$doc.display

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

$doc.display

THOMAS, BRIAN M (ATTSI)
This is a two-part question:

First, somewhere on xwiki.org, I found a discussion Ludovic had about
the design strategy of XWiki, and I seem to recall that he mentioned
that the property types in XWiki objects were extensible, which I can
well believe.  However, I have searched in vain for any mention of how
to do this, and it looks as though it requires adding Java classes to
the server, and at minimum a database schema change.  However, some hope
remains because it seems that there may be a way to create aggregate
objects from simple types.  How can this be done?

Second, how do I learn the different display modes and what they mean to
the $doc.display method?  I note that the "xcode" parameter's value
sometimes corresponds to a Velocity script (e.g. "rdf" to rdf.vm, etc.).
What I would like to be able to do is to create a custom display mode so
that, in conjunction possibly with an aggregate type, I can, for
example, create an arbitrarily-deep hierarchical menu structure, and
when I invoke a particular xcode or other mode, $doc.display will use my
template to decorate the data with xml that will make links that invoke
javascript to show or hide their contents.

In general, it appears there are lots of very valuable constants (format
strings, display modes, special codes, etc.) throughout the system that
are not useful to me because I don't know about them.  The javadoc APIs
hint at them, and some of the wiki docs use them.  How can I learn of
them, especially those that are simply the result of configurations that
I can easily extend?

This is a wonderful product, and developing with it is fabulously easy -
once I figure out stuff, which is excruciatingly difficult.  I am sure
that you are working furiously on the project, but I wonder how much
more effectively you could work if the APIs were more effectively
documented?  Then lots more work could get done, because others would be
able to work much more effectively, and have plenty of time left over to
contribute our stuff back.  That's how it would work with me, at
least...

brain[sic]



--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

Re: $doc.display

Ludovic Dubost

I agree completely.. We will make a push on documentation..
I've started a page for URLs:

http://www.xwiki.org/xwiki/bin/view/DevGuide/Controler

THOMAS, BRIAN M (SBCSI) a écrit :

> This is a two-part question:
>
> First, somewhere on xwiki.org, I found a discussion Ludovic had about
> the design strategy of XWiki, and I seem to recall that he mentioned
> that the property types in XWiki objects were extensible, which I can
> well believe.  However, I have searched in vain for any mention of how
> to do this, and it looks as though it requires adding Java classes to
> the server, and at minimum a database schema change.  However, some hope
> remains because it seems that there may be a way to create aggregate
> objects from simple types.  How can this be done?
>
> Second, how do I learn the different display modes and what they mean to
> the $doc.display method?  I note that the "xcode" parameter's value
> sometimes corresponds to a Velocity script (e.g. "rdf" to rdf.vm, etc.).
> What I would like to be able to do is to create a custom display mode so
> that, in conjunction possibly with an aggregate type, I can, for
> example, create an arbitrarily-deep hierarchical menu structure, and
> when I invoke a particular xcode or other mode, $doc.display will use my
> template to decorate the data with xml that will make links that invoke
> javascript to show or hide their contents.
>
> In general, it appears there are lots of very valuable constants (format
> strings, display modes, special codes, etc.) throughout the system that
> are not useful to me because I don't know about them.  The javadoc APIs
> hint at them, and some of the wiki docs use them.  How can I learn of
> them, especially those that are simply the result of configurations that
> I can easily extend?
>
> This is a wonderful product, and developing with it is fabulously easy -
> once I figure out stuff, which is excruciatingly difficult.  I am sure
> that you are working furiously on the project, but I wonder how much
> more effectively you could work if the APIs were more effectively
> documented?  Then lots more work could get done, because others would be
> able to work much more effectively, and have plenty of time left over to
> contribute our stuff back.  That's how it would work with me, at
> least...
>
> brain[sic]
>
>  
> ------------------------------------------------------------------------
>
>
> --
> You receive this message as a subscriber of the [hidden email] mailing list.
> To unsubscribe: mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>  

--
Ludovic Dubost
XPertNet: http://www.xpertnet.fr/
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost AIM: nvludo Yahoo: ludovic




--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
Reply | Threaded
Open this post in threaded view
|

RE: $doc.display

THOMAS, BRIAN M (ATTSI)
In reply to this post by THOMAS, BRIAN M (ATTSI)
A good beginning.  Sorry, I kept saying "xcode" when I meant "xpage" - don't know why I got that stuck in my head.

So, according to the page, my inference was correct: that the "xpage" parameter specifies the name of a Velocity template.

What exactly, then, happens to the document named in the "template" parameter?  It is my hope that this, which you describe as "static content", would be copied into the target document before editing, but it isn't listed as a possible parameter to the "edit" action.

brain[sic]

-----Original Message-----
From: Ludovic Dubost [mailto:[hidden email]]
Sent: Saturday, February 18, 2006 7:35 AM
To: [hidden email]
Subject: Re: [xwiki-users] $doc.display



I agree completely.. We will make a push on documentation.. I've started a page for URLs:

http://www.xwiki.org/xwiki/bin/view/DevGuide/Controler

THOMAS, BRIAN M (SBCSI) a écrit :

> This is a two-part question:
>
> First, somewhere on xwiki.org, I found a discussion Ludovic had about
> the design strategy of XWiki, and I seem to recall that he mentioned
> that the property types in XWiki objects were extensible, which I can
> well believe.  However, I have searched in vain for any mention of how
> to do this, and it looks as though it requires adding Java classes to
> the server, and at minimum a database schema change.  However, some
> hope remains because it seems that there may be a way to create
> aggregate objects from simple types.  How can this be done?
>
> Second, how do I learn the different display modes and what they mean
> to the $doc.display method?  I note that the "xcode" parameter's value
> sometimes corresponds to a Velocity script (e.g. "rdf" to rdf.vm,
> etc.). What I would like to be able to do is to create a custom
> display mode so that, in conjunction possibly with an aggregate type,
> I can, for example, create an arbitrarily-deep hierarchical menu
> structure, and when I invoke a particular xcode or other mode,
> $doc.display will use my template to decorate the data with xml that
> will make links that invoke javascript to show or hide their contents.
>
> In general, it appears there are lots of very valuable constants
> (format strings, display modes, special codes, etc.) throughout the
> system that are not useful to me because I don't know about them.  The
> javadoc APIs hint at them, and some of the wiki docs use them.  How
> can I learn of them, especially those that are simply the result of
> configurations that I can easily extend?
>
> This is a wonderful product, and developing with it is fabulously easy
> - once I figure out stuff, which is excruciatingly difficult.  I am
> sure that you are working furiously on the project, but I wonder how
> much more effectively you could work if the APIs were more effectively
> documented?  Then lots more work could get done, because others would
> be able to work much more effectively, and have plenty of time left
> over to contribute our stuff back.  That's how it would work with me,
> at least...
>
> brain[sic]
>
>  
> ----------------------------------------------------------------------
> --
>
>
> --
> You receive this message as a subscriber of the
> [hidden email] mailing list. To unsubscribe:
> mailto:[hidden email]
> For general help: mailto:[hidden email]?subject=help
> ObjectWeb mailing lists service home page: http://www.objectweb.org/wws
>  

--
Ludovic Dubost
XPertNet: http://www.xpertnet.fr/
Blog: http://www.ludovic.org/blog/
XWiki: http://www.xwiki.com
Skype: ldubost AIM: nvludo Yahoo: ludovic





--
You receive this message as a subscriber of the [hidden email] mailing list.
To unsubscribe: mailto:[hidden email]
For general help: mailto:[hidden email]?subject=help
ObjectWeb mailing lists service home page: http://www.objectweb.org/wws