Gee... I was really thinking this was obvious... hence the relatively undetailed descriptions.

- XMLoutput objects are exchanged as part of the doTag nested calls. Therefore it is easy for something aimed at "receiving data" to create an XMLOutput object that does something just for the data() call, and passes-through for the rest.
This way a tag can receive a return value.
There's no way to do so with the context except delicate hacks and fragile naming-conventions.


- The objects being exchanged aren't meant ot be stored. They are part of the process... i.e. when I write
<math:determinant>
<math:product>
<math:matrix>xxx</math:matrix>
<math:matrix>xxx</math:matrix>
</math:product>
</math:determinant>
I am not storing the matrix of the product, I'm just passing it around.


- to me, it makes loads of sense to have tags that transform their output... and that should apply to object-data as well. (so that adding a constraint in jelly-swing would be simply a transformation)

- another fancy feature: the result of a bsf or beanshell script could be fed using this data() function... and thus used (it is currently only used when setting a variable)

At least, to me, it is the only way for a component child, like a swing button, to talk flexibly to a component container, without manually walking the hierarchy.

paul


Le 6 oct. 04, à 13:19, Dion Gillard a écrit :

So what's the advantage over this versus the context. XMLOutput is for
producing output, not storing data. The context is for storing data.

Paul, I must be missing something obvious here.


On Wed, 6 Oct 2004 10:37:21 +0200, Paul Libbrecht <[EMAIL PROTECTED]> wrote:
It does differ only by the fact that you write an >>Object<< and not
XML-nodes!
Only, this tiny change to be able to invoke the sacred functional word.


paul

Le 6 oct. 04, à 10:12, Dion Gillard a écrit :



How does this differ from writing to XMLOutput.

It seems XMLOutput is being confused with the context...?


On Wed, 6 Oct 2004 09:54:11 +0200, Paul Libbrecht <[EMAIL PROTECTED]> wrote:
Maybe one little quick example:

- currently, jelly-swing's ComponentTag calls, somewhere down in its
doTag() findAncestorWithClass(ContainerTag.class) to which they call
addComponent... At least one major drawback: putting such in a defined
tag does not work unless you go till the top-level container in the
defined tag (so no re-used swing script-snippets). Many other
issues...
- proposed: jelly-swing's ComponentTag should call, in its doTag(),
xmlOutput.data(myBean)
Advantage: works with scripts.


- currently: jelly-sql can only define variables with the current
result-sets
   Instead, the result-set could be given as data and the latter be
transformed by some other tags
   (e.g. a tag that would merge the fields, or extract the only
interesting ones).

Overall, the idea is to have the ability for a tag to give "return
value"  that is not XML.

I could produce many more scenarios. Most probably that should affect
UseBeanTag... though maybe not at first launch. I would propose to
enrich XMLOutput class itself (by adding the method doing the default
toString). This should really bother the release, I believe. Then I'd
like to concentrate on using this jelly-swing, with the hope to be
able
to make a jelly-swing-runner as a browser (maybe for jelly-swing 1.1
or
so).


paul

Le 6 oct. 04, à 00:05, Dion Gillard a écrit :



I'm not sure I understand what the use of this method is for Tags and
TagLibraries, since it's on XML output.


Can you give us an idea?


On Tue, 5 Oct 2004 21:31:08 +0200, Paul Libbrecht <[EMAIL PROTECTED]> wrote:

Dear Jellyers,

I'd like to propose an addition to the XMLOutput class, used
throughout
Jelly:
   a method called data() (or object) accepting any object.

By default... take the toString and call characters...
Actually, this is the way it is done with the return value of a Jexl
expression as part of a text node.


But the interesting comes in the non-default case:
- a math library could return a polynomial or numerical type... and
this could then be further evaluated by parents
- the arg element of jelly could actually avoid special treatment as
it
has currently
- most of my interest applies for jelly-swing: the components would
then want to call data(component) on the xmlOutput. The latter could
be
filtered by constraint-tags to call
data(component-with-constraints).
Finally, container tags could, also, filter, and receive the
resulting
data and add it.


I would look forward to comments !

-------------------------------------------------------------------- -
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]





--
http://www.multitask.com.au/people/dion/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------


To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]




--
http://www.multitask.com.au/people/dion/

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



Reply via email to