On 6/7/13 3:00 PM, "Carlos Rovira" <carlos.rov...@codeoscopic.com> wrote:
>Hi Peter, > >how this will show up? calling "foo.show()"? > >I use to like this kind of UI Object declaration, but in this particular >case a problem I'm seeing is that we will generate the Alert although it's >not called by the user, isn't it? (calling Alert.show() in the old way was >generating the object at runtime). 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. > >2013/6/7 Peter Ent <p...@adobe.com> > >> Hi, >> >> I'm currently working on the Alert dialog for FlexJS. Alex and I have >>been >> discussing options regarding event handling from the Alert dialog which >> could provide a pattern for future dialogs. We thought it would been >>good >> to get some opinions. >> >> In Flex you normally post an Alert dialog using Alert.show() and pass >>it a >> closeFunction. The returned Alert instance can be used to listen for >>events >> for whatever else you want to do with it. The closeFunction is optional >>as >> you can also listen for events. >> >> We thought of these possibilities: >> >> Events: make the FlexJS Alert work the same - create an Alert instance >>and >> then listen for events. >> >> Delegate pattern: register an object (probably the instance that is >> posting the Alert) as a delegate and implement one or more callbacks. >>This >> is how you would do it in iOS, for example. >> >> Declare in MXML, something like this: >> >> <fx:Declarations> >> <basic:Alert id="foo" title="Panic" message="Yowza!" ok="doSomething()" >> cancel="doSomethingElse()" /> >> </fx:Declarations> >> >> These are not mutually exclusive by any means. >> >> Thoughts? Preferences? >> >> Peter Ent >> Flex SDK Team >> Adobe Systems >> > > > >-- >Carlos Rovira >Director de Tecnología >M: +34 607 22 60 05 >F: +34 912 94 80 80 >http://www.codeoscopic.com >http://www.directwriter.es >http://www.avant2.es
