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/06 15:08:01 UTC
Defining Source Interfaces
I think it's time to define the WriteableSource etc. interfaces
for the excalibur source package and move them out of Cocoon.
What do you think about this? This would move the responsibility
to excalibur :)
I added before christmas the possibility to retrieve children
of a source to the Source interface in excalibur and started
with the ModifiableSource interface (= WriteableSource).
What else do we need? I think we have a buch of extensions
to the Source interface.
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: Defining Source Interfaces
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> I think it's time to define the WriteableSource etc. interfaces
> for the excalibur source package and move them out of Cocoon.
>
> What do you think about this? This would move the responsibility
> to excalibur :)
Given the current state of Avalon, and more of excalibur, I would wait.
We are deciding what to do with excalibur, and probably it will be a
repository open to ann Apache maybe in Apache Commons.
IMHO we have more pressing things to do, like fix the dependency of
Cocoon to the deprecated classes, write unit tests, and make Gump build
Cocoon.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Steven Noels <st...@outerthought.org>.
Sylvain Wallez wrote:
> While working on sources recently (the CVSSource I'm about to publish)...
Hip Hip Hooray!
Wonderful, Sylvain.
</Steven>
--
Steven Noels http://outerthought.org/
Outerthought - Open Source, Java & XML Competence Support Center
Read my weblog at http://blogs.cocoondev.org/stevenn/
stevenn at outerthought.org stevenn at apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>Carsten Ziegeler wrote:
>>
>>>I think it's time to define the WriteableSource etc. interfaces
>>>for the excalibur source package and move them out of Cocoon.
>>>
>>>What do you think about this? This would move the responsibility
>>>to excalibur :)
>>>
>>I guess you're joking, but is this good or bad ? Who else beside Cocoon
>>is using the source package in Excalibur ?
>>
>Oh, believe me - a lot of projects and companies are using it! I get
>several support questions for that package every month from various
>places.
>So, to be true: no, it's not a joke.
>
>
Ok. Then that's good.
>>>I added before christmas the possibility to retrieve children
>>>of a source to the Source interface in excalibur and started
>>>with the ModifiableSource interface (= WriteableSource).
>>>
>>>What else do we need? I think we have a buch of extensions
>>>to the Source interface.
>>>
>>Well, look in the 2.1 scratchpad where there's a lot of yummy stuff :
>>TraversableSource, VersionableSource, LockableSource, etc.
>>
>>While working on sources recently (the CVSSource I'm about to publish),
>>I found the current definition of TraversableSource not intuitive, and
>>modified it so it's more like to java.io.File :
>>
>>public interface TraversableSource extends Source {
>>
>> /** Is the source a directory or a collection ? */
>> public boolean isSourceCollection() throws ProcessingException,
>>IOException;
>>
>> /** Returns the collection of child sources. */
>> public Collection getChildren() throws ProcessingException,
>>IOException;
>>
>> /** Returns the local name of this source */
>> public String getName() throws ProcessingException, IOException;
>>
>> /** Return the parent source. Returns null if the source hasn't a
>>parent. */
>> public Source getParentSource() throws ProcessingException,
>>IOException;
>>}
>>
>>Stephan, others, what about these changes ?
>>
>>Carsten, I also some remarks/questions about your changes in Excalibur :
>>- should parent/child traversal be defined on Source. IMO, a Source
>>should be kept very simple and basic as not all sources are traversable,
>>
>>
>Yes, that is true. But always doing an instanceof is not the best advice
>for doing OOP. So, I thought of adding the most common methods to the base
>interface and only use extending interfaces if required.
>
>
>
>>- why does getChildrenLocation return an Iterator (and not a Collection)
>>of URIs (and Sources) ?
>>
>>
>Hmm, why not Iterator? Why is Collection better?
>
>
Because a Collection is a concrete object (it holds the children)
whereas an Iterator is just a moving cursor that can be used only once
on that Collection.
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: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>Aren't we all a little bit mad to send dozen of mails for a bunch of
>>methods ;-P
>>
>And the real fun has just started: finding the correct name of something!
>Yuppie!
>
>BTW: How are our current blocks called now? (no, no, please don't take this
>as serious).
>
>
ROFL again !!!
Ahem... what about "plugin" for webapp blocks and "module" for source
blocks ??
;-P
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: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Aren't we all a little bit mad to send dozen of mails for a bunch of
> methods ;-P
>
And the real fun has just started: finding the correct name of something!
Yuppie!
BTW: How are our current blocks called now? (no, no, please don't take this
as serious).
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>
> Sylvain Wallez wrote:
>
>> Nicola Ken Barozzi wrote:
>>
>>>
>>> Carsten Ziegeler wrote:
>>>
>>>> Sylvain Wallez wrote:
>>>>
>>> [...]
>>>
>>>>> You're totally on track. If you need this action right now, I
>>>>> would suggest to mimic what's in the DirectoryGenerator, that
>>>>> makes the assumption that the Source is a file. You can then use
>>>>> all the facilities given by File.
>>>>>
>>>>
>>>> And we only argue, if this support should belong to the Source
>>>> interface
>>>> or too an optional extension interface where I always have to do an
>>>> instanceof to see if the source has childs or not.
>>>>
>>>> :)
>>>
>>>
>>> It's nice when discussions are about where to put something new,
>>> it's always goodness :-)
>>
>>
>> Welcome to the party, Nicola Ken !
>
>
> :-)
>
>>> MHO: It all depends on what a Source is.
>>>
>>> 1 - If a source is a plug to a URI-based source handler, it should
>>> have children.
>>
>>
>> ?? Have you seen children access methods on java.net.URL ??
>
>
> Good point. Actually, it sorta closes the discussion for me :-)
>
>>> 2 - If it's a plug to a resource, it should not.
>>
>>
>> What is a "resource" ?
>
>
> stuff, bytes, bits, whatever ;-)
>
>>> Usually a source is (2), but since we bind the Source to a URI, (1)
>>> makes more sense. BTW, if (2) is true, specific Sources should
>>> probably not be the place anyway where to traverse a URI space, or
>>> else we are in case (1).
>>
>>
>> You lost me ;-)
>
>
> Yeah :-)
>
> Let me try to explain it, it could be fun trying to understand how my
> fried brain comes up with these sentences:
>
> Usually a source is [intended as something that gives me a resource,
> that is a data entity], but since we bind the Source to a URI, [that
> is we get Sources from URIs], [making it hierarchically navigable as a
> URI space] makes more sense.
IMO, this is wrong, for two reasons :
- an URI space may not be hierarchical. For example, the 'blob' protocol
isn't hierarchical.
- having a hierarchical URI space doesn't mean that you can navigate
through this hierarchy : you can only get an URI's parent on some URI ,
but you have no means to get the available children of an URI.
> BTW, if [being simply a handle to a resource] is true, specific
> [implelentations of] Sources should probably not be the place anyway
> where to traverse a URI space, or else we are in [the] case [where
> those Sources are resolvable with URIs, so they should have those
> methods].
Still didn't got all the essence of it, but what I can say is that
providing navigation methods makes sense only if the URI space defined
by a given SourceFactory is hierarchical *and* this hierarchy can be
traversed.
> If you still don't get it (yes, you should laugh at the complexity of
> the above) don't worry, *I'm* the mad one ;-)
Aren't we all a little bit mad to send dozen of mails for a bunch of
methods ;-P
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: Defining Source Interfaces
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Sylvain Wallez wrote:
> Nicola Ken Barozzi wrote:
>
>>
>> Carsten Ziegeler wrote:
>>
>>> Sylvain Wallez wrote:
>>>
>> [...]
>>
>>>> You're totally on track. If you need this action right now, I would
>>>> suggest to mimic what's in the DirectoryGenerator, that makes the
>>>> assumption that the Source is a file. You can then use all the
>>>> facilities given by File.
>>>>
>>>
>>> And we only argue, if this support should belong to the Source interface
>>> or too an optional extension interface where I always have to do an
>>> instanceof to see if the source has childs or not.
>>>
>>> :)
>>
>> It's nice when discussions are about where to put something new, it's
>> always goodness :-)
>
> Welcome to the party, Nicola Ken !
:-)
>> MHO: It all depends on what a Source is.
>>
>> 1 - If a source is a plug to a URI-based source handler, it should
>> have children.
>
> ?? Have you seen children access methods on java.net.URL ??
Good point. Actually, it sorta closes the discussion for me :-)
>> 2 - If it's a plug to a resource, it should not.
>
> What is a "resource" ?
stuff, bytes, bits, whatever ;-)
>> Usually a source is (2), but since we bind the Source to a URI, (1)
>> makes more sense. BTW, if (2) is true, specific Sources should
>> probably not be the place anyway where to traverse a URI space, or
>> else we are in case (1).
>
> You lost me ;-)
Yeah :-)
Let me try to explain it, it could be fun trying to understand how my
fried brain comes up with these sentences:
Usually a source is [intended as something that gives me a resource,
that is a data entity], but since we bind the Source to a URI, [that is
we get Sources from URIs], [making it hierarchically navigable as a URI
space] makes more sense. BTW, if [being simply a handle to a resource]
is true, specific [implelentations of] Sources should probably not be
the place anyway where to traverse a URI space, or else we are in [the]
case [where those Sources are resolvable with URIs, so they should have
those methods].
If you still don't get it (yes, you should laugh at the complexity of
the above) don't worry, *I'm* the mad one ;-)
>> Also, a source should IMNSHO do stream2xml conversion. It should pipe
>> directly XML *only* if the source is itself already in xml form, like
>> for example a precompiled SAX stream or a direct plugged in SAX stream
>> (for example in the future bean env).
>>
>> This makes the whole system more flexible, because we can easily
>> change Generators to make the stream2xml conversion phase pluggale. If
>> we make sources do all the conversion, we are back to Generators, and
>> I don't see the real benfit other than syntatic sugar...
>
> Even Carsten "source-master" got lost here ;-)))
hope my reply helps...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
>
>> Sylvain Wallez wrote:
>>
> [...]
>
>>> You're totally on track. If you need this action right now, I would
>>> suggest to mimic what's in the DirectoryGenerator, that makes the
>>> assumption that the Source is a file. You can then use all the
>>> facilities given by File.
>>>
>>
>> And we only argue, if this support should belong to the Source interface
>> or too an optional extension interface where I always have to do an
>> instanceof to see if the source has childs or not.
>>
>> :)
>
>
> It's nice when discussions are about where to put something new, it's
> always goodness :-)
Welcome to the party, Nicola Ken !
> MHO: It all depends on what a Source is.
>
> 1 - If a source is a plug to a URI-based source handler, it should
> have children.
?? Have you seen children access methods on java.net.URL ??
> 2 - If it's a plug to a resource, it should not.
What is a "resource" ?
> Usually a source is (2), but since we bind the Source to a URI, (1)
> makes more sense. BTW, if (2) is true, specific Sources should
> probably not be the place anyway where to traverse a URI space, or
> else we are in case (1).
You lost me ;-)
> Also, a source should IMNSHO do stream2xml conversion. It should pipe
> directly XML *only* if the source is itself already in xml form, like
> for example a precompiled SAX stream or a direct plugged in SAX stream
> (for example in the future bean env).
>
> This makes the whole system more flexible, because we can easily
> change Generators to make the stream2xml conversion phase pluggale. If
> we make sources do all the conversion, we are back to Generators, and
> I don't see the real benfit other than syntatic sugar...
Even Carsten "source-master" got lost here ;-)))
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: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> From: Nicola Ken Barozzi [mailto:nicolaken@apache.org]
> >>MHO: It all depends on what a Source is.
> >>
> >>1 - If a source is a plug to a URI-based source handler, it should have
> >>children.
> >>2 -If it's a plug to a resource, it should not.
> >>
> >>Usually a source is (2), but since we bind the Source to a URI, (1)
> >>makes more sense. BTW, if (2) is true, specific Sources should probably
> >>not be the place anyway where to traverse a URI space, or else we are in
> >>case (1).
> >
> > So you tend to {1}, right?
>
> Your're German, right? Always trying to make a clean cut? ;-)
>
Ehm...yes...
> >
> > Sorry, you totally lost me..(what is IMNSHO?)
>
> InMyNotSoHumbleOpinion
Ah!
>
> > A source by itself has nothing to do with XML or sax events. A source
> > can still implement the XMLizable interface for sax streaming. We have
> > the Cocoon SourceResolver which has a toSAX() method for a Source
> > object.
> > This method checks for the XMLizable interface. If the source implements
> > it, it's used. If not, the XMLizer component from excalibur is used
> > which does a mime-type to sax conversion and is therefore pluggable.
> >
> > Is it that what you meant?
>
> Errr, the context is that, yes. My point is that a *Generator* should do
> the stream to sax conversion, not the source. This maintains cleaner SOC.
>
Ok, we can now argue if it's the generator or some other component, but
I totally agree that it'S not the source itself. And actually as explained
above it's the case today.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Nicola Ken Barozzi wrote:
>
>>Carsten Ziegeler wrote:
>>
>>>Sylvain Wallez wrote:
>>>
>>
>>[...]
>>
>>>>You're totally on track. If you need this action right now, I would
>>>>suggest to mimic what's in the DirectoryGenerator, that makes the
>>>>assumption that the Source is a file. You can then use all the
>>>>facilities given by File.
>>>>
>>>
>>>And we only argue, if this support should belong to the Source interface
>>>or too an optional extension interface where I always have to do
>>>an instanceof to see if the source has childs or not.
>>>
>>>:)
>>
>>It's nice when discussions are about where to put something new, it's
>>always goodness :-)
>>
>
> Yupp!
>
>
>>MHO: It all depends on what a Source is.
>>
>>1 - If a source is a plug to a URI-based source handler, it should have
>>children.
>>2 -If it's a plug to a resource, it should not.
>>
>>Usually a source is (2), but since we bind the Source to a URI, (1)
>>makes more sense. BTW, if (2) is true, specific Sources should probably
>>not be the place anyway where to traverse a URI space, or else we are in
>>case (1).
>
> So you tend to {1}, right?
Your're German, right? Always trying to make a clean cut? ;-)
Define what a Source is and you will have the answer... if the source
interface has anything to do with a URI, it's {1}, else {1} is not it's
concern, but a concern of who gave you the Source, hence it would be {2}.
>>Also, a source should IMNSHO do stream2xml conversion. It should pipe
>>directly XML *only* if the source is itself already in xml form, like
>>for example a precompiled SAX stream or a direct plugged in SAX stream
>>(for example in the future bean env).
>>
>>This makes the whole system more flexible, because we can easily change
>>Generators to make the stream2xml conversion phase pluggale. If we make
>>sources do all the conversion, we are back to Generators, and I don't
>>see the real benfit other than syntatic sugar...
>>
>
> Sorry, you totally lost me..(what is IMNSHO?)
InMyNotSoHumbleOpinion
> A source by itself has nothing to do with XML or sax events. A source
> can still implement the XMLizable interface for sax streaming. We have
> the Cocoon SourceResolver which has a toSAX() method for a Source
> object.
> This method checks for the XMLizable interface. If the source implements
> it, it's used. If not, the XMLizer component from excalibur is used
> which does a mime-type to sax conversion and is therefore pluggable.
>
> Is it that what you meant?
Errr, the context is that, yes. My point is that a *Generator* should do
the stream to sax conversion, not the source. This maintains cleaner SOC.
If a Source *is* XML, then implementing XMLizable makes sense (XMLDB).
If it's not, it doesn't, because a Generator should do it.
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Nicola Ken Barozzi wrote:
>
> Carsten Ziegeler wrote:
> > Sylvain Wallez wrote:
> >
> [...]
> >>You're totally on track. If you need this action right now, I would
> >>suggest to mimic what's in the DirectoryGenerator, that makes the
> >>assumption that the Source is a file. You can then use all the
> >>facilities given by File.
> >>
> >
> > And we only argue, if this support should belong to the Source interface
> > or too an optional extension interface where I always have to do
> > an instanceof to see if the source has childs or not.
> >
> > :)
>
> It's nice when discussions are about where to put something new, it's
> always goodness :-)
>
Yupp!
> MHO: It all depends on what a Source is.
>
> 1 - If a source is a plug to a URI-based source handler, it should have
> children.
> 2 -If it's a plug to a resource, it should not.
>
> Usually a source is (2), but since we bind the Source to a URI, (1)
> makes more sense. BTW, if (2) is true, specific Sources should probably
> not be the place anyway where to traverse a URI space, or else we are in
> case (1).
>
So you tend to {1}, right?
> Also, a source should IMNSHO do stream2xml conversion. It should pipe
> directly XML *only* if the source is itself already in xml form, like
> for example a precompiled SAX stream or a direct plugged in SAX stream
> (for example in the future bean env).
>
> This makes the whole system more flexible, because we can easily change
> Generators to make the stream2xml conversion phase pluggale. If we make
> sources do all the conversion, we are back to Generators, and I don't
> see the real benfit other than syntatic sugar...
>
Sorry, you totally lost me..(what is IMNSHO?)
A source by itself has nothing to do with XML or sax events. A source
can still implement the XMLizable interface for sax streaming. We have
the Cocoon SourceResolver which has a toSAX() method for a Source
object.
This method checks for the XMLizable interface. If the source implements
it, it's used. If not, the XMLizer component from excalibur is used
which does a mime-type to sax conversion and is therefore pluggable.
Is it that what you meant?
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: Defining Source Interfaces
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
[...]
>>You're totally on track. If you need this action right now, I would
>>suggest to mimic what's in the DirectoryGenerator, that makes the
>>assumption that the Source is a file. You can then use all the
>>facilities given by File.
>>
>
> And we only argue, if this support should belong to the Source interface
> or too an optional extension interface where I always have to do
> an instanceof to see if the source has childs or not.
>
> :)
It's nice when discussions are about where to put something new, it's
always goodness :-)
MHO: It all depends on what a Source is.
1 - If a source is a plug to a URI-based source handler, it should have
children.
2 -If it's a plug to a resource, it should not.
Usually a source is (2), but since we bind the Source to a URI, (1)
makes more sense. BTW, if (2) is true, specific Sources should probably
not be the place anyway where to traverse a URI space, or else we are in
case (1).
Also, a source should IMNSHO do stream2xml conversion. It should pipe
directly XML *only* if the source is itself already in xml form, like
for example a precompiled SAX stream or a direct plugged in SAX stream
(for example in the future bean env).
This makes the whole system more flexible, because we can easily change
Generators to make the stream2xml conversion phase pluggale. If we make
sources do all the conversion, we are back to Generators, and I don't
see the real benfit other than syntatic sugar...
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Nicola Ken Barozzi wrote:
>
> <snip/>
>
> > I really don't understand much of the heat in this discussion because
> > I'm not so into it, but I'm happy you guys are and are making
> progress :-)
>
>
> Thanks. Actually, the discussions is about many points, one after the
> other ;-)
>
> > I just wanted to ask for a second (please excluse my ignorance), if
> > this means that a Generator can query a source if a certain "file" in
> > the same dir exists.
> >
> > The reason (Forrest need): on the filesystem I have
> >
> > mydir/myfile.pdf
> > mydir/thefile.xml
> > mydir/mydile.xml
> >
> > If I get a request for "mydir/myfile", I would like to get a Source
> > for ""mydir/" and ask what "files" it contains that have "myfile" as a
> > name.
>
>
> Thats it. We're discussing about the definition of a Source that can
> give you its parent ("mydir/") and its children.
>
> > Basically it could make us do a more generic version of ResourceExists.
> >
> > Do I understand what can be done or am I on track? Sorry if I cannot
> > dwelve further myself into it now, and thanks for the answers :-)
>
>
> You're totally on track. If you need this action right now, I would
> suggest to mimic what's in the DirectoryGenerator, that makes the
> assumption that the Source is a file. You can then use all the
> facilities given by File.
>
And we only argue, if this support should belong to the Source interface
or too an optional extension interface where I always have to do
an instanceof to see if the source has childs or not.
:)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Nicola Ken Barozzi wrote:
<snip/>
> I really don't understand much of the heat in this discussion because
> I'm not so into it, but I'm happy you guys are and are making progress :-)
Thanks. Actually, the discussions is about many points, one after the
other ;-)
> I just wanted to ask for a second (please excluse my ignorance), if
> this means that a Generator can query a source if a certain "file" in
> the same dir exists.
>
> The reason (Forrest need): on the filesystem I have
>
> mydir/myfile.pdf
> mydir/thefile.xml
> mydir/mydile.xml
>
> If I get a request for "mydir/myfile", I would like to get a Source
> for ""mydir/" and ask what "files" it contains that have "myfile" as a
> name.
Thats it. We're discussing about the definition of a Source that can
give you its parent ("mydir/") and its children.
> Basically it could make us do a more generic version of ResourceExists.
>
> Do I understand what can be done or am I on track? Sorry if I cannot
> dwelve further myself into it now, and thanks for the answers :-)
You're totally on track. If you need this action right now, I would
suggest to mimic what's in the DirectoryGenerator, that makes the
assumption that the Source is a file. You can then use all the
facilities given by File.
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: Defining Source Interfaces
Posted by Nicola Ken Barozzi <ni...@apache.org>.
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>>Carsten Ziegeler wrote:
>>
>>>Ah, btw you're right that the Source object should return a Collection
>>>instead of an Iterator for the children - I will fix that, too, asap.
>>
>>Cool. But I'm still not that happy with these methods being on Source
>>itself. What about TraversableSource or HierarchicalSource (I have this
>>last one ready on my PC with collections) ?
>
> I really don't like all these instanceof tests and I think that a source
> can have children is very common. So if you deal with sources you always
> end up with a test if this source contains children or not.
> I think this test is much more cleaner/nicer/whatever if I can directly
> query the source. An instanceof test for this reason is not appropriate.
I really don't understand much of the heat in this discussion because
I'm not so into it, but I'm happy you guys are and are making progress :-)
I just wanted to ask for a second (please excluse my ignorance), if this
means that a Generator can query a source if a certain "file" in the
same dir exists.
The reason (Forrest need): on the filesystem I have
mydir/myfile.pdf
mydir/thefile.xml
mydir/mydile.xml
If I get a request for "mydir/myfile", I would like to get a Source for
""mydir/" and ask what "files" it contains that have "myfile" as a name.
Basically it could make us do a more generic version of ResourceExists.
Do I understand what can be done or am I on track? Sorry if I cannot
dwelve further myself into it now, and thanks for the answers :-)
--
Nicola Ken Barozzi nicolaken@apache.org
- verba volant, scripta manent -
(discussions get forgotten, just code remains)
---------------------------------------------------------------------
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Jens Lorenz <je...@interface-projects.de>.
Carsten Ziegeler wrote:
>>>Now, think if an implementation for copy(). Each Source implementation
>>>must test if the destination is the same source implementation or not.
>>>If not use IS/OS if yes use optimized etc.
>>
>>agreed.
>>
>>>So, if we are using these "marker" interfaces for all other parts, I
>>>really think we should add a "MoveableSource" (substitute the
>>
>>name if you
>>
>>>like)
>>
>>I thought these operations are a kind of writing operations.
>>
>>
>>>and have an utility class check if:
>>>a) both sources have the same implementation and
>>>b) implement MoveableSource
>>>If both is answered with yes, this can be used - if not the
>>
>>utility class
>>
>>>uses IS/OS copying.
>>
>>I like code sippets ;-)
>
>
> sippets? :) (ok, just kidding)
>
>
>>class MySource implements MoveableSource
>>{
>> void copy(Source source)
>> {
>> // impementation depending copy
>> }
>>}
>>
>>class SourceCopyUtil<whatever>
>>{
>> void copy(Source from, Source to)
>> {
>> If ((from instanceof MoveableSource) &&
>> (from.getClass().equals(to.getClass()))
>> // impementation depending copy
>> ((MoveableSource)from).copy(to);
>> else
>> IS/OS copy
>> }
>>}
>>
>>Something like that?
>>
>
> Exactly.
>
> Would you suggest to have two interfaces, one for copying
> and one for moving?
> Or is it ok, to implement a move as a copy/delete?
IMHO, no. Think of a 600MB file on your hardrive. When moving this file
from one folder to another it's much less expensive to play with the
I-Nodes, than actually copying 600MB of data and then deleting 600 MB of
data.
You should give the Source implementation a hook to do such
optimizations with a fallback of a default implementation.
Within a WebDAV repository, like Slide, you also loose all your
metadata, when not using the methods of the store for copying and moving
resources.
> Carsten
Jens
--
Jens Lorenz
interface:projects GmbH \\|//
Tolkewitzer Strasse 49 (o o)
01277 Dresden ~~~~oOOo~(_)~oOOo~~~~
Germany
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Stephan Michels <st...@apache.org>.
On Thu, 9 Jan 2003, Carsten Ziegeler wrote:
>
> Stephan Michels wrote:
> > Carsten Ziegeler wrote:
> > >
> > > Now, think if an implementation for copy(). Each Source implementation
> > > must test if the destination is the same source implementation or not.
> > > If not use IS/OS if yes use optimized etc.
> >
> > agreed.
> >
> > > So, if we are using these "marker" interfaces for all other parts, I
> > > really think we should add a "MoveableSource" (substitute the
> > name if you
> > > like)
> >
> > I thought these operations are a kind of writing operations.
> >
> > > and have an utility class check if:
> > > a) both sources have the same implementation and
> > > b) implement MoveableSource
> > > If both is answered with yes, this can be used - if not the
> > utility class
> > > uses IS/OS copying.
> >
> > I like code sippets ;-)
>
> sippets? :) (ok, just kidding)
okay okay 'snippet' ;-)
> >
> > class MySource implements MoveableSource
> > {
> > void copy(Source source)
> > {
> > // impementation depending copy
> > }
> > }
> >
> > class SourceCopyUtil<whatever>
> > {
> > void copy(Source from, Source to)
> > {
> > If ((from instanceof MoveableSource) &&
> > (from.getClass().equals(to.getClass()))
> > // impementation depending copy
> > ((MoveableSource)from).copy(to);
> > else
> > IS/OS copy
> > }
> > }
> >
> > Something like that?
> >
> Exactly.
>
> Would you suggest to have two interfaces, one for copying
> and one for moving?
No, I think if we have a source, which we can copy, we
will always have a source, which we can also move.
So can we use org/apache/cocoon/components/source/SourceUtil
for the external copy? I think so.
> Or is it ok, to implement a move as a copy/delete?
Not really.
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Stephan Michels wrote:
> Carsten Ziegeler wrote:
> >
> > Now, think if an implementation for copy(). Each Source implementation
> > must test if the destination is the same source implementation or not.
> > If not use IS/OS if yes use optimized etc.
>
> agreed.
>
> > So, if we are using these "marker" interfaces for all other parts, I
> > really think we should add a "MoveableSource" (substitute the
> name if you
> > like)
>
> I thought these operations are a kind of writing operations.
>
> > and have an utility class check if:
> > a) both sources have the same implementation and
> > b) implement MoveableSource
> > If both is answered with yes, this can be used - if not the
> utility class
> > uses IS/OS copying.
>
> I like code sippets ;-)
sippets? :) (ok, just kidding)
>
> class MySource implements MoveableSource
> {
> void copy(Source source)
> {
> // impementation depending copy
> }
> }
>
> class SourceCopyUtil<whatever>
> {
> void copy(Source from, Source to)
> {
> If ((from instanceof MoveableSource) &&
> (from.getClass().equals(to.getClass()))
> // impementation depending copy
> ((MoveableSource)from).copy(to);
> else
> IS/OS copy
> }
> }
>
> Something like that?
>
Exactly.
Would you suggest to have two interfaces, one for copying
and one for moving?
Or is it ok, to implement a move as a copy/delete?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Stephan Michels <st...@apache.org>.
On Wed, 8 Jan 2003, Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
> > >
> > >The problem is, if you are using getInputStream/getOutputSteam to copy
> > >a file in a slide repository, that all metadata informations get lost. On
> > >the other hand, if you are using an external SourceUtil to copy a file,
> > >you can't hide all implementation details.
> > >
> > >
> >
> > Ah, I got it now : if the copied/moved source is of the same type than
> > the "source" source, then some optimisations are possible (like the
> > above or direct filesystem copy), else we fallback to a generic
> > getInputStream/getOutputStream implementation, right ?
> >
> > So it makes sense after all to keep them on the
> > [Modifiable/Writeable/Whatever]Source
> >
> No, I don't think so (sorry, I have to do this :) )
>
> Now, think if an implementation for copy(). Each Source implementation
> must test if the destination is the same source implementation or not.
> If not use IS/OS if yes use optimized etc.
agreed.
> So, if we are using these "marker" interfaces for all other parts, I
> really think we should add a "MoveableSource" (substitute the name if you
> like)
I thought these operations are a kind of writing operations.
> and have an utility class check if:
> a) both sources have the same implementation and
> b) implement MoveableSource
> If both is answered with yes, this can be used - if not the utility class
> uses IS/OS copying.
I like code sippets ;-)
class MySource implements MoveableSource
{
void copy(Source source)
{
// impementation depending copy
}
}
class SourceCopyUtil<whatever>
{
void copy(Source from, Source to)
{
If ((from instanceof MoveableSource) &&
(from.getClass().equals(to.getClass()))
// impementation depending copy
((MoveableSource)from).copy(to);
else
IS/OS copy
}
}
Something like that?
> It's the magic of SoC - if a source is not interested in move/copy it should
> not have to care about it.
Sometimes SoC is a pain, but I think the better way :-/
I also think that XMLizable isn't SoC, you should have to write
a (name)Serializer, which use \1.
Stephan
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
> >
> >The problem is, if you are using getInputStream/getOutputSteam to copy
> >a file in a slide repository, that all metadata informations get lost. On
> >the other hand, if you are using an external SourceUtil to copy a file,
> >you can't hide all implementation details.
> >
> >
>
> Ah, I got it now : if the copied/moved source is of the same type than
> the "source" source, then some optimisations are possible (like the
> above or direct filesystem copy), else we fallback to a generic
> getInputStream/getOutputStream implementation, right ?
>
> So it makes sense after all to keep them on the
> [Modifiable/Writeable/Whatever]Source
>
No, I don't think so (sorry, I have to do this :) )
Now, think if an implementation for copy(). Each Source implementation
must test if the destination is the same source implementation or not.
If not use IS/OS if yes use optimized etc.
So, if we are using these "marker" interfaces for all other parts, I
really think we should add a "MoveableSource" (substitute the name if you
like) and have an utility class check if:
a) both sources have the same implementation and
b) implement MoveableSource
If both is answered with yes, this can be used - if not the utility class
uses IS/OS copying.
It's the magic of SoC - if a source is not interested in move/copy it should
not have to care about it.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stephan Michels wrote:
>>>About the move() and copy() methods, I don't know if they should be kept
>>>in the new incarnation of this interface.
>>>
>>I don't think that they are important. A copy is a read/write action and
>>a move a read/write/delete action. We could make an utility class providing
>>support for it (and this would allow an inter source moving. wow!).
>>
>>
>
>The problem is, if you are using getInputStream/getOutputSteam to copy
>a file in a slide repository, that all metadata informations get lost. On
>the other hand, if you are using an external SourceUtil to copy a file,
>you can't hide all implementation details.
>
>
Ah, I got it now : if the copied/moved source is of the same type than
the "source" source, then some optimisations are possible (like the
above or direct filesystem copy), else we fallback to a generic
getInputStream/getOutputStream implementation, right ?
So it makes sense after all to keep them on the
[Modifiable/Writeable/Whatever]Source
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: Defining Source Interfaces
Posted by Stephan Michels <st...@apache.org>.
> > About the move() and copy() methods, I don't know if they should be kept
> > in the new incarnation of this interface.
> >
> I don't think that they are important. A copy is a read/write action and
> a move a read/write/delete action. We could make an utility class providing
> support for it (and this would allow an inter source moving. wow!).
The problem is, if you are using getInputStream/getOutputSteam to copy
a file in a slide repository, that all metadata informations get lost. On
the other hand, if you are using an external SourceUtil to copy a file,
you can't hide all implementation details.
Stephan.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
>
> Following Stephen's example, I grep'ed instanceof on the whole 2.1
> source base and found... 388 of them !
>
And how many of them are *not* because of Avalon?
> >Anyway, I think your arguments are better than mine (sniff).
> >
> >So, we have a TraversableSource or HierarchicalSource or ...?
> >
> >
>
> I'm not a native speaker, but the definition of traversable given by
> dictionary.com makes me prefer hierarchical...
>
Yupp.
> Ah, and what about adding an "exists()" method on Source (it's currently
> on WriteableSource) ? That one makes sense and is really useful, as the
> current way to know if an URI exists is to try to getInputStream(),
> which can be heavy.
+1
>
> >What do you think about the ModifiableSource in Excalibur? (That
> should be
> >the replacement for WriteableSource - please let *me* win this time ;) )
> >
> >
>
> Hey, you won on the SourceFactory.release() !
Ah, yes - I forgot that. :)
>
> But I don't want to count points or judge anyone/anything. I just want
> things to be nice, and, well, we sometimes have different feelings about
> what is nice ;-)
Absolutely, and (you know me) I only meant this as a joke. It's not
important
who is right, but it's important that we come to the "right" solution.
>
> I'm not sure about the "Modifiable" name. Maybe I'm biased because it
> was formerly (in 2.0) used to name something else ? Don't you like
> "WriteableSource", or "OutputSource" ? Don't know...
Ok, you're right with Modifiable and actually I didn't like WriteableSource
because you don't write directly to the source but to the OutputStream
provided by the Source.
>
> Whatever its name, it would be good for this interface to have the
> canCancel() and cancel() that are on WriteableSource. These allow data
> that has been written to a source to be discarded if something goes
> wrong. This is especially usefull in pipelines using the SWT for example.
Ah yes, these were the methods I wanted to ask about - ok, if they are
important we can add them.
>
> About the move() and copy() methods, I don't know if they should be kept
> in the new incarnation of this interface.
>
I don't think that they are important. A copy is a read/write action and
a move a read/write/delete action. We could make an utility class providing
support for it (and this would allow an inter source moving. wow!).
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Geoff Howard <co...@leverageweb.com>.
> Stephan Michels wrote:
>
> >On Wed, 8 Jan 2003, Sylvain Wallez wrote:
> >
> >>>Anyway, I think your arguments are better than mine (sniff).
> >>>
> >>>So, we have a TraversableSource or HierarchicalSource or ...?
> >>>
> >>I'm not a native speaker, but the definition of traversable given by
> >>dictionary.com makes me prefer hierarchical...
> >
> >You could traverse the hierarchy ;-)
>
> You're right. Given the answer I gave to Nicola Ken that this interface
> makes sense only if the URI space is hierarchical _and_ traversable,
> this could be a good name after all.
>
> Any opinion of a native or better speaker out there ?
>
Well, at least I can help you there - I speak English pretty good! ;)
Whatever traversable means in common speech, its meaning in this context
would be
most intuitively drawn from DOM traversal, which IIUC is a parallel concept
to what
you are discussing. It implies the ability to _learn_ about parents,
children and
siblings and to _reach_ them.
Hierarchical seems only to imply that a hierarchy exists - not that it can
be used
for accessing related items.
Therefore, it seems to me that some resources are hierarchical but not
necessarily traversable (in a source resolving context). For instance, take
http://xml.apache.org/cocoon/userdocs/generators/generators.html You could
say its "parent" is http://xml.apache.org/cocoon/userdocs/index.html, since
that is the
containing page, or maybe it's
http://xml.apache.org/cocoon/userdocs/generators/ (BTW, should indexing be
allowed on apache.org sites like that?). In that sort of context,
The resources are arranged hierarchically, but how would the Source return
that knowledge?
So, if you're open to a shot from the "peanut gallery" my opinion would be
that Traversable communicates the additional possibilities of some types of
sources (file systems, for example).
HTH,
Geoff Howard
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Jens Lorenz <je...@interface-projects.de>.
Stephan Michels wrote:
>
>>>>About the move() and copy() methods, I don't know if they should be kept
>>>>in the new incarnation of this interface.
>>>
>>>:-/ not another MoveableSource ;-)
>>
>>ROFL !!!
>
> ;-)
>
>>Seriously, are these methods of real use ?
>
> I thought that these methods could be a good start for a cms
> webportal. Not?
I agree with you, Stephan. This is an excellent start for a CMS.
CMS-wise you can't think of Sources as files. It's a file with metadata
which you need in order for your CMS to work. If you treat them just as
files you will loose those metadata and your CMS will start choking at
the next user interaction.
Jens
--
Jens Lorenz
interface:projects GmbH \\|//
Tolkewitzer Strasse 49 (o o)
01277 Dresden ~~~~oOOo~(_)~oOOo~~~~
Germany
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Stephan Michels <st...@apache.org>.
> >>About the move() and copy() methods, I don't know if they should be kept
> >>in the new incarnation of this interface.
> >
> >:-/ not another MoveableSource ;-)
>
> ROFL !!!
;-)
> Seriously, are these methods of real use ?
I thought that these methods could be a good start for a cms
webportal. Not?
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stephan Michels wrote:
>On Wed, 8 Jan 2003, Sylvain Wallez wrote:
>
>>>Anyway, I think your arguments are better than mine (sniff).
>>>
>>>So, we have a TraversableSource or HierarchicalSource or ...?
>>>
>>>
>>I'm not a native speaker, but the definition of traversable given by
>>dictionary.com makes me prefer hierarchical...
>>
>>
>
>You could traverse the hierarchy ;-)
>
>
You're right. Given the answer I gave to Nicola Ken that this interface
makes sense only if the URI space is hierarchical _and_ traversable,
this could be a good name after all.
Any opinion of a native or better speaker out there ?
>>About the move() and copy() methods, I don't know if they should be kept
>>in the new incarnation of this interface.
>>
>>
>
>:-/ not another MoveableSource ;-)
>
>
ROFL !!!
Seriously, are these methods of real use ?
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: Defining Source Interfaces
Posted by Stephan Michels <st...@apache.org>.
On Wed, 8 Jan 2003, Sylvain Wallez wrote:
> >Anyway, I think your arguments are better than mine (sniff).
> >
> >So, we have a TraversableSource or HierarchicalSource or ...?
>
> I'm not a native speaker, but the definition of traversable given by
> dictionary.com makes me prefer hierarchical...
You could traverse the hierarchy ;-)
> Ah, and what about adding an "exists()" method on Source (it's currently
> on WriteableSource) ? That one makes sense and is really useful, as the
> current way to know if an URI exists is to try to getInputStream(),
> which can be heavy.
+1
> About the move() and copy() methods, I don't know if they should be kept
> in the new incarnation of this interface.
:-/ not another MoveableSource ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Giacomo Pati <gi...@apache.org>.
On Wed, 8 Jan 2003, Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>
> >Sylvain Wallez wrote:
> >
> >
>
> <snip/>
>
> >>And as far as code cleanliness is concerned, an "instanceof" test seems
> >>more OOP to me than a isTraversable() method that tells us if is we have
> >>the right to use getParent() and getChildren(). With a separate
> >>interface, these methods do not exist if they do not make sense.
> >>
> >This is a point were a not really agree with. If I always have to do instanceof tests and class casts, something is wrong with OOP then in my eyes.
> >
>
> Following Stephen's example, I grep'ed instanceof on the whole 2.1
> source base and found... 388 of them !
Not that much for 2050 files or 436780 lines of code (including comments).
So Carsten is right saying the sentence above.
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
<snip/>
>>And as far as code cleanliness is concerned, an "instanceof" test seems
>>more OOP to me than a isTraversable() method that tells us if is we have
>>the right to use getParent() and getChildren(). With a separate
>>interface, these methods do not exist if they do not make sense.
>>
>This is a point were a not really agree with. If I always have to do instanceof tests and class casts, something is wrong with OOP then in my eyes.
>
Following Stephen's example, I grep'ed instanceof on the whole 2.1
source base and found... 388 of them !
>Anyway, I think your arguments are better than mine (sniff).
>
>So, we have a TraversableSource or HierarchicalSource or ...?
>
>
I'm not a native speaker, but the definition of traversable given by
dictionary.com makes me prefer hierarchical...
Ah, and what about adding an "exists()" method on Source (it's currently
on WriteableSource) ? That one makes sense and is really useful, as the
current way to know if an URI exists is to try to getInputStream(),
which can be heavy.
>What do you think about the ModifiableSource in Excalibur? (That should be
>the replacement for WriteableSource - please let *me* win this time ;) )
>
>
Hey, you won on the SourceFactory.release() !
But I don't want to count points or judge anyone/anything. I just want
things to be nice, and, well, we sometimes have different feelings about
what is nice ;-)
I'm not sure about the "Modifiable" name. Maybe I'm biased because it
was formerly (in 2.0) used to name something else ? Don't you like
"WriteableSource", or "OutputSource" ? Don't know...
Whatever its name, it would be good for this interface to have the
canCancel() and cancel() that are on WriteableSource. These allow data
that has been written to a source to be discarded if something goes
wrong. This is especially usefull in pipelines using the SWT for example.
About the move() and copy() methods, I don't know if they should be kept
in the new incarnation of this interface.
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: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Giacomo Pati wrote:
> > And here is the definitiv answer from the avalon team:
> >
> > "Remember that this is component-oriented programming (COP) and
> not OOP".
> >
> > :)
>
> C'mon. LifecycleHelper is the master batch of COP and not a "normal"
> class!
>
:) Yes, I know - but if you look at most instanceof tests, you will see
that they are related to Avalon and COP. That's my point - nothing more.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Giacomo Pati <gi...@apache.org>.
On Wed, 8 Jan 2003, Carsten Ziegeler wrote:
>
>
> > -----Original Message-----
> > From: Stephan Michels [mailto:stephan@apache.org]
> > Sent: Wednesday, January 08, 2003 3:47 PM
> > To: cocoon-dev@xml.apache.org
> > Subject: RE: Defining Source Interfaces
> >
> >
> >
> >
> > > > And as far as code cleanliness is concerned, an "instanceof"
> > test seems
> > > > more OOP to me than a isTraversable() method that tells us if
> > is we have
> > > > the right to use getParent() and getChildren(). With a separate
> > > > interface, these methods do not exist if they do not make sense.
> > > >
> > > This is a point were a not really agree with. If I always have to do
> > > instanceof tests and class casts, something is wrong with OOP then in my
> > > eyes.
> >
> > I'll hope not ... ;-)
> >
> > > fgrep -n "instanceof"
> > xml-cocoon2/src/java/org/apache/cocoon/components/LifecycleHelper.java
> > 212: if( component instanceof LogEnabled )
> > 240: if( null != context && component instanceof Contextualizable )
> > 245: if( null != componentManager && component instanceof
> > Composable )
> > 250: if( null != roles && component instanceof RoleManageable )
> > 255: if( null != logkit && component instanceof LogKitManageable )
> > 260: if( null != configuration && component instanceof Configurable
> > )
> > 265: if( null != configuration && component instanceof
> > Parameterizable )
> > 271: if( initializeAndStart && component instanceof Initializable )
> > 276: if( initializeAndStart && component instanceof Startable )
> > 291: if( component instanceof Startable )
> > 304: if ( component instanceof Disposable )
> >
> And here is the definitiv answer from the avalon team:
>
> "Remember that this is component-oriented programming (COP) and not OOP".
>
> :)
C'mon. LifecycleHelper is the master batch of COP and not a "normal"
class!
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> -----Original Message-----
> From: Stephan Michels [mailto:stephan@apache.org]
> Sent: Wednesday, January 08, 2003 3:47 PM
> To: cocoon-dev@xml.apache.org
> Subject: RE: Defining Source Interfaces
>
>
>
>
> > > And as far as code cleanliness is concerned, an "instanceof"
> test seems
> > > more OOP to me than a isTraversable() method that tells us if
> is we have
> > > the right to use getParent() and getChildren(). With a separate
> > > interface, these methods do not exist if they do not make sense.
> > >
> > This is a point were a not really agree with. If I always have to do
> > instanceof tests and class casts, something is wrong with OOP then in my
> > eyes.
>
> I'll hope not ... ;-)
>
> > fgrep -n "instanceof"
> xml-cocoon2/src/java/org/apache/cocoon/components/LifecycleHelper.java
> 212: if( component instanceof LogEnabled )
> 240: if( null != context && component instanceof Contextualizable )
> 245: if( null != componentManager && component instanceof
> Composable )
> 250: if( null != roles && component instanceof RoleManageable )
> 255: if( null != logkit && component instanceof LogKitManageable )
> 260: if( null != configuration && component instanceof Configurable
> )
> 265: if( null != configuration && component instanceof
> Parameterizable )
> 271: if( initializeAndStart && component instanceof Initializable )
> 276: if( initializeAndStart && component instanceof Startable )
> 291: if( component instanceof Startable )
> 304: if ( component instanceof Disposable )
>
And here is the definitiv answer from the avalon team:
"Remember that this is component-oriented programming (COP) and not OOP".
:)
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Stephan Michels <st...@apache.org>.
> > And as far as code cleanliness is concerned, an "instanceof" test seems
> > more OOP to me than a isTraversable() method that tells us if is we have
> > the right to use getParent() and getChildren(). With a separate
> > interface, these methods do not exist if they do not make sense.
> >
> This is a point were a not really agree with. If I always have to do
> instanceof tests and class casts, something is wrong with OOP then in my
> eyes.
I'll hope not ... ;-)
> fgrep -n "instanceof"
xml-cocoon2/src/java/org/apache/cocoon/components/LifecycleHelper.java
212: if( component instanceof LogEnabled )
240: if( null != context && component instanceof Contextualizable )
245: if( null != componentManager && component instanceof
Composable )
250: if( null != roles && component instanceof RoleManageable )
255: if( null != logkit && component instanceof LogKitManageable )
260: if( null != configuration && component instanceof Configurable
)
265: if( null != configuration && component instanceof
Parameterizable )
271: if( initializeAndStart && component instanceof Initializable )
276: if( initializeAndStart && component instanceof Startable )
291: if( component instanceof Startable )
304: if ( component instanceof Disposable )
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Giacomo Pati wrote:
>On Wed, 8 Jan 2003, Carsten Ziegeler wrote:
>
>>Sylvain Wallez wrote:
>>
>>What do you think about the ModifiableSource in Excalibur? (That should be
>>the replacement for WriteableSource - please let *me* win this time ;) )
>>
>>
>
>Sylvain is hard to beat somtimes, I can tell from experience ;)
>
>
Are you still angry against me, more than 18 months later ?
I must admit that whenever I have an opinion on a subject and believe
this opinion to be the right one, I find many arguments (always
technical, never personal) to finally convince people ;-)
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: Defining Source Interfaces
Posted by Giacomo Pati <gi...@apache.org>.
On Wed, 8 Jan 2003, Carsten Ziegeler wrote:
>
> Sylvain Wallez wrote:
>
> What do you think about the ModifiableSource in Excalibur? (That should be
> the replacement for WriteableSource - please let *me* win this time ;) )
Sylvain is hard to beat somtimes, I can tell from experience ;)
Giacomo
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Okay. Let me throw in more arguments ;-)
>
Great!
> How many protocols do we have for which parent and children make sense ?
> Actually 2 : 'file' and 'slide' (and 'cvs' soon). For other protocols
> such as 'cocoon', 'resource', 'blob', 'xmldb', 'http', etc, this has no
> meaning.
>
> How many components do we have that use a source's parent and children ?
> Actually one : DirectoryGenerator, or its TraversableSource counterpart.
>
> So should we add a lot of methods to Source for these few protocols and
> components ? I would say no.
>
Ok, seems reasonable.
> Furthermore, I consider that DirectoryGenerator should fail hard if we
> try to generate from a source that is not traversable (as it does today
> if it's not given a file). So we should be able to know not only if a
> Source has children or not, but if it actually supports this feature.
>
Yes. true. A isTraversable() would work.
> Finally, what about WriteableSource, VersionableSource, LockableSource,
> InspectableSource, etc ? Should we merge their methods to Source ? If
> not, then why a particular case for TraversableSource ?
>
Hmm, nice point. Yes, if it's true that a TraversableSource is only
used in 5% of the cases then it should be a separate interface.
The others you mention above are of course separate interface, so you're
right that it's only natural separate TraversableSource as well.
>
> And as far as code cleanliness is concerned, an "instanceof" test seems
> more OOP to me than a isTraversable() method that tells us if is we have
> the right to use getParent() and getChildren(). With a separate
> interface, these methods do not exist if they do not make sense.
>
This is a point were a not really agree with. If I always have to do
instanceof tests and class casts, something is wrong with OOP then in my
eyes.
Anyway, I think your arguments are better than mine (sniff).
So, we have a TraversableSource or HierarchicalSource or ...?
What do you think about the ModifiableSource in Excalibur? (That should be
the replacement for WriteableSource - please let *me* win this time ;) )
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>Carsten Ziegeler wrote:
>>
>>
>>Cool. But I'm still not that happy with these methods being on Source
>>itself. What about TraversableSource or HierarchicalSource (I have this
>>last one ready on my PC with collections) ?
>>
>>
>>
>I really don't like all these instanceof tests and I think that a source
>can have children is very common. So if you deal with sources you always
>end up with a test if this source contains children or not.
>I think this test is much more cleaner/nicer/whatever if I can directly
>query the source. An instanceof test for this reason is not appropriate.
>
>
Okay. Let me throw in more arguments ;-)
How many protocols do we have for which parent and children make sense ?
Actually 2 : 'file' and 'slide' (and 'cvs' soon). For other protocols
such as 'cocoon', 'resource', 'blob', 'xmldb', 'http', etc, this has no
meaning.
How many components do we have that use a source's parent and children ?
Actually one : DirectoryGenerator, or its TraversableSource counterpart.
So should we add a lot of methods to Source for these few protocols and
components ? I would say no.
Furthermore, I consider that DirectoryGenerator should fail hard if we
try to generate from a source that is not traversable (as it does today
if it's not given a file). So we should be able to know not only if a
Source has children or not, but if it actually supports this feature.
Finally, what about WriteableSource, VersionableSource, LockableSource,
InspectableSource, etc ? Should we merge their methods to Source ? If
not, then why a particular case for TraversableSource ?
And as far as code cleanliness is concerned, an "instanceof" test seems
more OOP to me than a isTraversable() method that tells us if is we have
the right to use getParent() and getChildren(). With a separate
interface, these methods do not exist if they do not make sense.
Your turn, now ;-)
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: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
> >Sylvain Wallez wrote:
> >
> >
> >>The performance problem is that among all implementations of
> Source that
> >>I know of (URLSource, FileSource, SlideSource, BlobSource, XMLDBSource,
> >>SitemapSource and CVSSource), only one actually needs to be disposed
> >>(SitemapSource).
> >>
> >>So having a isSelectable()-select()-release() cycle to call a
> >>factory.release() that does nothing most of the time seems CPU
> >>waste to me.
> >>
> >>Now I agree that theoretically releasing is the factory's job. So, in
> >>order to lower my performance fears, what about removing the
> >>isSelectable() call in SourceResolverImpl.release() ? It would
> remove an
> >>unnecessary search in the ServiceSelector HashMaps, considering also
> >>that the select() that follows this isSelectable() is surrounded by a
> >>try/catch.
> >>
> >>
> >>
> >Wow, entering twilight zone...believe it or not, I just thought of this
> >yesterday evening when I tried to think about some general performance
> >improvements.
> >Actually, I wasn't sure about it, because if we are honest, it's a hack.
> >
>
> Why is it a hack ? Calling isSelectable() is only of real use if the
> probability for it to return false is important and if you can make some
> corrective actions in that case.
>
Ok, hack is perhaps a too hard formulated. Anyway, I think we can live with
it
and change it.
> >And throwing/catching exceptions is also a little bit time consuming.
> >But as a (better?) solution I would like to make a factory for the
> >URLSource as well - so all sources are handled by a factory and the
> >select() call will always return a factory - and this will avoid
> >the isSelectable() call.
> >What do you think about this?
> >
>
> Twilight zone again ;-)
> I wanted to raise this issue just after we finished with that one,
> because it seemed to me unclean for URLSource to be managed directly by
> the SourceResolver and not through a factory.
>
> >Ah, btw you're right that the Source object should return a Collection
> >instead of an Iterator for the children - I will fix that, too, asap.
> >
>
> Cool. But I'm still not that happy with these methods being on Source
> itself. What about TraversableSource or HierarchicalSource (I have this
> last one ready on my PC with collections) ?
>
I really don't like all these instanceof tests and I think that a source
can have children is very common. So if you deal with sources you always
end up with a test if this source contains children or not.
I think this test is much more cleaner/nicer/whatever if I can directly
query the source. An instanceof test for this reason is not appropriate.
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>The performance problem is that among all implementations of Source that
>>I know of (URLSource, FileSource, SlideSource, BlobSource, XMLDBSource,
>>SitemapSource and CVSSource), only one actually needs to be disposed
>>(SitemapSource).
>>
>>So having a isSelectable()-select()-release() cycle to call a
>>factory.release() that does nothing most of the time seems CPU
>>waste to me.
>>
>>Now I agree that theoretically releasing is the factory's job. So, in
>>order to lower my performance fears, what about removing the
>>isSelectable() call in SourceResolverImpl.release() ? It would remove an
>>unnecessary search in the ServiceSelector HashMaps, considering also
>>that the select() that follows this isSelectable() is surrounded by a
>>try/catch.
>>
>>
>>
>Wow, entering twilight zone...believe it or not, I just thought of this
>yesterday evening when I tried to think about some general performance
>improvements.
>Actually, I wasn't sure about it, because if we are honest, it's a hack.
>
Why is it a hack ? Calling isSelectable() is only of real use if the
probability for it to return false is important and if you can make some
corrective actions in that case.
>And throwing/catching exceptions is also a little bit time consuming.
>But as a (better?) solution I would like to make a factory for the
>URLSource as well - so all sources are handled by a factory and the
>select() call will always return a factory - and this will avoid
>the isSelectable() call.
>What do you think about this?
>
Twilight zone again ;-)
I wanted to raise this issue just after we finished with that one,
because it seemed to me unclean for URLSource to be managed directly by
the SourceResolver and not through a factory.
>Ah, btw you're right that the Source object should return a Collection
>instead of an Iterator for the children - I will fix that, too, asap.
>
Cool. But I'm still not that happy with these methods being on Source
itself. What about TraversableSource or HierarchicalSource (I have this
last one ready on my PC with collections) ?
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: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> The performance problem is that among all implementations of Source that
> I know of (URLSource, FileSource, SlideSource, BlobSource, XMLDBSource,
> SitemapSource and CVSSource), only one actually needs to be disposed
> (SitemapSource).
>
> So having a isSelectable()-select()-release() cycle to call a
> factory.release() that does nothing most of the time seems CPU
> waste to me.
>
> Now I agree that theoretically releasing is the factory's job. So, in
> order to lower my performance fears, what about removing the
> isSelectable() call in SourceResolverImpl.release() ? It would remove an
> unnecessary search in the ServiceSelector HashMaps, considering also
> that the select() that follows this isSelectable() is surrounded by a
> try/catch.
>
Wow, entering twilight zone...believe it or not, I just thought of this
yesterday evening when I tried to think about some general performance
improvements.
Actually, I wasn't sure about it, because if we are honest, it's a hack.
And throwing/catching exceptions is also a little bit time consuming.
But as a (better?) solution I would like to make a factory for the
URLSource as well - so all sources are handled by a factory and the
select() call will always return a factory - and this will avoid
the isSelectable() call.
What do you think about this?
Ah, btw you're right that the Source object should return a Collection
instead of an Iterator for the children - I will fix that, too, asap.
Regards
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: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>Sylvain Wallez wrote:
>
>
>>However, I still consider the new implementation of
>>SourceResolverImpl.release() in Excalibur (dated 15 dec. and not
>>currently in Cocoon) to be a performance burden since in most cases all
>>component-related operations it performs *will be useless*.
>>
>>Carsten, what do you think ? Should we move this to avalon-dev or can
>>you wear you Avalon hat here ?
>>
>>
>>
>I'm glad that you wrote hat and not hate... (just a hint of a joke).
>
Wow, this kind of typo must absolutely be avoided ;-)
>The implementation currently used in Cocoon is wrong. The new version i
>Avalon is IMHO cleaner and correct, because a factory is responsible
>for creating a source, so it must be the responsibility of exactly this
>factory to pool/destroy/recylce the source as well. It cannot be
>the source resolver doing the job.
>
>Where do you see the performance problems?
>
The performance problem is that among all implementations of Source that
I know of (URLSource, FileSource, SlideSource, BlobSource, XMLDBSource,
SitemapSource and CVSSource), only one actually needs to be disposed
(SitemapSource).
So having a isSelectable()-select()-release() cycle to call a
factory.release() that does nothing most of the time seems CPU waste to me.
Now I agree that theoretically releasing is the factory's job. So, in
order to lower my performance fears, what about removing the
isSelectable() call in SourceResolverImpl.release() ? It would remove an
unnecessary search in the ServiceSelector HashMaps, considering also
that the select() that follows this isSelectable() is surrounded by a
try/catch.
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: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> However, I still consider the new implementation of
> SourceResolverImpl.release() in Excalibur (dated 15 dec. and not
> currently in Cocoon) to be a performance burden since in most cases all
> component-related operations it performs *will be useless*.
>
> Carsten, what do you think ? Should we move this to avalon-dev or can
> you wear you Avalon hat here ?
>
I'm glad that you wrote hat and not hate... (just a hint of a joke).
The implementation currently used in Cocoon is wrong. The new version i
Avalon is IMHO cleaner and correct, because a factory is responsible
for creating a source, so it must be the responsibility of exactly this
factory to pool/destroy/recylce the source as well. It cannot be
the source resolver doing the job.
Where do you see the performance problems?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Vadim Gritsenko wrote:
> Sylvain Wallez wrote:
>
> ...
>
>> Furthermore, I'm really wondering now if we need to release() a
>> Source, as I can't find any implementation that actually does
>> something of it.
>
>
> Do you mean recycle()? There is no release() in Source...
I was referring to SourceResolver.release() in 2.1 that is meant to
replace Source.recycle() that's present in 2.0
> If you've meant recycle(), look no further than into
> SitemapSource.java for implementation example. SitemapSource won't
> live without recycle() (unless you propose a way).
... ...(double-checking this complicated source file)... ...
Yep, you're right : this is a case where looked-up components must be
kept between calls of getLastModified() and toSax() to avoid multiple
constructions of the pipeline.
So, since at lease one implementation requires it, all Sources should be
released. Sorry for me wrongly making noise :-/
However, I still consider the new implementation of
SourceResolverImpl.release() in Excalibur (dated 15 dec. and not
currently in Cocoon) to be a performance burden since in most cases all
component-related operations it performs *will be useless*.
Carsten, what do you think ? Should we move this to avalon-dev or can
you wear you Avalon hat here ?
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: Defining Source Interfaces
Posted by Vadim Gritsenko <va...@verizon.net>.
Sylvain Wallez wrote:
...
> Furthermore, I'm really wondering now if we need to release() a
> Source, as I can't find any implementation that actually does
> something of it.
Do you mean recycle()? There is no release() in Source...
If you've meant recycle(), look no further than into SitemapSource.java
for implementation example. SitemapSource won't live without recycle()
(unless you propose a way).
Vadim
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Stephan Michels <st...@apache.org>.
On Mon, 6 Jan 2003, Sylvain Wallez wrote:
> Stephan Michels wrote:
>
> >On Mon, 6 Jan 2003, Sylvain Wallez wrote:
> >
> >>Stephan Michels wrote:
> >>
> >>
> >>>>> /** Return the parent source. Returns null if the source hasn't a
> >>>>>parent. */
> >>>>> public Source getParentSource() throws ProcessingException,
> >>>>>IOException;
> >>>>>}
> >>>>>
> >>>I don't return Sources, because Sources can be Components, which
> >>>must be resolved/released by the SourceResolver.
> >>>So I think returning the URI instead of the Sources is a must-have.
> >>>
> >>I disagree : the SourceResolver is used to get a Source from its URL,
> >>but a Source is not a component : the component is the SourceFactory
> >>that creates Source instances. A source itself is not managed by a
> >>ServiceManager.
> >>
> >>
> >
> >But can managed by the SourceResolver.
> >
>
> Can you elaborate ? I was meaning that a source has no defined
> lifecycle. Even the release that is managed by the factory and not the
> source itself.
>
> >>Also, having to hop through the SourceResolver to get parents or
> >>children of a Source *really hits performance*, as each call to
> >>resolve() looks up/releases the factory, asks it to create the source,
> >>etc, etc.
> >>
> >>
> >
> >But if the creation of the Sources is expensive, is is easier to create
> >a SourceResolver, which holds a pool of the sources.
> >
> >
>
> Can you elaborate again ? You can only manage a pool of equivalent
> objects that can be reused. Sources don't fall in this category, as a
> Source is intimately tied to its URI and the range of URIs is infinite.
URI can be infinite, be most of the computer does have an infinite
filesystem, especially cocoon webapps ;-)
> >>So, considering that the SourceResolver is one of the most used
> >>components, removing release() from this interface may lead to a
> >>significant performance increase.
> >>
> >>
> >
> >That can be, but a resolve/release has much cleaner lifecycle. For
> >example, if the Source lookup for a component using the componentmanager,
> >which got the Source by the Composable contract, the component must
> >release the component, if the Source were disposed.
> >
> >
>
> Sorry, I don't understand what you mean above :-/
class MySource implements Source,Composable,Disposable
{
private Component used;
public compose(ComponentManager cm)
{
used = cm.lookup("whatever");
}
public dispose()
{
cm.release(used);
}
}
Something like that ;-) Of cause, you can write
class MySource implements Source,Composable,Disposable
{
private ComponentManager cm;
public compose(ComponentManager cm)
{
this.cm = cm;
}
public using()
{
used = cm.lookup("whatever");
used.using();
cm.release(used);
}
}
But in the essence, there are examples, which need a lifecycle for a
source object. :-/
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stephan Michels wrote:
>On Mon, 6 Jan 2003, Sylvain Wallez wrote:
>
>>Stephan Michels wrote:
>>
>>
>>>>> /** Return the parent source. Returns null if the source hasn't a
>>>>>parent. */
>>>>> public Source getParentSource() throws ProcessingException,
>>>>>IOException;
>>>>>}
>>>>>
>>>I don't return Sources, because Sources can be Components, which
>>>must be resolved/released by the SourceResolver.
>>>So I think returning the URI instead of the Sources is a must-have.
>>>
>>I disagree : the SourceResolver is used to get a Source from its URL,
>>but a Source is not a component : the component is the SourceFactory
>>that creates Source instances. A source itself is not managed by a
>>ServiceManager.
>>
>>
>
>But can managed by the SourceResolver.
>
Can you elaborate ? I was meaning that a source has no defined
lifecycle. Even the release that is managed by the factory and not the
source itself.
>>Also, having to hop through the SourceResolver to get parents or
>>children of a Source *really hits performance*, as each call to
>>resolve() looks up/releases the factory, asks it to create the source,
>>etc, etc.
>>
>>
>
>But if the creation of the Sources is expensive, is is easier to create
>a SourceResolver, which holds a pool of the sources.
>
>
Can you elaborate again ? You can only manage a pool of equivalent
objects that can be reused. Sources don't fall in this category, as a
Source is intimately tied to its URI and the range of URIs is infinite.
Furthermore, managing a pool would not be very different
performance-wise than going through the standard resolution mechanism.
>>Looking at all traversable sources I know of (Slide source and my
>>yet-unpublished CVSSource and TraversableFileSource), getting the
>>children or parents Source objects is really trivial and lightweight
>>compared to the processing required if we go through the SourceResolver.
>>
>>Furthermore, I'm really wondering now if we need to release() a Source,
>>as I can't find any implementation that actually does something of it.
>>
>>And I don't think an implementation will ever use it : the point where
>>something has to be released in Sources is related to stream methods
>>(look at BlobSource.getInputStream()). Also, these methods can be called
>>several times during the lifetime of the Source object, and their result
>>can last longer than the Source object's lifetime (look at
>>XSLTProcessorImpl.resolve()).
>>
>>And releasing a Source involves once more a look up/release of the
>>SourceFactory to actually do nothing...
>>
>>So, considering that the SourceResolver is one of the most used
>>components, removing release() from this interface may lead to a
>>significant performance increase.
>>
>>
>
>That can be, but a resolve/release has much cleaner lifecycle. For
>example, if the Source lookup for a component using the componentmanager,
>which got the Source by the Composable contract, the component must
>release the component, if the Source were disposed.
>
>
Sorry, I don't understand what you mean above :-/
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: Defining Source Interfaces
Posted by Stephan Michels <st...@apache.org>.
On Mon, 6 Jan 2003, Sylvain Wallez wrote:
> Stephan Michels wrote:
>
> >On Mon, 6 Jan 2003, Carsten Ziegeler wrote:
> >
> >>>>I added before christmas the possibility to retrieve children
> >>>>of a source to the Source interface in excalibur and started
> >>>>with the ModifiableSource interface (= WriteableSource).
> >>>>
> >>>>What else do we need? I think we have a buch of extensions
> >>>>to the Source interface.
> >>>>
> >>>Well, look in the 2.1 scratchpad where there's a lot of yummy stuff :
> >>>TraversableSource, VersionableSource, LockableSource, etc.
> >>>
> >>>While working on sources recently (the CVSSource I'm about to publish),
> >>>I found the current definition of TraversableSource not intuitive, and
> >>>modified it so it's more like to java.io.File :
> >>>
> >>>public interface TraversableSource extends Source {
> >>>
> >>> /** Is the source a directory or a collection ? */
> >>> public boolean isSourceCollection() throws ProcessingException,
> >>>IOException;
> >>>
> >>> /** Returns the collection of child sources. */
> >>> public Collection getChildren() throws ProcessingException,
> >>>IOException;
> >>>
> >>> /** Returns the local name of this source */
> >>> public String getName() throws ProcessingException, IOException;
> >>>
> >>>
> >
> >getLocalId() ??? because of getSystemId()?
> Look at java.io.File : you have getPath() and getName(), not getLocalPath().
http://jakarta.apache.org/commons/sandbox/vfs/apidocs/org/apache/commons/vfs/FileObject.html
used also getName(). hmm.
> >>> /** Return the parent source. Returns null if the source hasn't a
> >>>parent. */
> >>> public Source getParentSource() throws ProcessingException,
> >>>IOException;
> >>>}
> >>>
> >>>
> >
> >I don't return Sources, because Sources can be Components, which
> >must be resolved/released by the SourceResolver.
> >So I think returning the URI instead of the Sources is a must-have.
> >
> >
>
> I disagree : the SourceResolver is used to get a Source from its URL,
> but a Source is not a component : the component is the SourceFactory
> that creates Source instances. A source itself is not managed by a
> ServiceManager.
But can managed by the SourceResolver.
> Also, having to hop through the SourceResolver to get parents or
> children of a Source *really hits performance*, as each call to
> resolve() looks up/releases the factory, asks it to create the source,
> etc, etc.
But if the creation of the Sources is expensive, is is easier to create
a SourceResolver, which holds a pool of the sources.
> Looking at all traversable sources I know of (Slide source and my
> yet-unpublished CVSSource and TraversableFileSource), getting the
> children or parents Source objects is really trivial and lightweight
> compared to the processing required if we go through the SourceResolver.
>
> Furthermore, I'm really wondering now if we need to release() a Source,
> as I can't find any implementation that actually does something of it.
>
> And I don't think an implementation will ever use it : the point where
> something has to be released in Sources is related to stream methods
> (look at BlobSource.getInputStream()). Also, these methods can be called
> several times during the lifetime of the Source object, and their result
> can last longer than the Source object's lifetime (look at
> XSLTProcessorImpl.resolve()).
>
> And releasing a Source involves once more a look up/release of the
> SourceFactory to actually do nothing...
>
> So, considering that the SourceResolver is one of the most used
> components, removing release() from this interface may lead to a
> significant performance increase.
That can be, but a resolve/release has much cleaner lifecycle. For
example, if the Source lookup for a component using the componentmanager,
which got the Source by the Composable contract, the component must
release the component, if the Source were disposed.
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Stephan Michels wrote:
>On Mon, 6 Jan 2003, Carsten Ziegeler wrote:
>
>>>>I added before christmas the possibility to retrieve children
>>>>of a source to the Source interface in excalibur and started
>>>>with the ModifiableSource interface (= WriteableSource).
>>>>
>>>>What else do we need? I think we have a buch of extensions
>>>>to the Source interface.
>>>>
>>>Well, look in the 2.1 scratchpad where there's a lot of yummy stuff :
>>>TraversableSource, VersionableSource, LockableSource, etc.
>>>
>>>While working on sources recently (the CVSSource I'm about to publish),
>>>I found the current definition of TraversableSource not intuitive, and
>>>modified it so it's more like to java.io.File :
>>>
>>>public interface TraversableSource extends Source {
>>>
>>> /** Is the source a directory or a collection ? */
>>> public boolean isSourceCollection() throws ProcessingException,
>>>IOException;
>>>
>>> /** Returns the collection of child sources. */
>>> public Collection getChildren() throws ProcessingException,
>>>IOException;
>>>
>>> /** Returns the local name of this source */
>>> public String getName() throws ProcessingException, IOException;
>>>
>>>
>
>getLocalId() ??? because of getSystemId()?
>
>
Look at java.io.File : you have getPath() and getName(), not getLocalPath().
>>> /** Return the parent source. Returns null if the source hasn't a
>>>parent. */
>>> public Source getParentSource() throws ProcessingException,
>>>IOException;
>>>}
>>>
>>>
>
>I don't return Sources, because Sources can be Components, which
>must be resolved/released by the SourceResolver.
>So I think returning the URI instead of the Sources is a must-have.
>
>
I disagree : the SourceResolver is used to get a Source from its URL,
but a Source is not a component : the component is the SourceFactory
that creates Source instances. A source itself is not managed by a
ServiceManager.
Also, having to hop through the SourceResolver to get parents or
children of a Source *really hits performance*, as each call to
resolve() looks up/releases the factory, asks it to create the source,
etc, etc.
Looking at all traversable sources I know of (Slide source and my
yet-unpublished CVSSource and TraversableFileSource), getting the
children or parents Source objects is really trivial and lightweight
compared to the processing required if we go through the SourceResolver.
Furthermore, I'm really wondering now if we need to release() a Source,
as I can't find any implementation that actually does something of it.
And I don't think an implementation will ever use it : the point where
something has to be released in Sources is related to stream methods
(look at BlobSource.getInputStream()). Also, these methods can be called
several times during the lifetime of the Source object, and their result
can last longer than the Source object's lifetime (look at
XSLTProcessorImpl.resolve()).
And releasing a Source involves once more a look up/release of the
SourceFactory to actually do nothing...
So, considering that the SourceResolver is one of the most used
components, removing release() from this interface may lead to a
significant performance increase.
>>>Carsten, I also some remarks/questions about your changes in Excalibur :
>>>- should parent/child traversal be defined on Source. IMO, a Source
>>>should be kept very simple and basic as not all sources are traversable,
>>>
>>>
>>Yes, that is true. But always doing an instanceof is not the best advice
>>for doing OOP. So, I thought of adding the most common methods to the base
>>interface and only use extending interfaces if required.
>>
>>
>
>I like Avalon because of the separation of the contracts. If you implement
>a component, you don't have to implement all lifecycle methods like
>EJBs. If you implement a source you only need to implement the IFs that
>you need.
>
>
Yep. The beauty of Avalon comes from it's "Zen-itude" : each interface
provides the minimal but sufficient set of methods.
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: Defining Source Interfaces
Posted by Stephan Michels <st...@apache.org>.
On Mon, 6 Jan 2003, Carsten Ziegeler wrote:
> > >I added before christmas the possibility to retrieve children
> > >of a source to the Source interface in excalibur and started
> > >with the ModifiableSource interface (= WriteableSource).
> > >
> > >What else do we need? I think we have a buch of extensions
> > >to the Source interface.
> > >
> >
> > Well, look in the 2.1 scratchpad where there's a lot of yummy stuff :
> > TraversableSource, VersionableSource, LockableSource, etc.
> >
> > While working on sources recently (the CVSSource I'm about to publish),
> > I found the current definition of TraversableSource not intuitive, and
> > modified it so it's more like to java.io.File :
> >
> > public interface TraversableSource extends Source {
> >
> > /** Is the source a directory or a collection ? */
> > public boolean isSourceCollection() throws ProcessingException,
> > IOException;
> >
> > /** Returns the collection of child sources. */
> > public Collection getChildren() throws ProcessingException,
> > IOException;
> >
> > /** Returns the local name of this source */
> > public String getName() throws ProcessingException, IOException;
getLocalId() ??? because of getSystemId()?
> > /** Return the parent source. Returns null if the source hasn't a
> > parent. */
> > public Source getParentSource() throws ProcessingException,
> > IOException;
> > }
I don't return Sources, because Sources can be Components, which
must be resolved/released by the SourceResolver.
So I think returning the URI instead of the Sources is a must-have.
> > Carsten, I also some remarks/questions about your changes in Excalibur :
> > - should parent/child traversal be defined on Source. IMO, a Source
> > should be kept very simple and basic as not all sources are traversable,
> Yes, that is true. But always doing an instanceof is not the best advice
> for doing OOP. So, I thought of adding the most common methods to the base
> interface and only use extending interfaces if required.
I like Avalon because of the separation of the contracts. If you implement
a component, you don't have to implement all lifecycle methods like
EJBs. If you implement a source you only need to implement the IFs that
you need.
My 2cents, Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Sylvain Wallez wrote:
>
> Carsten Ziegeler wrote:
>
> >I think it's time to define the WriteableSource etc. interfaces
> >for the excalibur source package and move them out of Cocoon.
> >
> >What do you think about this? This would move the responsibility
> >to excalibur :)
> >
>
> I guess you're joking, but is this good or bad ? Who else beside Cocoon
> is using the source package in Excalibur ?
>
Oh, believe me - a lot of projects and companies are using it! I get
several support questions for that package every month from various
places.
So, to be true: no, it's not a joke.
> >I added before christmas the possibility to retrieve children
> >of a source to the Source interface in excalibur and started
> >with the ModifiableSource interface (= WriteableSource).
> >
> >What else do we need? I think we have a buch of extensions
> >to the Source interface.
> >
>
> Well, look in the 2.1 scratchpad where there's a lot of yummy stuff :
> TraversableSource, VersionableSource, LockableSource, etc.
>
> While working on sources recently (the CVSSource I'm about to publish),
> I found the current definition of TraversableSource not intuitive, and
> modified it so it's more like to java.io.File :
>
> public interface TraversableSource extends Source {
>
> /** Is the source a directory or a collection ? */
> public boolean isSourceCollection() throws ProcessingException,
> IOException;
>
> /** Returns the collection of child sources. */
> public Collection getChildren() throws ProcessingException,
> IOException;
>
> /** Returns the local name of this source */
> public String getName() throws ProcessingException, IOException;
>
> /** Return the parent source. Returns null if the source hasn't a
> parent. */
> public Source getParentSource() throws ProcessingException,
> IOException;
> }
>
> Stephan, others, what about these changes ?
>
> Carsten, I also some remarks/questions about your changes in Excalibur :
> - should parent/child traversal be defined on Source. IMO, a Source
> should be kept very simple and basic as not all sources are traversable,
Yes, that is true. But always doing an instanceof is not the best advice
for doing OOP. So, I thought of adding the most common methods to the base
interface and only use extending interfaces if required.
> - why does getChildrenLocation return an Iterator (and not a Collection)
> of URIs (and Sources) ?
Hmm, why not Iterator? Why is Collection better?
Carsten
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Sylvain Wallez <sy...@anyware-tech.com>.
Carsten Ziegeler wrote:
>I think it's time to define the WriteableSource etc. interfaces
>for the excalibur source package and move them out of Cocoon.
>
>What do you think about this? This would move the responsibility
>to excalibur :)
>
I guess you're joking, but is this good or bad ? Who else beside Cocoon
is using the source package in Excalibur ?
>I added before christmas the possibility to retrieve children
>of a source to the Source interface in excalibur and started
>with the ModifiableSource interface (= WriteableSource).
>
>What else do we need? I think we have a buch of extensions
>to the Source interface.
>
Well, look in the 2.1 scratchpad where there's a lot of yummy stuff :
TraversableSource, VersionableSource, LockableSource, etc.
While working on sources recently (the CVSSource I'm about to publish),
I found the current definition of TraversableSource not intuitive, and
modified it so it's more like to java.io.File :
public interface TraversableSource extends Source {
/** Is the source a directory or a collection ? */
public boolean isSourceCollection() throws ProcessingException,
IOException;
/** Returns the collection of child sources. */
public Collection getChildren() throws ProcessingException, IOException;
/** Returns the local name of this source */
public String getName() throws ProcessingException, IOException;
/** Return the parent source. Returns null if the source hasn't a
parent. */
public Source getParentSource() throws ProcessingException, IOException;
}
Stephan, others, what about these changes ?
Carsten, I also some remarks/questions about your changes in Excalibur :
- should parent/child traversal be defined on Source. IMO, a Source
should be kept very simple and basic as not all sources are traversable,
- why does getChildrenLocation return an Iterator (and not a Collection)
of URIs (and Sources) ?
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: Defining Source Interfaces
Posted by Stephan Michels <st...@apache.org>.
On Mon, 6 Jan 2003, Carsten Ziegeler wrote:
>
>
> > -----Original Message-----
> > From: Stephan Michels [mailto:stephan@apache.org]
> > Sent: Monday, January 06, 2003 3:44 PM
> > To: Cocoon-Dev
> > Subject: Re: Defining Source Interfaces
> >
> >
> >
> >
> > On Mon, 6 Jan 2003, Carsten Ziegeler wrote:
> >
> > > I think it's time to define the WriteableSource etc. interfaces
> > > for the excalibur source package and move them out of Cocoon.
> > >
> > > What do you think about this? This would move the responsibility
> > > to excalibur :)
> > >
> > > I added before christmas the possibility to retrieve children
> > > of a source to the Source interface in excalibur and started
> > > with the ModifiableSource interface (= WriteableSource).
> > >
> > > What else do we need? I think we have a buch of extensions
> > > to the Source interface.
> >
> > Nothing that is really ready for production usage.
> >
> > But what about replacing the SourceResolver in SitemapModelComponent
> > by the the Excalibur SourceResolver? (Do we really need the SourceResolver
> > in the setup method *gruebel*).
> For compatibility reasons we can't change or remove the setup method.
> In fact (in C2.1) the first argument is the excalibur source resolver.
Of cause for 2.1 ;-)
Thanks, Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
RE: Defining Source Interfaces
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
> -----Original Message-----
> From: Stephan Michels [mailto:stephan@apache.org]
> Sent: Monday, January 06, 2003 3:44 PM
> To: Cocoon-Dev
> Subject: Re: Defining Source Interfaces
>
>
>
>
> On Mon, 6 Jan 2003, Carsten Ziegeler wrote:
>
> > I think it's time to define the WriteableSource etc. interfaces
> > for the excalibur source package and move them out of Cocoon.
> >
> > What do you think about this? This would move the responsibility
> > to excalibur :)
> >
> > I added before christmas the possibility to retrieve children
> > of a source to the Source interface in excalibur and started
> > with the ModifiableSource interface (= WriteableSource).
> >
> > What else do we need? I think we have a buch of extensions
> > to the Source interface.
>
> Nothing that is really ready for production usage.
>
> But what about replacing the SourceResolver in SitemapModelComponent
> by the the Excalibur SourceResolver? (Do we really need the SourceResolver
> in the setup method *gruebel*).
For compatibility reasons we can't change or remove the setup method.
In fact (in C2.1) the first argument is the excalibur source resolver.
Carsten
>
> That would make my job easier to write a Generator- and
> TransformerTestCase simply by extending the ExcaliburTestCase ;-)
>
> Stephan Michels.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org
Re: Defining Source Interfaces
Posted by Stephan Michels <st...@apache.org>.
On Mon, 6 Jan 2003, Carsten Ziegeler wrote:
> I think it's time to define the WriteableSource etc. interfaces
> for the excalibur source package and move them out of Cocoon.
>
> What do you think about this? This would move the responsibility
> to excalibur :)
>
> I added before christmas the possibility to retrieve children
> of a source to the Source interface in excalibur and started
> with the ModifiableSource interface (= WriteableSource).
>
> What else do we need? I think we have a buch of extensions
> to the Source interface.
Nothing that is really ready for production usage.
But what about replacing the SourceResolver in SitemapModelComponent
by the the Excalibur SourceResolver? (Do we really need the SourceResolver
in the setup method *gruebel*).
That would make my job easier to write a Generator- and
TransformerTestCase simply by extending the ExcaliburTestCase ;-)
Stephan Michels.
---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org