[jdt-ui-dev] RE: [Ejbbuilder-developers] Re: [eclipse-dev] TypePage

["Mariano Kamp" <mkamp@xxxxxx>]

Hi Erich,

  thanks for taking the time to give me detailled feedback.

>You are correct that we will promote the TypePage to API. The focus of
>TypePage
>is to support simple class creation: classes, interfaces, servlets or
>JUnit test cases. As you point out below EJB creation is more involved and
>our assumption was that for such a use case a custom Wizard/Page is more
>appropriate. You observations below seem to confirm this.
>Rather than us trying to generalize what is currently there without
>working on the concrete use case I suggst that you push ahead (by copying,
>tweaking, use of internal APIs) and providing us with feedback of your
>needs.
Ok, I understand that, but I fear that changing an API afterwards will be
painful too.
We've already implemented most of the Wizard in the ejbbuilder, though it is
the first throw and at least the code generation will be completly reworked
as the concepts (by me) are messy. At least the separation of generation,
model and ui is already there and can be looked at.
Hence we would not benefit directly if the TypePage is to be changed as we
already have this functionality in place, but we are keen to keep up with
the "standard way" of doing things and give feedback what discouraged us
from using the type page.

>See <EG>for answers</EG>
<MK>I've annotated mine using the same scheme </MK>.

--erich

  Extracting the data to a model as well as pulling out the generation
code.
    Reuse would be much easier. For example: For an ejb is more than one
type to be generated, leaving alone the dd. Having the model and controll
logic separated from the ui I could extend the current model and trigger
the
generation myself and generate more than one CU.
<EG>
rather than trying to come up with a general framework that handles the
multiple type generation
case. It is more flexible and maintainable when the JDT tools surface
building blocks methods
to support this use case rather than prescribing a particular way for doing
this with a framework.
</EG>
<MK>
I am not sure if I properly understood that or if I expressed myself
properly the first time?
My point was that the code generation and the model data already leads to
some kind of usage. It would be nicer if it would just use a very thin
interface method like "void generate(Model theModel, Object
someBuildSpecificParameters) throws BuilderException". So that the
generation is decoupled and it can be implemeneted to yield in one CU or
more than one CU generated. It is also not assuming which kind of resource
is to be generated and what lifecycle calls are needed to generate it.</MK>

  Pulling up some behaviour and state to a new abstract class.
    At least when looking from the ejbbuilder job, there seems to be a gap
between ContainerPage and TypePage. Actually a good name for TypePage could
be [Single/Simple]PageTypePage and making TypePage the superclass of it and
New[Class/Interface]CreationPage as concrete subclasses of
SinglePageTypePage.
Stuff like access modifier make sense for an interface or class but doesn't
make much sense for generating ejb, so if they were pushed down from the
new
TypePage to the new SimpleTypePage, I could leave them alone and extend the
new TypePage.
Just curious - as an eclipse newbie - why is it implemented as a page
instead of a wizard? It is not supposed to interact with other pages, is
it?
<EG>
Making it a page enables you to compose the page with other pages to create
a new wizard.
This is more flexible than providing a generic wizard that can be extended.
</EG>

  As I am at it. Browsing through the code it seems, that after some
indirection it ends up in CreateTypeOperation and this being a subclass of
JavaModelOperation I was expecting some UpdateOperations as well, but
haven't found any. After building the initial ejb wizard we would like to
enhance the plugin to provide full lifecycle support and are looking for
the
right way of doing it.
<EG>
The JavaModelOperations are an implementation detail of the Java Model API
only. You should
be able to achieve what you want through the official Java Model API
(org.eclipse.jdt.core*).
Please look into the corresponding API documentation.
</EG>
<MK>I was wrong. I found that besides formatting the generated code I can
always use the IType interface to create/overwrite source code. The only
other thing, besides formatting, I haven't found is adding unimplemented
methods with the public API.  Well, I also haven't found how to add for
example methods in batch mode. When adding fifteen methods to a type, like
the remote interface, then it takes ages and by looking at the local history
there are fifteen versions of the code and I assume the code has been
compiled fifteen times (if autobuild is turned on). Anyway I am leaving the
original topic and haven't looked into this new one properly yet.
</MK>

  The whole code looks a tiny little bit like scripting code - not meant to
be offensive though - maybe there is even more features which can be
extracted to different classes because of their broader usage patterns.
choosePackage() is one example here.

  If nothing of this makes any sense to you, it would at least nice if
StubUtility would be promoted to the eclipse API.
<EG>
I fully agree that some of the stub utility should become API. However, it
should not be surfaced
a the jdt-ui level but at the level of jdt-core (these are different
teams).
</EG>
<MK>
Ok, then I guess it would be the right approach to enter two feature request
for jdt-core (promoting formatting and adding unimplemented methods so far).
I'll do that.
I am on the wrong list again though :-)
</MK>
  Btw. I don't think that ejbs are the only potential clients, which aren't
fitting in the current picture. Creating stubs for WebServices or O/R
mapping classes could be other candidates and I haven't really started
thinking about it.
<EG>
This makes sense, but frameworks (and this is what we are discussing here,
i.e., a creation framework
for Java classes) should evolve from concrete examples, rather than the
other way around.
Frameworks have a high API cost and therefore: it has to really hurt before
doing one...
</EG>
<MK>
I do see real pain with the current approach ;-) Type access modifier are
already wired into the TypePage. The API states that it is intended to be
subclassed for a Servlet wizard. I don't think it makes sense for servlets
to have a different access modifier than public, but as it is already in
Type Page it needs to be used, doesn't it?
The reason I was asking for the SimpleTypePage is, that I was fearing there
would be no change possible after the promotion and for me, it already hurts
;-)
</MK>


Cheers,
Mariano