xml-xsp-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Sergeant <m...@sergeant.org>
Subject Re: this list --was Xsp w/out Cocoon
Date Sun, 07 Apr 2002 11:48:31 GMT
On Saturday 06 April 2002 9:37 pm, Ulrich Mayring wrote:
> Matt Sergeant wrote:
> > > startElement("foo") ==> t1 handler
> > > startElement("bar") ==> t2 handler
> > > endElement("bar") ==> t2 handler
> > > endElement("foo") ==> t1 handler
> >
> > Right. This is how it works.
> >
> > > But this way the t1 handler cannot know if the <t1:foo> element is
> > > empty or not.
> >
> > Why would it care? It all just DWIMs (Do What I Mean). In fact I would
> > consider it a HORRIBLE design error if t1 knew anything whatsoever about
> > t2 there.
>
> Yes, I absolutely agree that t1 shouldn't know about t2. But the
> question here is, should t1 know whether it has any children or not.
> Consider this template rule in t1:
>
> <xsl:template match="t1:foo">
> 	<xsl:if test="count(*) > 0">
> 		<yay/>
> 	</xsl:if>
> </xsl:template>
>
> Obviously, with namespace dispatch there will never be a <yay/> in the
> output, whereas with traditional processing there will be. However,
> different implementations of the same spec should produce the same result.

t1 should never know about child elements - that's simply wrong-think. If it 
takes some form of parameters it should only know about those parameters, and 
XSP should only send parameters to a taglib when they are actual expressions 
- otherwise you've just got plain output, which really should never be seen 
by a taglib whatsoever.

-- 
<:->get a SMart net</:->

Mime
View raw message