> On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted wrote: > > On Tue, 26 Oct 2004 12:50:05 -0700, Craig McClanahan wrote: > > > My personal itch is to not have to build everything from scratch -- > > > its to build on the JSF request processing lifecycle, without > > > committing you to any particular view tier templating approach. > > > Doing more work than that is ... more work. > > > > Granted that Shale will be painful to implement without the support of another > framework, like JavaServer Faces, could we still position JSF as one possible > implementation of Shale. > > > > For example, instead of an "impl" folder, could we have a "faces" folder? > > > > I don't see the point in doing this now -- if a reasonable non-JSF > approach is shown to be viable and accepted by the community we can > always do it later. I haven't seen enough yet to make me think this > is viable without compromising the simplicity of the current approach. > > > And would it be all right if I reorganized the API JavaDoc for ViewController > to distinguish between the "abstract" responsibilities of the interface and what > happens when an ViewController implementation is wired to JSF? > > Abstracting when the init/prepare/destroy methods are called and what > they do would not be that hard, although you're going to need a bunch > of things to make ViewController actually usable without presuming > JSF: > > * The notion of a "view identifier" that maps to both the > view tier presentation (typically a JSP page) and the > corresponding ViewController class. > > * A mechanism for performing validations and handling > validation error messages. > > * Some method that gets invoked when, say, a submit > button is pressed that triggers your business logic. > > * A mechanism for a ViewController to request that its own > view get redisplayed, or to navigate to a different view id. > > All of the above are already provided by JSF, but necessary in a non-JSF world. > > Basically, I'm really curious how you propose to abstract out the > "Standard JSF processing and event handling is performed" part without > essentially re-inventing a JSF-like lifecycle. If you try to impose > those abstractions onto the basic ViewController API then I would > likely be -1 because they are redundant to using the framework *with* > JSF. You could create a NonFacesViewController abstraction on top of > ViewController if you wanted, but by that point we might as well > create two separate frameworks instead of one. > What if a component based presentation solution could be found that built on the current features of struts and only focused on the view layer? Strut’s already has a flavor of managed beans, converters, error messages, localization, actions and declarative navigation rules. JSF provides all of these things in addition. I think it would be interesting to see a solution that was built for struts only focusing on rendering the view but not specifically tied to a single view solution. 1) Restore View – Use a custom Request Processor to load a view tree in request scope. The view id could be a simple attribute that was associated with an extended ActionMapping. The view id could be associated with each struts action. The composition of a presentation fragment could be build from a XML source. The XML definitions could define display elements that could act as a container or a component. The definition could support inheritance and composition. Each visual element could be associated with a model class much the same way the action is linked in the struts config. The metadata could be loaded/digested and references fixed up at startup using a plug-in. The resources stored in application scope. 2) Apply Request Values – Struts already handle the population of the form bean with values form the request. It handles some data conversion. A system to define unique names for a reusable component mapped into the form bean would be needed. JSF uses at component id which is a name qualified by the containment in the component tree. 3) Process Validation - Struts already provides a declarative validation mechanism. 4) Update Model Values, Invoke Application - A custom view controller could delegate to all the models in the component tree. The view controller, like the LookupDispatchAction and DispatchAction, would need to have a strategy of mapping command to methods or command classes. The component tree would already be staged in request scope from the request processor. The view controller could use the static view definition and create instances of model classes associated with each view element. The controller would need to broadcast too all the model classes. 5) Render Response – The action could forward to the view component. The view component would use the component tree metadata and simple helper classes to render the view. The view helper would enumerate metadata and render the view. They could be use in JSP, Custom JSP tags or Velocity templates. The view helpers could fire back on the custom models to conditionally control rendering. The focus of the visual component base solution would be to create a XML definition, backed beans, and an abstract factory/ cache to manage the resources. Create a view controller or action class that knows how to use the metadata to manage corresponding model classes. And view helpers that would encapsulate the call back to the models when generating a presentation. It’s not as sexy as faces? Thanks for listening…
Gary > > > > -Ted. > > > > > > Craig > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] >
