Scroll down for English translation...
אהלן, מה קורה?
האמת שהיה לא רע כל כך, עד שנתקלתי בעובדה פלקסאית חדשה שמעט ערערה אותי.
אתם מבינים, אני לאחרונה חופר מעט ב-Spark, בקטע של "need to know basis". מה שאני צריך אני בודק, בלי לפתוח אתר ארכיאולוגי. ת'כלס עניין אותי הכפתור החדש, מה קוראים אותו s:Button.
העובדה הראשונה שמטרידה את עבדכם הנאמן היא העלמות הפתע של המאפיין הנחמד icon. כמה קל זה היה להצמיד אייקון לכפתור? בלי בעיות ובלי נעליים, שים את האייקון על הטאג וסגור עניין. אז זהו, שלא עוד. אז מה עושים?
או! מכיוון שהכל ב- SDK 4 הוא מכוון Skins and Styles, מהנדסי אדובי החליטו שגם את האייקון ל Button החביב יגדירו ב Skin. על פניו, החלטה נכונה, הגיונית ויושבת טוב עם כל האינטגרציה שהם עושים עם Catalyst, אמה-מה? זה אומר שלכל כפתור שאני רוצה לתת בו אייקון, אני צריך לבנות Skin.
שמעתי נכון? לכתוב סקין לכל כפתור שרוצה אייקון? זה אבסורד. תחשבו, שכאשר תבואו לשדרג את ה SDK של הפרוייקט הקרוב לביתכם, כל כפתור נושא אייקון, יצטרך עכשיו סקין אישי. לפני שנאמר דבר בנושא, ולפני התחכמויות - גרוע.
אז לא. באים המתחכמים ואומרים, עשה לך Class אשר יורש מ- Button, ופתח API להגדרת האייקון שנמצא עליו. במילים פשוטות - תכתוב את ה Button הישן של mx, רק עם המאמבו-ג'אמבו של Spark.
שוב, שמעתי נכון? למה?! אני מבין את הרעיון לאפשר את הגמישות הזו, אבל מה המחיר, אדובי? כבר עכשיו צצות להן כל מיני קומפוננטות שמרחיבות את Button, שכל יעודן הוא לאפשר הצגת אייקון על כפתור. אתם יכולים לדמיין לעצמכם את האנדרלמוסיה הגרסאתית שנוצרת פה? איך קומפוננטה כל כך בסיסית הופכת למשהו שהוא קאסטומאלי ולא חלק מהפריימוורק של פלקס?
הגמישות פה אכן משחקת תפקיד מפתח, כי אם בעבר אייקון על כפתור נראה ומוקם בצורה מאד מסויימת, היום אין קץ ליצירתיות, אבל לדעתי היום צריכים לשמר את הפונקציונאליות הבסיסית כחלק מהקומפוננטה.
אני לא יודע כמה מכם כבר נחשפו לעניין, אבל בתור מפתח פלקס (ותיק, אם יורשה לי) אני מוצא את הרעיון כ- overhead רציני, ועוד נקודה טובה עבור המקטרגים על פלקס. משהו שאני עוד צריך ללעוס, אבל בינתיים, סאחבק לא מרוצה.
סופ"ש רגוע שיהיה...
האמת שהיה לא רע כל כך, עד שנתקלתי בעובדה פלקסאית חדשה שמעט ערערה אותי.
אתם מבינים, אני לאחרונה חופר מעט ב-Spark, בקטע של "need to know basis". מה שאני צריך אני בודק, בלי לפתוח אתר ארכיאולוגי. ת'כלס עניין אותי הכפתור החדש, מה קוראים אותו s:Button.
העובדה הראשונה שמטרידה את עבדכם הנאמן היא העלמות הפתע של המאפיין הנחמד icon. כמה קל זה היה להצמיד אייקון לכפתור? בלי בעיות ובלי נעליים, שים את האייקון על הטאג וסגור עניין. אז זהו, שלא עוד. אז מה עושים?
או! מכיוון שהכל ב- SDK 4 הוא מכוון Skins and Styles, מהנדסי אדובי החליטו שגם את האייקון ל Button החביב יגדירו ב Skin. על פניו, החלטה נכונה, הגיונית ויושבת טוב עם כל האינטגרציה שהם עושים עם Catalyst, אמה-מה? זה אומר שלכל כפתור שאני רוצה לתת בו אייקון, אני צריך לבנות Skin.
שמעתי נכון? לכתוב סקין לכל כפתור שרוצה אייקון? זה אבסורד. תחשבו, שכאשר תבואו לשדרג את ה SDK של הפרוייקט הקרוב לביתכם, כל כפתור נושא אייקון, יצטרך עכשיו סקין אישי. לפני שנאמר דבר בנושא, ולפני התחכמויות - גרוע.
אז לא. באים המתחכמים ואומרים, עשה לך Class אשר יורש מ- Button, ופתח API להגדרת האייקון שנמצא עליו. במילים פשוטות - תכתוב את ה Button הישן של mx, רק עם המאמבו-ג'אמבו של Spark.
שוב, שמעתי נכון? למה?! אני מבין את הרעיון לאפשר את הגמישות הזו, אבל מה המחיר, אדובי? כבר עכשיו צצות להן כל מיני קומפוננטות שמרחיבות את Button, שכל יעודן הוא לאפשר הצגת אייקון על כפתור. אתם יכולים לדמיין לעצמכם את האנדרלמוסיה הגרסאתית שנוצרת פה? איך קומפוננטה כל כך בסיסית הופכת למשהו שהוא קאסטומאלי ולא חלק מהפריימוורק של פלקס?
הגמישות פה אכן משחקת תפקיד מפתח, כי אם בעבר אייקון על כפתור נראה ומוקם בצורה מאד מסויימת, היום אין קץ ליצירתיות, אבל לדעתי היום צריכים לשמר את הפונקציונאליות הבסיסית כחלק מהקומפוננטה.
אני לא יודע כמה מכם כבר נחשפו לעניין, אבל בתור מפתח פלקס (ותיק, אם יורשה לי) אני מוצא את הרעיון כ- overhead רציני, ועוד נקודה טובה עבור המקטרגים על פלקס. משהו שאני עוד צריך ללעוס, אבל בינתיים, סאחבק לא מרוצה.
סופ"ש רגוע שיהיה...
Hey, How's it going?
To be honest, I wasn't that bad until I bumped into a Flex fact which shook be a little bit.
You see, I'm lately lightly digging in Spark, in the "need to know basis". What I need I check out, with out opening an archeological site over it. Bottom line, I was interested in the new Button offered by Spark, what you call s:Button.
The first fact that disturbs me is the sudden disappearance of the "icon" property on the Button. How easy was it to just place an icon on a button, right? No trouble there mate, put it on the tag and there you go. So that's it for that. No more. So what do we do?
Right! Since everything in the new Flex SDK 4 is Style and Skin oriented, Adobe engineers decided that the button icon should be defined in a skin. On the surface it looks like the right thing to do, that sits well with all the Catalyst integration, BUT is means that for each button with an icon I need to create a custom skin.
Did I hear right? Write a skin for each button that needs an icon? This is absurdity. Think, when you come to upgrade your nearby project, every button that has an icon on it will need a new skin now. Before anything is said - this is bad.
So wait! No. Developers come and say "hey! Make yourself a Class that inherits Button and enable and API to define the icon that is on it". In other words - write the same old mx:Button only with the Spark component definitions.
Again, did I hear right? Why?! I understand the idea of enabling this flexibility to the components, but for what cost. Adobe? Even as we speak, extended component are emerging , that extend the Button component, destined to enable the displaying an Icon on the button easily. Can you imagine the version mess that is being created? How come that such a very basic component is something that is custom made and not part of the framework?
Flexibility does play a key roll here, cause if in the past the icon on the button would be place in a certain manner, today you can really go far with what can be done, but in my opinion, the basic functionality should have been kept as part of the component.
I don't know how many of you were exposed to this matter, but as a Flex developer (senior, if I may) I find the idea as a major overhead, and yet another good point for all of these that talk trash about Flex out there.
This is something I still need to chew on, but in the meantime - yours truly is not happy at all.
Have a good on...
To be honest, I wasn't that bad until I bumped into a Flex fact which shook be a little bit.
You see, I'm lately lightly digging in Spark, in the "need to know basis". What I need I check out, with out opening an archeological site over it. Bottom line, I was interested in the new Button offered by Spark, what you call s:Button.
The first fact that disturbs me is the sudden disappearance of the "icon" property on the Button. How easy was it to just place an icon on a button, right? No trouble there mate, put it on the tag and there you go. So that's it for that. No more. So what do we do?
Right! Since everything in the new Flex SDK 4 is Style and Skin oriented, Adobe engineers decided that the button icon should be defined in a skin. On the surface it looks like the right thing to do, that sits well with all the Catalyst integration, BUT is means that for each button with an icon I need to create a custom skin.
Did I hear right? Write a skin for each button that needs an icon? This is absurdity. Think, when you come to upgrade your nearby project, every button that has an icon on it will need a new skin now. Before anything is said - this is bad.
So wait! No. Developers come and say "hey! Make yourself a Class that inherits Button and enable and API to define the icon that is on it". In other words - write the same old mx:Button only with the Spark component definitions.
Again, did I hear right? Why?! I understand the idea of enabling this flexibility to the components, but for what cost. Adobe? Even as we speak, extended component are emerging , that extend the Button component, destined to enable the displaying an Icon on the button easily. Can you imagine the version mess that is being created? How come that such a very basic component is something that is custom made and not part of the framework?
Flexibility does play a key roll here, cause if in the past the icon on the button would be place in a certain manner, today you can really go far with what can be done, but in my opinion, the basic functionality should have been kept as part of the component.
I don't know how many of you were exposed to this matter, but as a Flex developer (senior, if I may) I find the idea as a major overhead, and yet another good point for all of these that talk trash about Flex out there.
This is something I still need to chew on, but in the meantime - yours truly is not happy at all.
Have a good on...
No comments:
Post a Comment