On Apr 2, 2005 8:38 AM, Erik Weber <[EMAIL PROTECTED]> wrote:
> I was playing a bit of devil's advocate when I wrote "I have no interest
> in JSF". It probably sounded harsh.
>
> The truth is, I want both Struts and JSF in my toolbox. I don't want one
> to supplant the other.
>
> I have a couple of JSF questions.
>
> 1) I do a lot of Swing work with some HTTP-based services (some with a
> human interface, some with a programmatic interface) mixed in with other
> services that use other protocols. To do the HTTP stuff, I am interested
> in a killer, but focused, controller. I just don't need "web services"
> proper and a bunch of XML bloat, and I don't need tag libraries, for
> what I'm talking about. Struts 1.3 CoR controller looks promising in
> this aspect. Can JSF help me in this aspect? If not, you see how JSF is
> not a replacement for Struts, in my world (or in one of my worlds).
JSF has a front controller architecture with a well-defined request
processing lifecycle, similar in overall responsibilities to Struts's
request processor (which is being CoR-ized for 1.3). The typical way
that a submitted transaction is mapped to corresponding logic is
through a method binding on a submit button. For example,
<h:commandButton ... method="#{mybean.save}" .../>
causes a Java class named "mybean" to be created (if necessary, sort
of like what Struts does with form beans but more generalized -- it's
actually a basic IoC framework based on setter injection), and then
calls the public void save() method on it to perform the actual
transaction.
But that's not the only way to do it. I'm working on some code in
Shale that maps incoming XmlHttpRequest transactions directly to
corresponding business logic, but uses the JSF front controller so
that your logic can take advantage of the IoC and value binding
capabilities of the JSF front controller.
>
> 2) At first, and second, glance, JSF looked to me like the ultimate tag
> library (obviously I'm not looking deep enough).
Just as a note, it will be quite common for JSF component libraries to
offer tags around their components, but the actual components
themselves are Java classes, and you can plug in different mechanisms
for representing them in source code. JSP is not required.
> That's great for when
> I'm doing tag-centric development, but that's just one aspect of my
> development. I see that JSF claims to be independent of HTTP/HTML.
Well, independent of HTML at least (other than a few standard
components that are HTML specific, to give you enough to get started).
In another thread (with the keyword [Shale] in it), I've described
some of the other kinds of things you can do, such as rendering
components that are themselves a bunch of JavaScript and DHTML to
create better client side user interfaces. You can also, of course,
have your components emit SVG or WML or any other sort of markup you
need, too.
JSF 1.x doesn't really try to be independent of HTTP (although it does
try to abstract away the differences between the Servlet and Portlet
APIs, so that you can write applications for either environment using
JSF components).
> Can
> JSF express view-control logic that I can use as the backbone for
> putting an HTML interface as well as, say, a Swing interface, on the
> same application? If not, could you give me an example of what the
> independence from HTTP/HTML buys me? This is the thing I'm more curious
> about than anything.
There are many who believe that a framework that crosses these two
domains (Swing and web) would be ideal. I'm afraid that I am
something of a skeptic ... the event handling paradigms are very
different, which generally leads to application architectures that are
quite different. (There are some existing frameworks like Swinglets
and Echo that succeed, to varying degrees, at making the applicaton
models look more alike.)
For example, in Swing apps it is common to have your view components
register interest (via event isteners) in changes to model objects, so
that they can automatically rerender themselves when the model data
changes. That's very different from a web environment where your view
tier stuff is all sitting on the client, while your model tier data is
actually split across both the client and the server.
What I forsee is two general approaches to this problem space -- Java
running on the client with nice components like those from JDNC, and
JSF components that themselves render complex JavaScript and DHTML
code so that you can build user interfaces like those on the current
Google apps (including GMail, which I'm using to compose this
message).
Interestingly, the two approaches can come together by sharing the
back end infrastructure. After all, a front controller doesn't care
whether an incoming request was created by Java code in a Swing
client, or by JavaScript code via XmlHttpRequest.
>
> The thing I am trying to avoid is investing in code that is tied to
> Internet Explorer or Mozilla -- in particular, to JavaScript. A timeless
> Web app or view-control framework for me will offer *adapters* for those
> browsers, and those adapters might be implemented with JavaScript, but
> the framework won't be focused on them, and the author(s) will look at
> the JavaScript adapters as something that makes the framework a reality
> for now but can be replaced easily when better browsers and browser APIs
> come along.
>From a JSF perspective, then, you would want to look for component
libraries that deal with all of those differences for you (so that
your page author doesn't have to). It then becomes the responsibility
of the component library developer to maintain cross browser
compatibility -- and, along the way, hide *your* developers from even
having to know that JavaScript is involved.
>
> Thanks,
> Erik
Craig
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
