This Hebrew message will be followed by an English one...
הטריף לי את השכל, הקטע הזה, הארגומנט הממזר הזה של MXMLC (ו- COMPC) שנקרא בפי חבריו: keep-as3-metadata. אם תקראו בקצרה בדוקומנטציה (שכמו תמיד לא מאכזבת ולא מספרת שום דבר יעיל) תלמדו שאם אתם רוצים לשמור תגי metadata שלכם, כך עושים זאת. לא ממש מפרטים מי, מה, איך להוציא את הפרטים של אותו התג ב-runtime... לא... למה שפרטו? אנחנו, כרגיל, ננחש.
האמת? את העניין גיליתי תוך כדי הצצה לעבר framework שנקרא
Swiz (שווה הצצה, אבל לא מספיק בכדי לצאת לרחוב בצעקות "הידד!"). ב- Swiz משתמשים בשני תגי metadata של ה- framework שהם לא קשורים לאלו המוגדרים מראש בפלקס, וזה הביא לי בסקרנות – האימפלמנטציה, השימוש, אז פתחתי ונברתי מעט בקוד של Swiz ויש לפני את הבשורה.
לפני שאני אפרוש פה קוד, אציין שהשימוש, במתכונת הנוכחית, הוא מעט בזבזני ולא אלגנטי. אני מקווה שבעתיד תהיה אופציה הרבה יותר טובה ליישם את העניין. ובכן, לעסק:
ראשית, בואו רגע נתעכב על ()describeType. המתודה הזו יודעת לקבל אובייקט ולהחזיר אובייקט XML עם כל המאפיינים ה- Public של אותו אובייקט. ה-XML הזה גם מכיל גם את ה-metadata עבור כל מאפיין. יש כמה וכמה כלים לפלקס שבנויים על היכולת הזו. סבבה לנו? למה לא.
עכשיו, בכדי לאפשר את תגי ה-metadata הנוספים מוסיפים ארגומנט לקומפיילר העונה לשם keep-as3-metadta. כך שאם אנחנו רוצים להוסיף metadata בשם flashmattic, נכתוב:
-keep-as3-metadata+=flashmattic
למה =+? כי אנחנו לא רוצים להיות חצילונים ולמחוק את כל מה שכבר מוגדר.
מה שעכשיו קיבלנו הוא, שבכל הגדרה שנכתוב בה את [flashmattic], נקבל את את ערכי ה-metadata ב-XML של ה describeType. את ה metadata נכתוב כמו כל metadata אחר:
[flashmattic]
public var inputTxt:String;
אנחנו יכולים להוסיף גם מאפיינים ל- metadata, כך:
[flashmattic (value=”Matti”)]
public var inputTxt:String;
זה מגניב, אבל לא ממש עוזר לנו. את כל זה יכולנו לעשות גם בלי הטובות של הקומפיילר והארגומנטים שלו. או! אז פה הטעות, שכן מבלי להוסיף את הארגומנט המוזכר לעיל, הקומפיילר לא יודע לקרא את ה-metadata הזה ולהכניס אותו אל הפרטים ב-XML של describeType.
מה שנותר הוא לקרא את הנתונים הללו, להוציא מהם את מה שאנחנו מחפשים וכך, ב runtime נוכל ליישם dependency injection למשל. הנה אמפלמנטציה אחת לדוגמה:
private function resolveDependencies(accessorList:XMLList):void {
for each (var dependee:XML in accessorList) {
if (dependee.metadata != undefined && dependee.metadata.(@name== "flashmattic") != null) {
var meta:XMLList = dependee.metadata.(@name == " flashmattic");
if (meta.arg.(@key == "value") != null && meta.arg.(@key == "value").@value != undefined) {
trace(meta.arg.(@key == "value").@value); // Traces “Matti”
}
}
}
}
לא רע, הא? מה שכן, לכאורה נראה כי הריצה בלולאה על כל המאפיינים עולה בשן ועין בביצועים, אבל לאחר בדיקה קצרה, נראה כי הזמן זניח (16 מילישניות עבור 2 קומפוננטות מקוננות). אני עדיין צריך לבדוק את זה בפרויקטים בעלי נפח יותר גדול.
בכל אופן, מקווה שזה מגניב אתכם כמו שאותי, אחרת אני ממש יוצא פה חננת-מחשבים...
שבוע טוב שיהיה :).
This little thingy drove me insane. That elusive MXMLC (and COMPC) argument, well-known to his fellow arguments as “keep-as3-metada”. If you read the documentation about it (that never loses an opportunity to fail in description), you’ll learn that if you wish to keep your own metadata tags, this is the way to do so. They don’t really say who, where or how to get those details at runtime. We’re left guessing…
To be honest, I first discovered interest in this issue when reading about the “
Swiz” framework. In Swiz there are two extra customized metadata tags involved, and that made me curious about the implementation and usage, so I lifted the hood up and looked under it.
Now, before I give you my resolutions, I must admit that what Swiz is doing is a bit expensive performance-wise. I hope that this way of implementation will be made more elegant in the future of Flex SDK. Well… let’s dive into it:
First of all we want to check out this nice method called “describeType()”. This methods expects an object as its argument, and return an XML object with the details of all public properties in this object. By the way, Many Flex tools rely on this feature. Are we happy so far? Sure we are.
Now, in order to enable extra customized metadata, we need to add the keep-as3-metadata argument to the compiler, so say we want to add “flashmattic” as our new customized metadata, we’ll add the following to the compiler arguments:
-keep-as3-metadata+=flashmattic
Why +=? Cause we don’t want to be complete numb-nuts and override the predefined metadata tags.
What we have now is, whenever we add the flashmattic metadata tag to any public property of an object, the XML retrieved from the descibeType() method will include that metadata and it’s properties. We add the metadata to our like any other metadata in flex:
[flashmattic]
public var inputTxt:String;
We can also add some properties to our metadata tag, so… let’s add a property to our metadata:
[flashmattic (value=”Matti”)]
public var inputTxt:String;
This is nice, right? Yeah, but we could have done this without asking the favors from the compiler and its arguments. Wrong! Not adding the metadata to the compiler, will cause the descibeType() method to avoid it and not have its details to the XML.
What’s left for us is to run trough that XML at runtime, find our metadata and retrieve the information from it. This is highly useful when wishing to implement dependency injection in Flex. Here’s one example:
private function resolveDependencies(accessorList:XMLList):void {
for each (var dependee:XML in accessorList) {
if (dependee.metadata != undefined && dependee.metadata.(@name== "flashmattic") != null) {
var meta:XMLList = dependee.metadata.(@name == " flashmattic");
if (meta.arg.(@key == "value") != null && meta.arg.(@key == "value").@value != undefined) {
trace(meta.arg.(@key == "value").@value); // Traces “Matti”
}
}
}
}
Not bad, ah? Well, apparently, going through that loop looks a bit expensive as I mentioned before, but after running a couple of tests it looks like it will not affect the player that bad (16ms for 2 nested components), but I need to test it on a larger project to make sure that this implementation won’t add to the already bad performer we call Flash Player.
