Thanks for the quick response- just one more thing...

What if that manager needed to get a value from a proxy ?

Simply retrieve the facade via the Facade.getInstance() property and get the proxy that way, still in the managers package - or now that its tied into mvc should we place the class elsewhere ?

cheers

m.

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.

Thanks for the reply,

We are just packaging classes for convenience as we are using them more and more in various apps we build - they may be used by 3rd parties when outsourcing work.

I was thinking about adding the puremvc node as we have other generic utilities / classes that are not built round a framework -just simple ui components, Number / Date utils etc that we re use.

These are currently
com.domain.ui.*
com.domain.utils.*
com.domain.air.*

etc

And thought it would be good to distinguish between them, but I see your point about removing it, and it helps with the original issue of ending up with uneccisasarily long package names!

Never thought coming up with package names could be quite so in depth!

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,  I'm embarking on an similar app that will have multiple data sources of varying types which will expand in the future. Data will come from feeds and services such as RSS, ATOM, SOAP as well as some bespoke APIs. 

It will have many available services for the user to enable, but only a limited number can be enabled.

I was wonder what would be the best way to structure it, I was thinking something along the lines of..

Sources Definition / storage
A OPML file that defines all the possible services with url, title, poll interval, type and an enabled flag to indicate that this service is currently in use.

Then we can easily read/write/update this single file to change the sources.  I think storing this in a SQLite db would be overkill??  No relational data really and would be harder to update.



AS structure
A OPMLProxy to mange loading and saving of the main OPML file.

An interface IServiceProxy that defines the basic methods startPoll(), stopPoll(), pollNow(), parse() etc Or maybe an abstract that defines some more properties and private methods.

A Service class for each type of service - RssServiceProxy, AtomServiceProxy, MyApiServiceProxy -each will define parse in which ever way it needs to to extract the data required.

A ItemVO per service, RssItemVO, AtomItemVO, MyApiItemVO

The parse method of the Service class will parse to an ArrayCollection of VO's for that service.  I.e RSSServiceProxy's data will be an ArrayCollection of RSSItemVO's.


An overall SerivicesProxy that has methods such as addService( service ), removeService( service  ), hasService( url) that holds all the currently created services with some methods to retrieve them with some filtering perhaps getServicesByType( serviceType ) 


The basic set up would be load the OPML, retrieve all the enabled sources, for each instantiate an ServiceProxy based on its type (rss, atom, myApi etc), pass in a custom name for the proxy as we will have multiple instances of the same proxies as well as passing url, interval etc.  Then add this instance to the main ServicesProxy  and start polling it.


Does this sound ok?   Is there another way without having multiple instances of the same proxies - (although i don't see this as a bad thing)

And where should the timing code that actually triggers a poll for each service live?  Should this live in each ServiceProxy  - the startPoll() method would create the timer for that service within the proxy (based on its individual interval value from the OPML) and obviously send a note once the data is polled a parsed.

Each service proxy would hold all the items from the last poll, the overall ServicesProxy could have methods to get everything - returning an arrayCollection containing all items from all services.

Any feedback / pointers would be much appreciated.

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.