Add support to informative steps for the Flashmatticomponents Wizard

Scroll down for English translation...

טוב, זה יהיה קצרצר.
הוספתי לאחרונה, ל- Wizard Framework, את התמיכה בצעדים שכל תכליתם היא אינפורמטיבית.מה הכוונה? הכוונה היא שיש צעדים שלא אמורים להכלל בסיכום, בסופו של ה- Wizard. כל יעודם הוא להיות איזה Disclaimer או אולי המלצה מסויימת. מה שקורה בפועל הוא, שברגע שאין לאותו צעד data שהוא אמור לייצג, הוא פשוט לא נכלל בסיכום של ה- Wizard.
את קוד הפרוייקט החדש אתם יכולים להוריד מפה.
שימו לב שההורדה הישירה של ה- SWC גם עודכנה, אבל כרגיל, אני ממליץ להוריד את הקוד ולקמפל לבד.
תבלו.

Ok, this will be a quick one.
I recently added, to the Wizard Framework, the support for informative steps. What do I mean by that? I mean that there are steps that are not supposed to be included in the Wizard Summary. Their all purpose is to be some kind of a Disclaimer or some kind of a recommendation. What happens is that when these steps don't have a data representation, they will simply won't be included in the summary step.
You can download the project code from here.
Please note that the direct download of the SWC file was also updated, but as always, I recommend downloading the code and compiling it yourself.
Take care.

A Single Thread that can kill Flash

Scroll down for English translation...

זו רטינה.
אמנם לא חסרת תכלית, אך אם באתם בתקווה למצא פתרון, אני מצטער לאכזב אתכם הפעם.
מאד דרמתי מצידי, אבל אני חושב שזה מן ההכרח להצביע על המלך הנודיסט הוותיק - הרי הוא הת'רד היחיד של פלאש.
העובדה שפלאש יודעת לנהל רק ת'רד אחד בניגוד לסביבות ריצה אחרות (.NET, Java וכיו"ב) תמיד הייתה שם ברקע, אך מעולם לא נתפסה כטיעון מהותי נגד הטכנולוגיה. יש הטוענים שאם אתה מתכנת לפלאש פלייר ומצאת עצמך מנסה לנהל ת'רדים, אתה כנראה עושה משהו לא נכון. הוסיפו על כך את העובדה שבכדי לנהל ת'רדים, ה-VM של פלאש אמור לגדול בנפח, וקיבלתם את השיקול העסקי של אדובה לא לגעת בבייבי שלהם.
ברם, RIA, ומעבר לכך - AIR.

מה הבעיה ש'ך?
קחו את התרחיש הבא, בו אפליקציה כלשהי אמורה להשתמש ביכולות גישה ל- File System, ולעשות איזו איטרציה מסויימת על קבצי מערכת, משהו סטייל "ספר לי מה יש שם". תרחיש שיכול להיות בן-בית אהוב באפליקציות AIR, למשל, לא? עכשיו, בכדי שהלקוח שלנו יהיה מרוצה, אנחנו רוצים גם לתת לו חווית משתמש טובה (כי אנחנו מאמינים שאפליקצייה טובה לא נגמרת בארכיטקטורה פונקציונאלית), שתעזור לו להבין שמשהו קורה. progress bar נשמע כמו רעיון מבטיח.
אתם כבר מזהים את הבעיתיות? הרי יש לנו לולאה רקורסיבית שלא עושה הרבה בתוכה, אבל עדיין יכולה לרוץ פוטנציאלית פעמים רבות, מה שייתקע את הת'רד היחיד של פלאש, ושיגרום לכך שדבר, אבל דבר(!) לא יזוז על המסך והפלייר יתקע כמו אוטוביינקי בקסטל. אנחנו נחלוק מזל גדול אם ה- Progress Bar יעלה בכלל לתצוגה.

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

טוב נו, מה אפשר לעשות?
בשיטוטי לא נתקלתי עדיין בהתייחסות לעניין מצד אדובי בכל המדובר ב- roadmaps לעתיד הפלייר. אני גם לא הייתי שם יהווי על העניין. אתם יודעים. אישית, אני עדיין מחכה לתמיכה ב- Timezones שהובטחה בפלייר 10.
הפתרונות המוצעים בד"כ מדברים על לולאות פשוטות ולא רקורסיביות. איזה מין תמימות המבקשת לפרק לולאות פשוטות לחלקים קטנים יותר ולהריץ אותם בהתחשב בברינדור הפריימים. דוגמה לכך תוכלו למצא בפוסט מצויין של אלכס הרואיי (חובה לקרא את התגובות).

Pixel Bender
נחפש עוד קצת ונמצא את פתרון ה- Pixel Bender. בקצרה, Pixel Bender נועד ליצור אפקטיים חזותיים כמו פילטרים וכדומה על bitmaps, וקטורים ועוד. ת'כלס? אופרציות מתמטיות שמעבדות ביטים, ורצות על ת'רד נפרד. רגע, רגע, אז זה בדיוק מה שאנחנו צריכים לא? יש לנו ת'רד נפרד ועליו נריץ את מה שאנחנו רוצים, לא? ובכן התשובה היא לא. אפשר להריץ שם חישובים מתמטיים אבל לא לולאות. מה שגם, צריך לבנות עבור פעולות מיוחדות קרנלים (כן, Kernels, זוכרים מלינוקס? איזה כיף הא?... בואו נחולל קרנלים!), אז הפתרון הזה נחמד ויפה למניפולציות גראפיות או סאונדיות, כל עוד אין לולאות בעניין. לא טוב לנו. אתם יכולים לקרא על זה פה.

HTML
הלאה, כי אנחנו לא ילדות, ואני מנסה לפתור את העניין עם HTML. עובדה מעניינת אחת היא שאם תטמיעו HTML באפליקציית AIR שלכם, ותקראו לפונקציית JS שתרים Alert, אתם תופתעו לגלות שהת'רד היחיד של פלאש לא משחק שם תפקיד (מן הסתם) וה- Alert עולה כמו נינג'ה. מה שכן, אנחנו לא ממש מעוניינים ב-Alert. אנו רוצים משהו יותר בכיוון של חלון חדש שנפתח, עם פלאש פלייר אחר בתוכו, שיפעל בת'רד הבודד שלו. אתם יודעים מה? עזבו פלאש, אני מארגן progress bar שהוא AJAX נטו בפנים, יותר טוב מזה? אין.
כינים.
בשביל שה-HTML הנחמד שלנו ירונדר הפלייר צריך (ניחשתם נכון) לרנדר אותו, אבל הוא תפוס על הפעולה הרקורסיבית שלו, ושום דבר לא יעזור, ה-HTML לא מראה דבר וחצי דבר.

עוד פתרונות?
אין לי. לכן אני פה, כועס ורוטן. יש לכם? אשמח לשמוע...

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

This is a mutter
Not completely useless, but if you came here in search for a solution I'm sorry to disappoint you this time.
It's very dramatic of me, but I think it's high time to point out the so obvious fact that Flash has only one thread.
The fact that Flash can run on a single thread only, as opposed to other running environments (.NET, Java etc.), was always on the backgrounds but never was conceived as a major argument against the technology. Some might claim, that when you find yourself in need of multiple threads when developing for Flash, you're probably doing something wrong. Add that fact that in order to manage threads, the Flash player VM needs to grow in volume, and you get the business consideration for Adobe to not touch their little baby.
But then comes RIA and to top it off - AIR.

What's your problem?
Take the next scenario, where there is an application that supposed to use the file system API, and do some kind of an iteration over files. Something like "tell me what's going on in that directory". A scenario that can be a native resident in any AIR application.
Now, for our customer to be happy, we also want to give her a nice UX (cause we truly believe that an application does not end in a mere functional architecture) that will help her understand that some process is running. A Progress Bar sounds like a great idea.
Can you smell the rotten egg already? We have a recursive loop that doesn’t do much inside, but still can potentially run many times, what will eventually stuck Flash single thread and cause that nothing will be renderered on the screen. The player will be jammed and we will be considered lucky if our progress bar will be added to the stage (not to mention, show the progress).

Does it make you mad?
Now you tell me, does this lonely thread is something that Adobe needs to put high at their priority list when racing to conquer the RIA and Desktop Applications realm? Hell yeah.
It's very nice that the player is small, and it goes well with poor Web-Sites, but times are changing and you cannot be stagnated with the argument that "our player is small", especially when the competitors are supporting multi-threading.
Adobe has leaned and still leaning on the evangelist developers community, that works day and night in finding workarounds to many player limitations (RTL someone?), but the solutions to multi-threading support are awkward, expensive and to be honest? Not supposed to be something that we should develop.

Ok then, what can be done?
Roaming the web, I didn't find any reference to the issue from Adobe where it comes to Roadmaps for the future of Flash player. I wouldn't put my money there either. I'm still waiting for the Time zone support promised for Flash player 10.
The solutions suggested usually speak about simple loops and not recursive ones. A naïve approach to divide these loops into smaller routines and run them while considering the frame rate. A sample of that you would find in an excellent post by Alex Harui (reading the comments is a must).

Pixel Bender
If we look a little more we would find the Pixel Bender solution. In short, the Pixel Bender purpose is to create a dynamic visual effects like filters and such, on bitmaps and vector graphics. In a nut shell? Mathematical operations on bits that run on a different thread than the one used by the Flash player.
Hold on! This is exactly what we need, isn't it? Well, the answer is no. you can run mathematical calculations but not loops, and you also need to generate Kernels (yeah, remember that Linux fun?), so this solution is nice for graphic or sound manipulations, but as long as there no support for loops it doesn't really help us. You can read about it here.

HTML
Going on, cause we're not giving up that easily, I try to solve the issue with embedded HTML. One interesting fact is that if you embed HTML into your AIR app, and call a JS function that pops up an Alert, you will find out that Flash single thread doesn't get in the way and the alert goes up when asked, but I want something nicer, like a window. You know what? I don't even need Flash inside that window, I did it all in pure AJAX. Does it get any better than this?
Nothing.
In order to render HTML, the player needs to render the HTML container, but it is caught up in it's loop so nothing happens.

More solutions?
I have none. This is why I'm here… complaining. If you have some, I will be sure happy to hear them.

In conclusion
Straight and to the point, there are other technologies that do support multi-threading.
If Adobe wishes to keep their relative advantage over the competitors, in the RIA section and mostly in the Desktop Applications, I humbly suggest that they will take the matter of multi-threading into consideration, and fast, cause Microsoft ain't gonna wait until the next MAX convention.

You open, You see :: Curly Braces

Scroll down for the English translation...

מה המצב? איך עובר עליכם החג? בטוב? יופי.
אז ככה, אתם יודעים שמקום העבודה הוא אחת הזירות הטובות ביותר להעלות תהיות ומחלוקות. וכך קורה ששאלות תמימות (או לעיתים לא ממש) הופכות לדיונים סוערים, שאפשר להפיק מהם בעיקר תובנות ותשובות.
הנה משהו שקולגה שלי העלה וחשבתי שיהיה נכון (כמובן, ברשותו האדיבה) לשתף אתכם בו:
בזמנו, כל ביטוי action script בקובץ MXML היה צריך לחיות בתוך סוגריים מסולסלים, אבל מאז עברו מעט מים בנהר והסוגריים המסולסלים הם לא ממש הכרח. מתי לא? מתי שהצפי הוא עבור אובייקט, או מתודה, או אם להיות יותר מדויק כל מה אמור לייצג מחרוזת. סוגריים מסולסלים קיבלו מקום בעיקר עבור Binding, וכולנו יודעים שהן בעצם מורות לקומפיילר לייצר אקסטרה קוד שאמור לנהל את ה- Binding במקןם הנתון.
ובכל זאת, אנחנו עדיין רואים מפתחים משתמשים בסוגריים מסולסלים, כאשר הם למשל מגדירים event handlers, הו-אז נשאלת השאלה הבלתי נמנעת: האם כאשר אנחנו מגדירים event handler בתוך סוגריים מסולסלים אנחנו למעשה כופים על הקומפיילר ליצור אקסטרה קוד עבור Binding לא נחוץ בעליל?
בפשטות? לא.
למטה תוכלו למצא את קטעי הקוד המג'ונרטים (ברוך המוציא generated מן הקומפלייר), פעם אחת עם סוגריים מסולסלים ופעם בלי. כפי שאתם רואים, ההבדל הוא, באופן מפתיע, סוגריים מסולסלים. אז מעתה אתם יכולים להיות רגועים ולהרגיע את הסובבים אתכם – זה בסדר.
שנה טובה.

How’s its going?
So, you know that the working place is one of the best places to raise thoughts, wonderings and debates. And so it happen that innocent questions (or some time not that innocent) become a great argument, which sometimes you can benefit from.
Here is question that my colleague raised and I thought it would be great (with his generous permission) to share with you:
At the time, any ActionSctipt expression on an MXML file would have to be inside curly braces, but since then time has passed and the curly braces are not mandatory. You ask “when?” – Well, whenever the expression is not meant to define a String. Curly braces got the honorable rule of defining Binding (in general), and they instruct the compiler to generate extra code to handle the binding on the spot.
Still, we see developers using the curly braces when they define Event handlers, for instance. Then, one might ask, when you define an event handler inside curly braces, do you still instruct the complier to generate extra code, to no need?
Simply answered? Nop.
If you look, below, you would see the code and the generated code snippets for both using curly braces and not using them. As you can see, the only difference is, well, the curly braces. So from now on you can relax… it’s ok… it’s ok :).

Cheers.

Without curly braces

/**
* @private
**/
public function ___CurlyBraces_Application1_creationComplete(event:mx.events.FlexEvent):void
{
onCreationComplete(event)
}

With curly braces

/**
* @private
**/
public function ___CurlyBraces_Application1_creationComplete(event:mx.events.FlexEvent):void
{
{onCreationComplete(event)}
}

Flashmatticomponent direct SWC download

Scroll down for English translation...

אהלן,
אם תקראו את התגובות על הפוסט בו הצגתי לראשונה את Flashmatticomponents, תוכלו להבחין באחת המלינה על כך שאין אפשרות להוריד את ה- swc ישירות, אלא חייבים להוריד את הקוד ולקמפל לוקאלית.
נכון, ואללא נכון. הסיבה שעשיתי זאת כך היא מפני שהרבה יותר קשה לנהל את הגרסאות בצורה הזו, ויש מצב שה-SWC שאפשר להוריד ישירות לא יהיה הכי-הכי מעודכן.
בכל אופן, זה יהיה נכון לשים שם את גרסת ה-SWC, וזה מה שעשיתי. תרגישו בנוח לגשת לאיזור ה-download של אתר הפרוייקט ולהוריד את ה-SWC.

יאללא ביי.

Hey guys,
If you'll read the comments on the post where I first published the Flashmatticomponents, you'll notice one that complains about not having a direct download option in the project site, for the SWC file, but rather the option to download the code and compile it locally to get the artifact.
True, yeah… The reason I did it so is because it's a lot harder to manage the versions that way, and a situation might rise, where the direct download SWC will not be as updated as the one generated by compiling the code.
In any case, it would be a good Idea to put a direct download link to the SWC, which I did. Feel free to go there and download it.

Cheers!

FlexPMD from Flex Builder

Scroll down for English translation...

שלום שלום, מה קורה?
וודאי רובכם יודעים שאדובה הוציאה את FlexPMD לשוק הפתוח, ואם נהיה כנים - זה אחלא של דבר! למי שלא מכיר, אפשר לקרא פה, אבל בכל זאת הנה העיקר:
מוצא קוד שלא בשימוש.
מוצא קוד לא יעיל.
מוצא קוד שהמורכבות שלו מוגזמת.
מוצא רוטינות קוד ארוכות מדי.
ועוד יותר...

תשמעו, אתם מריצים את זה על הפרוייקט והוא מוצא תחלואות שלא היו מביישות את סומליה. ממש ממש כלי טוב, פשוט ויעיל העוזר לייצר קוד טוב יותר, ברם (ואתם ידעתם שזה יבוא), אליה וקוץ בה.
זה מגניב שאפשר להפעיל את זה אפילו מהמטבח של גיל חובב (mvn, ant, cmd) אבל אני רוצה דרך מהירה ויעילה להפעיל את העניינים. משהו של "קליק אחד ויאללא לרפואה", משהו של "מתוך פלקס בילדר ולעסק", וזה נכון שאדובה אומרים שהם עובדים על פלאג-אין לפלקס בילדר, אבל סאחבק לא נודע בשל חיכיונו למשיחי-תוכנה החל לתור אחר פתרון.
External tools!
מה שעוללתי הוא external tool בתוך Flex Builder, שיקרא Create PMD, והוא ידע לפנות ולבצע את הפעולות, נכון למיקום הבחירה בעץ הפרוייקט. כלומר, אם תבחרו את ה root, קובץ ה- PMD יופיע שם, אם תבחרו package, הקובץ יופיע בה.
תעקבו אחר הצעדים בתחתית הפוסט (הם באנגלית, אני יודע, אבל אתם תתמודדו), ובשלוש דקות יהיה לכם כפתור שמייצר PMD בקליק אחד. בכדי לחזות בתוצאות באופן נהיר, אדובה מציעים לנו את ה viewer שלהם. כל שצריך הוא להעלות את ה- PMD אליו וחזות בזוועות הקוד.
אם יש בעיות עם ה- tool, דברו איתי :).

Hi guys,
Recently Adobe has launched a new open source project called FlexPMD. You can read all about it here, but here are the highlights:

“FlexPMD is a tool that helps to improve code quality by auditing any AS3/Flex source directory and detecting common bad practices, such as:

* Unused code (functions, variables, constants, etc.)
* Inefficient code (misuse of dynamic filters, heavy constructors, etc.)
* Over-complex code (nested loops, too many conditionals, etc.)
* Over-long code (classes, methods, etc.)
* Incorrect use of the Flex component lifecycle (commitProperties, etc.)”

Well this is multi-nice, but it seems that we need a better/quicker way to invoke it on our projects than have it on the Maven site/Ant/CMD. This is something that we need on a day-to-day, hour-to-hour basis.
So until the Flex Builder plug-in will be out (they are working on it), here is my solution, and you are all welcomed to adopt it for better coding:

STPES:

Download the “command-line” version from adobe and extract it onto your local machine.
Open Flex Builder.
On the top menu, go to Run > External Tools > Open External Tools Dialog…
Create a new External tool and call it “Create PMD”.
Fill it according to the following:

• The Location is where the java.exe can be found
• The Working Directory is set to a variable which is the selected resource on the project tree (the variable name is “resource_loc” and can be found on the variables list).
• The Arguments are where the flex-pmd-command-line-1.0.RC3.jar is found, the source (“s”) and output (“o”) folders which are set to be at the same location as the Working Directory.
  

Ok – all you need to do now, is to select a resource on the project tree and run this tool.
After the tool has completed its work – you will see a pmd.xml file on the same folder you’ve selected on the project tree (if you don’t, refresh the tree, it’s there…).
Launch Adobe PMD viewer URL.
This is the viewer for PMD that Adobe created (If you’re really lazy, you can open the viewer directly from Flex Builder… but that's another story).
Load the file onto it and witness the HORROR :)

If you encounter any trouble with the tool, please let me know.
Cheers.

עברית או אנגלית / Hebrew or English

An English translation is available for this post...

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

It’s been a while that I’ve been walking with a small wondering cloud hanging above my head, as to keeping the Hebrew flavor of my blog. I love Hebrew, I love writing it, but there is no way you can avoid the obvious fact that this blog, being a technical blog, kinda misses its full strength when you mix the holy tongue with hi-tech terms. It’s true that I keep translating the technical posts, but still, aside from the fact that it’s a double work for me, it feels a bit overwhelming to the readers and sometimes even intimidating.
And on the other side, I truly love Hebrew.
I want to ask you, those who read the this blog - what do you think is the right direction to go? Hebrew? English? Both? Maybe a different solution?
What say you?

Flashmatticomponents – Open Source Flex/AIR Library by Flashmattic

An English translation is available for this post...

כותרת מפוצצת, הא? כן... אבל יש סיבה.
שלא תגידו שסחבק בא עם כל מיני "אני מכין לכם משהו", אבל יוצא מוסכניק בסוף. בחודש האחרון אני עמל על פרוייקט חדש ופריימוורק מגניב (לדעתי, אבל איך אומרים – "קוף בעיניי אימו, איילה"). אז אם כן, בשעה טובה ומוצלחת, אני פורש את הדברים לפניכם, והרי עיקרם:
זה נכון שכחלק מתהליך עבודה, אתה מוצא עצמך בונה סט של קומפוננטות, ואם יורשה לי, פריימוורקים לשימוש האישי. ככה זה, והרי זה מבורך, אבל אחרי זמן מה הסוציאליסט החבוי שבך מתחיל להרים ראש ולשאול "למה לא לחלוק... בנאדם?".
אז הנה אני מוצא עצמי בונה פרוייקט קוד-פתוח בחסות google-code, בשם Flashmatticomponents (שימו לב לקופירייטינג המושחז והמרטיט). הפרוייקט הזה, כמו כאלו שקדמו לו, יכיל קומפוננטות ופריימוורקים וכל דחפין יתי ויאכל. הקוד פתוח, כלומר שראשית, ניתן להוריד את ה SWC ולהשתמש בו כאוות נפשכם בכל פרוייקט העולה על רוחכם, ושנית, ניתן להוריד את ה source בעזרת SVN, לייבא את הפרוייקט לפלקס בילדר הקרוב לביתכם ולהתעמר בו. הרשיון לשימוש הוא Apache License 2.0.
אז לפני שאני אתן לכם את הקישור, אגיד לכם מה יש שם כרגע, ככה שלא תופתעו:
יש שם את ה PathValidator שפרסמתי לא מכבר. למי שלא זוכר, זהו וואלידטור המוודא שנתיב ל file system הוא ואלידי ומצביע אל קובץ או תקייה אמיתיים. זה בקטנה, ככה באפרטיף.
מה שבאמת מגניב הוא פריימוורק חדש שקראתי לו “Wizard”.
Wizard הוא פריימוורק שכל יעודו הוא לתת מענה קל ופשוט לייצירת step-by-step wizards בפלקס. אני לא מאמין שיש מישהו שלא יודע מה זה wizard, אבל לכל אלה שלא התקינו אפליקצייה מימיהם, ועשו next-next-next, אני אסביר שזה המקום שבו אתם בד"כ עושים... next-next-next.
ה- Wizard נותן כמה יכולות מאד מתבקשות, כמו:
1. הגדרת צעדים בתוכו היא קלה ומאד אינטואיטיבית.
2. מנהל את הנוויגציה בין הצעדים השונים בו.
3. מדספטצ' events עבור כל פעולה בו, בין אם עוברים לצעד הבא, או חוזרים אחור, מבטלים או מסיימים את ה- Wizard.
4. קובע את הגודל של עצמו נכון לגודל הצעדים שבתוכו. המפתח לא צריך לדאוג לכל עניין המדידה.
5. אחראי על איסוף המידע בכל צעד והשמה שלו באובייקט Data Model שהוזרק לו מבעוד מועד.
6. יכול להתבטל בכל רגע נתון.
סבבה, לא?
בכל אופן, את "איך משתמשים" ודוגמאות קוד תוכלו לקרא בדפי ה- Wiki של הפרוייקט, וכמובן אם יותרו לכם שאלות, אני פה (או שם), פשוט תפרסמו הערה ואני כבר אטפל בעניין. לא לא, זה מאד חשוב – כל הערה, שאלה משאלה (או גם מילה טובה, אם יש על מה) אני אשמח לשמוע ולפעול בהתאם, בטח ובטח אם גילתם באג סורר, או התנהגות לא צפויה/נכונה, אפשר לדווח על באגים בדף הפרוייקט עצמו.

אז עכשיו, כל שנותר הוא לקפוץ לאתר הפרוייקט, להוריד ולנסות.
תבלו :).

Grand headline, euh? Yeah… but there’s a good reason for that.
Just so that you won’t say that I come up with those promises of “cool stuff”, and later fail to deliver, I will let you know that I’ve been working on a new project and a cool framework for the past month or so, and if you allow me, I will present it now:
It’s true, that as a part of a working process you find yourself building a set of components, and dare I say frameworks that will help you along the road. That’s just the way it is, and a good thing too, but after a while the collaborative persona within you rears its head and starts asking: “why not share… mate?”
So I find myself building an Open Source project under Google-Code with the name of “Flashmatticomponents” (whiteness the marvelous and spin-shivering copywriting). This project, like other Open Source projects contains components and frameworks, so that whoever wishes to use them, will be able to.
The code is open, which means that you can download the SWC and use it freely in you project, and secondly, you can download the source and, import the project into your Flex Builder and mess with it. The Open Source Licensing is Apache License 2.0.
So, before giving you the link to the Google code site, I will tell you what currently can be found there, so that it won’t catch you in surprise:
You will find the PathValidator that I’ve recently published here. To those who don’t remember, it’s a Validator that checks the validity of native paths to the local file system. Pretty handy for any AIR application that uses file access, but this is just the aperitif…
What is really cool is the new framework that I named “Wizard”.
Wizard is a framework that its whole purpose is to make the implementation of wizards in Flex/AIR easy. The Wizard gives some very trivial behaviors:
1. Steps are easily implemented and added to the wizard, allowing the developer to concentrate on more important stuff.
2. It is responsible for the navigation within it, whether the next or previous steps are available and knows when the user has reached the end of the wizard.
3. It dispatches events for each relevant stated of the Wizard, such as: moving forward to the next step or moving backwards to the previous one, canceling it and of course when the Wizard is completed.
4. It is responsible for scaling itself according to its steps measured size. The developer using it should not be bothered with setting width and height to the Wizard or the steps.
5. The Wizard is also responsible for collecting the information the user has entered throughout the steps and package them into a data model object given to it.
6. The wizard can be canceled at any stage.
Sweet, right?
Anyway, you’ll find “how-to”’s at the project Wiki, and of course, if you still have questions, submit a comment and I will happily attend to it. No really – this is very important, if you have any wish, question, found a bug or simply have something nice to say, I will be glad to hear about it.
All there is left now is to jump to the project site, download and try it.
Enjoy :).

OT: הופעה של TYPO במעבדה, ירושלים

מה המצב?
לא, לא, שלא תגידו, גם הפעם אני אפתח בהתנצלות כוללת על כך שהעדכונים לא תכופים כשהיו, וכרגיל אקנח בכך שמחכה לכם, קוראים יקרים, פינוק פלקסי שיגניב לכם את האיברים הצנועים ביותר.
בכל מקרה, באתי הלום בכדי לספר לכם ש-TYPO (הלהקה של עבדכם הנאמן, לכל מי שלא מעודכן) תופיע ביום שישי הזה, אוגוסט 7, בשעה 14:00 (כן, זה הקטע) ב"מעבדה" בירושלים. הפעם אנחנו מארחים ראפר מ-UK העונה לשם Lord Thunda ודופקים איתו כמה שירים.
אתם מוזמנים לקרא על האירוע פה: אירועים במעבדה, וכמובן להגיע ולשמוע :).
נתראה שם.

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!

Path Validator

An English translation is available for this post...

הבטחתי, לא?
אז הנה איזה משהו קטנטן (באמת) שהוא חלק מאיזה פרוייקטון שאני עובד עליו. מדובר בואלידאטור שנועד לבדוק "תקינות" של path שמשתמש בכניס. השימושים די ברורים, למעשה כל אפליקציה שדורשת מהמשתמש להכניס Path כחלק מהפעולות שהוא רוצה לבצע.
הואלידאטור הנוכחי בודק אם בכלל יש קלט ואז, אם יש, הוא פשוט בודק אם הנתיב הזה קיים לוקאלית. זה הכל.
יש שם איזה try…catch קטן בכדי לא לפול על wrong arguments exception שיכול לעוף ברגע ש... יש ארגומנטים שלא יכולים להוות נתיב. זה הכל בתכלס. למטה אתם יכולים למצוא את הקוד של הולידאטור ואת השימוש בו. שימו לב שהאיתחול והשימוש בולידאטור נעשה ב-AS, למרות שהוא יכול להיעשות גם בדרך הקונבנציונאלית ב-MXML.
לכל שאלה, טענה וכיו"ב, אתם יודעים איפה למצוא אותי.
תבלו, וחג גבינות שמח!

I promised, didn’t I?
So here is something real tiny that is a part of some project I’m working on. It’s a Validator which checks a file path that the user have entered. The usage is pretty straight forward, any application that requires the user to enter a valid path as part of the operation he wants to perform. This Validator check if there’s an input at all, and there is, it checks that the file path does exists. That’s about it.
There is a little “try… catch” that ensures that the Validator won’t fall on wrong arguments exception that the File class might throw once the arguments for it are… well… wrong.
That’s it really, you can see the code for the Validator and the usage of it below.
Notice that the instatiation and usage of the validator is made in AS code, though it can be done in the more conventional way, in MXML.
For any question or comment, you know where to find me.
Take care.

PathValidator

package com.flashmattic.validator.pathvalidator {
import flash.filesystem.File;

import mx.validators.ValidationResult;
import mx.validators.Validator;

/**
* This validator validates that a path given is a valid path for an existing
* file or folder.
* @author MBz
*/
public class PathValidator extends Validator {
public function PathValidator() {
super();
}

/**
* Checks for illigal arguments for the File constructor and also if the
* path given is valid and points to an existing file or folder.
* This also checks of any input was inserted, if the user decided that
* this field is requiered.
* @param value
* @return Array
*/
override protected function doValidation(value:Object):Array {
// Convert value to a String.
var inputValue:String = value as String;

// Clear results Array.
var results:Array = new Array();

var validationResult:ValidationResult;

// Call base class doValidation().
results = super.doValidation(value);

// Return if there are errors.
if (results.length > 0) {
return results;
}

if (required && (inputValue == null || inputValue == "")) {
validationResult = new ValidationResult(true,
null,
"no string",
"You must enter a path");
results.push(validationResult);
return results;
}

try {
var testFile:File = new File(inputValue);
if (!testFile.exists) {
validationResult = new ValidationResult(true,
null,
"path not valid",
"Invalid Path");
results.push(validationResult);
return results;
}
} catch (e:ArgumentError) {
validationResult = new ValidationResult(true,
null,
"path not valid",
"Invalid Path");
results.push(validationResult);
}
return results;
}
}
}

Usage

filePathValidator = new PathValidator;
filePathValidator.addEventListener(ValidationResultEvent.VALID, onFilePathValid);
filePathValidator.addEventListener(ValidationResultEvent.INVALID, onFilePathInvalid);
filePathValidator.required = true;

filePathValidator.validate(value);

OT: עוד הופעה בעיר הקדושה

כמה OT's אפשר הא?

אני יודע... יש כאלו המתמרמרים, אבל מה אני לעשות? יש התפתחויות מעניינות בתחום המוסיקאלי, ולמרות שה-validator חדש שכתבתי מרתק (את השועלים ואותי...) אני מרגיש הרבה יותר טוב בלבשר לכם על ההופעה הבאה שלנו, בהתרעה של "מהיום למחר?".
הלהקה שלי, TYPO, מופיעה בירושלים במוצ"ש הזה (כן, מחר. זה הקטע של מהיום למחר בד"כ). אנחנו מופיעים עם להקה מצוינת שנקראת the CarSitters, המקום נקרא Bass. ההופעה תתחיל ב-22:00.
תגיעו, מבטיח שלא יהיה דיסקו.

OT: הופעה נוספת באוזן!

כן, זהו עוד פוסט שלא קשור לפלקס. תתבעו אותי.

אז ככה, ללהקה שלי יש עוד הופעה ב"אוזן בר" במסגרת ערב מרובע של 4 להקות (וחצי, עוד רגע תבינו למה) שהקונספט שלו הוא סולניות עם להקות בועטות מאחוריהן. האירוע יקרה ב 15 לחודש מאי, כלומר החודש למי שזה לא חלחל עבורו, ביום שישי. לכל הספקנים הנה הלו"ז של חודש מאי, תעיפו מבט.
ת'כלס, ערב של רוק/אינדי טוב, להקות שבאמת שווה להכנס ל- MySpace שלהן ולהטות אוזן. עכשיו, החצי ממקודם הוא מופע חימום של רייצ'ל עזוז (כן, השם מעלה עווית על הפה, אבל בכיף) משהו אינטימי-סטייל עם פסנתר בקטנה, לפי מה הבנתי אמור להיות סבבה. וכמובן דיג'וי של יעל קראוס מהפאניק-אנסמבל (הטו, הטו אוזן) לאורך כל הערב, והכל כולל הכל בעבור 40 שקלין מצלצלין וטיבין.
למי שלא זוכר איך ומה, אתם מוזמנים לקפוץ ל- MySpace שלנו. וכמו שאומרים, נשמח לראותכם במיטב מחלצותיכם, אבזמי-אפכם ומיימית וויסקי.
קפצו ל- Facebook ותנו Attend.

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

OT: הופעה שלנו באוזן-בר

An English translation is available for this post...

מה המצב?
אז ככה,כמו שחלקכם אולי יודע יש לי הרכב (להקה קוראים לזה, אבל נו... מה עכשיו?) שנקרא "Typo". אתם יכולים לשמוע קצת צלילים מחזרות ב- MySpace שלנו. הסיבה שאני שם את זה פה היא שאנחנו מעלים הופעה ב-3 לאפריל, 2009, שזה יוצא יום שישי,באוזן בר, ככה לקראת חצות שכזה. זו הופעת טרום בכורה, קצרה וקולעת וחשוב מכל - חינאמית. אז אתם יכולים להתייחס לזה כהזמנה אישית.
בכיף.
יאללא ביי.

How's it going?
So as some of you might know, I have a band called "Typo". You can some of our stuff from rehearsals we did on our MySpace spot. The reason I'm telling you this is that we're giving a show on April 3rd, 2009, in a place called The Ozen-Bar, close to midnight. It will be a pre-premiere (… right) show, short and to the point and most importantly - free! So you can take this as a personal invitation.
Cheers.

You open, You see :: Label

An English translation is available for this post...

בהמשך ל"פותחים רואים" הפעם אני אתעכב על class שכולנו משתמשים בה תכופות ויכולה לעיתים למרוט את העצבים שאנו שומרים רק להפסדים של נבחרת הכדוריד של טורקיה: Label.
למי שלא מכיר, הקדמה קלה – Label זו מחלקת UI שבאה להציג טקסט בשורה אחת עם היכולת הנהדרת של חיתוך הטקסט במקרה ואין מספיק מקום עבור כולו, שירשור עם "..." ויצירת tooltip עם הטקסט המלא. זו פונקציונאליות לא רעה, בייחוד אם רוצים להציג מידע ב- DataGrid למשל, ומעוניינים בהתנהגות שמגדירה כי ברגע שמצמצמים רוחב של עמודה המציגה טקסט, הטקסט יחתך עם "..." ו- tooltip יופיע עבורו.
אז הנה שני דברים מעניינים שגיליתי תוך כדי נבירה במחלקה:
הראשון, אם נביט במתודת updateDisplayList נגלה שיד נסתרת מירקרה (ניטרלה את הקוד כהערה) האחראי ליצירת צבע רקע עבור ה Label. מדוע? לא ממש ברור, ואני יודע שיש מספיק חנאנות שבנו מגדלים רבים בכדי לספק ל- Label שלהם רקע, אז סאחבק הרים את הכפפה המעופשת והרחיב את המחלקה. לא עשיתי הרבה, שכן הקוד היה כבר שם. אני אשמח לדעת אם יש סיבה מסויימת לכך שהוא מורקר. את הקוד תוכלו למצוא בסוף הפוסט.
הדבר השני, שהטריד אותי הרבה יותר, הוא באג תמוה ומכעיס שיש ל- Label ושנוגע בדיוק בפיצ'ר המגניב שהזכרתי לעיל. אני אסביר: נניח שיש לנו container ברוחב מסויים ותחתיו יש לנו Label עם רוחב של 100 אחוזים. הדבר יתבטא בכך שה- Label יקבל את הרוחב של ה container. נקטין את ה container נקטין גם את ה Label, אתם מבינים את הרעיון. באופן מוזר, ברגע שלא מוגדר ל Label רוחב פיקסלי מוצהר, הטקסט שבתוכה מרחיב אותה בלי להתחשב ב- container בו היא נמצאת. רציתי לברר את הסיבה למחדל הזה שגורם לנו לפעמים ליצור כל מיני workarounds מטורפים (שגם שעולים בביצועים) ולמצוא פתרון יותר אלגנטי עד שהחבר'ה שם למעלה יתעוררו.
הסיבה למחדל הזה נעוצה בחישוב ה- explicitMinWidth של Label. כפי שאולי ידוע לכם, את המאפיין explicitMinWidth אנחנו לא מגדירים ישירות אלא ע"י השמת ערך למאפיין minWidth, מה שאומר שאם לא מגדירים minWidth אזי ה explicit min width לא מוגדר. תוסיפו למשוואה את העובדה ש- explicitMinWidth נדרש עבור חישוב גודל "הילדים" של container ויש לכם כבר שלושת-רבעי התשובה.
Label מחזיקה את UITextField בקומפוזיציה וזו אחראית (היא וכל אבותיה) על כל חישוביי הרוחב של תיבת הטקסט, חיתוך הטקסט וכיו"ב. כפי הנראה, ב- measure נעשה חישוב של רוחב תיבת הטקסט נכון לטקסט שבתוכה וגם ה minWidth מוגדר עפ"י אותו הגודל, משמע, היה לנו טקסט שרוחבו הסתכם ב 480 פיקסלים לצורך העניין, גם ה- minWidth של תיבת הטקסט יוגדר כ 480 פיקסלים. ואם ה minWidth מוגדר כך, אזי גם explicitMinWidth מוגדר כך. אין סיכוי שתיבת הטקסט תצטמצם נכון לcontainer שמחזיק אותה שהרי יש לה הגבלת מינימום של 480 פיקסלים. מרגש, לא?
בד"כ זהו המקום להוציא שלל דימויים עבור מי שקודד את האיוולת, אך במקום זאת אני אפנה לפתרון המיידי והפשוט. ברגע שאתם רוצים שה- Label יסונכרן ברוחבו ל container שמגדיר אותו, יש להגדיר את ה minWidth שלו ל-0. שכן, ברגע שמוגדר כבר ערך עבור explicitMinWidth פעולת ה set של minWidth פשוט לא עושה דבר. זה הכל.
אני מקווה שהשכלתם ומעתה תדעו יותר על מה שקורה בתוך Label. עד הפעם הבאה, עם מערכת חיסון חזקה יותר מכל הבחינות.
תיסלם.

In continue to “you open, you see” series, this time I’m going to talk about a class that we all know and use very often, yet it has the potential for killing us slowly as a result of a nerves breakdown: the Label.
For those of you who have no idea of what I’m talking about, here’s a quick brief – Label is a UI class that represents a text in a single line with the great ability to truncate that text if the space doesn’t allow all of it, adding a “…” suffix to it and a nice tooltip with the full text in it. This functionality is not bad at all, especially when you want to display a textual data in a DataGrid, and have a behavior that when the column is reduced in width, then the text within it will be truncated with a “…” suffix and a nice tooltip.
So here are two interesting things that I found out digging in that class:
The first, if we look at the updateDisplayList we shall find that a mysterious hand has removed the code that was assigned to handle coloring the background of the Label component. Why? Heavens knows. I do know that many geeks have built many extensions to overcome not being able to color the background of Labels, so I’ve decided to take this small opportunity and extend the Label class. Actually, I didn’t do that much. The code was already there, but commented out. I’ll be glad to know if there is a reason for commenting this out in the first place. You can find the code at the end of this post.
The second thing that bothered me even more, is the weird and annoying bug that Label has right where the nice feature I mentioned above is. I’ll explain: Say we have a Container bearing a certain width and residing in it we have a Label with the width of 100%. This means that if we reduce the width of the Container then the Label’s width will act accordingly and be reduced as well. Strangely, when you don’t set a specific pixel width to the Label, the text inside it stretches it without caring about the width defined on the parent Container. I wanted to realize why this happens, this which cause us sometimes to come up with weird workarounds (that are also expensive performance wise), and find a more elegant solution to it until the guys upstairs wake up (maybe they did, in Gumbo?).
The reason for this bug is due to the calculation of the explicitMinWidth member. As you might know, we can’t directly set the explicitMinWidth member, but instead we define it by defining the minWidth member. This means that if you don’t define the minWidth then you’re not defining the explicitMinWidth as well. Adding to this equation the fact that a Container relies on explicitMinWidth to measure its children and you already have three-fourths of the solution.
Labels holds UITextField in composition, which is responsible (with its ancestors) for all the text field sizing calculations, text truncations and the rest. As it seems, the width calculation of the Label’s text field is done within the measure method of the Label class. Inside that method the minWidth is set for the component according to the text measurement I’ve mentioned before, so if our text width is 480 pixels, the minWidth of the Label component is set to 480. If the minWidth is set to 480 pixels so is the explicitMinWidth. There is no way that the parent Container of the Label will be able to cast it’s width on it, since we have a 480 pixels minimum width constraint on it. Exciting, isn’t it?... oh man.
Usually this is the place I reach for the sickest metaphors I have in order to describe to ones who coded this monstrosity, but let me spare you with that and go directly to the simple solution. When you want the Label to be in synch with its parent Container width, simply put 0 as it’s minWidth because, when there is a value set to the explicitMinWidth the minWidth setter does nothing. That’s all.
I hope this helps you and you now know a bit more about what’s going on inside the Label class. Until next time, take care, guys.

package com.flashmattic.underthehood.labelex {
import flash.display.Graphics;

import mx.controls.Label;
import mx.styles.StyleManager;


/**
* Color of the Label object's opaque background.
* The default value is undefined,
* which means that the background is transparent.
*/
[Style(name="backgroundColor", type="uint", format="Color", inherit="no")]

public class LabelEx extends Label {
public function LabelEx() {
super();
}

override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void {
super.updateDisplayList(unscaledWidth, unscaledHeight);

var g:Graphics = graphics;
g.clear();
var backgroundColor:* = getStyle("backgroundColor");
if (StyleManager.isValidStyleValue(backgroundColor))
{
g.beginFill(getStyle("backgroundColor"));
g.drawRect(0, 0, unscaledWidth, unscaledHeight);
g.endFill();
}
}
}
}

Flasher :: New Mag

An English translation is available for this post...

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

Yeah, I know I haven’t been writing for tones of time but fear not for I still coded my arse off like a beaten up boy at school lunch break.
All in all, all I came to say is that I found this nice new Flash/Flex Magazine on the web which pretty cute, nicely made (even for an armature mag maker) and… worth a look. There are some nice interviews with people from the scene, some geeks laughs and information of course. Give it a go: Flasher.