Hi Ulrich,
I've found that over time, my sitemap testing has moved from focusing
on technical nitty gritty to focusing on concepts. Its a subtle
difference, but it makes conditional checking for your examples below
a little easier.
On Wed, 11 Jul 2001, Ulrich Mayring wrote:
> But how to do that conditionally then? Here's some code from one of my
> Cocoon1 apps:
>
> String param = request.getParameter("param");
> if (param == null||param.equals(""))
> response.sendRedirect("error.xml?apperror=1526");
You could do this in the sitemap testing the value of param for null
or "", and then using map:redirect-to.
<map:select type="param-test">
<map:when test="">
<map:redirect-to uri="error.xml?apperror=1526"/>
</map:when>
<!-- and so on -->
</map:select>
All you need there is a selector which will bring the request
parameter 'param' into scope for testing. Not to difficult to write (I
posted an interpreter based param selector to the list
october/november last year).
Generically speaking, you can do this kind of test/redirect with any
resource. Selectors can test anything.
Note, for parameter testing, I might not follow this approach - if you
need to test 10 form values for example. (as you can see, you'll end
up with an extensive sitemap containing too much detail - this is what
I was describing above, with my shift from describing technical detail
in sitemap pipelines, to concepts).
I would write a validation action.
<map:match ...>
<map:act type="validate"/>
<!-- and so on, assuming validation works -->
</map:match>
And use the Redirector element of the action API. Then your code above
goes into the validation action you write (almost exactly as it is
above), with the call being redirector.redirect(..); instead of
response.sendRedirect(..).
What you've done above will work, you just need to relocate the code
out of your xsp page, into an action class. Optionally, you could
also write a c2 generic or application specific validator class to
reuse code. (there's already a generic formvalidatoraction in the c2
source now).
Now, be aware there is a trade off here, sending a redirect from
within an action will mean you'll have control flow code outside of
the sitemap.
An alternative is to return a value from your action to the sitemap
for testing and then sitemap redirection.
<map:match ...>
<map:act type="validate"/>
<map:select type="validatortester">
<map:when test="invalid">
<map:redirect-to uri="..."/>
</map:when>
<map:otherwise>
<!-- and so on, assuming validation works -->
</map:otherwise>
<map:select>
</map:match>
In this case you'll need to write an action and a selector.
As you can see, the trade off here is in sitemap size, complexity
and readability. I am not baised to either, as I see benefits in both
approaches. The other developers might see this differently. The
choice is up to you.
> This redirects the user to an error page, if his input is not ok. I have
> lines like this in most of my XSP pages. Another example:
>
> if (status.startsWith("active")) {
> // Send notification mail
> response.sendRedirect("mail/NOTIFY_CUSTOMER.xml");
> else if (status.startsWith("begin")) {
> // Send error fax
> response.sendRedirect("fax/NOTIFY_CUSTOMER.xml");
>
> Doing a 'grep -r sendRedirect * | wc -l' on the above app I get 104.
> Does this mean I have to write 104 actions? Or is it possible to write a
> generic redirect action
If they are all totally different sendRedirect tests, used only once
in individual xsp pages, you may need to write a comprehensive set of
actions. But I expect in reality it will be a lot less than 104.
(without seeing your application. :-) )
Hope that helps.
Cheers,
Marcus
--
.....
,,$$$$$$$$$, Marcus Crafter
;$' '$$$$: Computer Systems Engineer
$: $$$$: Open Software Associates GmbH
$ o_)$$$: 82-84 Mainzer Landstrasse
;$, _/\ &&:' 60327 Frankfurt Germany
' /( &&&
\_&&&&' Email : [EMAIL PROTECTED]
&&&&. Business Hours : +49 69 9757 200
&&&&&&&:
---------------------------------------------------------------------
Please check that your question has not already been answered in the
FAQ before posting. <http://xml.apache.org/cocoon/faqs.html>
To unsubscribe, e-mail: <[EMAIL PROTECTED]>
For additional commands, e-mail: <[EMAIL PROTECTED]>
