The DispatcherView supports the FrontController by finding the appropriate newx View. Therefore the DisptcherView does all the view-management and navigation as stated in the core J2EEpatterns catalog. The ActionCommand executes business-logic which is accessed through a BusinessDelegate of the business-tier.
Looking at the core J2EE patterns, they use a ViewHelper. Now I don't really have a clear understanding of what this ViewHelper does or is supposed to do I just can't find a clear definition of ViewHelper. Is my approach from above valid or do I need a ViewHelper (whatever it does in the end)?
Further, I plan on having a couple of component diagrams to illustrate the different components that fullfill the requirements. Obviously all the diagrams will have the MVC2 approach from above. I am now wondering if I should clutter my diagrams with always the same MVC2 or is it legal to have another component diagram that shows MVC2 apporach in detail and in the business component diagrams just have one component "presentation" and take it from there into the BusinessDelegate?
And finally, do I need a somehow detailed MVC design for the Swing Client as well, or is it good enough to show it as a single component in the business component diagrams?
Any comment is appreciated!
D. [ August 23, 2005: Message edited by: David Follow ]
Remember, you don't have to use all the patterns sometimes a combination of patterns implemented in a particular way eliminates the need for the implementation of other patterns
Look at this design pattern. Pay attention to the Solution section, which describes how to use all of them together. The way core J2EE pattern explains it is
Controller: Centralized entry point Dispatcher: Responsible for view management and navigation (Remember, controller and dispatcher can be combined as they are in Struts framework) View Helper: Helps the view prepare the content it is going to display. In other words, it's a component that reduces scriptlets in JSP by providing processing code. It could be implemented in different ways 1. As tags 2. As Javabeans 3. As separate classes Struts for example uses Action classes and doesn't put any data processing code in java beans (action forms) or tags.
In your case I think ActionCommands will play the role of a View Helper
I saw petstore code and i think that ViewHelper help to make the page . I explain me better, The viewhelper classes when a jsp is load go to server to retrieval information and so presents it in browser.
I think that JSP-->ViewHelpter-->BussinessDelegate-->Facade--> ... is the correct. What do you thinks about ??
I have a new doubt :
My doubs are with mapping *.screen --> TemplateServlet
For example in petstore, a page to search product go to link searchProduct.screen?id=233 ... then this url don't pass across FrontController because the views only retrieval information of server (Haven't action) . I think that is correct ..
I think that View Helper plays also a role in presentation formatting not only in view preparation, it formats and adapts data and may encapsulate presentation logic, think about a well designed custom tag for displaying a master/details table for example, this tag may be reusable across multiple jsp pages, JSTL is another option. A more sophisticated framework is JSF. This pattern is a View and Helper as named in Core J2EE patterns.
Joined: Aug 19, 2001
Marie, I agree. Patterns could be implemented in multiple ways (and I did mention that in my response). While responding, I kept in mind the struts framework to help the reader better relate the concepts to the real world. C
Joined: Oct 16, 2001
thanks for your input. I did some further research and came to the conclusion that a ViewHelper can be implemented in many different ways, mainly that a) it is a JavaBean which is used in the JSP and makes calls through a BusinessDelegate to the business logic, or b) it is a JavaBean in the sense of a ValueObject. Therefore, some ActionCommand (see Struts) performs the business call through a BusinessDelegate and puts the results of that business call in the Servlet session from where the JSP can then pick it up and process (STL) it.
I don't like solution a) very much because it feels somehow strange to call business logic directly from a JSP although it is wrapped in a JavaBean (or shall I say ViewHelper). I like option b) because this ActionCommand (or shall I say ViewHelper) calls the business services and put the result in a simple JavaBean (or should I say ViewHelper) to be picked up and displayed by the JSP.
So bottom line I have three different implementations that are all refered to as ViewHelpers
1) a smart JavaBean residing in a JSPS that can call business logic through a BusinessDelegate 2) a stupid JavaBean that holds only getters (e.g. ValueObject) stored in the session and picked up by the JSP 3) a ActionCommand that can call business logic (e.g. Struts Actions)