Too busy to read the whole thing? *Executive summary: just read the
bold words.*
*Methinks *there may be a cart before a horse in this process. The
timeline (as I understand it):
1. Feature was named (in a question given mid-presentation was it?)
2. Functionality was considered (not sure this totally matches the
feature name)
3. Need for the feature is discovered (hasn't happened yet imho)
I am a relative Model Glue newbie and I haven't built any large Model
Glue applications yet but I do have *lots of* experience with *feature
creep*. This has all the classic signs of a "ya know what'd be nice
is..." request that can soak up developer time away from stuff that
would be more useful.
*Why does the framework need this?* Give me a cost vs benefit
analysis. In what way am I better organized and prepared to do my job
good, fast and cheap? If I'm just completely missing the part of the
conversation where someone pointed that out, please /break it down for
me again nice and slow/.
As a new user, simply saving me 47 keystrokes in my config is not worth
the extra time I have to put into thinking about how to use this
framework. If I were *a totally new MG user*, learning Model-Glue day
1, and I saw the feature in the documentation I *would */*agonize* /over
whether or not I should be using default events just because the name
/sounds /interesting *and *it was in the documentation. I'd *probably
do it completely wrong* /at least/ once. I already have plenty to
agonize over.
~David
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "model-glue" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/model-glue?hl=en
For more about Model-Glue, check http://www.model-glue.com .
-~----------~----~----~----~------~----~------~--~---
