Simon,

I found this interesting as I'm starting to do a bit of Java myself. From
what I've found so far it has good and bad points, just like any language.
Some lift it above OpenROAD's level and some seem clumsy by comparison but
that's probably largely down to my lack of experience with it.

I don't agree with your points about getting a button click (simple matter of
registering a listener and coding event code for it) or the SQL point.
OpenROAD is the only language I've seen where you can put SQL directly into
scripts. VB, Perl etc. all require the use of some form of data access object
e.g ADO, DBI involving submitting SQL as a string and looking at a returned
resultset. It's a pain when you're used to using OpenROAD's nicer solution.
However, even OpenROAD comes adrift in some circumstances e.g dropping a
session table (resulting in a syntax error picked up), requiring the SQL to
be specified in a string.

There would be a variety of reasons for wanting to move an ABF application to
Java e.g class-based environment, nicer GUI. As you say though, and given my
limited experience with Java, I can't think of that many "technical" reasons
for wanting to take an OpenROAD app into Java.

IMHO most popular languages have good and bad points, good and bad being
decided upon by the purpose of using the language, level of experience etc.
However, very few languages could be described as being "good" or "bad" as a
whole.

There, lit the touch paper.... time to stand back and be flamed or not!

Regards,
Jim


-----Original Message-----
From: Simon Lovell [mailto:simon (AT) delta-link (DOT) com.au]
Sent: 02 March 2005 01:23
To: info-ingres (AT) cariboulake (DOT) com
Cc: OpenROAD Users (E-mail)
Subject: Re: [Openroad-users] RE: [Info-ingres] Re: Migrating ABF code
to J2EE


*************************************

This e-mail has been received by the Revenue Internet e-mail service.

*************************************

Hi All,
I've bit my tongue on this for a while, but since no-one else has commented;
why would you want to migrate to Java?
OpenROAD is a much better development platform, especially now that there is
an eClient available. What you have to do in Java to just get a button to
listen for clicks, not to mention the requirement to format a string to run
an SQL statement; there has to be a better way. Perhaps some IDEs overcome
these limitations in ways I haven't seen or heard of, but barring this, I
think the better way is to use a different tool.

I've been involved in 2 Transforge projects, and while it's far from
perfect, it beats a re-write from scratch. Especially if the proposed
re-write were in Java.

My 2 cents worth.

----- Original Message -----
From: "Paul White" <pwhite (AT) peerlessit (DOT) com.au>
To: <info-ingres (AT) cariboulake (DOT) com>
Cc: "OpenROAD Users (E-mail)" <openroad-users (AT) peerlessit (DOT) com>
Sent: Friday, February 25, 2005 12:00 PM
Subject: [Openroad-users] RE: [Info-ingres] Re: Migrating ABF code to J2EE



_______________________________________________
Openroad-users mailing list
Openroad-users (AT) peerlessit (DOT) com
http://www.peerlessit.com/mailman/li...openroad-users




************************

This message has been delivered to the Internet by the Revenue Internet e-mail service

*************************

Hi All,
I can see that I stirred things up by introducing the ABF to J2EE topic
:-)

The reason I was suggesting moving to J2EE, instead of OpenRoad, is
because many people these days are interested in web-based
applications. Last time I looked (a long time ago!) OpenRoad was a
client-server environment.

So I was thinking about a front-end based around HTML (or Java Server
Pages using Tag libraries or Struts), with a Middle layer holding the
Business Logic,

So the environment would look like this:
Browser ->
WebServer for Display Logic ->
EJB Application Server for Business Logic (such as JBOSS, also
OpenSource from CA ) ->
Relational Database

Knowing that ABF apps consist of Forms (Display Logic) and Frames
(Business Logic), I was wondering whether they could be mapped.

However, as Roy and others have pointed out, it's no simple job to
morph a procedural language into an Object-Orientated one. The
resulting code would be a mess.

The only real value is that you would have "web-enabled" your app.
Which might be quite a plus for some people, because it would preserve
their Ingres investment, and provide an interim solution until they are
able to re-write the business logic "properly".

Dennis