> 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] 
> 

Reply via email to