> Sounds like a winner to me, Steve. Many folks would benefit from a model
that
> essentially says, "if you need an application variable to store a piece of
> information like X, here's a standard name to use". Of course, you could
pick
> and choose, only using those variables you need for your app.
the only trick here is that the true benefits of app_model would only occur
if as a group we agreed not only on "recommendations" but a few outright
standards. To date, Fusebox has always been a list of recommendations with
the immediate Papovich proviso ("hey if you dont like it do it any &*!@# way
you want.")
But when suggesting a move to a "plug-n-play" then *some* kinda standard has
to be defined as absolute, even if it is minimal. And, to avoid a lot of the
issues involved with versioning, there would have to be some version
numbering system added
(even now it is a pain: "hey do you have the most recent version of
'CF_FORMURL2ATTRIBUTES'?" "You mean the one with search engine
Compatibility?" "Yes." "Well which one? the Nelson one or the other one
posted in mid-December?").
It is not so much that one *has* to do it such-n-such a way, but rather to
get the "good Fuseboxing seal of approval" it would have to meet some spec:
"This app meets Fusebox Plug-n-Play Spec 1.23" which may mean that a certain
app could be guaranteed to work with any other app that also used that Spec
("and below"..., I presume some backward compatibility would get built in)
But when we do that, we are definitely going to have to have some sort of
group of people who actually set such a standard.
I'm entirely in favour of the idea, i'm just pointing out that to really go
forward with it we have to accept some changes to how Fusebox has previously
handled this concept because we'd be transitioning, at least in part, from a
"recommendation" to a "standard". Otherwise everything labelled as
"Plug-n-Play" really isn't that at all--it'd be more like "Perhaps
Plug-n-Play" --you'd *always* have to re-inspect the code, everytime they
changed it!
[on a related note, I've often thought that custom tags should come with a
shell that calls each version of a custom tag based on a version number,
defaulting to the most recent version], ie:
formurl2attributes.cfm
formurl2attributes_1.1.cfm
formurl2attributes_1.2.cfm
formurl2attributes_1.5.cfm
called by
<cf_formurl2attributes version="1.2"> (use a specific version 1.2)
<cf_formurl2attributes> (uses the most recent version, here 1.5)
etc.
allowing one to use old versions of a tag so as not to break old code but
also allowing updates. The author would then only need to announce the
release of one of the sub-tags for a new version. Dinowitz' CFOM did this
but didn't seem to catch on
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Structure your ColdFusion code with Fusebox. Get the official book at
http://www.fusionauthority.com/bkinfo.cfm
Archives: http://www.mail-archive.com/[email protected]/
Unsubscribe: http://www.houseoffusion.com/index.cfm?sidebar=lists
