You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@avalon.apache.org by Peter Royal <pr...@managingpartners.com> on 2002/04/13 21:57:56 UTC
Status of Cocoon component migration.
see http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg05192.html
for the most recent thread on this.
It appears that the SourceResolver never made it out of scratchpad.
I have a need for cocoon's XSLTProcessor outside of Cocoon and thus I will
port that this afternoon. Its only component dependencies are upon the Store
and SourceResolver. Since Store support is optional I will just leave that
bit unimplemented for now. Is org.apache.avalon.excalibur.xml.xslt a good
package name?
It also uses org.apache.cocoon.util.ClassUtils, and harm in moving that
pretty much as-is to org.apache.avalon.excalibur.util.ClassUtils?
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XSLT Component, was Re: Status of Cocoon component migration.
Posted by Peter Royal <pr...@apache.org>.
On Thursday 25 April 2002 03:11 am, Carsten Ziegeler wrote:
> Yes, it's exactly the way I would have done it :)
good! :)
> One thing I just "corrected", the xslt processor should lookup the
> source resolver instead of getting it set.
I wasn't sure on that one, I just had copied the previous behavior. Thanks
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: XSLT Component, was Re: Status of Cocoon component migration.
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Peter Royal wrote:
>
> On Wednesday 24 April 2002 08:42 am, Carsten Ziegeler wrote:
> > in my eyes, the xslt component should use the sourceresolve package
> > to resolve xsl files, like the cocoon version does. This will allow
> > easy integration in every project using avalon.
> > So a dependency on the sourceresolve bundle is necessary.
>
> okie I've commited the xlst processor. If you could, look over how i'm
> converting the Source into SAX events to make sure I got all the
> discussions
> on the topic correct. thanks! :)
Yes, it's exactly the way I would have done it :)
One thing I just "corrected", the xslt processor should lookup the
source resolver instead of getting it set.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XSLT Component, was Re: Status of Cocoon component migration.
Posted by Peter Royal <pr...@apache.org>.
On Wednesday 24 April 2002 08:42 am, Carsten Ziegeler wrote:
> in my eyes, the xslt component should use the sourceresolve package
> to resolve xsl files, like the cocoon version does. This will allow
> easy integration in every project using avalon.
> So a dependency on the sourceresolve bundle is necessary.
okie I've commited the xlst processor. If you could, look over how i'm
converting the Source into SAX events to make sure I got all the discussions
on the topic correct. thanks! :)
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: XSLT Component, was Re: Status of Cocoon component migration.
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Peter Donald wrote:
>
> Hi,
>
> On Wed, 24 Apr 2002 22:42, Carsten Ziegeler wrote:
> > The move is finished now and everything should be stable and
> > (hopefully) working.
>
> I am going to try to integrate it this weekend into stuff I am
> working on. If
> you could hold of moving it to cocoon and finalizing the
> component till then
> that would be great !
>
It's already in Cocoon :)
But this is no problem, it's not activated yet, so if there are
any changes, I can simply reflect them. I'm interested in your
feedback.
Carsten
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: XSLT Component, was Re: Status of Cocoon component migration.
Posted by Peter Donald <pe...@apache.org>.
Hi,
On Wed, 24 Apr 2002 22:42, Carsten Ziegeler wrote:
> The move is finished now and everything should be stable and
> (hopefully) working.
I am going to try to integrate it this weekend into stuff I am working on. If
you could hold of moving it to cocoon and finalizing the component till then
that would be great !
--
Cheers,
Peter Donald
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: XSLT Component, was Re: Status of Cocoon component migration.
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Hi Peter,
in my eyes, the xslt component should use the sourceresolve package
to resolve xsl files, like the cocoon version does. This will allow
easy integration in every project using avalon.
So a dependency on the sourceresolve bundle is necessary.
The move is finished now and everything should be stable and
(hopefully) working.
Bye
Carsten
> -----Original Message-----
> From: Peter Royal [mailto:proyal@apache.org]
> Sent: Tuesday, April 23, 2002 5:55 PM
> To: Avalon Developers List
> Subject: XSLT Component, was Re: Status of Cocoon component migration.
>
>
> On Saturday 13 April 2002 05:56 pm, PeterDonald wrote:
> > For the time being I would actually move it into the same
> package as where
> > you move the XSLT stuff. This would mean that the xslt package was
> > decoupled from utils.* and thus easier to reuse. I may even
> just copy-paste
> > the required methods into classes that use them if ther eis
> only a few uses
> > of the methods.
>
> I have the XLST component working, or working compared to CVS as
> of last week
> before the XML and SourceResolver packages moved :)
>
> Now that the XML processor and family are in xmlbundle, they
> would require a
> new dependency on sourceresolve and scratchpad.
>
> I think being able to pass a Source to the XSLTProcessor is very
> useful, but
> wanted to ping others before adding deps.
> -pete
>
> --
> peter royal -> proyal@apache.org
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
XSLT Component, was Re: Status of Cocoon component migration.
Posted by Peter Royal <pr...@apache.org>.
On Saturday 13 April 2002 05:56 pm, PeterDonald wrote:
> For the time being I would actually move it into the same package as where
> you move the XSLT stuff. This would mean that the xslt package was
> decoupled from utils.* and thus easier to reuse. I may even just copy-paste
> the required methods into classes that use them if ther eis only a few uses
> of the methods.
I have the XLST component working, or working compared to CVS as of last week
before the XML and SourceResolver packages moved :)
Now that the XML processor and family are in xmlbundle, they would require a
new dependency on sourceresolve and scratchpad.
I think being able to pass a Source to the XSLTProcessor is very useful, but
wanted to ping others before adding deps.
-pete
--
peter royal -> proyal@apache.org
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Status of Cocoon component migration.
Posted by Peter Royal <pr...@managingpartners.com>.
On Saturday 13 April 2002 05:56 pm, PeterDonald wrote:
> > It also uses org.apache.cocoon.util.ClassUtils, and harm in moving that
> > pretty much as-is to org.apache.avalon.excalibur.util.ClassUtils?
>
> For the time being I would actually move it into the same package as where
> you move the XSLT stuff. This would mean that the xslt package was
> decoupled from utils.* and thus easier to reuse. I may even just copy-paste
> the required methods into classes that use them if ther eis only a few uses
> of the methods.
Willdo. I didn't end up using it this weekend (decided doing an edi interface
wasn't what i wanted to spend my weekend hours on, altrmi is more fun) but
might get to it this week.
-pete
--
peter royal -> proyal@managingpartners.com
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
Re: Status of Cocoon component migration.
Posted by PeterDonald <pe...@apache.org>.
On Sun, 14 Apr 2002 05:57, Peter Royal wrote:
> see http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg05192.html
> for the most recent thread on this.
>
> It appears that the SourceResolver never made it out of scratchpad.
We should probably get around to releasing that ;)
> It also uses org.apache.cocoon.util.ClassUtils, and harm in moving that
> pretty much as-is to org.apache.avalon.excalibur.util.ClassUtils?
For the time being I would actually move it into the same package as where you
move the XSLT stuff. This would mean that the xslt package was decoupled from
utils.* and thus easier to reuse. I may even just copy-paste the required
methods into classes that use them if ther eis only a few uses of the
methods.
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
RE: Status of Cocoon component migration.
Posted by Carsten Ziegeler <cz...@s-und-n.de>.
Peter Royal wrote:
>
> see
> http://www.mail-archive.com/avalon-dev@jakarta.apache.org/msg05192.html
> for the most recent thread on this.
>
> It appears that the SourceResolver never made it out of scratchpad.
Yupp, I just started with integrating the SourceResolver back into
Cocoon. The current CVS of Cocoon is able to use the SourceResolver
but I'm not happy with the Source/ModifiableSource etc. interfaces
and wanted to start a discussion about this topic this week as soon
as I get time for it.
I hope to get it out of scratchpad either this or next week.
>
> I have a need for cocoon's XSLTProcessor outside of Cocoon and
> thus I will
> port that this afternoon.
Great!
Carsten
> Its only component dependencies are
> upon the Store
> and SourceResolver. Since Store support is optional I will just
> leave that
> bit unimplemented for now. Is org.apache.avalon.excalibur.xml.xslt a good
> package name?
>
> It also uses org.apache.cocoon.util.ClassUtils, and harm in moving that
> pretty much as-is to org.apache.avalon.excalibur.util.ClassUtils?
> -pete
>
> --
> peter royal -> proyal@managingpartners.com
>
> --
> To unsubscribe, e-mail:
<ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>
--
To unsubscribe, e-mail: <ma...@jakarta.apache.org>
For additional commands, e-mail: <ma...@jakarta.apache.org>