You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Giacomo Pati <gi...@apache.org> on 2000/11/12 18:02:43 UTC
Re: [C2 & patch] Re: Matchers and Selectors (was Re: Better and
Betterand RT)
Marcus Crafter wrote:
>
> On Thu, 9 Nov 2000, Giacomo Pati wrote:
>
> > The concept of a Matcher is much more general. You can easily write a
> > Matcher that matches "high load on the servel" or alike.
>
> *nod*.. sounds good.
>
> > How about his:
> >
> > <select type="paramselector">
> > <when test="myparameter = on">
> > ...
> > </when>
> > <when test="yourparameter = on">
> > ...
> > </when>
> > <otherwise>
> > ...
> > </otherwise>
> > </select>
>
> Excellent idea. I'm putting it together at the moment. Note for the
> above example to work, we'll need to add = to the call to 'translate' in
> sitemap.xsl (when 'generate-name' is called, otherwise the = sign is
> added to the generated class variable name causing a compiler error).
Oh, yes of course, I didn't think of. Maybe it's better to get rid of
trying to derivate names from the pattern and generate pure names with
generate-id().
> I also though about implementing 'greater than' and 'less than'
> operators too. Over time I would like to expand the set of operators
> to include many varied tests. ie:
Why not. But keep in mind your operators are used by admin people not by
programmers (and with admin people i don't meant sys admins :). So
please keep it as simple and understandable as possible.
You can use an "is" instead of "=" (good old COBOL is comming back :])
> <when test="yourparameter > 30">
> ...
> </when>
>
> However there is a problem in sitemap.xsl here. The translate method
> can turn the < and > symbols into _ symbols which is fine, but the
> call to 'generate-id()' will give the same id for both generated class
> variables (because generate-id() is called with .. as a parameter).
Yes, see above.
> This means the 2 variables can have the same name (eg. if you use <
> or > in 2 equal leveled when statements).
Yup.
> I've changed the call to generate-id() to use . (ie. the current node,
> instead of its parent) to fix this problem - why was it
> using .. anyway ? Have I possible broken something else ?
I wanted to have the same id based on the <select> element and not on
the <when> or <otherwise>. But yes, anyway, I'll have to change the hole
name generation stuff.
> I've attached a patch with the changes.
Thanks, it's a workaround for now.
Giacomo
Re: [C2 & patch] Re: Matchers and Selectors (was Re: Better and
Betterand RT)
Posted by Raphael Luta <lu...@networks.vivendi.net>.
Giacomo Pati wrote:
>
> Marcus Crafter wrote:
> >
> > On Thu, 9 Nov 2000, Giacomo Pati wrote:
> >
> > > The concept of a Matcher is much more general. You can easily write a
> > > Matcher that matches "high load on the servel" or alike.
> >
> > *nod*.. sounds good.
> >
> > > How about his:
> > >
> > > <select type="paramselector">
> > > <when test="myparameter = on">
> > > ...
> > > </when>
> > > <when test="yourparameter = on">
> > > ...
> > > </when>
> > > <otherwise>
> > > ...
> > > </otherwise>
> > > </select>
> >
> > Excellent idea. I'm putting it together at the moment. Note for the
> > above example to work, we'll need to add = to the call to 'translate' in
> > sitemap.xsl (when 'generate-name' is called, otherwise the = sign is
> > added to the generated class variable name causing a compiler error).
>
> Oh, yes of course, I didn't think of. Maybe it's better to get rid of
> trying to derivate names from the pattern and generate pure names with
> generate-id().
>
> > I also though about implementing 'greater than' and 'less than'
> > operators too. Over time I would like to expand the set of operators
> > to include many varied tests. ie:
>
> Why not. But keep in mind your operators are used by admin people not by
> programmers (and with admin people i don't meant sys admins :). So
> please keep it as simple and understandable as possible.
>
> You can use an "is" instead of "=" (good old COBOL is comming back :])
>
I'd rather have UNIX shell like operators name (my own background ;) )
eq for equal
ne for not equal
lt for lower than
gt for greater than
le for lower or equal
...
This avoids the use of restricted characters, covers all the needed operators
and is pretty intuitive for any English speaker or UNIX shell user.
--
Raphaël Luta - luta.raphael@networks.vivendi.net
Re: [C2 & patch] Re: Matchers and Selectors (was Re: Better and
Betterand RT)
Posted by Marcus Crafter <cr...@dresdnerbank.de>.
Hi All,
On Tue, 14 Nov 2000, Marcus Crafter wrote:
> On Mon, 13 Nov 2000, Marcus Crafter wrote:
>
> > Programmer style Quasi-English style
> > -----------------------------------
> > == eq
> > != ne
> > < lt
> > > gt
> > <= le
> > >= ge
> > && and
> > || or
> > ! not
Just to keep everyone updated - the selectors are coming along well, I
had to put out some other fires in the meantime which caused a little
delay, but I'll have something posted to the list in the next few days.
Looking forward to everyones comments,
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&: After Hours : +49 69 49086750
Re: [C2 & patch] Re: Matchers and Selectors (was Re: Better and
Betterand RT)
Posted by Marcus Crafter <cr...@dresdnerbank.de>.
On Mon, 13 Nov 2000, Marcus Crafter wrote:
> On Sun, 12 Nov 2000, Giacomo Pati wrote:
>
> > Marcus Crafter wrote:
> > >
> I thought about the following operator set:
>
> Programmer style Quasi-English style
> -----------------------------------
> == eq
> != ne
> < lt
> > gt
> <= le
> >= ge
> && and
> || or
> ! not
>
> and even for the perl dudes:
>
> =~ matches (?)
After thinking about it last night, perhaps this last one should be
covered by a 'matcher' and not a 'selector' ? What I was aiming for
was a way to be able to save people needing to write '.. or ... or
.. or .. or .. or', etc. Regular expressions seemed natural enough.
I'll can implement the others first, and after a bit of usage we can
see if the last one makes sense as a selector test case ?
Comments anyone ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&: After Hours : +49 69 49086750
Re: [C2 & patch] Re: Matchers and Selectors (was Re: Better and
Betterand RT)
Posted by Marcus Crafter <cr...@dresdnerbank.de>.
On Sun, 12 Nov 2000, Giacomo Pati wrote:
> Marcus Crafter wrote:
> >
> > On Thu, 9 Nov 2000, Giacomo Pati wrote:
>
> Maybe it's better to get rid of trying to derive names from the pattern
> and generate pure names with generate-id().
Might be better solution. With generate-id(.) we're guaranteed of
getting unique variables anyway.
> > I also though about implementing 'greater than' and 'less than'
> > operators too. Over time I would like to expand the set of operators
> > to include many varied tests. ie:
>
> Why not. But keep in mind your operators are used by admin people not by
> programmers (and with admin people i don't meant sys admins :). So
> please keep it as simple and understandable as possible.
>
> You can use an "is" instead of "=" (good old COBOL is comming back :])
I understand, although as a developer I tend to like 'eq' instead of
'is' like Raphael suggested. What do you think ?
I see a lot of power in creating a boolean logic evaluation engine
which could be used from a parameter selector, a session selector, a
context selector, etc, in fact any kind of selector that can provide
a context to operate in (ie. lookup between variable names and values)
and a string to evaluate. It would provide for a lot of flexibility in
the sitemap.
I'm itching to write such a thing, even if it is a little overkill! :-)
We could please both developers and admins with the operator names ?
I thought about the following operator set:
Programmer style Quasi-English style
-----------------------------------
== eq
!= ne
< lt
> gt
<= le
>= ge
&& and
|| or
! not
and even for the perl dudes:
=~ matches (?)
with the ability to nest expressions using parentheses ().
Any others that I'm missing ?
Implementation wise, my intention was to base the logic evaluator on
the Interpreter and Composite patterns, perhaps in combination with
the Visitor and Flyweight patterns where appropriate.
I thought about also using jlex/cups to build up the logics AST easily.
Any suggestions, I'd be interested in peoples comments ?
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : Marcus.Crafter@osa.de
&&&&. Business Hours : +49 69 9757 200
&&&&&&&: After Hours : +49 69 49086750