Hi!
> Hello,
>
> I'm currently evaluating Cocoon 2 for the next version of our site (we
> deployed with Cocoon 1.8 earlier this year). I spent a couple of days
> porting the old application to Cocoon 2 as a test, and I've run into a few
> issues that I'm hoping you can help me sort out. Some of these things may
> be pure ignorance, so forgive me if I overlooked something obvious. I did,
> however, read all of the docs, and I have a lot of experience with Cocoon
1.8.
>
> Here are my comments/issues/etc:
>
> - Sending action results to an XSP. I know I'm missing something here, but
> I couldn't figure out how to do this (without using the request
logicsheet).
> The old code had a home-grown Action framework, so I created a proxy
action
> to convert between our framework and Cocoon's. Here's what the action did
> in its act() method:
>
> DispatchableActionAdapter oldAction =
> (DispatchableActionAdapter)ActionFactory.getAction(actionName);
> Object obj = oldAction.handle(req);
> if (obj != null)
> {
> HashMap map = new HashMap();
> String documentName = oldAction.getNormalReturnDocument();
> documentName = documentName.substring(0,
> documentName.lastIndexOf("."));
> map.put("document", documentName);
> SystemLog.trace("saved [document] as " + documentName);
> map.put(ActionConstants.ACTION_RESPONSE, obj);
> SystemLog.trace("saved value as " +
> ActionConstants.ACTION_RESPONSE);
>
> return map;
> }
>
> The old XSP pages had statements like the following inside <xsp:logic>
tags:
>
> ArrayList skillList =
> (ArrayList)request.getAttribute(ActionConstants.ACTION_RESPONSE);
>
> However, this always returned null (I tried many different variations). I
> could access the responses fine from the sitemap, but I had no luck with
> XSP. What am I missing?
I are missing this lines in your act() method:
...
Request request =
(Request) objectModel.get(Constants.REQUEST_OBJECT);
request.setAttribute(ActionConstants.ACTION_RESPONSE, obj);
The return map is used in sitemap processing, but that does not mean that a
request attribute will be added too. If you need your 'obj' only in sitemap
then there's no need to add a request attribute.
>
> - Having trouble getting nested sitemap matcher variables (e.g. "{1}")
> within an action tag. Example:
>
> <map:match pattern="content/*.xsp">
>
> <map:act type="wrapper">
> <map:parameter name="oldAction" value="authentication"/>
>
> <map:generate type="serverpages" src="content/{1}.xsp"/>
> <map:transform src="styles/{1}.xsl"/>
> <map:serialize/>
> </map:act>
>
> <!-- something was wrong, redirect to login page -->
> <map:redirect-to uri="../login_error"/>
> </map:match>
>
> When this executes, the {1} values aren't substituted at all (it tries to
> find "content/.xsp"). However, the following works because the variables
> aren't nested within the action:
>
> <map:match pattern="content/*.xsp">
>
> <map:generate type="serverpages" src="content/{1}.xsp"/>
> <map:transform src="styles/{1}.xsl"/>
>
> <map:act type="wrapper">
> <map:parameter name="oldAction" value="authentication"/>
> <map:serialize/>
> </map:act>
>
> <!-- something was wrong, redirect to login page -->
> <map:redirect-to uri="../login_error"/>
> </map:match>
>
Try this:
<map:generate type="serverpages" src="content/{../1}.xsp"/>
<map:transform src="styles/{../1}.xsl"/>
Hope this will help.
> - There seems to be an XSP bug that often generates the following code:
>
> this.characters("
> ");
>
> This seems to happen whenever there's an extra line after an <xsp:logic>
> statement:
>
> <xsp:logic>
> ...
> </xsp:logic>
>
> <info>
> <title>Site Guide</title>
> <userType><xsp:expr>userType</xsp:expr></userType>
> </info>
> <navigation/>
> <content/>
> ...
>
> Remove the line, and it works fine:
>
> <xsp:logic>
> ...
> </xsp:logic>
> <info>
> <title>Site Guide</title>
> <userType><xsp:expr>userType</xsp:expr></userType>
> </info>
> <navigation/>
> <content/>
> ...
>
> - No default (hard-coded) error handler. One of the things that really
> throws me off with Cocoon 2 is the lack of some default error handling. It
> doesn't seem like the <map:handle-errors> section gets called for a lot of
> exceptions that can occur in the pipeline. I found myself constantly
> looking at the logs to figure out what went wrong, which was difficult to
> get used to, since 1.8 always displayed some sort of error.
>
> - No default output. It's disconcerting to see a blank page, because it
can
> mean many things (i.e. an exception in an action, no mapping defined for
> the requested url, etc.).
Strange... There was a hard coded error page. Maybe there's an error in your
own page?
>
> - Background compilation. This is a great thing for production use, but
> during development I want instant gratification :-). Is there a way to
just
> make the request block until the compilation is complete?
Compilation settings for sitemap you can change in cocoon.xconf file.
>
> If anyone can spread some light on these issues, I'd greatly appreciate
it.
Welcome
> I'm quite impressed with the architecture of this release, btw.
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> Kito D. Mann
> Chief Architect
> [EMAIL PROTECTED]
> Grow.Net
> (212)625-1914 x105
---------------------------------------------------------------------
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]>
