Hey Doug,
My backend is mainly DAO's and I've got one delegate pers DAO in my
company lib, that gets used across multiple projects.
But I'm pretty sure thats not Cairngorm.
Cairngorm is 1 to 1 e-c-d.
regards,
Bjorn
On 23/10/2007, at 2:33 PM, Douglas Knudsen wrote:
me2 :) I usually use one delegate per application or major
division of the app, eg Modules. This delegate can access how ever
many services it needs to to do the job. Further, it can rely on
utility classes to massage incoming data if need be too. Now if I
have to switch from WebService to RemoteObject, only need to create
one new delegate to use, eh? bamm!
DK
On 10/22/07, ben.clinkinbeard <[EMAIL PROTECTED]> wrote:
Yea, I just don't buy into that. I am all for short files and clear
separation of responsibilities, but I don't see what
single-method-delegates buys you. My delegates are pretty dumb, they
just contain methods that take params and pass em along to web
methods. I don't access the model or anything inside my delegates. To
each his own obviously but I just don't think I will ever be sold on
that division. I guess I'm a Cairngorm rebel. :)
Ben
--- In flexcoders@yahoogroups.com, Bjorn Schultheiss
<[EMAIL PROTECTED]> wrote:
>
> Hey Ben,
>
>
> The Idea is that even if you are calling the same webservice you are
> to create a new delegate.
>
> The sequence is Event - Command - Delegate.
>
> Not saying that i follow it, but I'm sure in it's strictest
> implementation its 1 to 1.
>
>
> Check this
> http://jessewarden.com/2007/08/10-tips-for-working-with-
cairngorm.html
> 6. There are 3 ways to use Commands & Delegates. I prefer A because
> it's consistent, leads to short class files, and is very explicit.
> A) For every use case, you make 1 Command and 1 Event. This can
> sometimes also mean 1 Delegate. (ie, LoginEvent, LoginCommand,
> LoginDelegate)
>
>
> Anyone from AC care to confirm?
>
>
>
> On 23/10/2007, at 12:08 PM, ben.clinkinbeard wrote:
>
> > > the 1 to 1 event-command-delegate methodology
> >
> > I've heard that mentioned indirectly a couple of times before but
> > don't remember ever reading it as a suggested methodology. Maybe I
> > just missed that instruction but I don't follow that practice.
I have
> > one delegate per Web Service, so several Commands end up using the
> > same Delegate.
> >
> > As a general practice, I think Commands are very often an
appropriate
> > and efficient approach.
> >
> > I haven't looked into PureMVC yet but would like to at some point.
> > That being said, I've also not really encountered any
situations where
> > I felt Cairngorm was restricting me from accomplishing anything.
> >
> > Ben
> >
> > --- In flexcoders@yahoogroups.com, Bjorn Schultheiss
> > <bjorn.mailinglists@> wrote:
> > >
> > > Hey All,
> > >
> > > I don't know if there has been a previous thread on this. I'm
> > > assuming there is but i thought i'd start one again in light
of some
> > > recent blog posts about a Silvafug meeting by the assertTrue
guys on
> > > frameworks.
> > >
> > > http://www.asserttrue.com/articles/2007/10/17/silvafug-
application-
> > > frameworks-presentation
> > > http://probertson.com/articles/2007/10/18/flex-application-
> > frameworks-
> > > presentations/
> > > http://www.sephiroth.it/weblog/archives/2007/10/
flex_frameworks.php
> > >
> > > I haven't used PureMVC yet but I have used Cairngorm for a while
> > > (since the flash 7 days).
> > >
> > > I will say I've got a few beefs with Cairngorm and from just
looking
> > > at the PureMVC diagram i already see a few solutions.
> > >
> > > I guess my main beefs with cairngorm has been the use of
commands.
> > > Specifically in creating Re-usable commands.
> > > the 1 to 1 event-command-delegate methodology has never sat well
> > with
> > > me.
> > >
> > > Dumb Models (vo collections) is another.
> > >
> > > Support for unit testing in the View is another.
> > >
> > >
> > > Anyone care to help start a discussion?
> > >
> > >
> > > regards,
> > >
> > > Bjorn
> > >
> >
> >
> >
>
--
Douglas Knudsen
http://www.cubicleman.com
this is my signature, like it?
