| Issue 53: | Plugging in editors and renderers | |
| 1 person starred this issue and may be notified of changes. | Back to list |
This is from the wiki...it should be written up better but I didn't want to forget about it: http://groups.google.com/group/jmesa/browse_thread/thread/b887614d23b0ed5 Taking the renderer and view instantiation problem first... The best thing to do would be to create a default constructor and then make sure that the default objects are loaded up. I use the notion of support interfaces to accomplish this. The idea is to detect if a user has a certain interface and then I know if the object is not set then I should set it for them. I have that detailed pretty good on the wiki at https://code.google.com/p/jmesa/wiki/SupportInterfaces. The renderer would be fixed with just a default constructor, however the view would need a support interface for the HtmlSnippets library and maybe even the HtmlTable. The view could further define an abstract class to extend to make adding support classes like this easier for developers that have already modified their view or any other changes in the future. The HtmlHeaderRenderer going to a td versus a th element I am not sure about. The specification is so fuzzy about that. It basically reads that if you do anything beyond just displaying text you should use the td element. It for sure does not say that always using the th element is correct, although it would be easier if it did. With both the header and filter being so interactive it seems the td element is correct. I would say a better approach would be to make this a configurable option that could be defaulted in the preferences file. You are the second person to ask me about this so I know it is a hot topic for some. I would hate to break peoples tables though for such a non-definitive rule. The last question you had deals with extending the AbstractHeaderRenderer and the Groovy class. I do see your point, but the difference is the Groovy support is only a runtime dependency and only if you want to extend the default functionality. In the future JMesa would like to support as many dynamic technologies as possible so the compile-time dependencies are going to potentially increase. One thing I really like about Groovy especially is you can define your table not using Groovy, and then Groovy things up...meaning a Groovy tables can use closures or non-closures and still run the same, which is really nice.
Nov 18, 2007
#1
extremec...@gmail.com
Status:
Started
Nov 24, 2007
The renderers and editors will now use the defaults if nothing is specified. This presented itself as a great opportunity to refactor those methods and make them much more simply and robust at the same time. Also, the renderer element can now be specified as a td or a th element. The default is a td element and can be overridden in the preferences file. html.column.header.renderer.element=td
Status:
Fixed
|