Wedge

That's the thing - assuming the browser is capable of handling it, you get email addresses being checked that they are at least legal email addresses, you get numbers validated to being integers (optionally conforming to steps, e.g. between 0 and 100, rounded to nearest 10), and the spec even allows for validating floats though I never got into that because I can't remember anywhere that actually uses it...

Well, that's SMF/Wedge's type (there's a whole bunch of them) but I didn't know until I went looking that there was a type="number" in HTML5 that's modestly well supported.

Actually, though, it's the number 2 reason for me. Having the browser do idiot-proofing on the inputs for the user - so I don't have to - is the number 1 reason :DMore than one already does it in the paid sector. So I'm being daring by NOT doing it ;)Contact forms in the core are nothing new, thus it doesn't innovate or push any boundaries to either leave it out or put it in. And doing it this way means I don't have to worry about it in the core - and have a perfect test subject for the feature I added today.Actually it should be mostly done, apart from having to fix $modSettings -> $settings, just really needs a lot of testing and making sure the whole post form integration stuff works (because that hasn't been tested AFAIK)

OK, so here's a project I started a while ago but put down due to so much other stuff going on. Now I'm dusting it off and trying to work on it, and I thought I might share a few pictures. ;)

I only really got as far as the admin area with a few very minor bits of UI foundation for the main area, but nonetheless...

Back in November when I first started on this before getting massively derailed, I had planned unreservedly to make it paid. Now, I'm a bit undecided on my plugins being free or paid, but it's likely that this one will be paid.[1]

1.	It has been suggested that I make all my plugins paid but pay a small one-time-only fee. I'm certainly more amenable to that than any kind of annual licensing deal. But there's a *lot* of stuff in this plugin so IMHO making it paid would be justified.

Having now integrated the admin panel stuff for simple cases, I'm inclined to think I should add something similar for the main menu - much as it's already possible to add actions without any hooks being called. The idea isn't to remove those hooks but to take out the most common use cases from being required (to lower the barrier to entry for basic stuff, without compromising more powerful stuff should it be needed)

Main menu tabs are a bit more complex than actions, because they need to cover things like permissions, so here's what I'm thinking. There would be a single cache of all the items, which is a nicely serialized array.

The XML would look like:


This would create a new menu item, which would be highlighted on action=myplugin (due to the name), would use $txt['my_plugin'] as its caption (loaded from the plugin's MyPlugin.language.php file, and cached!), would have myicon.png as its icon, would only be visible if the user had some_perm permission, and when clicked would go to the given URL. Same deal for sub items.

As far as the caching goes, all that information would be cached, as well as - and this is the important part - when we created the cache and added an item, we'd also make sure to load all the different installed languages' files, to grab the entry/ies that we needed, and we'd cache them all in the menu. Since it's done at enable-plugin time, it should be relatively cheap to do.

The only problem I can imagine with that setup is that we might end up overflowing the serialize field if there's a lot of languages and a lot of menu entries added. Maybe this is a candidate for json_encode instead.

Also note we would definitely need to change the menu styling code as discussed before to create a single base class for each of the menu icons, such that each icon held to the same styling as far as padding etc. goes (and then this only has to worry about adding the icon itself, rather than having to worry about trying to add all the extra style code like padding)

Thoughts? (This one's primarily for plugin authors, though I'd appreciate your comments, Nao)

This is now in r1397.

And I've updated the contact page plugin in my repo to cover it too.

Well, this stuff was primarily about putting it into the admin panel core templates, so it's available everywhere in the admin panel. That is, assuming we don't have stupid stuff where you have multiple numeric fields combined together to make a composite text field, grrr.

But all 'int' fields in the admin templates now use type="number" and I've added a few more min/max places locally and I'll commit them shortly.

Interesting thing to note, at least in Chrome, that the size attribute is no longer respected (though I've left it in for browsers who will fall back to text boxes as standard), and that the presence of min/max (or, just max, not sure) is required to actually set the size of the textbox.

(This, of course, is no way a prelude to functionality for the settings-page support in plugins, of course :whistle:)

(3 files, 4KB)

Revision: 1396
Author: arantor
Date: 27 February 2012 14:45:00
Message:
+ Provide better support in the internal admin system for HTML5 types, such as a dedicated email field and being able to set min/max/step on numeric fields. Some of the fields, sadly, can't directly use the facilities for validation that are now present because they do implosion-of-multiple-items to a single text field. (ManageServer.php, ManageSettings.php, Admin.template.php)
----
Modified : /trunk/Sources/ManageServer.php
Modified : /trunk/Sources/ManageSettings.php
Modified : /trunk/Themes/default/Admin.template.php