Let's take another crack at this. Please don't take offense by my
suggestions. I am trying to help you. To obtain a clean solution
for your application, I believe that you need to change your
approach slightly in two areas; delegates and views. Instead
of "view dependent on server", think "view dependent on user type".
I'll explain shortly. Secondly, in Cairngorm, delegates are nothing
more than proxies. In your case, instead of having delegates based
on user type or server, I would break them down into smaller
functional units. Instead of GuestBookDelegate and
FriendGuestBookDelegate, I would have getMessageDelegate,
addMessageDelegate and removeMessageDelegate. In the delegates,
depending on the user type, you would call one service (server) or
the other. You could do this conditionally or even with
overloading. The way that you currently have it setup, if you add a
feature (like updateMessage), you would have to add redundant
methods to 2 or more places. To my understanding, delegates create
a level of abstraction between a command and a service. They do not
act as control classes. Instead of controlling whether a user can
remove a message in a delegate, you can do it in the view. If the
user shouldn't be able to remove a message, don't display a visible
removeMessage button. Cairngorm events and commands are usually
initiated by user gestures. If the gesture isn't available to the
user, it will not occur. As a tip, you can control the visibility
of a button with a Boolean value that is bound to the ModelLocator.
As far as the rest of it goes, I think that I should call Shirley
McClaine. :--)
Hope that this helps,
Tim Hoff
--- In flexcoders@yahoogroups.com, "maxym.hryniv" <[EMAIL PROTECTED]> wrote:
>
> //While I don't necessarily subscribe to the idea that delegates
> should
> //have a one-to-one mapping with views (I don't know your app, so
I
> can't
> //comment specifically), I see no reason why the delegate layer
should
> //impact on this model/view binding strategy.
> Don't u think that it's can be called "view dependent on server"?
I
> can descripe: we are creating social network and for user own
> guestbook it has GuestBookDelegate with "getMessages()",
> "addMessage(message : GuestbookMessage)", "removeMessage(messageId:
> Number)" methods. For different user guestbook we have another
> delegate FriendGuestBookDelegate with "getMessages(userId :
Number)",
> "addMessage(userId : Number, message : GuestbookMessage)". I think
> it's logical, cause i don't want to extend signature of
> GuestBookDelegate by unnecessary information and i don't want to
have
> a possibility to call "removeMessage" if i don't have such
> permissions.
>
> To resolve this i can of course create Adapters for these
delegates
> that will cast them to same interface than make a set of
workarounds
> to support different delegates, BUT i don't like workarounds.
>
> Can you describe me clean solution, or why we have "one-to-one
mapping
> ". Cause any view only renders data and must be completely
separated
> from data provider.
>
>
> // Hey, I'm just a guy from the RIA practice. I'm not sure we
have a
> //metaphysics practice. :-)
> lol. Respect.
>
> Thanks one more time and reply please to another my post with the
same
> subj.
>
>
> --- In flexcoders@yahoogroups.com, "Steven Webster" <swebster@>
> wrote:
> >
> > Hey,
> >
> > > 1. Using this approach i'm loosing all advantages of flex
> > > data binding, cause if i make decomposition (i did) of my
> > > view, binding to specific property will be really painfull
> > > thing and has to be done by hands.
> >
> > So I don't *quite* follow your example ... If you could even
give
> some
> > psuedo-code of the difficulty you perceive, that might help me
grasp
> > what you see as a problem. To me, the idea of achieving reuse
is
> that
> > the same component can be used multiple times within one
> application,
> > and between different applications.
> >
> > However, at the "highest level of abstraction" (within the
> Application
> > tag for instance), it's acceptable for me that a reusable
component
> > receive it's data from some application-specific data store (the
> > ModelLocator in this sense), while any dependant children
> (components
> > that you decompose) receive their data directly from their
parent.
> >
> > Imagine (from my previous example) that you have:
> >
> > MyView.mxml
> > |
> > +-- MySubViewA.mxml
> > |
> > +-- MySubViewB.mxml
> > |
> > +-- MySubViewC.mxml
> > |
> > +-- MySubSubView.mxml
> >
> > So we have our MyView.mxml component from my previous email, but
now
> we
> > can look deeper at it's implementation and recognise that it
> decomposes
> > into several "dependant children".
> >
> > Now if what you're telling me is that your MySubViewB and
> MySubSubView
> > components also need to fetch that data from the ModelLocator,
then
> the
> > approach I'd suggest is:
> >
> > <view:MyView.mxml instanceSpecificData="{
> > ModelLocator.getInstance().theData }" />
> >
> > But then if you look inside MyView.mxml, it would contain:
> >
> > <view:MySubViewB data="" />
> >
> > Rather than:
> >
> > <view:MySubViewB data="" ModelLocator.getInstance().theData }" />
> >
> > So only the parent container (MyView) interacts with the
> ModelLocator -
> > once it has the data, it's dependant child objects My(Sub)+(View)
*.
> mxml
> > - there's a reg-exp for you - simply receive that data from their
> > parent.
> >
> > For me, this is the correct abstraction of when to get data from
a
> > parent, versus when to get it from the model.
> >
> > Make sense ?
> >
> >
> > > 2. What about different set of delegates for every view
> > > (depends on server architecture)??
> >
> > While I don't necessarily subscribe to the idea that delegates
> should
> > have a one-to-one mapping with views (I don't know your app, so
I
> can't
> > comment specifically), I see no reason why the delegate layer
should
> > impact on this model/view binding strategy.
> >
> > > 3. Don't u think that restriction and freedom seems different?
> >
> > Hey, I'm just a guy from the RIA practice. I'm not sure we have
a
> > metaphysics practice. :-)
> >
> > Best,
> >
> > 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
> > swebster@
> >
>
--
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
- Visit your group "flexcoders" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
