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