Re: Java Struts: Book Recommendation?
On Fri, 19 Nov 2010, Lew wrote:
Steve wrote:
I worked for a company that sort of rolled their own. A dispatcher
servlet, taking requests, reading a database table, then deciding to
send the user to a java [sic] class, JSP or HTML page as a response.
As an aside, Lew, do you think the [sic] is necessary in blocks quoted
using the > convention? Doesn't that already imply literal,
copy-and-paste, quotation? Isn't using both a bit like writing "java [sic]
[sic]", which implies that someone actually wrote "java [sic]"? I
appreciate that if you were quoting inline, the [sic] would be
appropriate, but here it seems not just redundant but erroneous.
That is what struts and JSF seem like.
JSF is rather different. Unlike Struts, it doesn't use a single
front-controller model, but uses a multiplicity of controllers - loosely
speaking, one per screen. It also imposes a component model on the
screens, sort of like Swing or other GUI frameworks, but of course
different in order to work on the Web.
I've never used JSF. I knew about the component model stuff, but i hadn't
heard about the multiple controllers. Would you say that either is a
bigger part of JSF than the other? Is it possible to use the multiple
controllers with plain JSP, should you want to? Would it be possible for
you to write or direct me to a brief explanation of how the multiple
controllers work?
I came from the front-controller world of Model 2 and Struts into JSF
myself. It took some getting used to, but now I find it very useful.
Have you had any contact with Stripes at all? My knowledge of web
frameworks is embarrassingly limited, and this is something i am slowly
trying to address. I worked with plain old J2EE back in the day, and since
coming back to programming have been working with something called ATG
Dynamo, which is a bit of a beast [1], but does have a flexible and
tractable web framework. I've started playing with Stripes in my own time;
it was written by people who'd used Struts 1 but weren't happy with it, so
i assume it is similar but superior to that. It's not a million miles from
what ATG does, which is helpful, but i'm curious as to whether there are
frameworks which use a radically different model.
Anyway, Stripes, i would say, has a single controller with no
intelligence. You set up its filter and dispatcher servlet in your
web.xml, which don't really take any app-specific configuration, then in
your JSP, you write:
<stripes:form beanclass="com.initech.smslottery.PlayActionBean">
<stripes:text name="mobilePhoneNumber"/>
<stripes:submit name="play" value="Play!"/>
</stripes:form>
And in your code you write:
package com.initech.smslottery;
public class PlayActionBean implements ActionBean {
// a few minor details omitted
private String mobilePhoneNumber;
public String getMobilePhoneNumber() {return mobilePhoneNumber;}
public void setMobilePhoneNumber(String mobilePhoneNumber) {this.mobilePhoneNumber = mobilePhoneNumber;}
public Resolution play() {
enterNumberIntoLottery(mobilePhoneNumber);
return new ForwardResolution("/lottery/thanks.jsp");
}
}
When you submit the form, the controller finds the class named in the
beanclass attribute of the stripes:form element, creates an instance, then
for each stripesified input in the form, calls the corresponding setter on
it, then calls the handler method named in the stripes:submit element.
That does what it needs to do, then returns a Resolution which indicates
what the response to the browser should be (usually a redirect to a page
or another form; Stripes is built around the redirect-after-post pattern
of request handling, although i think you can serve a page back directly),
which the controller duly puts into action.
However, it's possible my terminology is wrong here - it might be that the
ActionBeans are controllers, in which case there is one per page (ish).
tom
[1] It's also the Snake Plissken of app frameworks; whenever i mention to
people, the response, if they've heard if it, is "I thought that was
dead".
--
It takes at least 17 habbos to make a visible swastika.