You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by gr...@intellicare.com on 2005/08/23 21:10:38 UTC
[Shale/JSF] Extending AbstractViewController doesn't automagically give me
access to init() etc.
Hi all:
I have been struggling all day to understand the features provided by
Shale. Here's what i have so far:
I have a new skeletal project with just the jars in usecases.war in my
WEB-INF/lib and 2 trivial jsps. index.jsp which forwards to logon.faces.
logon.jsp is a usual logon page with un/pw stuff.
I have a LogonAction class (using org.apache.shale.usecases.profile
.LogonActions) which extends AbstractViewController. From the API docs for
ViewController:
"having your backing beans implement this interface (typically by
extending AbstractViewController) will receive the benefit of the extra
services described by this interface, all of which will be provided
automatically."
So I took that to mean that Shale has provided me with this nice
AbstractViewController so all I gotta do is exend it...? So, in my
LogonAction I implemented init(), prerender() and preprocess() methods
with trivial code. However, none of these methods are ever getting called.
(The LogonAction.logon method however *is* getting called...)
There's more stuff in the docs about:
To be useful, the ViewController must be plugged into the application
lifecycle through a custom JSF ViewHandler, like the ShaleViewHandler"
So am I supposed to plug the LogonAction to ShaleViewHandler? How do I do
that? (I didn't understand the docs here - and I can explain why but this
is already a very long message so will desist..)
Plus there's stuff about "registering" my ViewController bean. But I had
rather hoped that extending AbstractViewController would mean I wouldn't
have to do that explicitly..?
I have looked at the logon stuff in faces-confing.xml in usecases.war but
am afraid have drawn a blank..Kinda stuck at this point..(:(
Can someone please help me see what i am missing? Many thanks in advance!
Geeta
p.s. my faces-config.xml looks like this:
<managed-bean>
<managed-bean-name>profile$logon</managed-bean-name>
<managed-bean-class>
com.intellicare.shaleNShark.logon.LogonAction
</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
<managed-property>
<description>
Session scope attribute key under which the User instance for a
logged on user is stored.
</description>
<display-name>User Key</display-name>
<property-name>userKey</property-name>
<property-class>java.lang.String</property-class>
<value>user</value>
</managed-property>
</managed-bean>
<navigation-rule>
<from-view-id>*</from-view-id>
<navigation-case>
<from-outcome>authenticated</from-outcome>
<to-view-id>/success.jsp</to-view-id>
</navigation-case>
<navigation-case>
<from-outcome>unauthenticated</from-outcome>
<to-view-id>/failure.jsp</to-view-id>
</navigation-case>
</navigation-rule>
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give
me access to init() etc.
Posted by gr...@intellicare.com.
Craig McClanahan <cr...@gmail.com> wrote on 08/23/2005 04:38:23 PM:
> Yep :-).
>
> > Well, not exactly. Now my logon method isn't getting hit..(:(.
> > Instead I have nasty errors like this:
> >
> > javax.servlet.ServletException: Error testing property 'username' in
bean
> > of type null
>
> This means that one of your value binding expressions that includes
> "username" is likely to still be messed up. When you changed the
> managed bean name from "profile$logon" to "logon", you'll need to
> update *all* the expressions that used to say "profile$logon" ... not
> just one of them.
Right on as usual. That was just the problem..:)
> Craig
Geeta
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give me access to init() etc.
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/23/05, gramani@intellicare.com <gr...@intellicare.com> wrote:
> Craig McClanahan <cr...@gmail.com> wrote on 08/23/2005 03:27:18 PM:
>
> > Change this to "logon" and update any value binding expressions that
> > use it as well.
> >
>
> Craig, as ever many thanks for your detailed reply!
>
> ok, so I changed my faces.config.xml and now my manged bean looks like
> this:
>
> <managed-bean>
> <managed-bean-name>logon</managed-bean-name>
> <managed-bean-class>
> etc..
>
> Plus my logon.jsp has now:
> <h:commandButton id="logon"
> action="#{logon.logon}"
> value="#{messages['label.logon']}"/>
>
> That's right, I hope? (I had "profile$logon" instead of "logon.logon"
> before..
>
> Cleaned out my work directory, restarted tomcat, blah blah and now,...
> yeah!... I do hit the init(), prerender() and preprocess() methods! Cool,
> right?
Yep :-).
> Well, not exactly. Now my logon method isn't getting hit..(:(.
> Instead I have nasty errors like this:
>
> javax.servlet.ServletException: Error testing property 'username' in bean
> of type null
This means that one of your value binding expressions that includes
"username" is likely to still be messed up. When you changed the
managed bean name from "profile$logon" to "logon", you'll need to
update *all* the expressions that used to say "profile$logon" ... not
just one of them.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically
give me access to init() etc.
Posted by Rick Reumann <st...@reumann.net>.
Craig McClanahan wrote the following on 8/23/2005 4:47 PM:
>>Is it typical then to end up with several ManagedBean definitions for
>>the same backingBean but for different mappings?
>>
>
>
> Why would you need that? I typically use a 1:1 mapping between JSP
> pages and backing beans.
I guess that probably will be the case for most scenarios. It would take
too long to describe the last scenario on the project I just worked on,
but to break it down into a different analogy.. imagine if you had three
separate JSPs: dog.jsp, fish.jsp, cat.jsp. They were all unique enough
from a 'view' concept to make them separate pages. Yet, before you went
to each page you needed to set up some data in the form for that page.
Speaking in Struts terms, each page shared the same "AnimalForm" (even
though it could have been broken out into 3 separate ones). Also when
the form on each page submitted it only needed to submit to one
AnimalAction (no need for a fish, cat, dog action when essentially what
happened in each case was very similar). Processing on a save took place
like...
saveDispatchMethod(..) {
//bean utils copy animal form properties into an Animal object
//save
animalFactory.getAnimalService(animalType).save( animal );
}
Also there was a setUp() method that would be called before going to
fish.jsp, dog.jsp etc and it would set up the correct animal information
in the form.
So even though I had separate views (jsps), only one Action was needed
to handle all of them.
This became important as later on more 'animal' types might need to be
supported. In that case only a new view jsp might need to be added
(along with a couple of backend classes - service and dao) yet the
Struts controller didn't need to be touched. I didn't need to create a
new Action for each type of animal(view). Granted this isn't the typical
case but it might come up for others.
In relation to the 'employees' issue at hand, I was hoping to reuse the
same backing bean for "employees" and "employee." employees.jsp shows
the data grid and "employee.jsp" would be your typical edit/add form. I
see though that it would make more sense to break these up into two
different managed beans since the prerender for each is completely
different.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give me access to init() etc.
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/23/05, Rick Reumann <st...@reumann.net> wrote:
> Craig McClanahan wrote the following on 8/23/2005 4:10 PM:
>
> > The important principle is really pretty easy to articulate:
> >
> > IF you want your backing bean to implement ViewController
> > and get its event methods called, THEN the name of the
> > managed bean MUST conform to the mapping rules.
> >
> > That would mean, for a page named "/employee.jsp", then the managed
> > bean name (if you use the default mapper, which is recommended) MUST
> > be "employee", not "employeeBacking". Making that change would also
> > mean changing expressions that use "employeeBacking" now to use
> > "employee" instead, so you'd have:
> >
> > <h:dataTable value="#{employee.employees}" var="emp">
>
> Is it typical then to end up with several ManagedBean definitions for
> the same backingBean but for different mappings?
>
Why would you need that? I typically use a 1:1 mapping between JSP
pages and backing beans.
> In other words what if not just employee.jsp needed the "Employee"
> managed bean but also "employees.jsp", "employeeForm.jsp", "FooBar.jsp"
> all needed access to the managedBean? If all of them needed the
> prerender to fire off then I would think each of them would have to be
> created with separate managed bean definitions?
It might be helpful to distinguish different kinds of managed beans:
* Backing beans containing event handlers and data related
specifically to a particular page. This is what a ViewController
is in Shale. There will normally be exactly one such bean per page,
with (at least) an action method for each submit button that does
something different ("Save" versus "Cancel" for example).
* General purpose data beans that you define as managed beans
so you can leverage the dependency injection mechanism. The
names of these beans are arbitrary, and easy to share across pages.
(In apps built with Java Studio Creator, for example, we precreate
three beans like this -- one in each of request/session/application
scope -- as convenient places to pass data around). But you can
also stick your own objects into the appropriate scope whenever
you need to share. But these should be *data* or *business logic*
beans, not tied to JSF APIs. They are *not* "backing beans" by
the definition above.
Another way to look at things is to mentally translate from Struts 1.x
terms: a "backing bean" (or ViewController) is a combination of an
ActionForm and an Action. Or, more precisely, it's often a
combination of an ActionForm and a DispatchAction -- although the
multiple action methods is implemented by binding each component
individually, rather than calling a common execute() method that then
dispatches.
In general, then, each action method functionally corresponds to a
single Action.execute() method in Struts. And the best practices
about abstracting out your actual business logic into a separate tier
applies here as well -- call your DAO and business logic objects from
within the action method.
> Rick
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give me access to init() etc.
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/23/05, gramani@intellicare.com <gr...@intellicare.com> wrote:
> Craig McClanahan <cr...@gmail.com> wrote on 08/23/2005 06:33:35 PM:
> [snip the <soapbox>]
>
> Correct. And I have indeed coded for situations similar to your search
> example, for Struts apps in the past. What i mean is (continuing your
> example) my (Struts) action returned perhaps forwards for say "noMatch",
> "oneMatch" or "manyMatches". However, the forwards for that action in
> struts-config then had to have paths for something like noMatches.jsp,
> oneMatch.jsp, manyMatches.jsp. So the architect can indeed decide to
> change the "where to go next" piece without touching the action code by
> simply fixing struts-config.xml. And, as I understand it, we code the the
> Shale/JSF framework also similarly. The backing bean returns an outcome
> and the faces-config.xml maps the outcome to the view. So, I don't mean to
> sound impertinent or anything :), but really, you *do* in fact return an
> "outcome" in either case and "outcomes" are indeed about "what happened"
> and not "where to go next".. Except you *do* of course go somewhere next,
> and therefore have to code that information (in config files in either
> framework). So what am i missing? I mean, where's the difference between
> the Struts way and the Shale/JSF way?
>
Congratulations, you broke the code :-). All the things you learned
about good application design using Struts stil work.
> > > Ok, maybe you could have many different managed beans (I mean with
> > > different names) but all "pointing to the same class/bean?..
> > >
> >
> > It's not clear what you mean by "pointing" in this scenario.
>
> Well, just kind of a stupid way of doing things. ;) I meant that in
> faces-config.xml, we can have two <managed-bean> defintions, one with
> managed-bean-name as say page1 and the other as page2 but both having
> managed-bean-class as the same bean class say MyBeanClass. In that case,
> page1.jsp and page2.jsp would both share the same bean..(Would have to set
> the managed-bean-scope to session though I'd guess in order to share it
> across both pages..?) I imagine that would work.. but, yes, I understand
> you have said it isn't a good idea..:)
>
Yep :-).
Backing beans (or ViewControllers when you also use Shale) are view
tier things, just like form beans in Struts were intended to be (but
way to many people in the world use for other things too).
> > Yep, for all the standard reasons (this logic should be independent of
> > the web tier APIs, so it can be unit tested easily and reused in other
> > scenarios). And, you can optionally use the managed beans facility to
> > configure such objects and put them in the right scope (or use Spring,
> > or use JNDI lookups, or use either of the above transparently via
> > value binding expressions in Shale).
> >
> > The best practices here (separate business logic from presentation
> > logic) are exactly the same as they are for a Struts based app.
> >
>
> Yes, I think we shouldn't have a problem with that..;-)
>
> > Craig
>
> Once again, many thanks for your time!
> Geeta
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give
me access to init() etc.
Posted by gr...@intellicare.com.
Craig McClanahan <cr...@gmail.com> wrote on 08/23/2005 06:33:35 PM:
> <soapbox>
> But, I would caution you to avoid a mistake that lots of Struts users
> make as well -- think of an outcome (JSF) or an ActionForward (Struts)
> as a description that says "this is what happened", not "this is where
> to go next". Let's consider an example (applicabe to either
> technology) to show you what I mean.
>
> How many apps have you built that has a little search field to, for
> example, look up the customers that match the first few characters you
> type (yes, in today's world, you'd probably use an Ajax-ish code
> completion widget, but bear with me). If you think about it, the
> action that executes the lookup has three significant possible
> outcomes:
>
> * Zero matches were found
>
> * Exactly one match was found
>
> * More than one match was found
>
> A quick and dirty implementation would always present a table or list
> of the matches, allowing the user to select the customer they actually
> wanted. For that, you would only need one outcome. A more
> sophisticated UI, however, might want to do three different things:
>
> * In the zero matches case, go back to the query screen,
> perhaps adding a message like "I'm sorry, no customers matched
> your criteria. Please broaden your search criteria."
>
> * In the one match case, go directly to the customer details screen
> for that customer.
>
> * In the multiple matches case, list the options as before.
>
> I would advocate that the developer coding the lookup action should
> return outcomes like "No Matches", "One Match", and "Multiple
> Matches". It should be up to the application architect desgning the
> overall flow. And she should be able to change her mind about whether
> to go to one place or three, *without* changing the lookup action code
> at all.
>
> Outcomes are about "what happened", not about "where to go next".
> </soapbox>
>
Correct. And I have indeed coded for situations similar to your search
example, for Struts apps in the past. What i mean is (continuing your
example) my (Struts) action returned perhaps forwards for say "noMatch",
"oneMatch" or "manyMatches". However, the forwards for that action in
struts-config then had to have paths for something like noMatches.jsp,
oneMatch.jsp, manyMatches.jsp. So the architect can indeed decide to
change the "where to go next" piece without touching the action code by
simply fixing struts-config.xml. And, as I understand it, we code the the
Shale/JSF framework also similarly. The backing bean returns an outcome
and the faces-config.xml maps the outcome to the view. So, I don't mean to
sound impertinent or anything :), but really, you *do* in fact return an
"outcome" in either case and "outcomes" are indeed about "what happened"
and not "where to go next".. Except you *do* of course go somewhere next,
and therefore have to code that information (in config files in either
framework). So what am i missing? I mean, where's the difference between
the Struts way and the Shale/JSF way?
> > Ok, maybe you could have many different managed beans (I mean with
> > different names) but all "pointing to the same class/bean?..
> >
>
> It's not clear what you mean by "pointing" in this scenario.
Well, just kind of a stupid way of doing things. ;) I meant that in
faces-config.xml, we can have two <managed-bean> defintions, one with
managed-bean-name as say page1 and the other as page2 but both having
managed-bean-class as the same bean class say MyBeanClass. In that case,
page1.jsp and page2.jsp would both share the same bean..(Would have to set
the managed-bean-scope to session though I'd guess in order to share it
across both pages..?) I imagine that would work.. but, yes, I understand
you have said it isn't a good idea..:)
> Yep, for all the standard reasons (this logic should be independent of
> the web tier APIs, so it can be unit tested easily and reused in other
> scenarios). And, you can optionally use the managed beans facility to
> configure such objects and put them in the right scope (or use Spring,
> or use JNDI lookups, or use either of the above transparently via
> value binding expressions in Shale).
>
> The best practices here (separate business logic from presentation
> logic) are exactly the same as they are for a Struts based app.
>
Yes, I think we shouldn't have a problem with that..;-)
> Craig
Once again, many thanks for your time!
Geeta
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give me access to init() etc.
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/23/05, gramani@intellicare.com <gr...@intellicare.com> wrote:
> Rick Reumann <st...@reumann.net> wrote on 08/23/2005 04:53:35 PM:
>
> > If that's the case, though, I'd find that as a severe limitation of JSF.
>
> > In Struts my DispatchActions can be called from anywhere and there isn't
>
> > really a need for a tight coupling. "getEmployee" returns "success" and
> > any form or JSP can use this Action (assuming they also use the
> > ActionForm also).
Note that navigation rules *themselves* can be shared ... by virtue of
the fact that you can use wildcard expressions. So, you get the
benefits of global forwards in Struts too, so "success" goes the same
place no matter which action returns it.
> In JSF I keep wishing there was a way I can through in a "use this
> > managed bean" in the navigation rules - but I'm guessing that's because
> > I've been using Struts for so long. Hopefully this will all start to
> > "click" at some point.
> >
<soapbox>
But, I would caution you to avoid a mistake that lots of Struts users
make as well -- think of an outcome (JSF) or an ActionForward (Struts)
as a description that says "this is what happened", not "this is where
to go next". Let's consider an example (applicabe to either
technology) to show you what I mean.
How many apps have you built that has a little search field to, for
example, look up the customers that match the first few characters you
type (yes, in today's world, you'd probably use an Ajax-ish code
completion widget, but bear with me). If you think about it, the
action that executes the lookup has three significant possible
outcomes:
* Zero matches were found
* Exactly one match was found
* More than one match was found
A quick and dirty implementation would always present a table or list
of the matches, allowing the user to select the customer they actually
wanted. For that, you would only need one outcome. A more
sophisticated UI, however, might want to do three different things:
* In the zero matches case, go back to the query screen,
perhaps adding a message like "I'm sorry, no customers matched
your criteria. Please broaden your search criteria."
* In the one match case, go directly to the customer details screen
for that customer.
* In the multiple matches case, list the options as before.
I would advocate that the developer coding the lookup action should
return outcomes like "No Matches", "One Match", and "Multiple
Matches". It should be up to the application architect desgning the
overall flow. And she should be able to change her mind about whether
to go to one place or three, *without* changing the lookup action code
at all.
Outcomes are about "what happened", not about "where to go next".
</soapbox>
>
> ok, I'm probably being quite stupid here and should think this over a bit
> more.. but hey, what the hell..;)
>
> Ok, maybe you could have many different managed beans (I mean with
> different names) but all "pointing to the same class/bean?..
>
It's not clear what you mean by "pointing" in this scenario.
> Though perhaps (from Craig's earlier note), really we are supposed to
> think of backing beans as kind of very basic and specific to a page or
> something..
That is the correct viewpoint. The backing bean is (along with the
page itself) your view tier, and it interacts with model tier stuff
the same way you would do it in a Struts app.
> and thus not *have to* share it across many pages.
I would go one stronger, and say you should *not* share this kind of
bean -- although there is a subtle exception to that ... you can
compose your view out of multiple smaller pieces (either by using
<jsp:include> or Tiles). You'd want to have a backing bean *per Tile*
in this case, so the backing bean, plus its corresponding JSP, are
being reused. But they are a unit, and should be thought of that way.
> If you have
> logic in there which you have to share, then move it to another layer once
> removed perhaps..
Yep, for all the standard reasons (this logic should be independent of
the web tier APIs, so it can be unit tested easily and reused in other
scenarios). And, you can optionally use the managed beans facility to
configure such objects and put them in the right scope (or use Spring,
or use JNDI lookups, or use either of the above transparently via
value binding expressions in Shale).
The best practices here (separate business logic from presentation
logic) are exactly the same as they are for a Struts based app.
>
> But you are right, this isn't sinking in like it should..(:(
>
> > Rick
>
> Geeta
>
>
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give
me access to init() etc.
Posted by gr...@intellicare.com.
Rick Reumann <st...@reumann.net> wrote on 08/23/2005 04:53:35 PM:
> If that's the case, though, I'd find that as a severe limitation of JSF.
> In Struts my DispatchActions can be called from anywhere and there isn't
> really a need for a tight coupling. "getEmployee" returns "success" and
> any form or JSP can use this Action (assuming they also use the
> ActionForm also).
> In JSF I keep wishing there was a way I can through in a "use this
> managed bean" in the navigation rules - but I'm guessing that's because
> I've been using Struts for so long. Hopefully this will all start to
> "click" at some point.
>
ok, I'm probably being quite stupid here and should think this over a bit
more.. but hey, what the hell..;)
Ok, maybe you could have many different managed beans (I mean with
different names) but all "pointing to the same class/bean?..
Though perhaps (from Craig's earlier note), really we are supposed to
think of backing beans as kind of very basic and specific to a page or
something.. and thus not *have to* share it across many pages. If you have
logic in there which you have to share, then move it to another layer once
removed perhaps..
But you are right, this isn't sinking in like it should..(:(
> Rick
Geeta
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically
give me access to init() etc.
Posted by Rick Reumann <st...@reumann.net>.
gramani@intellicare.com wrote the following on 8/23/2005 4:39 PM:
> Funny, I was *just* thinking that! And then I figured it is because in the
> Struts world, we are typically used to thinking of a form bean as being
> shared by many jsps. But I think in the Faces world perhaps the backing
> bean and the jsp are supposed to be really tightly integrated..(almost the
> same (one) thing..?)
If that's the case, though, I'd find that as a severe limitation of JSF.
In Struts my DispatchActions can be called from anywhere and there isn't
really a need for a tight coupling. "getEmployee" returns "success" and
any form or JSP can use this Action (assuming they also use the
ActionForm also).
In JSF I keep wishing there was a way I can through in a "use this
managed bean" in the navigation rules - but I'm guessing that's because
I've been using Struts for so long. Hopefully this will all start to
"click" at some point.
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give
me access to init() etc.
Posted by gr...@intellicare.com.
Rick Reumann <st...@reumann.net> wrote on 08/23/2005 04:31:41 PM:
> Craig McClanahan wrote the following on 8/23/2005 4:10 PM:
>
> > The important principle is really pretty easy to articulate:
> >
> > IF you want your backing bean to implement ViewController
> > and get its event methods called, THEN the name of the
> > managed bean MUST conform to the mapping rules.
> >
> > That would mean, for a page named "/employee.jsp", then the managed
> > bean name (if you use the default mapper, which is recommended) MUST
> > be "employee", not "employeeBacking". Making that change would also
> > mean changing expressions that use "employeeBacking" now to use
> > "employee" instead, so you'd have:
> >
> > <h:dataTable value="#{employee.employees}" var="emp">
>
> Is it typical then to end up with several ManagedBean definitions for
> the same backingBean but for different mappings?
Funny, I was *just* thinking that! And then I figured it is because in the
Struts world, we are typically used to thinking of a form bean as being
shared by many jsps. But I think in the Faces world perhaps the backing
bean and the jsp are supposed to be really tightly integrated..(almost the
same (one) thing..?)
>
> In other words what if not just employee.jsp needed the "Employee"
> managed bean but also "employees.jsp", "employeeForm.jsp", "FooBar.jsp"
> all needed access to the managedBean? If all of them needed the
> prerender to fire off then I would think each of them would have to be
> created with separate managed bean definitions?
>
> --
> Rick
Geeta
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically
give me access to init() etc.
Posted by Rick Reumann <st...@reumann.net>.
Craig McClanahan wrote the following on 8/23/2005 4:10 PM:
> The important principle is really pretty easy to articulate:
>
> IF you want your backing bean to implement ViewController
> and get its event methods called, THEN the name of the
> managed bean MUST conform to the mapping rules.
>
> That would mean, for a page named "/employee.jsp", then the managed
> bean name (if you use the default mapper, which is recommended) MUST
> be "employee", not "employeeBacking". Making that change would also
> mean changing expressions that use "employeeBacking" now to use
> "employee" instead, so you'd have:
>
> <h:dataTable value="#{employee.employees}" var="emp">
Is it typical then to end up with several ManagedBean definitions for
the same backingBean but for different mappings?
In other words what if not just employee.jsp needed the "Employee"
managed bean but also "employees.jsp", "employeeForm.jsp", "FooBar.jsp"
all needed access to the managedBean? If all of them needed the
prerender to fire off then I would think each of them would have to be
created with separate managed bean definitions?
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give me access to init() etc.
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/23/05, Rick Reumann <st...@reumann.net> wrote:
> Craig McClanahan wrote the following on 8/23/2005 3:27 PM:
>
> > 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".
>
> Ok, this a total noob question, but it still has me confused. For
> example you'll see the use of a DataTable..
>
> <h:dataTable value="#{tableData.names}" var="name">
> ...
>
> this above would mean that I need a managed bean named "tableData"
> configured. Ok I'm fine there.
Yes, you'd need that, but not because of Shale ... that's pure JSF level stuff.
>
> But now I see that you were a mentioning you need managed beans with
> names that match a URL pattern? If so this is very confusing. Would you
> then need to duplicate the managed bean definitions?
>
> For example (and this in relation to my question from yesterday), what
> if if I had a forward (or even someone typing in the url directly) that
> went to a page...
>
> employees.jsp
>
> and on that page, I needed to used a dataTable to show the list of
> employees. I currently have a managed bean definiton:
>
> <managed-bean>
> <managed-bean-name>employeeBacking</managed-bean-name>
> <managed-bean-class>net.reumann.EmployeeBacking</managed-bean-class>
> <managed-bean-scope>request</managed-bean-scope>
> </managed-bean>
>
> I then planned to use it on the employees.jsp with a dataTable:
>
> <h:dataTable value="#{employeeBacking.employees}" var="emp">
>
> EmployeeBacking extends AbstractViewController
>
> and I have a prerender() in there that just throws in some sample data
> into my employees List in the EmployeeBacking class.
>
> I'm too am having difficulty getting the prerender to fire:(
>
> Is the problem that at I need another managed-bean definition with the
> name "employees" attached to the same "EmployeeBacking" object?
>
> TIA for any help.
>
The important principle is really pretty easy to articulate:
IF you want your backing bean to implement ViewController
and get its event methods called, THEN the name of the
managed bean MUST conform to the mapping rules.
That would mean, for a page named "/employee.jsp", then the managed
bean name (if you use the default mapper, which is recommended) MUST
be "employee", not "employeeBacking". Making that change would also
mean changing expressions that use "employeeBacking" now to use
"employee" instead, so you'd have:
<h:dataTable value="#{employee.employees}" var="emp">
since you're changing the name of the managed bean.
If you don't need your backing bean to implement ViewController, then
Shale imposes no restrictions ... pure JSF code continues to work.
But you would not get the extra event calling services in that case.
Craig
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically
give me access to init() etc.
Posted by Rick Reumann <st...@reumann.net>.
Craig McClanahan wrote the following on 8/23/2005 3:27 PM:
> 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".
Ok, this a total noob question, but it still has me confused. For
example you'll see the use of a DataTable..
<h:dataTable value="#{tableData.names}" var="name">
...
this above would mean that I need a managed bean named "tableData"
configured. Ok I'm fine there.
But now I see that you were a mentioning you need managed beans with
names that match a URL pattern? If so this is very confusing. Would you
then need to duplicate the managed bean definitions?
For example (and this in relation to my question from yesterday), what
if if I had a forward (or even someone typing in the url directly) that
went to a page...
employees.jsp
and on that page, I needed to used a dataTable to show the list of
employees. I currently have a managed bean definiton:
<managed-bean>
<managed-bean-name>employeeBacking</managed-bean-name>
<managed-bean-class>net.reumann.EmployeeBacking</managed-bean-class>
<managed-bean-scope>request</managed-bean-scope>
</managed-bean>
I then planned to use it on the employees.jsp with a dataTable:
<h:dataTable value="#{employeeBacking.employees}" var="emp">
EmployeeBacking extends AbstractViewController
and I have a prerender() in there that just throws in some sample data
into my employees List in the EmployeeBacking class.
I'm too am having difficulty getting the prerender to fire:(
Is the problem that at I need another managed-bean definition with the
name "employees" attached to the same "EmployeeBacking" object?
TIA for any help.
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give me access to init() etc.
Posted by Larry Meadors <la...@gmail.com>.
I did not want to be greedy, but OK.
;-)
Larry
On 8/23/05, gramani@intellicare.com <gr...@intellicare.com> wrote:
> Larry Meadors <la...@gmail.com> wrote on 08/23/2005 03:59:50 PM:
>
> > On 8/23/05, Craig McClanahan <cr...@gmail.com> wrote:
> > >
> > > Hmm ... sounds like a "shale-blank" app (corresponding to
> > > struts-blank) might be a good idea ...
> >
> > +1!
> >
> > :-D
> >
>
> +..like.. a gazillion..? ;)
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give
me access to init() etc.
Posted by gr...@intellicare.com.
Larry Meadors <la...@gmail.com> wrote on 08/23/2005 03:59:50 PM:
> On 8/23/05, Craig McClanahan <cr...@gmail.com> wrote:
> >
> > Hmm ... sounds like a "shale-blank" app (corresponding to
> > struts-blank) might be a good idea ...
>
> +1!
>
> :-D
>
+..like.. a gazillion..? ;)
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give me access to init() etc.
Posted by Larry Meadors <la...@gmail.com>.
On 8/23/05, Craig McClanahan <cr...@gmail.com> wrote:
>
> Hmm ... sounds like a "shale-blank" app (corresponding to
> struts-blank) might be a good idea ...
+1!
:-D
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give me access to init() etc.
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/23/05, Rick Reumann <st...@reumann.net> wrote:
> Craig McClanahan wrote the following on 8/23/2005 3:27 PM:
>
> > And yes, the javadocs do need to be clearer about the need for this.
> > I'll add some more information to the ViewController class docs to
> > explain it.
>
> I'm still really confused by all of it as well. Actually what would be
> great I think is a VERY simple example of the ViewController
> implementation being used in a sample application. I know I'm supposed
> to read java docs, but I love learning from example apps:)
>
Hmm ... sounds like a "shale-blank" app (corresponding to
struts-blank) might be a good idea ...
Craig
> --
> Rick
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically
give me access to init() etc.
Posted by Rick Reumann <st...@reumann.net>.
Craig McClanahan wrote the following on 8/23/2005 3:27 PM:
> And yes, the javadocs do need to be clearer about the need for this.
> I'll add some more information to the ViewController class docs to
> explain it.
I'm still really confused by all of it as well. Actually what would be
great I think is a VERY simple example of the ViewController
implementation being used in a sample application. I know I'm supposed
to read java docs, but I love learning from example apps:)
--
Rick
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give
me access to init() etc.
Posted by gr...@intellicare.com.
uh, oh....sorry!! Was being a dufus again... Please ignore my earlier
note. Had another profile$logon stuck in the username and pw fields in my
jsp.. Sorry! Everything's working just fine now..:)
Thanks a lot for the help, Craig! (and especially the explanation..:)
Geeta
gramani@intellicare.com wrote on 08/23/2005 04:13:17 PM:
> Instead I have nasty errors like this:
>
> javax.servlet.ServletException: Error testing property 'username' in
bean
> of type null
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give
me access to init() etc.
Posted by gr...@intellicare.com.
Craig McClanahan <cr...@gmail.com> wrote on 08/23/2005 03:27:18 PM:
> Change this to "logon" and update any value binding expressions that
> use it as well.
>
Craig, as ever many thanks for your detailed reply!
ok, so I changed my faces.config.xml and now my manged bean looks like
this:
<managed-bean>
<managed-bean-name>logon</managed-bean-name>
<managed-bean-class>
etc..
Plus my logon.jsp has now:
<h:commandButton id="logon"
action="#{logon.logon}"
value="#{messages['label.logon']}"/>
That's right, I hope? (I had "profile$logon" instead of "logon.logon"
before..
Cleaned out my work directory, restarted tomcat, blah blah and now,...
yeah!... I do hit the init(), prerender() and preprocess() methods! Cool,
right? Well, not exactly. Now my logon method isn't getting hit..(:(.
Instead I have nasty errors like this:
javax.servlet.ServletException: Error testing property 'username' in bean
of type null
javax.faces.webapp.FacesServlet.service(FacesServlet.java:209)
org.apache.shale.faces.InvokeCommand.execute(InvokeCommand.java:40)
org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:166)
org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationFilter.java:252)
root cause
javax.faces.el.PropertyNotFoundException: Error testing property
'username' in bean of type null
com.sun.faces.el.PropertyResolverImpl.getType(PropertyResolverImpl.java:342)
org.apache.shale.faces.ShalePropertyResolver.getType(ShalePropertyResolver.java:206)
com.sun.faces.el.impl.ArraySuffix.getType(ArraySuffix.java:240)
com.sun.faces.el.impl.ComplexValue.getType(ComplexValue.java:208)
com.sun.faces.el.ValueBindingImpl.getType(ValueBindingImpl.java:345)
com.sun.faces.renderkit.html_basic.HtmlBasicInputRenderer.getConvertedValue(HtmlBasicInputRenderer.java:111)
javax.faces.component.UIInput.getConvertedValue(UIInput.java:713)
javax.faces.component.UIInput.validate(UIInput.java:638)
javax.faces.component.UIInput.executeValidate(UIInput.java:849)
javax.faces.component.UIInput.processValidators(UIInput.java:412)
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:912)
javax.faces.component.UIForm.processValidators(UIForm.java:170)
javax.faces.component.UIComponentBase.processValidators(UIComponentBase.java:912)
javax.faces.component.UIViewRoot.processValidators(UIViewRoot.java:342)
com.sun.faces.lifecycle.ProcessValidationsPhase.execute(ProcessValidationsPhase.java:78)
com.sun.faces.lifecycle.LifecycleImpl.phase(LifecycleImpl.java:200)
com.sun.faces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:90)
javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
org.apache.shale.faces.InvokeCommand.execute(InvokeCommand.java:40)
org.apache.commons.chain.impl.ChainBase.execute(ChainBase.java:166)
org.apache.shale.faces.ShaleApplicationFilter.doFilter(ShaleApplicationFilter.java:252)
So somehow my backing bean is now null; isn't being found any more or
something..?
> Craig
Thanks again!
Geeta
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give me access to init() etc.
Posted by Craig McClanahan <cr...@gmail.com>.
On 8/23/05, gramani@intellicare.com <gr...@intellicare.com> wrote:
> Hi all:
>
> I have been struggling all day to understand the features provided by
> Shale. Here's what i have so far:
>
> I have a new skeletal project with just the jars in usecases.war in my
> WEB-INF/lib and 2 trivial jsps. index.jsp which forwards to logon.faces.
> logon.jsp is a usual logon page with un/pw stuff.
>
> I have a LogonAction class (using org.apache.shale.usecases.profile
> .LogonActions) which extends AbstractViewController. From the API docs for
> ViewController:
>
> "having your backing beans implement this interface (typically by
> extending AbstractViewController) will receive the benefit of the extra
> services described by this interface, all of which will be provided
> automatically."
>
I can see that "automatically" needs to be qualified by explaining
what "registered" means below.
> So I took that to mean that Shale has provided me with this nice
> AbstractViewController so all I gotta do is exend it...? So, in my
> LogonAction I implemented init(), prerender() and preprocess() methods
> with trivial code. However, none of these methods are ever getting called.
> (The LogonAction.logon method however *is* getting called...)
>
> There's more stuff in the docs about:
> To be useful, the ViewController must be plugged into the application
> lifecycle through a custom JSF ViewHandler, like the ShaleViewHandler"
>
> So am I supposed to plug the LogonAction to ShaleViewHandler? How do I do
> that? (I didn't understand the docs here - and I can explain why but this
> is already a very long message so will desist..)
>
> Plus there's stuff about "registering" my ViewController bean. But I had
> rather hoped that extending AbstractViewController would mean I wouldn't
> have to do that explicitly..?
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.
There is an API defining a mapper (ViewControllerMapper), and a
default implementation (DefaultViewControllerMapper) that applies the
following rules to transform a viewId into a managed bean name:
* Strip any leading slash ("/") character
* Strip any trailing extension (such as ".jsp")
* Convert any remaining instance of a slash ("/") into a dollar sign ("$")
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".
>
> I have looked at the logon stuff in faces-confing.xml in usecases.war but
> am afraid have drawn a blank..Kinda stuck at this point..(:(
>
> Can someone please help me see what i am missing? Many thanks in advance!
> Geeta
>
> p.s. my faces-config.xml looks like this:
>
> <managed-bean>
> <managed-bean-name>profile$logon</managed-bean-name>
Change this to "logon" and update any value binding expressions that
use it as well.
> <managed-bean-class>
> com.intellicare.shaleNShark.logon.LogonAction
> </managed-bean-class>
> <managed-bean-scope>request</managed-bean-scope>
> <managed-property>
> <description>
> Session scope attribute key under which the User instance for a
> logged on user is stored.
> </description>
> <display-name>User Key</display-name>
> <property-name>userKey</property-name>
> <property-class>java.lang.String</property-class>
> <value>user</value>
> </managed-property>
> </managed-bean>
>
> <navigation-rule>
> <from-view-id>*</from-view-id>
> <navigation-case>
> <from-outcome>authenticated</from-outcome>
> <to-view-id>/success.jsp</to-view-id>
> </navigation-case>
> <navigation-case>
> <from-outcome>unauthenticated</from-outcome>
> <to-view-id>/failure.jsp</to-view-id>
> </navigation-case>
> </navigation-rule>
>
>
And yes, the javadocs do need to be clearer about the need for this.
I'll add some more information to the ViewController class docs to
explain it.
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: [Shale/JSF] Extending AbstractViewController doesn't automagically give
me access to init() etc.
Posted by gr...@intellicare.com.
gramani@intellicare.com wrote on 08/23/2005 03:10:38 PM:
>
> I have a LogonAction class (using org.apache.shale.usecases.profile
> .LogonActions) which extends AbstractViewController. From the API docs
for
> ViewController:
I mean:
I have a LogonAction class (using org.apache.shale.usecases.profile
.LogonActions as a prototype) which extends AbstractViewController.
Thanks!
Geeta