fyi.. in my earlier message, I was *quoting* Craig's note.. everything
below here is what he said.. sorry I wasn't clear enough.. :)
Geeta

> You will want to register your view controller beans as a managed bean
> anyway, so that JSF will create them for you on demand.  But, for
> Shale to provide the services it does, it must know how to translate
> the "view id" --- something like "/logon.jsp" -- into the name of the
> corresponding managed bean.  That way, when you navigate to that page,
> Shale can precreate the bean and call the relevant event handlers.
>
> Thus, the managed bean name corresponding to "/logon.jsp" *must* be
> named "logon" for it to be recognized as a ViewController.  In your
> scenario, you left the name copied from the Use Cases example
> ("logon$profile"), which would be suitable for a page named
> "/logon/profile.jsp".


[EMAIL PROTECTED] wrote on 02/27/2007 12:20:08 AM:

> "Rahul Akolkar" <[EMAIL PROTECTED]> wrote on 02/26/2007 11:18:56
PM:
>
> >
> > About (1), if you're not using Spring, better off taking out all
> > Spring jars and the shale-spring jar from the application. (2) sounds
> > correct, and it might change further now that Tiles is a top level
> > project at Apache. Again, seems unrelated to the 403 bit.
> >
> > -Rahul
> >
> >
>
> Hi Rahul,
>
> Thanks for the reply. After a bit of trial and error I got tiles to
behave
> properly. (I did remove all references to Spring btw). But for now I have
> also had to remove *all* config info from my chain-config.xml; else I
can't
> get rid of my 403 error. I have shelved the problem for right now so I
can
> move on.
>
> Anyway, so I at least got my app up and running. But I am having a
peculiar
> problem with just one of my jsps in that I cannot seem to hit the backing
> bean's prerender() or init() methods. I have tried changing the scope of
> the bean to no avail.
>
> So I went back to the usecases example to try to see if anything has
> changed since the last time and saw a peculiar thing. In
faces-config.xml,
> in the "Validate test" section, the backing bean name is "validate$test"
> and not "validator$test". According to a long ago post of Craig's:
> http://mail-archives.apache.org/mod_mbox/struts-user/200508.mbox/%
> [EMAIL PROTECTED]
>
> You will want to register your view controller beans as a managed bean
> anyway, so that JSF will create them for you on demand.  But, for
> Shale to provide the services it does, it must know how to translate
> the "view id" --- something like "/logon.jsp" -- into the name of the
> corresponding managed bean.  That way, when you navigate to that page,
> Shale can precreate the bean and call the relevant event handlers.
>
> Thus, the managed bean name corresponding to "/logon.jsp" *must* be
> named "logon" for it to be recognized as a ViewController.  In your
> scenario, you left the name copied from the Use Cases example
> ("logon$profile"), which would be suitable for a page named
> "/logon/profile.jsp".
>
> Has this requirement been changed in the current Shale? More importantly
> are new requirements in place now? I looked through the docs for
> ViewController and didnt see anything.. but I may not be looking in the
> right places..
>
> ----------------------------------------
>
> My whole problem is that my breakpoints in my backing beans in init() and
> prerender() are not getting hit. My particular situation is this:
>
> 1. My faces-config.xml has this:
> <managed-bean>
>       <managed-bean-name>worklist</managed-bean-name>
>       <managed-bean-class>
>             com.intellicare.webshark.action.workflow.WorkListManagerBean
>       </managed-bean-class>
>       <managed-bean-scope>request</managed-bean-scope>
>       <managed-property>
>             <property-name>nextAssignmentHome1</property-name>
>                   <value>#{worklist$nextAssignmentHome1}</value>
>             </managed-property>
> </managed-bean>
>
> and my WorkListmanagerBean has private AssignmentBean1
nextAssignmentHome1;
> with the appropraite getters and setters. When i step through my code, in
> one of my "action" methods of WorkListmanagerBean I see that
> nextAssignmentHome1 is not null (as it should be) and I set some values
> here. At the end of my method I forward to "nextAssignmentHome1".
>
> 2. faces-config also has:
> <managed-bean>
>       <managed-bean-name>
>             worklist$nextAssignmentHome1
>       </managed-bean-name>
>       <managed-bean-class>
>             com.intellicare.webshark.action.workflow.AssignmentBean1
>       </managed-bean-class>
>       <managed-bean-scope>session</managed-bean-scope>
> </managed-bean>
>
> and <navigation-rule>
>       <from-view-id>*</from-view-id>
>             <navigation-case>
>                   <from-outcome>nextAssignmentHome1</from-outcome>
>
> <to-view-id>/worklist/nextAssignmentHome1.jsp</to-view-id>
>             </navigation-case>
> etc.
>
> Can you spot anything off? Because I step through the code in my worklist
> bean, I set attributes for the nextAssignmentHome1 backing bean. However,
> when I step through AssignmentBean1, everything I set in my worklist bean
> has been reset to default (null) values! (:( I even changed the above
code
> to use instead: AssignmentBean1 assignmentBean = (AssignmentBean1)
> getBean(Constants.ASSIGNMENT_BEAN1); (and removed the managed bean
property
> set in faces-config. xml but it made no differnece, my init() and
> prerender() are just *not* getting hit..(:(.. All this was working
> perfectly with my earlier version of Shale, btw...
>
>  I have been fighting with this upgrade since Friday and am ready to give
> it up.. though that is such a shame since I really feel I am *this*
> close..(:(
>
> Anyway, once again thanks for your help!
> Geeta
>
>
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>

Reply via email to