Plugging editors and renderers
aclement2
As I said on the bug trakcer I have a few remarks concerning plugging
renderers and editors. The main remark is : it is too much work!
I am still talking about the case where you use the taglib here. After
looking at the source code, I found out that we you use a plugged
renderer (I am thinking about the headerRender where I wanted to
render th tags instead of td tags), an empty constructor gets called
and then the other stuff is injected by setters...
This makes it hard to just extend your original classes to override
just the render method.
I think that most of the time, we want to have access to exactly the
same objects as the default implementation has but just want to
override the render method which actually does the rendering. This is
hard to do with the actual design. Maybe instead of instanciating with
an empty constructor, you could search a constructor with the same
signature as the default implementation and if it doesn't exist, then
call the empty one...
You might not agree on this, it is just a point of view.
Second remark. Still on my HeaderRenderer, I could not extend the
AbstractHeaderRenderer class because of a groovy import (Closure)
inside it. Adding groovy support is a great thing, but I did not want
to add a dependency to the project just to change tds to ths. See
what I mean?
Third remark. This ones joins a little bit the first remark. I
implemented my own view so I could change the render method, but also
because I wanted to change the HtmlSnippets. I agree the HtmlSnippets
you migth not have planned that someone might want to change the
implementation of this class but I had a really "weird" need for my
table rendering that the default implementation could not fill.
Because of the lack of calling the same constructor, a HtmlSnippet
implementation does not event get injected and I had to instanciate
one in the render method which isn't very clean. Again, if the same
constructor could have been called, I could of changed the second line
"this.snippets = new HtmlSnippetsImpl(table, toolbar, coreContext);"
by my own implementation.
Maybe the solutions I propose are not the right ones, they would just
work where I needed them. But I still think that when plugging our own
classes we should get (by which means I dont exactly know) everything
that we need to do the rendering and just have to focus on the render
method.
Voila.
Tell me what you think about all this. Am I the only one with this
point of view? Just to be clear, I think providing the possibility to
hook in our own classes is a excellent feature (this is why I chose
jmesa over displaytag on my project right now) but I think it could me
even more simple...
Keep up the good work.
Arthur CLEMENT
Jeff Johnston
first class citizen of the application, but I really depend on the
community to help me test it out. I use the API for the most part
myself...
So, you make some good points.
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 http://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.
I would be more than willing to work with you about getting things
easier. If you agree with enhancing the renderers and view with
default constructors and more support interfaces I can do that right
away. I could also implement the preferences fairly easy for the th
versus the td element in the header. The Groovy support by default I
would still like to keep though...the renderers are meant to be
plugable so you can easily make your own up if needed, and I think
that is the most important feature.
I would have time to help you out next week! Would you be able to test
builds that I make up for you?
Also, could I see a screenshot of what your headers look like with
regards to the look and feel when sorting? I would really like to
improve that look and am curious what you did :).
-Jeff Johnston