we would like to use the mvc pattern for our j2ee project. so we will have servlets that handle business logic thru ejb and then forward the request to jsp for display.
my question to j2ee developers out there is: how are you handling the re-display of pages on error conditions? if there was a combo box then you would display whatever was there along with the selection that was submitted. if it is a text field then whatever the user had typed.
each html component would therefore need to do 2 things: either display business logic results or re-display whatever was submitted. it seems like all jsp projects need to do this .. right?
Most of my forms map well to a bean or beans. The form is implemented in JSP, it submits to a servlet, which fills the bean, and validates it. If the validation is successful, the business logic continues its merry course and forwards to whatever view makes sense. If the validation is not successful, then the servlet sends the bean back to the JSP form.
The form itself simply works with jsp:useBean scoped to request. If you go directly to the form, the bean is empty, the form is empty, and the bean contains no validation errors. Once processed, the servlet can send the bean back to the form, which is no longer empty and contains validation errors, so the errors and values are populated into the form.
In situations where the form doesn't match well with a bean or a set of beans, you have to employ different strategies.
i like that solution also. thanks.
what about a framework such as struts? is the learning curve worth it? is it too proprietary? decisions .. decisions .. decisions.
Using a framework is definitely a great way to reduce the amount of work needed to implement something and promote re-use and rapid development.
That said, they do all come with learning curves and potentially involve proprietary features that don't translate very well to another environment, as you said.
On a personal level, I probably favour building up your own personal toolkit into a framework. However, if I found the right framework, I'd certainly be interested. I don't have any recommendations at this point. I've only looked briefly at some and none of them have made me want to leap into learning them.
You will no doubt be able to find people who believe strongly in any given framework. Of the ones I looked at briefly, Jcorporate was the one that seemed most interesting. Struts gets a lot of good press, and I haven't looked far enough into it to really form an opinion.
For all frameworks propagating MVC there is one aspect that should be evaluated. This aspect of course is 'personal' and may not be important to everybody depending on his development process and team. The aspect is
How neat is the separation between the web designer work (view) and the developer work (controller, model and related business logic)?
What is the point about this? The only common language that all website development tools support for sure is standard HTML. Now adding tags which are not HTML-tags, that is what most frameworks do (actually mostly in violation of the MVC model), turns things problematic. Most tools won't be able to identify such tags not even to the extent that they would ignore them and displaying the rest of the web page. So consequently the once so beautifully designed webpage (without any reference to the business logic) cannot be displayed anymore after having added the references to the business logic. Just an example: Microsoft Front Page cannot even display a JSP page which has jsp directives as the first non-empty line (which actually is nothing to be surprised of), but also other HTML editors have difficulties with standard JSP tags, sometimes resulting in displaying nothing at all or display just parts of the webpage with strange characters and string in between etc. etc.
Worse is it even with frameworks like Struts which have substitutes for standard HTML tags (e.g. <html:text property="username"/> instead of <input type="text" name="username" value="<jsp:getProperty name="loginBean" property="username"/>, latter can be displayed by all HTML editors (even FrontPage), the struts construct will never display in any HTML editor). The problem is that there is at the moment to my knowledge no HTML editor available which supports custom tags (this would mean the editor can identify these tags and ignore them for display) or 'alternative' HTML tags like in Struts.
This aspect prevented me up to now from using any existing framework, because I am a developer of the server side, the client interface design work I want to delegate 100% to a web designer (of course with a well-written specification). Actually our design decision is that our webpages only are allowed to contain standard jsp tags. This is a tough requirement, no custom jsp tags are allowed (this alleviates a web designer also from having to learn myriads of custom tags, and there are a lot of them out there). Or you can put it else, no proprietary solutions are allowed, only standards are to be used. We are working at the moment a putting up our own framework to fulfill that requirement. It is a very interesting but challenging and demanding task, especially because most standards are evolving, new ones emerge etc. etc. and these have to be integrated in the framework.
My experience is that up to now I did not encounter one framework which gives