in short, I think there is a room for adding smartDispatch capabilities to the DynamicAction, but i don't like the "standalone action" thing. why?
my view on that as I tried to post it as a comment on Adam's blog: The idea is nice. Might be useful, but on another scenarios. Inheritance does make sense in your scenario, as both controllers share behavior and semantics. So I'd use the inheritance thing, but a bit differently (from the top of my head, in pseudo): class BaseController<T> ... { protected virtual InternalIndex(...)..
}
class ProductsController : BaseController<Product> { public void Index(...) { InternalIndex(...); }
} etc. >> "ProductsController and CategoriesController no longer "speak" to me"
so now, the controller "speaks" to you.
Now about DynamicActions being "second class citizens", Id say that your idea can be served as en enhancement to the DActions.
however not in the way you've introduced as it would make the whole thing dependant on routing.
MR should be simple.
when I tell a newbie that url->Area/Controller/Action, the last thing I need to tell him is "except ...".
>> "What were our controllers doing? They were really just organizing our
actions" Well - controllers don't "do". Actions "do".
On 10/25/07, Ayende Rahien < aye...@ayende.com> wrote:
It's effectively "decoration" of controllers with actions, and useful for those situations where pulling that shared logic upwards in an inheritance chain would cause an unpleasant growth of classes. I'm guessing you lose the ability to apply attributes to those actions too, like DefaultAction, PrincipalPermission etc?
The SmartDispatcherAction might be easier to implement after refactoring towards IController.
On Oct 25, 9:27 am, "Ken Egozi" <egoz...@gmail.com> wrote:
> in short, I think there is a room for adding smartDispatch capabilities to > the DynamicAction, but i don't like the "standalone action" thing. > why?
> my view on that as I tried to post it as a comment on Adam's blog: > The idea is nice. > Might be useful, but on another scenarios. > Inheritance does make sense in your scenario, as both controllers share > behavior and semantics. > So I'd use the inheritance thing, but a bit differently (from the top of my > head, in pseudo): > class BaseController<T> ... > { > protected virtual InternalIndex(...)..}
> class ProductsController : BaseController<Product> > { > public void Index(...) { InternalIndex(...); }} > etc. > >> "ProductsController and CategoriesController no longer "speak" to me"
> so now, the controller "speaks" to you.
> Now about DynamicActions being "second class citizens", Id say that your > idea can be served as en enhancement to the DActions.
> however not in the way you've introduced as it would make the whole thing > dependant on routing.
> MR should be simple.
> when I tell a newbie that url->Area/Controller/Action, the last thing I need > to tell him is "except ...".
> >> "What were our controllers doing? They were really just organizing our
> actions" > Well - controllers don't "do". Actions "do".
> On 10/25/07, Ayende Rahien < aye...@ayende.com> wrote:
Yeah. but i see it as an evolution of DynamicAction rather than as a new thing.
So the controllers would exist, and have a new-kind-of-dynamic-action-named-index associated with an attribute, and the url would be /products/index, without relying on "external" routing rule.
On 10/25/07, Lee Henson <lee.m.hen...@gmail.com> wrote:
> It's effectively "decoration" of controllers with actions, and useful > for those situations where pulling that shared logic upwards in an > inheritance chain would cause an unpleasant growth of classes. I'm > guessing you lose the ability to apply attributes to those actions > too, like DefaultAction, PrincipalPermission etc?
> The SmartDispatcherAction might be easier to implement after > refactoring towards IController.
> On Oct 25, 9:27 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > in short, I think there is a room for adding smartDispatch capabilities > to > > the DynamicAction, but i don't like the "standalone action" thing. > > why?
> > my view on that as I tried to post it as a comment on Adam's blog: > > The idea is nice. > > Might be useful, but on another scenarios. > > Inheritance does make sense in your scenario, as both controllers share > > behavior and semantics. > > So I'd use the inheritance thing, but a bit differently (from the top of > my > > head, in pseudo): > > class BaseController<T> ... > > { > > protected virtual InternalIndex(...)..}
> > class ProductsController : BaseController<Product> > > { > > public void Index(...) { InternalIndex(...); }} > > etc. > > >> "ProductsController and CategoriesController no longer "speak" to me"
> > so now, the controller "speaks" to you.
> > Now about DynamicActions being "second class citizens", Id say that your > > idea can be served as en enhancement to the DActions.
> > however not in the way you've introduced as it would make the whole > thing > > dependant on routing.
> > MR should be simple.
> > when I tell a newbie that url->Area/Controller/Action, the last thing I > need > > to tell him is "except ...".
> > >> "What were our controllers doing? They were really just organizing > our
> Yeah. but i see it as an evolution of DynamicAction rather than as a new > thing.
> So the controllers would exist, and have a > new-kind-of-dynamic-action-named-index associated with an attribute, > and the url would be /products/index, without relying on "external" > routing rule.
> On 10/25/07, Lee Henson <lee.m.hen...@gmail.com> wrote:
> > It's effectively "decoration" of controllers with actions, and useful > > for those situations where pulling that shared logic upwards in an > > inheritance chain would cause an unpleasant growth of classes. I'm > > guessing you lose the ability to apply attributes to those actions > > too, like DefaultAction, PrincipalPermission etc?
> > The SmartDispatcherAction might be easier to implement after > > refactoring towards IController.
> > On Oct 25, 9:27 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > in short, I think there is a room for adding smartDispatch > > capabilities to > > > the DynamicAction, but i don't like the "standalone action" thing. > > > why?
> > > my view on that as I tried to post it as a comment on Adam's blog: > > > The idea is nice. > > > Might be useful, but on another scenarios. > > > Inheritance does make sense in your scenario, as both controllers > > share > > > behavior and semantics. > > > So I'd use the inheritance thing, but a bit differently (from the top > > of my > > > head, in pseudo): > > > class BaseController<T> ... > > > { > > > protected virtual InternalIndex(...)..}
> > > class ProductsController : BaseController<Product> > > > { > > > public void Index(...) { InternalIndex(...); }} > > > etc. > > > >> "ProductsController and CategoriesController no longer "speak" to > > me"
> > > so now, the controller "speaks" to you.
> > > Now about DynamicActions being "second class citizens", Id say that > > your > > > idea can be served as en enhancement to the DActions.
> > > however not in the way you've introduced as it would make the whole > > thing > > > dependant on routing.
> > > MR should be simple.
> > > when I tell a newbie that url->Area/Controller/Action, the last thing > > I need > > > to tell him is "except ...".
> > > >> "What were our controllers doing? They were really just organizing > > our
site.com/area/controller/action.rails = action() in Controller within an area site.com/controller/action.rails = action() in Controller site.com/action.rail = some first class Action.
but what if you want to group actions into an area?
youre trying to introduce something does not fit in the paradigm. it would rely on routing, so it'd make the simple things complicated.
if this action is supposed to work in conjunction with a controller, then set it up as a DAction in that controller. if it has no other context, then create a "CommonController" and throw that action in.
On 10/25/07, Ayende Rahien <aye...@ayende.com> wrote:
> Hm, but why would I want several controllers for the same action? > It seems reasonable to me that we would have action as a first class > concept
> On 10/25/07, Ken Egozi <egoz...@gmail.com> wrote:
> > Yeah. but i see it as an evolution of DynamicAction rather than as a new > > thing.
> > So the controllers would exist, and have a > > new-kind-of-dynamic-action-named-index associated with an attribute, > > and the url would be /products/index, without relying on "external" > > routing rule.
> > On 10/25/07, Lee Henson < lee.m.hen...@gmail.com> wrote:
> > > It's effectively "decoration" of controllers with actions, and useful > > > for those situations where pulling that shared logic upwards in an > > > inheritance chain would cause an unpleasant growth of classes. I'm > > > guessing you lose the ability to apply attributes to those actions > > > too, like DefaultAction, PrincipalPermission etc?
> > > The SmartDispatcherAction might be easier to implement after > > > refactoring towards IController.
> > > On Oct 25, 9:27 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > in short, I think there is a room for adding smartDispatch > > > capabilities to > > > > the DynamicAction, but i don't like the "standalone action" thing. > > > > why?
> > > > my view on that as I tried to post it as a comment on Adam's blog: > > > > The idea is nice. > > > > Might be useful, but on another scenarios. > > > > Inheritance does make sense in your scenario, as both controllers > > > share > > > > behavior and semantics. > > > > So I'd use the inheritance thing, but a bit differently (from the > > > top of my > > > > head, in pseudo): > > > > class BaseController<T> ... > > > > { > > > > protected virtual InternalIndex(...)..}
> > > > class ProductsController : BaseController<Product> > > > > { > > > > public void Index(...) { InternalIndex(...); }} > > > > etc. > > > > >> "ProductsController and CategoriesController no longer "speak" to > > > me"
> > > > so now, the controller "speaks" to you.
> > > > Now about DynamicActions being "second class citizens", Id say that > > > your > > > > idea can be served as en enhancement to the DActions.
> > > > however not in the way you've introduced as it would make the whole > > > thing > > > > dependant on routing.
> > > > MR should be simple.
> > > > when I tell a newbie that url->Area/Controller/Action, the last > > > thing I need > > > > to tell him is "except ...".
> > > > >> "What were our controllers doing? They were really just > > > organizing our
I think Adam is making the point that this might be useful for actions which are very similar, and that can be generalised to a sufficient extent. You wouldn't do this for "non-generic" actions.
On Oct 25, 11:16 am, "Ayende Rahien" <aye...@ayende.com> wrote:
> Hm, but why would I want several controllers for the same action? > It seems reasonable to me that we would have action as a first class concept
> On 10/25/07, Ken Egozi <egoz...@gmail.com> wrote:
> > Yeah. but i see it as an evolution of DynamicAction rather than as a new > > thing.
> > So the controllers would exist, and have a > > new-kind-of-dynamic-action-named-index associated with an attribute, > > and the url would be /products/index, without relying on "external" > > routing rule.
> > On 10/25/07, Lee Henson <lee.m.hen...@gmail.com> wrote:
> > > It's effectively "decoration" of controllers with actions, and useful > > > for those situations where pulling that shared logic upwards in an > > > inheritance chain would cause an unpleasant growth of classes. I'm > > > guessing you lose the ability to apply attributes to those actions > > > too, like DefaultAction, PrincipalPermission etc?
> > > The SmartDispatcherAction might be easier to implement after > > > refactoring towards IController.
> > > On Oct 25, 9:27 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > in short, I think there is a room for adding smartDispatch > > > capabilities to > > > > the DynamicAction, but i don't like the "standalone action" thing. > > > > why?
> > > > my view on that as I tried to post it as a comment on Adam's blog: > > > > The idea is nice. > > > > Might be useful, but on another scenarios. > > > > Inheritance does make sense in your scenario, as both controllers > > > share > > > > behavior and semantics. > > > > So I'd use the inheritance thing, but a bit differently (from the top > > > of my > > > > head, in pseudo): > > > > class BaseController<T> ... > > > > { > > > > protected virtual InternalIndex(...)..}
> > > > class ProductsController : BaseController<Product> > > > > { > > > > public void Index(...) { InternalIndex(...); }} > > > > etc. > > > > >> "ProductsController and CategoriesController no longer "speak" to > > > me"
> > > > so now, the controller "speaks" to you.
> > > > Now about DynamicActions being "second class citizens", Id say that > > > your > > > > idea can be served as en enhancement to the DActions.
> > > > however not in the way you've introduced as it would make the whole > > > thing > > > > dependant on routing.
> > > > MR should be simple.
> > > > when I tell a newbie that url->Area/Controller/Action, the last thing > > > I need > > > > to tell him is "except ...".
> > > > >> "What were our controllers doing? They were really just organizing > > > our
What I was suggesting is not really a new idea... Struts was doing this 8 years ago (but in an ugly way).
Controllers with actions as methods make good demos, but don't facilitate good code reuse. In my last project, we tried to make use of your below suggestion.
class BaseController<T>
We had 5 actions that could be reused across several controllers. You can only imagine the number of "template" methods that a child controller needed to implement to facilitate reuse of those 5 actions. To add to the problems, some of the child controllers only needed to reuse some of the actions. We ended up having some of the "template" methods return default values in the base class so that not every child controller had to override them. Talk about unclear... which template methods go with what actions? Which one do I need to implement? BaseController really breaks down when you want to reuse more than one action.
We were lead down the path of BaseController<T> because that is what the framework encourages. After we realized BaseController<T> was a nightmare we aggressively moved to DynamicActions. Our controllers ended up having a constructor with a bunch of dynamic action creations. After seeing this evolve, we thought our controllers were really not doing anything... other than organizing our actions.
What if routing had a nice syntax/dsl?
RoutingEngine.Add("products" delegate(Foo foo) { foo.Add(new Route("<name>", new IndexAction(new ProductRepository()) foo.Add(new Route("list", new ListAction(new ProductRepository())
});
Not sure this is the best code, but you get the idea. You could structure your "Routes" such that they are grouped by "concepts/ controllers".
Hopefully this explains, a little better, my point of view.
AE
On Oct 25, 3:27 am, "Ken Egozi" <egoz...@gmail.com> wrote:
> in short, I think there is a room for adding smartDispatch capabilities to > the DynamicAction, but i don't like the "standalone action" thing. > why?
> my view on that as I tried to post it as a comment on Adam's blog: > The idea is nice. > Might be useful, but on another scenarios. > Inheritance does make sense in your scenario, as both controllers share > behavior and semantics. > So I'd use the inheritance thing, but a bit differently (from the top of my > head, in pseudo): > class BaseController<T> ... > { > protected virtual InternalIndex(...)..}
> class ProductsController : BaseController<Product> > { > public void Index(...) { InternalIndex(...); }} > etc. > >> "ProductsController and CategoriesController no longer "speak" to me"
> so now, the controller "speaks" to you.
> Now about DynamicActions being "second class citizens", Id say that your > idea can be served as en enhancement to the DActions.
> however not in the way you've introduced as it would make the whole thing > dependant on routing.
> MR should be simple.
> when I tell a newbie that url->Area/Controller/Action, the last thing I need > to tell him is "except ...".
> >> "What were our controllers doing? They were really just organizing our
> actions" > Well - controllers don't "do". Actions "do".
> On 10/25/07, Ayende Rahien < aye...@ayende.com> wrote:
On 10/25/07, Adam Esterline <a...@esterlines.com> wrote:
> After we realized BaseController<T> was a > nightmare we aggressively moved > to DynamicActions. Our controllers ended up having a constructor > with a bunch of dynamic action creations.
So it's not the DActions are not good, the implementation details isn't nice enough, so we might need to think how to improve that.
After seeing this evolve,
> we thought our controllers were really not > doing anything... other than organizing our actions.
That's what controllers do. the executable code in a controller (aka public method) is an action, so all over your application, the controllers are logical groups of actions. If you do have an "all around" action that does not belong to an existing controller, you'd create a new controller for that action.
the RoutingEngine is not for routing from Url to CLR. it's for routing (or actually re-writing) an arbitrary Url to standard rails url.
plus - this couples the framework tightly to a specific RoutingEngine implementation, thus introducing a compulsory complication that is not supposed to be there, breaking Convention-Over-Configuration.
I'm not saying that it's bad. It might be great for your needs. but I cannot see it as part of the framework
Not sure this is the best code, but you get the idea. You could
> structure your "Routes" such that they are grouped by "concepts/ > controllers".
instead of "routes" and "concepts", use "actions" and "controllers" - and it's baked in
Hopefully this explains, a little better, my point of view.
> On Oct 25, 3:27 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > in short, I think there is a room for adding smartDispatch capabilities > to > > the DynamicAction, but i don't like the "standalone action" thing. > > why?
> > my view on that as I tried to post it as a comment on Adam's blog: > > The idea is nice. > > Might be useful, but on another scenarios. > > Inheritance does make sense in your scenario, as both controllers share > > behavior and semantics. > > So I'd use the inheritance thing, but a bit differently (from the top of > my > > head, in pseudo): > > class BaseController<T> ... > > { > > protected virtual InternalIndex(...)..}
> > class ProductsController : BaseController<Product> > > { > > public void Index(...) { InternalIndex(...); }} > > etc. > > >> "ProductsController and CategoriesController no longer "speak" to me"
> > so now, the controller "speaks" to you.
> > Now about DynamicActions being "second class citizens", Id say that your > > idea can be served as en enhancement to the DActions.
> > however not in the way you've introduced as it would make the whole > thing > > dependant on routing.
> > MR should be simple.
> > when I tell a newbie that url->Area/Controller/Action, the last thing I > need > > to tell him is "except ...".
> > >> "What were our controllers doing? They were really just organizing > our
> So it's not the DActions are not good, the implementation details isn't nice > enough, so we might need to think how to improve that.
I would agree. In MonoRail, DActions are the only way to handle the problem I described above. DAs need more "niceness". I am sure this could be done now by coding a SmartDispatcherAction that implements the IDynamicAction interface.
I really want to stress that Controllers with public action/methods leads developers into making bad design decisions. I did it. You suggested it. The framework leads you down a bad path. Without actions being a first class concept this will continue.
Controllers with public action/methods make great demos and simple quick applications. When developing non-simple applications that need to be DRY, it fails.
> the RoutingEngine is not for routing from Url to CLR. > it's for routing (or actually re-writing) an arbitrary Url to standard > rails url.
> plus - this couples the framework tightly to a specific RoutingEngine > implementation, thus introducing a compulsory complication that is not > supposed to be there, breaking Convention-Over-Configuration.
> I'm not saying that it's bad. It might be great for your needs. but I cannot > see it as part of the framework
I don't really see it as being tightly coupled. Your actions no nothing about the routing engine. I can agree to disagree.
AE
On Oct 26, 12:48 am, "Ken Egozi" <egoz...@gmail.com> wrote:
> On 10/25/07, Adam Esterline <a...@esterlines.com> wrote:
> > After we realized BaseController<T> was a > > nightmare we aggressively moved > > to DynamicActions. Our controllers ended up having a constructor > > with a bunch of dynamic action creations.
> So it's not the DActions are not good, the implementation details isn't nice > enough, so we might need to think how to improve that.
> After seeing this evolve,
> > we thought our controllers were really not > > doing anything... other than organizing our actions.
> That's what controllers do. the executable code in a controller (aka public > method) is an action, so all over your application, the controllers are > logical groups of actions. If you do have an "all around" action that does > not belong to an existing controller, you'd create a new controller for that > action.
> the RoutingEngine is not for routing from Url to CLR. > it's for routing (or actually re-writing) an arbitrary Url to standard > rails url.
> plus - this couples the framework tightly to a specific RoutingEngine > implementation, thus introducing a compulsory complication that is not > supposed to be there, breaking Convention-Over-Configuration.
> I'm not saying that it's bad. It might be great for your needs. but I cannot > see it as part of the framework
> Not sure this is the best code, but you get the idea. You could
> > structure your "Routes" such that they are grouped by "concepts/ > > controllers".
> instead of "routes" and "concepts", use "actions" and "controllers" - and > it's baked in
> Hopefully this explains, a little better, my point of view.
> Me too ;)
> AE
> > On Oct 25, 3:27 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > in short, I think there is a room for adding smartDispatch capabilities > > to > > > the DynamicAction, but i don't like the "standalone action" thing. > > > why?
> > > my view on that as I tried to post it as a comment on Adam's blog: > > > The idea is nice. > > > Might be useful, but on another scenarios. > > > Inheritance does make sense in your scenario, as both controllers share > > > behavior and semantics. > > > So I'd use the inheritance thing, but a bit differently (from the top of > > my > > > head, in pseudo): > > > class BaseController<T> ... > > > { > > > protected virtual InternalIndex(...)..}
> > > class ProductsController : BaseController<Product> > > > { > > > public void Index(...) { InternalIndex(...); }} > > > etc. > > > >> "ProductsController and CategoriesController no longer "speak" to me"
> > > so now, the controller "speaks" to you.
> > > Now about DynamicActions being "second class citizens", Id say that your > > > idea can be served as en enhancement to the DActions.
> > > however not in the way you've introduced as it would make the whole > > thing > > > dependant on routing.
> > > MR should be simple.
> > > when I tell a newbie that url->Area/Controller/Action, the last thing I > > need > > > to tell him is "except ...".
> > > >> "What were our controllers doing? They were really just organizing > > our
> > So it's not the DActions are not good, the implementation details isn't > nice > > enough, so we might need to think how to improve that.
> I would agree. In MonoRail, DActions are the only way to handle the > problem > I described above. DAs need more "niceness". I am sure this could > be done now > by coding a SmartDispatcherAction that implements the IDynamicAction > interface.
> I really want to stress that Controllers with public action/methods > leads developers > into making bad design decisions. I did it. You suggested it. > The framework > leads you down a bad path. Without actions being a first class > concept this will continue.
> Controllers with public action/methods make great demos and simple > quick applications. > When developing non-simple applications that need to be DRY, it fails.
> > the RoutingEngine is not for routing from Url to CLR. > > it's for routing (or actually re-writing) an arbitrary Url to standard > > rails url.
> > plus - this couples the framework tightly to a specific RoutingEngine > > implementation, thus introducing a compulsory complication that is not > > supposed to be there, breaking Convention-Over-Configuration.
> > I'm not saying that it's bad. It might be great for your needs. but I > cannot > > see it as part of the framework
> I don't really see it as being tightly coupled. Your actions no > nothing about > the routing engine. I can agree to disagree.
> AE
> On Oct 26, 12:48 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > On 10/25/07, Adam Esterline <a...@esterlines.com> wrote:
> > > After we realized BaseController<T> was a > > > nightmare we aggressively moved > > > to DynamicActions. Our controllers ended up having a constructor > > > with a bunch of dynamic action creations.
> > So it's not the DActions are not good, the implementation details isn't > nice > > enough, so we might need to think how to improve that.
> > After seeing this evolve,
> > > we thought our controllers were really not > > > doing anything... other than organizing our actions.
> > That's what controllers do. the executable code in a controller (aka > public > > method) is an action, so all over your application, the controllers are > > logical groups of actions. If you do have an "all around" action that > does > > not belong to an existing controller, you'd create a new controller for > that > > action.
> > the RoutingEngine is not for routing from Url to CLR. > > it's for routing (or actually re-writing) an arbitrary Url to standard > > rails url.
> > plus - this couples the framework tightly to a specific RoutingEngine > > implementation, thus introducing a compulsory complication that is not > > supposed to be there, breaking Convention-Over-Configuration.
> > I'm not saying that it's bad. It might be great for your needs. but I > cannot > > see it as part of the framework
> > Not sure this is the best code, but you get the idea. You could
> > > structure your "Routes" such that they are grouped by "concepts/ > > > controllers".
> > instead of "routes" and "concepts", use "actions" and "controllers" - > and > > it's baked in
> > Hopefully this explains, a little better, my point of view.
> > Me too ;)
> > AE
> > > On Oct 25, 3:27 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > in short, I think there is a room for adding smartDispatch > capabilities > > > to > > > > the DynamicAction, but i don't like the "standalone action" thing. > > > > why?
> > > > my view on that as I tried to post it as a comment on Adam's blog: > > > > The idea is nice. > > > > Might be useful, but on another scenarios. > > > > Inheritance does make sense in your scenario, as both controllers > share > > > > behavior and semantics. > > > > So I'd use the inheritance thing, but a bit differently (from the > top of > > > my > > > > head, in pseudo): > > > > class BaseController<T> ... > > > > { > > > > protected virtual InternalIndex(...)..}
> > > > class ProductsController : BaseController<Product> > > > > { > > > > public void Index(...) { InternalIndex(...); }} > > > > etc. > > > > >> "ProductsController and CategoriesController no longer "speak" to > me"
> > > > so now, the controller "speaks" to you.
> > > > Now about DynamicActions being "second class citizens", Id say that > your > > > > idea can be served as en enhancement to the DActions.
> > > > however not in the way you've introduced as it would make the whole > > > thing > > > > dependant on routing.
> > > > MR should be simple.
> > > > when I tell a newbie that url->Area/Controller/Action, the last > thing I > > > need > > > > to tell him is "except ...".
> > > > >> "What were our controllers doing? They were really just > organizing > > > our
> But the only way to activate the action is though a route. how else would > you construct a url that will activate a "standalone" action?
> anyway - if the action needs re-use then DAction is a good design choice > imho.
> and setup the DAction on the needed controllers (instead of setting it up in > the route rule as you've suggested). > I do not see the bad design here.
> On 10/26/07, Adam Esterline <a...@esterlines.com> wrote:
> > > So it's not the DActions are not good, the implementation details isn't > > nice > > > enough, so we might need to think how to improve that.
> > I would agree. In MonoRail, DActions are the only way to handle the > > problem > > I described above. DAs need more "niceness". I am sure this could > > be done now > > by coding a SmartDispatcherAction that implements the IDynamicAction > > interface.
> > I really want to stress that Controllers with public action/methods > > leads developers > > into making bad design decisions. I did it. You suggested it. > > The framework > > leads you down a bad path. Without actions being a first class > > concept this will continue.
> > Controllers with public action/methods make great demos and simple > > quick applications. > > When developing non-simple applications that need to be DRY, it fails.
> > > the RoutingEngine is not for routing from Url to CLR. > > > it's for routing (or actually re-writing) an arbitrary Url to standard > > > rails url.
> > > plus - this couples the framework tightly to a specific RoutingEngine > > > implementation, thus introducing a compulsory complication that is not > > > supposed to be there, breaking Convention-Over-Configuration.
> > > I'm not saying that it's bad. It might be great for your needs. but I > > cannot > > > see it as part of the framework
> > I don't really see it as being tightly coupled. Your actions no > > nothing about > > the routing engine. I can agree to disagree.
> > AE
> > On Oct 26, 12:48 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > On 10/25/07, Adam Esterline <a...@esterlines.com> wrote:
> > > > After we realized BaseController<T> was a > > > > nightmare we aggressively moved > > > > to DynamicActions. Our controllers ended up having a constructor > > > > with a bunch of dynamic action creations.
> > > So it's not the DActions are not good, the implementation details isn't > > nice > > > enough, so we might need to think how to improve that.
> > > After seeing this evolve,
> > > > we thought our controllers were really not > > > > doing anything... other than organizing our actions.
> > > That's what controllers do. the executable code in a controller (aka > > public > > > method) is an action, so all over your application, the controllers are > > > logical groups of actions. If you do have an "all around" action that > > does > > > not belong to an existing controller, you'd create a new controller for > > that > > > action.
> > > the RoutingEngine is not for routing from Url to CLR. > > > it's for routing (or actually re-writing) an arbitrary Url to standard > > > rails url.
> > > plus - this couples the framework tightly to a specific RoutingEngine > > > implementation, thus introducing a compulsory complication that is not > > > supposed to be there, breaking Convention-Over-Configuration.
> > > I'm not saying that it's bad. It might be great for your needs. but I > > cannot > > > see it as part of the framework
> > > Not sure this is the best code, but you get the idea. You could
> > > > structure your "Routes" such that they are grouped by "concepts/ > > > > controllers".
> > > instead of "routes" and "concepts", use "actions" and "controllers" - > > and > > > it's baked in
> > > Hopefully this explains, a little better, my point of view.
> > > Me too ;)
> > > AE
> > > > On Oct 25, 3:27 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > > in short, I think there is a room for adding smartDispatch > > capabilities > > > > to > > > > > the DynamicAction, but i don't like the "standalone action" thing. > > > > > why?
> > > > > my view on that as I tried to post it as a comment on Adam's blog: > > > > > The idea is nice. > > > > > Might be useful, but on another scenarios. > > > > > Inheritance does make sense in your scenario, as both controllers > > share > > > > > behavior and semantics. > > > > > So I'd use the inheritance thing, but a bit differently (from the > > top of > > > > my > > > > > head, in pseudo): > > > > > class BaseController<T> ... > > > > > { > > > > > protected virtual InternalIndex(...)..}
> > > > > class ProductsController : BaseController<Product> > > > > > { > > > > > public void Index(...) { InternalIndex(...); }} > > > > > etc. > > > > > >> "ProductsController and CategoriesController no longer "speak" to > > me"
> > > > > so now, the controller "speaks" to you.
> > > > > Now about DynamicActions being "second class citizens", Id say that > > your > > > > > idea can be served as en enhancement to the DActions.
> > > > > however not in the way you've introduced as it would make the whole > > > > thing > > > > > dependant on routing.
> > > > > MR should be simple.
> > > > > when I tell a newbie that url->Area/Controller/Action, the last > > thing I > > > > need > > > > > to tell him is "except ...".
> > > > > >> "What were our controllers doing? They were really just > > organizing > > > > our
> I agree that DAction are a good design choice. But... DActions are > not the encouraged by the framework. > That is my only point.
> On Oct 26, 6:53 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > But the only way to activate the action is though a route. how else > would > > you construct a url that will activate a "standalone" action?
> > anyway - if the action needs re-use then DAction is a good design choice > > imho.
> > and setup the DAction on the needed controllers (instead of setting it > up in > > the route rule as you've suggested). > > I do not see the bad design here.
> > On 10/26/07, Adam Esterline <a...@esterlines.com> wrote:
> > > > So it's not the DActions are not good, the implementation details > isn't > > > nice > > > > enough, so we might need to think how to improve that.
> > > I would agree. In MonoRail, DActions are the only way to handle the > > > problem > > > I described above. DAs need more "niceness". I am sure this could > > > be done now > > > by coding a SmartDispatcherAction that implements the IDynamicAction > > > interface.
> > > I really want to stress that Controllers with public action/methods > > > leads developers > > > into making bad design decisions. I did it. You suggested it. > > > The framework > > > leads you down a bad path. Without actions being a first class > > > concept this will continue.
> > > Controllers with public action/methods make great demos and simple > > > quick applications. > > > When developing non-simple applications that need to be DRY, it fails.
> > > > the RoutingEngine is not for routing from Url to CLR. > > > > it's for routing (or actually re-writing) an arbitrary > Url to standard > > > > rails url.
> > > > plus - this couples the framework tightly to a specific > RoutingEngine > > > > implementation, thus introducing a compulsory complication that is > not > > > > supposed to be there, breaking Convention-Over-Configuration.
> > > > I'm not saying that it's bad. It might be great for your needs. but > I > > > cannot > > > > see it as part of the framework
> > > I don't really see it as being tightly coupled. Your actions no > > > nothing about > > > the routing engine. I can agree to disagree.
> > > AE
> > > On Oct 26, 12:48 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > On 10/25/07, Adam Esterline <a...@esterlines.com> wrote:
> > > > > After we realized BaseController<T> was a > > > > > nightmare we aggressively moved > > > > > to DynamicActions. Our controllers ended up having a > constructor > > > > > with a bunch of dynamic action creations.
> > > > So it's not the DActions are not good, the implementation details > isn't > > > nice > > > > enough, so we might need to think how to improve that.
> > > > After seeing this evolve,
> > > > > we thought our controllers were really not > > > > > doing anything... other than organizing our actions.
> > > > That's what controllers do. the executable code in a controller > (aka > > > public > > > > method) is an action, so all over your application, the controllers > are > > > > logical groups of actions. If you do have an "all around" action > that > > > does > > > > not belong to an existing controller, you'd create a new controller > for > > > that > > > > action.
> > > > the RoutingEngine is not for routing from Url to CLR. > > > > it's for routing (or actually re-writing) an arbitrary > Url to standard > > > > rails url.
> > > > plus - this couples the framework tightly to a specific > RoutingEngine > > > > implementation, thus introducing a compulsory complication that is > not > > > > supposed to be there, breaking Convention-Over-Configuration.
> > > > I'm not saying that it's bad. It might be great for your needs. but > I > > > cannot > > > > see it as part of the framework
> > > > Not sure this is the best code, but you get the idea. You could
> > > > > structure your "Routes" such that they are grouped by "concepts/ > > > > > controllers".
> > > > instead of "routes" and "concepts", use "actions" and "controllers" > - > > > and > > > > it's baked in
> > > > Hopefully this explains, a little better, my point of view.
> > > > Me too ;)
> > > > AE
> > > > > On Oct 25, 3:27 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > > > in short, I think there is a room for adding smartDispatch > > > capabilities > > > > > to > > > > > > the DynamicAction, but i don't like the "standalone action" > thing. > > > > > > why?
> > > > > > my view on that as I tried to post it as a comment on Adam's > blog: > > > > > > The idea is nice. > > > > > > Might be useful, but on another scenarios. > > > > > > Inheritance does make sense in your scenario, as both > controllers > > > share > > > > > > behavior and semantics. > > > > > > So I'd use the inheritance thing, but a bit differently (from > the > > > top of > > > > > my > > > > > > head, in pseudo): > > > > > > class BaseController<T> ... > > > > > > { > > > > > > protected virtual InternalIndex(...)..}
> > > > > > class ProductsController : BaseController<Product> > > > > > > { > > > > > > public void Index(...) { InternalIndex(...); }} > > > > > > etc. > > > > > > >> "ProductsController and CategoriesController no longer > "speak" to > > > me"
> > > > > > so now, the controller "speaks" to you.
> > > > > > Now about DynamicActions being "second class citizens", Id say > that > > > your > > > > > > idea can be served as en enhancement to the DActions.
> > > > > > however not in the way you've introduced as it would make the > whole > > > > > thing > > > > > > dependant on routing.
> > > > > > MR should be simple.
> > > > > > when I tell a newbie that url->Area/Controller/Action, the last > > > thing I > > > > > need > > > > > > to tell him is "except ...".
> > > > > > >> "What were our controllers doing? They were really just > > > organizing > > > > > our
> Controllers with public action/methods make great demos and simple > quick applications. > When developing non-simple applications that need to be DRY, it fails.
Adam - I scanned your blog post - but didn't see a specific example of this type of problem.
I'm curious about why/how you think this is causing you DRY problems.
I've used public method per controller setups on a number of projects and not once come across this kind of problem.
Would you mind sharing an example of a type of action which shouldn't be bound to a controller?
> Would you mind sharing an example of a type of action which shouldn't > be bound to a controller?
Any action that needs to be shared across controllers. The example in the blog post shows an example of sharing actions across controllers using public methods. You end up with a base controller that exposes protected template methods. This is not a good way to reuse actions. It works "OK" for reusing one action, but totally falls apart when trying to reuse more than one action on a controller.
Did you never try to reuse actions, across controllers, in your projects? If so, how did you do it? This is really the problem I am trying to expose. How are users of RoR based MVC Frameworks reusing actions across controllers? I think the frameworks encourage users to reuse code in a bad way (Template Method Pattern).
I wish I could show you our code, but I cannot. I will work up a better example this weekend that will show the problem better.
On Oct 26, 9:10 am, "josh robb" <josh_r...@fastmail.fm> wrote:
> > Controllers with public action/methods make great demos and simple > > quick applications. > > When developing non-simple applications that need to be DRY, it fails.
> Adam - I scanned your blog post - but didn't see a specific example of > this type of problem.
> I'm curious about why/how you think this is causing you DRY problems.
> I've used public method per controller setups on a number of projects > and not once come across this kind of problem.
> Would you mind sharing an example of a type of action which shouldn't > be bound to a controller?
> Did you never try to reuse actions, across controllers, in your > projects?
No. I've never had a situation where I could (where the code wasn't trivial). I think that the problem is that the index action example is so trvial I don't see the problem.
If you're having to create 10 different index actions which are all that simple - then I'm inclined to think there's a problem somewhere else. This could be because I'm primarily thinking of public internet web apps rather than Lob type apps. (My LOB SaaS app is WebForms :( ).
> How are users of RoR based MVC Frameworks > reusing actions across controllers? I think the frameworks encourage > users to reuse code in a bad way (Template Method Pattern).
This seems like a pretty unusual requirement. For scaffolding type things (early stages) people use scaffolding. Once they've got past that the actions usually are very specific to the controller and use cases they're working within.
> I wish I could show you our code, but I cannot. I will work up a > better example this weekend that will show the problem better.
Even just a different example would help - as I said above - I'm not aware of lots of people having this kind of problem so maybe you've struck a whole new usecase.
Oh - just so I'm clear - I'm all for making dynamic actions nicer and SmartDispatcherAction sounds interesting . I'm just curious about whats driving this.
I am looking for ideas too. At present time, I am not sure "first class actions" can be encouraged with the current frameworks. They are all centered around controllers with public methods.
Do you have any ideas?
I still get the feeling you and I are not on the same page. I wish we could talk face-to-face. This would be easier.
On Oct 26, 8:28 am, "Ken Egozi" <egoz...@gmail.com> wrote:
> Ok. so what would you have liked to see changed in the DAction API in order > to make'em more encouraged?
> On 10/26/07, Adam Esterline <a...@esterlines.com> wrote:
> > I agree that DAction are a good design choice. But... DActions are > > not the encouraged by the framework. > > That is my only point.
> > On Oct 26, 6:53 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > But the only way to activate the action is though a route. how else > > would > > > you construct a url that will activate a "standalone" action?
> > > anyway - if the action needs re-use then DAction is a good design choice > > > imho.
> > > and setup the DAction on the needed controllers (instead of setting it > > up in > > > the route rule as you've suggested). > > > I do not see the bad design here.
> > > On 10/26/07, Adam Esterline <a...@esterlines.com> wrote:
> > > > > So it's not the DActions are not good, the implementation details > > isn't > > > > nice > > > > > enough, so we might need to think how to improve that.
> > > > I would agree. In MonoRail, DActions are the only way to handle the > > > > problem > > > > I described above. DAs need more "niceness". I am sure this could > > > > be done now > > > > by coding a SmartDispatcherAction that implements the IDynamicAction > > > > interface.
> > > > I really want to stress that Controllers with public action/methods > > > > leads developers > > > > into making bad design decisions. I did it. You suggested it. > > > > The framework > > > > leads you down a bad path. Without actions being a first class > > > > concept this will continue.
> > > > Controllers with public action/methods make great demos and simple > > > > quick applications. > > > > When developing non-simple applications that need to be DRY, it fails.
> > > > > the RoutingEngine is not for routing from Url to CLR. > > > > > it's for routing (or actually re-writing) an arbitrary > > Url to standard > > > > > rails url.
> > > > > plus - this couples the framework tightly to a specific > > RoutingEngine > > > > > implementation, thus introducing a compulsory complication that is > > not > > > > > supposed to be there, breaking Convention-Over-Configuration.
> > > > > I'm not saying that it's bad. It might be great for your needs. but > > I > > > > cannot > > > > > see it as part of the framework
> > > > I don't really see it as being tightly coupled. Your actions no > > > > nothing about > > > > the routing engine. I can agree to disagree.
> > > > AE
> > > > On Oct 26, 12:48 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > > On 10/25/07, Adam Esterline <a...@esterlines.com> wrote:
> > > > > > After we realized BaseController<T> was a > > > > > > nightmare we aggressively moved > > > > > > to DynamicActions. Our controllers ended up having a > > constructor > > > > > > with a bunch of dynamic action creations.
> > > > > So it's not the DActions are not good, the implementation details > > isn't > > > > nice > > > > > enough, so we might need to think how to improve that.
> > > > > After seeing this evolve,
> > > > > > we thought our controllers were really not > > > > > > doing anything... other than organizing our actions.
> > > > > That's what controllers do. the executable code in a controller > > (aka > > > > public > > > > > method) is an action, so all over your application, the controllers > > are > > > > > logical groups of actions. If you do have an "all around" action > > that > > > > does > > > > > not belong to an existing controller, you'd create a new controller > > for > > > > that > > > > > action.
> > > > > the RoutingEngine is not for routing from Url to CLR. > > > > > it's for routing (or actually re-writing) an arbitrary > > Url to standard > > > > > rails url.
> > > > > plus - this couples the framework tightly to a specific > > RoutingEngine > > > > > implementation, thus introducing a compulsory complication that is > > not > > > > > supposed to be there, breaking Convention-Over-Configuration.
> > > > > I'm not saying that it's bad. It might be great for your needs. but > > I > > > > cannot > > > > > see it as part of the framework
> > > > > Not sure this is the best code, but you get the idea. You could
> > > > > > structure your "Routes" such that they are grouped by "concepts/ > > > > > > controllers".
> > > > > instead of "routes" and "concepts", use "actions" and "controllers" > > - > > > > and > > > > > it's baked in
> > > > > Hopefully this explains, a little better, my point of view.
> > > > > Me too ;)
> > > > > AE
> > > > > > On Oct 25, 3:27 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > > > > in short, I think there is a room for adding smartDispatch > > > > capabilities > > > > > > to > > > > > > > the DynamicAction, but i don't like the "standalone action" > > thing. > > > > > > > why?
> > > > > > > my view on that as I tried to post it as a comment on Adam's > > blog: > > > > > > > The idea is nice. > > > > > > > Might be useful, but on another scenarios. > > > > > > > Inheritance does make sense in your scenario, as both > > controllers > > > > share > > > > > > > behavior and semantics. > > > > > > > So I'd use the inheritance thing, but a bit differently (from > > the > > > > top of > > > > > > my > > > > > > > head, in pseudo): > > > > > > > class BaseController<T> ... > > > > > > > { > > > > > > > protected virtual InternalIndex(...)..}
> > > > > > > class ProductsController : BaseController<Product> > > > > > > > { > > > > > > > public void Index(...) { InternalIndex(...); }} > > > > > > > etc. > > > > > > > >> "ProductsController and CategoriesController no longer > > "speak" to > > > > me"
> > > > > > > so now, the controller "speaks" to you.
> > > > > > > Now about DynamicActions being "second class citizens", Id say > > that > > > > your > > > > > > > idea can be served as en enhancement to the DActions.
> > > > > > > however not in the way you've introduced as it would make the > > whole > > > > > > thing > > > > > > > dependant on routing.
> > > > > > > MR should be simple.
> > > > > > > when I tell a newbie that url->Area/Controller/Action, the last > > > > thing I > > > > > > need > > > > > > > to tell him is "except ...".
> > > > > > > >> "What were our controllers doing? They were really just > > > > organizing > > > > > > our
I think the problem that people are having is simply that an action is "defined" (commonly associated) as a unique process that occurs inside your application. I too have a hard time imagining a case where I'd want to share an action between controllers. If I found the need to run the same action in multiple controllers, I'd either re-factor that action into a new controller, and call it from the others as necessary or pull the logic from the action into the service layer. That said though, I agree with Josh, and would love to see an example of an action needing to be re-used, that was more complicated than just a render of a template.
On 10/26/07, Adam Esterline <a...@esterlines.com> wrote:
> I am looking for ideas too. At present time, I am not sure "first > class actions" can be encouraged with the current frameworks. They > are all centered around controllers with public methods.
> Do you have any ideas?
> I still get the feeling you and I are not on the same page. I wish > we could talk face-to-face. This would be easier.
> On Oct 26, 8:28 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > Ok. so what would you have liked to see changed in the DAction API in > order > > to make'em more encouraged?
> > On 10/26/07, Adam Esterline <a...@esterlines.com> wrote:
> > > I agree that DAction are a good design choice. But... DActions are > > > not the encouraged by the framework. > > > That is my only point.
> > > On Oct 26, 6:53 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > But the only way to activate the action is though a route. how else > > > would > > > > you construct a url that will activate a "standalone" action?
> > > > anyway - if the action needs re-use then DAction is a good design > choice > > > > imho.
> > > > and setup the DAction on the needed controllers (instead of setting > it > > > up in > > > > the route rule as you've suggested). > > > > I do not see the bad design here.
> > > > On 10/26/07, Adam Esterline <a...@esterlines.com> wrote:
> > > > > > So it's not the DActions are not good, the implementation > details > > > isn't > > > > > nice > > > > > > enough, so we might need to think how to improve that.
> > > > > I would agree. In MonoRail, DActions are the only way to handle > the > > > > > problem > > > > > I described above. DAs need more "niceness". I am sure this > could > > > > > be done now > > > > > by coding a SmartDispatcherAction that implements the > IDynamicAction > > > > > interface.
> > > > > I really want to stress that Controllers with public > action/methods > > > > > leads developers > > > > > into making bad design decisions. I did it. You suggested it. > > > > > The framework > > > > > leads you down a bad path. Without actions being a first class > > > > > concept this will continue.
> > > > > Controllers with public action/methods make great demos and simple > > > > > quick applications. > > > > > When developing non-simple applications that need to be DRY, it > fails.
> > > > > > the RoutingEngine is not for routing from Url to CLR. > > > > > > it's for routing (or actually re-writing) an arbitrary > > > Url to standard > > > > > > rails url.
> > > > > > plus - this couples the framework tightly to a specific > > > RoutingEngine > > > > > > implementation, thus introducing a compulsory complication that > is > > > not > > > > > > supposed to be there, breaking Convention-Over-Configuration.
> > > > > > I'm not saying that it's bad. It might be great for your needs. > but > > > I > > > > > cannot > > > > > > see it as part of the framework
> > > > > I don't really see it as being tightly coupled. Your actions no > > > > > nothing about > > > > > the routing engine. I can agree to disagree.
> > > > > AE
> > > > > On Oct 26, 12:48 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > > > On 10/25/07, Adam Esterline <a...@esterlines.com> wrote:
> > > > > > > After we realized BaseController<T> was a > > > > > > > nightmare we aggressively moved > > > > > > > to DynamicActions. Our controllers ended up having a > > > constructor > > > > > > > with a bunch of dynamic action creations.
> > > > > > So it's not the DActions are not good, the implementation > details > > > isn't > > > > > nice > > > > > > enough, so we might need to think how to improve that.
> > > > > > After seeing this evolve,
> > > > > > > we thought our controllers were really not > > > > > > > doing anything... other than organizing our actions.
> > > > > > That's what controllers do. the executable code in a controller > > > (aka > > > > > public > > > > > > method) is an action, so all over your application, the > controllers > > > are > > > > > > logical groups of actions. If you do have an "all around" > action > > > that > > > > > does > > > > > > not belong to an existing controller, you'd create a new > controller > > > for > > > > > that > > > > > > action.
> > > > > > What if routing had a nice syntax/dsl?
> > > > > > the RoutingEngine is not for routing from Url to CLR. > > > > > > it's for routing (or actually re-writing) an arbitrary > > > Url to standard > > > > > > rails url.
> > > > > > plus - this couples the framework tightly to a specific > > > RoutingEngine > > > > > > implementation, thus introducing a compulsory complication that > is > > > not > > > > > > supposed to be there, breaking Convention-Over-Configuration.
> > > > > > I'm not saying that it's bad. It might be great for your needs. > but > > > I > > > > > cannot > > > > > > see it as part of the framework
> > > > > > Not sure this is the best code, but you get the idea. You > could
> > > > > > > structure your "Routes" such that they are grouped by > "concepts/ > > > > > > > controllers".
> > > > > > instead of "routes" and "concepts", use "actions" and > "controllers" > > > - > > > > > and > > > > > > it's baked in
> > > > > > Hopefully this explains, a little better, my point of view.
> > > > > > Me too ;)
> > > > > > AE
> > > > > > > On Oct 25, 3:27 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > > > > > in short, I think there is a room for adding smartDispatch > > > > > capabilities > > > > > > > to > > > > > > > > the DynamicAction, but i don't like the "standalone action" > > > thing. > > > > > > > > why?
> > > > > > > > my view on that as I tried to post it as a comment on Adam's > > > blog: > > > > > > > > The idea is nice. > > > > > > > > Might be useful, but on another scenarios. > > > > > > > > Inheritance does make sense in your scenario, as both > > > controllers > > > > > share > > > > > > > > behavior and semantics. > > > > > > > > So I'd use the inheritance thing, but a bit differently > (from > > > the > > > > > top of > > > > > > > my > > > > > > > > head, in pseudo): > > > > > > > > class BaseController<T> ... > > > > > > > > { > > > > > > > > protected virtual InternalIndex(...)..}
> > > > > > > > class ProductsController : BaseController<Product> > > > > > > > > { > > > > > > > > public void Index(...) { InternalIndex(...); }} > > > > > > > > etc. > > > > > > > > >> "ProductsController and CategoriesController no longer > > > "speak" to > > > > > me"
> > > > > > > > so now, the controller "speaks" to you.
> > > > > > > > Now about DynamicActions being "second class citizens", Id > say > > > that > > > > > your > > > > > > > > idea can be served as en enhancement to the DActions.
> > > > > > > > however not in the way you've introduced as it would make > the > > > whole > > > > > > > thing > > > > > > > > dependant on routing.
> > > > > > > > MR should be simple.
> > > > > > > > when I tell a newbie that url->Area/Controller/Action, the > last > > > > > thing I > > > > > > > need > > > > > > > > to tell him is "except ...".
> > > > > > > > >> "What were our controllers doing? They were really just > > > > > organizing > > > > > > > our
I do have this need actually. I usually push things to a base class, or a set of base classes, but it is gets painful after a while. I will have a post about it shortly.
On 10/26/07, josh robb <josh_r...@fastmail.fm> wrote:
> > Did you never try to reuse actions, across controllers, in your > > projects?
> No. I've never had a situation where I could (where the code wasn't > trivial). I think that the problem is that the index action example is > so trvial I don't see the problem.
> If you're having to create 10 different index actions which are all > that simple - then I'm inclined to think there's a problem somewhere > else. This could be because I'm primarily thinking of public internet > web apps rather than Lob type apps. (My LOB SaaS app is WebForms :( ).
> > How are users of RoR based MVC Frameworks > > reusing actions across controllers? I think the frameworks encourage > > users to reuse code in a bad way (Template Method Pattern).
> This seems like a pretty unusual requirement. For scaffolding type > things (early stages) people use scaffolding. Once they've got past > that the actions usually are very specific to the controller and use > cases they're working within.
> > I wish I could show you our code, but I cannot. I will work up a > > better example this weekend that will show the problem better.
> Even just a different example would help - as I said above - I'm not > aware of lots of people having this kind of problem so maybe you've > struck a whole new usecase.
Searching. I have several places where I need to do searching, and interact with the results in interesting ways. It can be printing, export to excel, paging, saving results or queries. All of the above except the initial search is shared.
On 10/26/07, Tanner Burson <tanner.bur...@gmail.com> wrote:
> I think the problem that people are having is simply that an action is > "defined" (commonly associated) as a unique process that occurs inside your > application. I too have a hard time imagining a case where I'd want to > share an action between controllers. If I found the need to run the same > action in multiple controllers, I'd either re-factor that action into a new > controller, and call it from the others as necessary or pull the logic from > the action into the service layer. That said though, I agree with Josh, and > would love to see an example of an action needing to be re-used, that was > more complicated than just a render of a template.
> On 10/26/07, Adam Esterline <a...@esterlines.com> wrote:
> > I am looking for ideas too. At present time, I am not sure "first > > class actions" can be encouraged with the current frameworks. They > > are all centered around controllers with public methods.
> > Do you have any ideas?
> > I still get the feeling you and I are not on the same page. I wish > > we could talk face-to-face. This would be easier.
> > On Oct 26, 8:28 am, "Ken Egozi" < egoz...@gmail.com> wrote: > > > Ok. so what would you have liked to see changed in the DAction API in > > order > > > to make'em more encouraged?
> > > On 10/26/07, Adam Esterline < a...@esterlines.com> wrote:
> > > > I agree that DAction are a good design choice. But... DActions > > are > > > > not the encouraged by the framework. > > > > That is my only point.
> > > > On Oct 26, 6:53 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > > But the only way to activate the action is though a route. how > > else > > > > would > > > > > you construct a url that will activate a "standalone" action?
> > > > > anyway - if the action needs re-use then DAction is a good design > > choice > > > > > imho.
> > > > > and setup the DAction on the needed controllers (instead of > > setting it > > > > up in > > > > > the route rule as you've suggested). > > > > > I do not see the bad design here.
> > > > > On 10/26/07, Adam Esterline <a...@esterlines.com> wrote:
> > > > > > > So it's not the DActions are not good, the implementation > > details > > > > isn't > > > > > > nice > > > > > > > enough, so we might need to think how to improve that.
> > > > > > I would agree. In MonoRail, DActions are the only way to > > handle the > > > > > > problem > > > > > > I described above. DAs need more "niceness". I am sure this > > could > > > > > > be done now > > > > > > by coding a SmartDispatcherAction that implements the > > IDynamicAction > > > > > > interface.
> > > > > > I really want to stress that Controllers with public > > action/methods > > > > > > leads developers > > > > > > into making bad design decisions. I did it. You suggested > > it. > > > > > > The framework > > > > > > leads you down a bad path. Without actions being a first class > > > > > > concept this will continue.
> > > > > > Controllers with public action/methods make great demos and > > simple > > > > > > quick applications. > > > > > > When developing non-simple applications that need to be DRY, it > > fails.
> > > > > > > the RoutingEngine is not for routing from Url to CLR. > > > > > > > it's for routing (or actually re-writing) an arbitrary > > > > Url to standard > > > > > > > rails url.
> > > > > > > plus - this couples the framework tightly to a specific > > > > RoutingEngine > > > > > > > implementation, thus introducing a compulsory complication > > that is > > > > not > > > > > > > supposed to be there, breaking Convention-Over-Configuration.
> > > > > > > I'm not saying that it's bad. It might be great for your > > needs. but > > > > I > > > > > > cannot > > > > > > > see it as part of the framework
> > > > > > I don't really see it as being tightly coupled. Your actions > > no > > > > > > nothing about > > > > > > the routing engine. I can agree to disagree.
> > > > > > AE
> > > > > > On Oct 26, 12:48 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > > > > On 10/25/07, Adam Esterline < a...@esterlines.com> wrote:
> > > > > > > > After we realized BaseController<T> was a > > > > > > > > nightmare we aggressively moved > > > > > > > > to DynamicActions. Our controllers ended up having a > > > > constructor > > > > > > > > with a bunch of dynamic action creations.
> > > > > > > So it's not the DActions are not good, the implementation > > details > > > > isn't > > > > > > nice > > > > > > > enough, so we might need to think how to improve that.
> > > > > > > After seeing this evolve,
> > > > > > > > we thought our controllers were really not > > > > > > > > doing anything... other than organizing our actions.
> > > > > > > That's what controllers do. the executable code in a > > controller > > > > (aka > > > > > > public > > > > > > > method) is an action, so all over your application, the > > controllers > > > > are > > > > > > > logical groups of actions. If you do have an "all around" > > action > > > > that > > > > > > does > > > > > > > not belong to an existing controller, you'd create a new > > controller > > > > for > > > > > > that > > > > > > > action.
> > > > > > > What if routing had a nice syntax/dsl?
> > > > > > > the RoutingEngine is not for routing from Url to CLR. > > > > > > > it's for routing (or actually re-writing) an arbitrary > > > > Url to standard > > > > > > > rails url.
> > > > > > > plus - this couples the framework tightly to a specific > > > > RoutingEngine > > > > > > > implementation, thus introducing a compulsory complication > > that is > > > > not > > > > > > > supposed to be there, breaking Convention-Over-Configuration.
> > > > > > > I'm not saying that it's bad. It might be great for your > > needs. but > > > > I > > > > > > cannot > > > > > > > see it as part of the framework
> > > > > > > Not sure this is the best code, but you get the idea. You > > could
> > > > > > > > structure your "Routes" such that they are grouped by > > "concepts/ > > > > > > > > controllers".
> > > > > > > instead of "routes" and "concepts", use "actions" and > > "controllers" > > > > - > > > > > > and > > > > > > > it's baked in
> > > > > > > Hopefully this explains, a little better, my point of view.
> > > > > > > Me too ;)
> > > > > > > AE
> > > > > > > > On Oct 25, 3:27 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > > > > > > in short, I think there is a room for adding smartDispatch
> > > > > > capabilities > > > > > > > > to > > > > > > > > > the DynamicAction, but i don't like the "standalone > > action" > > > > thing. > > > > > > > > > why?
> > > > > > > > > my view on that as I tried to post it as a comment on > > Adam's > > > > blog: > > > > > > > > > The idea is nice. > > > > > > > > > Might be useful, but on another scenarios. > > > > > > > > > Inheritance does make sense in your scenario, as both > > > > controllers > > > > > > share > > > > > > > > > behavior and semantics. > > > > > > > > > So I'd use the inheritance thing, but a bit differently > > (from > > > > the > > > > > > top of > > > > > > > > my > > > > > > > > > head, in pseudo): > > > > > > > > > class BaseController<T> ... > > > > > > > > > { > > > > > > > > > protected virtual InternalIndex(...)..}
> > > > > > > > > so now, the controller "speaks" to you.
> > > > > > > > > Now about DynamicActions being "second class citizens", Id > > say > > > > that > > > > > > your > > > > > > > > > idea can be served as en enhancement to the DActions.
> > > > > > > > > however not in the way you've introduced as it would make > > the > > > > whole > > > > > > > > thing > > > > > > > > > dependant on routing.
> > > > > > > > > MR should be simple.
> > > > > > > > > when I tell a newbie that url->Area/Controller/Action, the > > last > > > > > > thing I > > > > > > > > need > > > > > > > > > to tell him is "except ...".
> > > > > > > > > >> "What were our controllers doing? They were really just
I'd like (in your examination that you'd present at that post) to show how you can solve your problem within the current toolset, and to refer to DActions and how (maybe) extending them might fit your needs.
On 10/26/07, Ayende Rahien <aye...@ayende.com> wrote:
> I do have this need actually. > I usually push things to a base class, or a set of base classes, but it is > gets painful after a while. > I will have a post about it shortly.
> On 10/26/07, josh robb <josh_r...@fastmail.fm> wrote:
> > > Did you never try to reuse actions, across controllers, in your > > > projects?
> > No. I've never had a situation where I could (where the code wasn't > > trivial). I think that the problem is that the index action example is > > so trvial I don't see the problem.
> > If you're having to create 10 different index actions which are all > > that simple - then I'm inclined to think there's a problem somewhere > > else. This could be because I'm primarily thinking of public internet > > web apps rather than Lob type apps. (My LOB SaaS app is WebForms :( ).
> > > How are users of RoR based MVC Frameworks > > > reusing actions across controllers? I think the frameworks encourage > > > users to reuse code in a bad way (Template Method Pattern).
> > This seems like a pretty unusual requirement. For scaffolding type > > things (early stages) people use scaffolding. Once they've got past > > that the actions usually are very specific to the controller and use > > cases they're working within.
> > > I wish I could show you our code, but I cannot. I will work up a > > > better example this weekend that will show the problem better.
> > Even just a different example would help - as I said above - I'm not > > aware of lots of people having this kind of problem so maybe you've > > struck a whole new usecase.
> > I for one am curious to understand this better.
Our app needed to allow the same kinds of searches across entities. ByZip, ByCityState... The searching actions had complicated rendering logic that we did not want to rewrite. Example:
If you want to see the code in action check out sothebyshomes.com. Look at the top at the "Quick Search". There are several entities that need to support the same kinds of searches with the same kinds of error handling in each. You can actually see some of the error handling in practice.
Quick search by Area and give the zip code of 90210 (california). After doing this you will see the other region error page. This search by Area is present in Properties for Sale, Properties for Rent, Agents, Offices.
We started by implementing these with public methods in controllers with a base class. Each of the shared search functionality needed several template methods to satisfy it's requirements. After just a few search types, this becomes really ugly and painful. What made it worse is not all entities should inherit all search types. You can only imagine. I wish I could release the version of our base controller before we started cleaning it up (I asked, but got no).
Does this example help?
On Oct 26, 10:23 am, "Ayende Rahien" <aye...@ayende.com> wrote:
> Searching. > I have several places where I need to do searching, and interact with the > results in interesting ways. > It can be printing, export to excel, paging, saving results or queries. > All of the above except the initial search is shared.
> On 10/26/07, Tanner Burson <tanner.bur...@gmail.com> wrote:
> > I think the problem that people are having is simply that an action is > > "defined" (commonly associated) as a unique process that occurs inside your > > application. I too have a hard time imagining a case where I'd want to > > share an action between controllers. If I found the need to run the same > > action in multiple controllers, I'd either re-factor that action into a new > > controller, and call it from the others as necessary or pull the logic from > > the action into the service layer. That said though, I agree with Josh, and > > would love to see an example of an action needing to be re-used, that was > > more complicated than just a render of a template.
> > On 10/26/07, Adam Esterline <a...@esterlines.com> wrote:
> > > I am looking for ideas too. At present time, I am not sure "first > > > class actions" can be encouraged with the current frameworks. They > > > are all centered around controllers with public methods.
> > > Do you have any ideas?
> > > I still get the feeling you and I are not on the same page. I wish > > > we could talk face-to-face. This would be easier.
> > > On Oct 26, 8:28 am, "Ken Egozi" < egoz...@gmail.com> wrote: > > > > Ok. so what would you have liked to see changed in the DAction API in > > > order > > > > to make'em more encouraged?
> > > > On 10/26/07, Adam Esterline < a...@esterlines.com> wrote:
> > > > > I agree that DAction are a good design choice. But... DActions > > > are > > > > > not the encouraged by the framework. > > > > > That is my only point.
> > > > > On Oct 26, 6:53 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > > > But the only way to activate the action is though a route. how > > > else > > > > > would > > > > > > you construct a url that will activate a "standalone" action?
> > > > > > anyway - if the action needs re-use then DAction is a good design > > > choice > > > > > > imho.
> > > > > > and setup the DAction on the needed controllers (instead of > > > setting it > > > > > up in > > > > > > the route rule as you've suggested). > > > > > > I do not see the bad design here.
> > > > > > On 10/26/07, Adam Esterline <a...@esterlines.com> wrote:
> > > > > > > > So it's not the DActions are not good, the implementation > > > details > > > > > isn't > > > > > > > nice > > > > > > > > enough, so we might need to think how to improve that.
> > > > > > > I would agree. In MonoRail, DActions are the only way to > > > handle the > > > > > > > problem > > > > > > > I described above. DAs need more "niceness". I am sure this > > > could > > > > > > > be done now > > > > > > > by coding a SmartDispatcherAction that implements the > > > IDynamicAction > > > > > > > interface.
> > > > > > > I really want to stress that Controllers with public > > > action/methods > > > > > > > leads developers > > > > > > > into making bad design decisions. I did it. You suggested > > > it. > > > > > > > The framework > > > > > > > leads you down a bad path. Without actions being a first class > > > > > > > concept this will continue.
> > > > > > > Controllers with public action/methods make great demos and > > > simple > > > > > > > quick applications. > > > > > > > When developing non-simple applications that need to be DRY, it > > > fails.
> > > > > > > > the RoutingEngine is not for routing from Url to CLR. > > > > > > > > it's for routing (or actually re-writing) an arbitrary > > > > > Url to standard > > > > > > > > rails url.
> > > > > > > > plus - this couples the framework tightly to a specific > > > > > RoutingEngine > > > > > > > > implementation, thus introducing a compulsory complication > > > that is > > > > > not > > > > > > > > supposed to be there, breaking Convention-Over-Configuration.
> > > > > > > > I'm not saying that it's bad. It might be great for your > > > needs. but > > > > > I > > > > > > > cannot > > > > > > > > see it as part of the framework
> > > > > > > I don't really see it as being tightly coupled. Your actions > > > no > > > > > > > nothing about > > > > > > > the routing engine. I can agree to disagree.
> > > > > > > AE
> > > > > > > On Oct 26, 12:48 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > > > > > On 10/25/07, Adam Esterline < a...@esterlines.com> wrote:
> > > > > > > > > After we realized BaseController<T> was a > > > > > > > > > nightmare we aggressively moved > > > > > > > > > to DynamicActions. Our controllers ended up having a > > > > > constructor > > > > > > > > > with a bunch of dynamic action creations.
> > > > > > > > So it's not the DActions are not good, the implementation > > > details > > > > > isn't > > > > > > > nice > > > > > > > > enough, so we might need to think how to improve that.
> > > > > > > > After seeing this evolve,
> > > > > > > > > we thought our controllers were really not > > > > > > > > > doing anything... other than organizing our actions.
> > > > > > > > That's what controllers do. the executable code in a > > > controller > > > > > (aka > > > > > > > public > > > > > > > > method) is an action, so all over your application, the > > > controllers > > > > > are > > > > > > > > logical groups of actions. If you do have an "all around" > > > action > > > > > that > > > > > > > does > > > > > > > > not belong to an existing controller, you'd create a new > > > controller > > > > > for > > > > > > > that > > > > > > > > action.
> > > > > > > > What if routing had a nice syntax/dsl?
> > > > > > > > the RoutingEngine is not for routing from Url to CLR. > > > > > > > > it's for routing (or actually re-writing) an arbitrary > > > > > Url to standard > > > > > > > > rails url.
> > > > > > > > plus - this couples the framework tightly to a specific > > > > > RoutingEngine > > > > > > > > implementation, thus introducing a compulsory complication > > > that is > > > > > not > > > > > > > > supposed to be there, breaking Convention-Over-Configuration.
> > > > > > > > I'm not saying that it's bad. It might be great for your > > > needs. but > > > > > I > > > > > > > cannot > > > > > > > > see it as part of the framework
> > > > > > > > Not sure this is the best code, but you get the idea. You > > > could
> > > > > > > > > structure your "Routes" such that they are grouped by > > > "concepts/ > > > > > > > > > controllers".
> > > > > > > > instead of "routes" and "concepts", use "actions" and > > > "controllers" > > > > > - > > > > > > > and > > > > > > > > it's baked in
> > > > > > > > Hopefully this explains, a little better, my point of view.
> > > > > > > > Me too ;)
> > > > > > > > AE
> > > > > > > > > On Oct 25, 3:27 am, "Ken Egozi" <egoz...@gmail.com> wrote: > > > > > > > > > > in short, I think there is a room for adding smartDispatch
> > > > > > > capabilities > > > > > > > > > to > > > > > > > > > > the DynamicAction, but i don't like the "standalone > > > action" > > > > > thing. > > > > > > > > > > why?
> > > > > > > > > > my view on that as I tried to post it as a comment on > > > Adam's > > > > > blog: > > > > > > > > > > The idea is nice. > > > > > > > > > > Might be useful, but on another scenarios. > > > > > > > > > > Inheritance does make sense in your scenario, as both > > > > > controllers > > > > > > > share > > > > > > > > > > behavior and semantics. > > > > > > > > > > So I'd use the inheritance thing, but a bit differently > > > (from > > > > > the > > > > > > > top of > > > > > > > > > my > > > > > > > > > > head, in pseudo): > > > > > > > > > > class BaseController<T> ... > > > > > > > > > > {
> I'd like (in your examination that you'd present at that post) to show how > you can solve your problem within the current toolset, and to refer to > DActions and how (maybe) extending them might fit your needs.
> On 10/26/07, Ayende Rahien <aye...@ayende.com> wrote:
> > I do have this need actually. > > I usually push things to a base class, or a set of base classes, but it > > is gets painful after a while. > > I will have a post about it shortly.
> > On 10/26/07, josh robb <josh_r...@fastmail.fm> wrote:
> > > > Did you never try to reuse actions, across controllers, in your > > > > projects?
> > > No. I've never had a situation where I could (where the code wasn't > > > trivial). I think that the problem is that the index action example is
> > > so trvial I don't see the problem.
> > > If you're having to create 10 different index actions which are all > > > that simple - then I'm inclined to think there's a problem somewhere > > > else. This could be because I'm primarily thinking of public internet > > > web apps rather than Lob type apps. (My LOB SaaS app is WebForms :( ).
> > > > How are users of RoR based MVC Frameworks > > > > reusing actions across controllers? I think the frameworks > > > encourage > > > > users to reuse code in a bad way (Template Method Pattern).
> > > This seems like a pretty unusual requirement. For scaffolding type > > > things (early stages) people use scaffolding. Once they've got past > > > that the actions usually are very specific to the controller and use > > > cases they're working within.
> > > > I wish I could show you our code, but I cannot. I will work up a > > > > better example this weekend that will show the problem better.
> > > Even just a different example would help - as I said above - I'm not > > > aware of lots of people having this kind of problem so maybe you've > > > struck a whole new usecase.
> > > I for one am curious to understand this better.
> On 10/26/07, Ken Egozi <egoz...@gmail.com> wrote:
> > I'm sure you would.
> > I'd like (in your examination that you'd present at that post) to show > > how you can solve your problem within the current toolset, and to refer to > > DActions and how (maybe) extending them might fit your needs.
> > On 10/26/07, Ayende Rahien < aye...@ayende.com> wrote:
> > > I do have this need actually. > > > I usually push things to a base class, or a set of base classes, but > > > it is gets painful after a while. > > > I will have a post about it shortly.
> > > On 10/26/07, josh robb <josh_r...@fastmail.fm> wrote:
> > > > > Did you never try to reuse actions, across controllers, in your > > > > > projects?
> > > > No. I've never had a situation where I could (where the code wasn't > > > > trivial). I think that the problem is that the index action example > > > > is > > > > so trvial I don't see the problem.
> > > > If you're having to create 10 different index actions which are all > > > > that simple - then I'm inclined to think there's a problem somewhere > > > > else. This could be because I'm primarily thinking of public > > > > internet > > > > web apps rather than Lob type apps. (My LOB SaaS app is WebForms :( > > > > ).
> > > > > How are users of RoR based MVC Frameworks > > > > > reusing actions across controllers? I think the frameworks > > > > encourage > > > > > users to reuse code in a bad way (Template Method Pattern).
> > > > This seems like a pretty unusual requirement. For scaffolding type > > > > things (early stages) people use scaffolding. Once they've got past > > > > that the actions usually are very specific to the controller and use
> > > > cases they're working within.
> > > > > I wish I could show you our code, but I cannot. I will work up > > > > a > > > > > better example this weekend that will show the problem better.
> > > > Even just a different example would help - as I said above - I'm not
> > > > aware of lots of people having this kind of problem so maybe you've > > > > struck a whole new usecase.
> > > > I for one am curious to understand this better.
