On 7/13/05, Yaroslav Novytskyy <[EMAIL PROTECTED]> wrote: > Hello! > > Craig McClanahan wrote: > > On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > > > >>Craig McClanahan wrote: > >> > >>>I think of the state information represented by an ActionForm (in > >>>Struts 1.x) or potentially as properties of an "action" class (per the > >>>current discussion) to be part of the *view* tier. Further, I see the > >>>role of the execute method on an action as being an Adapter Pattern > >>>link between the web tier (HTTP-centric) and the model tier > >>>(HTTP-agnostic). Therefore, I don't feel any pain at the idea of > >>>combining the two together. > >> > >>It sounds like what your saying is that there really is no need for a > >>control layer, we're coming down to view-adapter-model now. Am I > >>understanding that correctly? > >> > > > > > > Not completely, but amost. > > > > There are reasons to have an "application scoped" front controller. > > There are reasons to have a "view-scoped" front controller. There is > > *no* reason I am aware of that requires these controllers to be the > > same :-). > > (The question is below but here I only wonder: what is a "view-scoped" > front controller? :) what are the differences between a "view-scoped" > and an "application-scoped" (a "normal" one as I can guess) front > controller?)
In design pattern terms, it's actually the View Helper pattern more than it really is a view scoped front controller. But the key differences are: FRONT CONTROLLER - Typically an application-level singleton - Processes every request - Enforces global architectural issues (has the user logged in? perform validations before application actions. ...) - Manages navigation between views VIEW HELPER: - Typically one instance per view - Processes only requests for that view - Assists the view in performing its rendering (go execute the JDBC select or Hibernate query needed for rendering a table, and clean up afterwards). - Does not manage navigation, but provides logical outcomes that influence the navigation performed by the front controller > > > In Shale, the application-scoped functions are performed by a Commons > > Chain pipeline that is configured and processed by Shale's filter. > > This is the right place to put things like "if the user isn't logged > > on, redirect to the login page" and "log every request" type > > functions. But it is not the right place for "execute this expensive > > SQL query, but *only* if I am the view that needs it.". > > > > In Struts 1.x, you get around the latter case, typically, by having a > > setup action before the view, and a process action after the view. > > Shale simply combines those two bits of code into a single class (and, > > along the way, combining the form bean too), resulting in a little > > less code, but a lot fewer classes. > > In Struts 1.x I do use setupAction->jsp->processAction technique and was > thinking all the time how can I put together the setupAction and > processAction into one class. The best way I could think of was to make > a "downgraded" DispatchAction, that dispatches based on mapping's > parameter (in the latest version of Struts just the same thing appeared > named MappingDispatchAction) and to put both setup and precess > actions-methods into one class. > > (p.s. this technique made it also possible to automate token-based > protection - every prepare calls saveToken and before every process > token is checked) > > So please tell, in what way does Shale do this? Shale provides four application level events in your backing bean (optionally -- you don't *have* to leverage this, but you'll get the service if you implement the ViewController interface): * init() -- The view you are associated with is going to be involved in the current request (either you are about to process a postback or about to process a render), so gather any resources you need to get ready for either. * preprocess() -- Your view is about to process a form submit, so get set up. For example, you might need to go lock a database row, or acquire references to some business logic options. * prerender() -- Your view is about to be rendered, so go collect the data that will be needed (this is used for the sort of stuff a setup action typically does in a struts app). * destroy() -- The framework guarantees to call this *after* rendering so you can clean up any allocated resources. For example, you might have executed a JDBC query in prerender() to provide the data for a table; here is where you would close it and release the database resources. (This is something Struts doesn't support directly; you have to mess around with a filter or something like that). > Should I pay more attention to shale? Is it ready to try it out on some > small test projects? I would definitely suggest paying attention :-). If you're investigating the JSF route, JSF+Shale is a good combination. > > > Yaroslav Novytskyy > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
