PureMVC Architects Lounge

Hi guys,

I have a fairly sizable portal architecture built with pureMVC and I'm working on the deep linking section and trying to figure out "where" to put some logic.

I get a notification that the page has changed and I need to parse the url parameters and store them in a proxy and then determine if I need to go to a new "page" in the system or if some url parameters changed e.g. a new video needs to be loaded.

The parsing of the url parameters needs to involve two proxies since one proxy has the list of parameters that are valid and the other proxy stores a hashmap of the results.  It seems that this code could go in a command like a URLParameterParserCommand but that just seems "not quite right" to me, mediators are for managing views and proxies should do business logic, so I'm back to "should a command do it?".

the other thought is to add it to the proxy and have the proxy do the parsing since the command is doing the business logic that determines the parsing should be done.

any thoughts would be appreciated :)

This sounds like a job for a command to me.

Commands are for business logic, proxies are for domain logic. There is a difference. The former deals with the rules for the application's behavior while the latter is concerned with maintaining the integrity of the domain model that the application is interacting with.

It would be most sensible to put the url parsing in a command.

-=Cliff>

thanks for the feedback,

So that led me to create a "parseURLSegments" method to my command.  The reason I did this is if I send a notification to have another command do this, then the primary command can't complete all its business logic until the URLSegmentParsingCommand had completed its job and I find I end up in a "daisychaining" command cycle which although it works, its quite complex to follow when you are later doing maintenance.

lets say I have the following

PageChangeCommand - Fired as a result of a swfObject event, decides if the page really changes, and then has to parse the url arguments and store them so they can be sent to appropriate modules.

If its "all" self contained here, it works great, however if I was to break to up amongst commands



PageChangeCommand - Fired as  a result if SwfObjectEvent, figures out if the page changed and then fires a "parseURLArguments" notification, also needs to set a state on a proxy to say "we are changing pages, we just don't have all the data we need yet"

ParseURLCommand - parses the URL segments and stores them in a hashmap, then fires a "urlSegmentsParsed" notification

UrlSegmentsParsedCommand - checks the proxy to see if a page change was in progress, and checks to see the url segments are parsed, and now says 'ok' we'll actually change pages.


Which way would you go, or do you have another solution ?

hi guys,
I am doing a similar thing with my app.
I'm Using a command to parse config xml which contains site url and other paths.

Once the xml has been parsed, where should i be storing the config data?
Inside a proxy? Or inside a static class from which the proxy's grab the url when doing requests?

cheers

hi guys,
I am doing a similar thing with my app.
I'm Using a command to parse config xml which contains site url and other paths.

Once the xml has been parsed, where should i be storing the config data?
Inside a proxy? Or inside a static class from which the proxy's grab the url when doing requests?

cheers

I parse my configs into value objects on a proxy.

I parse my configs into value objects on a proxy.

What is the advantage in doing this, opposed to using a static class (e.g Config.as) and calling Config.SITE_URL to retrieve the URL?

If the data is stored in a proxy, it means each time config data is required, the proxy has to be retrieved first. Seems overkill for simple constants like site URL which won't change.

Correct me if i'm wrong.

You can just respond to the page change by immediately parsing the segments into a VO, then store in a proxy, which fires off the note that there's a new URL to organize the app around. No need to break into all these steps.

And I'd put this in a Proxy. If other proxies need it they retrieve that proxy to get the info.

-=Cliff>