RE: [tcljava-dev] Jacl Status Questions/Survey

[Steve C. <st...@su...>]

Bruce,
	I guess you are trying to get a feel for the usage profile of Jacl so I
thought I should respond.

I work for Surpac Minex Group (SMG - www.surpac.com). We develop and sell
technical software used by Surveyors, Geologists and Mining engineers. The
software is used for orbody modelling, mine design and engineering,
surveying applications and other matters related to the earth resource
industries. If you want more info visit our web site at the above address.

Since 2000 our software has used Jacl as a key component of user interface
development, which probably seems very strange I'll admit. I'll explain a
little so it makes sense, I hope.

A major re-engineering exercise took place from 1998 to 2000 implement major
architectural changes to implement a client/server model to modernise the
sofwtare which began life in 1982 but has been through a number of previous
rewrites to 'keep up with the competition'. Notable among these was the
implementation of a client/server model so the application servers could be
hosted on a platform independent of the client user interface. This was
successful and we now have a teamwork model, admittedly still not being
actively used, that permits a 3D shared workspace for editing and viewing by
any number of users connected to a single application server. Connections to
the application server are across a TCP/IP connection.

Of course the software also works (and is actually used almost exclusively
in this mode at present) in a standalone single client configuration where
the application server and user interface client are hosted on the same
platform and in this mode of operation it appears like any other piece of
dektop productivity software, even though the client/server model is still
used to communicate and pass data between application server and UI client.

Jacl fits in to the UI client component which by now you must have guessed
is implemented in Java. Java of course was chosen for the write once run
anywhere capability, even though we only support M$ operating systems at
this time. We felt it insulated us somewhat from the sometimes unpredictable
decision making process at M$ as well as providing the capability to deploy
it to any platform that supported Java.

The UI is developed using Swing components. Rather than require our
development team to code directly in Swing, which can be nasty, and also
because the majority of development is in C++, we wanted to insulated
application development as much as possible from the vagaries of Swing. For
perhaps 80% of application development this is feasible because the UI
components are relatively static dialogues that simply obtain a number of
input parameters from users.

Most dialogues are therefore reasonably simple and static in design. At the
core of the UI module is a piece of technology that we call Guido.
Apparently it stands for Graphical User Interface Design Objects, or so
someone claims.

Insulating the majority of our development team from the nitty gritty of
Java/Swing has been achieved (and has been very successful) by implementing
a Guido as a scripting solution. This is where Jacl comes in to play.

So Guido is actually a suite of new commands that we have added to Jacl to
create Swing UI components. At teh back of this is a module that deals with
client/server communication so that when the "Apply/OK"  button is pressed
on forms the entered parameters are packed up and transmitted to teh server
where there is a nice clean API for applications to retrieve parameters and
pass them on to the processing modules.

Examples of commands added to Jacl include:
- GuidoField
- GuidoComboBox
- GuidoPanel
- GuidoCheckBox
- GuidoPanel
- GuidoMenu
- GuidoMenuItem
- GuidoToolbar
- GuidoExecServer (to execute a server side function and return parameters
to the client)
- there are many, many more.

Mostly the Guido commands are a thing layer on top of Swing components and
permit probably 95% of user interface components to be defined using
scripts. This seems to have reduced overheads substantially in the
development of user interface components. It also provides a third party
development environment for users and other software developers to write
product extensions to teh core software using the same UI and make them
appear indistinguishable from core components developed by SMG.

Hopefully this gives an idea of how we are using Jacl. You could argue that
there are other ways we could have achieved this but at the time 1998-2000
there was no viable UI that could be driven from Jacl so we came uo with
this solution and it has stood up remarkably well. The fact that you can
call Java methods directly from Jacl permits us to code in Java/Swing
directly when it is expedient.

We aren't doing any development on the core of Jacl at all. Over teh last 4
years even though it has been static, we've found it to be perfectly
adequate for our needs. It is unlikely that we will need to do any work
directly on Jacl in the forseeable future. We will probably continue to
extend the Guido commands that we added as circumstances require it.

It would be good to see Jacl used some more but I don't know that we have
anything to offer other than an example of how it can be used to good effect
in a niche product.

If you have any further question please email me and I'll do my best to
answer them.

Regards,
Steve Carter
Director, Research & Development
Surpac Minex Group
PH +61 7 49261995



-----Original Message-----
From: tcl...@li...
[mailto:tcl...@li...]On Behalf Of Bruce
Johnson
Sent: Friday, 14 May 2004 6:27 AM
To: tcl...@li...;
tcl...@li...
Subject: [tcljava-dev] Jacl Status Questions/Survey



I'm curious about the state of Jacl.  I myself think it's the best
thing since sliced bread and am fairly committed to using it in some of
my projects.  On the other hand, there doesn't seem to be much activity
on the mailing list or cvs repository these days.  I thought I'd see if
people would actually respond to a few questions.

1) Is anyone doing active development on Jacl itself?

2) Is anyone planning on doing development on Jacl in the future?

3) Is anyone actively using Jacl in projects?

4) Would anyone be interested in having some Jacl/Swank presence at the
upcoming Tcl/Tk 2004 conference (talks, tutorials, BOFS)?

5) Any thoughts on promoting the use of Jacl?


Thanks for any feedback.

Bruce





-------------------------------------------------------
This SF.Net email is sponsored by: SourceForge.net Broadband
Sign-up now for SourceForge Broadband and get the fastest
6.0/768 connection for only $19.95/mo for the first 3 months!
http://ads.osdn.com/?ad_id=2562&alloc_id=6184&op=click
_______________________________________________
tcljava-dev mailing list
tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcljava-dev