Hairy generics question

[Lew]

If you choose to think of JSF as MVC - let's say because you aren't
interested in breaking out MVP as a derivative of MVC - then that's fine
too. I have no problem with that, it's what I actually do myself,
because most folks haven't heard of MVP anyway so why confuse them? I
would like it though if people who "knowledgeably" classify JSF as being
MVC could identify what the Controller is in JSF: I've run across more
people than not who either think it's the FacesServlet or just don't know.

JSF is MVC if you think of a backing bean as a (generally) per-screen
controller. It coordinates the purely view-oriented actions of the XHTML (JSP
being out of fashion now) with the POJO logic types that implement the model.

But a JSF application does not have a simple, single-controller MVC structure,
as people usually think of the architecture. It is similar to Swing, as
described in
http://en.wikipedia.org/wiki/Model–view–controller
(in a section lacking citations):
"An MVC application may be a collection of model/view/controller triads, each
responsible for a different UI element."

Your distinctions between MVP and MVC are useful, as is your reticence to
enforce the distinction.

The difficulty isn't that things are or aren't different, it's that the term
"MVC" is rather broad. It applies to just about any architecture that
comprises triads of view, model and some coordinating third element. (What the
hell is the difference between a "controller" and a "presenter", really? I've
always called it a "dispatcher".) We need a common terminology to distinguish
the various flavors.

As for people thinking the FacesServlet is the controller, they can be excused
if they believe the pundits. There are articles about JSF out there that say so.
<http://www.javaworld.com/javaworld/jw-07-2004/jw-0719-jsf.html?page=3>
for example.

So even where the terminology is consistent, the taxonomy is in dispute.

I suppose that at that height, the FacesServlet is the dispatcher and backing
beans the model, but they're the interaction model, not the business model.

As a programmer I don't face the FacesServlet. (You see what I did there?)
It's black box and so I dismiss it. The part I design, the part that I model,
is the application-level MVC pattern. That's why I think of each
POJO-screen-bean triad as an MVC unit. (MSD in my universe -
dispatcher-screen-model.) (I did that on purpose. Which leg of the tripod is
the most important, after all?)

I think we're too late to peg MVC to any one flavor, but it makes sense to
reserve MVP for the specific variant that it describes. I would go along with
that.

 

[Arne Vajhøj]

JSF is MVC if you think of a backing bean as a (generally) per-screen
controller.

It usually have functionality besides controller, so it is not just
a controller.

And clean MVC should have something that is just a controller.

Arne

 

[Arne Vajhøj]

I've just read the original Taligent, Inc. PDF on what MVP is, and it
looks like its little more than a clarification of MVC, with some new
concepts pulled out.

MVC and MVP is certainly closely related.

I would tend to say that MVC is slightly more "input centric"
and MVP is slightly more "output centric".

Arne

 

[Lew]

It usually have functionality besides controller, so it is not just
a controller.

And clean MVC should have something that is just a controller.

QWhat non-controller functionality goes in a backing bean?

I've done a fair amount of JSF work, and the backing beans I've done work just
like a controller - they coordinate screen events and delegate fulfillment to
model objects.

I'm not sure where one exactly draws the line between "logic" and "control",
so perhaps I'm not writing controllers, but your statement is too vague for me
to discern if that's so. Please clarify.

 

[Arved Sandstrom]

QWhat non-controller functionality goes in a backing bean?

I've done a fair amount of JSF work, and the backing beans I've done
work just like a controller - they coordinate screen events and delegate
fulfillment to model objects.

I'm not sure where one exactly draws the line between "logic" and
"control", so perhaps I'm not writing controllers, but your statement is
too vague for me to discern if that's so. Please clarify.

Looking at typical backing beans is a good place to start. A
bog-standard backing bean will have fields, the accessors for those
fields, and action methods.

Everything is up for debate, here, that's the point of this subthread.
I'll sweeten the pot by suggesting that action methods belong to the
Controller, if we are sticking to an MVC picture.

Maybe we'll leave listeners aside for a moment, although some of them
will certainly figure in this discussion.

Now, what about the fields and accessors? As I see it a lot of these are
part of the View, or the presentation state. I think it's seriously
unfortunate that one JSF lifecycle phase is called "UPDATE_MODEL_VALUES"
because to me, as a starting point, the model acted upon here is a
*presentation* model, not the Model in MVC.

This is my initial contribution. I think a typical backing bean is
likely to include bits of both V and C in MVC.

AHS

 

[Arne Vajhøj]

QWhat non-controller functionality goes in a backing bean?

I've done a fair amount of JSF work, and the backing beans I've done
work just like a controller - they coordinate screen events and delegate
fulfillment to model objects.

Typical a backing bean will also contain data.

In Struts you have the form bean / dyna bean with the data
and the action class being the controller.

In JSF the form data and the controller got mixed up a bit.

Arne

 

[Lew]

Typical a backing bean will also contain data.

In Struts you have the form bean / dyna bean with the data
and the action class being the controller.

In JSF the form data and the controller got mixed up a bit.

You can mix up data and action in Struts, too. Doesn't reflect on the
framework so much as the practitioner.

Arved's points resonated with me also. Even the Model 2 MVC style has screen
field awareness in the C; has to, in order to properly dispatch logic. Arved's
comment pertains, "Everything is up for debate, here, that's the point of this
subthread."

Whether "JSF is MVC" now sounds like a style issue as I integrate your
information. I'm in the habit of writing JSF backing beans more like a
controller and less like a model-aware component, and your experience reveals
a style with less rigorous a separation. I suggest that while JSF admits of a
non-MVC approach, as you say, one should yet design along MVC lines.

Just having the MVC pattern in mind, with keen understanding of separation of
concerns and other principles, one will tend to a good architecture however
fuzzy the particular label for it. As always, there are no absolute rules,
only firm, supportive principles.

 

[Arne Vajhøj]

You can mix up data and action in Struts, too. Doesn't reflect on the
framework so much as the practitioner.

Struts forces you to specify a form bean and an action class, so
unless you pick the same class then they will be separate.

In JSF there is no such separation.

So there is a big difference in the framework.

Arved's points resonated with me also. Even the Model 2 MVC style has
screen field awareness in the C; has to, in order to properly dispatch
logic.

There is a difference between knowing how to process data and
storing the data.

Whether "JSF is MVC" now sounds like a style issue as I integrate your
information. I'm in the habit of writing JSF backing beans more like a
controller and less like a model-aware component, and your experience
reveals a style with less rigorous a separation. I suggest that while
JSF admits of a non-MVC approach, as you say, one should yet design
along MVC lines.

How do you write a managed bean with only control without form fields
properties?

Arne

 

[Arved Sandstrom]

On 3/10/2012 12:47 PM, Lew wrote:

[ SNIP ]

How do you write a managed bean with only control without form fields
properties?

Arne

You may have lost sight of the forest for the trees, Arne. It's
quite simple, you just write your form EL such that "properties" (input
texts, labels, checkboxes etc) point at one managed bean, and form
actions point at another managed bean.

The ICEDFaces dev team makes these distinctions (see
http://blog.icesoft.org/blojsom/blo...between-different-kinds-of-JSF-managed-beans/)

Using their names we see that the one bean I mention above is what they
call a "backing managed bean", and the other is a "controller managed bean".

They also assign - and this jibes with my classification of JSF bits
according to MVC - JSF actionListener and valueChangeListener methods to
the "backing bean" category.

Most people don't split forms JSF code like this - *I* don't - but there
is some merit to thinking about the distinction even if it's only
logical. If one did want to actually code like this, it can be done
cleanly in JSF 2.0 with @ManagedProperty or in CDI with @Inject -
provided that one is cognizant of scopes you can @Inject your backing
bean into the controller bean, and so your action method has clean
access to the backing bean form "properties" via accessors.

AHS

 

[Arne Vajhøj]

On 3/10/2012 12:47 PM, Lew wrote:

[ SNIP ]

How do you write a managed bean with only control without form fields
properties?

You may have lost sight of the forest for the trees, Arne.

That happens frequently.

It's
quite simple, you just write your form EL such that "properties" (input
texts, labels, checkboxes etc) point at one managed bean, and form
actions point at another managed bean.

But then you would need to send over the first managed beans as argument
to the second managed bean.

I don't like that.

If one did want to actually code like this, it can be done
cleanly in JSF 2.0 with @ManagedProperty or in CDI with @Inject -
provided that one is cognizant of scopes you can @Inject your backing
bean into the controller bean, and so your action method has clean
access to the backing bean form "properties" via accessors.

Ah.

That would make it useful.

The ICEDFaces dev team makes these distinctions (see
http://blog.icesoft.org/blojsom/blo...between-different-kinds-of-JSF-managed-beans/)

Using their names we see that the one bean I mention above is what they
call a "backing managed bean", and the other is a "controller managed bean".

If one want true MVC in JSF that is probably the way to go.

Most people don't split forms JSF code like this - *I* don't -

Neither does the Java EE tutorial or a common book like Core JSF.

Arne