Textpattern CMS support forum
You are not logged in. Register | Login | Help
- Topics: Active | Unanswered
#1 2009-08-31 21:56:33
- TheEric
- Plugin Author
- From: Wyoming
- Registered: 2004-09-17
- Posts: 566
rearrange class/id/name
Here’s a request that I really want :
Make a standardized ordering of function arguments : e.g. fInput($type, $id, $class, $title, $name, $value {});
Note that in the following example ID is the 9th argument. It shouldn’t be second to last as IDs are exceptionally important. Basically, keep IDs and class names towards the front, and ideally, do away with the onclick. That’s really bad form. The jQuery library is standard w/ textpattern, why not make use of it?
Last edited by TheEric (2009-08-31 22:02:11)
Offline
Re: rearrange class/id/name
What are your sugestions re: backward compatibility?
Offline
#3 2009-09-10 03:24:12
- TheEric
- Plugin Author
- From: Wyoming
- Registered: 2004-09-17
- Posts: 566
Re: rearrange class/id/name
Suggestions? Same as it’s always been. It’s better to continue to improve than be held by the past.
Offline
Re: rearrange class/id/name
Any plugin author wanting to chime in?
Offline
Re: rearrange class/id/name
‘name’ is more important than ‘id’, ‘class’ and certainly ‘title’.
If I had to change current variable order in that function (it’s certainly not perfect as it is), I’d move ‘id’ to just before ‘class’ and change nothing else (oh yes, the ‘onclick’ can go and perhaps swap ‘tabindex’ and ‘disabled’ though I’m not sure about the latter).
However… Eric, how do you intend to solve the backward compatibility problem?
Perhaps this calls for a more drastic change. Let’s drop PHP and switch to Python so we can use named parameters in function calls ;)
Offline
Re: rearrange class/id/name
Ding dong!
Improving is good, but all plugins — including some of mine — have to be revisited. The problem is some plugins not maintained but are working and are always used.
I mean PHP itself is inconsistent (function names with or without underscore, positions of needles and haystacks etc. pp.). And these functions are not changed too, for a backward compatibility.
So I would suggest — if more ppl want to change it and if developers are willing to change it — changing on a major step would be useful. Say on Textpattern 5.0, where MySQL and PHP version requirements will be changed too.
Digital nomad, sailing the world on a sailboat: 32fthome.com
Offline
#7 2009-09-10 10:47:31
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: rearrange class/id/name
+1 for change on a major upgrade and please, please, please have a list of these kind of changes available for the poor plugin devs (wiki page updated as changes are made is fine).
I don’t relish having to constantly update my plugins (some of which are widely used) with every Txp release, or having to dig through the core’s code to figure out why there are new errors popping up in my previously working fine plugin. :)
Offline
Re: rearrange class/id/name
Mary wrote:
+1 for change on a major upgrade
Mary, please disambiguate ;-)
+1 for “change it”, or +1 for “if it must happen at all, then wait at least for a major release”?
Offline
#9 2009-09-10 11:00:37
- Mary
- Sock Enthusiast
- Registered: 2004-06-27
- Posts: 6,236
Re: rearrange class/id/name
Both. :) As in, sure change it, but wait for a major release. Clear as mud? :)
Offline
Re: rearrange class/id/name
I agree it is a ballache to have to do some_function('type', 'class', '', '', '', '', '', id);
just to add an ID — especially if the args in between are something other than empty by default.
But I agree with trenc that inconsistency plagues most languages (the needle/haystack thing in PHP gets me every time… still!)
By all means change it on a major release but perhaps the way to go might be to rename the functions slightly:
function new_func('shiny', 'new', 'arg', 'order', 'goes', 'here') {
blah blah, same as current functionality;
}
// Stub
function old_func('order', 'goes', 'new', 'here', 'shiny', 'arg') {
return new_func('shiny', 'new', 'arg', 'order', 'goes', 'here');
}
That way, nothing breaks and the only downside is an extra item on the call stack when using the old functions. If these proposed function changes are published waaaay in advance of a major release, plugin authors can gear up for the changes and the core can use the new calls as we swap them out. If we miss one or two at first it has only a minor impact in performance until we catch them all.
Dunno, just a random idea. Not necessarily the best one, but some of the function names now do leave something to be desired so it’s a chance to make them more consistent at the same time as standardising the arg order wherever possible.
Long (long) term, the old funcs can be deprecated and eventually purged. Feel free to rubbish this proposal as I’ve not really thought it through :-)
The smd plugin menagerie — for when you need one more gribble of power from Textpattern. Bleeding-edge code available on GitHub.
Txp Builders – finely-crafted code, design and Txp
Online
Re: rearrange class/id/name
I like Stef’s suggestion
Piwik Dashboard, Google Analytics Dashboard, Minibar, Article Image Colorpicker, Admin Datepicker, Admin Google Map, Admin Colorpicker
Offline
#12 2009-09-10 14:20:24
- redbot
- Plugin Author
- Registered: 2006-02-14
- Posts: 1,410
Re: rearrange class/id/name
Bloke wrote:
By all means change it on a major release but perhaps the way to go might be to rename the functions slightly:
Don’t know if this will bloat the code too much but it seems a good idea to me.
Offline