File APIs for Java Developers
Manipulate DOC, XLS, PPT, PDF and many others from your application.
http://aspose.com/file-tools
The moose likes OO, Patterns, UML and Refactoring and the fly likes Origin of request data when implementing the front controller pattern Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login


Win a copy of Spring in Action this week in the Spring forum!
JavaRanch » Java Forums » Engineering » OO, Patterns, UML and Refactoring
Bookmark "Origin of request data when implementing the front controller pattern" Watch "Origin of request data when implementing the front controller pattern" New topic
Author

Origin of request data when implementing the front controller pattern

Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

Hello!

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).

Thanks in advance!

Marco
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
The request is usually a simple HTTP GET or POST. (There are other commands like PUT, HEAD and DELETE that are much less common.) HTTP requests can come from a browser doing normal browsing, another program in any language, the XMLHttpRequest object in Javascript, or anything that can speak the HTTP protocol.

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
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

Thank you very much, Stan!

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.

My question was what it is that is causing this request to happen before the front controller even starts to do something useful! I know it can be anything from JavaScript to a static HTML page, a JSP or another web resource that sends a request to the front controller. I'm especially interested in "normal" web pages containing a form to fill in user data. Is there a preferred way of gathering these user data. Is there an advantage of using simple static HTML pages or JSP pages? At the moment the only reason i can see for preferring a JSP pages "behind" the front controller over a static HTML page is to hide the real URL of the JSP or invoking central services like authentication or logging or something like this. I know this depends a lot on one's needs but perhaps practice has shown which way this is done best.

I hope i could express reasonably what i'm curious about...
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.
steve souza
Ranch Hand

Joined: Jun 26, 2002
Posts: 861
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.



http://www.jamonapi.com/ - a fast, free open source performance tuning api.
JavaRanch Performance FAQ
Marco Ehrentreich
best scout
Bartender

Joined: Mar 07, 2007
Posts: 1282

Thanks for your detailed and helpful answers!

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...

Marco
Ilja Preuss
author
Sheriff

Joined: Jul 11, 2001
Posts: 14112
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
Ingudam Manoranjan
Ranch Hand

Joined: Jul 31, 2006
Posts: 48
Hi Stan,
Would the following be considered bad design [in your opinion]? Here the Command is having a direct handle of the Session.

Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.
Ingudam Manoranjan
Ranch Hand

Joined: Jul 31, 2006
Posts: 48
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.
Stan James
(instanceof Sidekick)
Ranch Hand

Joined: Jan 29, 2003
Posts: 8791
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.
Ingudam Manoranjan
Ranch Hand

Joined: Jul 31, 2006
Posts: 48
Interesting.

Thanks Stan.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Origin of request data when implementing the front controller pattern