Nice flow chart for Component's life cycle

An English translation is available for this post...

מה זה ככה, יום אחרי יום? משהו לא תקין...
פשוט נתקלתי במשהו שאתם וודאי תעריכו כמו שאני הערכתי. איזה flow chart פשוט המתאר את ה-life cycle של ה- UIComponent. תכלס, כמה פעמים נתקלנו בדוקומנטציה הביצתית המתארת את התהליך, הא? אז הא לכם chart מבית היוצר של Dan Orlando.
תבלו.

So... what's going on? a "day-after-day" post? something is wrong...
It's just that I bumped into something that you might appreciate as I did. It's a flow chart that simply describes the life cycle of the UIComponent. To be honest, how many times did we encounter that swampy documentation that describes that process, right? so there you go, the chart out of the hand of Dan Orlando.
Enjoy.

Catalyst Motivation as I see it

An English translation is available for this post...

אהלן אהלן,
לפני יומיים, למי שלא ממש מעורה, התנהל כנס פלאשו שהציג את המוצרים החדשים של אדובה עם שימת דגש על Catalyst ו- Flash Builder 4. לפני שאפרוש פה את דעתי המתגבשת, חשוב לציין שלא יצא לי להתעסק עם Catalyst, ובכנס הייתה זו למעשה הפעם הראשונה שראיתי את תהליך העבודה המצופה מתבצע בה.
כמו שכתבתי בעבר מחולליי קוד כדוגמת קטאליסט וחברים מאז ומעולם העבירו צמרמורת קרה בגבי. הכלים הללו בד"כ יוצרים כל כך הרבה ג'אנק של קוד מאחור שלעיתים מזיקים יותר ממועילים. אחרי שאמרתי זאת, אני לא מאמין שהכוח או המוטיבציה מאחורי קטאליסט הוא ביצירת קוד מעיצוב. תסתכלו על Flex Builder עד כה, גם בו היינו יכולים להכנס אל ה- design mode להניח קומפוננטות על הבמה והקוד היה נכתב מאליו מאחור (גם אז, לא תמיד לשביעות רצוננו). זו אינה הנקודה. מה שקאטליסט נותן לנו בעצם הוא את היכולת לפצל את ה- layout וה- skinning מהלוגיקה של הקומפוננטות בצורה קלה. כל הרעיון של Spark די עונה על השאלה שהצגתי בפוסט הזה. הקומפוננטות כבר לא בנויות כמקשה אחת, ויש לנו את ההזדמנות ליצור layouts ו-skins שונים לאותה לוגיקה בדיוק. אם אני טיפה אתיימר, אוכל לומר ש-Spark היא בעצם תולדה של הצורך לתת למעצבים אפשרות קלה לשנות ייצוג קומפוננטות של ה-framework. אני מניח, שכמו כל מי שרצה להרחיב את הקומפוונטת של פלקס, גם הצוות באדובה נתקל בקירות בטון מזויינים ברגע שניסה לשנות את ה- layout של הקומפוננטות וזה הביא אותו למסקנה שהתשתית בנויה לא נכון. מסקנה שכל מי שמפתח בפלקס אפליקציות מעט יותר מתוחכמות מאתרי אינטרנט יכל להצביע עליה לפני שנים, אבל מוטב מאוחר מאף פעם לא. אם כך, מה ש-Catalyst מאפשר לנו הוא ליצור את קבצי ה layout וה-skinning בקלות, ולדעתי לשם כיוונו אדובה.
ה- designer developer workflow שאדובה כל כך מדברים עליו הוא הקונספט העיקרי שקאטליסט משחק בו תפקיד של מתווך. הרעיון, לפי הבנתי, הוא לא לצפות מה- designer לקוד, אלא יותר ל- assets ולקבצי ה-layout/skinning הנדרשים. לבנות פתרון end to end מפוטושופ (למשל) עד ל-swf של האפליקציה. ועל פניו... זה נראה לא רע בכלל :).

Hi there,
Couple of days ago, for those who don’t have their finger on the Flex pulse, Flashoo conducted a meeting to display the new Adobe product, giving the main stage to Flash Catalyst and Flash Builder. Before I will reveal my “still incarnating” opinion, It’s important I’ll mention that I hadn’t got the chance to mess around with Catalyst, and the meeting was the first time I saw the work process in action.
As I wrote before, code generators, the likes of Catalyst and friends have never been my bag (baby).These tools usually create do much junk in the code they generate that sometime they are doing more harm the good. Having said that, I don’t believe that the power or motivation behind Catalyst lies in code generation by design. Look at Flex Builder so far; it too has the ability to enter the design mode, drug some component on to the stage and see the code getting written at the back (and then too, the code wouldn’t always be what we intended it to be). That’s not the point. What Catalyst brings us is the ability to separate the layout and skinning from the logic of the components in an easy manner. The whole idea behind Spark pretty much answers the post I published a while ago. The components are no longer built as one class containing both layout and logic and we have the opportunity to create layouts and skins that are different, that will come on top of the same logic. Some might call it MVC…
If I may be a little pretentious, I can say that Spark came from a desperate need to give the designers the ability to alter components layouts. I assume, that like anyone who tried to extend the framework components, the Flex team also encountered some serious bumpers on the way and that made them come to the conclusion that the framework is not flexible enough – a conclusion that anyone who builds Flex application a bit more complicated than the average web site had reached years ago, but better late than never. Therefore, what Catalysit enables us is to create those layout and skinning files easlity, and I do think that this is what Adobe were aiming for.
The design developer workflow that Adobe so constantly are talking about is the main concept that Catalyst plays the role of the mediator in it. The idea, as I understand it, is not to expect code form the designer but rather expect the assets and layout files she’s generating and using, all this to build an end-to-end solution, from Photoshop (for instance) to the application .swf.
So far… doesn’t look bad at all :).

Are Components Views and vice versa?

An English translation is available for this post...

המוטיבציה לכתיבת הפוסט שלפניכם הגיעה משיחה קצרצרה שניהלתי בוקר אחד עם קולגה בעבודה, שהעלתה בי סימני שאלה מטרידים מעט בכל הקשור לארכיטקטורת קומפוננטות פלקס אל מול ארכיטקטורת views או יותר נכון Presentation Model. לצורך הדיון, אני אסביר בקצרה מה ה presentation model אומר; אפלקציית פלקס מורכבת בעיקר מרכיבי view שמייצגים את האיזורים השונים בה. View יכול להיות מסך Login, או טאב מסוים. לכל view שכזה יש את ה"ברזלים" שלו, שהם בעצם הקונטרולים הפלקסיים (containers, lists, buttons) ואת הלוגיקה שעומדת מאחור שכוללת את המצבים השונים של ה view ואת החישובים השונים הקשורים ללהתנהגות המצופה ממנו. הלוגיקה תמצא במה שאנחנו נקרא לו presentation model. וכך, כשאנחנו רוצים לבנות view מסוים, הוא חייב להיות מורכב לפחות מ- Class שמייצג את ה view ו-Class שמייצג את ה presentation model. יש המון יתרונות לשיטת פיתוח זאת מעבר להפרדה הברורה בין הרכיבים, אחד מהם, למשל, הוא טסט-אביליות נוחה.
אני בכוונה לא מרחיב מעבר לכך, בכדי לא לבלבל שלא לצורך.
בתור פלקסאי ותיק, אני מכיר את ה-framework של פלקס (לפחות,כרגע, עד SDK 3.x) ומכיר את מבנה הקומפוננטות הפלקסיות כמו Button, DataGrid וכיו"ב. עכשיו, זה נכון שגם שתי הנ"ל הן לכאורה view ולוגיקה הבאה לשמור על state ועל התנהגות מצופה, רק שב- framework הקומפוננטה Button מיוצגת ע"י Class אחד וכך גם DataGrid ועוד.
צורת הארכיטקטורה הזו, של קומפוננטות הפלקס, נראתה לי נכונה, שכן, לא ראיתי את הצורך לחלק את הקומפוננטה לשניים כאשר אין view שמיוצג ע"י MXML (ובמקרה הזה אני עושה את זה יותר עבור נוחות). הקומפוננטות עדיין היו טסט-אביליות, encapsulated ו-reusable.
אם אני אחזור לפתיחה, השאלה שנשאלתי הייתה מה שונה בין קומפוננטה ל-view, ולצורך ההפשטה – במה שונה מסך Login שנבנה בצורה גנרית לקומפוננטת כפתור גנרית? האם זה נכון לבנות קומפוננטת עם presentation model? האם יש מקום למינוח "קומפוננטה" בפלקס בכלל?
אני, כמו שאני, בוקר זה לא בדיוק פרק הזמן שאתם רוצים לפנות אליי בשאלות מהסוג שדורש חשיבה כלשהי, ישר התרעמתי ואמרתי ש"מה זאת אומרת? View זה view וקומפוננטה זו קומפוננ...”, אבל תוך כדי הרגשתי שמשהו חורק בהכרזה הזו. למה באמת לא לעשות קומפוננטות עם presentation model מאחוריהן? נכון לעכשיו, זה נראה לי יותר ויותר פתרון ארכיטקטוני נכון. זה נכון שיש לנו AS שבונה UI, אז מה? מדוע לא לפרק את הלוגיקה מה- view גם במקרה הזה?
אני עדיין מהרהר בזה ולכן אני מפרסם את הפוסט הזה. מאד הייתי רוצה לשמוע מה אתם חושבים ומה דעתכם.
תודה.

The motivation for writing this post in front of you came from a brief coffee-stand conversation I had the other morning, that raised some troubling thoughts and questions to my mind in all that is regarding the view architecture or to be more precise, the “presentation model” architecture.
For the sake of conversation, I’ll explain in short what the presentation model says; Flex application is mostly made of views that represent different areas in it. A view can be a login screen of a tab for that matter. To each view you have the “iron skeleton” which is the flex control (containers, Buttons, Lists) and the logic that stands behind it, which includes the different states of the view and other calculations that makes it work as expected. The logic will reside on, what we call, the Presentation Model class, and so, when we wish to build a certain view it has to made out of (at least) 2 classes. There are many advantages to this kind of architecture, say, easy testability.
I’m not going deeper to this architecture to keep you focused on the main problem.
As a veteran Flex developer I can pretty much say that I know the Flex framework (at least, until SDK 3.x) and know the component architecture like DataGrid and Button, etc. Now, it’s true that the ones I’ve mentioned are, apparently, views and logic that maintain the view states and its behavior, only that in the Flex Framework these components are represented as a single class.
This architecture of the Flex framework seemed right to me, that is, I didn’t see any need to divide the component into two where there is no view that is represented with MXML (in that case I do it for convenience). The components will still be testable, en capsulated and reusable.
If I’ll go back to the beginning, the question I’ve been asked was “what’s the difference between a view and a component?”, and to make things even simpler, what does a generically made login screen any different than a Button component? Is it right to build a component using the presentation model architecture? Is the term “component” is relevant at all in Flex?
I, being myself, don’t react well when people are showering questions at me at the delicate time of the morning, stood up and claimed that “what do you mean? View is a view and a component is a compon…” but then I felt that something is not right in saying that. Why would you not develop a flex component using the presentation model architecture? As for now it seems to be more and more the right way to do it. It’s true that we have the AS building our UI so what? Why not take the logic and states apart from it?
I’m still pondering on it and would very much like to know what you think about this issue
Cheers.

My First Take on Flash Build 4

אני רואה וקורא מה שקורה, את כל האנדרלמוסיה הזו המלווה כל יציאה חדשה של פלקס/פלאש וכמו כולם, תופס ריצת אמוק מפני השוורים השועטים ברחובות הרשת. איך המטאפורה עד כה? חלש... אני יודע.
לא, זה מגניב, שתדעו. אנשים כותבים על פלאש בילדר כאילו הם ישבו על האסלה בבוקרו של יום ויצרו כד חימר. אם אתם שואלים אותי, אני יכול לתמצת את פלאש בילדר בכמה משפטים פשוטים:
"רואים שמפתחי ג'אוה החלו לתת את הטון"
"לא, לא, ברצינות... מפתחי ג'אוה החלו לתת את הטון"
"איזה מגניב זה לחולל קוד באפליקציה, אבל... כמה זה עולה לנו בסוף?"

תראו, בסופו של יום, מרבית השינויים שנעשו בסביבת הפיתוח, היא הבילדר, הם עוד מספר צעדים לעבר הפיתוח הנוח באקליפס, למפתחי ג'אוה. יש עדיין כברת דרך לא קטנה, אבל אני, אישית, מרוצה מההתקדמות המתונה הזו. שכן נאמר כבר בעבר, לא חייבים לצעוד אחרי ג'אוה כמוקיונים סומאים, שכן, אחרי הכל, כש-Sun ז"ל באה לכתוב UI מה שיצא להם זה סווינג (ועכשיו JavaFX, שרק על זה רמי ורד יכול להעלות ערב שלם, ולשם שינוי לקרוע מצחוק).
בנינו, ה designer-developer workflow לא ממש העיף לי את הפטמה (אם להיות עדין). זה נחמד שיש את האפשרות לייצר ממשק, לגזור ממנו את הרכיבים ולחולל MXML בעזרתו. האם זה עוזר לי ועוד להרבה מפתחי RIA בעולם? אני בספק. אני חושב שהכלי הזה, Catalyst, יכול לשכון בכיף תחת הקטגוריה של "מוצרים שיביאו עוד מפתחים אלינו (Adobe)", שזה סבבה ובהחלט הכיוון הנכון, אבל לא ממש מרגש את מי שמפתח, אוהב ונוח לו עם סביבת הפיתוח של אדובה. מעבר לכך, אני לא ממש סומך על מחוללי קוד (עוד מימי Dream Weaver) כך שאני לא ממש רואה את עצמי עובד עם Catalyst על בסיס יומי.
השינוי המהותי עבורי נמצא יותר בין הקירות של ה IDE. הנה כמה דברים שדוקא כן מעיפים לי את הפטמה, ונכנסים לקטגוריית "הגיע הזמן באמת!":
Move Refactoring – למה זה לא נכנס בפלקס 3? אללא יודע...
Conditional Break Points – חן חן, ביחוד בפלאש, זה כל כך חשוב.
Getter/Setter generation, למרות ש... נו באמת, יאללא שיהיה.
Event Code Generation – תודה לכם שחסכתם לנו את הסיזיפיה הזו.
ASDoc – עכשיו כמו JavaDoc, יופי טופי.
Unit Testing – וואו! לא, לא... באמת וואו. מובנה בתוך ה IDE, מחולל מחלקות Test. כל הכבוד!

זה ברמה של הפיתוח. אני יודע שיש עוד, ואני אפילו לא באמצע השיטוט, אבל עדיין, זה מספיק לי.
מעבר לזה, כל מי שעובד עם Data Services ישמח לדעת על דברים כמו:
Network Monitoring – מה קורה לכם? לנטר אחרי התקשורת server-client ב IDE? ענק!
Data Management within the client – תשמעו, זה פשוט גדול. אני יודע שאנחנו בזבזנו לא מעט זמן לפתח משהו שכזה בקליינט, מה שהיום בשתי לחיצות עכבר וקפה עושים.
Defining Data Services Model – החיבור הפשוט ל BlazeDS וחבריו... מרגש, באמת מרגש.

די והותר, לא? כן, אני מבסוט בינתיים.
עכשיו, יש את כל החידושים והמצאות של ה SDK, שלא ממש הספקתי לרדת לעמקן, אך הם כבר הספיקו לעצבן אותי, עם namespaces כמו "s" עבור Spark, ועצם העובדה שקונטרולים מסויימים יופיעו כבחירה רק אחרי שלחצת בפעם השנייה על Ctrl+Space. "הם" רוצים שקודם יוצגו לך הרכיבים ש"הם" מעדיפים שתשתמש בהם. סבבה, אבל מעט לא בוגר. אדובה צריכים לצאת מנקודת הנחה שמפתחים שלהם כבר לא באנריסטים, והם יודעים מה יש ומה אין ובמה ירצו להשתמש.
העניין החדש עם ה States לא ממש מרגש אותי. זה היה ועדיין נשאר משהו שמאוד לא קל לנהל, מאד Hard-Coded ו... הממ... לא, לא עשה לי את זה. מה? הם באים לי אם האפרה של קוד שיהיה לי יותר ברור בעין? נו מה... אתם ילדים?

בכל אופן, זהו לעתה. אני מאד מרוצה בכללי עד כה, ואני בטוח שיש גם הרבה מפתחי ג'אוה מתוסכלים שסופקים כפיים ומרימים מבט לקוד האהוב עליהם בתודה. יש מצב לעוד טרוניות מצידי אז תפקחו אזניים.
יאללא ביי.

Flash Builder 4 (Beta) is a go

בשעה טובה יצאה גרסת הבטא של פלקס בילדר הרביעי, היא פלאש בילדר הרביעי (או הראשון? המממ.... רביעי? מתי היה השלישי?... לא משנה). יאללא, לכו תורידו, חרשנים.
יש עוד להוריד, מעבר לבילדר, כמו ה HP QTP Extensions וכדומה, אבל אני מניח שאתם תדעו למצוא זאת בכוחות עצמכם.
תבלו!

Well, it's about freaking time, ain't it?
At last, the Beta version of flash Builder 4 is out (or the 1st? wait... 4th? hmm... when was the 3rd?... nevermind). go ahead, download it, you nerds!~
There is more to download, like the HP QTP Extensions among others but I'm guessing that you'll be able to find it on your own, lads :)
have fun!