While going through my inbox I found this post...
...did anybody comment on this? If so I must have missed
that. Anyway, I think this proposal sounds reasonable...
Other comments?
--
Torsten
<snip/>
> 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>
> </map:select>
>
> to:
>
> if (myselector.select("this"...)) {
> ...
> } else if (myselector.select("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 = myselector.select(...);
>
> 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">...</>
> <map:otherwise>...</>
> </map:select>
>
> 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">...</>
> <map:otherwise>...</>
> </map:select>>
> </map:act>
>
> ie. combination of action and then selector, which I find to be
> a hack.
<snip/>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
