I have read and appreciate the article Bear wrote on the Front Man technique or pattern (as you will). I wonder if there is a good EXAMPLE that I can review with all the files used for configuration and description of classes/servlets/etc. Right now I do not know the blood and guts implementation details for the controller parts. I have bean classes and jsps but I keep running into the need to use bean object data inside my jquery logic which I think violates the technique (and rarely seems to work anyway).
The specific case I am dealing with is really simple. Filling out the details of one business object requires either choosing one if its members from a pulldown box or deciding to create a new one. There is only 1 member that has this complexity for the original object. Let's use as an example a company which refers to a salesman. The page I am talking about is for building a new company. It could refer to an existing salesman (the pre-display load of the combobox) or require a new salesman (the top default value within the combobox (using existing implementation)). Once the user has made a decision in the combobox (and possibly filled out the company info) they hit an action button that I want to display all the information side-by-side (company and salesperson). Another button press would clearly be needed for confirmation. So, using the Front Man technique and good JSP practices how many pages are we talking about and where do the distinctions for separation occur?
You need to stop thinking of JSPs as "pages". Yeah, I know that's what the P in JSP stands for, but that phrase was coined long before the advent of Ajax. In today's world, a response from the server needn't be an entire HTML page as was common in 1998.
So when you ask "how many pages", that isn't really a meaningful question.
I see a number of requests in your scenario. One that delivers the entire original HTML page, and some that deliver either HTML fragments (not whole pages), or even JSON data.
How all this ties into the Front Controller pattern is rather orthogonal. Regardless of what's going on on the client, the front controller is responsible for dispatching the request to the appropriate command. The fact that the command may respond with an HTML page, an HTML fragment, a JSON data construct, XML, or whatever else is rather irrelevant.
I see what you mean and I guess I would love to see a full page and partial page request ajax controller-using jsv(java server view? lol) implementation. An example. I will search around more but the examples I have found so far as so occluded with other concepts being the point that I cannot seem to sift a minimal set of what I need from them. If you know a good clean simple example and can link me to it I would surely appreciate it.
Yeah, most examples or tutorials for the cascading drop-down example will focus on the client side and hand-wave over the server-side details. Whenever I'm implementing this feature, here is the pattern I use:
I place a change handler on the triggering element (frequently a drop-down itself).
The change handler grabs the triggering value (a country name for example that needs to fetch a list of states or provinces) and issues an Ajax request using the jQuery .load() method. Life is simply too short to not use jQuery for Ajax. The trigger value is included as a request parameter or path variable.
The front controller (FrontMan for me) fields the request and dispatches it to the appropriate command.
The command grabs the trigger value from the request and uses it to delegate to the model to obtain the list of option values.
The option values are placed into a Map, where the map entries contains the option value and the option display text. If these two values are the same (they're not usually the same for me) you can just use a List or array.
The Map is placed in request scope, and the command forwards to the JSP view.
The view uses the JSTL and EL to mark up the list of <option> elements using the Map entries.
That's all there is to it. The response, an HTML fragment consisting of the list of option elements, is injected into the target drop-down by jQuery's load() method, so there isn't a whole lot of client-side script necessary.
Note that the server-side pattern is pretty much the same as just about any other task: front controller activates command, command collects request info, command delegates to model, command formats data for view, command forwards to view (for full-page responses, this is usually a redirect to the other page controller), view renders markup.
Joined: Jun 15, 2011
Excellent! A great high-level concept-oriented walkthrough. I'm looking for an example. The one's I find are usually intermixxed with PHP and other branded technologies which I do not use. The search goes on ...
Joined: Jun 15, 2011
So at first I wanted to handle the load content as strictly HTML. I'd still like to do that but the technique may not work well in that limited case.
Here is the calling JSP code:
and here is the (used to be HTML fragment) JSP for content:
I've tried EL and other not so pretty solutions but I just do not know nor can I find a concrete example of how I refer to the load call's data element within the fragment.
The class members for the contact bean are currently all just simple Strings with default getters and setters.
You're not being very clear. Is the jQuery statement part of the page you show below it? Or is that the page that load is calling?
P.S. We'll save the scolding for calling JSPs directly without a controller until later.
Joined: Jun 15, 2011
It's true I am not following the technique properly but I cannot find a concrete example of that using just JSP and HTML (no PHP, JSON, or any other concept that gets in the way or makes easy some step that I need to know how to do primitively first).
The first code section I show is my original JSP file with the JQuery load call. The second code block is the entire JSP file that is loaded (in that calling case only) by the first code fragment. I would prefer that this second code file be JUST HTML but ... I figured that the data transfer/handling would be easier using a JSP (where I had more of an idea how to accomplish getting the data to display. I am very confused by the fact that my session scoped bean object is apparently not visible to the loaded file but my CSS class information carries straight through with no issues. I pass the JQuery ajax request (load) the contact bean class as its data object (this could be an erroneous use of the data object which seems to be oddly limited to name/value pairs but I am just guessing). I do not know the EL syntax (well enough) or other proper way to refer to the JQuery data object within my fragment file (be it finally JSP or HTML or whatever). I would love to see a concrete example of a controller class implementation if it doesn't use too many new concepts with which I am as yet unfamiliar. It's cool if learning a whole new concept is the best way and I just damn sure need to learn it. Simple Java and HTML are what I am hoping for. Did that clear up your questions?
Also I am scolding myself for not understanding how to implement the controller class properly as well. I am trying to learn it.
At a high level, I think your issue is that you are not compartmentalizing the two requests. If the contact bean is going to be used in the fragment, what is it doing in the parent JSP? That's not where it's needed, and you can't just pass it to the Ajax request. (see the article I linked to.)
Rather, the Ajax request should be going to the page controller (not directly to the JSP) which will fetch the contact info and pass it to the fragment JSP.
At most, the data passed from the parent page to the Ajax request should be the id of the contact to look up.
And, if the contact bean is already in the session (which may not be the best idea), then it's already available to the Ajax request so no passing around of anything is necessary.
Joined: Jun 15, 2011
Yes contactdisplay.jsp is the HTML fragment to be loaded represented by the 2nd block.
The second block is ONE EXAMPLE of code that would be loaded. There are 2 special values in the combobox, a blank representing no choice and a "New Contact" selection for the case of creating a new contact entirely. So, there are 3 cases of Ajax loads (or maybe just 2): I clear the content div if the blank is selected. I load it with edit boxes of the new contact choice is selected. For any other value in the combobox I display that contact's information in the content div.
I read the article you linked. I believe that I have a fair grasp on the concepts involved but I am lacking the concrete example to solidify the concepts in an implementation.
I suppose if the data object in the load call is limited to a map of name/value pairs that I must use it that way. I have a bean class that contains the list of contacts. I can pull the right contact from that list based on the combobox selection and map field labels to field values for the loaded view. I confess I do not know how to accomplish this on the client side in the JQuery change handler for the combobox. Can JQuery functions refer to my session-scoped beans and I suppose I should ask the question should it do so? If so then I need to know how.
I would love to use the Frontman technique and create a controller class but I cannot find a simple java/ajax example. All the examples I find use PHP, JSON, ASP, etc. Is there a simple java/JSP/HTML only example I can review of the Frontman technique so that I can understand how to implement it that way first before moving on to more complicated examples?
I suppose the contact bean is in the JSP because I am squishing controller functionality into that page which is a no-no. Assuming I could ever find an example of a controller class implementation that was simple java I could remove that need and pass only the selected contact key from the dropdown to the controller.
I did try referring to the contact bean within the fragment (just like I would have done in the calling JSP) and that did not work. So between your assertion that no passing around is necessary and that situation I am really confused.
Sorry for the delay -- your last post slipped under my radar.
And using the combination of jQuery and FrontMan makes this easy. Steps would be:
The Ajax request (via jQuery's load() method) gets sent to the server (from the change event of a dropdown or any other stimulus), with a URL that identifies a FrontMan command.
On the server, the command is instantiated and executes.
The command uses whatever info was passed to it as request parameters to delegate to the Model and obtain the list of values and display text for the list of options.
The value/text values are placed into a Map as key/value pairs, and the Map is place into request scope.
The command forwards to its view.
In the view, JSTL and EL is used to iterate through the Map and create an HTML fragment consistintg of the list of option elements.
Back on the client, the list is injected into the dropdowm, and voila, the dropdown now has its list of new options.