Comments on: Will framework survive RIA? I hope not.

By: Victor Rasputnis

Victor Rasputnis — Tue, 13 Mar 2007 11:37:08 +0000

Separation of concerns is a valid point, inherent in Flex architecture. When a DataGrid is populated from a POJO via the AMF protocol, we have MVC at least twice, depending how south of API the point of view is. The main issue to realize, I think, is that time-to-market expected from Flex should put further separation of concerns in a very pragmatic corner. I have observed concerning incidents when Flex has been labeled as not matching the expectations. The problem is two sided, of course. Flex has been, IMHO, intentionally and rightfully introduced NOT as RAD approach to penetrate the market faster and easier; highly automated solutions are hard to “swallow”. The question is whether Flex will become RAD eventually and how fast.

By: Yakov Fain

Yakov Fain — Tue, 13 Mar 2007 02:00:29 +0000

Unfortunately, these days many programmers turn into configurators. They prefer spending time learning how to configure XML of a particular framework instead of writing code. I raised a similar concern about overuse of frameworks in the Java world in the JavaLobby post "A new breed: Framework Java coder", which was about people who do not know how things work and assume that the framework will do the job. I was surprised that lots of people who left comments there said that it's OK to not know what's going on in your program. Flex is a domain-oriented programming language that covers the GUI part of Web applications, and we should not overcomplicate programming there. I'm for reusable components vs. frameworks here. Sure enough, we need quality self-contained components thar are losely coupled with each other.

By: Anatole Tartakovsky

Anatole Tartakovsky — Tue, 13 Mar 2007 01:15:12 +0000

John,
Glad you found us. Please ping me offline – I would like to see if our “5 minutes” approach is what you are looking for in terms of Flex DB development.

Thank you,
Anatole

By: Anatole Tartakovsky

Anatole Tartakovsky — Tue, 13 Mar 2007 01:11:30 +0000

Theo,
Flex controls are reusable – I use them. Frameworks for Flex I have seen have very limited applicability to the cases that used them. In most cases they provided “support” – registration, delegation, control, etc. – sometimes they help by orginazing your code, more often they turn it into large beurocratic mess.

The post was not about reinventing the wheels, just about the quantity and quality of them you need to make your vehicle. But I would encourage you to take a look @ one in your vehicle – you whould notice that a lot of things are packed into one – including breaks, safety and ride protection elements, etc.. Some things have to be in-place. They are also going to be different for your bike, scooter, rollerblades, board or computer chair. Mainstream applications define scope of reusable components.

But I am open to design of the computer chair with bike wheels – opening possibilities to people with special needs. Again, the scale of application drives the selection of components, and not the “pure” design.

Sincerely,
Anatole Tartakovsky

By: Anatole Tartakovsky

Anatole Tartakovsky — Tue, 13 Mar 2007 00:47:05 +0000

Steve,

DataGrid is MVC construct. Framework is already in. Building framework over framework does not always work as expected – the complexity rises very quickly.

If you looked through our presentations / code we advocate more developer’s control on each step of the way – including middle tier. As a matter of fact we are building communications squarely on native DTOs and FDS’s ChangeObject making sure you can bind any standard Flex adapter you can think of. In the same time we have our own one with better deployment model, transactional support and built-in flow for automatic updates in relational environment with referential integrity. In the end of the day you have 99% probability that your SOA has to serve those.

At this point of time more then 50% of the new Flex developers are former ColdFusion/PHP users and having streamlined, faster-then-ruby-on-the-rails PowerBuilder like approach would drive the adoption a la ‘92. As far as people as advanced in SOA as yourself – I do not think you are in day-to-day “application” development. Think what PFC did to developers in 96-97 – with overhead/ limitations / structured approach – do you want the same here now?

Let us be realistic here. Flex is client framework. There is FDS middleware/driver to connect to your Java / middletier framework, but most of the Flex development happens on the client. Middle tier is already distributed, configurable and switchable. 99% of the time (assuming retrieve and update do not take long) middle tier is irrelevant – assuming it is communicating properly and does not add complexity. PB was completely on it’s own – with ideas like dynamic create/modify/scripting inside datawindow, VM, classloaders, etc. At best, it will take another Flex 2 years to reach PB3 level of robustness and simplicity for application development.

You add it all up – and see it as a spiral, not as linear progression. Drivers have changed, you got transparent distributed architecture in non-homogenic environment – but the strength of the client portion is still to be uncovered.

Sincerely,
Anatole

By: Theo

Theo — Mon, 12 Mar 2007 19:49:30 +0000

Hear! Hear! Let’s stop this nonsene of reusable components! Let’s develop everything from scratch, it’s the only way to be completely in control. Let’s reinvent the wheel every time we need to go somewhere.

This is the worst load of bollocks I have read all day.

By: Steve Benfield

Steve Benfield — Mon, 12 Mar 2007 19:41:24 +0000

Anatole, you sound like you are advocating moving to a more, err, PB-like construct?

I agree that a lot of GUI MVC design is overkill–especially if your data is form/grid oriented and almost all your data manipulation/interaction is through those controls. Much easier to say grid.getMyData() and then grid.saveMyData() and be done with it.

However, in a world of SOA where the backend isn’t as malleable as it was in the PB days, MVC frameworks give a nice way to ensure separation of concerns. Of course for enterprise applications, developers tend to have a lot of control over the middle tier.

–Steve

By: John

John — Mon, 12 Mar 2007 16:45:03 +0000

Agree with you very much. I’ve gone through 2 books now on building database front ends using Flex 2, and the “proper way” of constructing these apps is horrific – to create a simple data form means duplicating every field name to 3 or 4 different places of code, and there is a huge amount of transfering objects from component to component – it becomes spaghetti-ish.

I come from the Delphi world of creating db front-ends, and Delphi was always fantastically fast and flexible. What would take me literally half an hour in Delphi would take 2 days if I used these Flex “best practices”. Ugh. I may just drop Flex and look at the new “Delphi for PHP”.

By: Chris Velevitch

Chris Velevitch — Mon, 12 Mar 2007 07:56:28 +0000

You say frameworks are bad because they enforce certain patterns, then what you’re really saying is the patterns being used are inappropriate for a specific case. Which may be true, but wouldn’t that mean there’s a lack of understanding of what patterns are out there. A knowledge of all patterns is beneficial in helping one decide on which patterns to use.

But are you saying that the existing frameworks prevent you from choosing the most appropriate pattern to help solve the problem because the framework is NOT general enough to accommodate any and all patterns?

Maybe its time step up a level and have patterns that separate out the platform-independent elements of the business logic from the platform-specific elements used to automate it. Then implementing software systems would come closer to the way building are designed and built. The design would be independent of the materials and construction techniques used to build it.