Why is it not possible for the framework to use interfaces into which JSF can be plugged in, perhaps with adapters, as an option well as other alternatives? This too is not a rhetorical question.
Jack On Thu, 28 Oct 2004 10:16:56 -0700, Craig McClanahan <[EMAIL PROTECTED]> wrote: > > > 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] > > -- "You can't wake a person who is pretending to be asleep." ~Native Proverb~ "Each man is good in His sight. It is not necessary for eagles to be crows." ~Hunkesni (Sitting Bull), Hunkpapa Sioux~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
