http://ayende.comAyende @ RahienCopyright (C) Ayende Rahien 2004 - 2021 (c) 202660Nice, thanks for letting me know http://ayende.com/3342/simple-state-machine#comment10http://ayende.com/3342/simple-state-machine#comment10Wed, 25 Jun 2008 20:58:05 GMTI'm using Rhino DSL in a migrations open source project that a friend and I are working on. I made a blog post about the first thing I used Rhino DSL to do: manage the configuration of different environments in a settings file. http://nathan.whiteboard-it.com/archive/2008/06/24/settings-dsl.aspx http://ayende.com/3342/simple-state-machine#comment9http://ayende.com/3342/simple-state-machine#comment9Tue, 24 Jun 2008 20:14:05 GMTIt might not be so obvious because state machine in ECO is part of the UML model and requires some background in ECO Framework. But in a short: 1. You create a model. 2. You define an attribute of a class that keeps current state. 3. You define (in UML) states, transitions, guards, effects etc. 4. You use state it in code. Like so: order.Approve() - changes statues to Approved (if guards allow doing so). The idea: all is defined on the UML diagram and uses Model Driven Architecture. http://ayende.com/3342/simple-state-machine#comment8http://ayende.com/3342/simple-state-machine#comment8Thu, 05 Jun 2008 05:09:27 GMTI stopped reading when I saw how many steps you need to perform there http://ayende.com/3342/simple-state-machine#comment7http://ayende.com/3342/simple-state-machine#comment7Wed, 04 Jun 2008 19:47:14 GMTWhat do you think about this state machine implemented in ECO: http://www.capableobjects.com/downloads/docs/vs/VS_04_-_Creating_a_state_machine.pdf http://ayende.com/3342/simple-state-machine#comment6http://ayende.com/3342/simple-state-machine#comment6Mon, 02 Jun 2008 14:31:49 GMTI have been thinking about persistence, but I'm not sure what there is to persist. In WF, the object graph of the whole state machine is persisted for each instance, but i'm sure that is useful in this case. The only thing I can think of to persist other than the business objects (which I presume are persisted independently) is the current state, and I figured that generally just be another property of the domain. http://ayende.com/3342/simple-state-machine#comment5http://ayende.com/3342/simple-state-machine#comment5Mon, 02 Jun 2008 02:27:18 GMTif artist is not satisfied by any one language he should make his own. anyway, nice work. since i battle with WF (well our company's hack of WF) i can appreciate such project. All it would need now are persistence & security. http://ayende.com/3342/simple-state-machine#comment4http://ayende.com/3342/simple-state-machine#comment4Sat, 31 May 2008 18:36:45 GMTI keep asking myself, why create a language for every little thing? http://ayende.com/3342/simple-state-machine#comment3http://ayende.com/3342/simple-state-machine#comment3Sat, 31 May 2008 17:57:54 GMTShawn, I would tend to say that there are several fixed actions in the system, and leave the policy to the DSL. The DSL can be just dropped into a directory, and immediately take affect. http://ayende.com/3342/simple-state-machine#comment2http://ayende.com/3342/simple-state-machine#comment2Sat, 31 May 2008 17:14:17 GMTThis has me wondering if an internal DSL would be a useful component for an e-commerce shopping cart? Specifically use the DSL to calculate discounts between dependent products (buy one get one 50% off etc) and for promotion codes (promo code is good for product X, Y, Z only). This would certainly be more flexible, but I wonder if it would be more difficult to maintain than an engine that is statically defined and driven by data. It seems some middle ground for this would be preferable, data driven, yet write the rules not in C#, but the DSL? Also, how does deployment come into play? It would be preferable to support an XCopy style of deployment for the DSL script since I'm going to assume it would be constantly updated - several times a week. http://ayende.com/3342/simple-state-machine#comment1http://ayende.com/3342/simple-state-machine#comment1Sat, 31 May 2008 15:51:29 GMT