WTF, since when do Delagates know about the ModelLocator? Tom, I'm
sorry to disagree with you here, but a Delagate is nothing more than
a proxy for a service call; a layer of abstraction to help
encapsulate the Commands. Basically, what you're talking about here
is an event, containing the searchSting, that is dispatched to a
Command and a VO that is passed, from a Command to a Service; via a
Delagate.
package com.vo
{
import com.adobe.cairngorm.vo.ValueObject;
[Bindable]
public class SearchVO implements ValueObject
{
public var searchString : String;
public var userID : String;
}
}
The userID is persistant, while the searchString is temporary. In
the view, the searchString should be attached to the event, either
by using a custom event or using the event's data property. The
Command then takes the searchString from the event and updates the
VO in the ModelLocator. The VO is then passed on to the Delegate
which passes it on to the Service. This way only the Command
updates the ModelLocator; nice encapsulation. I've seen code that
has the view update the VO directly and uses the VO with a custom
event. But I don't beleive that this is the intended best practice.
I think that events should only carry temporary data and the
ModelLocator (VO's) should hold persistant data. In this scenario,
the searchString is temporary, but is held in the VO because it
might be needed for user notification of a failed search attempt.
IMHO, Delegates shouldn't know about the ModelLocator at all and
Views should only know about the ModelLocator through binding. The
Commands should do all of the work.
-TH
--- In [email protected], "Ben Lucyk" <[EMAIL PROTECTED]> wrote:
>
> I second this.
>
> Ben Lucyk
> http://esria.com
> p 1.877.TRY.ESRIA ext 718
> c 1.408.489.3913
> f 1.877.828.4436
> [EMAIL PROTECTED]
>
>
>
>
>
>
>
>
> ________________________________
>
> From: [email protected]
[mailto:[EMAIL PROTECTED] On
> Behalf Of Ralf Bokelberg
> Sent: Wednesday, October 11, 2006 4:27 AM
> To: [email protected]
> Subject: Re: [flexcoders] Cairngorm commands - best practise
>
> My delegates don't know about the model locator, but my commands
do.
> So I vote for commands.
>
> Cheers,
> Ralf.
>
> On 10/11/06, hank williams <[EMAIL PROTECTED]
> <mailto:hank777%40gmail.com> > wrote:
> > So we have Tom saying do it in the delegate and Bjorn saying do
it in
> > the command.
> >
> > Any tie breakers?
> >
> > Hank
> >
> > On 10/11/06, Tom Chiverton <[EMAIL PROTECTED]
> <mailto:tom.chiverton%40halliwells.com> > wrote:
> > > On Wednesday 11 October 2006 02:12, Robin Burrer wrote:
> > > > However I also want to send the userID when I do my server
> request.
> > > > Should the SearchDatabaseCommand get the userID from the
model or
> from
> > >
> > > I reasoned that passing any parameters not connected with what
to do
> was no
> > > business of the Command, and had the service delegate look up
the
> additional
> > > parameters from the model:
> > > public function
> search(r:String,c:String,o:String,d:String,h:String):void {
> > > var call:Object =
> serviceInstance.search(model.sessionToken,r,c,o,d,h);
> > > call.resultHandler = responder.onResult;
> > > call.faultHandler = responder.onFault;
> > > }
> > >
> > > --
> > > Tom Chiverton
> > > Helping to efficiently transform magnetic systems
> > >
> > > ****************************************************
> > >
> > > 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 St James's Court Brown Street Manchester M2
2JF. 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 Law Society.
> > >
> > > 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 8008.
> > >
> > > For more information about Halliwells LLP visit
www.halliwells.com.
> > >
> > >
> > >
> > > --
> > > Flexcoders Mailing List
> > > FAQ:
> http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
> <http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt>
> > > Search Archives:
> http://www.mail-archive.com/flexcoders%40yahoogroups.com
> <http://www.mail-archive.com/flexcoders%40yahoogroups.com>
> > > Yahoo! Groups Links
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> >
> >
> > --
> > Flexcoders Mailing List
> > FAQ:
http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt
> <http://groups.yahoo.com/group/flexcoders/files/flexcodersFAQ.txt>
> > Search Archives:
> http://www.mail-archive.com/flexcoders%40yahoogroups.com
> <http://www.mail-archive.com/flexcoders%40yahoogroups.com>
> > Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
> --
> Ralf Bokelberg <[EMAIL PROTECTED]
> <mailto:ralf.bokelberg%40gmail.com> >
> Flex & Flash Consultant based in Cologne/Germany
>
--
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
<*> 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/
