You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Carsten Ziegeler <cz...@s-und-n.de> on 2003/01/09 09:28:02 UTC
[RT]: Dynamic variables in the Sitemap / Input Modules revisited
Hi,
I think today is a good day to....dada...continue our
famous InputModules discussion. hurray.
Ok, I think we currently have a deadlock. Some of us say a) and not b)
and the others say b) and not a). Who is right? I don't know.
Would a vote help? No, definitly not.
So instead we should try to reach consensus (and I think this will not
be too hard).
I have the perception that we did one thing wrong: we started
by looking at the implementation and from there turned over to
the concept. And this is not they way it should be. We should first
discuss the concept and can then later on thing about how
to implement it or what existing implementations we can use.
So please do not use any java code, class names etc in this RT.
In addition I will try to avoid all the names that already have
a meaning, like InputModules, Properties etc.
So, on what do we agree?
First, of course, we want a dynamic substitution mechanism in the
sitemap that we can use nearly everywhere. This mechanism uses
different objects to resolve the dynamic values. An object is
represented by a distinct name and gets an identifier for the
actual value. We agree, that the syntax for using this is:
{object_identifier:key}
An example is {request-param:myparameter}.
The key passed to the object is custom to the object, which means
that it can be a simple name or an xpath expression or whatever as
long as it is representable as a string/text.
We all agree that the objects that provide those values should
be declared in the sitemap as components (I use the name objects
here to avoid any collision, so let's not discuss this):
<map:objects>
<map:object name="request-param" ..../>
</map:objects>
I think, up to this point we all agree, right?
Now, let's come to the missing part, chaining!
I think we have currently two approaches:
a) Chaining is done by special objects, so you have something like
this (let's not discuss the "first"/"second" syntax):
<map:objects>
<map:object name="request-param" ..../>
<map:object name="session-attr" ..../>
<map:object name="my_chain ....>
<first>request-param</first>
<second>session-attr</second>
...
</map:object>
</map:objects>
And I can simply use {request-param:myname} and {my_chain:skin}
b) Chainers (?) are special components:
<map:objects>
<map:object name="request-param" ..../>
<map:object name="session-attr" ..../>
</map:objects>
<map:object-chainers>
<map:object-chainer name="my_chain ....>
<first>request-param</first>
<second>session-attr</second>
...
</map:object>
</map:object-chainers>
And I can simply use {request-param:myname} and {my_chain:skin}
Personally I would opt for a) because b) adds another component type
to the sitemap that is not really needed and it might be confusing
that {request-param:myname} is handled by an object component and
{my_chain:skin} by an object-chainer.
Is everything correctly reproduced? Is anything missing for the concept?
PS: you see that I really try to avoid our long and great naming
discussion - when we have the concept we will find proper names
for it, believe me.... ;)
Carsten
Carsten Ziegeler
Open Source Group, S&N AG
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 09.Jan.2003 -- 10:22 AM, Carsten Ziegeler wrote:
>
> Christian Haul wrote:
> >
> > On 09.Jan.2003 -- 09:28 AM, Carsten Ziegeler wrote:
> > > b) Chainers (?) are special components:
> > >
> > > <map:objects>
> > > <map:object name="request-param" ..../>
> > > <map:object name="session-attr" ..../>
> > > </map:objects>
> > > <map:object-chainers>
> > > <map:object-chainer name="my_chain ....>
> > > <first>request-param</first>
> > > <second>session-attr</second>
> > > ...
> > > </map:object>
> > > </map:object-chainers>
> > >
> > > And I can simply use {request-param:myname} and {my_chain:skin}
> > >
> > > Personally I would opt for a) because b) adds another component type
> > > to the sitemap that is not really needed and it might be confusing
> > > that {request-param:myname} is handled by an object component and
> > > {my_chain:skin} by an object-chainer.
> >
> > Right. AFAIK b) has never been proposed.
> >
> It has!
Really? Well, I don't think it's coming back :-)
>
> > BTW the real differences have been for the case where this 'pipeline'
> > in a) spans several stages.
> >
> Can you expand on this a little bit?
OK, the famous mapping example:
Suppose there are two sources: request parameters and a XML file. The
XML file contains default values. For reasons out of your control,
this file contains different keys than the names of the expected
request parameters. Thus a mapping needs to take place.
Note that lines with a "*)" comment could be inherited from the parent
or a central sitemap.
i) nest it
<map:objects>
<map:object name="request-param" ... /> <!-- *) -->
<map:object name="xmlfile" ... /> <!-- *) -->
<map:object name="map" ... /> <!-- *) -->
<map:object name="chain" ... >
<first name="request-param"/>
<second name="map" ...>
<prefix>/this/app/defaults/</prefix>
<use name="xmlfile"/>
</second>
</map:object>
</map:objects>
ii) construct from intermediates
<map:objects>
<map:object name="request-param" ... /> <!-- *) -->
<map:object name="xmlfile" ... /> <!-- *) -->
<map:object name="mymap" ... />
<prefix>/this/app/defaults/</prefix>
<use name="xmlfile"/>
</map:object>
<map:object name="chain" ... >
<first name="request-param"/>
<second name="mymap"/>
</map:object>
</map:objects>
Now, i) is clearer to me especially, as some declarations could be
inherited but ii) will produce slightly faster code. Today, both are
possible and can be mixed, which is good IMO.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Christian Haul wrote:
>
> On 09.Jan.2003 -- 09:28 AM, Carsten Ziegeler wrote:
> > Now, let's come to the missing part, chaining!
> >
> > I think we have currently two approaches:
> > a) Chaining is done by special objects, so you have something like
> > this (let's not discuss the "first"/"second" syntax):
> >
> > <map:objects>
> > <map:object name="request-param" ..../>
> > <map:object name="session-attr" ..../>
> > <map:object name="my_chain ....>
> > <first>request-param</first>
> > <second>session-attr</second>
> > ...
> > </map:object>
> > </map:objects>
> > And I can simply use {request-param:myname} and {my_chain:skin}
>
> This is how it works today. Only that it is in cocoon.xconf.
>
Yes.
> > b) Chainers (?) are special components:
> >
> > <map:objects>
> > <map:object name="request-param" ..../>
> > <map:object name="session-attr" ..../>
> > </map:objects>
> > <map:object-chainers>
> > <map:object-chainer name="my_chain ....>
> > <first>request-param</first>
> > <second>session-attr</second>
> > ...
> > </map:object>
> > </map:object-chainers>
> >
> > And I can simply use {request-param:myname} and {my_chain:skin}
> >
> > Personally I would opt for a) because b) adds another component type
> > to the sitemap that is not really needed and it might be confusing
> > that {request-param:myname} is handled by an object component and
> > {my_chain:skin} by an object-chainer.
>
> Right. AFAIK b) has never been proposed.
>
It has!
> BTW the real differences have been for the case where this 'pipeline'
> in a) spans several stages.
>
Can you expand on this a little bit?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 09.Jan.2003 -- 09:28 AM, Carsten Ziegeler wrote:
> Now, let's come to the missing part, chaining!
>
> I think we have currently two approaches:
> a) Chaining is done by special objects, so you have something like
> this (let's not discuss the "first"/"second" syntax):
>
> <map:objects>
> <map:object name="request-param" ..../>
> <map:object name="session-attr" ..../>
> <map:object name="my_chain ....>
> <first>request-param</first>
> <second>session-attr</second>
> ...
> </map:object>
> </map:objects>
> And I can simply use {request-param:myname} and {my_chain:skin}
This is how it works today. Only that it is in cocoon.xconf.
> b) Chainers (?) are special components:
>
> <map:objects>
> <map:object name="request-param" ..../>
> <map:object name="session-attr" ..../>
> </map:objects>
> <map:object-chainers>
> <map:object-chainer name="my_chain ....>
> <first>request-param</first>
> <second>session-attr</second>
> ...
> </map:object>
> </map:object-chainers>
>
> And I can simply use {request-param:myname} and {my_chain:skin}
>
> Personally I would opt for a) because b) adds another component type
> to the sitemap that is not really needed and it might be confusing
> that {request-param:myname} is handled by an object component and
> {my_chain:skin} by an object-chainer.
Right. AFAIK b) has never been proposed.
BTW the real differences have been for the case where this 'pipeline'
in a) spans several stages.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Jeff Turner <je...@apache.org>.
On Thu, Jan 09, 2003 at 09:28:02AM +0100, Carsten Ziegeler wrote:
...
> I think we have currently two approaches:
> a) Chaining is done by special objects, so you have something like
> this (let's not discuss the "first"/"second" syntax):
>
> <map:objects>
> <map:object name="request-param" ..../>
> <map:object name="session-attr" ..../>
> <map:object name="my_chain ....>
> <first>request-param</first>
> <second>session-attr</second>
> ...
> </map:object>
> </map:objects>
> And I can simply use {request-param:myname} and {my_chain:skin}
>
> b) Chainers (?) are special components:
>
> <map:objects>
> <map:object name="request-param" ..../>
> <map:object name="session-attr" ..../>
> </map:objects>
> <map:object-chainers>
> <map:object-chainer name="my_chain ....>
> <first>request-param</first>
> <second>session-attr</second>
> ...
> </map:object>
> </map:object-chainers>
>
> And I can simply use {request-param:myname} and {my_chain:skin}
>
> Personally I would opt for a) because b) adds another component type
> to the sitemap that is not really needed and it might be confusing
> that {request-param:myname} is handled by an object component and
> {my_chain:skin} by an object-chainer.
+1 for a)
Btw, Forrest is now using InputModules extensively, both in the sitemap,
and in XML links, like <link href="site:index">, where 'site' identifies
an InputModule and 'index' is the key.
http://forrestbot.cocoondev.org/sites/xml-forrest/linking.html#implementation
Implementing this, I found the current InputModule architecture
(specifically, chaining) quite sufficient.
--Jeff
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: InspectableSources and InputModules (Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited)
Posted by Jeff Turner <je...@apache.org>.
On Fri, Jan 10, 2003 at 10:55:38AM +0100, Stephan Michels wrote:
>
> On Fri, 10 Jan 2003, Jeff Turner wrote:
>
> > > > How about:
> > > >
> > > > <source name="dir" collection="true">
> > > > <source name="file.xml"/>
> > > > <source name="file.jpg" height="${jpg:file.jpg#height}" width="${jpg:file.jpg#width}"/>
> > > > </source>
> > >
> > > Something like that.
> > >
> > > > Although, for your specific need, I think the InspectableSource-aware
> > > > Generator sounds simpler. Assuming I've understood correctly.
> > >
> > > Hmm, I think I had an idea. What about something like that
> > >
> > > abstract SourceInputModule
> > > {
> > > Object getAttribute( String name, Configuration modeConf, Map
> > > objectModel ) throws ConfigurationException
> > > {
> > > int index = name.indexOf("#");
> > > String uri = name.substring(0, index-1);
> > > String name = name.substring(index+1);
> > >
> > > return getSourceAttribute(uri, name, modeConf, objectModel);
> > > }
> > >
> > > abstarct Object getSourceAttribute( String uri , String name ,
> > > Configuration modeConf, Map objectModel )
> > > throws ConfigurationException;
> > > }
> > >
> > > It uses the conventional interface.
> >
> > Looks decent, but in practice, most classes will want to inherit from
> > more functional superclasses like AbstractJXPathModule, or
> > AbstractMetaModule, and Java doesn't have multiple inheritance. For
> > example, XMLFileModule works on a Source, but needs AbstractJXPathModule,
> > so couldn't use SourceInputModule.
>
> Okay, how about using SourceInputModule as interface, and to provide
> an abstract implementation using the InputModule interface.
>
> Hmm, I hoped that I could prevent to create a new interface.
It's only 3 lines of code.. not worth creating a new class/interface over
surely? Or do you need the class/interface so an 'instanceof' test can
distinguish Source InputModules from ordinary ones?
--Jeff
> Anyone against the new interface, or using the modules/input dir?
>
> Stephan Michels.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: InspectableSources and InputModules (Re: [RT]: Dynamic variables
in the Sitemap / Input Modules revisited)
Posted by Stephan Michels <st...@apache.org>.
On Fri, 10 Jan 2003, Jeff Turner wrote:
> > > How about:
> > >
> > > <source name="dir" collection="true">
> > > <source name="file.xml"/>
> > > <source name="file.jpg" height="${jpg:file.jpg#height}" width="${jpg:file.jpg#width}"/>
> > > </source>
> >
> > Something like that.
> >
> > > Although, for your specific need, I think the InspectableSource-aware
> > > Generator sounds simpler. Assuming I've understood correctly.
> >
> > Hmm, I think I had an idea. What about something like that
> >
> > abstract SourceInputModule
> > {
> > Object getAttribute( String name, Configuration modeConf, Map
> > objectModel ) throws ConfigurationException
> > {
> > int index = name.indexOf("#");
> > String uri = name.substring(0, index-1);
> > String name = name.substring(index+1);
> >
> > return getSourceAttribute(uri, name, modeConf, objectModel);
> > }
> >
> > abstarct Object getSourceAttribute( String uri , String name ,
> > Configuration modeConf, Map objectModel )
> > throws ConfigurationException;
> > }
> >
> > It uses the conventional interface.
>
> Looks decent, but in practice, most classes will want to inherit from
> more functional superclasses like AbstractJXPathModule, or
> AbstractMetaModule, and Java doesn't have multiple inheritance. For
> example, XMLFileModule works on a Source, but needs AbstractJXPathModule,
> so couldn't use SourceInputModule.
Okay, how about using SourceInputModule as interface, and to provide
an abstract implementation using the InputModule interface.
Hmm, I hoped that I could prevent to create a new interface.
Anyone against the new interface, or using the modules/input dir?
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: InspectableSources and InputModules (Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited)
Posted by Jeff Turner <je...@apache.org>.
On Thu, Jan 09, 2003 at 02:14:49PM +0100, Stephan Michels wrote:
> On Thu, 9 Jan 2003, Jeff Turner wrote:
...
> > Why not have the SourceDescriptionGenerator do:
> >
> > for (each file in the directory):
> > if (source instanceof InspectableSource) {
> > sourceProperty = source.getSourceProperties(),
> > createNewXMLAttribute(sourceProp.getName(), sourceProp.getValue());
> > }
> >
> > Then you'd automatically get attributes for any file metadata that is
> > made available by the InspectableSource.
>
> The difference between SourceInspector and InspectableSource is that
> SourceInspector retrieves Properties independend of the Source
> implementation.
> For example, if want get height/width from a image it doesn't have
> anything to do with if had a ResourceSource or SitemapSource.
I see. Well, same idea applies.. the generator feeds the Source to every
available SourceInspector, and for every SourceProperty it gets back,
creates an attribute.
...
> > How about:
> >
> > <source name="dir" collection="true">
> > <source name="file.xml"/>
> > <source name="file.jpg" height="${jpg:file.jpg#height}" width="${jpg:file.jpg#width}"/>
> > </source>
>
> Something like that.
>
> > Although, for your specific need, I think the InspectableSource-aware
> > Generator sounds simpler. Assuming I've understood correctly.
>
> Hmm, I think I had an idea. What about something like that
>
> abstract SourceInputModule
> {
> Object getAttribute( String name, Configuration modeConf, Map
> objectModel ) throws ConfigurationException
> {
> int index = name.indexOf("#");
> String uri = name.substring(0, index-1);
> String name = name.substring(index+1);
>
> return getSourceAttribute(uri, name, modeConf, objectModel);
> }
>
> abstarct Object getSourceAttribute( String uri , String name ,
> Configuration modeConf, Map objectModel )
> throws ConfigurationException;
> }
>
> It uses the conventional interface.
Looks decent, but in practice, most classes will want to inherit from
more functional superclasses like AbstractJXPathModule, or
AbstractMetaModule, and Java doesn't have multiple inheritance. For
example, XMLFileModule works on a Source, but needs AbstractJXPathModule,
so couldn't use SourceInputModule.
--Jeff
> Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: InputModules and Transformers
Posted by Vadim Gritsenko <va...@verizon.net>.
Jeff Turner wrote:
>On Fri, Jan 10, 2003 at 09:24:36AM -0500, Andy Lewis wrote:
>
>
>>I've been watching the extensive discussions about input modules for
>>some time now, and if I understand them corectly, it brings me to a
>>couple of questions... Is there / should there be / can there be a
>>transformer that allows access to data from input modules? Something
>>that allows values to be accessed and placed in the SAX stream?
>>
>>
>
>There is a LinkRewriterTransformer which does this for certain
>attributes:
>
>http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15611
>
>(and Chris just committed.. thanks)
>
>It would be simple to modify this to replace ${module:key} tokens in the
>SAX characters() method,
>
If you do this - don't forget to buffer all characters() before doing
replacements.
Vadim
> rather than attribute values.
>
>
>
>>How does this compare to ro correlate with the session transformer that
>>originated with the portal component donation? Are they / should they
>>be the same?
>>
>>
>
>Didn't know about it, hidden away in a block.. it looks quite powerful.
>Anything based on InputModules can only do string->string conversion, so
>I don't think there's too much overlap.
>
>--Jeff
>
>
>
>>I have found the session transformer invaluable in many
>>cases, but it seems to me that extending it to use input modules would
>>REALLY be useful.... thoughts?
>>
>>--
>>"The heights of genius are only measurable by the depths of stupidity."
>>
>>
>>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: InputModules and Transformers
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 11.Jan.2003 -- 02:08 AM, Jeff Turner wrote:
> Anything based on InputModules can only do string->string conversion, so
This ought to be string -> object
If it's XMLizable, it could be included for example.
String -> string is valid when used in the sitemap, though.
But I can't comment on the SessionTransformer.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: InputModules and Transformers
Posted by Jeff Turner <je...@apache.org>.
On Fri, Jan 10, 2003 at 09:24:36AM -0500, Andy Lewis wrote:
>
> I've been watching the extensive discussions about input modules for
> some time now, and if I understand them corectly, it brings me to a
> couple of questions... Is there / should there be / can there be a
> transformer that allows access to data from input modules? Something
> that allows values to be accessed and placed in the SAX stream?
There is a LinkRewriterTransformer which does this for certain
attributes:
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15611
(and Chris just committed.. thanks)
It would be simple to modify this to replace ${module:key} tokens in the
SAX characters() method, rather than attribute values.
> How does this compare to ro correlate with the session transformer that
> originated with the portal component donation? Are they / should they
> be the same?
Didn't know about it, hidden away in a block.. it looks quite powerful.
Anything based on InputModules can only do string->string conversion, so
I don't think there's too much overlap.
--Jeff
> I have found the session transformer invaluable in many
> cases, but it seems to me that extending it to use input modules would
> REALLY be useful.... thoughts?
>
> --
> "The heights of genius are only measurable by the depths of stupidity."
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RequestDispatcher with Cocoon
Posted by Andy Lewis <aj...@ascii27.net>.
If I actually get it working, I would certinaly contribute it. Yeah, ugly, but probalby no really
CLEAN way to achieve it.
At any rate, many thanks for the guidance - I'll go with a reader. I suspected that using the
wrong componenet would cause me grief....
> Vadim Gritsenko wrote:
>
>> Andy Lewis wrote:
>>
>>> I have a need to, under specific circumstances, do a
>>> RequestDispatcher.forward out of Cocoon. I've
>>> not found any support for this in Cocoon. Alternatives won't work since I need to do this
>>> while
>>> preserving request attributes. I would expect to be able to code this as an Action without
>>> extreme
>>> difficulty, but I thought I would thorw the idea to the list first and see if anyone has any
>>> ideas, comments, or suggestions...(something other than "No! Don't do it!" :)
>>> Many thanks....
>>>
>>
>> Why do I think that reader is much better place for something like this (...assuming that
>> it's possible...)?
>
>
> Because forwarding delegates the production of the output to the target resource. But Cocoon
> expects the sitemap to produce something or an error is displayed.
>
> So the only place where such forwarding is possible is in a Cocoon component that feeds the
> output with abitrary binary data, and Cocoon names it a reader ;-)
>
> Andy, would you like to contribute a "ForwardReader", how ugly and servlet-tied as it may be ?
>
> Sylvain
>
> --
> Sylvain Wallez Anyware Technologies
> http://www.apache.org/~sylvain http://www.anyware-tech.com { XML, Java, Cocoon,
> OpenSource }*{ Training, Consulting, Projects }
>
>
>
> --------------------------------------------------------------------- To unsubscribe, e-mail:
> cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
--
"The heights of genius are only measurable by the depths of stupidity."
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RequestDispatcher with Cocoon
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
> Vadim Gritsenko wrote:
>
>> Andy Lewis wrote:
>>
>>> I have a need to, under specific circumstances, do a
>>> RequestDispatcher.forward out of Cocoon. I've
>>> not found any support for this in Cocoon. Alternatives won't work
>>> since I need to do this while
>>> preserving request attributes. I would expect to be able to code
>>> this as an Action without extreme
>>> difficulty, but I thought I would thorw the idea to the list first
>>> and see if anyone has any
>>> ideas, comments, or suggestions...(something other than "No! Don't
>>> do it!" :)
>>> Many thanks....
>>>
>>
>> Why do I think that reader is much better place for something like
>> this (...assuming that it's possible...)?
>
>
>
> Because forwarding delegates the production of the output to the
> target resource. But Cocoon expects the sitemap to produce something
> or an error is displayed.
>
> So the only place where such forwarding is possible is in a Cocoon
> component that feeds the output with abitrary binary data, and Cocoon
> names it a reader ;-)
Thanks for explaining my thoughts ;)
Vadim
> Andy, would you like to contribute a "ForwardReader", how ugly and
> servlet-tied as it may be ?
>
> Sylvain
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RequestDispatcher with Cocoon
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
> Andy Lewis wrote:
>
>> I have a need to, under specific circumstances, do a
>> RequestDispatcher.forward out of Cocoon. I've
>> not found any support for this in Cocoon. Alternatives won't work
>> since I need to do this while
>> preserving request attributes. I would expect to be able to code this
>> as an Action without extreme
>> difficulty, but I thought I would thorw the idea to the list first
>> and see if anyone has any
>> ideas, comments, or suggestions...(something other than "No! Don't
>> do it!" :)
>> Many thanks....
>>
>
> Why do I think that reader is much better place for something like
> this (...assuming that it's possible...)?
Because forwarding delegates the production of the output to the target
resource. But Cocoon expects the sitemap to produce something or an
error is displayed.
So the only place where such forwarding is possible is in a Cocoon
component that feeds the output with abitrary binary data, and Cocoon
names it a reader ;-)
Andy, would you like to contribute a "ForwardReader", how ugly and
servlet-tied as it may be ?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: RequestDispatcher with Cocoon
Posted by Vadim Gritsenko <va...@verizon.net>.
Andy Lewis wrote:
>I have a need to, under specific circumstances, do a RequestDispatcher.forward out of Cocoon. I've
>not found any support for this in Cocoon. Alternatives won't work since I need to do this while
>preserving request attributes. I would expect to be able to code this as an Action without extreme
>difficulty, but I thought I would thorw the idea to the list first and see if anyone has any
>ideas, comments, or suggestions...(something other than "No! Don't do it!" :)
>Many thanks....
>
Why do I think that reader is much better place for something like this
(...assuming that it's possible...)?
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RequestDispatcher with Cocoon
Posted by Andy Lewis <aj...@ascii27.net>.
I have a need to, under specific circumstances, do a RequestDispatcher.forward out of Cocoon. I've
not found any support for this in Cocoon. Alternatives won't work since I need to do this while
preserving request attributes. I would expect to be able to code this as an Action without extreme
difficulty, but I thought I would thorw the idea to the list first and see if anyone has any
ideas, comments, or suggestions...(something other than "No! Don't do it!" :)
Many thanks....
--
"The heights of genius are only measurable by the depths of stupidity."
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
InputModules and Transformers
Posted by Andy Lewis <aj...@ascii27.net>.
I've been watching the extensive discussions about input modules for some time now, and if I
understand them corectly, it brings me to a couple of questions...
Is there / should there be / can there be a transformer that allows access to data from input
modules? Something that allows values to be accessed and placed in the SAX stream?
How does this compare to ro correlate with the session transformer that originated with the portal
component donation? Are they / should they be the same?
I have found the session transformer invaluable in many cases, but it seems to me that extending
it to use input modules would REALLY be useful....
thoughts?
--
"The heights of genius are only measurable by the depths of stupidity."
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: InspectableSources and InputModules (Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited)
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 09.Jan.2003 -- 02:14 PM, Stephan Michels wrote:
> On Thu, 9 Jan 2003, Jeff Turner wrote:
>
> > On Thu, Jan 09, 2003 at 12:23:42PM +0100, Stephan Michels wrote:
> > ...
> > > My problem is that I have always two parameters: the source uri
> > > and the property name.
> >
> > How about:
> >
> > <source name="dir" collection="true">
> > <source name="file.xml"/>
> > <source name="file.jpg" height="${jpg:file.jpg#height}" width="${jpg:file.jpg#width}"/>
> > </source>
>
> Something like that.
This was originally thought to be handled through the configuration
object that is passed to the module. Here -- as well as in the sitemap
-- this is obviously not possible.
The link syntax is quite natural here. Although it does not extent to
multiple parameters. HTTP GET syntax could be used as well:
{jpg:height?file=file.jpg} (height is a property of file.jpg but from
the original intention, file.jpg is a configuration parameter)
So, a solution could be to construct a configuration object from the
parameter. This could be done in the transformer and inside the
sitemap variable resolver or it could be engineered into the universal
parameter passing scheme.
This would perhaps also address the issues Carsten has with the
current interface?
Constructing configurations on the fly was said to be expensive -- I
have no idea how expensive it really is.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: InspectableSources and InputModules (Re: [RT]: Dynamic variables
in the Sitemap / Input Modules revisited)
Posted by Stephan Michels <st...@apache.org>.
On Thu, 9 Jan 2003, Jeff Turner wrote:
> On Thu, Jan 09, 2003 at 12:23:42PM +0100, Stephan Michels wrote:
> ...
> > From Bugzilla:
> > > While the transformer I've implemented happens to rewrite links, this
> > > transformer could be generalized to transform any part of the incoming
> > > XML. For
> > > example, we could rewrite any occurrence of ${scheme:address} in the
> > > source XML.
> >
> > This could be very useful. I have the following problem, because of
> > the depending of the DirectoryGenerator to java.io.File, I have written
> > an equivalent, which used TraversableSource IF, the
> > SourceDescriptionGenerator. Then I saw the inherited Generator classes
> > like ImageDirectoryGenertor or MP3DirectoryGenerator etc. So my conclusion
> > was to find something more universal, which
> >
> > 1) Get the source
> > 2) Retrieve a source depended property, like image height and width
> > 3) Make a XML description
> >
> > As result I got a SourceInspector.
> >
> > And on the other hand I have Sources, which got common properties, and
> > I created a InspectableSource.
> >
> > Now, to come to the 'Dynamic variables' discussion I want to merge
> > these concept with the modules. For the first case, I thought about
> > something like this
> >
> > 1) <map:generator type="directory" src="dir/"/>
> > 2) <map:transformer src="getImageProbs.xsl"/>
> > 3) <map:transformer type="module"/>
> >
> > to 1)
> > <source name="dir" collection="true">
> > <source name="file.xml"/>
> > <source name="file.jpg"/>
> > </source>
> >
> > to 2)
> > <source name="dir" collection="true">
> > <source name="file.xml"/>
> > <source name="file.jpg" height="${jpg:height}" width="${jpg:width}"/>
> > </source>
> >
> > to 3)
> > <source name="dir" collection="true">
> > <source name="file.xml"/>
> > <source name="file.jpg" height="400" width="300"/>
> > </source>
>
> I don't know if I've fully understood..
>
> Would it be correct to say you're looking for a generic way to augment a
> DirectoryGenerator's output with file metadata?
>
> Forrest needs this too, to generate output like:
>
> <source name="dir" collection="true">
> <source name="index.xml" dc:title="Index" dc:author="Joe Bloggs"/>
> <source name="primer.xml" dc:title="Forrest Primer" dc:author="Steven Noels"/>
> <source name="linking.xml" dc:title="Menus and Linking" dc:author="Jeff Turner"/>
> ...
> </source>
>
>
> Why not have the SourceDescriptionGenerator do:
>
> for (each file in the directory):
> if (source instanceof InspectableSource) {
> sourceProperty = source.getSourceProperties(),
> createNewXMLAttribute(sourceProp.getName(), sourceProp.getValue());
> }
>
> Then you'd automatically get attributes for any file metadata that is
> made available by the InspectableSource.
The difference between SourceInspector and InspectableSource is that
SourceInspector retrieves Properties independend of the Source
implementation.
For example, if want get height/width from a image it doesn't have
anything to do with if had a ResourceSource or SitemapSource.
> > It could work similar with the common properties using the
> > InspectableSource.
>
> Yes, there seems a natural tie-in between InspectableSources and
> InputModules.
>
> > My problem is that I have always two parameters: the source uri
> > and the property name.
>
> How about:
>
> <source name="dir" collection="true">
> <source name="file.xml"/>
> <source name="file.jpg" height="${jpg:file.jpg#height}" width="${jpg:file.jpg#width}"/>
> </source>
Something like that.
> Although, for your specific need, I think the InspectableSource-aware
> Generator sounds simpler. Assuming I've understood correctly.
Hmm, I think I had an idea. What about something like that
abstract SourceInputModule
{
Object getAttribute( String name, Configuration modeConf, Map
objectModel ) throws ConfigurationException
{
int index = name.indexOf("#");
String uri = name.substring(0, index-1);
String name = name.substring(index+1);
return getSourceAttribute(uri, name, modeConf, objectModel);
}
abstarct Object getSourceAttribute( String uri , String name ,
Configuration modeConf, Map objectModel )
throws ConfigurationException;
}
It uses the conventional interface.
Any thoughts?
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
InspectableSources and InputModules (Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited)
Posted by Jeff Turner <je...@apache.org>.
On Thu, Jan 09, 2003 at 12:23:42PM +0100, Stephan Michels wrote:
...
> From Bugzilla:
> > While the transformer I've implemented happens to rewrite links, this
> > transformer could be generalized to transform any part of the incoming
> > XML. For
> > example, we could rewrite any occurrence of ${scheme:address} in the
> > source XML.
>
> This could be very useful. I have the following problem, because of
> the depending of the DirectoryGenerator to java.io.File, I have written
> an equivalent, which used TraversableSource IF, the
> SourceDescriptionGenerator. Then I saw the inherited Generator classes
> like ImageDirectoryGenertor or MP3DirectoryGenerator etc. So my conclusion
> was to find something more universal, which
>
> 1) Get the source
> 2) Retrieve a source depended property, like image height and width
> 3) Make a XML description
>
> As result I got a SourceInspector.
>
> And on the other hand I have Sources, which got common properties, and
> I created a InspectableSource.
>
> Now, to come to the 'Dynamic variables' discussion I want to merge
> these concept with the modules. For the first case, I thought about
> something like this
>
> 1) <map:generator type="directory" src="dir/"/>
> 2) <map:transformer src="getImageProbs.xsl"/>
> 3) <map:transformer type="module"/>
>
> to 1)
> <source name="dir" collection="true">
> <source name="file.xml"/>
> <source name="file.jpg"/>
> </source>
>
> to 2)
> <source name="dir" collection="true">
> <source name="file.xml"/>
> <source name="file.jpg" height="${jpg:height}" width="${jpg:width}"/>
> </source>
>
> to 3)
> <source name="dir" collection="true">
> <source name="file.xml"/>
> <source name="file.jpg" height="400" width="300"/>
> </source>
I don't know if I've fully understood..
Would it be correct to say you're looking for a generic way to augment a
DirectoryGenerator's output with file metadata?
Forrest needs this too, to generate output like:
<source name="dir" collection="true">
<source name="index.xml" dc:title="Index" dc:author="Joe Bloggs"/>
<source name="primer.xml" dc:title="Forrest Primer" dc:author="Steven Noels"/>
<source name="linking.xml" dc:title="Menus and Linking" dc:author="Jeff Turner"/>
...
</source>
Why not have the SourceDescriptionGenerator do:
for (each file in the directory):
if (source instanceof InspectableSource) {
sourceProperty = source.getSourceProperties(),
createNewXMLAttribute(sourceProp.getName(), sourceProp.getValue());
}
Then you'd automatically get attributes for any file metadata that is
made available by the InspectableSource.
> It could work similar with the common properties using the
> InspectableSource.
Yes, there seems a natural tie-in between InspectableSources and
InputModules.
> My problem is that I have always two parameters: the source uri
> and the property name.
How about:
<source name="dir" collection="true">
<source name="file.xml"/>
<source name="file.jpg" height="${jpg:file.jpg#height}" width="${jpg:file.jpg#width}"/>
</source>
Although, for your specific need, I think the InspectableSource-aware
Generator sounds simpler. Assuming I've understood correctly.
--Jeff
> Any help is appreciated, Stephan Michels.
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Stephan Michels <st...@apache.org>.
On Thu, 9 Jan 2003, Christian Haul wrote:
> On 09.Jan.2003 -- 11:24 AM, Stephan Michels wrote:
> >
> >
> > > First, of course, we want a dynamic substitution mechanism in the
> > > sitemap that we can use nearly everywhere. This mechanism uses
> > > different objects to resolve the dynamic values. An object is
> > > represented by a distinct name and gets an identifier for the
> > > actual value. We agree, that the syntax for using this is:
> > >
> > > {object_identifier:key}
> > >
> > > An example is {request-param:myparameter}.
> >
> > One question, should these 'Dynamic variables' only be accessible
> > in the sitemap? Or will be there a 'Dynamic variables'Transformer,
> > or something more universal?
>
> There is a transformer pending
>
> http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15611
>
> with a detailed description how forrest uses it
>
> http://forrestbot.cocoondev.org/sites/xml-forrest/linking.html
>
> Also, ther is another transformer for simple HTML forms using this
> technique. In addition, there is a logicsheet as well (input.xsl,
> broken in 2.0.4, fixed in CVS), a matcher and most notably the
> database actions from the modular package.
Thank you for the hint.
>From Bugzilla:
> While the transformer I've implemented happens to rewrite links, this
> transformer could be generalized to transform any part of the incoming
> XML. For
> example, we could rewrite any occurrence of ${scheme:address} in the
> source XML.
This could be very useful. I have the following problem, because of
the depending of the DirectoryGenerator to java.io.File, I have written
an equivalent, which used TraversableSource IF, the
SourceDescriptionGenerator. Then I saw the inherited Generator classes
like ImageDirectoryGenertor or MP3DirectoryGenerator etc. So my conclusion
was to find something more universal, which
1) Get the source
2) Retrieve a source depended property, like image height and width
3) Make a XML description
As result I got a SourceInspector.
And on the other hand I have Sources, which got common properties, and
I created a InspectableSource.
Now, to come to the 'Dynamic variables' discussion I want to merge
these concept with the modules. For the first case, I thought about
something like this
1) <map:generator type="directory" src="dir/"/>
2) <map:transformer src="getImageProbs.xsl"/>
3) <map:transformer type="module"/>
to 1)
<source name="dir" collection="true">
<source name="file.xml"/>
<source name="file.jpg"/>
</source>
to 2)
<source name="dir" collection="true">
<source name="file.xml"/>
<source name="file.jpg" height="${jpg:height}" width="${jpg:width}"/>
</source>
to 3)
<source name="dir" collection="true">
<source name="file.xml"/>
<source name="file.jpg" height="400" width="300"/>
</source>
It could work similar with the common properties using the
InspectableSource.
My problem is that I have always two parameters: the source uri
and the property name.
Any help is appreciated, Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 09.Jan.2003 -- 11:24 AM, Stephan Michels wrote:
>
>
> > First, of course, we want a dynamic substitution mechanism in the
> > sitemap that we can use nearly everywhere. This mechanism uses
> > different objects to resolve the dynamic values. An object is
> > represented by a distinct name and gets an identifier for the
> > actual value. We agree, that the syntax for using this is:
> >
> > {object_identifier:key}
> >
> > An example is {request-param:myparameter}.
>
> One question, should these 'Dynamic variables' only be accessible
> in the sitemap? Or will be there a 'Dynamic variables'Transformer,
> or something more universal?
There is a transformer pending
http://nagoya.apache.org/bugzilla/show_bug.cgi?id=15611
with a detailed description how forrest uses it
http://forrestbot.cocoondev.org/sites/xml-forrest/linking.html
Also, ther is another transformer for simple HTML forms using this
technique. In addition, there is a logicsheet as well (input.xsl,
broken in 2.0.4, fixed in CVS), a matcher and most notably the
database actions from the modular package.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 10.Jan.2003 -- 05:56 PM, Sylvain Wallez wrote:
>
> But I'm also wondering how we could also use the fact that InputModule
> returns Objects and not only Strings and would like to have a means to
> return an object for e.g. {request-attr:foo}.
Since all object have a toString() method, it should not be a problem
to return objects. Obviously, the using component has to be aware of
how to deal better with eg XMLizable. OTOH there are occasions where
the automatic conversion does not work.
For the sitemap I fear it would be a rather fundamental change to
allow objects as parameters. For a transformer, it could work.
> I also would like to introduce InputOutputModules. For example, I have a
> component which needs some data to work, but doesn't actually care where
> this data comes from, as it may depend from the application. For
> example, it could be {request-attr:foo} or {session-attr:bar} or
> {context-attr:baz}. So I would like to have an InputOutputModule that
> can be used by the application to set the value, and the by the
> component to read it.
Tough one. A component could implement both interfaces but would end
up as two instances in the component manager. Therefore storing data
in one instance could not be read from the other instance.
A third category is difficult as well, making the module handling
extra complex.
Would leave a helper component that stores the data and is looked up
by both instances. But that would need to be a singleton since thread
safe does not guarantee this AFAIK. IOW this leads to unwanted
complexity.
Or is there a way to have one instance registered with multiple
selectors?
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 10 Jan 2003, Sylvain Wallez wrote:
> Christian Haul wrote:
>
> >On 10.Jan.2003 -- 04:42 PM, Sylvain Wallez wrote:
> >
> >
> >>FYI, I patched a bit VariableResolver in treeprocessor.variables so that
> >>it can be used outside the sitemap context :
> >>
> >>VariableResolver resolver =
> >>VariableResolverFactory.getResolver("{module:name}", manager);
> >>String value = resolver.resolve(objectModel);
> >>if (resolver instanceof Disposable) ((Disposable)resolver).dispose();
> >>
> >>It works but isn't clean since it's not COP, so I'm thinking of turning
> >>it to a component :
> >>
> >>ComponentSelector selector =
> >>manager.lookup(VariableResolverSelector.ROLE + "Selector");
> >>VariableResolver resolver = selector.select("{module:name}");
> >>String value = resolver.resolve();
> >>selector.release(resolver);
> >>
> >>
> >
> >This sounds extremely cool!
> >
>
> Thanks.
>
> And Giacomo is right about the typo : "VariableResolverSelector.ROLE"
> should be "VariableResolver.ROLE". Chatting like we do these days on
> cocoon-dev makes me less careful ;-)
LOL
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Christian Haul wrote:
>On 10.Jan.2003 -- 04:42 PM, Sylvain Wallez wrote:
>
>
>>FYI, I patched a bit VariableResolver in treeprocessor.variables so that
>>it can be used outside the sitemap context :
>>
>>VariableResolver resolver =
>>VariableResolverFactory.getResolver("{module:name}", manager);
>>String value = resolver.resolve(objectModel);
>>if (resolver instanceof Disposable) ((Disposable)resolver).dispose();
>>
>>It works but isn't clean since it's not COP, so I'm thinking of turning
>>it to a component :
>>
>>ComponentSelector selector =
>>manager.lookup(VariableResolverSelector.ROLE + "Selector");
>>VariableResolver resolver = selector.select("{module:name}");
>>String value = resolver.resolve();
>>selector.release(resolver);
>>
>>
>
>This sounds extremely cool!
>
Thanks.
And Giacomo is right about the typo : "VariableResolverSelector.ROLE"
should be "VariableResolver.ROLE". Chatting like we do these days on
cocoon-dev makes me less careful ;-)
>>The selector is a special implementation that does the parsing already
>>existing in the TreeProcessor, and resolver.resolve() accesses the
>>object model through CocoonComponentManager.
>>
>>
>
>That would include parsing the complete string
>eg. "log-{request-param:name}-{date:now}.xml", right?
>
Exactly.
But I'm also wondering how we could also use the fact that InputModule
returns Objects and not only Strings and would like to have a means to
return an object for e.g. {request-attr:foo}.
I also would like to introduce InputOutputModules. For example, I have a
component which needs some data to work, but doesn't actually care where
this data comes from, as it may depend from the application. For
example, it could be {request-attr:foo} or {session-attr:bar} or
{context-attr:baz}. So I would like to have an InputOutputModule that
can be used by the application to set the value, and the by the
component to read it.
Thoughts ?
>Another thought: the Selector needs use the same component manager as the component requiring the lookup. Otherwise there could be a visibility problem, right? That is, if we allow module to be declared anywhere else than in cocoon.xconf.
>
You're right. A solution is for this component to be implicitely added
to the sitemap's CM, thus avoiding looking up back to the parent's CM.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Giacomo Pati <gi...@apache.org>.
On Fri, 10 Jan 2003, Christian Haul wrote:
> On 10.Jan.2003 -- 04:42 PM, Sylvain Wallez wrote:
> > FYI, I patched a bit VariableResolver in treeprocessor.variables so that
> > it can be used outside the sitemap context :
> >
> > VariableResolver resolver =
> > VariableResolverFactory.getResolver("{module:name}", manager);
> > String value = resolver.resolve(objectModel);
> > if (resolver instanceof Disposable) ((Disposable)resolver).dispose();
> >
> > It works but isn't clean since it's not COP, so I'm thinking of turning
> > it to a component :
> >
> > ComponentSelector selector =
> > manager.lookup(VariableResolverSelector.ROLE + "Selector");
> > VariableResolver resolver = selector.select("{module:name}");
> > String value = resolver.resolve();
> > selector.release(resolver);
After looking at it a second time:
Should it be:
ComponentSelector selector =
manager.lookup(VariableResolver.ROLE + "Selector");
As the Component Interface is giving the Role name not a Selector.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Christian Haul <ha...@dvs1.informatik.tu-darmstadt.de>.
On 10.Jan.2003 -- 04:42 PM, Sylvain Wallez wrote:
> FYI, I patched a bit VariableResolver in treeprocessor.variables so that
> it can be used outside the sitemap context :
>
> VariableResolver resolver =
> VariableResolverFactory.getResolver("{module:name}", manager);
> String value = resolver.resolve(objectModel);
> if (resolver instanceof Disposable) ((Disposable)resolver).dispose();
>
> It works but isn't clean since it's not COP, so I'm thinking of turning
> it to a component :
>
> ComponentSelector selector =
> manager.lookup(VariableResolverSelector.ROLE + "Selector");
> VariableResolver resolver = selector.select("{module:name}");
> String value = resolver.resolve();
> selector.release(resolver);
This sounds extremely cool!
> The selector is a special implementation that does the parsing already
> existing in the TreeProcessor, and resolver.resolve() accesses the
> object model through CocoonComponentManager.
That would include parsing the complete string
eg. "log-{request-param:name}-{date:now}.xml", right?
Another thought: the Selector needs use the same component manager as
the component requiring the lookup. Otherwise there could be a
visibility problem, right? That is, if we allow module to be declared
anywhere else than in cocoon.xconf.
Chris.
--
C h r i s t i a n H a u l
haul@informatik.tu-darmstadt.de
fingerprint: 99B0 1D9D 7919 644A 4837 7D73 FEF9 6856 335A 9E08
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Stephan Michels wrote
>
>
>>One question, should these 'Dynamic variables' only be accessible
>>in the sitemap? Or will be there a 'Dynamic variables'Transformer,
>>or something more universal?
>>
>>
>>
>Ah, good question, yes, this is something I forgot:
>
>These dynamic variables should also be accessible in any other
>component. They are avalon components that can be looked up
>using a corresponding selector.
>
>
FYI, I patched a bit VariableResolver in treeprocessor.variables so that
it can be used outside the sitemap context :
VariableResolver resolver =
VariableResolverFactory.getResolver("{module:name}", manager);
String value = resolver.resolve(objectModel);
if (resolver instanceof Disposable) ((Disposable)resolver).dispose();
It works but isn't clean since it's not COP, so I'm thinking of turning
it to a component :
ComponentSelector selector =
manager.lookup(VariableResolverSelector.ROLE + "Selector");
VariableResolver resolver = selector.select("{module:name}");
String value = resolver.resolve();
selector.release(resolver);
The selector is a special implementation that does the parsing already
existing in the TreeProcessor, and resolver.resolve() accesses the
object model through CocoonComponentManager.
Used in such a context, "VariableResolve" and "resolve()" doesn't sound
so good. So maybe another name ?
Thoughts ?
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephan Michels wrote
>
> One question, should these 'Dynamic variables' only be accessible
> in the sitemap? Or will be there a 'Dynamic variables'Transformer,
> or something more universal?
>
Ah, good question, yes, this is something I forgot:
These dynamic variables should also be accessible in any other
component. They are avalon components that can be looked up
using a corresponding selector.
Thanks
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited
Posted by Stephan Michels <st...@apache.org>.
> First, of course, we want a dynamic substitution mechanism in the
> sitemap that we can use nearly everywhere. This mechanism uses
> different objects to resolve the dynamic values. An object is
> represented by a distinct name and gets an identifier for the
> actual value. We agree, that the syntax for using this is:
>
> {object_identifier:key}
>
> An example is {request-param:myparameter}.
One question, should these 'Dynamic variables' only be accessible
in the sitemap? Or will be there a 'Dynamic variables'Transformer,
or something more universal?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org