Right, that turned out to be harder than I anticipated. To get this to work I had to do the following things: - redeclare all event metadata that is declared by the Alert component and its base classes (to be able to use mxml event handlers) - extend EvenDispatcher and relay all events dispatched by the Alert instance - redeclare all style metadata that is declared by the Alert component and its base classes (to be able to use mxml style attributes) - implement IStyleClient (same reason) - cache the styles and assign them to the instance once created - "decorate" all properties exposed by Alert and its base classes (to be able to use mxml properties) - cache the properties and assign them to the instance once created
The resulting delegate class can be found here: https://github.com/RIAstar/SkinnablePopUpFx/blob/delegate/skinnable-popup-fx/src/main/actionscript/net/riastar/components/AlertDelegate.as You can play around with the compiled result here: http://riastar.github.io/SkinnablePopUpFx/ I didn't decorate all of the properties/styles/events (just the ones to get the demo working), but the resulting code is already bigger than the Alert class itself :( So I'm not so sure if it's still such a great idea. To be complete you'd have to wrap every property, style and event of SkinnableComponent and UIComponent, and there are a lot of them. And we're not even talking about methods: suppose someone wants to call `alert.addElement(someElement)`... Of course this is good old Flex 4; perhaps this can be solved another way in FlexJS? Max On Sat, Jun 8, 2013 at 9:13 PM, Maxime Cowez <maxime.co...@gmail.com> wrote: > @Carlos: Interesting idea. I had already created a Flex 4 implementation > of PopUp / Alert that can be used in a declarative way (see > https://github.com/RIAstar/SkinnablePopUpFx). I'll see if I can tweak it > to leverage your idea; don't think it should be too hard. > Max > > > On Sat, Jun 8, 2013 at 4:30 PM, Carlos Rovira <carlosrov...@apache.org>wrote: > >> 2013/6/8 Alex Harui <aha...@adobe.com> >> >> > >> > Good point, we forgot about that. It might be possible to use includeIn >> > to defer its instantiation or add some other attribute that works like >> > that but isn't tied to states. >> > >> > >> So from your response seems you're thinking in a state implementation >> similar to what we have today in flex 4, isn't it? >> >> Regarding deferred implementation maybe the proposal could be something >> like a value object that holds all config properties of the alert dialog >> (this will be the example posted by Peter) and the "show" method will be >> the one that unchains the process of create the UI Object through a static >> method. So all alerts VOs will be only a proxy that are very light weight >> and only it will pay as you go when calling "show" through delegating the >> work to the class that generates the fat UI object. >> > >
