Powerbuilder vs. Java
Bill Barbour
I have been a Powerbuilder developer for 1.5 years. Recently, my management has said
that they consider Powerbuilder to be a transitional tool only. They believe that our
future application development will be Java-based because Java will not have the
distribution problems that we have experienced with Powerbuilder (our tech support
people insist that our apps reside on the client machines) and will be more
platform-independent than Powerbuilder.
Since I have no experience with Java or JavaScript, I'd like to post the following
questions:
-- Has anyone put Powerbuilder apps on a Web page? How has this gone?
-- Does Java supplant Powerbuilder or is it complimentary to it?
-- How mature are the tools for creating Java applets when compared to
Powerbuilder's developer environment?
I'm sure that there are more questions about Java/JavaScript vs.
Powerbuilder/PowerScript that I haven't the technical wherewithall to ask. I'd
appreciate any feedback, particularly from developers with experience in both
Powerbuilder and Java.
Thanks for your attention, time, and consideration.
Dave Writz
Bill Barbour <bbar...@ole.net> wrote:
>I have been a Powerbuilder developer for 1.5 years. Recently, my management has said
>that they consider Powerbuilder to be a transitional tool only. They believe that our
>future application development will be Java-based because Java will not have the
>distribution problems that we have experienced with Powerbuilder (our tech support
>people insist that our apps reside on the client machines) and will be more
>platform-independent than Powerbuilder.
>Since I have no experience with Java or JavaScript, I'd like to post the following
>questions:
> -- Has anyone put Powerbuilder apps on a Web page? How has this gone?
Powersoft's Internet strategy includes a product called Web.PB. I
have created applications using the beta version. This allows your
distributed PowerBuilder application to be run as a CGI application on
a web server.
In addition, Powersoft has datawindow plugin for Netscape. this
allows you to create simple applications that will function in the
Netscape browser.
Both of these techniques allow you to leverage your investment in
PowerBuilder while expanding into the internet....
> -- Does Java supplant Powerbuilder or is it complimentary to it?
Jury is still out on that.....
> -- How mature are the tools for creating Java applets when compared to
> Powerbuilder's developer environment?
I have only used one Java development tool, Symantec's Cafe. While
this tool is much nicer than developing Java from the command line, it
is no where near as nice as the PowerBuilder environment.
>I'm sure that there are more questions about Java/JavaScript vs.
>Powerbuilder/PowerScript that I haven't the technical wherewithall to ask. I'd
>appreciate any feedback, particularly from developers with experience in both
>Powerbuilder and Java.
Let me know if you have any specific questions.
>Thanks for your attention, time, and consideration.
Dave Writz (da...@crnrstne.com)
Cornerstone Consulting
414-351-6007
www.crnrstne.com
Shelley Powers
I have worked with PB for a few years now, and have am now also
working with Java.
I am in process of creating an ActiveX control and a Java Applet
to create an on-line mineral show and I found the Java to be
a much easier process.
Now comes the however: However, I think of all the client-server
apps I have worked on and the thought of doing this with Java
makes me want to cring. If I were offered an assignment to
convert a pretty standard PB app (and we know what these are like
- all sorts of different datawindows, and windows and MDI, etc)
to Java, I would decline. Java is just now starting (and I mean
just now) to work with database support with the JDBC. It
does not have anywhere near the sophisticated data output such
as the good old PB datawindow. Java itself does not have any
graphics design and development tools, though there are starting
to be some out. However, I have worked with Java WorkShop from
Sun and Microsoft's Visual J++ and they do not have the
ease of use that PB has. Think of Java as a form of C++ and
all those arguments for an against C++ would also work for Java.
You can create standalone Java Applications. And Java is more
portable. However, I find it unlikely that you could migrate
your current apps, at all. If you could, it will probably take you
about three or four times as long, and they would not have
the sophistication your would like for your app.
For web support, Java applets of course work, we see that. So
does the datawindow and window plugins and web.pb. However,
no reason you can't use all of these tools. A good shop makes
use of multiple tools.
I am confused about your statement that your tech support wants all
the apps to reside on the client, then you ask if these work
with the Web. If you are placing the apps on the client I am
unsure of where the web comes in. Also, when you mentioned
distribution are all your clients different types such as Mac,
UNIX, and Windows, or did you mean that you have trouble with
distributing the files.
If the latter is true, you could
use the web for one thing: Place the update files on the web
server and with an extension such as zip or exe that will cause them
to be downloadable.
Start a system where everyone logs into their own home page on
the web every morning. The home pages would have components that
are included that are basically generic announcements. When you want
to distribute, put out a notice of what the distribution covers and
how to install and then put in a link to the file. A very nice
use of a company web installation. You have used the web to cover your
distribution problems, and still used PB to create your more
sophisticated client-server app.
And you will use Java for some inline form or image and you will
use JavaScript (scripting language, do not expect much from this)
to test for form contents or other goodies.
Last question: PB and Java compliment each other
Shelley
Bill Barbour wrote:
>
> I have been a Powerbuilder developer for 1.5 years. Recently, my management has said
> that they consider Powerbuilder to be a transitional tool only. They believe that our
> future application development will be Java-based because Java will not have the
> distribution problems that we have experienced with Powerbuilder (our tech support
> people insist that our apps reside on the client machines) and will be more
> platform-independent than Powerbuilder.
>
> Since I have no experience with Java or JavaScript, I'd like to post the following
> questions:
>
> -- Has anyone put Powerbuilder apps on a Web page? How has this gone?
>
> -- Does Java supplant Powerbuilder or is it complimentary to it?
>
> -- How mature are the tools for creating Java applets when compared to
> Powerbuilder's developer environment?
>
> I'm sure that there are more questions about Java/JavaScript vs.
> Powerbuilder/PowerScript that I haven't the technical wherewithall to ask. I'd
> appreciate any feedback, particularly from developers with experience in both
> Powerbuilder and Java.
>
> Thanks for your attention, time, and consideration.
--
=========================================
Shelley Powers YASD Web Development
shel...@yasd.com http://www.yasd.com
$0.02
Jerry Kreps
Bill,
Do they know that java applets do not write to client HDs? If they
did, would your management people want other java applets to write to
their servers? That's the most unsafe computer sex I know of! Do
you know where their applet has been? ;-)
If they do then I have some ocean front property in Montana that I
would be willing to sell them! ;-)
BTW - I'm using PB 5.0 to create web pages with the push of a command
button using the Sybase SQL Anywhere 5.0 database that came with my
DeskTop version. Then I upload the HTML pages to my website. From
what I've been able to discern, if you use PB to build web services
you must make a formless app. But, if you do that then the only
event you can monitor is the keyboard event so you can hot-key your
program shut-down, sort of like the old TSRs. I'm not willing to try
that yet.
Jerry
Bill Barbour <bbar...@ole.net> wrote in article
<320E2A...@ole.net>...
Ken Howe
PB plug in for netscape works quite well with a few
exceptions. The runtime DLL's are still required,
and you cannot do MDI. Also your code must be very
encapsulated as you cannot have any global
variables.
Other than those limitations the web never looked
so good.
--
Ken Howe
10421...@compuserve.com (home)
kho...@entergy.com (work)
http://ourworld.compuserve.com/homepages/Howe (PB
Tips Web site)
Mike Swaim
Bill Barbour (bbar...@ole.net) wrote:
: Since I have no experience with Java or JavaScript, I'd like to post the following
: questions:
I have yet to actually write a Java applet, but I have two big binders of
Java reference material, and I've experimented with some client/server
stuff over the web, so I'm willing to play the expert. Also, my bosses
occasionally make noises about redoing our app as a Web thing, so I've
thought about this, somewhat.
: -- Has anyone put Powerbuilder apps on a Web page? How has this gone?
I haven't done this. Otoh, if you're just doing simple data entry or
simple queries, and you're using MicroSoft's web server, they have a
server plug in that lets you write HTML that'll talk to ODBC data
sources. Not hard at all.
: -- Does Java supplant Powerbuilder or is it complimentary to it?
Java doesn't know squat about databases. If I were to try to deploy a
C/S application using Java, I'd definately use a middleware app to
translate between the Java app and the database.
: -- How mature are the tools for creating Java applets when compared to
: Powerbuilder's developer environment?
MicroSoft's J++ development suite is supposed to be nice. I strongly
suspect that the Java development tools are more robust than PB. They may
not be as easy to use, though.
: I'm sure that there are more questions about Java/JavaScript vs.
: Powerbuilder/PowerScript that I haven't the technical wherewithall to ask.
The question that I'd ask is, "What are you going to use it for?"
Java's nice for running small applications on random machines, but has no
clue how to talk to databases. If you need some sort of C/S application,
and you're not distributing to the general public, I think that I'd stick
with PowerBuilder.
--
Mike "Special Agent in charge of Chaos" Swaim, sw...@phoenix.net, I lie.
'Many so-called "guardian angels" have taken up that occuparion not
because they are so concerned for the well being of their earthly
charges, but because they are voyeurs.' -_Cosmic_Relief_ by Connie Schmidt
Matt Taylor
In article <4uqd2i$k...@uhura.phoenix.net>, sw...@alpha1.phoenix.net
says...
>: -- Does Java supplant Powerbuilder or is it complimentary to it?
> Java doesn't know squat about databases. If I were to try to deploy a
>C/S application using Java, I'd definately use a middleware app to
>translate between the Java app and the database.
I hope Java never knows "squat" about databases. The best of all
possible worlds is the have the database server handle SQL strings and
just return the info to Java to display. I think embedded SQL is not
only the JAVA way, it's the way most things are done now, and the Net
will only reinforce this.
The real question is whether JDBC implementation will be better than ODBC
implementation, so that there is more efficient communication between the
application and database engine layers. No?
Matt Taylor
Academic Book Center
"Not quite. The Internet IS the Database."
- Joseph Roubidoux, upon hearing Sun's "The network IS the computer."
Shelley Powers
Hi Mike.
I believe and have said that to replace PB with Java is
not a wise course.
However, I also believe in distributing knowledge so...
Mike Swaim wrote:
> I have yet to actually write a Java applet, but I have two big binders of
> Java reference material, and I've experimented with some client/server
> stuff over the web, so I'm willing to play the expert. Also, my bosses
> occasionally make noises about redoing our app as a Web thing, so I've
> thought about this, somewhat.
>
PB web tools...
> I haven't done this. Otoh, if you're just doing simple data entry or
> simple queries, and you're using MicroSoft's web server, they have a
> server plug in that lets you write HTML that'll talk to ODBC data
> sources. Not hard at all.
>
Actually, this extensibility is not just inherent to Microsoft...
You can call Stored Procedures if you are using Oracle web server,
and there are CGI libraries to encapsulate SQL access, and
Netscape has just released LiveWire where you can make SQL calls
using Server side javascript.
Nice to have choice
> : -- Does Java supplant Powerbuilder or is it complimentary to it?
> Java doesn't know squat about databases. If I were to try to deploy a
> C/S application using Java, I'd definately use a middleware app to
> translate between the Java app and the database.
Well, this isn't exactly true. Have you been keeping up with
the JDBC API, which provide an API for Java for accessing database?
They have drivers for Solaris and Windows 95/NT JDBC to ODBC
and most database companies such as Oracle have committed to
providing drivers for this. Take a look at
http://splash.javasoft.com/jdbc/. It is fairly new, but so is
most web stuff.
And I think of Java as complimentary.
> : -- How mature are the tools for creating Java applets when compared to
> : Powerbuilder's developer environment?
> MicroSoft's J++ development suite is supposed to be nice. I strongly
> suspect that the Java development tools are more robust than PB. They may
> not be as easy to use, though.
Agree, and I have both Sun's Java WorkShop (which has a
most unusual exit technique) and Visual J++. If you have
used Visual C++ you will know the level these tools are at...
PB does handle much more of the code for you.
> : I'm sure that there are more questions about Java/JavaScript vs.
> : Powerbuilder/PowerScript that I haven't the technical wherewithall to ask.
> The question that I'd ask is, "What are you going to use it for?"
> Java's nice for running small applications on random machines, but has no
> clue how to talk to databases. If you need some sort of C/S application,
> and you're not distributing to the general public, I think that I'd stick
> with PowerBuilder.
Well, if you need to have interactivity on a web page, consider
Java. If you need simple JDBC based forms, try Java. If you
have a mega PB app that you are thinking of porting to Java,
please ask yourself "Do you feel lucky?".
> --
> Mike "Special Agent in charge of Chaos" Swaim, sw...@phoenix.net, I l
Bye
Shelley
William Harris
In article <320E2A...@ole.net>, bbar...@ole.net says...
>I have been a Powerbuilder developer for 1.5 years. Recently, my management
has said
>that they consider Powerbuilder to be a transitional tool only. They believe
that our
>future application development will be Java-based because Java will not have
the
>distribution problems that we have experienced with Powerbuilder (our tech
support
>people insist that our apps reside on the client machines) and will be more
>platform-independent than Powerbuilder.
Java is not yet mature enough to create applications. In particular, the
windowing library (AWT) is pathatic in comparison to Powerbuilder. The
database access specifications (JDBC) are still in the "open for comment"
phase. Tools available for Java (like Symantec's Cafe) are decent, but don't
offer nearly the capability of Powerbuilder, and where they offer limited
screen painting abilities, they often sacrifice platform portability to do so.
Java itself is not nearly as platform-independant as Sun would have you
believe. I offer as an example the non-implementation under the Windows
environment of the FilenameFilter capability in the FileDialog class.
I like Java as a language. Unlike Powerbuilder, it doesn't crash my computer
half a dozen times a day. :-) But it's got a long way to go before the tools
available catch up to Powerbuilder.
>Since I have no experience with Java or JavaScript, I'd like to post the
following
>questions:
Bite your tongue. :-) Java is not JavaScript, has no relation to it other
than the fact that both look like C, and it is better to think of JavaScript as
NetscapeScript.
--
William Harris wil...@carsinfo.com
CARS Information Systems
4000 Executive Park Drive
Cincinnati, OH (USA) 45241
George Reese
William Harris (wil...@carsinfo.com) wrote:
: In article <320E2A...@ole.net>, bbar...@ole.net says...
: >I have been a Powerbuilder developer for 1.5 years. Recently, my management
: has said
: >that they consider Powerbuilder to be a transitional tool only. They believe
: that our
: >future application development will be Java-based because Java will not have
: the
: >distribution problems that we have experienced with Powerbuilder (our tech
: support
: >people insist that our apps reside on the client machines) and will be more
: >platform-independent than Powerbuilder.
:
: Java is not yet mature enough to create applications. In particular, the
: windowing library (AWT) is pathatic in comparison to Powerbuilder.
Which happens to be pathetic in comparison to Delphi.
However, this is quickly being resolved by at least both Symantec and
Borland with their Visual Cafe and Latte products respectively.
: The
: database access specifications (JDBC) are still in the "open for comment"
: phase.
No, it is in its release form. Quite solid. Of course, that takes
care of part of the trick. It is now up to tools vendors to write
persistence libraries using relational databases for persistence.
: Tools available for Java (like Symantec's Cafe) are decent, but don't
: offer nearly the capability of Powerbuilder, and where they offer limited
: screen painting abilities, they often sacrifice platform portability to do so.
Well, how long has Java been in full release? 7 months?
The AWT sucks. But it will get better, it has to. It is well set for
its current stage. And the tools I mentioned above should help go
along way to addressing this.
On the other hand, let's talk about PowerBuilder real quick.
What exactly does it have? One thing: GUI -> database mapping in the
form of data windows.
And this solution sucks since it does not scale well across databases,
and, more important, ties the presentation of objects DIRECTLY to
their relational representation. It is not suited well to a
three-tier architecture. And it is not suited at all to an
object-oriented three-tier architecture.
And that is PowerBuilder's strength.
Let's talk about its weaknesses.
#1 It is prhaps the most bug-filled commercial grade application I hve
ever encountered excepting perhaps CorelDraw 4. GPF's are a way of
life.
#2 The trick to PowerBuilder coding is not learnign the tool,
but learning how to get around its limitations.
#3 PowerSoft technical support (you pay for the priveledge of
debugging their tools)
#4 PowerScript (what an oxymoron)
#5 the function/event dichotomy
And that is just stuff that jumps to mind in a rant.
: Java itself is not nearly as platform-independant as Sun would have you
: believe. I offer as an example the non-implementation under the Windows
: environment of the FilenameFilter capability in the FileDialog class.
:
: I like Java as a language. Unlike Powerbuilder, it doesn't crash my computer
: half a dozen times a day. :-) But it's got a long way to go before the tools
: available catch up to Powerbuilder.
Oh, you mentioned stability :)
--
George Reese (bo...@imaginary.com) http://www.imaginary.com/~borg
i think i've reached that point/where every wish has come true/
and tired disguised oblivion/is everything i do
-the cure
Matt Kennel
Matt Taylor (mta...@acbc.com) wrote:
: In article <4uqd2i$k...@uhura.phoenix.net>, sw...@alpha1.phoenix.net
: says...
: >: -- Does Java supplant Powerbuilder or is it complimentary to it?
: > Java doesn't know squat about databases. If I were to try to deploy a
: >C/S application using Java, I'd definately use a middleware app to
: >translate between the Java app and the database.
: I hope Java never knows "squat" about databases. The best of all
: possible worlds is the have the database server handle SQL strings and
: just return the info to Java to display. I think embedded SQL is not
: only the JAVA way, it's the way most things are done now, and the Net
: will only reinforce this.
Right. Shouldn't it be the other way around?
Shouldn't *databases* know Java? I.e. instead of making
calls with a text-based "SQL" one should make calls with idiomatic
Java objects + classes implemented by the database software.
: Matt Taylor
: Academic Book Center
--
Matthew B. Kennel/m...@caffeine.engr.utk.edu/I do not speak for ORNL, DOE or UT
Oak Ridge National Laboratory/University of Tennessee, Knoxville, TN USA/
I would not, could not SAVE ON PHONE,
I would not, could not BUY YOUR LOAN,
I would not, could not MAKE MONEY FAST,
I would not, could not SEND NO CA$H,
I would not, could not SEE YOUR SITE,
I would not, could not EAT VEG-I-MITE,
I do *not* *like* GREEN CARDS AND SPAM! Mad-I-Am! (inspired: PvdL)
Jim Mangione
I can see these two working together in a way:
With large scale apps already developed in Powerbuilder, perhaps these
can ported to a server (in powerbuilder 5 this supposedly can be done)
and used solely as "agents" ... a middle layer, handling the DB stuff
only, and passing back results to a the client, platform-independant JAVA
app.
I've been a PB person for about 3 years, and see the future
client/internet development being JAVA (thank God), but as stated
earlier, JAVA should not be responsible for DB communication.
My two-cents!
Jim Mangione
George Reese
Jim Mangione (mang...@pt.cyanamid.com) wrote:
: I can see these two working together in a way:
Why? Java is an excellent language for object-to-relational
modeling. You just have to rethink the way you program your
client/server applications.
Specifically, the way things are dne in a common PowerBuilder two-tier
environment is that you request data from the database and display it
in a DataWindow. The cool thing is that you can paint this Window
simply by selecting database fields and mapping them to a particular
widget. Point and click database acccess.
The bad thing is that in an OO environment, you don't want to be
dealing with data directly. What is on your screen is not really data
from a database, but business objects.
For example, let's say you are building an automobile tracking
pplication like your dealer might have to track your car from the time
it is built to the time it is demolished. The front end is not
viewing data, it is viewing cars. But powerbuilder treats it as data.
Java, on the other hand, let's you use the database as a prsistent
store. You use it to instantiate objects, and then your GUI
references those objects. This allows you to scale much easier, make
drastic database changes much easier, etc.
Tell me, for example, what happens if you decide you need to split
your database across two databases? Across two machines?
PowerBuilder does not like that very well :)
What happens if you want to build your application three-tier? There
are of course tools suited to the PowerBuilder crowd to help you do
this, but they certainly are not natural.
Matt Taylor
In article <4uvldo$b...@gaia.ns.utk.edu>, m...@caffeine.engr.utk.edu
says...
>
>Matt Taylor (mta...@acbc.com) wrote:
>: In article <4uqd2i$k...@uhura.phoenix.net>, sw...@alpha1.phoenix.net
>: says...
>
>: >: -- Does Java supplant Powerbuilder or is it complimentary to it?
>
>: > Java doesn't know squat about databases. If I were to try to deploy
a
>: >C/S application using Java, I'd definately use a middleware app to
>: >translate between the Java app and the database.
>
>: I hope Java never knows "squat" about databases. The best of all
>: possible worlds is the have the database server handle SQL strings and
>: just return the info to Java to display. I think embedded SQL is not
>: only the JAVA way, it's the way most things are done now, and the Net
>: will only reinforce this.
>
>Right. Shouldn't it be the other way around?
>
>Shouldn't *databases* know Java? I.e. instead of making
>calls with a text-based "SQL" one should make calls with idiomatic
>Java objects + classes implemented by the database software.
The current thing is sending SQL strings to the relationally structured
database. SQL3 (OO version) will have to come along, as well as more
vendor support of Java, before you pass data from database server table
objects to Java table subset objects or whatever. One step at a time.
Kolbjørn Aambø
In article <4uvmqa$e...@darla.visi.com>, bo...@visi.com (George Reese) wrote:
> William Harris (wil...@carsinfo.com) wrote:
<Snipped>
> And that is PowerBuilder's strength.
>
> Let's talk about its weaknesses.
>
> #1 It is prhaps the most bug-filled commercial grade application I hve
> ever encountered excepting perhaps CorelDraw 4. GPF's are a way of
> life.
> #2 The trick to PowerBuilder coding is not learnign the tool,
> but learning how to get around its limitations.
> #3 PowerSoft technical support (you pay for the priveledge of
> debugging their tools)
> #4 PowerScript (what an oxymoron)
> #5 the function/event dichotomy
>
> And that is just stuff that jumps to mind in a rant.
After working hard on a PowerBuilder App for more than a Year I must say
your critic of PowerBuilder is TO-THE-POINT.
I find it a little more stable on a Mac though, but still can't use things
like Binding even though that is what the Manual states as Default
setting!
> : Java itself is not nearly as platform-independant as Sun would have you
> : believe. I offer as an example the non-implementation under the Windows
> : environment of the FilenameFilter capability in the FileDialog class.
> :
> : I like Java as a language.
Me too, I like it because it remind me a lot of SIMULA 67 that I learned
programming with. If it one day can be compared to SIMULA when it comes to
stability of big programs and have debuggers in popular development
systems support JAVA as well as it support C++ I would look forward with a
little more optimism.....
PowerBuilder and ORACLE 7 almost *killed* me.
<Distressed programmer closing in on his first client-server project.>
Matt Taylor
In article <4uvmqa$e...@darla.visi.com>, bo...@visi.com says...
Check out the book due any time GRAPHIC JAVA: Mastering the AWT.
Contains lots of new components in a custom class called GJL Graphical
Java Toolkit. The author is an experienced OO fellow who has worked with
biggies like Boeing.
You can find a few pages of description at:
http://www.sun.com/smi/ssoftpress/books/Geary/Geary.html
You'll see more and more of this. All of the companies out there who
have something to gain from not losing to Microsoft are going to pump
money into Java and the internet like you wouldn't believe in your
wildest dreams. It won't happen today, but if you get up on JDBC and the
AWT and Java in general (do some application stuff, not just the applet
crap; write to files, etc.) you should be ready to roll by the time the
wave hits.
Wayne Liu
I am a new reader to this discussion and I found it is interesting because
I am facing the similar situation to determine the future direction of
Intranet C/S application development in my company. We also have PB and VB
applications talking to Mainframe and AS/400 today and trying to find a way
to build the business application on the web. What my main concern is the
DB connectivity and deployment. I would appreciate any comments on my
concern.
For the simple data entry or query, I can have hundreds of choices to build
the application such as CGI programming. However, if I deal with on-line
interactive data maintenance, especially when user needs to maintain 200
rows times 26 columns of data inside a grid control (or data window), I
really don't know "where do I want to go tomorrow" in the Intranet
application development.
I think the traditional CGI application is good for publishing, query and
simple data entry applications only. In terms of large amount of data
maintenance, I should have my Java applet talking directly to AS/400 or
Mainframe using JDBC type of connection. And I think my java applet is the
full function application that I write in PB or VB today. I don't know my
thinking is correct or not. Pls comment. Also, I don't know the JDBC can
serve this purpose or not.
On the deployment side, now we put the PB application and run time DLL on
the Novell serve and using Sybase MDI gateway talking to Mainframe. In this
situation, there is virtually no work needs to be done on the user machine
except the drive mapping. However, when I want to use VB and ODBC talking
to AS/400, I find that I hate the Microsoft approach. You need to install
Client/Access ODBC driver, config the ODBC and register the OCX in the
users' PCs. Even I also put my VB application on the Novell Server, I still
need the one time installation.
I really hope the Java or ActiveX technologies can solve my problem but I
don't know so much details on these two things. I am learning the Java
today but have no experience in JDBC. Pls feel free to share your idea with
me. Thks in advance for your advice and comment.
wayne
PS. Regarding to Bill's questions, I think it is not fair to compare Java
to PB and can't compare. Java is a language with some pre-defined class
(lib functions) which is similar to VC++ plus MFC. Of course, Java is
easier to learn than VC++. PB, in my opinion, it is a marketing product
focus on the Corporate RAD. Even you use VJ++, it is still much more like
VC++ than PB or VB.
Bill Barbour <bbar...@ole.net> wrote in article <320E2A...@ole.net>...
> I have been a Powerbuilder developer for 1.5 years. Recently, my
management has said
> that they consider Powerbuilder to be a transitional tool only. They
believe that our
> future application development will be Java-based because Java will not
have the
> distribution problems that we have experienced with Powerbuilder (our
tech support
> people insist that our apps reside on the client machines) and will be
more
> platform-independent than Powerbuilder.
>
> Since I have no experience with Java or JavaScript, I'd like to post the
following
> questions:
>
> -- Has anyone put Powerbuilder apps on a Web page? How has this gone?
>
> -- Does Java supplant Powerbuilder or is it complimentary to it?
>
> -- How mature are the tools for creating Java applets when compared to
> Powerbuilder's developer environment?
>
> I'm sure that there are more questions about Java/JavaScript vs.
> Powerbuilder/PowerScript that I haven't the technical wherewithall to
Francis Norton
In article <4v22gn$m...@igate2.pt.cyanamid.com>, Jim Mangione
<mang...@pt.cyanamid.com> writes
>I can see these two working together in a way:
>
>With large scale apps already developed in Powerbuilder, perhaps these
>can ported to a server (in powerbuilder 5 this supposedly can be done)
>and used solely as "agents" ... a middle layer, handling the DB stuff
>only, and passing back results to a the client, platform-independant JAVA
>app.
>
>I've been a PB person for about 3 years, and see the future
>client/internet development being JAVA (thank God), but as stated
>earlier, JAVA should not be responsible for DB communication.
>
>Jim Mangione
>
>
Apologies for a corporate plug, but I think it *is* relevent...
We've already beaten this path...
Our C/S tool AM (Application Manager) evolved earlier this year to a web
application tool called Amazon. We've been playing cross-platform C/S
for about six or seven years now, and developed some pretty mature
productivity tools - eg an SQL workbench for compiling Static SQL to do
high-performance direct access to the original poster's DB2 databases.
You can have multiple simultaneous threads open to multiple data sources
(eg DB2, Oracle, SQL/Server, ODBC) at the same time as doing eg CICS,
APPC, Sockets or 5250 screen scraping.
For a java front-end you might like to look at the slot-car circuit
applet on http://www.ieinc.com.
Francis.
--
Francis Norton
Wayne Liu
I do agree with your idea of working with object instead of pure data.
However, in the coperate world, we need to deal with large amount of rows
and columns of data, especially in the schedule and allocation planning
side. What they are doing everyday is to schedule or allocate the product
qty into each individual customer for the next 12 months for that product
item. In this situation, it is just a simple grid (or data window)
application. And this kind of app. is critical to our 3.8 billion business.
Today, I can easily retrieve those 200 row x 12 col of data into the grid
using ODBC. However, my next requirement is my user want to access these
data anywhere in the world no matter in the office or outside the office.
Then I think my solution is Internet app. But when I look at the CGI type
app., I can't believe I need to declare thousands of input fields to allow
the user to maintain these data. Also, after the CGI pgm finishes the
validation, it returns a new HTML page back to client brower and that is
what I don't like (This approach is OK for publishing but not for online
data maintenance; in my opinion). Fortunately, now we have AxtiveX and
java. But my concern is when I using ODBC, I need to install the ODBC
driver in the PC side in order to talk to AS/400. I don't know it works or
not in the Internet env. and I think I shouldn't be done. The ODBC driver
should be downloaded and configured automatically when the applet is
downloaded. I don't want to install anything on the user PC ahead except
the browser and TCP/IP connection. So that's why I think JDBC may work in
this approach but I am not sure. This is the reason I put my concern on
this forum to see anybody can give some idea.
Thks for your comment.
Wayne
George Reese <bo...@visi.com> wrote in article
<4v7gqg$c...@darla.visi.com>...
> Wayne Liu (liuw...@earthlink.net) wrote:
> : I am a new reader to this discussion and I found it is interesting
because
> : I am facing the similar situation to determine the future direction of
> : Intranet C/S application development in my company. We also have PB and
VB
> : applications talking to Mainframe and AS/400 today and trying to find a
way
> : to build the business application on the web. What my main concern is
the
> : DB connectivity and deployment. I would appreciate any comments on my
> : concern.
> :
> : For the simple data entry or query, I can have hundreds of choices to
build
> : the application such as CGI programming. However, if I deal with
on-line
> : interactive data maintenance, especially when user needs to maintain
200
> : rows times 26 columns of data inside a grid control (or data window), I
> : really don't know "where do I want to go tomorrow" in the Intranet
> : application development.
>
> PowerBuilder is clearly the best solution for simplistic online data
> maintainence. The DataWindow is simply the best tool there is for
> representing rows of relational data in a GUI. Unfortunately, you
> rarely simply want to represent rows of relational data on a screen.
>
> PowerBuilder falls apart in an object environment because it is so
> heavily married to the relational backend. It is almost impossible to
> construct the PB app so it is representing objects instead of pure
> data. That means, for example, that when you want to drag row 1 of
> your automobile inventory, car #4555, to another window, you are
> dragging a datawindow in PB's mind. You have to write of performance
> painful logic to get the application to understand you are dragging a
> car.
>
> And what if you wish to capture your business rules in a middle tier?
> It can be done in PB, but it is completely unnatural.
>
> JDBC is an excellent API for taking relational data out of a
> database. Add to it an object-to-relational class library, and you
> have an application that sees its world in terms of objects. Your GUI
> maps screen widgets to business objects instead of database rows. You
> drag one of those widgets, you will be dragging the actual business
> object.
George Reese
Miles T. Parker
I just got this, and its really worth a look; the classes included will
save a lot of us from having to reinvent the wheel...
Matt Taylor (mta...@acbc.com) wrote:
: In article <4uvmqa$e...@darla.visi.com>, bo...@visi.com says...
:
: Check out the book due any time GRAPHIC JAVA: Mastering the AWT.
: Contains lots of new components in a custom class called GJL Graphical
: Java Toolkit. The author is an experienced OO fellow who has worked with
: biggies like Boeing.
:
: You can find a few pages of description at:
:
: http://www.sun.com/smi/ssoftpress/books/Geary/Geary.html
:
: You'll see more and more of this. All of the companies out there who
: have something to gain from not losing to Microsoft are going to pump
: money into Java and the internet like you wouldn't believe in your
:
George Reese
Wayne Liu (liuw...@earthlink.net) wrote:
: I do agree with your idea of working with object instead of pure data.
: However, in the coperate world, we need to deal with large amount of rows
: and columns of data, especially in the schedule and allocation planning
: side. What they are doing everyday is to schedule or allocate the product
: qty into each individual customer for the next 12 months for that product
: item. In this situation, it is just a simple grid (or data window)
: application. And this kind of app. is critical to our 3.8 billion business.
Why is working with objects bad? Given the requirements below, I
would say it is good.
: Today, I can easily retrieve those 200 row x 12 col of data into the grid
: using ODBC. However, my next requirement is my user want to access these
: data anywhere in the world no matter in the office or outside the office.
: Then I think my solution is Internet app. But when I look at the CGI type
: app., I can't believe I need to declare thousands of input fields to allow
: the user to maintain these data. Also, after the CGI pgm finishes the
: validation, it returns a new HTML page back to client brower and that is
: what I don't like (This approach is OK for publishing but not for online
: data maintenance; in my opinion). Fortunately, now we have AxtiveX and
: java. But my concern is when I using ODBC, I need to install the ODBC
: driver in the PC side in order to talk to AS/400. I don't know it works or
: not in the Internet env. and I think I shouldn't be done. The ODBC driver
: should be downloaded and configured automatically when the applet is
: downloaded. I don't want to install anything on the user PC ahead except
: the browser and TCP/IP connection. So that's why I think JDBC may work in
: this approach but I am not sure. This is the reason I put my concern on
: this forum to see anybody can give some idea.
By showing rows of objects instantiated on the server, communicating
with the client using RMI, you minimize network traffic to that which
is essential and you also make it so people are operating on the same
data no matter where they are. Thus if I am viewing the same data you
are changing, I see the change the instant it happens.
Tilman Sporkert
I went and bought this book, mostly because I was curious about the GJT.
Well, there is a major problem: The GJT is practically useless because of the
license restrictions!!!
It starts out pretty well in the preface: "We'd like to emphasize use of the
Graphics Java Toolkit. In many ways, Graphic Java is not just a book with
an accompanying CD. It is a product with an accompanying book. ... and put
that toolkit to use"
Now lets check the license. Nothing on the CD itself, or inside the
Grfxjava.zip file. But there's one at the end of the book about the CD:
"... right to use and display the copy of the SOFTWARE on a single computer
at a single location... You may *not* copy the Documentation or the
SOFTWARE... You may *not* network the SOFTWARE or otherwise use it on more
than one computer or computer terminal at the same time. ... You may *not*
distribute copies of the SOFTWARE or Documentation to others. You may *not*
reverse engineer, disassemble, decompile, modify, adapter, translate, or
create derivative works based on the SOFTWARE or the Documentation without
the prior written consent of the Company. ... The enclosed SOFTWARE is
licenses only to you and may *not* be transferred to any one else without the
prior written consent of the Company."
I will try to contact the authors or publishers of this book, because this
is just complete nonsense. A book that is supposed to help me master the AWT,
but then I can't use the GJT for anything other than for my own entertainment?
If I build an applet using GJT components then I can't let others run it???
If I build my own widgets, I can get in trouble because it might be considered
derivative work? And if I don't like the book and the software,
I can't even give it to my co-worker without written permission?
Unfortunately, I already took out the CD, so legally, I can't return it
anymore. At least, I got 20% off, and I only paid $32.96 for a book with
a useless CD.
--
Tilman Sporkert Active Software, Inc. til...@activesw.com
Anything stated above is just my opinion, not an offical statement of
Active Softare, Inc.
Rachel Borden
There are no license restrictions on anything you build using the
Graphic Java Toolkit that comes with the Graphic Java book. The license
agreement printed at the back of the book is only supposed to apply to
the other software included on the CD-ROM -- not to the GJT itself.
This is a problem in the wording of the license that we will fix in
future printings of the book. I apologize for any confusion this has
caused.
- Rachel Borden
Publisher, SunSoft Press
>From Tilman Sporkert <til...@nscale.activesw.com>
Bernard James Leach
[ newsgroups line cut ]
Miles T. Parker (mi...@clark.net) wrote:
: I just got this, and its really worth a look; the classes included will
: save a lot of us from having to reinvent the wheel...
: Matt Taylor (mta...@acbc.com) wrote:
: : In article <4uvmqa$e...@darla.visi.com>, bo...@visi.com says...
: :
: : Check out the book due any time GRAPHIC JAVA: Mastering the AWT.
: : Contains lots of new components in a custom class called GJL Graphical
: : Java Toolkit. The author is an experienced OO fellow who has worked with
: : biggies like Boeing.
: :
: : You can find a few pages of description at:
: :
: : http://www.sun.com/smi/ssoftpress/books/Geary/Geary.html
What is the licensing on the Graphical Java Toolkit? If its
freely distributable is it available for ftp somewhere?
--
Bernard Leach La Trobe Uni Melbourne Australia
lea...@cs.latrobe.edu.au http://www.cs.latrobe.edu.au/~leachbj/
PGP FingerPrint: A3 48 0B 07 4D 9B E6 4A FA C1 C9 0A AF 83 09 BF
Tate Jones
Kolbjørn Aambø wrote:
>
> In article <4uvmqa$e...@darla.visi.com>, bo...@visi.com (George Reese) wrote:
>
> > William Harris (wil...@carsinfo.com) wrote:
> <Snipped>
> > And that is PowerBuilder's strength.
> >
> > Let's talk about its weaknesses.
> >
> > #1 It is prhaps the most bug-filled commercial grade application I hve
> > ever encountered excepting perhaps CorelDraw 4. GPF's are a way of
> > life.
> > #2 The trick to PowerBuilder coding is not learnign the tool,
> > but learning how to get around its limitations.
> > #3 PowerSoft technical support (you pay for the priveledge of
> > debugging their tools)
> > #4 PowerScript (what an oxymoron)
> > #5 the function/event dichotomy
> >
> > And that is just stuff that jumps to mind in a rant.
>
Powerbuilder GPF's piss me off too. However, i found about 90% were
caused by my own programming bad habbits. I now used a stable class
library and enforce strong OO techinques, very simular to Java. I
haven't seen GPF's for a good 12 months. Remember windows is not a
stable enviro too.
Tate.
George Reese
Tate Jones (ta...@mistral.co.uk) wrote:
Everyone makes mistakes in development. That is why you test things.
PowerBuilder is the only development environment I have used that
GPF's because you sneezed at it. It even GPF's when you do not make
mistakes.
Keep in mind, this is a tool that is supposed to produce safe-code,
like Java. Unlike C/C++.
Bernard James Leach
Rachel Borden (rac...@Eng.Sun.COM) wrote:
: There are no license restrictions on anything you build using the
: Graphic Java Toolkit that comes with the Graphic Java book. The license
: agreement printed at the back of the book is only supposed to apply to
: the other software included on the CD-ROM -- not to the GJT itself.
: This is a problem in the wording of the license that we will fix in
: future printings of the book. I apologize for any confusion this has
: caused.
: - Rachel Borden
: Publisher, SunSoft Press
But the GJT is only available on the CD with the book?
: >From Tilman Sporkert <til...@nscale.activesw.com>
: >I went and bought this book, mostly because I was curious about the GJT.
: >Well, there is a major problem: The GJT is practically useless because of the
: >license restrictions!!!
: >It starts out pretty well in the preface: "We'd like to emphasize use of the
: >Graphics Java Toolkit. In many ways, Graphic Java is not just a book with
: >an accompanying CD. It is a product with an accompanying book. ... and put
: >that toolkit to use"
roger day
Wayne Liu wrote:
>
> I am a new reader to this discussion and I found it is interesting because
> I am facing the similar situation to determine the future direction of
> Intranet C/S application development in my company. We also have PB and VB
> applications talking to Mainframe and AS/400 today and trying to find a way
> to build the business application on the web. What my main concern is the
> DB connectivity and deployment. I would appreciate any comments on my
> concern.
>
> For the simple data entry or query, I can have hundreds of choices to build
> the application such as CGI programming. However, if I deal with on-line
> interactive data maintenance, especially when user needs to maintain 200
> rows times 26 columns of data inside a grid control (or data window), I
> really don't know "where do I want to go tomorrow" in the Intranet
> application development.
>
> simple data entry applications only. In terms of large amount of data
> maintenance, I should have my Java applet talking directly to AS/400 or
> Mainframe using JDBC type of connection. And I think my java applet is the
> full function application that I write in PB or VB today. I don't know my
> thinking is correct or not. Pls comment. Also, I don't know the JDBC can
> serve this purpose or not.
>
> On the deployment side, now we put the PB application and run time DLL on
> the Novell serve and using Sybase MDI gateway talking to Mainframe. In this
> situation, there is virtually no work needs to be done on the user machine
> except the drive mapping. However, when I want to use VB and ODBC talking
> to AS/400, I find that I hate the Microsoft approach. You need to install
> Client/Access ODBC driver, config the ODBC and register the OCX in the
> users' PCs. Even I also put my VB application on the Novell Server, I still
> need the one time installation.
>
> I really hope the Java or ActiveX technologies can solve my problem but I
> don't know so much details on these two things. I am learning the Java
> today but have no experience in JDBC. Pls feel free to share your idea with
> me. Thks in advance for your advice and comment.
>
> wayne
You could use either Java Servlets or FastCGI. Both overcome CGI
problems, in thatthe launched process/servlet remains live between
connections. They're almost like real servers.
Roger.
--
====================================================================
poetry ( http://www.ssynth.co.uk/~rday/poet_mag.html )
politics ( http://www.McSpotlight.org/ )
pussy ( http://www.ssynth.co.uk/~rday/pussy/ )
What more could you want? Watch "Ice Station Zebra" in the nude?
Wayne Liu
> You could use either Java Servlets or FastCGI. Both overcome CGI
> problems, in thatthe launched process/servlet remains live between
> connections. They're almost like real servers.
>
> Roger.
Roger,
Where can I found more info on the methods that you described above?
thks, wayne
Mike Swaim
Tate Jones (ta...@mistral.co.uk) wrote:
: Powerbuilder GPF's piss me off too. However, i found about 90% were
: caused by my own programming bad habbits. I now used a stable class
: library and enforce strong OO techinques, very simular to Java. I
: haven't seen GPF's for a good 12 months.
Unfortunately, most of my GPFs are in the development environment. Hard
to code around those.
--
Mike "Special Agent in charge of Chaos" Swaim, sw...@phoenix.net, I lie.
'Many so-called "guardian angels" have taken up that occupation not