Futurescale, Inc. PureMVC Home

The PureMVC Framework Code at the Speed of Thought


Over 10 years of community discussion and knowledge are maintained here as a read-only archive.

New discussions should be taken up in issues on the appropriate projects at https://github.com/PureMVC

Pages: [1]
Print
Author Topic: Retrieving URL data for use in a command  (Read 10978 times)
lizardruss
Newbie
*
Posts: 9


View Profile Email
« on: September 19, 2007, 06:58:49 »

Hi!

I have the following scenario and haven't found any examples where this is done.

I have an account management application that sends out emails to users to confirm registration. In this email is a link to the account management application with an encrypted token used to verify that the user received the email.

The user uses this link to open the flex application and log in. Based on the account status, the flex application gets a signal telling it that the registration needs to be confirmed.

I wanted to get suggestions on how to implement this with puremvc and have the responsibilities in the right place.

Here's what I'm planning so far:
  • AccountProxy receives signal from the server and sends a notification.
  • ApplicationMediator reacts to the notification, getting the email token from the mx.core.Application.application.parameters Array.
  • ApplicationMediator sends a new "confirmRegistration" notification with the data needed to confirm the registration.
  • ConfirmRegistrationCommand reacts to the "confirmRegistration" notification and either calls the AccountProxy to confirm registration with the server, or if the email token isn't set (the user didn't use the email link to log in) sends notification to display a message to the user.

Something about it just seems odd, since the ApplicationMediator is involved only to pick up data needed to confirm the registration. Any suggestions on a cleaner solution?

Thanks!
Russ
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #1 on: September 19, 2007, 09:36:02 »

You might eliminate the ApplicationMediator if you're accessing the parameters from Application.application.

Just have a Command answer the first notification from the AccountProxy. It needs to see if the token is present in the parameters, and if not, alert the user.

You might even go as far as to send the user a link and the token standing alone. So if they didn't follow the link, they could just key in the token. Maybe they popped the email with their blackberry and can't follow the link on the public computer in the airport lounge or something.

So the Command could use the Flex PopupManager to popup a custom dialog to collect the token.

Either way, the Command gathers the token and sets it on the AccountProxy, who has a setter for that property that makes the confirmation service call with the token.

-=Cliff>
Logged
lizardruss
Newbie
*
Posts: 9


View Profile Email
« Reply #2 on: September 19, 2007, 09:35:21 »

Thanks for the quick response.  I came up with an alternative solution that's pretty clean.

For those that are interested, here's an explanation.

First, I've been using mx.rpc.IResponder implementations to handle remote service responses. To make these implementations useful to puremvc they extend the framework provided Notifier object.

Second, I created a URLParametersProxy. URL parameters, like any other data in an application are a model. After realizing that it was an easy decision on where to put & how to get the parameters.

Last, I moved the logic of deciding whether to confirm the user's registration or show an error message to the IResponder implementation. Since the Responder has a reference to the Facade, I can get the email token via the URLParametersProxy. At that point its a simple matter of either calling the AccountProxy to confirm the registration, or sending a notification to show the error message.

This eliminates a number of objects and moves the logic of how the remote service is interacted with back into its Proxy.

Thanks again for the framework, its been a pleasure to work with so far.
Logged
Pages: [1]
Print