Thanks for the responses guys,
Dimitrios:
Yes, the majority of
my views are updated through binding to the
ModelLocator. However, there
are certain functions that are soley
view-related (like setFocus(),
filtering a DataGrid, updating a
search parameter VO with view component
values prior to executing a
search command), that imo don't merit creating
a command to
perform. These kind of functions could just be located in a
script
tag inside the view. But, if the functions are numerous, the code
becomes more readable if a seperate class is used.
Bjorn:
I
agree that a command shouldn't interrogate a view. That would
defeat the
encapsulation. For the most part though, the command
should update the
ModelLocator and the ModelLocator should update
the
view.
Jesse:
As always, you crack me up. In the situations that I
mentioned
above, I assume that you are using a ViewLocator - uid approach.
This is probably more efficient and centralized than using
ViewHelpers. Besides, I really don't want to deal with Satan
spawn.
Care to share a small sample of your approach?
All in all, this isn't a
huge issue. Out of my current 300 views,
I've only found the need to use
three ViewHelpers. My questions are
more theoretical and best practice
oriented. Good stuff to know
when scalability is an issue. Also, I'm still
not sure what Alex
Uhlmann meant by "the ViewHelper adds and removes
itself from the
ViewLocator". Guess I need to take a trip back to the
Cairngorm
source.
Thanks again for your answers. I was hoping that
Steven or
Alistaire had time to chime in here, but I realize that they are
very busy these days.
Cheers,
Tim Hoff
--- In [EMAIL PROTECTED]ups.com,
"JesterXL" <[EMAIL PROTECTED].> wrote:
>
> ViewHelpers ==
spawn of satan. Nothing here but bloated
code. "Seperation
> of
concerns" doesn't count here; it's just something they say to
make
> themselves feel better by using them.
>
> ViewLocators,
to me are only justified in extreme use cases.
Having other
>
View's, or even Commands specifically telling other views to do
certain
> things are bad practice, but I have seen times where there is just
no other
> way. The rest of the time, databinding and combinations
of
getter / setters
> should accomplish what you want. While their
use should be
discouraged,
> I'll be the first to admit they are
useful and lifesavers when you
need
> them.
>
>
> ----- Original Message -----
> From: "Tim Hoff"
<[EMAIL PROTECTED]>
> To: <[EMAIL PROTECTED]ups.com>
>
Sent: Monday, July 03, 2006 6:05 AM
> Subject: [flexcoders] Cairngorm2:
ViewLocator - ViewHelper
>
>
> I've recently been toying
with the concepts of ViewHelper vs.
> ViewLocator. Alex Ulmann posted,
"the ViewHelper adds and removes
> itself from the ViewLocator", in
his Cairngorm 2 (for Flex 2) -
> Overview and Migration Path. I haven't
seen any examples yet that
> illustrate this method. Understandably, the
example pool and
> documentation for this kind of thing is small but
growing. So, I
was
> wondering if the authors of Cairngorm had any
advise/guidance for
this
> topic. Of course it's a matter of scale,
but in an enterprise
> application, what is recommended as best practice
for the use of
> ViewLocator and/or ViewHelpers? I'm sure that there are
forthcoming
> books that cover this area, but feedback here might
promote better
> understanding.
>
> Best regards,
>
Tim Hoff
>
>
>
>
>
>
>
--
> 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
>
