On 11/17/05, Garner, Shawn <[EMAIL PROTECTED]> wrote:
>
> I was looking at the struts faces example app and was wondering what the
> difference between the managed-bean and a form-bean was?
>
> I would think managed-beans would replace the need for form beans.


In general JSF programming, this is definitely correct ... managed beans are
a generalization of a Struts ActionForm, because they can be created on
demand at *any* time, not just by the act of submitting a form. Additional
generalizations:

* Managed beans can be of any class that has a public zero-args
constructor, not just subclasses of ActionForm.

* The properties of a managed bean can be initialized from literal
values or expressions in the faces-config.xml file, which might have
the side effect of creating additional beans. In effect, managed beans
are a basic dependency injection framework.

* Managed beans can be stored in any scope, or no scope at all,
versus just request or session scope for form beans.

* JSF's extension APIs let you transparently integrate other DI
frameworks (such as Spring) if you prefer them.

They are both beans but I was wondering how they are different in this
> architecture?


The design center for the struts-faces integration library is to allow you
to migrate your Struts view tier (JSP pages using Struts HTML tags, to JSP
pages using JSF components), with minimal changes to any of your Java
classes. Thus, the architecture allows you to continue using ActionForm
beans if you want.

Once you have completed the view tier migration, you'd most often want to
migrate the back end code as well, switching away from the restrictions of
form beans to the more generalized capabilities of managed beans -- but you
can do that at your own pace; you're not forced to migrate to managed beans
at the same time.

Shawn


Craig

Reply via email to