Re: XSP...

[Matt Sergeant <ma...@sergeant.org>]

On Thu, 29 Jun 2000, Niklas Lindström wrote:

> 
> Although I'm lagging far behind on my reading of this list, the
> xsp-issue
> reminds me of a question/wish. It's about including the following
> "XSP-built in objects" mentioned in Cocoons page:
> 
> - xspCurrentNode. An org.w3c.Node object corresponding to the node being
> currently populated
> - xspParser. A Cocoon-supplied DOM parser which may be used to create
> new
> documents and parse external XML documents
> 
> I believe these can prove very useful. (Actually, after some pondering,
> I
> wonder why there is no <xsp:parse url="..."/> or likewise in the
> xsp-specs.) To have a producer being able to serve some xml-fragments
> depending on request for instance, would prove more dynamic in some
> cases
> than expanding each of those into indepentent producers. I may be a
> little
> fuzzy about this, but I haven't tried out anything for real yet.

After attending Bob DuCharme's talk on xlink at xmldevcon, I think
<xsp:parse> might be pretty smart in here - but using xlink you could
specify if the new document would replace the current one, or be embedded
into it, or be completely separate. Could be quite nice. I wouldn't want
to diverge from the Cocoon guys on this issue though - so I'm CC'ing
Cocoon-Dev on this.

PS: Cocoon-dev: Thank you very much for fixing the list archive - 1000%
better now.

PPS: Cocoon-dev: Please make sure you don't trim the CC list on replies,
as I don't subscribe.

-- 
<Matt/>

Fastnet Software Ltd. High Performance Web Specialists
Providing mod_perl, XML, Sybase and Oracle solutions
Email for training and consultancy availability.
http://sergeant.org | AxKit: http://axkit.org

Re: XSP...

[Stefano Mazzocchi <st...@apache.org>]

Matt Sergeant wrote:
> 
> On Thu, 29 Jun 2000, Niklas Lindström wrote:
> 
> >
> > Although I'm lagging far behind on my reading of this list, the
> > xsp-issue
> > reminds me of a question/wish. It's about including the following
> > "XSP-built in objects" mentioned in Cocoons page:
> >
> > - xspCurrentNode. An org.w3c.Node object corresponding to the node being
> > currently populated
> > - xspParser. A Cocoon-supplied DOM parser which may be used to create
> > new
> > documents and parse external XML documents
> >
> > I believe these can prove very useful. (Actually, after some pondering,
> > I
> > wonder why there is no <xsp:parse url="..."/> or likewise in the
> > xsp-specs.) To have a producer being able to serve some xml-fragments
> > depending on request for instance, would prove more dynamic in some
> > cases
> > than expanding each of those into indepentent producers. I may be a
> > little
> > fuzzy about this, but I haven't tried out anything for real yet.
> 
> After attending Bob DuCharme's talk on xlink at xmldevcon, I think
> <xsp:parse> might be pretty smart in here - but using xlink you could
> specify if the new document would replace the current one, or be embedded
> into it, or be completely separate. Could be quite nice. I wouldn't want
> to diverge from the Cocoon guys on this issue though - so I'm CC'ing
> Cocoon-Dev on this.

Thanks for doing this Matt, I totally agree that forking XSP would be a
very bad thing to do.

I think that <xsp:parse> would be bad as well, because it would just
duplicate XInclude functionalities (that we already provide in Cocoon).

(BTW, latest xlink spec removed the auto/parsed links in favor of
XInclude)
 
> PS: Cocoon-dev: Thank you very much for fixing the list archive - 1000%
> better now.

You're welcome.
 
-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------