myfaces-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Apache Wiki <wikidi...@apache.org>
Subject [Myfaces Wiki] Update of "JSF_and_MVC" by LeonardoUribe
Date Thu, 04 Aug 2011 19:03:13 GMT
Dear Wiki user,

You have subscribed to a wiki page or wiki category on "Myfaces Wiki" for change notification.

The "JSF_and_MVC" page has been changed by LeonardoUribe:
http://wiki.apache.org/myfaces/JSF_and_MVC?action=diff&rev1=4&rev2=5

+ See the updated page here:
- Over the last decade or so, the development of applications with graphical user interfaces
has pretty much standardised. Whether you are developing with Gnome, KDE, MFC, !VisualBasic,
Delphi, or any similar library the process is the same:
-  * a tree of widgets is built, either by code or by loading a configuration file
-  * callbacks are attached to the widgets
-  * the GUI framework is left to render and manage the user interface.
  
- When the user activates a widget (clicks a button, chooses a menu option, etc) the appropriate
callback is invoked. This callback inspects the requested action, and may choose to report
an error, or to update some kind of data-structure according to the user input. Then control
is either returned to the UI framework with the same set of widgets, or a new set of widgets
(a new "screen" is built).
+ https://cwiki.apache.org/confluence/display/MYFACES/JSF+and+MVC
  
- The data-structure here is the "model"; it may be a model of a building, of an economy,
of a text-document, etc. The logic which decides whether to update the model or report an
error, and whether to redisplay the same set of widgets (same screen) or a different set (new
screen) is the "controller". And the widgets themselves (which may have custom drawing logic)
are the "view".
- 
- This approach has been vastly successful in systems where all the processing is on one physical
computer system. However in our internet-connected world, accessing remote systems in interactive
ways is becoming more and more common. Having to deploy applications onto client systems is
becoming more and more clumsy.
- 
- One solution is the Java !WebStart approach, where client logic is dynamically downloaded.
The client can then be implemented much like a traditional MVC application, with the addition
of communication back to the original host. However downloading logic to the client computer
is not generally popular; it requires significant computer power and memory on the client
side, and a large startup delay as the logic is transferred.
- 
- JSF instead is a different way to bring the successful MVC programming approach to the internet.
It is designed to assume that the client has some software capable of rendering a reasonable
range of graphical widgets, and of transmitting information back to the server about changes
in the state of those widgets. JSF does not assume, however, that it can download any kind
of logic to the remote system other than a basic description of the screen layout. Of course
there is a widely-spread application that fits the description of a JSF client perfectly:
the Web Browser.
- 
- Like the previous MVC frameworks (Gnome, KDE, MFC, etc) JSF is based around defining a tree
of widgets ("components" in JSF terminology), where some of these components have callbacks
associated with them. JSF ensures that when data is received back from the remote client the
appropriate callbacks are invoked, without (in most cases) user code having to deal with things
like HTML forms or urls. Instead, controller code simply responds to events, updates data-models,
and then builds an appropriate view to render the new application state.
- 
- In practice, JSF component trees (widget trees) are almost always defined via a "template
file", and the most popular template file formats happen to be JSP and XHTML files. Purists
will limit themselves to defining only widgets in such files, but many people also take the
opportunity to encode fragments of traditional HTML or XHTML in such files, and JSF implementations
traditionally merge the two to generate the output that is actually sent to the remote client.
- 
- You will of course have noticed that while the effect is similar to older web-application
frameworks like Apache Struts, the approach is somewhat different. The HTML and Web are abstracted
away to a great extent. This allows a number of nice features, like being able to simply change
configuration to render HTML, XHTML, WML, and potentially things like PDF or Mozilla-XUL.
- 
- Another nice feature that results from this design is that it is easy to add more types
of components (widgets). Simply add a library into the classpath, update your views to reference
some of these new components, and if necessary attach callbacks to handle the actions that
these components can trigger. The !MyFaces Tomahawk, Trinidad and Tobago libraries are component
collections that can be used in exactly this way to enhance your JSF applications, and there
are more libraries available from many sources.
- 
- One of the issues that people notice when moving from more html-centric frameworks to JSF
is that there is some loss of control over exactly what urls are generated, what appears in
the query parameters, etc. Part of this is due to handing over of control of these aspects
to a framework rather than directly managing it; other parts are due to the fact that JSF
is still a reasonably young technology and still has a few rough edges. And partly it is due
to the fact that JSF is optimized for very interactive applications; it can do things that
are extremely complex to do with other approaches, but does not always perform quite as elegantly
in the simpler cases.
- 

Mime
View raw message