Hi Cory,
How do they recognize relations between tables?
Frank
On Tuesday, November 07, 2000 3:32 PM, Cory Adams [SMTP:[EMAIL PROTECTED]]
wrote:
> I just received JBuilder 4 Enterprise and I will say that it does an
> amazing job at EJB so far. You can connect to a datasource via JDBC and
> pick your tables and keys for Entity CMP. It's amazing.
>
> I'm still tweaking the deployment descriptors for Orion.
>
> Man the money you can save on Orion should go toward also purchasing JB4
> Enterprise. The two together could be a very cutting edge solution.
>
> It does also have support for EJB 2.0 style descriptors.... Haven't tested
> this yet though.
>
> Cory
>
>
> At 09:37 AM 11/7/00 +0100, Frank Eggink wrote:
> >I guess I'm using neither.
> >
> >The clue is that, when you stick to the rules, you have to write the
> minimum one panel and one table
> >per dataobject as all the access to the properties is done via methods and
> each of those methods is
> >specific for the dataobjects (e.g. getName(), setName(x)). When you have a
> lot of dataobjects that is
> >a bore.
> >
> >The 'pattern' I'm using abstracts away (= marketing speak) from the clean
> OO model. The generator
> >generates standard bean access (getProperty(index), setProperty(index, x)
> and by using descriptors
> >for the dataobjects and its relations is it possible to generate default
> screens. Something you would
> >most likely use reflection for when that was possible.
> >
> >Using reflection has two problems:
> >- It does not work with Orion.
> >- It works only on a per object basis.
> >You could solve those by adding on the client side wrapper objects that
> implement Just-Another-Layer.
> >You can use reflection for that layer and if you device you object in a
> clever way (using clever naming
> >patterns) you -can- use reflection.
> >
> >Why the complex stuff and not generating the tables and the panel. Well,
> in the system I'm using I plan
> >to implement the option for users/systemmanager to tailor their screens.
> You can do that when you
> >generate screen on the fly, you can't when they are already compiled.
> >
> >It is a bit of an excercise but I am always strongly in favour to use as
> less as possible code to build your
> >final system. A lot of bugs stem from silly mistakes: the less code, the
> less silly mistakes. And if in the
> >above generator there is a silly mistake it is reproduced in a lot of
> places: more chance to be discovered.
> >
> >
> >I guess the same model could be used for dynamic creation of HTML.
> >
> >Frank
> >
> >On Monday, November 06, 2000 11:16 AM, Cory Adams
> [SMTP:[EMAIL PROTECTED]] wrote:
> >> Are you using the command or business object pattern?
> >>
> >> At 08:49 AM 11/6/00 +0100, Frank Eggink wrote:
> >> >I'm using Swing instead of JSP.
> >> >
> >> >On Sunday, November 05, 2000 9:04 PM, Cory Adams
> >> [SMTP:[EMAIL PROTECTED]] wrote:
> >> >> Thanks for that update.
> >> >>
> >> >> Do you or does anyone else know of the MVC (model - view - control)
> pattern
> >> >> used with JSP - Servlets and EJB? I have read that a single servlet
> >> >> becomes that controlling mechanism to the EJBs. I wondering how that is
> >> >> done?
> >> >>
> >> >> Cory
> >> >>
> >> >> At 10:23 PM 11/5/00 +0100, Frank Eggink wrote:
> >> >> >My personal trade off was:
> >> >> >
> >> >> >Why not CMP 2.0 style:
> >> >> >- Too scared to use it for real as it is not even officially there ...
> >> >> >
> >> >> >Why choose for CMP 1.1?
> >> >> >- CMP is more portable (across db's).
> >> >> >- Working already towards EJB2.0.
> >> >> >- The claim is CMP can be optimized better (I would be happy to know
> more
> >> >> details about that, until that time it is a bit
> >> >> >of a bet on a blackhorse for me).
> >> >> >
> >> >> >Why choose for BMP?
> >> >> >- I do not know yet whether I'll run into trouble with complex and
> highly
> >> >> flexible queries requirements
> >> >> >for Query By Example forms. The requirement for extra flexibility could
> >> >> become an argument.
> >> >> >
> >> >> >I would say if you can spend the time learning enough about CMP 1.1 I
> >> >> would go for that as a first option. The EJB1.1
> >> >> >specs are even written so that you can sub class a CMP bean to create a
> >> >> BMP bean.
> >> >> >
> >> >> >
> >> >> >One of the biggest disadavantages of EJB's is the tremendous amount of
> >> >> redundant code you have to write. Add for
> >> >> >instance a field to a bean. You'll have to change three files
> minimum and
> >> >> don't make mistakes as that will cost you time.
> >> >> >This disadavantage applies to both CMP and BMP and will apply to
> EJB2.0 as
> >> >> well.
> >> >> >
> >> >> >
> >> >> >What I'm doing is using EJB1.1 CMP and generate beans and stuff using a
> >> >> slightly more advanced bean
> >> >> >generator then the standard ones. Based on a datamodel
> (Entity-Relation)
> >> >> it generates a set of beans for
> >> >> >your application (including the remote and home interfaces and the
> *.xml
> >> >> files of course). The generated
> >> >> >beans include the fields, the finder queries, the additional methods to
> >> >> retrieve related beans etc.
> >> >> >
> >> >> >As an additional bonus the beans include a more abstract way to
> access the
> >> >> properties (myBean.getProperty(int index))
> >> >> >as the client side of orion does not allow reflection. I use that to
> >> >> generate forms and tables on the client.
> >> >> >
> >> >> >The generator adds a tremendous flexibility (I can switch to BMP /
> EJB2.0
> >> >> easily), makes CMP 1.1 managable and
> >> >> >keeps me away from EJB2.0 while it is still too early for me. For the
> >> >> rest: Im a notoruios mifftyper and am able to
> >> >> >spend tons of time debug typos in 2638 lines of very closely resembling
> >> >> code. That problem is solved as well :-)
> >> >> >
> >> >> >
> >> >> >Frank
> >> >> >
> >> >> >On Saturday, November 04, 2000 12:10 AM, Cory Adams
> >> >> [SMTP:[EMAIL PROTECTED]] wrote:
> >> >> >> At 11:44 PM 11/3/00 +0100, Robert Krueger wrote:
> >> >> >> >At 11:23 03.11.00 , you wrote:
> >> >> >> >>I have looked through the 2.0 spec and find the chapters regarding
> >> CMP to
> >> >> >> >>be daunting. It appears as though the complexity of writing my own
> >> >> SQL in
> >> >> >> >>BMP has to be balanced against learning an entire new way of
> managin
> >> >> >> >>persistence within the XML deployment descriptors which seems to
> be no
> >> >> less
> >> >> >> >>or perhaps even more complicated than BMP????
> >> >> >> >>
> >> >> >> >>Or am I missing something with regard to CMP being easier?
> >> >> >> >
> >> >> >> >yes, two things:
> >> >> >> >
> >> >> >> >1. your code including the queries is guaranteed to be portable
> between
> >> >> ejb
> >> >> >> >servers and databases (that's the theory)
> >> >> >> >2. you cannot possibly make optimizations using BMP that the
> container
> >> >> can
> >> >> >> >make using CMP
> >> >> >> >
> >> >> >> >why do you have to use ejb2.0 CMP? you didn't mention 1.1 cmp as an
> >> >> >> >alternative?
> >> >> >> >
> >> >> >>
> >> >> >> Hmmm..... I can find even less regarding 1.1 CMP. I have the
> >> ORielly book
> >> >> >> as well as the Mastering EJB books. The 2.0 spec is what I'm using
> >> because
> >> >> >> I would think (perhaps wrongly) that EJB 2.0 would maybe be easier
> >> and or
> >> >> >> offer more functionality??? Chapters 9 and 10 are over 100 pages
> which
> >> >> >> have to do with CMP. The last thing I need to do is learn another
> query
> >> >> >> language which is what some of the 2.0 spec seemed to indicate I
> >> would need
> >> >> >> to do....
> >> >> >>
> >> >> >> I also understand points 1 and 2 above but they do not address my
> >> original
> >> >> >> question of the relative complexity between BMP and CMP. Basically 1
> >> and 2
> >> >> >> are irrelevant to me if I can not implement CMP and can not
> practically
> >> >> >> compare the relative complexity between the two because I just don't
> >> >> >> understand CMP so I will keep digging through examples and utilize
> >> the post
> >> >> >> that has been helpful that somebody posted earlier today :
> >> >> >> http://www.execpc.com/~gopalan/java/entity.html .
> >> >> >>
> >> >> >> Thanks,
> >> >> >>
> >> >> >> Cory
> >> >> >>
> >> >> >>
> >> >> >> >regards,
> >> >> >> >
> >> >> >> >robert
> >> >> >> >
> >> >> >> >>Thanks,
> >> >> >> >>
> >> >> >> >>Cory
> >> >> >> >
> >> >> >> >(-) Robert Kruger
> >> >> >> >(-) SIGNAL 7 Gesellschaft fur Informationstechnologie mbH
> >> >> >> >(-) Bruder-Knau?-Str. 79 - 64285 Darmstadt,
> >> >> >> >(-) Tel: 06151 665401, Fax: 06151 665373
> >> >> >> >(-) [EMAIL PROTECTED], www.signal7.de
> >> >> >> >
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>
