cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marcus Crafter <>
Subject Proposal: new style selector
Date Fri, 15 Mar 2002 12:33:01 GMT
Hi All,

	Hope all is well.

	Sylvain and I have recently had a discussion about the current
	selector implementation. Here's the first email from the


Hi Sylvain!

	Hope all is well mate.

	I remember a while back (>6 months) on cocoon-dev we discussed the
	semantics of map:select and it's current implementation.
	I remember you comments were similar to mine, and I'm
	trying to catch up with where this discussion went (if
	anywhere), as I've been off in project land for the past few

	My current (perhaps naive) opinion is that map:select is implemented
	wrong, and causes confusion among new cocoon application developers.

	The current implementation converts:

	<map:select type="myselector">
	 <map:when test="this">...</map:when>
	 <map:when test="that">...</map:when>


	if ("this"...)) {
	} else if ("that"...)) {

	This seems to be contrary to the semantics the xml implies (and
	can cause unwanted behaviour) :

	I think many might expect generated java code to behave like:

	Object result =;

	if (result.equals("this")) {
	} else if (result.equals("that")) {

	more like a expanded switch statement.

	ie. the test case is done only once, and its return value is
	checked multiple times. Not only is this better performance
	wise, but prevents unwanted behaviour. eg:

	I found this out when writing a login selector.

	I had something like:

	<map:select type="login">
	  <map:when test="permitted">...</>
	  <map:when test="denied">...</>

	which in practice tried to log denied users in 2 times!

	This means one has to do something like:

	<map:act type="login"/>
	  <map:select type="userstatus">
	    <map:when test="permitted">...</>
	    <map:when test="denied">...</>

	ie. combination of action and then selector, which I find to be
	a hack.

	What do you think ? Has this already been covered on cocoon-dev in
	recent times ?




	After some thinking we came up with an idea to create 
	an extended selector interface which supports switch-style semantics
	rather than if-if-else semantics.

	The newer interface supports switch-style semantics by allowing
	a developer to create a 'testable' context before any of the
	<map:when> tests have been done. This context can then be used in
	select() to see if the current test yield a true value.

	The newer interface looks like:

public interface ContextualizableSelector extends Selector, ThreadSafe
	Object getSelectorContext(Map objectModel, Parameters parameters);
	boolean select(String expression, Object selectorContext);

	There's an Abstract class to support the older style:

public abstract class AbstractContextualizableSelector extends AbstractLoggable
	implements ContextualizableSelector
	public boolean select(
		String expr, Map objectModel, Parameters params
            return select(expr, getSelectorContext(objectModel, params));

	A sample implementation would be like:

public class RequestParameterSelector extends AbstractContextualizableSelector
	implements Configurable
	public Object getSelectorContext(Map objectModel, Parameters params)
	  String name = params.getParameter("parameter-name", this.defaultName);
	  return ObjectModelHelper.getRequest(objectModel).getParameter(name);

	public boolean select(String expression, Object selectorContext)
	  return selectorContext.equals(expression);

	Ok, it's a simple example, but for selectors that calculate more
	complex conditionals, or do some thing like attempt to log in a
	user for example, the getSelectorContext(...) would give them a
	huge saving.

	The current files use Contextualizable as the prefix which we're
	not so happy with as a name as it might confuse people with
	avalon's context or the cocoon environment context. If anyone has a
	better idea please let us know. So far the only alternative name has
	been SwitchStyleSelector (?)

	I've put together some diffs which are attached (updated
	sitemap.xsl, interfaces and abstract class, and a modified 
	RequestParameterSelector as a sample). We'd be interested in your



     ,,$$$$$$$$$,      Marcus Crafter
    ;$'      '$$$$:    Computer Systems Engineer
    $:         $$$$:   ManageSoft GmbH
     $       o_)$$$:   82-84 Mainzer Landstrasse
     ;$,    _/\ &&:'   60327 Frankfurt Germany
       '     /( &&&

View raw message