This is interesting, but I think adding a new "type" for every potential use somebody comes up with for a ticket field is going to become unwieldy quite quickly.
I disagree. I racked my brains trying to think of permutations of the types someone could want for custom fields. I think it is a fairly small number of useful types. How many can you think of?
Having a ".onchange" property added to the custom fields might be a more flexible solution, allowing people to add arbitrary JS logic to their custom templates. In conjunction with the (hopefully imminent) workflow
More flexible, sure and more of a programmer's solution. Much harder for an unskilled admin to use though. IMHO the .ini file is not a place for programmers, it is a place for admins who shouldn't have to write any code to configure their Trac site. If a programmer (like me) wants to add arbitrary JS code to a page there is nothing to stop them learning the .cs file and editing it. This patch is my first foray into JS and .cs and I did exactly that (add arbitrary js)!
Another point. .onchange would require some changes to python code handling the config. I had a look at this area and it is very difficult to follow. I wouldn't like to be the one to do this work. The patches I've done only touch the js file and the cs file.
mycustomfield.tooltip = Please enter your value here. (numbers only)
This seems like a good idea to me.
Thanks. I'm not sure if I could write this change but I'd love to see it go in. If a developer with more familiarity with this area could outline the architecture of the config system, I would be willing to give it a go.
Thanks for your feedback. Regards, Felix _______________________________________________ Trac-dev mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac-dev
