You're right on the money about this. I've been thinking about how we
could have a die-hard standard for this type of thing, who would control
it, how could it be added to etc....
i absolutely love the idea of a non centralized committee... meaning
anyone could suggest an addition to the standard and anyone could vote
it in or out, none of this elector crap that us Americans had to deal
with for our president.... true democracy. It's the essence of what the
web is capable of.
We'll all have to think about the specifics of how this would work.
Steve Nelson
http://www.SecretAgents.com
Tools for Fusebox Developers
(804) 825-6093
John Quarto-vonTivadar wrote:
>
> > 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
