In an earlier post, Craig responded to a question by saying "Personally,
I consider putting view controllers in session scope to be a pretty bad
idea, and would
lean towards making this a restriction. (Putting non-view-controller
backing beans in session scope to save state across sessions is fine.)"
(The whole post is included below if you're interested)
This makes sense if a ViewController is our in-memory object
representation of a page, since a page only lasts for one request.
Well, I was looking at the Shale samples and in the rolodex example, the
ViewController (backing bean) for the rolodex is stored in session
scope.
<managed-bean>
<description>
View controller for the JSP view rolodex usecase
</description>
<managed-bean-name>rolodex</managed-bean-name>
<managed-bean-class>
org.apache.shale.usecases.rolodex.Rolodex
</managed-bean-class>
<managed-bean-scope>session</managed-bean-scope>
</managed-bean>
I understand that samples don't have to reflect best-practices, but I'm
curious as to what the best-practice would be.
Should your ViewController object be in request scope, and get injected
with a non-view-Controller that could live in any scope. The
non-view-Controller can have model objects injected into it. This way
the ViewController can handle all view related methods, and pass through
to the non-view-Controller for business methods which then get passed on
to the model objects.
Should your ViewController object live in request scope, and just get
variously scoped model objects injected, and after that just work as
both a View and non-view Controller.
Shoud you do something else completely different from either of those
two scenarios?
JB
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig
McClanahan
Sent: Tuesday, June 20, 2006 1:03 AM
To: Struts Users Mailing List
Subject: Re: [shale] Problems with View controller
On 6/19/06, Marty Phee <[EMAIL PROTECTED]> wrote:
>
> Ok, I've got most everything working. Combination of things mostly me
> not know how to configure everything.
>
> There is a problem though if you use tiger and subview. Only init()
> will be called if the bean is marked session. If you mark it request
> init and destroy will be called. The problem is in
> org.apache.shale.component.SubView. Not really a problem per-say, but
> tiger needs to implement something for subviews.
Hmm ... I'll bet it's not just subviews ... I'll bet any ViewController
you put in session scope will have the same problem. Personally, I
consider putting view controllers in session scope to be a pretty bad
idea, and would
lean towards making this a restriction. (Putting non-view-controller
backing beans in session scope to save state across sessions is fine.)
It ends up failling here after I set the id to a valid managed (by
> tiger) bean that has the @View anotation. Since it's trying to cast
> it to a ViewController it fails.
What bit of code is trying to cast it? If you are talking about the
ViewControllerCallbacks implementation, that gets specifically replaced
by a Tiger version that uses reflection to call the method marked with
an annotation instead, when you add shale-tiger.jar to your webapp
After I added extends
> AbstractViewController all the events were filed. Like wise if I
> didn't use tiger it worked fine.
Those caess make sense, because even the Tiger version will recognize
beans that implement the ViewController interface ... essentially it
just pretends that the four callback methods were annotated.
// Construct and initialize a new ViewController, if any is
associated
> String expr = "#{" + name + "}";
> try {
> vc = (ViewController) context.getApplication().
> createValueBinding(expr).getValue(context);
> if (vc == null) {
> log.debug(messages.getMessage("subview.noBean",
> new Object[] { getId()
}));
> return null;
> }
Where specifically is this code? If it's in the subview handler, that
will definitely have problems with the Tiger stuff, and will need to be
updated.
Craig
Craig McClanahan wrote:
> > On 6/19/06, Marty Phee <[EMAIL PROTECTED]> wrote:
> >>
> >> I'm using: shale, tiger, tiles.
> >
> >
> > Nothing like trying *all* the new stuff all at once :-).
> >
> > How recent is the Shale build you are using? I ask because there
> > were recent (after 1.0.2) changes in how init and destroy get called
> > such
> that
> > they should *always* happen. To cause the other callbacks to occur,
> > you'll need to use <s:subview> tags around your <tiles:insert> tags.
> > Also, I haven't tested this particular combination, so if that fails
> > on a
> current
> > build, then it's a bug we'll need to take a look at.
> >
> > Craig
> >
> > I have a layout with one of the tiles being AdminContent.jsp.
> >> <!-- Doc index page description -->
> >> <definition name="/admin/AdminMain"
> >> path="/admin/layouts/mainLayout.jsp">
> >> <put name="header" value="/admin/tiles/header.jsp" />
> >> <put name="menu" value="/admin/tiles/MainMenu.jsp" />
> >> <put name="monitor" value="/admin/tiles/DSLMonitor.jsp" />
> >> <put name="content" value="/admin/tiles/AdminContent.jsp"
/>
> >> <put name="messages" value="/admin/tiles/Messages.jsp" />
> >> </definition>
> >>
> >> I have a backing bean bean.AdminContent which is also declared as a
> >> @View.
> >> @Bean(name="AdminContent", scope= Scope.SESSION) @View public class
> >> AdminContent {
> >> @Init public void init(){
> >> System.out.println("Init called");
> >>
> >> }
> >>
> >> @Prerender public void preRender()
> >> {
> >> System.out.println("Prerender");
> >> }
> >>
> >> @Destroy public void destroy()
> >> {
> >> System.out.println("Destroy");
> >> }
> >>
> >> @Preprocess public void preprocess()
> >> {
> >> System.out.println("Preprocess");
> >> }
> >>
> >>
> >> init() is getting called, but none of the other methods are
> >> (destroy, prerender, preprocess). When I do submits the bean is
> >> being populated fine and the callback works as expected.
> >>
> >>
> >> JSP: AdminContent.jsp
> >> <f:view>
> >> .
> >> .
> >> .
> >> <h:form>
> >> <table border="0"
> >> cellpadding="0" cellspacing="0">
> >> <tr>
> >> <td>
> >>
> >> <h:outputText
> >> value="Status: #{AdminContent.status}"/>
> >> </td>
> >> </tr>
> >> <tr>
> >> <td>
> >>
> <h:commandButton
> >> value="Start" action="#{adminContentHandler.saveAdminContent}" />
> >> <br>
> >>
> <h:commandButton
> >> value="Stop" action="#{adminContentHandler.saveAdminContent}" />
> >> <br>
> >>
> <h:commandButton
> >> value="Restart" action="#{adminContentHandler.saveAdminContent}" />
> >> </td>
> >> </tr>
> >> </table>
> >> </h:form> .
> >> .
> >> .
> >> </f:view>
> >>
> >> Layout: mainLayout.jsp
> >> <html>
> >> <head>
> >> <title>My Title</title>
> >> <link rel="stylesheet" type="text/css"
> >> href="/styles/vaAdmin.css"/>
> >> </head>
> >> <table border="0" cellpadding="0" height="100%" width="100%">
> >> <tr valign="top" >
> >> <td colspan="4">
> >> <tiles:insert attribute="header"
></tiles:insert>
> >> </td>
> >> </tr>
> >> <TR height="100%">
> >> <TD height="100%" width="15%" valign="top">
> >> <tiles:insert attribute="menu" ></tiles:insert>
> >> </TD>
> >> <TD width="65%" valign="top">
> >> <tiles:insert attribute="content"
></tiles:insert>
> >> </TD>
> >> <td width="20%" valign="top">
> >> <tiles:insert attribute="monitor"
></tiles:insert>
> >> </td>
> >> </tr>
> >> <tr valign="bottom">
> >> <td colspan="4" valign="top" >
> >> <tiles:insert attribute="messages"
></tiles:insert>
> >> </td>
> >> </tr>
> >> </table>
> >> </html>
> >>
> >>
> >>
> >> -------------------------------------------------------------------
> >> -- To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
