John Prevost wrote:
>
> >>>>> "sm" == Stefano Mazzocchi <stefano@apache.org> writes:
>
> sm> the need for a "default" matcher emerged and I agree that the
> sm> syntax above can lead to problems for users thinking that the
> sm> <generator> at the end is executed no matter what.
>
> sm> Possible solutions are:
>
> <process uri="*">
> <match type="load" greater-then="2.5">
> <generator type="parser" src="./*.xml" />
> <filter type="xslt" src="./stylesheet/low-graphics.xsl" />
> <serializer type="html" />
> </match>
> <match type="browser" is="Mozilla5">
> <generator type="parser" src="./*.xml" />
> <filter type="xslt" src="./stylesheet/xul-enabled.xsl" />
> <serializer type="html" />
> </match>
> <otherwise>
> <generator type="parser" src="./*.xml" />
> <filter type="xslt" src="./stylesheet/general-browser.xsl" />
> <serializer type="html" />
> </otherwise>
> </process>
>
> sm> which can be rewritten less verbosely as
>
> <process uri="*">
> <generator type="parser" src="./*.xml"/>
> <match type="load" greater-then="2.5">
> <filter type="xslt" src="./stylesheet/low-graphics.xsl"/>
> </match>
> <match type="browser" is="Mozilla5">
> <filter type="xslt" src="./stylesheet/xul-enabled.xsl"/>
> </match>
> <otherwise>
> <filter type="xslt" src="./stylesheet/general-browser.xsl"/>
> </otherwise>
> <serializer type="html"/>
> </process>
>
> sm> is this readable enough for everybody?
>
> Hmm. I think this would be better:
>
> <process uri="*">
> <generator type="parser" src="./*.xml"/>
> <case>
> <match type="load" greater-than="2.5">
> <filter type="xslt" src="./stylesheet/low-graphics.xsl"/>
> </match>
> <match type="browser" equal-to="Mozilla5">
> <filter type="xslt" src="./stylesheet/xul-enabled.xsl"/>
> </match>
> <otherwise>
> <filter type="xslt" src="./stylesheet/general-browser.xsl"/>
> </otherwise>
> </case>
> <serializer type="html"/>
> </process>
>
> First, because greater-than is better than greater-then, and equal-to
> is more like greater-than (and hence more consistent). ;>
>
> But more importantly, because it allows for the possibility of more
> than one match case grouping in a row:
>
> <process ...>
> <generator .../>
> <case>
> ...
> </case>
> <case>
> ...
> </case>
> <serializer .../>
> </process>
>
> In this example, one choice from the first case would run, then one
> choice from the second case would run. We could further add syntax
> sugar to make:
>
> <process ...>
> ...
> <match ...>
> ...
> </match>
> ...
> </process>
>
> where the match isn't in a case be equivalent to:
>
> <process ...>
> ...
> <case>
> <match ...>
> ...
> </match>
> </case>
> ...
> </process>
>
> Which in my example would mean "if it matches do it, if not, don't".
> So match on its own is equivalent to xsl:if, and match and otherwise
> inside case are equivalent to xsl:when and xsl:otherwise inside
> xsl:case.
Ok, I understand.
Should we _clone_ the XSLT conditional paradigms "in toto"?
> As an example of how you might want to use this (now we get to see how
> much I remember from your message yesterday without looking at it
> again.):
>
> <process uri="*">
> <case>
> <match type="load" greater-than="3.5">
> <generator type="parser" src="./pre-processed/*.xml"/>
> </match>
> <otherwise>
> <generator type="parser" src="./*.xml"/>
> <filter type="xslt" src="./logicsheet/blah.xsl"/>
> <filter type="xsp"/>
> </otherwise>
> </case>
> <case>
> <match type="load" greater-than="2.5">
> <filter type="xslt" src="./stylesheet/low-graphics.xsl"/>
> </match>
> <match type="browser" equal-to="Mozilla5">
> <filter type="xslt" src="./stylesheet/xul.xsl"/>
> </match>
> <otherwise>
> <filter type="xslt" src="./stylesheet/plain.xsl"/>
> </otherwise>
> </case>
> <serializer type="html"/>
> </process>
>
> The goal of the above is: normally, use Mozilla5 XUL or normal
> stylesheets depending on the browser, and read from ./*.xml. But if
> the load goes above 2.5, we want to use the low-graphics sheet no
> matter what browser.
>
> But then, if the load is still high, and goes above 3.5, we also bail
> on doing xsp work (which is going to a database or something and
> provides neat dynamic stuff) and drop down to a static content only
> site until things calm down a bit.
>
> Sound reasonable? Sounds reasonably complex. :)
Complex things require complex logic. But this is _much_ less complex
that any mod_rewrite stuff that provide equal functionality.
> On the "naming things" warpath again, I noticed when looking back at
> your original message (yes, I cheated) that you have:
>
> <match type="ip-filter" allowed-address="...">
> <match type="browser" accepts="...">
> <match type="user" belongs-to="...">
> <match type="load" greater-than="...">
> <match type="browser" is="...">
>
> This looks to me like another case of "the loaded class chooses what
> attributes it can have", which is easy to code and pretty friendly,
> but not so XMLish sometimes. I'm almost starting to think that you
> almost ought to be ripping XSL's expression syntax and conditionals
> off completely here, and say:
>
> <if test="allowed-address($ip-filter)">
> <if test="accepts($browser, 'blah')">
> <if test="belongs-to($user, 'group')">
> <if test="$load > 2.5">
> <if test="$browser = 'Mozilla5'">
>
> The above isn't a good choice of syntax, and I'm not entirely sure
> what is, but with choices that are this free-form, I think you really
> do start dropping into a place where a fuul expression syntax is
> needed. And that's not even counting the pain of creating halfway
> complex logical expressions with nested match tags.
Ok, we are clearly back again to the XSLT/XPath realm.
_PLEASE_ listen carefully: I _do_ understand that code-influenced
schemas are _not_ XMLish. But this is only because you think of Valid
XML as something that can be validated using a DTD or an XMLSchema!!!
There is no point on having a DTD-validated sitemap if we encode all the
logic into unparsable strings. XPath is different because reused by
other specs (xpointer, XQL), but do we really want to create another
one-liner scripting language for matching rules?
I admit I'm not happy with the current matching framework myself, but
_please_ let's not use the "this is not XMLish" argument anymore, ok?
I think it's much easier to validate something that has code-driven
attributes, provided that there is an automatic way to generate a DTD
out of code... much like you do javadocs for your code documentation.
(in fact, you could use a doclet to do it!)
So
<if test="belongs-to($user, 'group')"/>
is actually worse than
<if type="user" belongs-to="group"/>
for both validation and readability once you have your code-generated
DTD.
> I say +1 to most of what I see in the sitemap, but 0 to the way the
> match stuff works right now. I apologize for not being able to come
> up with a better proposal.
Don't worry..
> Hrm. Okay, a slight proposal, but it still makes me feel icky. You
> could have match like:
>
> <match type="foo" test="bar">
> ...
> </match>
>
> where foo gets to interpret bar however it pleases. Hence:
>
> <match type="ip-filter" test="allowed">
> <match type="browser" test="accepts('...')">
> <match type="user" test="member-of('...')">
> <match type="load" test="> 2.5">
> <match type="browser" test="is('Mozilla5')">
>
> But this is still a big mess--trying to integrate the expression
> evaluation stuff from XPath might actually be easier.
We are slowly converging to the mod_rewrite complexity.... and this
scares the hell out of me :(
--
Stefano Mazzocchi One must still have chaos in oneself to be
able to give birth to a dancing star.
<stefano@apache.org> Friedrich Nietzsche
--------------------------------------------------------------------
Missed us in Orlando? Make it up with ApacheCON Europe in London!
------------------------- http://ApacheCon.Com ---------------------
|