I'm trying to implement a web application with a (simple) front controller pattern. It's just for personal testing and research purposes so it doesn't have to be too complicated or powerful. And i'm pretty new to Java/J2EE so i don't see chances to get an answer from looking to the source code of Struts or something
What i'm particularly unsure about is where initial request data (for example user form data) should come from. I've read a lot of documentation and i also understand those nice scenario diagrams but they all just say that there is a request from the client to the (front) controller and they don't say where this comes from.
Would you use simple HTML pages for that purpose? Or do you prefer JSP pages? Should they be put under control of the controller servlet, too? Respectively do you map all web resources to your front controller? Most likely this is not usefull for static images or CSS files...
Any help would be appreciated! Perhaps you know a tutorial with CONCRETE hints on how to implement a front controller (which is not too complex).
Anyhow, the servlet container routes GET and POST requests to the proper methods of your front controller servlet and you're on your own from there. Here's how simple it can be:
Scroll up to the Servlet forum, find a post from Ben Souther and follow the links from his signature to his simple samples. They are quite good and I'm pretty sure there's a front controller in there somewhere.
A good question is never answered. It is not a bolt to be tightened into place but a seed to be planted and to bear more seed toward the hope of greening the landscape of the idea. John Ciardi
This really helped me a lot. Indeed i found some example code and the Front Man article by Bear Bibeault seems to be very helpful, too.
But i'm still a little bit unsure about the initial origin of the request data referred to simply as "client request" in all the examples. I'm very familiar with the HTTP protocol so it's clear that there is usually a GET or POST request reaching the front controller servlet.
I hope i could express reasonably what i'm curious about...
Joined: Jan 29, 2003
Static HTML and JSP and PHP and ASP and all those page generation techniques look the same when you "view source" at the browser. In other words, they have nothing to do with the browser generating the next GET or POST.
It's common to use a Servlet to receive requests and build it with all Java, no HTML. Then use a JSP to build the response HTML, all HTML and tags, no Java. Let's try a picture:
How does that GET/POST get to the servlet? I think that's one of your questions yet. The web server has a ServerSocket that accepts messages from clients. Every time a client calls, it reads the request from a socket, parses out the HTTP command line, headers, body, etc, and passes them on to the servlet. If you want to dig into the HTTP protocol and what all those parts look like, maybe start up a new thread.
Presumably if your user inputs data into a form you would like to repopulate it at some point (say an error after validation) with values they had just input, so for most apps I wouldn't use straight html pages for input forms. For the first time it is displayed you would populate it with defaults.
As an aside jamon is great for timing this type of code. The following will time each unique actionID and allow you to tell which actions are currently executing among other things. You simply run the jamon admin page to see the results in real time.
Now it's a lot clearer how a concrete workflow between the involved parts of the architecture could look like.
My question about the "initial HTTP user request" wasn't actually focused on technical details like the underlying socket communication. In fact i have a clear understanding of the HTTP/socket communication as i already said. Anyhow thanks for you explanation
It was simply focused on the common technology used for creating the web pages and forms to retrieve user data. But Steve's hint on repopulating a form after validation is obviously a very good reason to use JSP pages rather than static HTML files.
Thanks again for you help! I'll do my best to get a working architecture for my web app...
More generally speaking, which technology the start page is implemented in (HTML, JSP, whatever) will mostly depend on how dynamic it needs to be.
The soul is dyed the color of its thoughts. Think only on those things that are in line with your principles and can bear the light of day. The content of your character is your choice. Day by day, what you do is who you become. Your integrity is your destiny - it is the light that guides your way. - Heraclitus
Hi Stan, Would the following be considered bad design [in your opinion]? Here the Command is having a direct handle of the Session.
Joined: Jan 29, 2003
With some effort you can write commands with no J2EE imports, just POJO classes with POJO inputs and outputs. That makes it much easier to test them and even reuse them in some other context. I like to see the layers that are aware of HTTP and servlets as thin as possible.
Joined: Jul 31, 2006
I agree. Testing becomes much easier with POJO.
Just wandering on the following:
Servlet gets back data from Commands.
Q1) Does Commands send back data in a common data carrier? I guess it must be so.
Servlet puts back data to Session which JSP can use to render the view. Q1) Is such a thing configuration driven? Meaning it takes out the Configured data from the common data carrier to put back to Session.
Or Is it that there is a seperate code to put back the data for each kind of command? In this case, I guess the Servlet will have to have that many number of Helper classes.
Joined: Jan 29, 2003
You can make all Commands return Object and make any object available to the JSP. The Command and the JSP have to agree on what it is, but the controller never needs to know. I worked with one framework where Commands always returned an XML DOM and the JSP had a taglib that understood XML for data binding. I wouldn't recommend that again.