Re: [flexcoders] Re: Use Cairngorm wihtout Dispatch
On Wednesday 07 May 2008, Stephen Downs wrote: > You mean if you change the name of a method on your controller? I also mean if it's interface changes i.e. the order, number or data type of arguments changes. One case where that wouldn't mean a change to the view would be if the controller no needs some Model value injecting into it. -- Tom Chiverton This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
Re: [flexcoders] Re: Use Cairngorm wihtout Dispatch
You mean if you change the name of a method on your controller? Sounds like you'd have the same prob if you change the name of the event you were listening to on your controller. You'd have to change the event back to the correct name in your controller (i.e. the same as changing the method name back), or change every view to dispatch the new event your were using in your controller (after finding them ;)). The diff is, using events it would fail silently, then you'd have to search to find the events being dispatched by your view, where as the view calling a method on the controller that had its name changed would show me errors before I compiled. -- Stephen Downs Addict, Tink Ltd. e: [EMAIL PROTECTED] t: +44 (0) 7730 838 785 w: http://www.tink.ws -- On 6 May 2008, at 11:48, Tom Chiverton wrote: On Sunday 04 May 2008, Stephen Downs wrote: 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? If your Controller changes, you have to change every view that uses it. -- Tom Chiverton Helping to preemptively maintain strategic e-commerce on: http://thefalken.livejournal.com This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders% 40yahoogroups.comYahoo! Groups Links
Re: [flexcoders] Re: Use Cairngorm wihtout Dispatch
On Sunday 04 May 2008, Stephen Downs wrote: > 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? If your Controller changes, you have to change every view that uses it. -- Tom Chiverton Helping to preemptively maintain strategic e-commerce on: http://thefalken.livejournal.com This email is sent for and on behalf of Halliwells LLP. Halliwells LLP is a limited liability partnership registered in England and Wales under registered number OC307980 whose registered office address is at Halliwells LLP, 3 Hardman Square, Spinningfields, Manchester, M3 3EB. A list of members is available for inspection at the registered office. Any reference to a partner in relation to Halliwells LLP means a member of Halliwells LLP. Regulated by The Solicitors Regulation Authority. CONFIDENTIALITY This email is intended only for the use of the addressee named above and may be confidential or legally privileged. If you are not the addressee you must not read it and must not use any information contained in nor copy it nor inform any person other than Halliwells LLP or the addressee of its existence or contents. If you have received this email in error please delete it and notify Halliwells LLP IT Department on 0870 365 2500. For more information about Halliwells LLP visit www.halliwells.com. -- Flexcoders Mailing List FAQ: http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt Search Archives: http://www.mail-archive.com/flexcoders%40yahoogroups.comYahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/flexcoders/ <*> Your email settings: Individual Email | Traditional <*> To change settings online go to: http://groups.yahoo.com/group/flexcoders/join (Yahoo! ID required) <*> To change settings via email: mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
[flexcoders] Re: Use Cairngorm wihtout Dispatch
> 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,
Re: [flexcoders] Re: Use Cairngorm wihtout Dispatch
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" <[EMAIL PROTECTED]> wrote: > > > > Hi Coders, > > > > I just want t
RE: [flexcoders] Re: Use Cairngorm wihtout Dispatch
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
[flexcoders] Re: Use Cairngorm wihtout Dispatch
ServiceFacade.getInstance().loadCats();
public function loadCats():void {
var handlers : IResponder = new
mx.rpc.Responder(onResults_loadCatalog,fault);
getDelegate(handlers).loadCatalog();
}
Looks like a terrible solution.
I agree with your comments regarding the Controller and Commands but
replacing them with a singleton that defines all your applications
responder methods doesn't seem very manageable.
--- In flexcoders@yahoogroups.com, "michniu" <[EMAIL PROTECTED]> wrote:
>
> Hi Coders,
>
> I just want to discuss some issues about the Cairgorm, Because I
> cant find another maillist or forum to discuss it. I put it here.
>
>
> The most uselees part in cairgorm frontCotroller and command
>
>
> Just my on opionion, I really dont like to write the command for
> every action and register it on frontcoutroller. I really think it
> waste time, and It make debuging difficult! Sometimes you dont know
> where do you get the result after you dispathce your Event.
>
>
>
> Use A ServiceFacade to replace the frontcontroller 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
> dispathc any event . it will call the service mathod from service
> facade.
>
> Here is example code form flexStore:
>
>/**
> * Wrapper function to invoke a call to load the
> catalog XML data
> * @private
> */
> private function onLoadCatalog():void {
> var event : LoadCatalogEvent =
> new oadCatalogEvent();
> event.dispatch();
> }
>
> to replace the event dispath() my solution is :
>
>private function onLoadCatalog():void {
>
> ServiceFacade.getInstance().loadCats();
> }
>
>
> And Ind ServiceFacade .loadCats() method call teh delegate and
> service:
>
> public function loadCats():void {
> var handlers : IResponder = new
> mx.rpc.Responder(onResults_loadCatalog,fault);
> getDelegate(handlers).loadCatalog();
> }
>
>
> Use this way, I dont need create any frontController and command.
> I also get the benefit from Cairgorm ServiceLocate Delegate and
> Model locator.
>
>
> Any suggestion or Criticze is Appretiate
>
>
> Mike
>
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
>
[flexcoders] Re: Use Cairngorm wihtout Dispatch
Thanks for replying.
Lets talk about MVC. there are two different implementation of
MVC. One is Event driven, Which means call The Model(Service) in
Action. In JAVA Framework, JSF is the one. Another is Action driven.
Which means dispatch and Central listen. like Struts in Java.
I think my solution just call the Service in Every Flex Action.
not Dispatch to a Central controller.
The benefit is The logic is much more clear. and It is much more
easier to maintain, Because You always know which service is
used in the Exactly Flex Action(event).
compare the Cairngorm workflow:
View-->Action-->dipatch event--> frontcontroller-->command--
>delegate--->sevice Locator-->Modellocate--->View.
To:
View-->Action-->Service Facade-->Delegate-->Service locator-->Model
locator-->View
I relly think my way is much more easier and clearer.
Cheers
Mike
--- In flexcoders@yahoogroups.com, "ben.clinkinbeard"
<[EMAIL PROTECTED]> 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" 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
> >
>
[flexcoders] Re: Use Cairngorm wihtout Dispatch
Thanks for replying.
Lets talk about MVC. there are two different implementation of
MVC. One is Event driven, Which means call The Model(Service) in
Action. In JAVA Framework, JSF is the one. Another is Action driven.
Which means dispatch and Central listen. like Struts in Java.
I think my solution just call the Service in Every Flex Action.
not Dispatch to a Central controller.
The benefit is The logic is much more clear. and It is much more
easier to maintain, Because You always know which service is
used in the Exactly Flex Action(event).
compare the Cairngorm workflow:
View-->Action-->dipatch event--> frontcontroller-->command--
>delegate--->sevice Locator-->Modellocate--->View.
To:
View-->Action-->Service Facade-->Delegate-->Service locator-->Model
locator-->View
I relly think my way is much more easier and clearer.
Cheers
Mike
--- In flexcoders@yahoogroups.com, "ben.clinkinbeard"
<[EMAIL PROTECTED]> 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" 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
> >
>
[flexcoders] Re: Use Cairngorm wihtout Dispatch
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
>
