syntax:

# active record style

before_save <pattern>  do |card|

   #...

end

OR

before_save <pattern> do
  # this code executed in context of card object
end

OR

# a more explicit syntax with options for multiple hooks, multiple patterns, and a priority setting

on :hook=>[:name_change, :type_change], :pattern=>[ <pattern1>, <pattern2> ], :priority=>0 do

  # ...

end

OR

? ...

hook list:

 

• all ActiveRecord callbacks
• name_change
• type_change
• content_change
• before_multi_update
• after_multi_update

access needs:

• the card invoking the hook
• the defining module?
• current user executing the operation?  maybe only the permissions module needs to know about a current user.

collisions

generally I expect these hooks to be additive.  If that's the case I don't know if we need to be able to "overwrite" hook implementations from other modules, and if so, how.

notes:

• priority setting:  I know from the current wagn implementation that there are times that you need some control over the order of invocations within a particular callback.  there are times when I've had to do ugly hacks to insert a callback at the beginning of the list of  :before_save operations instead of the end.  it would be nice to have syntax support for this.  
• in some cases it would be nice to define a block of code that is run on several hooks.
• virtual cards could be implemented as a hook on a find method

---

I really like this stuff, but also would like to connect this to what I was developing about the DSL question.  I like the more specific syntaxes and think modules should be able to add these.  The most basic Card deployment would have no security (i.e. a local resource deploy, etc.) for example so you any hooks for that would be optional.  I think "everything is optional" is a good goal.  For example, you would only have before/after_multi_update when modules doing multi-update are loaded.  I might have an XML only deploy without this, but no problem if you register for a hook that is never called.

 

I think that you could make each sub-action from layout through authorization and rendering for action could be a hook, including the ones you list.  In other words I want to define everything in the DSL in terms of hooks (maybe), some parts that define hooks, and others that define the order in which the hooks will be called to process the next hook.

 

--Gerry Gleason.....Fri Oct 16 06:33:57 -0700 2009