[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-dev] Java EE 5 models design overview
|
Raev, Kaloyan wrote:
Hi Jesper,
We have taken a look at the J2EE 1.4 models implementation. It did make
impression that there are lots of hand made tweaks there.
I'm a bit confused. You've seen/commented on bug 157185 covering most of
the XML side of J2EE, excluding annotations, so you must know quite a
bit about the progress on this. I'll offer my findings anyway:
We decided to make the initial Java EE 5 models generated from the XML
schemas. There is also a lot of hand made work to be done to integrate
Java Annotations in these models.
I can imagine. The Java EE annotation classes make up a model in itself,
and it would be a pity to have to hand code all that model translation.
Can you outline in more details the tweaks that were done to the J2EE
1.4 models, so we have them in mind for the Java EE 5 ones? Do you think
better approach is to extend the existing J2EE 1.4 models with Java EE 5
specification instead of implementing separate Java EE 5 models?
[First a disclaimer: My knowledge of this is based in part on *Daniel
Rohes *excellent article on Persisting EMF models with WTP [1], and in
part by reading source and experimenting. I do hope the WTP veterans
will confirm my findings. WTP hacking is not my day job.]
As I understand the idea behind the current J2EE 1.4 EMF models, they
are modeled after the semantic contents and then the XML translation is
added "on top", bypassing the EMF XMLSave/XMLLoad, but using EMF2DOM,
EMF2SAX and EMF2DOMSSE instead. This translation is done by hand, see
e.g.
org.eclipse.jst.j2ee.internal.model.translator.webapplication.WebAppTranslator
(note how this handles all supported versions of the spec)
By "semantic contents", I mean that while the XSD support in EMF is good
at de-XML'izing the EMF model generated from the XML, it cannot guess
what the schema means. It you import the XSD for web application, you
get (among other things) a "ServletMapping" type, with a servletName
(string) attribute. This corresponds to the XSD model and binds cleanly
to XML using the EMF model annotations.
If you look at WTP's corresponding model (webapplication.ecore), you see
that the ServletMapping type actually references the real Servlet type,
with the name of the servlet being factored out (normalized into the
Servlet). You even get the link back to WebApplication as a getter. It
makes a lot of coding tasks easier, such as when writing custom
validators, specialized GUI code and whatnot. Not to mention that if you
want to build a graphical editor on top of this, you really really need
the semantics to be represented in the model.
Another key benefits of the Translator model is that the EMF models are
updated "as you type" in the XML documents when using the structured XML
editor (SSE). This is how e.g. the common navigator updates is updated
if you type "<servlet name="myServlet" ...> into a web.xml file. Typing
updates the SSE DOM, which in turn notifies the EMF2DOMSSEAdapters,
which then updates the EMF model (which the common navigator listens
to). This wouldn't be possible using the EMF XMLSave/XMLLoad where you'd
have to wait for a save/load before you could pick up model changes. And
you can still use the EMF based editing scheme, or even GMF.
(I haven't found a reference document for this or a discussion, etc. but
I'm possibly not looking in the right places)
The translation layer, while neat, comes at a cost as described above:
You have to wire up the EMF to XML translations yourself. Documentation
is pretty scarce, and the framework does not allow all combinations of
modifiers are allowed (see bug 160569 [2] and 164246 [3]). I'm also
looking into other enhancements.
For the annotation model, I'll refer you to Neil's reply, I had
something similar in mind, but instead of coding the Annotation <-> EMF
mapping, I'd suggest mapping it in a fashion similar to the EMF-XML
Translators, using adapters on the EMF model, referring back to the AST
model.
-Jesper
[1]
http://www.eclipse.org/articles/Article-WTP-Persisting-EMF/persisting.html
[2] https://bugs.eclipse.org/bugs/show_bug.cgi?id=160569
[3] https://bugs.eclipse.org/bugs/show_bug.cgi?id=164246
