Craig McClanahan wrote:
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.
Thanks. I will look into it more here and there as I have time. Right now I am going through the JSF slides on the "Core" site. I haven't had time to look at Shale yet other than reading your initial outline a few months back.
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.
Sounds good.
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).
Thanks for all the posts. It will take time to understand.
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.
I know what you are saying and understand the skepticism. However, I have been having some success with an approach that makes my Swing apps a little more Web-app like, rather than trying to make the Web app more Swing-like. Sounds backwards I know, but I'll just say for now, it can be done when the right level of abstraction is found (or the right pattern(s) come into focus in other words). So yeah, I'll say it's a matter of how far "forward" you can push the abstraction (certainly the approaches can unite *somewhere*, as you suggest) before you're forcing one paradigm to try to exist in the space of the other. Working with HTTP and Jabber in the same applications has taught me a lot about mixing active and passive notification and has given me some insight with respect to this. As with anything, you practice working with seemingly incongruent objects/paradigms, you learn how to factor out the incongruencies.
I certainly see a future for Java that includes both approaches as you do. That's good news for all of us.
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 componentlibraries 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,Craig
Erik
I appreciate it.
Erik
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
