RE: Storing MaverickContext in request causing issues with portal processes

"Eric Kreiser" <[email protected]> Wed, 7 May 2003 11:24:12 -0400
Newsgroups	gmane.comp.web.maverick.general
Message-ID	<[email protected]>
The issue is not efficiency in chaining or not chaining - the issue is is it correct to assume that if two controllers are processed using the same under lying httpservletrequest that they are being chained - and the answer is no.

-----Original Message-----
From: Calvin Ling [mailto:[email protected]]
Sent: Tuesday, May 06, 2003 1:21 PM
To: [email protected]
Subject: RE: [Mav-user] Storing MaverickContext in request causing issues with portal processes


Knowing the chaining behavior, it should be simple to disregard the forwarded model etc.  isn't it more efficient to chain it than not?

Eric Kreiser <[email protected]> wrote: 

I have a jsp page similar to the following.  It is a basic portal page.  With Maverick2.1.2 - only the first (page1.m) is rendered completely.  The other 3 result in the model XML being handed back to this controlling jsp.  If I take the attribute check out of org.infohazard.maverick.Dispatcher, the entire process completes successfully and correctly (just as it did under 2.1.1).  The problem stems from the fact that in this scenario, technically all 4 pages will be built against the same underlying httprequest object, but for me they are all separate and distinct processes.  Your 2.1.2 product erroneously assumes that if the same request object is used the user must want to chain controllers.  Your change will cause problems anytime the RequestDispatcher forward(), or include() methods are used with multiple maverick controllers.! 
 
<%@ page contentType="text/html; charset=UTF-8" %>
<%@ taglib uri="sitemesh-decorator" prefix="decorator" %>
<%@ taglib uri="sitemesh-page" prefix="page" %>
<html>
    <head>
        <title>Test</title>
    </head>
    <body>
        <table>
            <tr>
             <td width="33%" ALIGN="left" VALIGN="top">
                 <page:applyDecorator page="/page1.m" name="panel" encoding="UTF-8"/>
                    <br>
                    <page:applyDecorator page="! /page2.m" name="panel" encoding="UTF-8"/>
                </td>
                <td width="<%=secondcolumnwidth%>%" ALIGN="left" VALIGN="top">
                    <page:applyDecorator page="/page3.m" name="panel" encoding="UTF-8"/>
                </td>
                <td width="<%=thirdcolumnwidth%>%" ALIGN="left" VALIGN="top">
                    <page:applyDecorator page="/page4.m" name="panel" encoding="UTF-8"/>
 !                </td>
            </tr>
        </table>
    </body>
</html>

-----Original Message-----
From: Schnitzer, Jeff [mailto:[email protected]]
Sent: Monday, May 05, 2003 8:50 PM
To: [email protected]
Cc: Opensymphony-Sitemesh (E-mail)
Subject: RE: [Mav-user] Storing MaverickContext in request causing issues with portal processes



This was done to facilitate chaining maverick commands together, so one command can forward to another and each one can take a shot at modifying the model.  Here is the relevant discussion:

 

http://www.mail-archive.com/mav-user%40lists.sourceforge.net/msg00493.html

 

In what way does this break SiteMesh?  I'm open to discussion as to why we should change back to the old behavior.

 

J2FF

 

-----Original Message-----
From: Eric Kreiser [mailto:[email protected]] 
Sent: Thursday, May 01, 2003 5:48 AM
To: Maverick-User (E-mail)
Cc: Opensymphony-Sitemesh (E-mail)
Subject: [Mav-user] Storing MaverickContext in request causing issues with portal processes

 

I just tried to make the switch from version 2.1.1 to 2.1.2 and ran into the following issue.

 

The direct issue is that I have a portal screen which uses Sitemesh to pull in all the content configured to show to the user.  All the content is rendered thru maverick controllers.  The problem now is that under 2.1.2 only the first controller called is rendered to completion, all the rest, resulting in the XML being dumped to the screen.  The root of the issue is the way org.infohazard.maverick.Dispatcher sets the MaverickContext in a request attribute, and if present reuses it.  Since the same request is used and passed along to each controller, the first one sets the MaverickContext and the others use the context from the first.

 

Exactly what situation was trying to be solved by this change.



  _____  

Do you Yahoo!?
The New  <http://us.rd.yahoo.com/search/mailsig/*http://search.yahoo.com> Yahoo! Search - Faster. Easier. Bingo.