On Thu, 28 Oct 2004 07:08:40 -0400, Ted Husted <[EMAIL PROTECTED]> 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. > > -Ted. > > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
