cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Giacomo Pati <pati_giac...@yahoo.com>
Subject Re: [C2/Patch] Selector Heaven :-)
Date Thu, 30 Nov 2000 12:48:42 GMT

--- Marcus Crafter <crafterm@dresdnerbank.de> wrote:
> Hi All,
> 
> 	Hope all is going well across the Cocoon globe!
> 	
> 	Attached is a set of files to add initial support for the following
> 	selectors to Cocoon 2:
> 
> 		o ParamSelectorFactory
> 
> 			Used for testing values from request parameters.
> 
> 		o SessionSelectorFactory
> 
> 			Used for testing values from session attributes.
> 
> 		o ContextSelectorFactory
> 
> 			Used for testing values from context attributes.
> 
> 		o RequestHeaderSelectorFactory
> 
> 			Used for testing values from request headers.

Awesome or awefull (I never really know which is correct). Sound really
great. But let me bring up some thoughts poping up :)

> 	Each of the selectors use an underlying boolean engine which can
> 	parse and evaluate strings for truthness. The boolean engine uses
> JLex
> 	and CUP to scan and parse strings according to a defined (and
> 	extensible) grammar.

Have you checked the license of those tools (no GPL allowed in apache
cvs)

> 	Currently, the following operators (programmer-style and
> 	english-style) are supported:
> 
> 	=, !=, <, >, <=, >=, &&, || , !, (, )

AFAIK some of these symbols are illegal in XML documents (< > &).
Shouldn't we get rid of them and use the following only [but of course
keeping !, ( and )]

> 	eq, ne lt, gt, le, ge, and, or
> 
> 	The operators also automatically select string, or integer based
> 	arithmetic depending on the arguments given (eg. when given an
> integer,
> 	= performs integer comparison, when given a string, = performs
> string
> 	comparison).

and if I use something like

   <map:select type="parm" test="myparm gt yourparm"/>

> 	Using these operators one can create simple to quite powerful and
> 	useful tests.
> 
> 	Examples:
> 
> 		<!-- test whether myparameter equals the integer 5 -->
> 		<when test="myparameter=5">
> 
> 		<!-- test whether myparameter is lexographically greater than
> 		     the string 'abcde' -->
> 		<when test="myparameter>'abcde'">
> 
> 		<!-- test whether myparameter is less than 10 or greater than
> 		     20 -->
> 		<when test="myparameter < 10 or myparameter > 20">
> 
> 		<!-- test whether myparmeter simply exists -->
> 		<when test="myparameter">
> 
> 	(more examples are in the Test directory)
> 
> 	Technically, the selectors simply pass the string to the boolean
> 	engine for evaluation with a 'context' the engine can use to
> retrieve
> 	values of variables.
> 	
> 	In effect, a boolean style selector can now be made out of any class
> 	that provides a way to map variables to values - the
> 	ParamSelectorFactory, etc, selectors only differ by the way they
> 	provide a context for the boolean engine to operate in.
> 
> 	I've tested the code in our environment here, but what it needs now
> is
> 	much more rigorous testing. I'm building a test rig for the engine
> to
> 	automate much of the testing and will send the rest of it in over
> the
> 	next days (the file Tester.java is the start of it, but it needs a
> bit
> 	more work). If you see some strange behaviour or think that
> something
> 	is wrong, please send me the string you used to evaluate, and the
> 	values of the variables you used (if any). I'll look in to it.
> 
> 	What is not yet implemented includes support for floating point
> 	numbers in the scanner (the parser and logic supports them), more
> 	rigorous error handling, a complete test rig, and other operators
> not
> 	listed above. I'm going to be looking into these next.
> 
> 	I'm also looking into optimising the code a some more to reduce the
> 	number of objects created each test. The addition of some
> flyweights,
> 	and mutator methods should help here.
> 
> 	I've also noticed that my coding style is a slightly different from
> 	Apache's. Is there a code formatter one can use to automatically
> 	format code according to Apache's guidelines ? (where are the
> 	guidelines ?). Something like indent for C ?

Apaches coding style is the same as sun's. There is a formatter in the
C2 lib (JStyle and JBeautifier classes in the jstyle.jar which have a
simple pipe aproche to use)

   cat source.java | \
      java jstyle.JStyle | \
      java jstyle.JBeautifier > newsource.java

IIRC

> 	If the Cocoon developers are OK with it, I'm happy for this to
> 	be included in the general Cocoon 2 distribution. The files are
> ready
> 	to be dropped into CVS as is, except for the parser and scanner java
> 	files which must be generated (I didn't touch the build.xml, perhaps
> 	one of the other more 'ant' familiar developers might be able to
> help

Sure. No problem.

> 	me out there), but what should happen before the build starts
> (perhaps
> 	in the prepare rule) is the following:
> 
> 	java -classpath jlex.jar JLex.Main Scanner.jlex
> 	mv Scanner.jlex.java Yylex.java
> 
> 	to generate the scanner (yes, unfortunately the move is necessary),
> 	and then:
> 
> 	java -classpath cup.jar java_cup.Main < Parser.cup
> 
> 	to generate the parser.
> 
> 	These two steps generate the files Yylex.java, parser.java and
> 	sym.java, which should be moved/copy into the
> 	cocoon/selection/helpers/bool directory and then compiled (I've
> 	included pregenerated versions of these files in the attachment
> above
> 	for those who want to see what the generated scanner/parser code
> looks
> 	like).
> 
> 	I haven't included JLex or CUP in the attachments above to keep the
> 	size down. JLex is available from
> 	http://www.cs.princeton.edu/~appel/modern/java/JLex/ (version
> 1.2.5),
> 	and CUP is available from
> 	http://www.cs.princeton.edu/~appel/modern/java/CUP/ (version 0.10j).
> 	They need to be downloaded and added to the lib directory.
> 
> 	The only other change is to add the selectors to your sitemap
> 	configuration:
> 
> <map:selector name="parameter"
> factory="org.apache.cocoon.selection.ParamSelectorFactory"/>
> <map:selector name="session"
> factory="org.apache.cocoon.selection.SessionSelectorFactory"/>
> <map:selector name="context"
> factory="org.apache.cocoon.selection.ContextSelectorFactory"/>
> <map:selector name="header"
> factory="org.apache.cocoon.selection.RequestHeaderSelectorFactory"/>
> 
> 	and everything should be fine! Various logging is also written to
> the
> 	WEB-INF/logs/cocoon.log file, using the org.apache.log.* classes
> 	recently added to Cocoon.
> 
> 	Well, if there any questions, problems, suggestions, etc, please let
> 	me know. 

Yes I have :) Does it make sense to combine all Selectors above into
one and use a syntax like

  <map:when test="parameter.myparm eq "foo" and session.myvar gt 3"/>

I mean can we prefix the context of the variable used to test (header,
parameter, session, context so far).

> 
> 	I have lots of questions though! - Are there other
> 	operators/types people would like to use ? Are there any functions
> 	people would like to use ? (eg. I thought about being able to test
> the
> 	length of a request parameter in a selector ?), etc. Do people want
> to
> 	compare floating point numbers internationally (ie. 0.00 in
> Australia,
> 	and 0,00 in Germany ?). Are the chosen english style operator
> 	names ok ? etc. What other kinds of selectors would be appropriate ?
> 	And then comes the subject of documentation ?? :-)
> 
> 	Ok, Well I'll leave it there for the moment. Look forward to
> responses.
> 
> 	Cheers,
> 
> 	Marcus

Giacomo

=====


__________________________________________________
Do You Yahoo!?
Yahoo! Shopping - Thousands of Stores. Millions of Products.
http://shopping.yahoo.com/

Mime
View raw message