[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.html -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/
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: 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.html > > -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/
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: > > > > > > 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.html > > > > -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/
Re: [Mav-user] Using "decorator" pattern on controllers
Actually I just found the ControllerWithParams class in the Javadoc which is defined as a "a Decorator pattern, adding params defined for a controller". Are they any examples of how this is used? -Roy - 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: > > > > > > 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.html > > > > -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/
RE: [Mav-user] Using "decorator" pattern on controllers
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: > > > > > > > > > > > > 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/
RE: [Mav-user] Using "decorator" pattern on controllers
It's used internally right now, but the mechanism could be surfaced by configurable controller factories. On the other hand, since singleton controllers are passed the XML of their configuration, you can always compose layers of decoration yourself. Jeff Schnitzer [EMAIL PROTECTED] > -Original Message- > From: Roy Truelove [mailto:[EMAIL PROTECTED]] > Sent: Friday, August 09, 2002 11:46 AM > To: [EMAIL PROTECTED] > Subject: Re: [Mav-user] Using "decorator" pattern on controllers > > Actually I just found the ControllerWithParams class in the Javadoc which > is > defined as a "a Decorator pattern, adding params defined for a > controller". > Are they any examples of how this is used? > > -Roy > > - 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: > > > > > > > > > > > > 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/
