but how often do you need model to be shared across views that are backed by different mxmls? Even if you need it you can access one view from another, you can create some more general ViewHelper in this case that will contain that model. I'm my project 90% cases are just dummy calls to the server and displaying the results. If I'll need something that does not fit this concept and makes viewhelper very complex I can always refactor, but why should I start having in mind that I'm writing something very complex. My principle is use the simplest reasonable way that works. If it works for JSF, Struts, Webwork, Tapestry then why it does not work for RIA, only because client has more logic? Maybe cause I have no DnD in Java and some effects but all the rest seems to be the same.
Anyway I'm glad that people realize that this approach can work. All I want is just not to do the sings more complex than they are. Refactoring will help if I'm wrong, but in most cases it will not be required.
Mykola Paliyenko
Senior Software Engineer at Sonopia
On 11/15/05, Renaun Erickson <[EMAIL PROTECTED]> wrote:
The code example fit Mykola's arguments well, which I see as a case
for a component that self contains everything. The Model, ViewHelper,
and Command for these specific components would never be reused
outside the component it self. Is there a need for this? Could be,
but a lot of times Models run across multiple Views hence the need for
more hefty patterns.
For example you have one component that is the form to update a User
(UserFormView), self containing all the ViewHelper, Model, and Command
in the component is much easier then 5 different files. This is
probably perfectly fine if the UserFormView component is truly self
contained. But most applications require a lot of reuse and coupling
is not so distinct and sometimes not so predictable.
Some of the different view points depend on the way the Application
are conceived and developed. A server business logic driven
application like Mykola's case below might warrant strict self
contained components. The Use Case driven Cairngorm methodology
creates more robust components that are unaware of each other (excuse
me for my broad statement here).
Where I start to see self contained components break down is where the
Model should be used across multiple Views. It nice to have a command
setup a Collection of data that is bound across multiple views, and
then to change you logic of when it gets loaded is really simple. You
dont have to worry about all the places the Collection is used, all
you have to worry about is the asynchronous of the Command call.
I believe there is some room for discussion on the specific uses of
self contained components and maybe some ways of integrating both
ideas into Cairngorm. Of course with Flex 2 and the Data Services
handling CRUD functions we'll have lots to discuss in the future.
Renaun
--
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.
