You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Stephan Michels <st...@apache.org> on 2002/10/11 13:07:02 UTC
InputModules and SourceInspectors
Hi,
I currently not available(Learning for exams), but interesting
in the your discussion.
On my intentions to integrate Slide into Cocoon I developed
the InspectableSource and SourceInspector IFs. And now I'm
thinking about merging the two concepts, InputModules and
SourceInspectors.
The SourceInspectors are used to get information about
a Source, e.g. the height of an image. It should be an replacement
for the ImageDirectoryGenerator, and MP3DirectoryGenerator etc.
The InspectableSource should create the posibility to store
properties with the a source, like title, owner etc. It
should work similar to the WebDAV propfind and proppatch method.
So now the problem, at the moment the InputModules have only a
name to identify the Information, but I need also a way to specify
the a source, like
int height = {JPGDimension:height:context://bla.jpg}
These modules are perhaps suboptimal to use them into the sitemap.
I'm more interested in a transformer
<input module="JPGDimension" name="height" source="context://bla.jpg"/>
->
<height>568</height>
Another example is to get a result of a XPath expression of a
source.
So what do think, It is posiible to merge the two concepts, or
should I create a new form of an InputModule.
My 2 cents, Stephan.
_______________________________________________________________________
Stephan Michels EMail: stephan@apache.org
ICQ: 115535699 Tel: +49-030-314-21583
----+----|----+----|----+----|----+----|----+----|----+----|----+----|-|
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: InputModules and SourceInspectors
Posted by Stephan Michels <st...@apache.org>.
On Fri, 11 Oct 2002, Carsten Ziegeler wrote:
>
> Stephan Michels wrote:
> >
> > On Fri, 11 Oct 2002, Carsten Ziegeler wrote:
> >
> > > Stephan Michels wrote:
> > > >
> > > > On my intentions to integrate Slide into Cocoon I developed
> > > > the InspectableSource and SourceInspector IFs. And now I'm
> > > > thinking about merging the two concepts, InputModules and
> > > > SourceInspectors.
> > > >
> > > > The SourceInspectors are used to get information about
> > > > a Source, e.g. the height of an image. It should be an replacement
> > > > for the ImageDirectoryGenerator, and MP3DirectoryGenerator etc.
> > > >
> > > > The InspectableSource should create the posibility to store
> > > > properties with the a source, like title, owner etc. It
> > > > should work similar to the WebDAV propfind and proppatch method.
> > > >
> > > Ehm, why do you need an extra marker interface for this? The
> > > Source interface has already these methods:
> > > String getParameter( String name );
> > > long getParameterAsLong( String name );
> > > Iterator getParameterNames();
> >
> > Two points:
> >
> > 1. There is no way to set a property.
> We could extend WriteableSource with a setParameter() method.
>
> > 2. There is also a need for a namespace of properties.
> > namespace="DAV:" name="getcontentlength"
> > namespace="http://jakarta.apache.org/slide/" name="password"
> > etc.
> >
> You can use namespaces with getParameter() as well, like
> "DAV:getcontentlength" or "http://jakarta.apache.org/slide/password"
> or any other syntax.
Hmmm, could work, then I would prefer the first one.
The following proposal
Source:
Object getProperty(String name);
WriteableSource:
void setProperty(String name, Object value);
The value could be XMLizable ;-)
> > > So, you ask a source for any information, e.g. the height or
> > > anything else and if the source supports this information,
> > > you will get it.
> >
> > There is a difference between InspectableSource and
> > SourceInspector. The SourceInspector allows to apply an action
> > to an source, independent of the implementation of the Source
> > object, like retriving information of the inputstream.
> >
> Ok, so this is a general component, right? Shouldn't that go into
> Excalibur then?
It's like the InputModules, with only difference that you
need to specify a Source URI.
Another example is the evaluation of a XPath Expression.
String title = module.getValue("context://myfile.xml",
"/document/title");
And I don't know if it's general enough for excalibur.
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 SourceInspectors
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephan Michels wrote:
>
> On Fri, 11 Oct 2002, Carsten Ziegeler wrote:
>
> > Stephan Michels wrote:
> > >
> > > On my intentions to integrate Slide into Cocoon I developed
> > > the InspectableSource and SourceInspector IFs. And now I'm
> > > thinking about merging the two concepts, InputModules and
> > > SourceInspectors.
> > >
> > > The SourceInspectors are used to get information about
> > > a Source, e.g. the height of an image. It should be an replacement
> > > for the ImageDirectoryGenerator, and MP3DirectoryGenerator etc.
> > >
> > > The InspectableSource should create the posibility to store
> > > properties with the a source, like title, owner etc. It
> > > should work similar to the WebDAV propfind and proppatch method.
> > >
> > Ehm, why do you need an extra marker interface for this? The
> > Source interface has already these methods:
> > String getParameter( String name );
> > long getParameterAsLong( String name );
> > Iterator getParameterNames();
>
> Two points:
>
> 1. There is no way to set a property.
We could extend WriteableSource with a setParameter() method.
> 2. There is also a need for a namespace of properties.
> namespace="DAV:" name="getcontentlength"
> namespace="http://jakarta.apache.org/slide/" name="password"
> etc.
>
You can use namespaces with getParameter() as well, like
"DAV:getcontentlength" or "http://jakarta.apache.org/slide/password"
or any other syntax.
> > So, you ask a source for any information, e.g. the height or
> > anything else and if the source supports this information,
> > you will get it.
>
> There is a difference between InspectableSource and
> SourceInspector. The SourceInspector allows to apply an action
> to an source, independent of the implementation of the Source
> object, like retriving information of the inputstream.
>
Ok, so this is a general component, right? Shouldn't that go into
Excalibur then?
> > I think we should really avoid this flood of additional
> > source marker interfaces.
>
> I totally agree, that was the intention of my mail ;-)
>
Great, consensus reached ;)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: InputModules and SourceInspectors
Posted by Stephan Michels <st...@apache.org>.
On Fri, 11 Oct 2002, Carsten Ziegeler wrote:
> Stephan Michels wrote:
> >
> > On my intentions to integrate Slide into Cocoon I developed
> > the InspectableSource and SourceInspector IFs. And now I'm
> > thinking about merging the two concepts, InputModules and
> > SourceInspectors.
> >
> > The SourceInspectors are used to get information about
> > a Source, e.g. the height of an image. It should be an replacement
> > for the ImageDirectoryGenerator, and MP3DirectoryGenerator etc.
> >
> > The InspectableSource should create the posibility to store
> > properties with the a source, like title, owner etc. It
> > should work similar to the WebDAV propfind and proppatch method.
> >
> Ehm, why do you need an extra marker interface for this? The
> Source interface has already these methods:
> String getParameter( String name );
> long getParameterAsLong( String name );
> Iterator getParameterNames();
Two points:
1. There is no way to set a property.
2. There is also a need for a namespace of properties.
namespace="DAV:" name="getcontentlength"
namespace="http://jakarta.apache.org/slide/" name="password"
etc.
> So, you ask a source for any information, e.g. the height or
> anything else and if the source supports this information,
> you will get it.
There is a difference between InspectableSource and
SourceInspector. The SourceInspector allows to apply an action
to an source, independent of the implementation of the Source
object, like retriving information of the inputstream.
> I think we should really avoid this flood of additional
> source marker interfaces.
I totally agree, that was the intention of my mail ;-)
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 SourceInspectors
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephan Michels wrote:
>
> On my intentions to integrate Slide into Cocoon I developed
> the InspectableSource and SourceInspector IFs. And now I'm
> thinking about merging the two concepts, InputModules and
> SourceInspectors.
>
> The SourceInspectors are used to get information about
> a Source, e.g. the height of an image. It should be an replacement
> for the ImageDirectoryGenerator, and MP3DirectoryGenerator etc.
>
> The InspectableSource should create the posibility to store
> properties with the a source, like title, owner etc. It
> should work similar to the WebDAV propfind and proppatch method.
>
Ehm, why do you need an extra marker interface for this? The
Source interface has already these methods:
String getParameter( String name );
long getParameterAsLong( String name );
Iterator getParameterNames();
So, you ask a source for any information, e.g. the height or
anything else and if the source supports this information,
you will get it.
I think we should really avoid this flood of additional
source marker interfaces.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org