> 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
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.
