You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Jeff Turner <je...@apache.org> on 2003/01/09 13:54:19 UTC
InspectableSources and InputModules (Re: [RT]: Dynamic variables in the Sitemap / Input Modules revisited)
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: 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