Comments on: The Perfect Flex Application Framework (Part 1 of 2)

By: jonr

jonr — Tue, 30 Jun 2009 15:32:41 +0000

Edward, Thank you for the comment. I do think if you read both parts of the posts it communicates much more than “a simple inventory of likes or dislikes,” as it attempts to highlight where the gaps are in building a typical Flex application that one might want/need a third-party framework to fill. I believe this is an important point, as these tools should be used for a purpose (and at times are not). Since most frameworks do come with a cost, it is important that they play a clearly defined role in any project.

By: Edward Apostol

Edward Apostol — Mon, 29 Jun 2009 19:26:50 +0000

“An simple inventory of the likes or dislikes of the author, while interesting on the surface, leaves a lot up to the reader, if one is to actually come away with knowledge on how to apply any given framework to their current situation.”

I think it is ultimately up to the reader to make the best decision on frameworks. Really at the end of the day its a group of organized code that makes it easier to replicate the practice of making applications easier in the long run. Our firm uses Cairngorm, and we don’t believe it has a high overhead, and have used it for a number of tier one companies. It may be overkill for the “Hello World” application, but I think we realize that.

If however you would build the same application and do some sort of performance metrics across different frameworks, that would be an interesting measure (although I expect the performance difference for code execution to be actually minimal, given these frameworks are probably fairly optimized to begin with” .

Just my two cents.

Edward Apostol
Sr. Instructor, Consultant
New Toronto Group
Certified Adobe Developer, Instructor

By: AB

AB — Sat, 27 Jun 2009 06:09:43 +0000

I agree with the sentiment above, for sure there are times when use of a framework is overkill. Good code goes a long way. However, it’s unlikely that you can put together an enterprise scale application, or work on a team of more than 2 or 3 people, without some pre decided structure. Design patterns are essential, and deciding what patterns to use, and where to use them, is a large part of what frameworks accomplish. A scalable, maintainable application requires pre-planning how the code is going to be oranized, the ways that differet duties will be segregated, how commuication will take place between components, etc. Just as we re-use design patterns, it makes sense to build on framework patterns that have already been thought through, implemented, discussed, improved, scaled, criticized, and revised. Given all that, use of ‘out of the box’ frameworks make sense, but the expectation that a framework will be perfect out of the box is a bit silly. I’m always amused by these sort of blogs and discussions, where frameworks are approached as if they must be accepted as a whole, or the idea that there could be a single framework to rule them all. Sure, if the code of the framework is compiled into a SWC it makes it harded to change what you needs changing. Still, any framework can be adapted as needed. Whatever you come up with as the perfect framework *for you* will be just that, perfect for you, most likely not perfect for any other project. As long as that is kept well in the foreground, fine with me. Discuss away. But keep in mind that 99% of us don’t share the criteria that make this perfect framework work for you. What would help us most will be detailed discussion of what are the good and bad qualities of all the available frameworks. We need to know in what situations they make sense, what parts might be a bad fit, alternative for the parts that are questionable, etc. An simple inventory of the likes or dislikes of the author, while interesting on the surface, leaves a lot up to the reader, if one is to actually come away with knowledge on how to apply any given framework to their current situation.

By: Reverend Dan

Reverend Dan — Tue, 23 Jun 2009 01:26:48 +0000

Man does this topic hit a sore point with me. Have been a developer since 1981 and have seen many frameworks, methodologies and languages go by the wayside (remember snobol?). I like to do my own thing and keep my ears open on what is going on, but when it comes to frameworks and generated code, I really have to do much to keep quiet, which for once (this time), I am not going to.
On the code-generator stand, I have seen it all, the good, the bad and garbage. Even the best systems I have seen always required a group of developers to have some sort of update/script that goes back over the code and ‘fixes’ all of the items not addressed by the original code generated. From entire solutions to simple fixes, they are always there. There is a learning curve using the generated code or using custom code and learning corporate standards so this is moot in my mind. You have control over the way things are done, not some others who think they have it right.
On frameworks. In all of my coding days, I have never used a “framework”. No MVC or any other. Why? Good coding standards. At times my coding has emulated some frameworks, but I have never really changed my coding style in 25+ years. And most of the people I work with, who I consider excellent developers, all work just about the same. Good variable naming. Good function naming. Have a disconnected front-end calling backend functions through webservices, dlls or old style includes. Have well written SQL and stored procs if you are using them. This “framework” I use is fully dynamic and disconnected. If I need to change the front end, don’t have to touch the services or SQL. Need to change underlying table structures, change the table and create a view over it. Easy, dynamic, and simple for anyone to walk in and hit the ground running. Any reusable functions, controls or whatever is stored in a general linked library.
Of course there are times when I have to break my own rules and build tightly coupled code or mock things up to get a bit more time, but in the end have found a simple multi-layer approach with a common library works and has stood the test of time.

By: Shaun

Shaun — Mon, 22 Jun 2009 15:53:04 +0000

@ Jethro: I’m not sure I agree. Code Generators are great when you start a project, but all that boiler plate code is going to hinder/limit refactoring later on.

By: Jethro

Jethro — Mon, 22 Jun 2009 11:37:13 +0000

I have to say the Mark Lapasa’s comments hit the mark.

CG, I would say reduces cost. It requires a low entry level of understanding and helps people locate code in larger more complex projects.

The ‘extra code’ argument I feel is a little bit of a red-herring. We have a simple script to create boilerplate events and commands wired into the front controller, and I know many other developers who have their own too. Its not difficult or time-consuming.

Still, a nice article

By: Jon Rose’s Blog » Blog Archive » The Perfect Flex Application Framework (Part 2 of 2)

Mon, 22 Jun 2009 02:16:39 +0000

[...] part one, I introduced some of the things that I believe convolute the Flex third party framework space – [...]

By: James Polanco

James Polanco — Sat, 20 Jun 2009 07:19:59 +0000

Jon,
Thanks for taking the time to write this out. This has been a hot topic with my friends and fellow developers that I work with. Over the last year and a half we have been evolving a framework for our own internal and client use. The goal and focus for our framework is to create a toolkit that provides some pattern enforcement but more importantly provides a set of functional tools. I dislike using the word framework for our library since its more of a toolkit that can be combined together to form a complete system yet at the same time its compartmentalized in away that you can adopt and integrate only the functionality you need.

We have been using these tools for a while now on client and internal projects and continue to update and add functionality. For example, we have just added to the trunk build a history management extension for undo/redo support on the command system. What we are looking for is more insight from developers like yourself on both the approach we are taking and if the tools that are being developed are useful to more then just us. It would be amazing to have you and/or any of your readers take a look at the library and give us feedback, ask questions about how we are using it, etc. We love the library so far, but we also built it, so we are hardly objective.

If you are interested we have licensed it under MIT and host it over at Google code, check it out when you get a chance:

http://code.google.com/p/developmentarc-core/

Thanks again and I am looking forward to part two to see what you are looking for in a 3rd party solution.

By: ash

ash — Fri, 19 Jun 2009 05:21:27 +0000

I’ve never used it, but here’s another MVC framework that may be worth checking out: http://hydramvc.com/

By: Dave Cates

Dave Cates — Tue, 16 Jun 2009 17:54:08 +0000

Great article and I also am looking forward to part 2
We too have been debating frameworks for Flex as well and to be honest really struggle to justify adopting any of them.
We have a very strong background in code development with the MVC pattern (amongst others) and to be honest it’s sometimes very bemusing to see why anybody would want to use a 3rd party framework. If you’re an experienced MVC developer then why would you want to be constrained by a 3rd party framework? In our experience it would take longer to adopt, use and modify a 3rd party framework than code in an MVC pattern from scratch – Most of the frameworks are limited to some degree and would need hacking of some sort. Or, like has been said in this article, they’re just too bulky.
Therefore we can’t help but think all these 3rd party frameworks are more suited to in-experienced MVC coders? Not offense meant there, we’re just struggling to see ‘why’ we should adopt a framework like PureMVC, Mate etc when we’re just as quick, efficient etc without one.
I understand the argument of large teams working on code but that hasn’t stopped us either. Well documented code and code that is structured well using accepted ’standards’ eliminates most of these ‘large app’ arguments for us.
Any thoughts or comments would be most welcome as we genuinely are interested to hear from people as to why they adopt frameworks.
Great article – roll on part 2!