Am Do, 2003-11-20 um 16.43 schrieb Tod Harter:
> On Wednesday 19 November 2003 7:22 pm, Michael A Nachbaur wrote:
> > I've started transitioning my application to use a Mozilla XUL client
> > application, installed using a download from the intranet website, that
> > presents the user with a fat client interface to the same server-side
> > intranet application.
> >
> > Mozilla has made a really big commitment to RDF for all manner of aspects
> > of it's basic operations; tree views, templated XUL sections (for
> > repeatable clusters of display elements), menus and so on can all be
> > programmatically built using RDF as a datasource.
> >
> > The bummer about all this is I find it pretty hard to generate RDF using
> > AxKit. I ended up dropping down into a plain'ol mod_perl handler, and
> > printed out the RDF tags manually. My XUL application is still just a
> > prototype, but I'd like to see this functionality merged into AxKit more
> > before going whole-hog into it.
> >
> > So, anyway, to answer the question, I would like to see better support for
> > outputting RDF in AxKit. Perhaps I had better spit the RDF out as a result
> > of an XSL transform, but somehow that never occurred to me before.
>
> Interesting. I am trying a different tack. My client-side application is built
> by loading an initial page, which contains javascript logic which goes back
> to the server via XMLHttpRequest(), gets whatever data is required for the
> particular operation being performed (served back as raw XML by the server
> side), applies XSLT to it, and attaches the resulting UI to the DOM tree in
> whatever is designated as the content area for whatever enclosing UI element
> is holding this 'panel' or whatnot. XUL could certainly be incorporated in
> there, but basically what I have is a component and a corresponding XSLT to
> instantiate it. You can go back and forth to the server all day and there are
> no 'pages' being loaded. In fact the application becomes entirely a normal
> event-driven GUI, albeit with some javascript glue logic.
I do the similar using something I called ReferentialJavaScript-Fields
which retrieve their content using XMLHttpRequest or in IE the
corresponding ActiveX-Component.
Beside retrieving values using XML one could define references between
fields, using this approach one could minimize the values downloaded
when using huge list. E.g. ListBox1 ==> continent, ListBox2 ===>
Countries. When ListBox1 holds Europe it does not make any sense to
download e.g. Australia, China, ... .
The complete JavaScript-code is based upon Model-View-Controler
approach, so it is easy to add more Views, at the moment I've the
following ones implemented:
* MultipleSelect-Lists
* Select-Lists
* DropDowns
* CheckBoxLists (==>MultipleSelect-Lists with Checkboxes)
One more thing I also implemented in JavaScript is something I called
AutoForm-Expand. It is simply a textbox sending requests to a mod_perl
handler when it's content changes and poping-up a "dropdownlist" below
the textbox showing all database entries who match the content of the
textbox (I found this approach very helpful e.g. for forms where one had
to select a Person from a huge list).
The drawback of all those approaches it that their only working in IE
and Mozilla based browsers which is no problem when creating a Intranet
application with a controlled environment.
On top of these JS-Libs I implemented in my old company an
application-framework which is configured using XML, mapping
database-content to GUI-Elements, allowing none programmers to create
Intranet-Application simply using an XML-Editor.
The features included into this framework have been:
* Referential Fields like described above
* AutoExpand-Fields like described above
* faked SQL-Triggers
* Automatic mapping between database content and GUI-Elements
including automatic creation of insert/update/delete-statements
* Parent-Child-Relationships between forms including conditional
selection of children of based upon values set in parent form
* KeyBord-Navigation using a JS-Libary where one could easily add
his her funtionality
Well that all sounds to good, doesn't it. The bad news is that I left
this company and all my code behind. Still I'm in contact with them
talking whether they could maybe release the code to the opensource
world.
The second bad news is that at the time I wrote this framework I didn't
know about mod_perl or even axkit, so it's all implemented using FCGI.
At the end good news. In my new (own) company we already have many
design documents describing a similar application framework than the one
described above but much more flexible/faster => powerful. From the
first idea on we decided that the complete project has to be made
opensource so people around the world could contribute their ideas,
knowledge, ... . I'm going to bring our design documents up-to-date and
publish them at our website this weekend/next weekend so people here
could take a look at them.
A first small part of the project is already registered at sourceforge
(http://sf.net/projects/perl-torque), reimplementing apache's-torque
database mapping generator using TemplateToolkit/Class-DBI. At the
moment there's only code into the CVS-Repository, and the only things
really working are:
* creation of DB-CREATE-SQLS for MySQL, Postgres (e.g. a XML-File
describing the XIMS Database is included)
* creation of ER-Diagrams
At the end of the day this project should provide informations about
database-relations to create databasefrontends easily and the
possibility to create an OO-AbstractionLayer automatically e.g. using
Class::DBI.
Maybe more if people here are interested and after I've published our
design documents.
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
