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]