Speaking
for Steven, but the reason they espoused using ModelLocator over
ViewHelpers was a few reasons. First off, many people felt the need to
create ViewHelpers for every View. This was ridicolous; no View could ever
do anything useful but instantiate GUI components, and register for
events.
You had no clue WHAT that View could do. Suddenly you're code base
basically doubled for extremely little gain.
Secondly, most people
utilized ViewHelpers with ViewLocator instead of the
actual View's. While
this was nice, no one ever implemented strong typing,
thus defeating the
purpose of casting as ViewHelper describing what the View
could
do.
Third, you wrote more code for no gain. Some people would even put
code in
both the MXML View and ViewHelper, further compounding the issue
of "what's
really being seperated here".
In all fairness, I come
from a Flash background where you wrote classes.
These classes were your
View. You can do the same thing in Flex; write your
class to extend Canvas
instead of using a root Canvas tag; same thing. To
me, organizing code is
2nd nature. MXML + embedded Script tags were just a
wonderful next step.
My code changes never broke my GUI changes and vice
versa. For some
reason, it seems people can't fathom the thought of
ActionScript in MXML
files. That's just absurd; you can see what the GUI is
AND does in the
same. Go look at the source code; all kinds of controls
draw themselves
and perform actions. This isn't rocket science, it's a
fuggin' form for
crying out loud.
The other option of using an external script file for
the script tag is just
as bad. You have to define controls and other
buttons again, defeating the
use of the ID control concept which helps
shield your code from being broken
when you change your GUI. :: que Carlos
Mencia duh dah daaaa ::
Bottom line, MXML components are extremely
portable and encapsulated with
ActionScript inside them. Granted, there
are still people who will write
"components" with ModelLocator's
littered amongst them vs. expousing public
properties and methods to set
the data instead... but that's the developers
fault, not
MXML's.
MXML is just a class... it's ok to write properties and methods
in a
class... seriously, it's ok. :: whips out a bag of teddy bears to
hand out
just in case ::
----- Original Message -----
From:
"Tim Hoff" <[EMAIL PROTECTED]com>
To: <[EMAIL PROTECTED]ups.com>
Sent:
Monday, July 03, 2006 5:01 PM
Subject: [flexcoders] Re: Cairngorm2:
ViewLocator - ViewHelper
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
>
--
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
