Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
[eclipse-dev] TypePage


  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.

  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
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?

  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.

  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.

  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.

  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. 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.

ps. Is there any particular reason that sometimes the instance variables are
prefixed with "f" and sometimes not?

Back to the top