Question about new API

[David]

Jeff:

I'm only now (finally!) getting to look at the new API (v3). I'm bound to say I'm having a lot of difficulty with it, and in particular with extending it. A lot of difficulty. How do I create a CoreContext now? I used to get it from the TableFacade, but that's not visible in the new dispensation. The WebContext is just a constructor (albeit one that requires the request, which I'm not sure I have where I am trying to create it), but the CoreContext involves a lot more. Help!

David

[Jeff Johnston]

What are you trying to do by extending the CoreContext?

The TableModel is the preferred entry point into the API now. You can still use the TableFacade if you want, but the problem with the facade was it could be difficult to get the order of calls correct. With the TableModel the order that you call things does not matter.

-Jeff

David

--
You received this message because you are subscribed to the Google Groups "JMesa" group.
To view this discussion on the web visit https://groups.google.com/d/msg/jmesa/-/vIVIBmt-KKAJ.
To post to this group, send email to jm...@googlegroups.com.
To unsubscribe from this group, send email to jmesa+un...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/jmesa?hl=en.

[David]

It isn't that I need to extend the CoreContext - one of my extended classes (a HeaderRenderer, as it happens, but it could be anything) needs a CoreContext and there's nowhere to get it from. I understand the change in the API quite well - I'm just saying that it's hard to work with in extension. So long as what I need is exactly what the framework does "out of box", it works fantastically. But if I do need access to the "innards", they're even farther away than they used to be. I have simply gone back to using the TableFacade, but am of course open to any new ideas.

[Jeff Johnston]

Its actually a lot closer than you think! What I have now are what I call "support" interfaces that will automatically inject the classes that you need.

I need to update the documentation but you can look at this wiki page to get an idea of what happens.

http://code.google.com/p/jmesa/wiki/SupportInterfaces

So, for your HeaderRenderer you could extend the AbstractHeaderRenderer and then automatically get access to the Column, WebContext and CoreContext.

http://code.google.com/p/jmesa/source/browse/trunk/jmesa/src/org/jmesa/view/renderer/AbstractHeaderRenderer.java

In general I have tried to consistently give an abstract class to extend to do something custom so that you have access to everything that you could potentially need.

Also, I would really try to not use the TableFacade because the TableModel is much much easier to use.

-Jeff

--
You received this message because you are subscribed to the Google Groups "JMesa" group.

To view this discussion on the web visit https://groups.google.com/d/msg/jmesa/-/Qn9iyWu1F2EJ.

[David]

OK, seems pretty good. I hadn't noticed those marker interfaces. Good planning! I'll try them and see how they work.

To unsubscribe from this group, send email to jmesa+unsubscribe@googlegroups.com.

[David]

Oh, I had such high hopes! And what a pity - the marker interfaces did nothing at all to solve my problem. I still don't get a CoreContext injected, even though I modified my editor to subclass HtmlCellEditor rather than AbstractContextSupport (and, of course, added the marker interfaces). Any further ideas? Thanks!

[David]

I tracked through your code and discovered the problem - my columns never get a CoreContext! Without that, it's useless to have the API code you actually do have. I thought the whole point was to avoid having to do things in order, but am I wrong? Must I add the column before I configure it? Why are the CoreContext and WebContext not injected during render(), when you know you have everything just so? Only wondering.... Thanks!

[David]

Oh, and I thought to extend TableModel to enable myself to get the CoreContext manually (as it were), only to discover that all the attributes of TableModel are private and therefore cannot be accessed, even by subclasses! This seems very odd in a framework, which must expect (I would think) to be extended and decorated. But I'm clearly just hot (we've been without electricity for 2 days now and there's a heat wave in the near-100s) and irritated thereby, so sorry.