I've not really had those problems myself Tink. I don't dispatch any standard cairngorm events, instead I have events that extend it and are (usually!) fairly well named to reflect what's happening. Maybe that's because for me they normally carry some data, and I like that data to be as strongly typed as is practicable. The command/delegate will usually follow the same naming, so I may have SaveBitmapEvent + SaveBitmapCommand + SaveBitmapDelegate, for example. So to find any particular event dispatch in my view, it's pretty easy to do a "find in files" on the project, though in practice I find I rarely need to. Likewise, finding the command it calls is pretty easy for the most part, as is the implementation in the delegate.
Good point on the controller not listening, but I guess I've just got used to
writing a shell version of my command, breakpointing it's constructor and
checking it does get called when I expect it to before proceeding to fill in
it's implementation. If not, then the frontController has it's fingers in it's
ears shouting na na na I can't hear you :)
It would be good if it could catch all cairngorm events and raise a warning if
they were not registered, though. I have a feeling it wouldn't be too hard to
extend it do that, but I've never felt the need myself.
I'm sure we're both thinking "don't make me have to think too hard, if at all",
and I'm in broad agreement with you, but the 3 classes and controller entry
approach does work for me (even if it is very tedious to write at the time).
-----Original Message-----
From: flexcoders@yahoogroups.com on behalf of Stephen Downs
Sent: Sun 04/05/2008 14:08
To: flexcoders@yahoogroups.com
Subject: Re: [flexcoders] Re: Use Cairngorm wihtout Dispatch
I have to agree with MichNiu here.
The CairngormEventDispatcher obsfucates the code. i.e. you come back
to a project 6 months down the line, its difficult to find in the
view where your CairngormEvents are dispatch.
What is the difference of the view knowing what event it has to
dispatch, to it actually knowing the method on the controller it was
to invoke? Very little in my opinion, but the later enables you to
very easily pinpoint all the calls from the view to a method on the
controller, by just changing the name of the method on the
controller, and looking at all the errors that will appear on the
view. This makes things much easier to debug and therefore easier to
maintain.
You talk about making views re-useable, but if your view is
dispatching CairngormEvents, you can guarantee it's relying on some
action of the FrontController for it to work properly. If you
FrontController doesn't listen to these events, your view won't work,
therefore it aint re-usable, its relying on the FrontController
acting upon the events is dispatches.
We still keep a Controller unlike MichNui's implementation, but we
cut out the use of CairngormEventDispatcher some time ago.
Now when it comes to re-usable components, thats a different matter.
Tink
On 22 Apr 2008, at 03:53, ben.clinkinbeard wrote:
> One of the core principles of not just Cairngorm but MVC in general is
> for your views to be as dumb as possible. The less they know about
> models, services, etc the better. You've essentially taken the
> opposite approach. Creating reusable/generic views using your approach
> wouldn't really be possible.
>
> Also, Flex is an event driven architecture and events are another core
> aspect of creating loosely coupled application components. I think
> your approach will result in very brittle code that will be hard to
> maintain.
>
> Ben
>
> --- In flexcoders@yahoogroups.com, "michniu" <[EMAIL PROTECTED]> wrote:
> >
> > Hi Coders,
> >
> > I just want to discuss some issues about the Cairngorm, Because I
> > cant find another mail list or forum to discuss it. I put it
> > here.
> >
> >
> > The most useless part in cairngorm ----FrontCotroller and command
> >
> >
> > Just on my opinion, I really don't like to write the command for
> > every action and register it on FrontCotroller. I really think it
> > waste time, and It make debugging difficult! Sometimes you don't
> > know where do you get the result after you dispatched your Event.
> >
> >
> >
> > Use A ServiceFacade to replace the front controller and the command.
> >
> > I use a ServiceFacade to call the Delegate instead of the
> > controller and the junk command.
> >
> > The idea is when the view page active some action. it will not
> > dispatch any event . it will call the service method from service
> > facade.
> >
> > Here is example code form flexStore:
> >
> > private function onLoadCatalog():void {
> > var event : LoadCatalogEvent = new
> > oadCatalogEvent();
> > event.dispatch();
> > }
> >
> > to replace the event dispatch() my solution is :
> >
> > private function onLoadCatalog():void {
> >
> > ServiceFacade.getInstance().loadCats();
> > }
> >
> >
> > The ServiceFacade .loadCats() method call the delegate and service:
> >
> > public function loadCats():void {
> > var handlers : IResponder
> > = new Responder
> > (onResults_loadCatalog,fault);
> > getDelegate(handlers).loadCatalog();
> > }
> >
> >
> > Use this way, I don't need create any front Controller and
> > command. I also get the benefit from Cairngorm Service Locate
> > Delegate and Model locator.
> >
> >
> > Any suggestion or Criticize is Appreciated
> >
> >
> > Mike
> >
>
>
>
______________________________________________________________________
This communication is from Primal Pictures Ltd., a company registered in
England and Wales with registration No. 02622298 and registered office: 4th
Floor, Tennyson House, 159-165 Great Portland Street, London, W1W 5PA, UK. VAT
registration No. 648874577.
This e-mail is confidential and may be privileged. It may be read, copied and
used only by the intended recipient. If you have received it in error, please
contact the sender immediately by return e-mail or by telephoning +44(0)20 7637
1010. Please then delete the e-mail and do not disclose its contents to any
person.
This email has been scanned for Primal Pictures by the MessageLabs Email
Security System.
______________________________________________________________________<<winmail.dat>>
