I've debated with my boss about this 6 months ago when I was put into the middle of a project.  They had 3 Commands that did A LOT of stuff.  The typical setup was DB driven design.  Most people on the team come from strong CF backgrounds.  As such, the client architecture fits really well into this.  The CFC's, Delegate's, and Commands are all almost seamless in methods.  Since we have about 4 core CFC's that drive most of our logic, from a server-side developer perpsective, this is quite nice.  The CFC gives me the data, the Delegate shoves it through a factory to clean up pre-CF 7.0.2's mess, the Command's set the appropriate data.
 
The thing I changed almost immediately when I came on board is implementing Event classes.  This is in Flex 1.5, mind you, so these aren't typically used.  However, the insane amount of Constant values used in the FontController were really hard to grasp.  It took me about 2 months to really get "comfortable" in the code base because it was so huge.  That was quick, in my opinion, considering their architect was extremely anal retentive, and this paid off; everything followed standards, and my expectations grew strong because everything followed the same pattern.  The Event classes took it a step further, because now I had context on what "I wanted to happen" when dispatching it.  The FrontController is a lot easier to read, now too because you can get a better idea of what the events are really causing to happen.
 
Concrete example?  Nope... but what really IS concrete in programming?  My boss told me to do it that way, we debated heavily, and I gave in because I didn't have enough good ammo, nor clout at the time, to really make an architectual impact to an already old, huge, and working well, code base.  If it ain't broke, don't fix it.  He does heavily support refactoring, though, so he was, and still is, open minded, as am I.
 
I actually really don't have a strong opinion either way.  While many commands are lighter weight and more specifc, I think most have a common theme on what they are doing, at least with our app.  Thus, being in the same Command class is comforting as there is a lot of similiar methods nearby that remind me of what other parts are doing; remember, we're all using the same Delegate class, just calling different methods on the same CFC.  I had an older Flash app I did in ARP where we calling a lot of un-related Java class methods.  So, this made sense.  I understand Commands are supposed to be implied user actions, and in this case, they basically were since every Java method (about 30) did something specific.   23'ish of them were user specific actions where the rest were behind the scenes data management jazz.  ...so, I can see where both angles work.  I've been heads down for 6 months in 4 commands, so, forrest for the trees, ya know?
 
 
 
----- Original Message -----
Sent: Thursday, July 06, 2006 3:55 PM
Subject: RE: [flexcoders] Re: WebService & Cairngorm 2 Example

I don't necessarily agree here with Jesse; for me, a Command is most useful when it's an implementation of a single use-case, and when it executes in context, and handles it's results in context.  If there is functionality that is shared between commands, then I'd either move that functionality into a base command, or into a class that can be used by multiple commands.  I don't however, like the idea of coalescing multiple commands into one, or that the motivation for doing this being "having a lot of classes".
 
For those new to Cairngorm, I'd strongly advocate following the patterns as we've presented them, rather than commands switching their behavior as you describe here Jesse. 
 
Can you share a concrete example where you think there's valid reason to coalesce the commands ?
 
Steven
 
Steven Webster
Practice Director (Rich Internet Applications)
Adobe Consulting
Westpoint, 4 Redheughs Rigg, South Gyle, Edinburgh, EH12 9DQ, UK
p: +44 (0) 131 338 6108
m: +44 (0) 7917 428 947 
[EMAIL PROTECTED]

 


From: [email protected] [mailto:[EMAIL PROTECTED] On Behalf Of JesterXL
Sent: 06 July 2006 16:08
To: [email protected]
Subject: Re: [flexcoders] Re: WebService & Cairngorm 2 Example

Naw. Commands aren't necessarely needing to be created that way. You
could, but for larger apps, you'd end up with a LOT of Commands. However,
it's not too tough to re-factor because if you coelecsed many Commands into
one, you'd really only need to change the Controller's addCommans function.

So, if you want to start that way, sure, go for it. For smaller projects,
it'll make it easier to identify what Command does what, and you won't have
to use custom responders in your Command's either if your Delegate only does
one thing.

For larger projects, however, you'll end up having many Commands doing
similiar things to similiar data; it's just easier to combine them in the
same class so related code is nearby for reference and/or sharing. Same
goes for Delegate's. A common strategy we've done is mapping our Delegate's
to CFC's; some of our CFC's, have say, 8 methods. 1 Delegate will have 8
public methods.

----- Original Message -----
From: "ben.clinkinbeard" <ben.clinkinbeard@gmail.com>
To: <[EMAIL PROTECTED]ups.com>
Sent: Thursday, July 06, 2006 10:37 AM
Subject: [flexcoders] Re: WebService & Cairngorm 2 Example

Very cool. That all makes pretty much sense. I do have another
question (shocking, huh?) about why you would have a single command
support multiple events/use multiple delegates. Isn't the point of
Commands to have a class that does one thing (and nothing else)?

Thanks again,
Ben

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com
Yahoo! Groups Links

__._,_.___

--
Flexcoders Mailing List
FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.com





SPONSORED LINKS
Web site design development Computer software development Software design and development
Macromedia flex Software development best practice


YAHOO! GROUPS LINKS




__,_._,___

Reply via email to