Java Customization : XUI or Swing

[ptc-1894556]

This feels like another potential discussion so I created a new post for it..

Melissa - thanks for your input. We are just getting started and our original prototype did use Swing. But in recent days I have started to experiment with XUI and am starting to prefer it because 1) its quicker to design the UI and 2) the XUI windows appear to integrate better with the editor's UI environment (dockable etc). I'm wondering why you decided to use Swing in your application? For one thing I would assume that there will be limitations in what can be done XUI vs Swing. So pros and cons either way but I think we will go with XUI..


That said, for the moment I'm deciding to implement the event handling from the XUI windows in Java. Writing event handlers in Java is some more code than Javascript (and you must compile/deploy) but at the end of the day I believe we will end up with a better event handling structure and avoid spaghetti possibly generated by JavaScript handlers.


We are also interested in potentially using embedded XUI on the document surface and will try some experiments with that in coming days. One ambitious requirement we have is to host Flash inside the editor (I guess using an ActiveX control)


Sounds like you've received a lot of input, but I'll add my 2 cents anyways.We currently do not use any XUI dialogs in our project, but instead use Swing. The biggest problem we have encountered with this approach is dialogs going behind the main editor window. Setting the Swing GUIs to alwaysOnTop() keeps the Swing GUI on top, but occasionally we have problems with the Editor error dialogs showing up behind the java dialogs. We have been able to minimize these issues, but they still crop up every once and a while.

As far as using ACL vs Java we have found that ACL is harder to debug. Every time I have an issue with ACL code I end up having to put a message_box in the code to figure out what it is doing. Reminds me of college when they didn't allow us to use full fledged code editors like Eclipse. If anyone has any tips on debugging ACL let me know.

Basically for complex logic we find it much easier to maintain in Java by calling the Application.getActiveDocument() to get the W3C Dom object of the open document in the Editor and manipulate it in Java. Of course we do call ACL from our Java code quite a bit. Using Java also allows us to reuse code outside of the Editor. Our users require several reports to be generated based on their documents without them being opened in the Editor and do not require any Editor specific logic. Some of the code used to generate these reports is also needed in the Editor when they are drafting the documents. Having the code in Java allows us to maintain this logic in one place.

If you run into any issues I would be more than happy to provide you with more information. The Arbortext Editor people need to stick together.

Melissa

[berard]

Hopefully this will fit somewhat within the scope of the thread.

While we don't use swing, we do have some extra utilities that are written
in .NET that interact with Arbortext. The main reason we have written
these in .NET and not in XUI is to take advantage of additional GUI controls
such as progress bars, etc as well as to tie in to our back-end systems more
easily. We are mostly a .NET/SQLServer shop, so even our XUI components
hit .NET web services via java AXIS libs, which work surprisingly well.

Like swing (or at least what I've heard so far) these controls also suffer
from loss of editor context (eg: pop under errors) and are somewhat
restricted to the top-level editor window. Also, since they go through a
COM layer, there is a somewhat significant performance impact depending upon
the operation being performed.

In fact, our initial intent was to design an activex control that could be
loaded up in the editor to serve as a reverse-entry point. Unfortunately,
deployment became the major hassle (due to COM registration) and the
approach was abandoned.

That said, we have written some successful applications in .NET. One of
these is a "translation" tool that is able to take a glossary and go through
epic phrase by phrase (or word by word) all the while highlighting the text
in context and allowing the user to replace the word/phrase with a click of
a button. This application also generates Excel reports, complete with
color coding, which would have been somewhat difficult to accomplish in
java.

keith

[melissa.kauma]

As far as why we went with Swing over XUI I am not sure. When I started on the project a few years back they had already implemented the GUIs in Swing. From what I have heard there were limitations as to what could be accomplished in XUI. Also, I believe that people mentioned that there was no nice tool for designing XUI dialogs or an easy way to implement them. The project started 5 or 6 years back so maybe XUI has been improved upon since then. We have fairly complex dialogs that require a lot of user input with multiple panels, typically card panels that change with a combo box selection. I'm not sure if something like this can be handled in XUI or not.

Any opinions out there on how well XUI handles complex dialogs?

[ClayHelberg]

Hi Melissa--



I've done some fairly elaborate dialogs using XUI, and I find it meets
most of my needs quite well. There are a few control types that aren't
native to XUI, such as progress bars. But it supports most of the
typical UI controls. I don't find it especially hard to lay out a XUI
dialog--if you edit the dialog XML in Arbortext, you can select
Tools->View Dialog from the menus and it will display the dialog. The
displayed dialog updates every time you change the XUI document, so you
can see what you're doing as you put it together.



And yes, it's quite feasible to do a multi-panel, complex dialog. For an
obvious example, the Preferences dialog in Arbortext is a XUI dialog, so
you can take a look at C:\Program
Files\Arbortext\Editor\lib\dialogs\pref.xml to see how they implement a
multi-panel dialog with various types of controls.



--Clay

[ptc-925411]

Clay, how do you do progress bars? It's frustrating to me that XUL, the basis for XUI, has progress bars, but XUI doesn't.

Steve

[ClayHelberg]

Hi Steve--



I don't, which is maybe one of the reasons I don't mind using XUI. 🙂



A couple of ideas occur to me, though I haven't tested them so I don't
know how well they'd work or how much trouble they'd be to implement:



1) You could probably use some kind of ActiveX control for this. I
imagine there is some kind of standard Windows widget that could be used
this way, but I haven't done it so I don't know the details



2) You could "roll your own" using a label and some script code



What solutions have you tried for this? Have you found anything that
works especially well?



--Clay

[ptc-925411]

I haven't tried anything, since the effort to solve it didn't seem worth the benefit, but I've heard complaints about it. Most commonly, "How will I know when it's done?" - I guess popping up a window saying, basically, "It's done" isn't good enough anymore 😉

Steve

[ClayHelberg]

Hi Steve--



Here's a little prototype of a simple label-based progress bar in XUI I
threw together in my Copious Spare Time(tm). It's pretty bare-bones, but
you ought to be able to set it up to be more like a proper listener with
a little tinkering.



I did manage to find the standard progress bar ActiveX control that is
built into Windows, but I didn't have time to get it hooked up properly
so it would work. (I was having problems with JScript that I didn't have
time to track down.) But, in principle, if your Jscript is working
properly, you should be able to use that as well. The ProgID is
"MSComctlLib.ProgCtrl" if you want to play with it.



The sample is below. Enjoy!



--Clay









<window modal="false" orient="horizontal" title="Find">

<box orient="vertical">

<box orient="horizontal">

<label label="How" far=" are=" we?&quot;="/>

<textbox>

<value id="sofar">500</value>

<script ev:event="domsubtreemodified">

updatepbs();</script>

</textbox>

<label label="Out" of=" total:&quot;="/>

<textbox>

<value id="total">500</value>

</textbox>

</box>

<box orient="horizontal">

<label label="Label" progress=" bar:&quot;="/>

<label id="labelpb" label="" width="100px"/">

<button label="Test">

<script ev:event="DOMActivate" type="text/javascript">

test();

</script>

</button>

</box>

</box>

<script ev:event="windowload" type="text/javascript">

// This is the function called by the monitored process when

// it wants to update the progress bar. In this simple implementation

// it reads the completed and total values from the textboxes in the

// dialog. In a real system you would probably pass them as parameters

// from the monitored process.

function updatepbs(dlgdoc) {

if (typeof dlgdoc == "undefined") {

dlgdoc = Application.event.target.ownerDocument;

}

// get current progress

current =
parseInt(dlgdoc.getElementById("sofar").firstChild.nodeValue);

total = parseInt(dlgdoc.getElementById("total").firstChild.nodeValue);

if (current < total) {

progress = current/total;

lpb.update(progress);

}

}



// define a method for progressbar element

function update(progress) {

boxes = Math.floor(progress * 10);

text = ";

while (boxes-- > 0) {

text += "█";

}

if (((progress * 10) - Math.floor(progress * 10)) > 0.5) text +=
"▌";

this.lb.setAttribute("label",text);

}



// create an object type for the progress bar, with one property

// (the label element) and one method (the update function defined
above)

function LabelPB(lbelement) {

this.lb = lbelement;

this.update = update;

}



// instantiate the object with our progress bar label

var dlgdoc = Application.event.target.dialogView.document;

labelPB = dlgdoc.getElementById("labelpb");

var lpb = new LabelPB(labelPB);



// here's a test to exercise the PB's



function test() {

var limit = 500;

dlgdoc.getElementById("total").firstChild.nodeValue = limit;

for (var i=1; i <= limit; i++) {

dlgdoc.getElementById("sofar").firstChild.nodeValue = i;

updatepbs(dlgdoc);

Packages.java.lang.Thread.sleep(10);

}

}

</script>

</window>

[ptc-925411]

Thanks Clay! I'm looking forward to tinkering with this.

Steve