>> >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 like menus and resultsets and display elements. The content of the page can be completely defined using an xml definition. The display elements are the coolest part because they have both characteristics of the gui metaphor, inheritance and aggregation. We read in our xml files using a struts plugin and cache our metatdata in application scope. We resolve the inheritance at startup. Gui frameworks like Delphi's VCL used a metadata schema to define the properties of a visual form. Even the events where fixed-up dynamically. Using XML to define the page instead of HTML would not be for the RAD developers unless there was a nice tool to manage it. I think that the capabilities could be greater, take tiles for example. I would love to see struts actions and DynaForms have inheritance. We use sequence ids to define the "unique signatures" for our metadata inheritance. The Comparable interfaces and the TreeSet collection kindly do most of the work in resolving the heritage. We have these reusable jsp fragments that use the helpers on top of the struts tags. I suppose that if we had the courage, we could have tried to duplicate the functionality of all the struts tags but we didn't. However, by keeping them as jsp scriplet, we can quickly make a horizontal menu a vertical menu or a left navbar, all using the same menu helper. These helpers could be used by other template engines or used in custom tags. The development that we have been using this framework for is CRUD based. I'm not sure that it would be everything to everyone like the struts baseline. I suppose the concept could be described as the J2EE Service to Worker pattern. You can see an example DTD here: http://www.sos.state.co.us/dtd/struts-extension.dtd. I'm not sure if this kind of extension would be attractive? If so, it could be made more generic. I'm sure that you would need to see a living/breathing example to make a better opinion? Gary --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
