RE: Storing MaverickContext in request causing issues with portal processes
Calvin Ling <[email protected]>
| Newsgroups | gmane.comp.web.maverick.general |
|---|---|
| Message-ID | <[email protected]> |
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:@font-face { font-family: Tahoma;}@page Section1 {size: 8.5in 11.0in; margin: 1.0in 1.25in 1.0in 1.25in; }P.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"}LI.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"}DIV.MsoNormal { FONT-SIZE: 12pt; MARGIN: 0in 0in 0pt; FONT-FAMILY: "Times New Roman"}A:link { COLOR: blue; TEXT-DECORATION: underline}SPAN.MsoHyperlink { COLOR: blue; TEXT-DECORATION: underline}A:visited { COLOR: purple; TEXT-DECORATION: underline}SPAN.MsoHyperlinkFollowed { COLOR: purple; TEXT-DECORATION: underline}SPAN.EmailStyle17 { COLOR: navy; FONT-FAMILY: Arial}DIV.Section1 { page: Section1}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.in fohazard.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? Im 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 Yahoo! Search - Faster. Easier. Bingo.