[ragel-users] First FSM - is my approach correct?

[Adrian Thurston]

Hi Nick, it doesn't seem that what you want to do maps to the FSM model.
I think it might be more productive to bang out a mini version of this
without using ragel and then it might become clear if there is any
benefit at all to using ragel.

Adrian

Nick C wrote:
> Hi,
> 
> I would like to use Ragel to build a couple of FSMs based on the same
> machine definition, one handling data validation, and another to
> construct an interface (this would be the first time I use either
> Ragel or FSMs). The data causing state transitions will probably be
> passed in as key-value pairs. The validity of some keys depends on the
> values set for others; so for instance, if a user chooses
> "PublicTransport" as the value for the "FavouriteModeOfTransport" key,
> he will be able to choose from "Bus", "Metro", "Tramway" as possible
> values for the "FavouriteModeOfPublicTransport" key, but if he chooses
> "Motorbike" as the value for "FavouriteModeOfTransport", he won't be
> able to enter a value for "FavouriteModeOfPublicTransport" (validation
> would fail in the data validation routine, and the field wouldn't be
> displayed on the front end). There will be 40-50 different possible
> fields, out of which around 15 or so would be dependent on the values
> chosen for other fields. I can't guarantee the ordering of the keys,
> although I can guarantee that the "FavouriteModeOfPublicTransport" key
> would always be set after the "FavouriteModeOfTransport" key.
> 
> I was thinking as implementing this as a scanner, using conditions to
> determine whether the field is valid or not (for instance, the
> "FavouriteModeOfPublicTransport" field would only be valid if a
> "FavouriteModeOfTransport" field has already been supplied with the
> value set to "PublicTransport"). The disadvantage is that the full set
> of state transitions isn't purely defined in Ragel, which potentially
> makes the FSM hard to read (though if I'm correct defining the
> possible states for 15 conditional fields in Ragel would require 15^15
> different state definitions, which would probably be worse).
> 
> Do you think this approach would work? Am I missing a better way of
> doing this?
> 
> Thanks,
> Nick
>