On Monday 07 January 2002 01:03 pm, Nicola Ken Barozzi wrote: > ----- Original Message ----- > From: "Vadim Gritsenko" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]>; "'Nicola Ken Barozzi'" > <[EMAIL PROTECTED]> > Sent: Monday, January 07, 2002 7:31 PM > Subject: RE: Allowed Sitemap Constructs > > > <map:select> > > <map:when test="XX"> > > <map:generate/> > > </map:when> > > <map:when test="YY"> > > <map:generate/> > > </map:when> > > <map:otherwise> > > <map:generate/> > > </map:otherwise> > > </map:select> > > <map:serialize/> > > > > Try to convert to matchers - you will fail :) > > This fails? :-o ;-) > > <map:match> > <map:match pattern="XX"> > <map:generate/> > </map:match> > <map:match pattern="YY"> > <map:generate/> > </map:match> > <map:match pattern="**"> > <map:generate/> > </map:match> > </map:match> > <map:serialize/> >
The select structure does one generate (for XX, YY or in all other cases) and one serialize, while the match version generates once or twice (XX & the **, YY & **, or in all other cases **), and one serialize. > I haven't tried it, so I don't know if it really fails, but it seems there > is an overlap between matchers and selectors which is dangerous IMHO. > With no overlap it's easy to decide what to use, but they seem so similar > it's difficult to really see how to use them. Actions complicate this Can it be successfully argued that match and select can't be fused? Recollect the C++ usage of struct and class. A struct is public by default, so a C struct behaves as it should. So, map:select might accept a returns-map="true" attribute, Thus, map:match could be retained, but be converted always into an equivalent select statement. Why not? --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
