architecture. I wish you good luck and success with your
application.
Take care,
Tim Hoff
--- In [email protected], "maxym.hryniv" <[EMAIL PROTECTED]> 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
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.
