Created on 2021-03-25 02:06 by ngaba, last changed 2021-03-31 00:29 by ngaba.
|msg7140||Author: [hidden] (ngaba)||Date: 2021-03-25 02:06|
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:"
|msg7141||Author: [hidden] (jerrykan)||Date: 2021-03-25 03:17|
I more general solution to this might be to enable templates to override these sorts of hard-coded HTML generation.
|msg7148||Author: [hidden] (rouilj)||Date: 2021-03-28 18:51|
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.
|msg7151||Author: [hidden] (jerrykan)||Date: 2021-03-29 12:12|
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.
|msg7154||Author: [hidden] (ngaba)||Date: 2021-03-29 13:10|
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. :)
|msg7157||Author: [hidden] (rouilj)||Date: 2021-03-31 00:09|
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?
|msg7158||Author: [hidden] (ngaba)||Date: 2021-03-31 00:29|
|2021-03-31 00:29:28||ngaba||set||messages: + msg7158|
|2021-03-31 00:09:46||rouilj||set||type: behavior -> rfe|
|2021-03-31 00:09:30||rouilj||set||messages: + msg7157|
|2021-03-29 13:10:22||ngaba||set||messages: + msg7154|
|2021-03-29 12:12:37||jerrykan||set||messages: + msg7151|
messages: + msg7148
|2021-03-25 09:18:27||schlatterbeck||set||nosy: + schlatterbeck|
messages: + msg7141