W3C home > Mailing lists > Public > www-forms@w3.org > October 2001

Xybrix & xforms

From: Jim Wissner <jim@jbrix.org>
Date: Tue, 30 Oct 2001 03:06:09 -0500
Message-Id: <5.0.0.25.2.20011030024420.00aa3a38@pop3.kattare.com>
To: www-forms@w3.org

Hi,

I've been following this list for only a short time now, so please bear 
with me. I have an open source project called Xybrix, which is an "XML 
application construction kit" that includes, amongst other things, 
something called "xforms."  The history of this particular xforms package 
is that it pre-dates the w3c xforms specification. It originally was 
similar in concept, but not as ambitious as the w3c spec turned out to be. 
I've tried to make some of the markup more closely resemble the w3c spec, 
but that's about it. At this point, it is primarily focused on presentation 
and document modification, and is geared heavily towards standalone 
applications. There is no processing or event model to speak of, yet.

I would love to make it more w3c xforms compliant, and I have several 
questions to you all:

Is it useful and/or sensible to have an xforms implementation centered 
around standalone applications?
Is there already a mature standalone xforms-based application framework? 
(in other words is it worth bothering, or would this be reinventing the wheel?)
Is the w3c xforms spec still very much a moving target?
As a standalone Swing app, it is very easy to add significant functionality 
beyond the scope of the w3c xforms spec. Does this put it at odds with 
becoming w3c compliant?

...and, finally, if you've by any chance taken a look at Xybrix, do you 
think it's a decent starting point for a real xforms implementation, or not?

I should mention that I'm mindful and respectful of this group, its 
expertise, and its goals, and I hope these comments are taken in that 
light. I think the spec is great, and hope I can somehow contribute, if 
only indirectly.

Thanks,
Jim

BTW here's the url:    http://www.jbrix.org

and here's the latest release notes:


Version 0.2 of the Xybrix XML Application Construction Kit is now 
available. This release contains a lot of cleanup to the application 
framework package, several aesthetic improvements, and many other fixes. 
Some new examples have also been added to the distribution.

Xybrix is an XML application framework in written in Java.  It includes a 
Swing-based implementation of xforms (variation of the w3c xforms), 
XML-definable applications with file and window management, unlimited 
undo/redo of XML mutations, a graphical form designer component, and 
more.  Additionally there is a speech plugin that optionally allows Xybrix 
applications to be controlled by voice through JSAPI of you have a 
compliant speech recognition engine.

It can be found at:

http://www.jbrix.org


Changes since version 0.1:

- Interface now sports the fantastic looking Kunststoff look & feel.
- ZoomMaster: When exposed, zoom layers remember and refocus on components 
that had focus before zoomed.
- XTable: column resize/reorder in XFormEditPanel now sets column 
width/order in table config element
- XTable: remove button now disabled if there is no selection in table.
- XTable: move row up/down now works properly, including multiple row moves 
(use ctrl-up/down keys)
- XTable: delete multple rows now works (remove button or delete key)
- XTable: home/end keys now change selection to first/last rows, respectively.
- Fixed nasty undo/redo bug - see XMLElement.setAttribute(String,String).
- App framework now uses JFileChooser instead of java.awt.FileDialog.
- App framework now maps file extensions to types.
- App framework markup syntax changed: app:editor/@name has been deprecated 
in favor of app:editor/@id, and app:type/@name has been deprecated in favor 
of app:type/@id.
- ZoomLayerPanel label now anti-aliased.
- Added TextPad example, which demonstrates a custom application editor.
- XForms/XComponent: field help can now be disabled.

Known Outstanding Issues:

- Undo/redo events are not fully reflected through nested forms, so if you 
are zoomed in, you might not see the effects of your undo/redo.
- When the current form has only a single field, if that and only that 
field is edited in the application, then the change might not be detected, 
and the application might let you exit without prompting to save the file.
- When operating in a text area, undo/redo still operates on XML DOM 
mutations, which is confusing to the user who is expecting something else. 
When a text component has focus, perhaps it should push its own edits onto 
the Document's modifications stack.

Thank you,
Jim

http://www.jbrix.org
Received on Tuesday, 30 October 2001 03:04:24 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 10 March 2012 06:21:50 GMT