This week's book giveaway is in the OCAJP 8 forum. We're giving away four copies of OCA Java SE 8 Programmer I Study Guide and have Edward Finegan & Robert Liguori on-line! See this thread for details.
Hi all We are undertaking a mid-sized J2EE project. We will be building a CRM-type application, specialised to the particular needs of our customer. Some preliminary requirements/specification/scoping work has been completed, and it looks at this stage as if WebLogic will be our app server. So far, so good. However, I have severe reservations about using JSP as a front end. To give an example, one particular transaction in the proposed system needs to capture up to 37 interrelated pieces of data, and possibly take the user to sub-screens depending on what has previously been entered. A major part of our system is data capture, and I am worried that relying on HTML pages for data entry is going to get awkward for everybody. I am interested in opinions as to the best way to faciliate data capture in a scenario like the one I've just described. If we have to use JSP, we will, but it does feel like a giant leap backwards. Thoughts, please? Thanks RW
If client code distribution is not an issue (e.g. you own the desktop) then a Java Swing application is a perfectly valid way to implement this. In fact, you might even consider looking into JNLP/WebStart for the client code distribution. Check the Swing and Webstart fora here on Javaranch for more information. It is perfectly acceptable (and totally J2EE compliant!) to write an application front-end for EJB's in WebLogic or any other EJB container. Kyle
I have had similar requirements on some of my applications that I have implemented with JSP. I have dealt with it by having a common servlet that the JSP's post to which builds my data object(s) and controls navigation. The entire transaction is not executed until the appropriate data has been gathered. It behaves similar to a wizard in that you can step forward or backward through the process and the only way out is by completing the navigation or pressing a cancel button that clears out the session. KJ
Kirt's got it. There's nothing wrong with JSPs per se, but you really need to use them only as the view, not as the controller and logic/data. Look up Model 2 MVC (model-view-controller) on google, and take a look at Struts (apache-jakarta). The idea is that all data is posted to servlets that call out helpers or EJBs to do stuff with the data and maintain state, then the servlets forward to JSPs to display pages based on the application state, data just entered, or a scripted process require ordered steps. One servlet can handle multiple JSPs that post to it if one dataset needs to be built over multiple screens. Just don't store the data in the Servlet - put it into a helper object that resides in the session and updated it as each new set of data arrives. The Servlet essentially becomes the script that glues the GUI (HTML) to the logic/data back-end. This type of scenario happens all the time and it's pretty much accepted as the current 'best practice'. I don't think anyone should post to JSPs, so if your tech team is recommending that, they haven't done their homework. Ask them about MVS and which model they intend to use. Also, make sure you be careful with when to use EJBs and what types to use. Not every session bean needs to be stateful, sometimes CMP is better than BMP, and vice-versa. Message beans require rigorous design for asnychronous usage. And not all database calls must use an EJB. I'm working on two J2EE projects right now and neither has any requirements that would lead us to use EJBs - hardly any transactions that aren't inside the database as stored procedures already, no need for distribution since there's only one server, and the data is always different so caching doesn't help us. I forsee a future project that will definitely need EJBs, but they aren't a cure-all and can actually complicate matters. I recommend a mixed approach if you need them, especially if scalability matters and you have limited hardware resources. Good luck on your project!
CJP (Certifiable Java Programmer), AMSE (Anti-Microsoft Software Engineer)
Author of Posts in the Saloon
It sounds from your post like you are afraid of striking the limitations of HTML. If it's not really the JSP per se you are worried about, but the fact that HTML is stateless and the users need to a lot of submitting, then I would advocate the application front end. If the users don't mind submitting their data in small bite-sized chunks and you're prepared to live with HTML, then Struts is definitely the way to go. If you do decide to go with the application-style front end, check out the Amber product http://amber.clearfield.com It's basically an SDK to make application-style interfaces easy in an EJB-type environment. The interfaces you end up with are displayed in an applet and but actually have all their processing logic on the server (a bit like the dumb terminals of old) There are a couple of demos on the website, but they perform like treacle because there is a high latency to the site. If you're interested in seeing what it's really like, I would definitely download & install the 60-day trial. The trial has a lot of the same demos as are on the website, and they are pretty representative of speed if you are close to the server. Hope this helps. Mark
Robert Williams Jr
Joined: Apr 15, 2002
Gentlemen, thanks for your replies I have had a busy day progressing this project. I have had one of my guys spending a few hours knocking up a quick prototype of our proposed "most complex transaction" (tm) using dumb web pages. There was nearly a revolt when the users saw it, and from this reaction I think that an JSP browser interface is definitely underpowered for these guys. I got a lot of moaning and comments like "why don't we just put these fields in a popup dialog?" (my favourite was something like "our new system looks just like the shopping cart on Amazon"). Of particular issue was the number of pages that have to be gone through to process our most common transactions. Because a good 25% of our people work in the call center and work with the same transactions over and over, they want as streamlined an interface as possible. After hearing their point of view, I tend to agree that being forced to do their data entry through web pages is going to make their lives a lot slower (especially when their current interface was written in Delphi - it's got search popups and fields enabling & disabling all over the place). So, it looks like the way we will be going for our J2EE project is to write an application front-end. We don't have perfect control of every desktop, as our users are from several different companies, but their IT departments seem reasonably amenable to using WebStart. This is one option. I have also downloaded a copy of Amber. At the moment, it looks like the most attractive option. On the downside, the Amber product appears to be very new. On the upside, the demo installed and ran fine, and it is most certainly fast enough for us. It seemed to be a lot quicker than WebStart, and it doesn't download all the code, which seems like a good thing from a paranoia point of view. It also worked without any additional software, which may count in it's favor as long-term we are looking at opening our application up to registered internet users. I have assigned one of our programmers to do a serious evaluation of the product. (If anyone is interested, I can post his comments here). If anyone has any further comments, or any experiences/dire warnings to relate about Amber or WebStart, please let me know. Thanks for your time. Robert
Check out Struts !! http://jakarta.apache.org/struts 'One' of the things you can archieve with struts is to *easely* translate HTTP logic (form fields and they're quirks) into real java objects & variables. For exampe; - easy validation of input (in a standard programatic way) - easy filling of select boxes or drop down - easy re-filling of chosen values (for instance when a page is reloaded because the user entered something wrong) - etc.. I found struts to be MORE than worth the time to learn it