Dakota Jack wrote:
The view "controller" is not a controller in the Web-MVC sense and is
completely misleading, in my opinion, Mark. So part of this just may be
who's dog is in the hunt?
The point of the tool-based and VB analogy is that JSF tries to hide from
you, to do it for you, what other frameworks, like Struts, demand you know.
This allows quick turnaround and allows the construction of tools. This was
the charter for JSF. It is not a bug, it is deliberate. So, if this
confuses a new person, at least it has the value of being accurate as hell.
Well in my opinion JSF is much closer to the traditional way of doing
user interfaces than Struts, most people who have a clear experience in
user interfaces probably grasp the page centric approach of JSF easier
than the enforced action centric approach of Struts.
The terms, component, Page, Backend Controller are visible in one way or
the other in most rich client uis, also the validation on component
levels, the events etc...
In one way the comparison to Visual Basic is valid, because it brings a
rich client approach to the page->action->page mix of html and struts.
But from a functionality point of view JSF is sort of Struts 2.0 because
the more you dive into the framework them more you see that basically
everything (sans client side validation) of Struts still is there, but
so much more and everything especially configurationwise a tad more
cleaned up and with less xml.
So, if you want to use programmers with little experience and train them to
use the inevitable tools, just like with the community college VB junkies,
JSF is a good alternative. If you think a smaller cadre of thinking and
knowing engineers is the way to go, like cs graduates who know Java or C++,
then Struts is the way to go.
I do not think so, JSF is definitely not graspable by the first
community, because once you get out of the we have a set of component
level, things become more complicated than the usual visual tool user
can handle.
Struts never even tries to reach the visual level.
But does not cover all areas jsf covers. If you dive deeper into JSF
you can find that JSF partially was derived from Struts, but adds lots
of stuff to the mix.
But one thing for me in JSF is heavens sent, that you finally have a
huge number of components and a clear and good event system, the rest is
up to the taste, after all you cannot really change within the
boundaries of HTML how html behaves.
If you go the enforced model controller route or the non enforce model
view controller or model view route is up to personal taste.
JSF is not more page centric than Struts. JSF is page centric. Struts is
not page centric.
Something has to take JSF from page to page, and this is called a "view
controller" due to an unfortunate naming of a pattern having to do with
views, pages. This, again, is NOT a controller as you find in Struts.
Actually it is the nav handler :-), it just happens that you have the
controller logic in the backend beans and thus you get an "action
controller" that way.
What you probably mean is the view handler, but that is something
entirely different, and nav and view handlers are replaceable parts.
I personally would find my VB and C++ the most helpful. I always find
heuristics the most helpful, unless you want to get bogged down in
irrelevant detail, like "view controller". This is essentially the sort of
choice you are making. VB is a tool based, dumbed down, "language". JSF is
a tool based, dumbed down "framework". C++ is a full blown language.
Struts is a full blown framework.
I assume you never had a serious look at jsf, judging a framework by its
tools and never look beyound is always bad ;-)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
