Sometimes it is useful to hide the "- no selection -" option in <select> menus (rendered by the menu() methods of templating.py). When we want force the users *gently* to set a value in the web interface.

The patch is trivial, but I only did that for the class LinkHTMLProperty of templating.py: I've added a new "show_nosel=True" argument to menu(), and put
"l.append(self._('<option %svalue="-1">- no selection -</option>')%s)"
(and maybe the 2 or 3 preceding lines) behind an
"if show_nosel:"

I more general solution to this might be to enable templates to override these sorts of hard-coded HTML generation.

John I agree, do you have ideas on how to implement that?
In reality I can write menu() completely in tal if I really
need it. But having the menu() (and implementing the checklist or 
radiolist display methods in addition to menu) is a big win. 

One of the backburner items is to support html5 as an html_version
value. So changing an implementation could be done for the html5
version so as to not require changes unless the user is also
changing html format.

I've only got some rough ideas for implementation.

I would suggest having a new class of templates with the format of something like `_layout.*.html`. By default the `menu()` method would try to use the `_layout.select.html` template for generating the appropriate html, and `field()` would use `_layout.input.html`. A user could override the template by using a `template` kwarg, ie. `menu(template='custom')` would use the `_layout.custom.html` template.

If no template can be found the default would be to fall back to the existing hard-coded html generation.

For long term maintainability it would probably be good to eventually replace the hard-coded html generated with a hard-coded template.

However these are just ideas, I haven't looked at how practical it would be to implement.

Some comments.

"For long term maintainability it would probably be good to eventually replace the hard-coded html generated with a hard-coded template."

I agree with this. The main power of Roundup for me is its flexibility. These hard-coded stuffs should be more easily editable somehow, like an extension. (OK, we can do this.)

"(and implementing the checklist or radiolist display methods in addition to menu)"

I also agree with this. The .menu() for multilinks is suitable for IT specialists only imho. But this is due to web standards, not to Roundup. :)

Hmm, I kind of like the idea, but performance worries me.

Performance stats show a lot of time in the templating
library even on a single page load.

Things are already slow enough and calling the TAL/chameleon/jinja2
engine multiple times on every single page to build all the inputs
doesn't seem like it would be performant. I literally have pages with 
thousands of inputs (think an editable index page).

Caching might help, but any cache would have to be per user. Cache 
invalidation also becomes an issue.

Thoughts?

Well, performance is important.

I think it would be a great start, if the Python code generating the selection menus were be moved to the extension directory of the templates. (And it could be slightly rewritten to be more user friendly, and using less internal stuff.) Then it could be easier to tweak by the user. (OK, roundup can be patched, or the relevant code part can duplicated into an extension and rewritten, but that would be nicer in my opinion.)

Btw, generating Javascript in the method base_javascript etc. is also a bit strange, instead of putting the .js file to the templates.