There have been discussions about modularizing the ControllerFactory in the past but there was just never a compelling reason to do it. Maybe it's time.
I should have DSL in a week or two and can do some experimentation then. Otherwise, if someone else wants to take a stab at it, feel free. I imagine that ControllerFactories would be configured very much like the other factories. As you mentioned, the framework does already allow for some amount of controller composition. If the flexibility of controller factories is meant to address the needs of portal developers, maybe we should focus on that subject first. Jeff Schnitzer [EMAIL PROTECTED] > -----Original Message----- > From: jim moore [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 09, 2002 9:33 AM > To: [EMAIL PROTECTED] > Subject: Re: [Mav-user] Using "decorator" pattern on controllers > > On a related note, I'm wondering if we should make ControllerFactory a > public class. That way decorators would be free to use it's > createController() method. There's a lot of good functionality in there, > and > I don't really see a reason to hide it away. What do you think Jeff? > > --jim > > ----- Original Message ----- > From: "jim moore" <[EMAIL PROTECTED]> > To: <[EMAIL PROTECTED]> > Sent: Friday, August 09, 2002 12:23 PM > Subject: Re: [Mav-user] Using "decorator" pattern on controllers > > > > This shouldn't be too difficult. Just have your decorator implement > > ControllerSingleton, then you will get an init method in which the > > controller node from maverick.xml is passed in. > > > > If you had a controller node that looked like: > > > > <controller class="com.foo.bar.MyControllerDecorator"> > > <decorated class="com.foo.bar.SomeExistingController"> > > </controller> > > > > Your decorator could hold an internal controller. When the decorator's > go > > method was called, it could call go on the decorated controller, read > the > > result and the model, and still do its own thing. This is actually > similar > > to what I just sent as the CompositeController. > > > > --jim > > > > ----- Original Message ----- > > From: "Roy Truelove" <[EMAIL PROTECTED]> > > To: <[EMAIL PROTECTED]> > > Sent: Friday, August 09, 2002 12:04 PM > > Subject: [Mav-user] Using "decorator" pattern on controllers > > > > > > > Hey all, > > > > > > I'm looking into the feasablity of using the Decorator pattern* to > > > create Controllers. In the friendbook example, each controller > inherits > > > from another controller which inherits from another controller, each > one > > > adding a little functionality. The problem with this is that you > can't > > pick > > > and choose which controllers you want to use, you have to use > extentions > > of > > > extentions. This would certainly help with the composite view issues > that > > > are being discussed, as well as securing controllers, etc. > > > > > > The problem is .. how can this be done while keeping Maverick > backwards > > > compatable *and* keeping configuration to a minimum? Any ideas? > Since > > > controllers are instantiated using reflections and not explicitly, is > the > > > Decorator pattern even possible? > > > > > > *Decorator pattern info : > > > > http://www.javaworld.com/javaworld/jw-12-2001/jw-1214-designpatterns.htm l > > > > > > -Roy > > > > > > > > > > > > ------------------------------------------------------- > > > This sf.net email is sponsored by:ThinkGeek > > > Welcome to geek heaven. > > > http://thinkgeek.com/sf > > > _______________________________________________ > > > Mav-user mailing list > > > [EMAIL PROTECTED] > > > https://lists.sourceforge.net/lists/listinfo/mav-user > > > Archives are available at http://www.mail-archive.com/ > > > > > > > > ------------------------------------------------------- > > This sf.net email is sponsored by:ThinkGeek > > Welcome to geek heaven. > > http://thinkgeek.com/sf > > _______________________________________________ > > Mav-user mailing list > > [EMAIL PROTECTED] > > https://lists.sourceforge.net/lists/listinfo/mav-user > > Archives are available at http://www.mail-archive.com/ > > > > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > Mav-user mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/mav-user > Archives are available at http://www.mail-archive.com/ ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Mav-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/mav-user Archives are available at http://www.mail-archive.com/
