Hi everyone,
We are in a situation where our application currently samples each option of UI that Progress offers – gui, chui and webspeed. All of our UI is progress based.
We are in the process of moving all our clients to OE10 db’s (from V8). Once this is done, we will be re-writing all our business logic in accordance with the OERA via prodatasets, etc.
Within our organisation, there are different (and some strong) opinions as to the UI that will best suit us as developers and of course our user’s and prospective users needs.
We always attend the PTW conferences and seen what is coming from Progress as far as UI development is concerned – however, this may be too far away.
So, our UI options going forward have been narrowed down to:
1. Stick with Progress, wait until the new UI tools are available.
2. Java UI
Re 1 - We are aware of the options to add “sizzle” to our interface in the meantime via the use of ocx controls (and are currently working on a new project with the UI based around the Codejock controls (due to a deadline and a client’s specific requirements)). We have also seen the presentations on the future of the Progress UI development capabilities.
Re 2 – There is a push from some here to investigate the Java option. As we deploy our applications on Linux, it is seen to have many advantages.
So, what’s your question I hear you asking?
Basically this – we are looking for any feedback from anyone who has perhaps successfully developed an application using a Java UI/Progress appserver with prodataset business logic layer.
Has anyone developed a large-scale app (we are an ERP) in Java UI? If so, do you have any comments you’d like to share (good and bad)? Or does anyone else have anything they'd like to add to this topic?
I’d greatly appreciate ANY feedback fro the community to present to my fellow management team members.
Regards,
Ashley
Did you consider the AJAX alternative? I think there are some huge advantages of not having to have anything installed on the client.
Hi Thomas,
Yes, are looking at AJAX, but more from the point of view of using it to replace our current webspeed sections of the application (e.g. requisition approvals), not the core (and in some cases very rich) UI. We will probably wait until AJAX matures a little more before doing any proof of concept testing....
And yes, I agree re the client.
I come at this from the point of view of having trained on Siebel and done a Siebel installation a couple of years ago. Their browser client is just fabulous and in no way does one think of it being any less rich than a full native application. Because they did this a few years ago, they accomplish it with a couple of small pieces which automatically download on first use as required, but I see no reason why the same functionality can't be achieved with AJAX ... it is just a question of putting in some development time to get the tools. So, don't dismiss it too quickly ... one client on every platform has some real attractions.
Apparently the UI for Eclipse was split off from the project and is available as a RCP (Rich Client Project).
Have you looked into that? If so, what did you think?
I quite like the new SWING stuff in Java 6. Its a lot faster than it use to be.
Murray
Hi Ashley,
We have successfully done a Java UI implementation with progress backend.
We have developed a framework in Java which contains a very strong data set handling (to read proxies, etc).
One of the things we have done here is to integrate with Progress GUI so that the migration is not a big bang approach.
It was done via sockets. Our main menu is still progress based, we start the java process within our progress app, make it hidden until required my a particular screen(s), and open a server socket on the java side. Then progress connects to this server socket and sends messages to it such as what class to start, what user has logged in, etc.
On the java side, we have spent around 3 man months on the initial framework, then another 3 to refine it as screens were built.
This java framework contains all temp-table definitions (for proxy calls) in XML, contains all tables (browsers), and everything else you can think of that are not "application" specific.
Therefore, now, when a "new screen" comes along, on the UI side it's pretty simply to create, since the whole template is already created as one of the super classes. All combo boxes, lookups, inquiry screens, data entry screens, etc are standard look and feel due to that.
We currently have a factor of 5 progress developers to 1 java UI developer.
If you want more information please contact me directly, I would be glad to help.
Regards
Jonny Oenning