Re: Reviving PageController (ViewController?) discussion?
--- Joe Germuska [EMAIL PROTECTED] wrote: However, I can see using the contents of the forward element as a way to provide more than one form bean to the renderer. I'll think about this some more. How would you actually make them available to the renderer? Via a map? Expect the renderer to fish them out of request or session scope? I was thinking we could have one renderer per form. This way, if a form gets reused by different views, the renderer can be reused as well. With this, a slightly modified version of your initial draft for the renderer's method signature could be used: public void render(ForwardConfig config, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception; I would also suggest giving the method access to the ServletContext and/or ModuleConfig. Somehow. It could be argued that even if the one-ForwardConfig-instance implementation is preserved, a ForwardConfig instance only applies to one module, so it could carry the ServletContext and ModuleConfig into the render method. Either way, it's looking like it might make sense to move the scope setting to the form definition, or at least allow a default setting there which will be honored if an action mapping doesn't specify a form scope. (Could be a topic for another thread) I don't think I agree with this, or at least, I think you have to preserve the possibility that different actions would want to use the same form definition in different scopes. I don't think that would be a very good design, because of the risk of confusion, but I'm not ready to say we should block it. Obviously we can't move the scope setting without sacrificing backwards compatibility -- that is, we can't move it at all, since we won't sacrifice compatibility -- although we could have a default scope on the form bean if that were helpful. I'm not sure I see that it is, but we can see... I agree about the backward compatibility concern. The issue I see is how the RequestProcessor will store the output form that the Renderer prepopulated. Right now, the scope is dictated by the Action receiving the form. How would the RP know what that is? Even if the point of prepopulation is to allow the form to be rendered, thus making it possible for the RP to store it in request scope and be discarded once the view is rendered, a session scoped form might be prepopulated with fields that the immediate view will not use but needs to be preserved for a later purpose. Storing that in request scope by default wouldn't work. I'm not sure I'm comfortable with the other option either, which is to store the output form in session scope, since the receiving Action could've only specified the request scope. I wouldn't mind being enlightened, though. - Hubert __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
I'd be concerned about associating a form with a ForwardConfig. It's possible that the resulting view could contain more than one form needing prepopulation... I personally have come across this scenario multiple times in multiple web apps I've been involved in. Good point; I haven't faced this myself, but I agree we should try to design to support it. I don't think I like the chaining idea; it just doesn't seem clear -- but I don't think you're advocating it as much as floating it. However, I can see using the contents of the forward element as a way to provide more than one form bean to the renderer. I'll think about this some more. How would you actually make them available to the renderer? Via a map? Expect the renderer to fish them out of request or session scope? Either way, it's looking like it might make sense to move the scope setting to the form definition, or at least allow a default setting there which will be honored if an action mapping doesn't specify a form scope. (Could be a topic for another thread) I don't think I agree with this, or at least, I think you have to preserve the possibility that different actions would want to use the same form definition in different scopes. I don't think that would be a very good design, because of the risk of confusion, but I'm not ready to say we should block it. Obviously we can't move the scope setting without sacrificing backwards compatibility -- that is, we can't move it at all, since we won't sacrifice compatibility -- although we could have a default scope on the form bean if that were helpful. I'm not sure I see that it is, but we can see... The PageController would then concentrate on non-form data needed by the view. Also, maybe we can call the Renderer's method render. That's probably better. Let's see if we can get some other folks to weigh in on this one... Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
Hubert Rabago [EMAIL PROTECTED] wrote: In such a case, (A) do we facilitate it by letting the function return another ForwardConfig which is associated with another form? Or (B) should the method just use the new createActionForm to create new forms and store them in the right scope? (B) If we use createActionForm with an additional RequestUtils (ResponseUtils? oops, deprecated.) method to set a form. RequestUtils creates the blank form, the PageController populates it, and a RequestUtils method sets the form in the proper scope using the proper attribute name. I'm not sure if this is related, but under Struts 1.1, I found it to be very frustrating to try to create additional initialized actionForms in an action. I wanted to create another DynaValidatorForm, but there appeared to be no way to easily do this. I eventually ended up creating a custom ActionForm class, then pulling pieces of code out of RequestProcessor.processActionForm() to get it installed. It'd be great if a utility method were available to create additional defined form-beans. The 1.1 createActionForm was not of any value. -Mike - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
I'm not sure if this is related, but under Struts 1.1, I found it to be very frustrating to try to create additional initialized actionForms in an action. In January, I refactored RequestUtils to expose a new public method, createActionForm(FormBeanConfig, ActionServlet) The ActionServlet may seem extraneous, but there are deep dependencies on it in the DynaForms, and I didn't want to monkey around with that. http://jakarta.apache.org/struts/api/org/apache/struts/util/RequestUtils.html#createActionForm(org.apache.struts.config.FormBeanConfig,%20org.apache.struts.action.ActionServlet) A possible shortcoming of the above is that it does no scope checking for already existing versions of the given form. I feel that it's not entirely straightforward as to the best way to expose that functionality. If we pursue this Renderer/ViewController idea, we'll probably have to find a resolution to that -- in fact, that's one of the reason I'm trying to drum up discussion instead of just plunging ahead and coding it. So nightly builds since 1/24/04 (and, of course, Struts 1.2.0) include some of the functionality I think you were looking for. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reviving PageController (ViewController?) discussion?
I'd be concerned about associating a form with a ForwardConfig. It's possible that the resulting view could contain more than one form needing prepopulation... I personally have come across this scenario multiple times in multiple web apps I've been involved in. Good point; I haven't faced this myself, but I agree we should try to design to support it. I don't think I like the chaining idea; it just doesn't seem clear -- but I don't think you're advocating it as much as floating it. However, I can see using the contents of the forward element as a way to provide more than one form bean to the renderer. I'll think about this some more. How would you actually make them available to the renderer? Via a map? Expect the renderer to fish them out of request or session scope? I prefer making a single action have the responsibility of staging the data for the view and handling the events resulting in a page submit. Like the DispatchAction and the LookupDispatch action the appropriate methods in a view controller could be invoked depending on a command argument or the button that was invoked to submit the page. I don't think I agree with this, or at least, I think you have to preserve the possibility that different actions would want to use the same form definition in different scopes. I don't think that would be a very good design, because of the risk of confusion, but I'm not ready to say we should block it. I think the problem with creating a page controller is that it is coupled with the view. The component aspect of JSF seems very attractive but it would be nice if it was a solution built around the struts model and not made to fit. What if struts had a visual component framework of its own and the page controller was responsible for loading the metadata the components would use into scope and assembling associated model classes that the components would hook into. The view model/events might best be used for constructing the view (unlike JSF). As the visual components are rendered, callback events to the model could effect the rendering phase. Leave the rest alone letting struts map values into a single formbean. The visual components could be constructed as view helpers that could be used in jsp scriplet, custom tags or velocity templates. These component helpers would be like smart collections that would use the metadata to make rendering decisions. This would keep the conditional view logic out of the presentation. Let the page controller/struts action handle delegating to a command listener. Obviously we can't move the scope setting without sacrificing backwards compatibility -- that is, we can't move it at all, since we won't sacrifice compatibility -- although we could have a default scope on the form bean if that were helpful. I'm not sure I see that it is, but we can see... Gary - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reviving PageController (ViewController?) discussion?
However, I can see using the contents of the forward element as a way to provide more than one form bean to the renderer. I'll think about this some more. How would you actually make them available to the renderer? Via a map? Expect the renderer to fish them out of request or session scope? I prefer making a single action have the responsibility of staging the data for the view and handling the events resulting in a page submit. Like the DispatchAction and the LookupDispatch action the appropriate methods in a view controller could be invoked depending on a command argument or the button that was invoked to submit the page. Gary, I'm not sure I follow you here. Are you saying that you think using Actions the way they are is better? Or that you'd like to have a single Action *class* which might have two methods? I think that a single action would that extended the action class would work. A web application will always need those process/passthru actions to perform backend work. Developers would still need the vanilla action. The view action might dispatch to a view model. The model could be coupled to the view controller/action in an xml file. The view model might have a couple of call back methods to override. I suppose that it could have a single method and a phase identifier or just use the technique in faces with a context object that is cached in task scope using the ThreadLocal object. This sure makes a loosely coupled design not having to worry about the method signatures. We have implemented something similar to what I'm describing but our controller/page model wouldn't be general enough. Our page has a finite number of commands/buttons that have a single callback method in the page model. Our page model has a doLoad, doDelete, doSave, doAdd, doQuit and a few other methods that correspond to submit buttons. All of these methods return an action forward and have the same signature as the action execute method excluding the response object. The labels of the buttons don't always match the action. We also have a doIsButtonValid on the page model that is invoked by the view helper. It's a way to programmatically make a button invisible. Like struts actions, the button can be associated with a value list of roles. Our menus and resultsets have similar behavior. The page controller, in the load operation, instantiates all the component models, places them into a single memento class that is cached in session scope. The load methods of the models are invoked. The dispatched task returns to the view controller action and forwards to the view. The view helpers are instantiated with the PageContext and know how to get to metadata cached in the various contexts. I prefer using dispatch-style designs for actions myself, and I'd want to design this controller/renderer so that it could also be implemented that way. I think you're saying that's what you want, but I'm not sure. I agree that the elements should snap together like the rest of struts by way of an xml definition. I don't think I agree with this, or at least, I think you have to preserve the possibility that different actions would want to use the same form definition in different scopes. I don't think that would be a very good design, because of the risk of confusion, but I'm not ready to say we should block it. I think the problem with creating a page controller is that it is coupled with the view. The component aspect of JSF seems very attractive but it would be nice if it was a solution built around the struts model and not made to fit. Well, I'll agree that it's coupled with the view, but I'm not sure that's the problem. There are going to be times when you have to do very specific things to achieve your goal. Coupling them with the view isn't a horrible thing if they are neatly encapsulated from other things, and that's the idea behind having a separate stage. I think it's more problematic to clutter up action.execute(...) with this stuff than to put it in a separate place. What if struts had a visual component framework of its own... Sounds complicated. Might be interesting. I'd like to do something sooner than later. If you have a vision for the component framework, can you help steer us on a path that gets something sooner which doesn't block the path to the more elaborate future solution? It sounds like you are describing an optional package that plugs in like tiles or the validator? I'm not sure that what we have implemented is worthy of that categorization in terms of quality but it does lie on top of struts, tiles and validator nicely. We call it rustts (anagram of struts). We used an xml document to define our page and used jsp to render the page. Like tiles, our metadata has inheritance. A page can extend another page and override the title or add a button or make a button in the super page invisible. The page is associated with other types of reusable components
Re: Reviving PageController (ViewController?) discussion?
Remember this ol' thread? http://thread.gmane.org/gmane.comp.jakarta.struts.devel/15486 Just thought I'd check in and see what folks were thinking about the view controller thing. Seems like there are a few enthusiastic folks on struts-dev now who weren't around for the last round of this discussion, or who have started speaking up more. The way I see it, the problem may be as much how to configure as how to implement. Struts-config files are already kind of complicated. There's also a question about how much more to pile on the poor RequestProcessor when the Chain ComposableRequestProcessor seems pretty close to prime-time. However, assuming we'd want to put this in the original RequestProcessor rather than wait for struts-chain to reach full maturity, here's some off-the-cuff ideas for you to shoot down Create a new interface, Renderer, strongly modeled off of Action. It would have one method: public ForwardConfig execute(ForwardConfig config, ActionForm form, HttpServletRequest request, HttpServletResponse response) throws Exception; ForwardConfig could have a form or formName property (since 'name' is already taken), and using that, the output form would be looked up more or less the way forms are now, taking advantage of some recent refactorings so that you no longer require an ActionMapping to get a form. This would give the Renderer something it could pre-populate using whatever logic and system information it needed, should it care to. The renderer could return the same ForwardConfig which was passed to it, or it could create a new one: for example, the new one might rewrite the path to include localization information (as described in the post mentioned above.) I'd want to provide a base DispatchRenderer implementation which works like MappingDispatchAction, so i'd probably want to add a 'parameter' property to ForwardConfig. I don't expect everyone to use it, but I really prefer having less classes with more behavior. It seems like it might be slightly disruptive to add properties to ForwardConfig since people may have already extended it for their own purposes. How do people rate that risk? Does the Renderer need the ability to look up global forwards? Is now a good time to coin a StrutsContext class that encapsulates the various arguments to execute? I've always kind of wanted this for Action too. I've frequently thought it would be a nice thing. This seems to get a little blurry when looking forward to a more chain-oriented Struts, where there's already a Context object floating through, but it seems worth discussing if we're making a new interface. Like I said, this is just something to shoot down... so fire away! Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com Imagine if every Thursday your shoes exploded if you tied them the usual way. This happens to us all the time with computers, and nobody thinks of complaining. -- Jef Raskin - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
--- Joe Germuska [EMAIL PROTECTED] wrote: ForwardConfig could have a form or formName property (since 'name' is already taken), and using that, the output form would be looked up more or less the way forms are now, taking advantage of some recent refactorings so that you no longer require an ActionMapping to get a form. This would give the Renderer something it could pre-populate using whatever logic and system information it needed, should it care to. The renderer could return the same ForwardConfig which was passed to it, or it could create a new one: for example, the new one might rewrite the path to include localization information (as described in the post mentioned above.) I'd be concerned about associating a form with a ForwardConfig. It's possible that the resulting view could contain more than one form needing prepopulation, and we don't want to limit the entire response chain to only prepopulate one of them, or at least imply that that's the limit. Following the use case you mentioned on the user list, where the action accepted the search keys and displays search results, the resulting view could include both the search result in a form for editing, and a form to allow the user to run another search (abandoning the current record). I personally have come across this scenario multiple times in multiple web apps I've been involved in. In such a case, (A) do we facilitate it by letting the function return another ForwardConfig which is associated with another form? Or (B) should the method just use the new createActionForm to create new forms and store them in the right scope? (A) If we use another ForwardConfig, we could reuse the one used by the original search form. It could be declared as a global forward which could be reused in all pages needing that form. Sure sounds like Tiles. This echoes the intentions mentioned in earlier threads, which is to provide this functionality to the core. This requires chaining a ForwardConfig for each form a view will need. (B) If we use createActionForm with an additional RequestUtils (ResponseUtils? oops, deprecated.) method to set a form. RequestUtils creates the blank form, the PageController populates it, and a RequestUtils method sets the form in the proper scope using the proper attribute name. Either way, it's looking like it might make sense to move the scope setting to the form definition, or at least allow a default setting there which will be honored if an action mapping doesn't specify a form scope. (Could be a topic for another thread) Could we instead define the forms as children of ForwardConfig? This seems to make more sense and doesn't imply that a view is limited to one form. form-beans form name=form1 type=o.a.s.a.DynaActionForm renderer=com.corp.Renderer1 form-property .../ /form form name=form2 type=com.corp.MyActionForm renderer=com.corp.Renderer2/ /form-beans action ... forward name=view1 form name=form1/ /forward forward name=view2 form name=form1/ form name=form2/ /forward forward name=view3 type=com.corp.PageController1/ /action The PageController would then concentrate on non-form data needed by the view. Also, maybe we can call the Renderer's method render. Like I said, this is just something to shoot down... so fire away! Joe Line this up among those to shoot down. Hubert __ Do you Yahoo!? Yahoo! Mail - More reliable, more storage, less spam http://mail.yahoo.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
Joe Germuska wrote: See Ted's recent post copied in below... I'm definitely going to look at Chain before I invest a lot of energy in a PageController that works as earlier discussions have gone. So, just to report back. I tried using view Command in place of view action. It worked fairly well at first. You end up with a number of Chains terminating in a view Command, which is fine under most circumstances. Though, it starts to get clumsy when you are bridging between flows, say from a insert flow to a display detail flow. So, I've gone back to using a view action again. Though, there's only one class that is passed the Command name as a parameter. So the view action just runs a view Command. Some frameworks, like Maverick, directly supports the notion of a page controller with its own extension point. This seems like a useful strategy for Struts to consider. The conflicting issues seem to be * We do want to give ActionForward an extension point so that it can prepare the request before forwarding to its resource. * We don't want to confuse matters by introducing another navigational decision point. Once the Action has selected an ActionForward, that ActionForward should be responsible for the response. * We don't necessarily want to introduce another class into the mix. A side issue is that it would be helpful if the framework provided better support for selecting alternate paths for an ActionForward, based on Locale or other properties (/pages/en/this.jsp vs /pages/fr/this.jsp). So, in addition to preparing the request, the ActionForward extension point might also want to adjust the path (or choose between paths provided in the configuration). No concrete proposal; I just wanted to keep this on the table. -Ted. -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reviving PageController (ViewController?) discussion?
Is the PageController going to have an associated ActionForm? When preparing to display a new page, it is often the case that I want to have access to a new action form that I can populate with default values for the HTML form to display. The action form is probably not of the same type as the action form for the previously-executed action, as that action form was having its processing completed, while this new action form is just beginning its lifecycle. Thanks. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reviving PageController (ViewController?) discussion?
At 11:41 -0400 10/16/03, Derek Richardson wrote: Is the PageController going to have an associated ActionForm? When preparing to display a new page, it is often the case that I want to have access to a new action form that I can populate with default values for the HTML form to display. The action form is probably not of the same type as the action form for the previously-executed action, as that action form was having its processing completed, while this new action form is just beginning its lifecycle. That basic idea (a different form for on-the-way-out-to-the-view than the one on-the-way-in-to-the-controller is really useful, and we've fudged something like on the current project, but I have to admit that while I've been waiting to get done with my current project and back to doing something about this conversation, it kind of looks like the struts-chain stuff is passing us by. See Ted's recent post copied in below... I'm definitely going to look at Chain before I invest a lot of energy in a PageController that works as earlier discussions have gone. Joe At 5:33 -0400 10/16/03, Ted Husted wrote: Ted Husted wrote: I think the Chain package will make it easier for people to do the Right Thing. The ActionForm properties, and so forth, can be commuted to a Context, and the Context passed up to a Chain which can do whatever it is they want to do. Just to check in ... I've been refactoring an application that started out using the page controller type actions into an architecture that uses view commands instead, and it seems to be working well. In cases where I want to forward directly to the page, I can use a single Command: command name=summary className=app.command.SummaryView / In cases where I need to do something else first, like look up a seed record or process an update, I can set up a Chain that executes the business operations first, and then runs the view command. For one interesting page, I have two chains running back to it, depending on which control is used: chain name=summary_select_applicant command className=app.command.SummaryList / command className=app.command.SummaryView / /chain chain name=summary_select_permit command className=app.command.Select / command className=app.command.SummaryList / command className=app.command.SummaryView / /chain So, in places where I had business actions forward to presentation actions, I'm now back to having command actions forward straight to the server pages again. Life is good. Ladies and gentlemen, I believe we've found the missing link =:) -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
- Original Message - From: Ted Husted [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Tuesday, September 30, 2003 6:29 AM Subject: Re: Reviving PageController (ViewController?) discussion? Jing Zhou wrote: - A well designed framework should not have overlapped concepts, or terms that lead to overlapped concepts. We have the concept of action controllers, we should not have more *controllers* when a view is under preparations. IMHO, a well-designed framework should provide extension points where developers need extensions points. Right now, we have one extension point where a developer can cleanly interject an Action. Well, since the context switch is an interface, it is an extension point by itself. What I am against here is that the context switch could return a different target ForwardConfig (or changing its logical destination page). Determining a target ForwardConfig is the core business of Action(s) before we reach the phase of preparing the view requirements for the next page. It is not a good idea to overlap the Action semantics in the context switch semantics in regard to returning a different ForwardConfig. That is the reason I think we should not have more *controllers*. Note that multiple Actions (or Commands) could be allowed before the phase of preparing the view requirements. - The class is responsible for switching module-wide settings. A ModuleSwitch(Command) would be closer to what it really does. IMHO, a large part of the problem is the assumption that there can only be one front controller. Many of the module use cases could be solved if multiple instances of the Struts controller were available in an application. One could handle the *.mod1 URIs andother another could handle the *.mod2 URIs. This approach was contrary to the initial Struts architecture, and we decided to pursue the context-switching strategy. I am not aware of the design details in your projects, but I fully agree with the context-switching strategy. If you and any developers could advise me about our plan to implement the strategy, that would be great. Here is the pseudo definition: Definition of ModuleSwitch (for the context switch interface): 1) Responsibility: Prepare the context required by the underlying business logic components for the incoming http request and the context required by the presentation components for the outgoing http response (typically a JSP page or template engine). 2) Relationship to ModuleConfig: An instance of ModuleSwitch interface has a one to one correspondence to an instance of ModuleConfig. ModuleConfig provides immutable properties while ModuleSwitch provides mutable properties for wider applicability. 3) Relationship to Chain: There are two points in a request processor Chain that could invoke the methods in ModuleSwitch. - When an incoming http request is received and the current ModuleConfig and ActionMapping is identified, a Command in the Chain should invoke a method in ModuleSwitch to prepare the context required by following Commands that are responsible to execute business logic. - When the final logical target is identified, typically in term of a ForwardConfig returned by previous Action Commands, a Command in the Chain should invoke a method in ModuleSwitch to prepare the context required by presentation components. The implementation of the method could just do in-module switch if the target is in the current module. If the target is in a different module, then out-module switch must be performed. Remark: This is an alpha idea, my gut feeling is that the existence of such interface is fully justified, of course, its name and its method signatures are to be determined and there are a lot of things to be filled. The concept of Logical Target is also introduced. The implementation could translate a logical target to a physical target when it sees fit, much like selecting a Renderer per JSF, or Theme per our project. -Ted. Jing Netspread Carrier http://www.netspread.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
Joe Germuska wrote: Looking to Struts 2.x, I am thinking that the ForwardConfig would merge with a ViewController, and that instead of the Struts action returning a ForwardConfig, it would return a logical name (String); then the details (and potential complexities) of dispatching to any chosen view technology, including any view preparation, would be entirely external to the action. Then what I'm calling a merged ForwardConfig/ViewController would actually just be another Command in the processing chain and would actually have a much less defined structure. Speaking of chains, given Ted's suggestion about just plugging in another Action class as part of the ForwardConfig -- if that were to be the case, I think I'd just be more interested in a Commons-Chain/Struts-Chain solution -- which might be better anyway, as it's more forward looking than any of my suggestions. Personally, I like returning the ForwardConfig instead of a String since it's extensible. You can always call a method to get whichever String you want, the logical name or the system path. In terms of what a framework based on Commons Chain might be like, I've made some notes here: http://cvs.apache.org/viewcvs/jakarta-commons-sandbox/chain/WHITEBOARD.html But the cool thing about Chain is that it plays well with others. You can start using a Chain solution in your Actions at any time. The Action path could be a command name keyed to the business logic. Likewise, the ActionForward name could be another command keyed to the presentation side of the business logic. (What raw materials will be needed by the controls client specified for the target page.) But, there's also another aspect to the view controller use case -- better support for i18n. The message bundles are a great start, but many applications need to branch to different paths for different locales, or even different clients. So, aside from preparing the request, we could also use a View Action to munge the path (in a new instance of ForwardConfig). Of course, the nuts-and-bolts of this process could be encapsulated in a Chain. But once you take these two related cases together, I do believe an Action extension point for the ForwardConfig would be useful and justified. We've been taking about making the forward smarter for years. Now that we have a more flexible request processor, perhaps it's time to make it smarter in the usual way, by giving it an Action class. I agree that you could collapse the business Action and the presentation Action into a single Chain. But, as much as I like Chain, I don't know if I want to present it as the final solution to this problem. Even with Chain, I might want to separate the concern of calling the business command from the concern of calling the presentation command. I might even want to put them in different catalogs. One set of Actions could be calling a standard set of DAO commands. Another might be calling a set of commands geared for the presentation layer. One might be in a JAR handed down from another team. The second might be in my WEB-INF directory. Of course, you could combine these into the same runtime catalog, but then you have to micro-manage the namespaces and all that. TANSTAFL. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
Jing Zhou wrote: - A well designed framework should not have overlapped concepts, or terms that lead to overlapped concepts. We have the concept of action controllers, we should not have more *controllers* when a view is under preparations. IMHO, a well-designed framework should provide extension points where developers need extensions points. Right now, we have one extension point where a developer can cleanly interject an Action. In practice, many developers, including myself, have found that they need to interject a second Action to prepare the request for the page. We need two extension points, because there are two decisions being made. The first is who will handle the response. The second is what material they need to handle it. I believe we all like the idea of separation of concerns, but most of also do not like splitting responsibilities. Currently, Actions are responsible for doing all the same things we want a page controller to do. So, my current suggestion is to add an extension point to ForwardConfig, so that the RequestProcess can call an Action here as well. This approach lets developers continue using the Actions we all know and love, but saves the trouble of forwarding the request through container, just to complete the response. - The class is responsible for switching module-wide settings. A ModuleSwitch(Command) would be closer to what it really does. IMHO, a large part of the problem is the assumption that there can only be one front controller. Many of the module use cases could be solved if multiple instances of the Struts controller were available in an application. One could handle the *.mod1 URIs andother another could handle the *.mod2 URIs. This approach was contrary to the initial Struts architecture, and we decided to pursue the context-switching strategy. For Struts 2, I would suggest starting with the premise that multiple Struts controllers can be available in the application, and that an action can be specified anywhere that a page or forward can be specified now. If the configuration and server pages never need to know what server pattern is being used, since they can refer only to actions, then we can accomplish modules (and I imagine portlets) by registering each player under a different URI pattern. If we add metadata inheritence, multiple configuration files, and wildcard mappings to the mix, I believe teams would be able to define and use both hierarchical modules or switched modules in the same application. One element of the front controller pattern is consistency in how incoming requests are handled, which helped to justify the there can only be one strategy. Happily, the excellent work that's been done on the RequestProcessor now makes it possible for multiple controllers to share the same customized class. So, we could have our cake and eat it too :) This is a very *vague* area that should draw many experts from different view/logic technologies to work out a common solution for all. When I was at school, my supervisor always asked me what's the state-of-the-art in your proposals. I think there is a state-of-the-art somewhere, we need to find it. In the end, we should be able to let the users to drop a jar file in WEB-INF/lib and register some settings in web.xml for new modules, and then see it working with no codes or very little custom codes. To an extent, we already have this functionality. A user can drop a WAR file into a container's directory, and presto-bango, they have a web application. The portlet spec tries to do the same sort of thing one layer down, so that you can drop a PAR file in an application with the sort of result you describe. The state-of-the-art in for portlets is our own Jetspeed project here at Jarkara (which in fact bred the proposed portlet specification). -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
At 7:28 -0400 9/30/03, Ted Husted wrote: Joe Germuska wrote: Looking to Struts 2.x, I am thinking that the ForwardConfig would merge with a ViewController, and that instead of the Struts action returning a ForwardConfig, it would return a logical name (String); then the details (and potential complexities) of dispatching to any chosen view technology, including any view preparation, would be entirely external to the action. Then what I'm calling a merged ForwardConfig/ViewController would actually just be another Command in the processing chain and would actually have a much less defined structure. Speaking of chains, given Ted's suggestion about just plugging in another Action class as part of the ForwardConfig -- if that were to be the case, I think I'd just be more interested in a Commons-Chain/Struts-Chain solution -- which might be better anyway, as it's more forward looking than any of my suggestions. Personally, I like returning the ForwardConfig instead of a String since it's extensible. You can always call a method to get whichever String you want, the logical name or the system path. Well, the string would just look up a ForwardConfig or ViewController one level out, and I figured you'd still have extensibility and configurability there. My thinking (admittedly still in progress even now) is that I don't really love the implementation of processForwardConfig because it seems to focus on a limited area of how views are rendered. Shouldn't the responsibility for seeing that a response is rendered be encapsulated in the ForwardConfig or a a more active class like ViewController, instead of having the RequestProcessor assume that forwarding is the way to dispatch to a view? I'll acknowledge that this is fairly theoretical, and practically speaking, probably 99% of actions prefer to use RequestDispatcher.forward to pass off to the view. And arguably even when we now write to the response output stream and return a null ForwardConfig, that might be best implemented in another Servlet in the WebApp, to keep Struts more a pure Controller. One small itch about just going ahead and using Action as a ViewController -- should the framework make a more explicit mechanism for communication between the controller action and the view action? Certainly, they can just agree to use well-known request attributes, but is that good enough? But once you take these two related cases together, I do believe an Action extension point for the ForwardConfig would be useful and justified. We've been taking about making the forward smarter for years. Now that we have a more flexible request processor, perhaps it's time to make it smarter in the usual way, by giving it an Action class. OK... so let's go along this line. What ActionMapping gets passed to the view Action? The same that was passed to the control Action? What if I want per-forward configuration details in the struts-config.xml? Do we need to extend ForwardConfig to have all the same configuration properties that ActionConfig has? There are some overlaps, so that could be tricky. I do like the possibility that the ActionForm passed in to the view action could be the one which will be presented on the view page, instead of the one which was populated from request parameters -- this solves the very common problem of people needing to pre-fill a form. There's still the question of who instantiates and manages the view action instances; I guess it would be ActionMapping? Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
it working with no codes or
very little custom codes.
Anybody who is working in this area, I am willing to
provide my help to fine tune concepts, proposals,
and potential codes.
Jing
Netspread Carrier
http://www.netspread.com
When we find it, we decouple it.
When we use it, we integrate it.
- Original Message -
From: Joe Germuska [EMAIL PROTECTED]
To: Struts Developers List [EMAIL PROTECTED]
Sent: Sunday, September 28, 2003 4:55 PM
Subject: Re: Reviving PageController (ViewController?) discussion?
I've been thinking about this a bit; as I see it now, some
implementation choices might be a little contentious, so I feel like
the right approach is discuss first, code later.
Below is my interpretation of the interface based on earlier
discussion and such. Note that I suggest we change the name from
PageController to ViewController, although I don't feel very
strongly about it. It's just one method (plus some javadoc to flesh
out the idea.)
package org.apache.struts.action;
public interface ViewController {
/**
* pPerform any view-level preparations after an [EMAIL PROTECTED] Action}
has executed
* and before the display is rendered. Return a [EMAIL PROTECTED]
ForwardConfig}
* instance describing where and how control should be forwarded, or
* codenull/code if the response has already been completed./p
*
* pIn the simplest case, where an implementation only modifies the
* request context, the return value may be the same as the
codeForwardConfig/code
* provided as an argument. However, note that implementations
should not
* directly modify the given ForwardConfig if it is not the
appropriate
* return value; they must instead return a new instance
* (or an implementation-level cached instance)./p
*
* @param forward The ForwardConfig in whose context this controller
is
* being invoked.
* @param request The HTTP request we are processing
* @param response The HTTP response we are creating
* @return a ForwardConfig which will be used for final view
dispatch,
* or null if the response has already been completed
* @exception Exception if the view preparation process throws
* an exception
*/
public ForwardConfig prepareView(
ForwardConfig forward,
HttpServletRequest request,
HttpServletResponse response)
throws Exception;
I think it's important (as noted in the JavaDoc) to help people
understand that they can't change a frozen ForwardConfig. (I kind
of feel like this belongs more in something like o.a.s.view, but if
it's going to be the only class there...)
At 10:31 -0400 9/15/03, Ted Husted wrote:
I'll post more on this later, but to avoid the gotcha, I'm now
thinking we should try this using a modified
ActionMapping.findForward method. In that way, all the navigational
control stays within the Action.
The part that seems like it might raise some discussion is about who
manages the ViewControllers. It seems wasteful to instantiate one
each time a view is dispatched. So then does the base ActionMapping
cache ViewControllers? If that's the case, then what about
Module-level global forwards? You could make a simple support
class that wrapped up the instantiation and caching and have it
available to ActionMapping and implementations of ModuleConfig -- and
just to note, the fact that ModuleConfig is an interface leaves open
the risk that existing implementations wouldn't implement the new,
more complex contract of findForwardConfig.
I guess I'm waiting to hear more on Ted's teaser; I'm not sure I see
the gotcha that makes hiding this behavior in ActionMapping better
than making it the responsibility of the RequestProcessor, which
seems like a clearer place to put a single cache of ViewController
classes -- which seems to be how Tiles works.
If people want to weigh in on this, I'll distill the discussion into
draft code once we think the path is clear.
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
We want beef in dessert if we can get it there.
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
At 1:24 -0500 9/29/03, Jing Zhou wrote: From an earlier discussion (Where is Struts 2 going?), I could see people kind of agree with the following picture. Thanks for the thorough and thoughtful response/contribution to the discussion. I want to point out that my post is presented in the context of something that is reasonable to do in Struts 1.x, whether or not it is the most ideal design. I'm interested in talking about Struts 2 also, but my proposal is intended more for fitting-in than for being ideal. The design goal of the PC/VC is to prepare the *required* settings for the next view. The intention is fully justified, but we have too many questions as Joe pointed out below. Now I encourage people to think as a businessman. When you are using a set of view components in a web application, you find you need another set of view components from a different vendor, how do you combine them in one web application easily? Is this possible? Yes, if Struts 2 could provide an integratable environment along the concept of modules. I'm not sure I understand your distinctions between module and application. As Struts is now, I don't think things break down the way you describe them. Are you talking about Struts 2, or do we just have different models of the responsibilities for the Application and the Module? Our research shows that every kind of presentation could have two basic settings, application-wide settings and module-wide settings. The Chain takes care of the application-wide settings, the ModuleConfig (and some other interfaces) takes care of the module-wide settings. The vendors package their view components as a set of modules with minimum requirements on application-wide settings for maximum compatibility with other vendors. OK, so am I to understand that you'd propose that any given Module would be responsible for either business or view control, but not both? Interesting. I'm not sure I agree yet, but then, one of my original responses after reading your message was to suggest that the View Controller should be implemented as a separate servlet. (In a purely technical sense, that's what JSPs are, and that's how the Velocity integration works too, and my current co-developer was talking about installing a second ActionServlet along these lines earlier in our project...) I'll have to think about it some more; I am kind of concerned that configuring and coordinating between two Modules (or two Servlets) will be relatively complicated. That may be too much separation-of-concerns. But it's worth thinking about. I think it works with JSPs and Velocity because the domain of those servlets are so well defined. So the thing is not that *simple*. For example, what the future ForwardConfig will look like in order to accommodate a variety of presentation technologies? Looking to Struts 2.x, I am thinking that the ForwardConfig would merge with a ViewController, and that instead of the Struts action returning a ForwardConfig, it would return a logical name (String); then the details (and potential complexities) of dispatching to any chosen view technology, including any view preparation, would be entirely external to the action. Then what I'm calling a merged ForwardConfig/ViewController would actually just be another Command in the processing chain and would actually have a much less defined structure. Speaking of chains, given Ted's suggestion about just plugging in another Action class as part of the ForwardConfig -- if that were to be the case, I think I'd just be more interested in a Commons-Chain/Struts-Chain solution -- which might be better anyway, as it's more forward looking than any of my suggestions. Joe -- Joe Germuska [EMAIL PROTECTED] http://blog.germuska.com We want beef in dessert if we can get it there. -- Betty Hogan, Director of New Product Development, National Cattlemen's Beef Association - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Reviving PageController (ViewController?) discussion?
I've been following this thread and solicited you opinions individually. I thought I might throw out some ideas. We have developed a struts plug-in that we called rustts (see attachment). It has properties of a page controller and view controller. We implemented the page controller as a subclass of the DispatchAction class. It combines principles of the DispatchAction and LookupDispatchAction. This controller handles the creation of various types of model classes that are associated with visual components thru our struts extension XML file. The visual components are defined through xml entries which support metadata inheritance, much like tiles. Each visual component can be associated with a model class that controls visual aspects such as if the visual element should be displayed. The composition of visual components on a page is defined in the extension XML file. The page XML element, being the outermost visual element, is associated with the struts action using a custom attribute in a subclass of ActionMapping. We have created view helpers that we use within JSP fragments that are pulled together using tiles. These view helpers use the metadata and the associated modules to render the view. Currently the helpers make heavy use of scriptlet. Eventually we could build custom tags that use the helpers to render the page but we like the ability to quickly change the skin of a visual element. For example we have a vertical menu and horizontal menu that use the same helper to render a different presentation. These view helpers could also be used by velocity to render a presentation. We have extended the ActionMapping and ActionForward classes to simplify propagation of properties in the form bean to the target page. action path=/docInfoCategoryEdit name=DocInfoCategoryForm validate=true input=.dynaPage scope=request parameter=cmd type=com.rustts.action.RusttsDispatchAction className=com.rustts.action.RusttsActionMapping set-property property=pageId value=docInfoCategoryEditPage/ forward name=quit path=/Welcome.do redirect=true className=com.rustts.action.RusttsForwardAction set-property property=arg6 value=dcDivision / /forward !-- next button -- forward name=save-success path=/docInfoType.do redirect=false className=com.rustts.action.RusttsForwardAction set-property property=arg1 value=drId / set-property property=arg2 value=dcCode / set-property property=arg3 value=drName / set-property property=arg4 value=drComment / set-property property=arg5 value=drOrigIndic / set-property property=arg6 value=dcDivision / /forward !-- validate button -- forward name=add-success path=/docInfoCategoryValidate.do redirect=false className=com.rustts.action.RusttsForwardAction set-property property=arg1 value=drId / set-property property=arg6 value=dcDivision / /forward /action Each model has a public interface that provides callback methods that can be implemented to conditionally effect different aspects about a page or how a visual component behaves within a page. We have extended the TilesRequestProcessor to cache the metadata loaded by our plugin in request scope making it available to other resources. Our extension sits on top of struts and is really where we came up with the name rustts. Besides being an anagram of Struts, our vision was that rust is a natural byproduct of metal structures of impressive stature, and that often rust is most visible where the struts are joined. Regards, Gary -Original Message- From: Ted Husted [mailto:[EMAIL PROTECTED] Sent: Sunday, September 28, 2003 8:13 PM To: Struts Developers List Subject: Re: Reviving PageController (ViewController?) discussion? Here's a third idea: Instead of creating a new class, we could just associate an Action class with the ActionForward. This is what people do now anyway. It seems to work, but wastes an ActionMapping and trip through the container. So, we just add a type property to ActionForward, and a step to the RequestProcessor to handle it when available. If it's there, it gets called, and the RequestProcess forward to the path. If it's not there, the RP forwards to the path given by the original forward. Everything else remains the same. I'm sure some people will misuse the feature, but some people will always misuse any feature. At least this way, we recognize what most people (including me) already do most of the time, put an Action in front of page. The advantage being that we don't have to waste an ActionMapping or a trip
Re: Reviving PageController (ViewController?) discussion?
- Original Message - From: Joe Germuska [EMAIL PROTECTED] To: Struts Developers List [EMAIL PROTECTED] Sent: Monday, September 29, 2003 9:37 AM Subject: Re: Reviving PageController (ViewController?) discussion? Thanks for the thorough and thoughtful response/contribution to the discussion. I want to point out that my post is presented in the context of something that is reasonable to do in Struts 1.x, whether or not it is the most ideal design. I'm interested in talking about Struts 2 also, but my proposal is intended more for fitting-in than for being ideal. I understand that. In the past, there were many things that people thought very *important*. But after a while, the things could become not that *important* or totally irrelevant. So sometime, born-to-be-deprecated classes could be invented. That's the thing I would like to avoid. People could produce something in Struts 1.x that is still in line with Struts 2.x. I'm not sure I understand your distinctions between module and application. As Struts is now, I don't think things break down the way you describe them. Are you talking about Struts 2, or do we just have different models of the responsibilities for the Application and the Module? The application here refers to a web application as defined by the Java Servlet Specification which corresponds to a ServletContext. The module here refers to the resources covered by a ModuleConfig as defined in Struts. When you set up things in a ServletContext, they are application-wide settings. When you set up things in a ModuleConfig, they are considered as module-wide settings. The important things for ModuleConfig is that better organized solutions should be packaged in modules so that different packaged solutions could work peacefully in one web application. Our research shows that every kind of presentation could have two basic settings, application-wide settings and module-wide settings. The Chain takes care of the application-wide settings, the ModuleConfig (and some other interfaces) takes care of the module-wide settings. The vendors package their view components as a set of modules with minimum requirements on application-wide settings for maximum compatibility with other vendors. OK, so am I to understand that you'd propose that any given Module would be responsible for either business or view control, but not both? No. Module-wide settings could serve both presentation components and business logic components. So the thing is not that *simple*. For example, what the future ForwardConfig will look like in order to accommodate a variety of presentation technologies? Looking to Struts 2.x, I am thinking that the ForwardConfig would merge with a ViewController, and that instead of the Struts action returning a ForwardConfig, it would return a logical name (String); then the details (and potential complexities) of dispatching to any chosen view technology, including any view preparation, would be entirely external to the action. Then what I'm calling a merged ForwardConfig/ViewController would actually just be another Command in the processing chain and would actually have a much less defined structure. That could be possible. But in the meanwhile, we do not want Struts 2 to be reduced into a-few-line framework. Some heavy duty work has to be done somewhere. Speaking of chains, given Ted's suggestion about just plugging in another Action class as part of the ForwardConfig -- if that were to be the case, I think I'd just be more interested in a Commons-Chain/Struts-Chain solution -- which might be better anyway, as it's more forward looking than any of my suggestions. Yes. You could switch the module settings in a Command by invoking the method in the interface. Joe Jing - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
I've been thinking about this a bit; as I see it now, some
implementation choices might be a little contentious, so I feel like
the right approach is discuss first, code later.
Below is my interpretation of the interface based on earlier
discussion and such. Note that I suggest we change the name from
PageController to ViewController, although I don't feel very
strongly about it. It's just one method (plus some javadoc to flesh
out the idea.)
package org.apache.struts.action;
public interface ViewController {
/**
* pPerform any view-level preparations after an [EMAIL PROTECTED] Action}
has executed
* and before the display is rendered. Return a [EMAIL PROTECTED] ForwardConfig}
* instance describing where and how control should be forwarded, or
* codenull/code if the response has already been completed./p
*
* pIn the simplest case, where an implementation only modifies the
* request context, the return value may be the same as the
codeForwardConfig/code
* provided as an argument. However, note that implementations should not
* directly modify the given ForwardConfig if it is not the appropriate
* return value; they must instead return a new instance
* (or an implementation-level cached instance)./p
*
* @param forward The ForwardConfig in whose context this controller is
* being invoked.
* @param request The HTTP request we are processing
* @param response The HTTP response we are creating
* @return a ForwardConfig which will be used for final view dispatch,
* or null if the response has already been completed
* @exception Exception if the view preparation process throws
* an exception
*/
public ForwardConfig prepareView(
ForwardConfig forward,
HttpServletRequest request,
HttpServletResponse response)
throws Exception;
I think it's important (as noted in the JavaDoc) to help people
understand that they can't change a frozen ForwardConfig. (I kind
of feel like this belongs more in something like o.a.s.view, but if
it's going to be the only class there...)
At 10:31 -0400 9/15/03, Ted Husted wrote:
I'll post more on this later, but to avoid the gotcha, I'm now
thinking we should try this using a modified
ActionMapping.findForward method. In that way, all the navigational
control stays within the Action.
The part that seems like it might raise some discussion is about who
manages the ViewControllers. It seems wasteful to instantiate one
each time a view is dispatched. So then does the base ActionMapping
cache ViewControllers? If that's the case, then what about
Module-level global forwards? You could make a simple support
class that wrapped up the instantiation and caching and have it
available to ActionMapping and implementations of ModuleConfig -- and
just to note, the fact that ModuleConfig is an interface leaves open
the risk that existing implementations wouldn't implement the new,
more complex contract of findForwardConfig.
I guess I'm waiting to hear more on Ted's teaser; I'm not sure I see
the gotcha that makes hiding this behavior in ActionMapping better
than making it the responsibility of the RequestProcessor, which
seems like a clearer place to put a single cache of ViewController
classes -- which seems to be how Tiles works.
If people want to weigh in on this, I'll distill the discussion into
draft code once we think the path is clear.
Joe
--
Joe Germuska
[EMAIL PROTECTED]
http://blog.germuska.com
We want beef in dessert if we can get it there.
-- Betty Hogan, Director of New Product Development, National
Cattlemen's Beef Association
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Reviving PageController (ViewController?) discussion?
Here's a third idea:
Instead of creating a new class, we could just associate an Action class
with the ActionForward. This is what people do now anyway. It seems to
work, but wastes an ActionMapping and trip through the container.
So, we just add a type property to ActionForward, and a step to the
RequestProcessor to handle it when available. If it's there, it gets
called, and the RequestProcess forward to the path. If it's not there,
the RP forwards to the path given by the original forward. Everything
else remains the same.
I'm sure some people will misuse the feature, but some people will
always misuse any feature. At least this way, we recognize what most
people (including me) already do most of the time, put an Action in
front of page. The advantage being that we don't have to waste an
ActionMapping or a trip through the container just to forward to the page.
-Ted.
Joe Germuska wrote:
I've been thinking about this a bit; as I see it now, some
implementation choices might be a little contentious, so I feel like the
right approach is discuss first, code later.
Below is my interpretation of the interface based on earlier discussion
and such. Note that I suggest we change the name from PageController
to ViewController, although I don't feel very strongly about it. It's
just one method (plus some javadoc to flesh out the idea.)
package org.apache.struts.action;
public interface ViewController {
/**
* pPerform any view-level preparations after an [EMAIL PROTECTED] Action}
has executed
* and before the display is rendered. Return a [EMAIL PROTECTED] ForwardConfig}
* instance describing where and how control should be forwarded, or
* codenull/code if the response has already been completed./p
*
* pIn the simplest case, where an implementation only modifies the
* request context, the return value may be the same as the
codeForwardConfig/code
* provided as an argument. However, note that implementations
should not
* directly modify the given ForwardConfig if it is not the appropriate
* return value; they must instead return a new instance
* (or an implementation-level cached instance)./p
*
* @param forward The ForwardConfig in whose context this controller is
* being invoked.
* @param request The HTTP request we are processing
* @param response The HTTP response we are creating
* @return a ForwardConfig which will be used for final view dispatch,
* or null if the response has already been completed
* @exception Exception if the view preparation process throws
* an exception
*/
public ForwardConfig prepareView(
ForwardConfig forward,
HttpServletRequest request,
HttpServletResponse response)
throws Exception;
I think it's important (as noted in the JavaDoc) to help people
understand that they can't change a frozen ForwardConfig. (I kind of
feel like this belongs more in something like o.a.s.view, but if it's
going to be the only class there...)
At 10:31 -0400 9/15/03, Ted Husted wrote:
I'll post more on this later, but to avoid the gotcha, I'm now
thinking we should try this using a modified ActionMapping.findForward
method. In that way, all the navigational control stays within the
Action.
The part that seems like it might raise some discussion is about who
manages the ViewControllers. It seems wasteful to instantiate one each
time a view is dispatched. So then does the base ActionMapping cache
ViewControllers? If that's the case, then what about Module-level
global forwards? You could make a simple support class that wrapped
up the instantiation and caching and have it available to ActionMapping
and implementations of ModuleConfig -- and just to note, the fact that
ModuleConfig is an interface leaves open the risk that existing
implementations wouldn't implement the new, more complex contract of
findForwardConfig.
I guess I'm waiting to hear more on Ted's teaser; I'm not sure I see the
gotcha that makes hiding this behavior in ActionMapping better than
making it the responsibility of the RequestProcessor, which seems like a
clearer place to put a single cache of ViewController classes -- which
seems to be how Tiles works.
If people want to weigh in on this, I'll distill the discussion into
draft code once we think the path is clear.
Joe
--
Ted Husted,
Junit in Action - http://www.manning.com/massol/,
Struts in Action - http://husted.com/struts/book.html,
JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512.
Get Ready, We're Moving Out!! - http://www.clark04.com
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
