Ok, thanks You all! I think I must reconsider the whole thing.
Lets look at it with an example, the class I am refactoring right now. It is class for editing complicated data structures (nested jobject and jarrays with many different datatypes). It uses html template, data object and an array of "plugs" for modifying some behaviors (editing some type of data, validation, default values, etc). User intefrace looks like this: user clicks on a row of data in html table, row changes to form, user modifies data, clicks on "save" button, class validates input, updates data object, do some math for automathic fields like % or sums and partial sums, hides form and show updated table row. Simple. Looking at moo code I was thinking about replacing some of this "plugs" by events. for example: onBeforeUpdate event could be used for validation, inputFocus could be used for adding mask or opening popup to edit more complex datatype... this would allow more flexiblility for users, more loosely coupled design and clearer code. But this would need some chaining on events (for example: "update" cannot happen before "beforeUpdate" finishes) and tracing state, which - if I understand it right - is not possible with mootools events? Do You think it is worth to apply some more formal patterns like filters, decorators or lambdas - or just live it like it is, with array of plugs with names in options (applied based on parameters from cssclass in template)? Hope my english is understandable, haven't use it much lately ;-) Thanks a lot for Your time, Robert
