Apache Flex :: Flex-Dev summaries 20
Monday always has a bit of a bite. Sentiments of Monday followed this with various subjects revolving around inpatients. I guess it’s only natural when your future hangs in the balance of belief.
Logo final round
Well, Doug posted a thread yesterday for the final round of the logo contest. This will decide the winner and communities favorite.
For information on voting see;
http://incubator.apache.org/flex/logo-contest.html
Component cloning
This was an out of the blue request, DisplayObject cloning. I have to admit I have never really needed this in the apps I have made. Alex mentioned and API could be added to create such a feature but the, what are the use cases?
From my perspective, if you can’t create a utility from the outside that calls public API on a component to clone it OR holds state that initializes the component from say an application model, you are trying to do to much.
I don’t think this will ever be an option in the framework. There really are already ways to accomplish this as stated.
Component Behavior Pattern
This topic has been flying around not just in the mailing list but on a couple blogs as well. I am no stranger to behaviors, fact is back in 2008 I wrote a complete framework from Flex 3 using them as a prototype experiment. Didn’t really get any exposure, I did get four favorite stars in google code for it!
So anyway, this subject really relates to the original thread I started on the list about Modularity and Interfaces. As Alex keeps pointing out, we live in a constrained environment(Flash Player), rules have to be bent and broken all the time to provide optimum performance.
There are draw backs to composition as Alex points out. A major consideration is the line between granularity and performance. It’s noted that although breaking a class up into parts allows flexibility, we then incur the cost of calling the proxied methods of the composed object. So here is the problem, there is not a way with the current constraints of the system to actually create a “purist” behavior pattern. Oh the engineers in us wish we could because it would make life 10 times easier, but we have to realize that any design pattern we can come up with is going to have the flaw of overhead in the Flash Player.
State of the project
The state of the project was discussed, what is that you say? State, you know where is it at. What are the future goals, what promises have been made, why are we here. I feel these answer will come in the next couple weeks. The wiki has been created and I think there is an effort to have a page that allows for the community to see the progress of all these questions.
Coding conventions
Coding conventions and best practices was brought again by a new community member, it seems as though that subject has quote “been beat to a pulp”. So a community member was kind enough to use markmail links to guide the new member to the 100′s of threads written on the subject.
Ah, how sweet is that.
Tagging on the list
Tagging for list threads was also mentioned for adding more clarity to a subject line of a post. IE [SomeCategory], explains where the subject belongs in a namespace fashion.
Folks, I have had enough experience with forums and mailing lists to say, whatever order you try and achieve will never work. Mainly due to the influx of new members and the fact it’s community driven from all over the world.
Moral of the story is, create email folders like flex-dev, flex-user, flex-commit, setup email filters to push anything from the said emails into the folders. As an added bonus, use an email client that can sort mailing lists by thread when you are looking at them. You good to go using this pattern.
Note; The only flaw with this is when members start new subjects in a reply to another subject. Then threading goes to well you know.
Conclusion
Monday, its definitely not Friday.
Thanks for reading,
Mike
I’ve implemented the behavior patterns of microsoft in a major enterprise Flex project recently.
I can tell you it works really nicely. Therefor may I suggest that you take a look at this.
Particularly the onAttach and onDetach methods.
http://geekswithblogs.net/SilverBlog/archive/2009/09/22/behaviors-how-to-attach-behavior-in-code-behind-silverlight-3.aspx
We assign the behaviors either in the declaration tag (DeclarativeBehavior) or next to the tag (VisualBehavior).
Ideally you’d want to do it like in XAML. Where you’d have a tag for ui components. But using the declarations tag has been very good too. Just less inline.
I am a strong believer that composition wins over inheritance. Particularly for large scale enterprise development, where many UI components are augmented and used in various ways.
This has been very successful for us – I’m no MSFT fan boy, but thanks Microsoft for showing us the way.
Cheers
Nic
Here is a simpler, clearer example
http://wildermuth.com/2009/5/16/Writing_Behaviors_for_Silverlight_3_-_Part_1
Cheers
Nic