This week's book giveaway is in the Design forum.
We're giving away four copies of Design for the Mind and have Victor S. Yocco on-line!
See this thread for details.
Win a copy of Design for the Mind this week in the Design forum!
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Origin of request data when implementing the front controller pattern

 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 862
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.

 
Marco Ehrentreich
best scout
Bartender
Posts: 1294
IntelliJ IDE Java Scala
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 14112
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
More generally speaking, which technology the start page is implemented in (HTML, JSP, whatever) will mostly depend on how dynamic it needs to be.
 
Ingudam Manoranjan
Ranch Hand
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 8791
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 48
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Interesting.

Thanks Stan.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic