Re: [Mav-user] Pico-enabled Controllers?
On Fri, 2003-11-07 at 07:06, Ted Husted wrote: One of the things I like best about Maverick is that it is clearly focused on providing a standard front controller, a key problem that neither Java, .NET, nor PHP want to address (for some reason). Many projects start to sprawl, which seems to cause more problems than it solves. But, Maverick has retained a very clear focus. I couldn't agree with this more. Jeffs commitment to keeping the core of the product focused on the key problem it is trying to solve is one of Mavericks greatest strengths. -k. -- If you don't test then your code is only a collection of bugs which apparently behave like a working program. Website: http://blogs.codehaus.org/people/kevin/ Pub Key: http://blogs.codehaus.org/people/kevin/public.asc signature.asc Description: This is a digitally signed message part
RE: [Mav-user] Pico-enabled Controllers?
Cool... what's a picocontainer? :-) PicoContainer is an implementation of the inversion of control (or IoC) pattern. PicoContainer developers call it IoC type 3 (that is constructor managed dependencies). PicoContainer is just a container that can be populated with components (components are just plain old java objects). Components can have dependencies on other components. For example UserManager component might depend on DataSource or Hibernate Session component (some might not call these components, but I think that they work as components as well as any other self made pojos) etc. Or some service ie. imaginary JMS Service might depend on configuration component or configuration parameters like Strings and other basic stuff that it needs for it's initialization. What PicoContainer does is that it manages these dependecies for you (and Lifecycle - by implementing some or all the lifecycle methods - if needed). You just register components to your PicoContainer and PicoContainer then initializes them whenever they are needed. It's not any magic, it's just a simple component management system (management can be seen as a big word, but in this case is just component initialization that is constructing components with some constructor parameter(s) and automatic handling of that construction and dependencies) (you do not need to know the order of component construction, PicoContainer does it for you). PicoContainer can be then stored to whatever context you like, for example in ServletContext or JNDI. Users can then request these components (or sometimes called as Services) from PicoContainer and use them. To make things pluggable and configurable, interface based design is a plus. You can then change your implementation and let your Maverick Controllers use the interface. You just create components that are usually reusable in many context (not only in maverick or some other framework). With PicoContainer it's easy to decouple you business logic from Maverick controllers. This decoupling leads to a benefit that these components are not depended on anything other than maybe other components and sometimes some parameters. You can definately do everything I mentioned without PicoContainer or any other IoC implementation by yourself, but PicoContainer or Sping IoC (or some other) makes it a little bit more simple. I do no see how this should be integrated in maverick as any user can just make their own implemenation of for example Servlet and then just place this container in whatever context they like. I see there is possibility to integrate it with controllers so that controllers are like components and get their dependencies from PicoContainer but I do no see that much added value in that as users can always request the container from servlet/session/request context (or maybe you can use static singleton) and then just use PicoContainer to retrieve the needed components and use them. Infact this integration just ties components with maverick. What maverick needs is something that helps you with Web development. Ie. Velocity macro libraries, Java tag libraries, and something that helps you with input parameter validation. I know that Ted has worked with FormProc implementation, but maybe FormProc is not what users are looking at. It's a good library, but something more tightly integrated with maverick would be nice. Regards Aapo --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ [INVALID FOOTER]
Re: [Mav-user] Pico-enabled Controllers?
Aapo Laakkonen wrote: What maverick needs is something that helps you with Web development. Ie. Velocity macro libraries, Java tag libraries, and something that helps you with input parameter validation. I know that Ted has worked with FormProc implementation, but maybe FormProc is not what users are looking at. It's a good library, but something more tightly integrated with maverick would be nice. The stock Velocity tools and macros and JSTL libraries work just fine with Maverick. As, I'm sure, will JavaServer Faces when it ships. A couple of years ago, a framework may have needed to roll their own JSP tags, but those days have passed. (At least for 2.3 containers.) The FormProc integration is actually quite tight, especially if you can use a Map (or Context) as the Model. You can define the parameters needed in the FormProc XML and just use a stock Maverick controller. FormProc takes care of ensuring that only the parameters you want are harvested, as well as transforming the parameters into the desired datatype. If validation fails, the CVS version can now return the original parameter map, so you can populate the controls again. Though, FormProc is just one cog in the gear. :) In my own current development, I'm using Velocity, FormProc, Maverick, Commons Chain, iBATIS DAO, and iBATIS SqlMap. Together, these are an absolutely dynamite combination. Happily, the current phase of our project is a application for managing a user database on Jetty or Tomcat. Since this application is generally useful, I'll be able to share the final result, and provide a tour of how it all fits together. One of the things I like best about Maverick is that it is clearly focused on providing a standard front controller, a key problem that neither Java, .NET, nor PHP want to address (for some reason). Many projects start to sprawl, which seems to cause more problems than it solves. But, Maverick has retained a very clear focus. A definite issue with the proliferation of XML-configured products, like five of the six I mentioned, is juggling the elements. But that's something that we can solve with IDE plugins, or a master seedling configuration that loaded the object graph a product expected from a master document. -Ted. -- Ted Husted, Junit in Action - http://www.manning.com/massol/, Struts in Action - http://husted.com/struts/book.html, JSP Site Design - http://www.amazon.com/exec/obidos/ISBN=1861005512. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ [INVALID FOOTER]
Re: [Mav-user] Pico-enabled Controllers?
Schnitzer, Jeff wrote: Cool... what's a picocontainer? :-) Oh, come on Jeff, is Google down or something? =:) http://www.picocontainer.org/ Dyn, can you make this available for download someplace? -Ted. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ [INVALID FOOTER]
[Mav-user] Pico-enabled Controllers?
Hi, please enlighten me a bit, is it possible to plug a new ControllerFactory dynamically into Maverick? I'd love to use PicoContainer-enabled maverick controller classes, so my controllers could get initialized with the business components I have in pico in IoC3 style. I created a custom Dispatcher class which initializes the picocontainer (so controllers can reach it through the servlet context), but I'd really love to use a custom controllerfactory.. Is there anyone using Maverick this way with picocontainer? Also, anyone who would be interested in such a feature? I guess adding pico-compatibility would be quite popular for the masses these days :) Openions? dyn -- .Digital.Yearning.for.Networked.Assassination.and.Xenocide --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ [INVALID FOOTER]
