If you had some custom implementations of flex managers in your application, where would you store them....

Outside the mcv strucutre....

:

com.mydomain.myapp.managers.MyCustomManagerImplementation
As this manager updates external data - would it live in the model..

:

com.mydomain.myapp.model.managers.MyCustomManagerImplementation
It's multicore as well, and could be used by any core so would it be in ...

:

com.mydomain.myapp.common.model.manager.MyCustomManagerImplementation

Any thoughts would be appreciated

m.

Hi, I need some architecture advice re persisting data and parsing to VO's via some proxies..

We have an Air app that polls web services, and creates messageVO's of the items that are returned.

We are now looking to add some persistence of data, so storing read/unread states etc.

First thoughts are to create SQL db, store a table of Services, and table of Messages with states such as read/unread and message data so they can be read offline etc.

The issue is - when should this be read/written to?

The app boots, load up all the messages and parses them to VO's.  If a VO's "read" property is set to "true", we also update the DB at the same time.

However, if we search the DB for all unread messages, we then need to parse the results again. Effectively duplicating all of the VO's. The original VO's would not reflect the new states - and we have 2 VO's for the same data source.

Ideally, we need to somehow query the database for the items, but then return the already existing VO's from the proxy - the proxy could match results from the DB recordset to the VO ids, but that just feels a little clunky. Or it could replace the VO in the arrayCollection in the proxy, but this still leaves the original hanging around, and any view running off the origional VO would no longer be updated as the new VO changes.

We could get the proxies to do all the searching within their data and not use the DB at all, that wouldnt be as powerful, or as fast probably - and we may as well just save all the data as XML, parse on app boot and persist on shutdown and do away with the SQL db all together.


Does anyone have any thoughts / suggestions.

m.

Hi,

We have a few classes that we are using over and over so im moving them into re-usable utilities.

And I was wondering what the best way to package them would be ?

For example take a class to do with web services.

As part of an application it would be

com.domain.appName.model.ServicesProxy

However, if we moved this, and a collection of other related classes to a resuable utility - how should we package it?

com.domain.puremvc.webServices.model.ServicesProxy   ?
com.domain.puremvc.utilities.webServices.model.ServicesProxy   ?
com.domain.puremvc.as3.multicore.utilities.webServices.model.ServicesProxy   ?


Any sugestions  / examples would be great.

cheers.

m.

Hi, we have just started with FLex and PureMVC and we are have come across an issue regarding registering mediators to states of a component.

An MXML component has various states.  Each state is another MXML that is wrapped in an AddChild tag.  Each state component contains buttons, input fields, labels etc and has properties that are binded to the labels, tooltips etc.

A Mediator is instantiated for the main component and registered with the facade.
Each state component has a mediator who's constructor sets the binded properties.

The issue we have is WHEN should register the mediators for each state.?

If we register the mediator for each state view at the same time as we register the mediator for the main component we get null object reference errors at run time.  I'm not sure of the null object is the the state, or the binded properties within the states view.

The way we have got round it is to wait for the "creationComplete" event of each state component to fire, then send that to the Main component mediator. 

This then sends a note to trigger a command that will register the appropriate mediator for the state component that has just loaded.

However we end up with an extra command that checks the note for which state view has just loaded and then register its Mediator and send a note to set the binded properties for the labels etc in the view.


I was wondering if we are missing something, is there a way to register these mediators without having to have the creationComplete events and extra commands to handle them?


Should we simply have the "creationComplete" event trigger a handler in the mediator that then registers its mediator and NOT have a command that does this?

Is there a totally different approach?


I can post some examples if that is needed.

Thanks in advance, Matt.