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: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
