My favorites | Sign in
Project Home Downloads Wiki Issues Source
READ-ONLY: This project has been archived. For more information see this post.
Search
for
  Advanced search   Search tips   Subscriptions
Issue 53: Plugging in editors and renderers
1 person starred this issue and may be notified of changes. Back to list
Status:  Fixed
Owner:  extremec...@gmail.com
Closed:  Nov 2007


 
Reported by extremec...@gmail.com, Nov 12, 2007
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
The view has a new AbstractHtmlView. In addtion the TableFacade now supports numerous
support classes. The docs are updated to reflect this...
Status: Started
Nov 24, 2007
#2 extremec...@gmail.com
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

Powered by Google Project Hosting