I think this is rather what I was doing, The canvas raises the creationComplete-event and contains info about what children should be instantiated. Then this canvas requests that instance by calling getUIComponent(). This static method is part of a class called UIComponentFactory, a part of my lib. It is UIComponentFactory that connects to a Java-service (I'm thinking RPC would be fit here) and the Java-class that connects with the db, and sends the result back to UICF.getUIComponent(). At that moment, the method instantiates the component and returns it to it's caller (in this case the canvas).
However, if I have a slow db, my user will see a canvas with some hardcoded parts on, that then gradually updates itself to it's final form (as the resulthandlers are getting invoked). Instead of not seeing anything, and then a complete canvas... --Johan --- In flexcoders@yahoogroups.com, "Paul Andrews" <[EMAIL PROTECTED]> wrote: > > I'm not sure having a visual component doing database calls is a good > architecture, though I haven't really gone through your code. > > In an MVC architecture the UI should raise an event. The model should > recognise the event, initiate the DB transfer, on transfer complete you can > raise another event to alert the GUI to update itself or just bind to the > model. > > I suspect that in your case, the canvas should not be responding to creation > complete by trying to initiate the creation of the person for display. On > creation complete, you should ask the model to fetch a person. The model > should then initiate the DB transfer and handle the asynchronous completion > event. On completion, it can either update part of the model with the person > data (and use binding from the GUI to update the display), or raise an event > to alert the GUI to update itself and create the visual for the person. > > Paul
