On Thursday 05 June 2003 07:18 am, J�rg Walter wrote:
> Am Thursday, 05. June 2003 01:51, schrieb Tod Harter:
> > Yeah, the problem is that XML::LibXML requires a flag to be set when the
> > parser is instantiated to tell it to process xincludes. I made a patch to
> > set the flag, but I never did get it to work. The result is that in
> > STATIC xml pages (non-XSP) AxKit DOES process xincludes, but in XSP land
> > it doesn't.
>
> I don't know what AxKit you are using, but all my AxKit installations
> definitely do XInclude for XSP, I use it all over the place.

In 1.6.x XSP DOES NOT do XInclude. I went over this with Matt. I tried hacking 
my copy. I never could get it to work. As I said, STATIC XML DOES do 
XInclude. Maybe something is peculiar about my system? I don't know... 
>
> > > What I'm trying to do is break up components of a page into small parts
> > > each of which I can manage the ACL for seperately and have a single xsl
> > > sheet control how those parts are arranged within a whole, with the
> > > possibility that, based on the data from the XSP, some parts may or may
> > > not be included.
>
> I thin for your case you should look at XSLT's document() function, it
> might be better suited. XInclude is always unconditionally - even if you
> put some <xsl:if> around it, the document will be parsed and processed, the
> result is just passed on or it isn't, but it is there. With document(), you
> won't touch any document unless you actually need it. Moreover, document()
> has nice semantics for relative paths, once you understand them ;-)

I agree with Jorge, though XInclude sure is simpler! Personally I use XInclude 
for things like forms and sidebars which you know are always going to show up 
on the page but which you wish to maintain seperately.
-- 
Tod Harter
Giant Electronic Brain
http://www.giantelectronicbrain.com

---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to