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
