Farata Systems      

I feel like touching a sacred OOP cow, but let me do it anyway. Yesterday, I’ve been working on custom resizing of one Flex screen. I was able to use the property unscaledWidth of the mx.core.Application object in onResize method. Then I had to make a change and apply this resizing just to one of the VBox components. Unfortunately, VBox does not expose unscaledWidth property.

Looking up the class hierarchy reveals that UIComponent has the variable unscaledWidth defined, and its description reads

“A convenience method for determining the unscaled width of the component All of a component’s drawing and child layout should be done within a bounding rectangle of this width, which is also passed as an argument to updateDisplayList()”.

But using the word “convenience” here is a stretch, because the variable is defined as protected, which means I can’t just access it just as a property on my VBox.
Why? Because a creator of UIComponent class did not want me to.
Why? Because s/he did not think I’d need access it this way.

This also proves that the person who documented this class is not the one who created it, otherwise the word convenience would not be used.

And it is inconvenient, indeed. As a workaround, I’ve created a subclass of the VBox and made unscaledWidth and unscaledHeight publicly available:

package
{
import mx.containers.VBox;
public class VBoxScalable extends VBox
{
public function get unscWidth():Number{
return unscaledWidth;
}
public function get unscHeight():Number{
return unscaledHeight;
}
}
}

Here comes the question. Why creators of a framework even use protected variables?
I’ve been asking this question for a while on different forums, and blogged about it in the past, and so far no one was able to give me an answer other than “Because the creator of this class wanted you to use this variable only from a descendant of the class”.

In my opinion, this is wrong. If you want to give me an access to a class variable, make it public, otherwise make it private. It’s either a yes or a no. You can’t be a little pregnant, really.

Now it’s your turn: please explain me why do we need protected variables?

Yakov Fain

I assume that you are already sold on using Adobe Flex for developing the front end of your next rich Internet application. As of end of 2007, it’s the best choice you can make, really. But after spending almost two years working on real-world projects that involve Flex, I can see a number of roadblocks that prevent Adobe Flex from being the only solution for RIA.

1. Flex 2 is not a RAD tool – plan accordingly.

If you made a decision to go with Flex after attending one of the sales presentations, you may get an impression that Flex is a magic wand and anyone can quickly create an application that will get the data from a remote computer and display the data using one of the nice looking components. Yes, Flex makes lots of things easier, but there is big difference between creating a quick prototype and delivering a production-quality well performing application. Next year, Flex 3 will offer some RAD features such as code generators for various tasks, which will really help.

Learn from the Ruby on Rails, which can get you started with a CRUD Web application in no time, but then it requires experience and hard work for turning a prototype into a product.

You need to create a realistic project plan. Do not just accept the statement like “You can do things in Flex faster than in Java, so two months should be enough for this project. OK, let’s make it three to be on the safe side.” Sounds familiar? It’s a pretty dangerous approach. Identify each screen and its components, try to access the time and complexity of each of them, allocate resources, make the learning curve adjustments, and allocate ample time for testing (dynamically typed programming languages require more time for testing as compiler are as not as helpful as in Java or C++).

Add up the times required for each of these components/processes and then add a 30% extra time to account for unexpected.

2. The pool of Flex developers is still limited – re-train your own developers

Two years ago Adobe has announced that they expect to have one million of Flex developers by 2010. I have my reservations. I do not have any official statistics, but based on the number of Flex developers participating in various online forums, blog and book sales statistics, my guestimate is that there is under 100K Flex developers, and only a small number of them are IT professionals.

Adobe has achieved some good results in getting Flex into enterprises, but they are still facing resistance from Java developers. I know this first hand, because I work on the Flex/Java projects, mentor and train developers and a typical attitude of a senior Java developer is, “I can do all this in Java”.

The other statement I hear is this: “I do not want to move away from Java”. People are not convinced that adding Flex to their skill set can improve their marketability.

I hope that Adobe can bring the number of developers to a mil, but at this point in time, you’d be better off re-training your Java, C++, PowerBuilder or other developers.

Also, there are developers and developers. I mean that only a small number of developers in any programming language are professionals. Enterprises need well rounded Flex developers who understand Web application and are not afraid of SQL.

So far, Adobe did not invest in engaging colleges and universities with Flex. Students of computer science majors do not know about Flex. But according to my sources, the situation may change soon. Expect some major announcements regarding popularizing Flex in academia.

3. Check the credentials of the vendors you hire

This is a tough one. By checking credentials I do not mean comparing the quality of PowePoint decks and skills of sales people of the vendors offering Flex professional services. Ask them to do stuff before letting them working on your project. I’ve seen six months old Flex projects in a poor shape.
”Why did you select this vendor?”
”They gave us the best deal.”

There is a way to check if the perspective vendor can deliver. If several vendors bid on your project, allocate an extra budget and hire each of the bidders for two weeks. Ask them to create a working prototype of your system. In two weeks a good Flex developer can create an application that may resemble your future system. Hire the vendor who does the best job. This will require some extra money upfront, but in the long run the savings can be huge.

4. Be careful with frameworks – use components

Developers that come to Flex from Java start looking for an application framework. They are ready to be confined in a cage. Do not be. Even though Flex has several application frameworks, think twice before entering the cage. This may be an overkill for your project, and may slow down the development by introducing yet another tool to learn. Stick to small self-contained widgets. Use data-driven components. Apply code generators that minimize the amount of error prone code you need to write manually.

5. Architect your applications properly. Avoid monolithic solutions

Recently, one of the project managers told me, “We’ve chosen Flex to avoid page refreshes, but our pilot application requires 10 seconds to load and another 10 second on each screen change”. After a quick analysis it was clear that the application has been improperly architected. It was one large swf file, no libraries or modules have been used, session management was not properly done, and caching of the reusable data was not present.

Is this Flex’s fault? Of course not, but try to prove it to your architecture committee or, more importantly, to your business users.

So what’s my message to you, the Flex aficionado? Your relations with Flex will go through three main phases: falling in love, marriage and honeymoon, and daily hard work on making marriage work. The last phase is the most important one.
And…I really like working with Flex.
Thanks,
Yakov Fain

The second most interesting notion I got from the MAX was subtle feeling that Adobe is playing completely different game this year. MAX got bigger – that was expected. MAX brought a lot of different kinds of people, and  the previous events did not – also expected. What was less expected was the feeling that Adobe targets Flex to the mass market that was almost not present @ MAX.

I am talking about PHP, Rails and the likes developers, which are being treated as first class citizens in the new Adobe world. There were very few of them in the audience. Most of them work as independents – the cost of the show was prohibitive to many. Nevertheless the sessions were stacked in favor of “lighter” server and protocols integration. New announced Flex pricing also lowers the entrance cost for non-enterprise developers.

That is also evident in the way Flex tooling progresses. New wizards for server binding are “classical” for PHP/old ASP folks that recently moved to AJAX world. They are nowhere close to the enterprise-level DataServices introduced in Flex 2. The communication libraries have been separated recently, with a lot of work being done to make WebServices and other XML-based technologies viable for larger Flex applications and mash-ups.

So far, Flex adopted  was mainly driven by very few groups – Flash programmers and J2EE developers. Resources are scarce, and Adobe marketed Flex as a new generation of Flash – very high risk proposition in this situation. It is common believe that programmers can’t do good design. It is equally harsh on Flash designers to write the programs. There is a limit beyond which art-oriented people find themselves  in a completely foreign territory. Companies that hire Flash developers to lead Flex projects will learn it hard way.

How will it affect Flex adoption and positioning in enterprises and mid-sized businesses? The next year will be interesting one. Finally there is a competition from Microsoft. Keep your flame mails to yourself – it does not matter how much better or worse their product is – it is up to people to choose the tool and build something with it. People go either for easy or familiar first. I do believe that tools will be just as important as the player ubiquity or appeal.

As far as tooling goes, Flex usability is definitely improving. Aside from the performance, Java developers can use Flex 3 almost “naturally”. Great job, Flex Team. Making working environment easier is what Flex really needs in the coming year. The only “deciding” complaint I have heard from Eclipse and MS Visual Studio users was not about framework or integration, but about the environment.

That brings in the third “main” Flex theme of the MAX – going Open Source(OS). Open Source appeals to a lot of people, and Adobe certainly hopes to increase community involvement in their products. With the end of J2EE era, it is expected that companies and individuals who championed OS 5-10 years ago will come aboard. Again, MAX might have been running ahead of their attendants here – not too many showed up at OS gatherings.

There were very few sessions on the open source (the most complete was done by Matt Chotin, need to publish my notes or find link online), and they did not bring large crowds. Interesting news were circulated in form of rumors, which means that we can expect big announcements in this area in 3-4 months.

There are high hopes of the OS movement for Flex. But this time around it might be a different game. Reliance on OS to win enterprise and businesses adoption seems to me the most difficult and risky part of Adobe strategy.

Do not get me wrong. I love open source – it is definitely a relief after 20 years of breaking and fighting “black boxes”. I gladly read and “adopt” open source libraries and contribute the results back. As a company we release significant part of our research and development as open source as a way to insure we can reuse our code for different clients as well as share it with the community. Releasing something as an open source product and driving adoption is the simplest way to protect IP for small companies and insure they keep control of the process.

Businesses grew a bit tired of OS over the time, and going in with OS solution sometimes means more trouble than it is worth.

First thing is the licensing. Relationships between enterprises, developers, distributors, etc are often “interesting”. Quite often the companies require you to not have or use OS software in your product.

Second is the effect of old switch-and-bait game. Open source was at its peak when software industry was in recession; selling support for OS products was the only source of money. Industry moved from software as a product (cheap and working) to software as a service (needs a little push from knowledgeable person, info is scarce) – and the real cost of software for enterprises skyrocketed. Even if the intentions are good this time and we get commercial grade software as OS the perceptions are there.

I am looking forward to get my hands dirty with Flex compiler as soon as it goes OS – we have loads of things we need to expand there or have to keep “external” for now. The goal is to make it usable for our enterprise and business clients. Large applications need better tools for modularity and build process, performance, diagnostics, language extensions, etc. It will be very interesting to see how this last big “problematic” piece is going to sail through the community process.

Sincerely,

Anatole Tartakovsky

We are looking for Flex developers working on various consulting assignments. Currently we need people working for our
clients in New York, New Jersey and Connecticut. Ideal candidate is a senior Java developer with Flex experience (the more the better). Good communication skills and willingness to travel is a must.
We can work with you either on the corp-to-corp basis, or offer full time employment.

Please send your resume and salary/rate requirements to me personally at yfain at faratasystems dot com.
If you are a senior Java or PowerBuilder developer and are seriously considering making a career change toward developing rich Internet applications with Adobe Flex, get in touch with us. We’ll be offering a mentoring program for selected candidates.
Let’s work together.
Yakov Fain

Time flies. This is already the third time that I’m going to teach a hands-on course Building Rich Internet Applications with Adobe Flex at New York University starting on October 25. I really like this class. It runs over five weeks on Thursday nights. As opposed to typical five-day-in-a-row enterprise training, this gives the students a chance to spend some time between the sessions, do some studying on their own and bring the right questions to the next session. By the end of this course the students build a FLex application that communicates with Java part deployed under Tomcat and with Yahoo! to grab some RSS data from there.

If this sounds interesting, let’s spend these five evenings together in an NYU lab. Enrollment is opened to the public. Pre-requisites: understanding of Object Oriented Programming and basics of XML.

Disclaimer. I’m not getting paid based on the number of enrolled students, so this blog is not an infomercial but rather a friendly suggestion on how killing five evenings may possibly change your career and add some fun to your day-to-day coding routine. This course really worth the money, especially if you take into consideration that having a student card entitles you for purchasing Flex Builder license dirt cheap.

Check out this article to see how two swf components (both written in Flex) can help AJAX folks with processing SOAP Web Services and incorporating professional looking reports into HTML/JavaScript pages. Now our Web reporter can get the data from any JavaScript array, from Web Services, from POJO using open sourced openAMF, and, of course from LiveCycle Data Services ES.
Regards,

Yakov Fain

One of the most interesting sessions during Max 2007 was Ely Greenfield’s “Flex RoadMap” . It actually had a flair of developer-to-developer conversation rather than a demo or promotion – more on “why” Flex Team is moving in this direction. Unfortunately, the feedback from the audience was rather weak as most of the people were stunned by the approach taken. I felt compelled to compose my thoughts and re-evaluate my experience before I will come with any feedback on the subject.

The reason being that we walked that road in the past; we still are using that methodology in our Flex work. Having support for it from the tool vendor will change both adoption rate and the way people approach it.The idea behind new set of tools in development is pretty powerful and simple:

Take large controls that we have in frameworks and libraries and layer them in relatively small and specialized layers of loosely bound reference implementations.

The layers can be UI elements, skinning, layout, data binding, view controllers, etc that compose a typical framework control. Each layer is completely replaceable or better yet each control is being assembled for an application from “parts” by a team of designers, programmers, model designers, etc. As long as it can be expressed as an XML markup, design tools can produce these layers thus providing interchangeable implementation of design or other aspects.

We used this approach as core methodology in the past and were very happy with the results. In the beginning of RIA era (1999) IE version of DHTML had so-called “behaviors”. You could have attached these XML/script combo components to any tag or create your own tags. They could be small – just to add a presentation/effect like rollover or provide intelligent links or tooltips. We also had the “monster” ones representing DataGrid, Report, Tree, and TabFolder to name a few. You could have attached multiple behaviors to a single tag providing control with a superset of functions – the same rollover/selection effect would work on DataGrid and Tree in the same way.

Data binding was just another behavior shared across multiple controls. Within a year after adoption our home-grown framework had over a hundred of such components that we customized and delivered to clients in a way that was the most beneficial to them. We’ve also built an IDE to support these components, but for me it was simpler to “notepad” it with a smart XML editor.

It was a very simple model as it was built on top of C++/OLE world supporting multiple inheritance/vtables. Each behavior would automatically expose its public methods, event model and properties. The order of attachments would define the priority. If you wanted to specify particular behavior, you just use behavior name as intermediate selector before property/method name. You can even layer different languages as behaviors – we would use XSLT styling as one of the behaviors. That was the simplest aggregation model I ever seen in world of C++/OLE or anywhere – even in the modern dynamic languages.

Flash 9 VM does neither supports multiple inheritance nor dynamic resolvers (to the best of my knowledge), and Proxy approach might not be good for regular application developers. Now it might be a good time to start adding that functionality back in Flash 9 sub releases and definitely in the Flash 10 to go head-to-head with rails and other modern languages. You really need to apply aspect based programming methodology on system level to afford this approach – or have tools to do it under the cover. However, I feel that the tools approach will take longer and will cause slower adoption.

The power of externalizing the functionality is just awesome. You clean up a lot of code, and get more choices in the process. Reusability of the code becomes obvious. It takes some time to learn, but it makes you a better thinker. All cumbersome patterns go away as you concentrate on one thing at a time.

We never gave up on this architecture, and it proves to be the most powerful feature of our current framework of Flex components. I will publish some samples this week to show how trivial the code looks like in comparison to typical Flex programs yet delivering more functionality.

Ely presented architectural diagrams illustrating how things are interconnected now and how they can change in the new architecture, and I could not help seeing it as a live biological system going through a major transformation. Application components are the cells of the living and breathing application. In the current development we are integrating more and more specialized creatures without their own DNA (hence viruses) directly in the cells using ever extending set of backdoors. Managing viruses is a nasty business, taking all kinds of the resources. Proposed architecture is more of bacterial helpers, attaching to the cells, but not breaking in, exchanging energy and processing waste. It holds better promise over brutal methodology of “gene engineering” and provides open space of growing specialized “cultures”. Count me in.

Sincerely,

Anatole Tartakovsky

That came about during the best practices show. One of the panel speakers, while making a disclaimer that he is not hands-on, said that he does not believe in code generators. At that point I just thought it was funny as it goes along the line “Why people who do not wash dishes think that dish washing machines are not needed?”. But after the show I met a few people and some thought that application generators should be avoided. I was not able to find out “why” though – it was more of the way they felt rather than a argument. So why do they feel that way?

I do not know. Let us do a mall exercise first. Open a new Flex project and create a new FDS application project. Before you even write a single line of code Flex creates 30 files and 120+KB of code in background. You can see them by adding –keep switch to the compilers command line. Before you are finished with login screen you have 100 files in the generated folder. Is it good or bad?

It is expected. It is good in a sense that you do not have to write this code yourself. It is good that it will be compiled rather the interpreted giving you the best performance possible.

Code generators are essential part of every IDE product and there is not need to debate this. Every productivity language/compiler (starting from Assemblers to C to C++ and the modern ones) has some code generators built into it. Most of software development tools I know are using code generators of some kind. Another example – if you are the programmer who are just filling the blanks in someone’s framework as oppesoed to being a creative writer – you are also a code generator to some degree.

There are good and bad code generators, but they are not solving their problems, but rather helping you in solving your application’s problems. They are just the power tools that implement best practices for solving domain problems.

People take domain-specific problems (either in the form of code annotations or just a as a standalone resource like UML in which you embed a host language) and generate the code that you can see and modify. You are doing it every day. For example, Flex processes annotations embedded in the ActionScript and MXML. So when you use [Bindable], [Managed] , [Event] or just include CSS references you are telling Flex code generators that you want certain patterns applied to this code fragment, and Flex generates a bunch of files in the background. You really have to be hands-off to use and denounce code generators in the same time.

Code generators are getting better and better. Bugs are eliminated, the language flexibility increases, new domain problems are added and automated. The best optimizing compiler produce better code (efficient, compact or anything in between) then any human. With alphas and betas of Flex, I’ve been studying the code in the folder generated . After a wile, the entire process became completely transparent to me.

Our code generators belong to the 3^rd generation. They work in background, generate and insert the into “invisible” locations. You do not need to see this code or build the resulting code separately. They perform hot deployment and provide automated and visual test code. You apply your code changes directly in the mix of the application code and domain annotations. You never have to see generated files – or at least not more often then you have to see files generated by Flex. For certain types of applications one person can be as productive as 3-4 developers. He does it faster and with less effort. The concepts of code visibility and rules of generated code invocation are identical with Flex even though the products are coming from different environments, but after all these are common best practices of the modern software development.

I think the problem is that most of the people think of generated code as source. Let me give you another example. We take a Java file with some SQL or other annotations and run it through our code generator. It produces the DAO and Assembler classes, multiple DTOs, deployment descriptors, deploys the jars and places all low level artifacts that you do not need to touch (ever) in your Flex project. That is where most code generators stop. We made sure that our generators are fully open; you can add templates for generating other type of code and modify the existing ones.

Over time, your reference implementations will have templates for databound datagrids, forms, master/details forms, reports, TreeGrids and other TEST samples for people to try the power of really fast development. The main target with the products are metalanguage files disguised as MXML extensions. However, people can take test the code and happily embed it in application. The changes come and they have to propagate these changes manually – and they say the process does not work.

That process indeed does not work – but it’s not the code generator’s fault. It just means that while the tool was working with annotations in Java and users somehow expected it work transparently on Flex side (and we did not have any annotations there yet). In order to achieve the  synchronization between Flex and Java,  you need another code generator that would allow you to process Flex annotations in the Flex compiler. We requested that feature in compiler over a year ago, and I was told it is in the plans for Flex 4 . However, as soon as Flex compiler goes open source, it should be fairly simple to embed your own code generators that would enable synchronization. For now, when we need to augment Flex with business domain functionality like business expressions a la Excel or Powerbuilder, we run source-to-source generators that are transparent to the developer.

Sincerely,

Anatole Tartakovsky

PS. I wrote these notes on the flight home. These morning I thought about other things, and I believe I got an idea why some people  do not believe in code generators:

1. They were much younger than me. Coming from the times when bytecode referred to bytecode of CPU, quest for Productivity Holy Grail is automatic for me. And experience with preprocessors, RADs, 4GLs and metalanguages allows me to see different implementations of generators as probably the most powerful way to incorporate best practices . Here is how I see it: It is ok to teach people how to recognize patterns and communicate among themselves using these patterns. A code generator is a way to communicate these patterns to the computer in the best possible implementation using the input provided by people using the patterns.

2. Somebody needs to explain people the difference between code generators and source code generators. A lot of people went to preceding Flex 3 sessions where they saw dialogs based code generation for PHP. They automatically associate (that’s what people do best after all) the CRUDe source generator with the similar functionality provided by domain extensions of our code generators. Well, if I’ll ever be invited to participate in a keynote, I’ll try to explain it to more people so there won’t be any confusion

When a bus pulls out the bus stop, a person who’s running to catch this bus and the person who is already in the bus see things differently. On the same note, people who use the free software and people who develop it look at giving away the software for free differently. I had a chance to be in both camps…
Besides offering professional services, our company, Farata Systems, creates software components and plugins . When we’ve released our first component DAOFlex and saw a couple of thousand downloads, we’ve decided to invest our own money and created a number of productivity plugins that would save time of professional software developers. Unless you work for a large firm, there is a huge difference between creating an open source and commercial software. With open source components, availability of any product documentation is perceived as an extra bonus. With the for-profit software, a well written documentation is expected, or else…

In the open source software, having bugs is a norm of life, but if you charge for it, any Joe-Shmo who paid $19.95 for this software, expects to have quick bug fixes and an expert-level production support provided by an engineer who’s paid at least $30 per hour.
OK, you want to sell your software – how much? The answer depends on who are your customers. If you sell to lots of individual consumers, preferred price is $19.95 or less and it does not really matter how much money did you invest into producing this software. For many people, twenty dollars is some kind of a magic number, and if an item costs more, people just do not buy it. If you are selling software for enterprises, THE SAME software has to cost at least a couple of thousand bucks, come with a salesman in a blue suit and 24×7 production support, otherwise big guys won’t take you seriously and won’t purchase it.

There is this joke about filthy rich “new Russians”, when one guy meets another who wears a nice yellow silk tie by Armani.
The first one asks, “How much did you pay for it?”
“$100!”
“You are plain stupid. Two blocks from here there is a place that sells the same exact ties for $200 a piece! ”
The same principle works with enterprises – the higher the price, the easier to sell.
Getting back to our products… We’ve invested our own time and money and developed a number of productivity plugins that save tremendous amount of time to any professionals like ourselves who work on Adobe Flex and Java projects for a living. Most of our components are priced from $99 to $399 dollars a license. After selling a number of copies we broke even, our R&D expenses were covered, and since we mainly sell Flex consulting, we started to talk about either giving these components away for free or cutting the prices since these components are not our main source of income anyway. But after a quick discussion, we’ve decided not to do give them away for free for several reasons:

1. If we make them free, a lot more people may start asking for support, and we do not have a dedicated person to answer such requests. Rejecting these requests is not an option either because people will start badmouthing us in the Web.

2. Our target customers are professional developers who value their time. They could easily do the math and appreciate the savings that these couple of hundred dollars would bring them.

3. As of today, these components give our consultants an edge while working on the projects for our clients. Btw, our clients get these components (except ClearBI) for free. If we’d give them away for free, we’d lose this competitive edge. Want to have an edge too? Spend a couple of hundred bucks while other people enjoy free software.

4. Giving components away for free while selling support is not an option for us, because these components just work and do not need much support especially for those who found the time to read the fine manuals (a.k.a. RTFM) that come with the products.
Free software plus premium for services works for creators of JBoss, Hibernate, Spring, Ruby on Rails, and AJAX frameworks because all of the developers that use these packages benefit from having an expert in the respective product handy. Our components are automated and can be used as is.

In the USA, a minimal price is being enforced on some grocery products, and stores are not allowed to set the price lower. Why? To keep the small convenience stores running. Without this regulation large supermarkets would start selling milk at 20 cents a gallon. They’d lose money on milk, but it would not really matter because after entering the store, the customer would purchase lots of other products at a substantial markup. But such a low price on milk would have killed all small stores in the area.

On the same note, the big guys give away software for free. Sun Microsystems made Java and NetBeans free. Tibco has open-sourced GI, their AJAX tool. Eclipse IDE is an open source project (let’s pretend that we do not know that it has started with a $40M worth of code donated by IBM). The big guys are killing small independent software vendors, who understand that they won’t be able to compete with a price tag of 20 cents even if their “milk” will taste a little better.

So why do we even develop these components? Because we can, and it’s fun. Do these components help us in finding consulting jobs? Absolutely! Seasoned hiring managers understand that if we were capable of creating this software the chances are high that we’ll succeed in working on their projects as well. And to be completely honest, somewhere in the back of our minds there is this little thought that may be one day one of the big firms will decide to acquire our small company because of our products.

Sincerely as usual,
Yakov Fain

I really enjoyed being on the panel of “Flex Best Practices”. The room was packed, so I have to guess some people did not have chance to get in. This is my recollection ( if memory serves me right – it is 11PM here in Chicago, after Adobe party and quite a few beers. I am planning to keep it short, so I will stick just to Joe Berkovitz questions and my answers. I will add small points here and there that I might skipped during the panel due to the time constrain. I will post links here when other panel participants will blog their takes on the subject.
Joe Berkovitz: …I have Steven Webster, from Adobe Consulting, known for his advocating and work on Cairngorm framework, Dave Wolf, VP of Consulting at Cynergy Systems, he heads Flex Consulting Practice, David Colleta is Principal Software Engineer at Virtual Ubiquity which created Buzzword software as you have seen in the presentations today and Anatole Tartakovsky, he is a Managing Principal at FarataSystems, they are doing a lot of great work on frameworks, Flex tools and products, very ambitious and interesting things. I am working as VP of engineering at Allurent, you might have seen RIA demo of our work at keynote presentation today and it is a work of the company I am working for. … So the first question is when to use MXML vs ActionScript, more traditional object oriented language?

Anatole Tartakovsky: We are trying to balance it by type of the functionality and type of the people writing the code. As David said, with pure UI markup you are better off with MXML as it generates tons of ActionScript behind the scene you would have to write by hand otherwise. MXML is painless and easy. For framework and reusable layer you are usually better served with ActionScipt as it gives you better control of object oriented features and forces you to think in more traditional environment. Also, based on the people involved in the project, I want to throw few more things in the mix. First, you might want to add CSS to your MXML files so designers can start playing too. Then you might want to extend MXML with data driven UI or business functionality so business analysts or end-user directly affect UI and behavior of the application. Data-driven is extremely important as it really enables personalization and gives a lot of control either to the systems administrators or end-users. Finally, Java back-end developers really prefer ActionScript classes before they become comfortable with the MXML, especially with automatic code generation of these proxy objects directly from Java code. These criteria’s allow having more people working together without stepping on each other’s toes. In the end, it will all be either compiled or interpreted by ActionScript, but it maximizes the reuse and makes process more manageable.
…
JB: On the subject of bindings – it is such an interesting feature and it adds so much to language – one person in the company said that binding is feature that violates encapsulation in very special way. You think you are making just an assignment and all sequence of changes start to happen throughout the application. And I want to hear from the panel what kind of the problems they encountered by using the binding?
AT: There are cases when binding is not very useful – cases with XML data structures or data that is not strongly typed. Binding of dynamic data classes require you to use descendents of ObjectProxy and that is often more challenging then what it is worth. Another case when it is difficult is when you use controller on the data object and it is not coded properly – you usually want to have either binding or controller – and I personally usually go with binding.
On the other hand, for majority of the applications binding is true blessing as it allows you to write very generic helpers that will do state management, synchronize data with the server, and generally write less code. Flex compiler/framework will generate quite a lot in background, and I encourage you to look in generated code to understand how it will impact your application.
But having automatic end-to-end data binding is a very important feature. Having the ability to load data, modify it and apply on the server represents significant portion of the code you write daily. We are using code generators to produce most of the code on both server and client side: deployment descriptors, DTOs, actual DAO and View MXML, etc..
Code generators support both [Bindable] and [Managed] versions of code binding. We also roll out few our own versions of the implementation, adding events that are part of the client’s requirements or changing timing of the standard events as an example – sometimes it is more appropriate to use them in asynchronous models.
The key is to keep binding “contained” and Flex uses [Array]Collection and their descendents to encapsulate data and act as thin controller that will consume most of the events, and will propagate “aggregated” events to the listening object. It is perfect place to put both generic (like state management) and business (like calculating totals) functionality. Small framework allows you to isolate your application from data binding implementation – including data retrieval and synchronization. We actually provided “open source” implementation of flex data services client in the book and articles.

JB: Moving on other topic, I would like to talk on frameworks. Cairngorm and some other frameworks that I call “shallow” frameworks. They are not necessarily provide a lot of functionality in a sense that Flex frameworks does. It provides what you might call Superpad – a set of interlocking patterns. I wonder if a shallow framework provides cure or actually causes disease by blocking developers from providing solutions and analyzing the problems.
AT: That is exactly the problem we are seeing. People come to us to rewrite Cairngorm projects. Cairngorm is answering to “how” question, but “why” or “what” just is not in the picture at that point. We believe that you should take some patterns – and enhance them on individual basis for a particular application, but the “meat” of the solution is in the developer’s framework. People need to have big pieces of an application available as components, customizable products that can perform common functions and transparently be used in the application. They are tested and give you the functionality that you want right away. You can start with small, single function components like logger or “caching logging” screen David mentioned, or you can try deep waters with complete set of components that very much fill the gaps in the current Flex frameworks. Over the years, we added objects like Report, DataForm, TreeGrid, OlapTreeGrid, etc. We added the functionality that is important for reliability of your applications like robustness layers for communications. Architectural frameworks are very much like skeleton of the application, and Application Framework is actually adds muscle – you can’t have one and not the other.
JB: The next question is if you use default HTML template in Flex builder or you feel it is necessary to customize?
AT: We usually customize the template – primarily for interoperability with external applications or system functions. Typical example is when you need to transfer data to Excel, mashup/history/Search Engine Integration and other system functions. The other sample would be to pass extra flash version specific parameter – for example, the code that would allow application to go full screen.
JB: What do you think of Designer/Developer workflow?
AT: I believe that while there are cases when you have designer and developer working “sequentially”, it can greatly extend the development time, which should not be a problem for consulting companies .. If you take this process to extreme, a developer will also wait for the back-end developer to complete code. In turn, a designer would have to wait on business analyst and back-end developer waits on architects/model designer. Given the way things usually are Flex developer will have a tiny fraction of the time to actually implement the application.
The other option is to start working from the functional spec in parallel. It is very much like digging a tunnel from both ends. While there is a chance of meeting somewhere in the middle, it is not easy.
I actually think that you should start from something that is agreed by everyone – start in the middle and dig out. We use Flex in a way that every person on the project can work in parallel. You start with a rather crude version of the generated screen and model, and you do refinements as you go. It is more manageable then it sounds and it is the direction taken by Flex Team for the next versions of the product.
Question from the floor: How do you deal with the problems with tag like event handling, debugging, etc.
AT: Modules are designed to be separate applications and while you can establish some patterns via use of interfaces any attempt to make them “friendlier” will require more custom code on both sides. We do not to use mx:Module but rather create library projects and turn them into “self-initialized” libraries/swfs with automated build process. Every library becomes “swc library” for references from outside code so you can reference classes, get strong data types resolved, etc., It is also compiled and deployed by mxmlc compiler you use to compile Modules as application. The auto generated main object is inherited from SimpleApplication object to save space ( but can be inherited from Module) to be loaded instead of module. In that case you have advantages of referencing the code the same way you would reference object in any other SWC library (you just need to mark it “external), have strong type support, and load it on demand.
This technique is described in our book and in Flex Developer’s Journal – it’s available online – just google it.

I will be posting on some random thoughts I had during that sessions – hopefully tonight on the way back

Anatole Tartakovsky

One cool thing I wished I knew a year and a half ago was a question on how to keep / get additional metatags from the class definition. I actually asked Flex Team members last summer about that feature, but did not get the answer then.

This is embarrassing as you can kind of derive it from documentation if you know it is there, but I asked few Flex experts if they knew about this compiler feature – feel much better now as nobody knew as well.

OK, we are talking about <strong>keep-as3-metadata</strong>=<em>class_name</em> [...] option -  here is excerpt from help:

Specifies metadata that you want to keep.

By default, the compiler keeps the following metadata:

· Bindable

· Managed

· ChangeEvent

· NonCommittingChangeEvent

· Transient

If you want to preserve the default metadata, you should use the += operator to append your new metadata, rather than the = operator which replaces the default metadata.

This is an advanced option.

That means that you can ask compiler to keep information about events your objects declare. You can define your own metatags, and they can be persisted in the class definition as part of objects XML definition.

You still cannot use metatags at the compile time as compiler stays closed till (and then some time after they open sources it due to standard “acceptance” process), but you can use these annotations in runtime. That opens a whole new world of embedding and using metadata information – that is really a major feature for any framework/component developer.

I need to do some performance and usability tests, but the way it looks like now it is the most straightforward and efficient way to embed/carry the metadata.

Sincerely,
Anatole Tartakovsky

The MAX 2007 conference features more than 200 sessions, and only a small number of them made it to the Sessions Highlights Web page. Flex Best Practices panel is one of them, and our own Anatole Tartakovsky has been invited to be a panelist there. Beside being my friend and colleague at Farata Systems, Anatole belongs to a really tiny group of programmers who understand all nitty-gritty details of developing rich Internet applications in general and with Flex in particular. As Anatole put it, he is one of those people who code faster than speak.

The Flex Best Practices is a short session, but if you have really tough questions or are facing problems in your Flex-related project, stop by and talk to him before or after this panel. Trust me, you won’t be disappointed.

Regards,

Yakov Fain

I am making small (5 minutes) presentation at Ignite / Welcome Reception at Adobe MAX 2007 later today – talking about making enterprise workspace fun again. I will talk about what works and what does not. 5 minutes is really short time, especially for people who code faster then speak.

Come say hello if you are at MAX, I will also be in the “ring” for “Best Practices” session on Tuesday.

Anatole Tartakovsky