I think that's Ted's basic point. My answer is to consider how much extra machinery you have to build in to the Struts abstraction of what a ViewController is so that an application built on top of Struts can use different technologies.
Just as one example out of my list from the previous email ... how does a ViewController say "I want to switch to a new view"? With JSF that's easy ... support for navigation is built in based on the string value that's returned by your action mapping, which is processed through the navigation rules that you've defined in faces-config.xml to pick the next view. Without JSF, someone is going to have to build in a way for a ViewController to ask for that -- and that's redundant work. Part of the potential confusion here is based on the fact that JSF isn't just a dynamic rendering technology. Indeed, JSF itself is agnostic whether you want to use JSP pages or Velocity (although you'll need to provide your own ViewHandler plugin for the latter case, but it's not tough to write one). The key difference is that JSF already has a well defined request processing lifecycle built in, following the Front Controller design pattern in a manner fairly similar to the way that Struts currently works. I want to leverage that instead of abstracting it out or reinventing it -- JSF's already good enough. Craig On Thu, 28 Oct 2004 10:23:37 -0700, Dakota Jack <[EMAIL PROTECTED]> wrote: > 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]
