architecture, thats why i'm trying to find not another workaround
solution cause every workaround decrease stability and simplicity of
large system (my app is large - allready 1500 classes on client). You
suggestion can help, but it's another workaround cause
1. Instead of "view dependent on server" or "view dependent on user
type" think "view MUST be independent" (it's general aproach of every
reusable solution). Against redesign of server i think we have to use
inversion to separate the view from the environment, and it's not so
hard, i'm just trying to find a solution that fits to cairngorm.
2.
//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.
I can't take this seriously, cause it's antipattern. It's sounds like
"make all methods 'public' but don't use methods that you don't have
permission to use".
3. For owner and visitor delegate's methods have different signatures,
thats why i can't use the same set of delegates. If I'll redesign
server side to has the same signatures it will be the same adapter but
on the server side.
Can someone suggest how to use binding in multiwindow app based on
cairngorm???
Thanx a lot for all suggestions.
--- In flexcoders@yahoogroups.com, "Tim Hoff" <[EMAIL PROTECTED]> wrote:
>
> Hi,
>
> 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" <mokus@> 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
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.
