> The point I was making as that just because events are used on the
> view instead of it accessing controller methods directly it doesn't
> necessarily de-couple them
Agreed.
Also, I don't like being restricted to only being able to register
events types to command classes to a Front Controller that is created
in the view.
Registering the controller in the view means to reference it at
runtime i have to go through the view.
Common sense tells me in MVC it would be better if the controller was
created by the model, not the view.
--- In flexcoders@yahoogroups.com, Stephen Downs <[EMAIL PROTECTED]>
wrote:
>
> I'm not saying it's a major problem that we come across often, but
> when taking on other people's work, or working as a team it's
> something we have come across. We would expect all vars, methods,
> class, events to be named well, but we find it more efficient to
> error the project through changing a method name, than to do a find
> in files. We want to keep things as simple as possible.
>
> The point I was making as that just because events are used on the
> view instead of it accessing controller methods directly it doesn't
> necessarily de-couple them, since in most cases the view is relying
> on its events being picked up and acted upon. If my previous
> statement is true for you and your team, there's really no need to go
> down the event road, as it does introduces more complication and with
> it more time to implement.
>
> Just to clarify we don't take this approach on components, but we do
> for views/screens.
>
>
>
>
> On 5 May 2008, at 01:37, Jim Hayes wrote:
>
> > 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" <MichNiu@> 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>
>
