the xml seems the have disappeared, so I have no idea what is going on. Please join our forum at http://forum.springframework.org/forumdisplay.php?f=60 and repost your question there.

thx,
Christophe

service = CairngormServiceLocator.getInstance().getRemoteObject(“bgwpmMetadateService”);
and my xml

Any idea to solve this issue?

Thanks,
karthik

it depends on what you see as blocking the UI. If you are firing a remote call that will load a big chunk of data, then I think it is perfectly acceptable to show a loading screen which informs the user and at the same time prevents the UI from being used.

About object reusability: I’m not sure if we should see commands and delegates as singletons. As you say, you would have to alter the interfaces so that responders can be passed in to the delegate methods. I think that a event/command/delegate sequence should really be handled by some sort of a factory mechanism that creates a new command and delegate each time. I don’t think performance will be an issue here. That way the concurrency problems would also be solved.

I like discussing this with you (and others). Would you mind subscribing to the mailinglist – if you haven’t already – so we can also get input from other developers? Thx for your time and interest! https://lists.sourceforge.net/mailman/listinfo/prana-user

What is not clear to me using cairngorm/prana is which objects are meant to be reused and which one are not. In order to keep performance to the maximum, I guess that it would be nice to have the command and business delegates as singletones (this is btw coherent with the patterns used in spring). They do not need to keep any state. Besides, defining more than one method on a business delegate will need to set, through a property or through constructor, a lot of delegates. In my opinion is much simpler to accept a responder as argument of the business delegate call (altough it clutters the interface). It will solve all the concurrency problems and make more explicit how the result will be handled.

that would indeed be a problem. This approach hence needs to be used when you can make sure only 1 call to the delegate will be made, for instance by disabling the UI until the response is received.

The best thing would be to have a delegate factory that is configured and stored in the modellocator and is then used inside the command to create a new delegate every time you need one.

var delegate:IProductDelegate = ShopModelLocator.getInstance().productDelegate;
delegate.responder = this;
delegate.getProducts();

If the user is hyperactive and clicks on several buttons calling the product delegate he will overwrite the responder property, causing some actions not to be executed properly!

please see the nightly builds at http://prana.herrodius.com/

regards,
Christophe

i’ve connection problems to your svn. Could you add a download link here? Thanks Hagen