I shouldn''t really be suggesting ideas for rails when I''m a week into the thing, but what the hay. By all means, tell me that this already exists in some form, and point me in the right direction. I hope not to waste anyone''s time -- I did read the Rails book cover to cover, so you know, I''m not speaking from nothing. When doing database design you inevitably end up with lots of tables that are just kind of reference tables. These change very rarely and typically represent something like state or type or identity. These "state" tables generally translate into "Value Objects" in your system. That is, you can''t really change them. Some examples might be: - Ordering Lifecycle: an order has one ORDER STATE (paid, shipped, tracking, etc) - Article Status: an article has one STATUS (drafted, posted) - Wooeing Lover: a wink has one RESPONSE (rejected, accepted, ambiguous) These state objects'' columns might be: - primary key - position (priority) - display_name - reference_name If you mark the state object as "acts_as_state" then you could do something like the following (using the previous examples): @order.mark_as_shipped! @article.mark_as_drafted! @wink.mark_as_rejected! Maybe even save methods: @order.save_as_shipped @article.save_as_drafted @wink.save_as_accepted These methods would be created using reference_name or perhaps even the display name by replacing spaces with underscores and lowercasing them. Methods like those are useful in a state applications where no other attributes have changed, so an "update_attributes" is overkill -- you''re just moving the object from one state to the next. Sorry if this is a plainly obvious feature of rails already. Noah
Hi Noah, I''m already 90% there - although my implementation isn''t an acts_as, and it doesn''t require any special save_as or mark_as methods. I''ll let you (and the list, in case anyone else is interested) know when it''s done (possibly this weekend). Regards, Trevor On 16-Sep-05, at 10:18 PM, Noah Davis wrote:> When doing database design you inevitably end up with lots of tables > that are just kind of reference tables. These change very rarely and > typically represent something like state or type or identity. These > "state" tables generally translate into "Value Objects" in your > system. That is, you can''t really change them. Some examples might be: > > - Ordering Lifecycle: an order has one ORDER STATE (paid, shipped, > tracking, etc) > - Article Status: an article has one STATUS (drafted, posted) > - Wooeing Lover: a wink has one RESPONSE (rejected, accepted, > ambiguous)
I''m interested. :) On Sep 17, 2005, at 10:08 AM, Trevor Squires wrote:> Hi Noah, > > I''m already 90% there - although my implementation isn''t an > acts_as, and it doesn''t require any special save_as or mark_as > methods. > > I''ll let you (and the list, in case anyone else is interested) know > when it''s done (possibly this weekend). > > Regards, > Trevor > > On 16-Sep-05, at 10:18 PM, Noah Davis wrote: > >> When doing database design you inevitably end up with lots of >> tables that are just kind of reference tables. These change very >> rarely and typically represent something like state or type or >> identity. These "state" tables generally translate into "Value >> Objects" in your system. That is, you can''t really change them. >> Some examples might be: >> >> - Ordering Lifecycle: an order has one ORDER STATE (paid, shipped, >> tracking, etc) >> - Article Status: an article has one STATUS (drafted, posted) >> - Wooeing Lover: a wink has one RESPONSE (rejected, accepted, >> ambiguous) >> > > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails >
On Saturday 17 September 2005 07:18, Noah Davis wrote:> When doing database design you inevitably end up with lots of tables > that are just kind of reference tables. These change very rarely and > typically represent something like state or type or identity. These > "state" tables generally translate into "Value Objects" in your > system.Have a look at the recent thread on enumerations http://thread.gmane.org/gmane.comp.lang.ruby.rails/19193 Michael -- Michael Schuerig Those people who smile a lot mailto:michael-q5aiKMLteq4b1SvskN2V4Q@public.gmane.org Watch the eyes http://www.schuerig.de/michael/ --Ani DiFranco, Outta Me, Onto You
On Sat, 2005-09-17 at 01:18 -0400, Noah Davis wrote:> When doing database design you inevitably end up with lots of tables > that are just kind of reference tables. These change very rarely and > typically represent something like state or type or identity. These > "state" tables generally translate into "Value Objects" in your system. > That is, you can''t really change them. Some examples might be: > > - Ordering Lifecycle: an order has one ORDER STATE (paid, shipped, > tracking, etc) > - Article Status: an article has one STATUS (drafted, posted) > - Wooeing Lover: a wink has one RESPONSE (rejected, accepted, ambiguous) > > These state objects'' columns might be: > > - primary key > - position (priority) > - display_name > - reference_nameYour position (priority) might be a problem. If you take a wider view of the problem, you are looking at stop points in a workflow. - Ordering consumer objects: order -> paid -> ship -> tracking -> delivered - Ordering business objects: order -> PO -> ship -> track -> deliver -> collect - Article: draft -> review -> post -> external review -> edit -> review - Wooing: wink -> talk -> hold hands -> kiss -> ... at any point you might experience varying degrees of setback. I am going to be working on an implementation that will list prerequisites and a list of potential success> Maybe even save methods: > > @order.save_as_shipped > @article.save_as_drafted > @wink.save_as_accepted > ive states.> If you mark the state object as "acts_as_state" then you could do > something like the following (using the previous examples): > > @order.mark_as_shipped! > @article.mark_as_drafted! > @wink.mark_as_rejected!The implementation I will be working on will let you query the state for possible next steps. Specifically, take your wooing example, there isn''t always a one way, one possible successive state to move to. So if you wanted to make a form allowing the data entry and validation of state transitions, you would want to know the possible success states. Success here being defined as a transition out of the current state, not necessary moving forward to some end state.> These methods would be created using reference_name or perhaps even the > display name by replacing spaces with underscores and lowercasing them. > Methods like those are useful in a state applications where no other > attributes have changed, so an "update_attributes" is overkill -- you''re > just moving the object from one state to the next.I''m not sure the savings in SQL terms is going to significant enough to warrant this change. An easy and well tested flexible workflow engine that is easily implemented is always a good thing. -- Steven Critchfield critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org KI4KTY
On 9/19/05, Steven <critch-wQLwMjUOumVBDgjK7y7TUQ@public.gmane.org> wrote:> > > > These state objects'' columns might be: > > > > - primary key > > - position (priority) > > - display_name > > - reference_name > > Your position (priority) might be a problem. If you take a wider view of > the problem, you are looking at stop points in a workflow. > > - Ordering consumer objects: order -> paid -> ship -> tracking -> delivered > - Ordering business objects: order -> PO -> ship -> track -> deliver -> collect > - Article: draft -> review -> post -> external review > -> edit -> review > - Wooing: wink -> talk -> hold hands -> kiss -> ... > at any point you might experience varying degrees of setback. > > I am going to be working on an implementation that will list > prerequisites and a list of potential success(still noah - i switched email addys) I take your point. I wasn''t thinking about the problem as some kind of Workflow problem. The priority really was more for convenience of ordering states when they are needed to be presented on the client side. ("drafted" first, "final" second). The problem domain expands significantly when you add workflow to this equation. What I was suggesting wouldn''t prohibit workflow, but also would allow for really basic "type" like behavior out of the box. Buet yes, workflow is cool too :)