1."view is dependent on environment in cairngorm"
2."multiwindow apps are not suported in cairngorm"
I wish you good luck in software development.
--- In [email protected], "Tim Hoff" <[EMAIL PROTECTED]> wrote:
>
> No problem Maxym. It sounds like you are set with your current
> architecture. I wish you good luck and success with your
> application.
>
> Take care,
> Tim Hoff
>
> --- In [email protected], "maxym.hryniv" <mokus@> wrote:
> >
> > Thanx, Tim. I'm not taking offence, but i'm really care about
> > 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 [email protected], "Tim Hoff" <TimHoff@> 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 [email protected], "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 [email protected], "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.
