[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [tamie] Exit question
Suppose you have a scriplet that generates an XML effect. Maybe it adds two values from events that it catches and puts them into a total elemet, like this:
<scriplet>
<total>
<var name="total1">
<catch>
<match
condition="content/order[@customer='1']/@total"/>
</catch>
</var>
<if condition="$total1 lt 0">
<exit/>
</if>
<var name="total2">
<catch>
<match
condition="content/order[@customer='2']/@total"/>
</catch>
</var>
<if condition="$total2 lt 0">
<exit/>
</if>
<eval expr="$total1 +
$total2"/>
</total>
</scriplet>
Everything is fine as long as both totals are greater than 0. But if either of the exit conditions are met, what is the effect of the scriplet?
I see three options:
1) The effect is anything that was produced up to when the exit was encountered. In this case, that would be an empty total element.
2) The effect is nothing at all.
<JD> Interesting problem. I think it all hinges on what are the rules to generate effects:
(a) if the rules are:
rule 1: if a scriplet does not generate a well-formed xml (or exits before doing so) then its effect is nil (or "empty").
rule 2: a scriplet can only generate a well-formed xml effect. Meaning if scriplet A has the tag <total>, and calls scriplet B that has the closing tag </total>, then that is still not correct as Scriplet B violates this rule, and by ripple effect Scriplet A also violates the rule (as the effect of B would be nil).
Your solution (2) is the thing to do according to these rules. But if the rule is:
rule 3: a scriplet has no understanding of the xml semantics of its effect: it just outputs anything that is not etsm-namespaced.
Then I guess there is yet another option: just produce an incomplete <total> fragment, that would fail validation.
3) We allow the exit instruction to be a container for other instructions. When an exit is encountered, its effect becomes the effect of the scriplet. For example,
<if condition="$total2 lt 0">
<exit>
<error>Total must be greater than or equal to
zero</error>
</exit>
</if>
At this point, I like option 3.
<JD> I am also in favor of the <exit> being able to produce an effect, otherwise there is no hope of getting any meaningful effect out of an "exiting" scriplet, since a brutal exit is almost sure to break any xml effect that was being prepared, as in your example. Now, after thinking about it, I think it is OK to say that the exit effect becomes THE effect of the scriplet.
Indeed, that does not prevent the developer to combine regular effect and a convenient usage of <exit>:
Consider the first scriplet that would not work according to your suggestion (because the total effect would "loose" the container tag <myapp:results>):
But the following rewriting would work fine. Note that the "exit" must NOT bubble up, for this to work, whic is the default bubbling option (it would not work if we called S2 as: <call scriplet="S2" bubblexit="true" > )
- Chuck
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]