[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [eclipse-dev] TypePage
|
Hi Mariano,
the eclipse-dev mailing list is intended for general eclipse developer
discussions.
For Java tooling related discussions please use the Java development
tools (jdt) mailing lists.
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.
See <EG>for answers</EG>
--erich
"Mariano Kamp"
<mkamp@xxxxxx> To: "Eclipse-Dev" <eclipse-dev@xxxxxxxxxxx>
Sent by: cc: "EJBBuilder Developer List"
eclipse-dev-admin@ <ejbbuilder-developers@xxxxxxxxxxxxxxxxxxxxx>
eclipse.org Subject: [eclipse-dev] TypePage
02/24/2002 09:27
PM
Please respond to
eclipse-dev
Hi,
looking at the different APIs which seem to be useful all the ways lead
to
TypePage. I believe to remember that there was a announcement on this list
saying that it is available and will eventually promoted to the API
(Unfortunately I don't have the mail anymore and can't go online to look
for
it). There was also a request for feedback. I am looking at it from the
perspective to develop an EJBBuilder, which should build the bean types and
create/update the deployement descriptor.
I like the current implementation very much. I especially like the small
things like finding the unimplemented methods.
That would be very handy for
the creation of the ejb bean class to provide stubs for all the lifecylce
methods. This will keep the generation code clean and slick. It is also
nice
to reuse the source folder and package browser.
Still there are some things which doesn't make it easy to be reused for
the a.m. job (ejbbuilder). I do confess that I probably haven't looked
close
enough to make a valid statement.
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>
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>
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>
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>
I know it is much easier to critize, than .... I really do not intend to
be offensive here and I probably missed the whole point - it is meant
constructive.
<EG>
don't worry. It is constructive, concrete code would even be more
constructive <g>
<EG>
I do like and enjoy eclipse a lot. In the current project I am
working my whole team of up to twenty developers is using eclipse since the
middle of november and they love it - just discovered remote debugging.
<EG>
actually such nice words justify sending the message to eclipse-dev <g>
<EG>
Mariano
ps. Is there any particular reason that sometimes the instance variables
are
prefixed with "f" and sometimes not?
<EG>
Our rule is that 1) each component has to have a consistent coding style
and
2) the API has to be consistent across eclipse. Different components have
decided for different
naming conventions for non API fields.
<EG>
_______________________________________________
eclipse-dev mailing list
eclipse-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/eclipse-dev
