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: Passing data to FSMs to reuse commands  (Read 12858 times)
LuisHerranz
Newbie
*
Posts: 3


View Profile Email
« on: December 10, 2013, 10:33:11 »

Hi everybody!

We are in the design phase of a project and we have a download sequence. We want to use a FSM for that. It would be something like this (this is only an example):

<fsm initial="CHECKING_CONNECTION">
   <state name="CHECKING_CONNECTION" changed="CHECK_CONNECTION">
      <transition action="CONNECTION_AVAILABLE" target="DOWNLOAD_SETTINGS_FILE"/>
      <transition action="CONNECTION_UNAVAILABLE" target="CHECKING_CONNECTION"/>
   </state>
   <state name="DOWNLOAD_SETTINGS_FILE" changed="DOWNLOAD_FILE">
      <transition action="DOWNLOAD_COMPLETE" target="CHECKING_DATES"/>
   </state>
   <state name="CHECKING_DATES" changed="DOWNLOAD_FILE">
      <transition action="NEW_CONTENT_AVAILABLE" target="DOWNLOAD_CONTENT_FILE"/>
      <transition action="NO_NEW_CONTENT" target="RENDERING_SCREEN"/>
   </state>
   <state name="DOWNLOAD_CONTENT_FILE" changed="DOWNLOAD_FILE">
      <transition action="DOWNLOAD_COMPLETE" target="RENDERING_SCREEN"/>
   </state>
   <state name="RENDERING_SCREEN" changed="REFRESH_SCREEN">
   </state>
</fsm>

Our problem here is: how do we reuse the same command (commandDownloadFile) to download both the Settings file and the Content file.

Our only idea right now, would be to include that info in the own FSM. Something like this:
   <state name="DOWNLOAD_SETTINGS_FILE" changed="DOWNLOAD_FILE" data="{ file: settingsFile.json }">
      <transition action="DOWNLOAD_COMPLETE" target="CHECKING_DATES"/>
   </state>
   <state name="DOWNLOAD_SETTINGS_FILE" changed="DOWNLOAD_FILE" data="{ file: contentFile.json }">
      <transition action="DOWNLOAD_COMPLETE" target="CHECKING_DATES"/>
   </state>

This is only an example to show a way we could solve it. Not sure how you should "add the data" to the xml FSM, but if something like that is supported, it would definitively allow us to reuse the commandDownloadFile.

Right now this is obviously not supported, so... how should we solve this? Could "adding data to the FSM" be a good/recommended way to solve these cases? Any drawback?

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



View Profile WWW Email
« Reply #1 on: December 10, 2013, 10:48:39 »

Register the same command to two different notifications. Inside the command, check the notification name to decide what file to download.

Cheers,
-=Cliff>
Logged
LuisHerranz
Newbie
*
Posts: 3


View Profile Email
« Reply #2 on: December 11, 2013, 02:40:54 »

Thanks for your answer Cliff.

I understand your approach, but...

The main advantages I see are in the other approach are:
- You can have a clean, simple, commandDownloadFile without any magic "switchs" and "ifs". 100% reusable.
- You don't need X different notifications, just one (DOWNLOAD_FILE).

In a small software where commandDownloadFile is used only twice, it makes total sense. But what about a larger software with hundreds of files?

Do you see any drawback following this practice? Any case that may run into problems?

Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #3 on: December 11, 2013, 07:20:38 »

You can already pass data between States. When sending a StateMachine.ACTION notification, you may include any Object as the body of the notification and it will be included in the state-specific 'exiting', 'entering', and 'changed' notifications. This allows, for instance, the data collected from a UI form in the 'DATA_ENTRY' state to be passed to the 'DATA_SAVING' state when the form's 'Save' button is pressed.

That might help or it might not. But I'd still declare the files to be loaded elsewhere, perhaps in a Proxy. And I'd locate the downloading code in the Proxy as well. The Command, should be able to look at the state and make the appropriate call to a given proxy.

Are you really downloading hundreds of files? Do you really expect this Command to be expanded to do that? If not, then I'd not try to constrain the architecture to doing what is needed now and in the foreseeable future. You don't want to preclude things, but you also can't code for every eventuality (and hit deadlines). Sometimes you have to do what makes sense for the planned usage, then refactor when and if things change.

In short, no, I don't think I'd make an on-the-spot modification of the FSM when there are other obvious ways to allow the Command to know, based on the new state, what it needs to do.
« Last Edit: December 11, 2013, 10:43:32 by puremvc » Logged
LuisHerranz
Newbie
*
Posts: 3


View Profile Email
« Reply #4 on: December 12, 2013, 02:28:53 »

Hi Cliff,

I was not asking you to implement that feature. I'm sorry if I wasn't clear enough. We are still trying to learn and we had a doubt about if "our method" would be correct or not, regarding software design. Maybe in another language, maybe in another framework :)

Many thanks for your help. We will do as you indicate.

All the best,
Luis.
Logged
puremvc
Global Moderator
Hero Member
*****
Posts: 2871



View Profile WWW Email
« Reply #5 on: December 12, 2013, 08:46:37 »

No, no, sorry, Luis.

I wasn't saying I personally refused to make the change. I was just saying my advice to you was not to modify the FSM, but to either a) pass the data through from whatever actor sends the note to make the state change, b) to have the command look at the note name and decide what file to download, or c) define those filenames in a different place, perhaps hardcoded in a Proxy, or in an XML file a Proxy reads, so that the command can invoke a method with a key to a map that the Proxy uses to figure out what file to download.

You're certainly free to modify the source code and do what you like, that's the beauty of Open Source. However, I've just seen in the past that usually, that's not the best option, and left as a last resort if there is absolutely no other way you can do the thing.

Cheers,
-=Cliff>
Logged
Pages: [1]
Print