Where to put processing code for loaded xml resource data

[valley]

Hi there,
i'm quite new to PureMVC and still have some understanding problems between Command and Proxy tasks.
Here is my question:
For an application i have to load two xml config files, which i did with two different Proxy and SimpleCommand extensions.
After everything has been loaded the next step is to extract and process the data from these two xml configs
together, where the result will be stored in VO objects and stored/offered in another Proxy extension.
I have to say that these processing steps is quite a lot of code and will be placed within several functions.
Now where will i have to put that bunch of processing code, in the corresponding SimpleCommand extension class, in the mentioned third Proxy or in an external Singleton helper class (package controller or model ?), that could also be used for similar processing tasks and be used by other commands ?
Or simpler: To what belongs such processing of loaded configs, business or domain logic ?

Thanks for your thoughts.
Best regards
valley

[Jason MacDonald]

I prefer to do this in a Proxy though I guess you could argue for using a command. But to me commands are best used for things that get reused or called from multiple locations.

A Proxy can take the RAW xml as it's data on creation and parse it into a VO. The Proxy then exposes the VO as a property for commands/mediators to access.

[valley]

Hi Jason

thank you! So in my case the processing Command could retrieve the two xml configs (raw or in VO) from the corresponding Proxies and pass them to a third Proxy, where they are finally processed and the results again
are offered as VO's in an ArrayCollection (for example) by that Proxy. Is that right ? So the third Proxy shouldn't retrieve the two xml configs from the other two Proxies directly ?

Regards
valley

[Jason MacDonald]

You can do it either way.

I usually do things a bit differently and have one proxy handle the loading and parsing of of the XML itself. I generally use the StartupManager utility and that way if a Proxy later needs the XML that was loaded previously in another Proxy I can ensure it's ready by making it a requirement. I load a ConfigProxy that has all the XML URL's first, then have each loaderProxy call that Proxy internally to get the URL it is responsible for to start loading and parsing.

In this kind of set-up, the flow goes something like this...

(All this is done using the StartupManagerUtility)
- Load config with urls and expose ConfigVo
- DataXMLProxy1 requests configVO and parses XML... exposing it's VO
- DataXMLProxy2 requests configVO and parses XML... exposing it's VO
- DataProxyFinal has a requirement of both 1 & 2 being completed before executing
- DataProxyFinal runs and asks for DataXMLProxy1 VO and DataXMLProxy2 VO
- once it's done StartupManager executes the LoadComplete.

Hope that makes sense, I'm not the greatest at explaining processes

[puremvc]

VOs are great with services that fetch and persist them, but if it is merely configuration data then there's rarely a need to turn it into VOs in order to efficiently distribute it within the app. 

If you are using AS3, XML is native to the language, and you have incredibly powerful tools for manipulating and querying it on the fly.

Another approach is to skip the VOs altogether, and expose getters on the Proxy which use E4X expressions to return the data needed. Your XML structure can be arbitrarily complex, but pulling out elements with E4X is lightning fast.

So when the Proxy recieves the data it sends a note that interested commands and mediators act upon by accessing getters on the ConfigProxy.

-=Cliff>

[Jason MacDonald]

In my case the ConfigVo's are used by sub Modules and need to be passed via Pipes, so VO's were the way to go. I don't want to pass around Proxy's.

[valley]

Jason & Cliff: Thank you very much for your input!

I'm doing it as follows:

1) By using the StartupManagerUtility the two Proxies load their corresponding XML file and expose it as is
    (so no VO's there). Reason: Querying the XML is definitely less time consuming than VO's, since the XML       
    structure is quite complex.
2) When StartupMonitorProxy.LOADING_COMPLETE arrives, a new notification is send, a new Command catches it,
    and
    a) registers a new Proxy
    b) retrieves the two XML objects from the Proxies at 1) and passes them to the new Proxy for processing them
        there, build a new VO out of it and expose that one to the application.

I guess with that it should work fine and performant.
Best regards
valley

[puremvc]

@jasonmac,

You could just pass the XML in the pipe message. The VO would be one less class that the two modules have to both know.

-=Cliff>

[JJfutbol]

I definitely recommend considering a parser for your XML. If you are dealing with services that you don't build yourself, and regardless of that, they are prone to change. I wouldn't suggest passing XML around as now your app is very tightly coupled to that XML and if it changes... well that gets messy.

At my job we are building a platform so we have lots of RESTful services and rich clients that consume them. By having the parsing for that XML abstracted into its own area and using VO classes its easier to make changes as well as also having strong typing.

[puremvc]

True that. Passing arbitrary XML around
isn't the best idea for a large data model. But use of a schema and normalization of the XML used within the app at the Proxy that reads it in can mitigate maintainability issues.

You can also wrap the XML in a VO but still bypass the messy parsing.
   
For an example of this, have a look at the Flex/AIR
DeploymentConfig utility.

You define your XML configuration and it is read in and stored in a VO which then exposes getters for the values. In the example XML/VO combination, the values are all siblings, but they could be arbitrarily nested.

Another nice thing that is shown is the use of XML namespaces. Since you may deploy to multiple environments (development,staging,testing and production are commonly used) each of which may have its own set of servers, and thus service urls may be different.

You don't want to hard code this info into your app, so you put it in a deployment configuration file and read it in at startup.

But how to tell which environment the app is deployed to and thus which set of configuration info is the problem.
In your XML in the config namespace, is a deploy tag that is required. It contains the name of the deployment namespace, the set of values to pay attention to.

So you put all your values in for each environment in their own namespace. Then you set the config:deploy tag to point to the one your deploying to.

The VO reads the deployment namespace name and creates an AS3 Namespace to match when the XML configuration is set on the VO. In your subclass you write getters that access values on the XML using a combination of the deployment namespace and e4x that gets the desired data from the selected namespace like: config.nsDeploy::myValue.

Yes, there'll be a demo soon, but there is a simple example set of files that you can use to model a test after. I've been using hand tooled variations of this for several years now and it works pretty well. I decided to abstract it and make it reusable.

-=Cliff>