I agree completely with Niall on this one. I cannot believe that the basic action class could conceivably be considered to carry this overhead.
On 5/9/06, Niall Pemberton <[EMAIL PROTECTED]> wrote:
On 5/4/06, Michael Jouravlev <[EMAIL PROTECTED]> wrote: > What we has been brought from the stone ages: > > * Base Action class does not dispatch events > * DispatchAction and its flavors do, but they do not allow a user to > derive an action class from some another user's base action > > What we got now in 1.2.9 and 1.3.1+ : > > * ActionDispatcher resolves the inheritance issue, allowing any action > to dispatch events > * EventActionDispatcher makes dispatching an easy and fun task; it > also allows to separate input phase from render phase, at the same > time it allows to trigger event with links (GET), not only with > buttons (POST). > > What appears to be a logical next step: > > * Stick dispatching features in base Action, thus making all actions > to be dispatch actions. > > Benefits: > > * ActionDispatcher will not be needed. > * Any action will be able to dispatch events. > * This makes a mind shift, making people think more in terms of events > and independent webresources, kind of like .NET's code-behind. > > Minor drawback: > > * only one dispatching behavior can be chosen. Considering all job > done before, we how have best-of-breed EventDispatchAction. Its > features (maybe in some modified manner) should be pushed to base > Action class. For those who rely on old-style DispatchAction or > MappingDispatchAction, they will still be available. > > So, the proposed feature changes nothing for regular Action users, it > changes nothing for old DispatchAction users, but it makes things a > lot simpler for those who want to switch to event-based paradigm with > as little efforts as possible. > > Thoughts? Objections? Suggestions? Personally I'm against this because IMO it just adds confusion/complexity to the Action class that is unnecessary for users who don't want to use the "dispatch" style. I also think that the current provision for "dispatch" flavours isn't a real barrier for people to adopt the style that you're promoting here. For people not limited/restricted by having to inherit from a "base" action class, they can simply inherit from one of the DispatchAction falvours. For people limited/restricted by having to inherit from a "base" action class, they can use the ActionDispatcher (or EventActionDispatcher) to easily plug in dispatch behaviour. Simply making the code changes you suggest will not shift people's mindset - you would need to document the choices available. IMO documentation is more important than merging the dispatch logic into the Action class and if Action and DispatchAction flavours were better documented you could achieve the same without changing the code at all. I don't use any of the DispatchAction/ActionDispatcher flavours and am happy with "simple" Actions. If we do document this better I would prefer we didn't promote one style over the other - but simply layout what the choices people have and let them decide. Niall > Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
-- "You can lead a horse to water but you cannot make it float on its back." ~Dakota Jack~ --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
