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" <[EMAIL PROTECTED]>
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
> [EMAIL PROTECTED]
>
--
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
- 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.
