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?

- 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>

- 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.).

- 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?

If anyone can spread some light on these issues, I'd greatly appreciate it. 
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]>

Reply via email to