This can be complex as you have to indicate which relation to use. Does it
only work for simple cases?
For instance below you have three relations to the field person.name
1. one direct
2. via father
3. via mother
Table person(name, father_fk, mother_fk);
Translating to:
class person {
.
.
.
private String name
private father person
private mother person
}
Frank
On Tuesday, November 07, 2000 9:47 PM, Cory Adams [SMTP:[EMAIL PROTECTED]]
wrote:
> It appears as though you can define/select any number of tables and or
> fields from different tables to define what makes up the fields within an
> entity bean.
>
> Cory
>
> At 10:12 PM 11/7/00 +0100, Frank Eggink wrote:
> >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
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >> >
> >> >> >> >>
> >> >> >> >
> >> >> >> >
> >> >> >>
> >> >> >
> >> >> >
> >> >>
> >> >
> >> >
> >>
> >
> >
>
