Re: [flexcoders] Re: Cairngorm is bad?

[Anatole Tartakovsky]

Mikola,     Dumb terminal tend to have some effect on programs written for them. RIA tries to change that by offering richer event-driven paradigm that allow you to show data in more ways and interact with it in more ways. As such, the responses from the server become smaller, more granulated/targeted toward UI, requests need to become faster. etc..       You indeed can reduce 90% of the SERVER work with more of the usage of standard components or generated code provided that STATE is transparently supported by front-end components.       You can use Struts - but without much benefit in terms of code size. Tapestry is great, but needs layer of support to work with controls so it is rapid application developments rather then optimizing 90% of 20%.       Refactoring of Flex applications is no fun - there are to many areas that can break and go unchecked - your best line of defense (as 10 years ago) is still to amount the least amount of code and use more reliable components. That is were Frameworks come in the play - by advertising that the code in them has been used and tested and does 80% of what you need to do.         I personally do not like frameworks. They usually evolve out of applications. That imposes 2 problems: 1. The problem is that it have to "fit".  Let us say you are building motorbikes, cars and trucks. You can share concepts, but not the complex parts - they would either brake or would not fit.  At best, you would have smaller thing that are interchangeable - nuts and bolts and signals. Can I reuse the shopping cart? Not likely, not without refactoring that would be bigger effort then writing from scratch. Serving 20 requests /sec and 2,000 require me to build differently - no abstraction survives the load, sorry. There is one thing that is indeed shared by companies making bikes, cars, trucks, planes, etc - tools to make concept into a product and base components.   2. Second problem is that frameworks formalize the process of building software by providing the "coding style" to adhere to. Some people call it patterns, some experience, but in the end it is just the base language constructs you are thinking with. It offers communication platform for larger group of people by abstraction. Internet revolution was a cultural shock that introduced most of patterns as the only way to express yourself as the sizes of development teams went out of control. Lack of tools caused use of manpower instead of tools, canned designs and manufacturing instead of custom design and engineering. It works, do not get me wrong, but it reaps most of the developers from the main benefit of intellectual work - creativity and individualism.   I think that part of Flex community might want an alternative to frameworks and that alternative is Tooling and Components. Here is simple test: 1.Try not to use some framework or library or component for a week. Change remoteObject to WebService or XML/HTTP Request. At the end of the week look at code that has been done and you would see that you created better performing, more powerful way to do things that fits better your style and applications. 2. Now try not to use your favorite IDE (Eclipse or such) or code generator (Struts or Tapestry ) and observe amount of code or extra steps you are making. In a week you are worse then before as your productivity is down and no solution is coming.   For the last 15 years company I am working at would spend at least 50% of my time manufacturing tools and components and the rest doing applications to make money while putting these tools/components to the test. Works both ways - you are getting reusable parts of applications as you manufacture them  - and  cleanly separate tools from components from application code.   I think time came to put an effort in the creation of Flash/Flex components with high reusability - that would take away most of the framework appeal without giving false promises.   Thank you, Anatole Tartakovsky [EMAIL PROTECTED]           ----- Original Message ----- From: Mykola Paliyenko To: flexcoders@yahoogroups.com Sent: Tuesday, November 15, 2005 11:05 AM Subject: Re: [flexcoders] Re: Cairngorm is bad? Good point Renaun, 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 SPONSORED LINKS Web site design development Computer software development Software design and development Macromedia flex Software development best practice 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.