Fwd: Struts Shale
Oops ... meant to reply to both Jack and the list. Craig -- Forwarded message -- From: Craig McClanahan [EMAIL PROTECTED] Date: Thu, 28 Oct 2004 10:19:48 -0700 Subject: Re: Struts Shale To: Dakota Jack [EMAIL PROTECTED] On Thu, 28 Oct 2004 06:51:32 -0700, Dakota Jack [EMAIL PROTECTED] wrote: How could there be a reason not to do this? (This is not a rhetorical question.) Ted can correct my understanding of his position if I'm wrong, but basically he wants Struts to be view tier agnostic. I'll agree with that on the actual technology used to implement the dynamic rendering (JSF lets you do that already), but not on abstracting the entire request processing lifecycle. JSF already provides a solid foundation on which to build application level controller facilities, and I see no point in re-inventing that part. Jack Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Struts Shale
On Thu, 28 Oct 2004 13:57:15 -0400, Ted Husted wrote: ... that we rename the package called impl as faces. As to the impl package: I think what really bothers me here is that the classes implemented here are not part of the Shale API. As soon as I saw ImplViewHandler, I starting looking around for a Shale ViewHandler interface. :) Of course, it is not a Shale interface, but a Faces interface. So far, all of the members here extend Faces interfaces or classes. To me, impl says we're implementing the interfaces for the Shale layer (rather than the Faces layer). Naming this package faces clarifies that it contains classes that are dependant on the lower-level Faces API, as opposed to the higher-level Shale API. What I would suggest is that we call the package faces, and the member classes: * ShaleApplicationFilter * ShaleConstants * ShalePhaseListener * ShaleViewHandler I'm thinking that in an import statement * org.apache.shale.ViewController * org.apache.shale.faces.ShaleApplicationFilter would clearly say who's riding whom. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Struts Shale
On Thu, 28 Oct 2004 14:30:33 -0400, Ted Husted [EMAIL PROTECTED] wrote: On Thu, 28 Oct 2004 13:57:15 -0400, Ted Husted wrote: ... that we rename the package called impl as faces. As to the impl package: I think what really bothers me here is that the classes implemented here are not part of the Shale API. As soon as I saw ImplViewHandler, I starting looking around for a Shale ViewHandler interface. :) Of course, it is not a Shale interface, but a Faces interface. So far, all of the members here extend Faces interfaces or classes. To me, impl says we're implementing the interfaces for the Shale layer (rather than the Faces layer). Naming this package faces clarifies that it contains classes that are dependant on the lower-level Faces API, as opposed to the higher-level Shale API. What I would suggest is that we call the package faces, and the member classes: * ShaleApplicationFilter * ShaleConstants * ShalePhaseListener * ShaleViewHandler I'm thinking that in an import statement * org.apache.shale.ViewController * org.apache.shale.faces.ShaleApplicationFilter would clearly say who's riding whom. Yah, I can buy that argument. Feel free to refactor. By the way, I'm about 50% done with making mailreader work just on top of ViewController (i'll refactor my imports as needed when you make those changes). That will give us a starting point for seeing what applications built on this thing could look like - even without all the dialog and application level stuff. Craig - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Fwd: Struts Shale
Ted Husted wrote: On Thu, 28 Oct 2004 13:57:15 -0400, Ted Husted wrote: ... that we rename the package called impl as faces. As to the impl package: I think what really bothers me here is that the classes implemented here are not part of the Shale API. As soon as I saw ImplViewHandler, I starting looking around for a Shale ViewHandler interface. :) Of course, it is not a Shale interface, but a Faces interface. So far, all of the members here extend Faces interfaces or classes. To me, impl says we're implementing the interfaces for the Shale layer (rather than the Faces layer). Greetings: I have not had a chance to look at the Shale API yet, but i already play around with the idea of controller and adapters. To me, the view handler (either you use JSF which is available now or future framework) is only 1 part of the adapters to manage services that use HTTP/HTTPS ports. Other services that use the ports are WebService, WebDAV, JMXRemote. It makes sense for Shale API to handle all standard services using HTTP/HTTPS by providing a centralized service requester and service router that routes the incoming services to appropriate adapter (view adapter for browser and mobile devices, webService adapter, webDAV adapter and JMXRemote adapter). Is there any one thinking along this line? BaTien DBGROUPS Naming this package faces clarifies that it contains classes that are dependant on the lower-level Faces API, as opposed to the higher-level Shale API. What I would suggest is that we call the package faces, and the member classes: * ShaleApplicationFilter * ShaleConstants * ShalePhaseListener * ShaleViewHandler I'm thinking that in an import statement * org.apache.shale.ViewController * org.apache.shale.faces.ShaleApplicationFilter would clearly say who's riding whom. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] . - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
