On Thursday 20 November 2003 11:58 am, Michael A Nachbaur wrote: > On Thursday 20 November 2003 07:43 am, Tod Harter wrote: > > On Wednesday 19 November 2003 7:22 pm, Michael A Nachbaur wrote: > > > 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. > > Intriguing. Do you perhaps have any samples you would be able to show that > illustrates this concept? Does the client-side application provide the > "Controller" part of the framework? What is the result of the XSLT > transform, a conventional web page rendered in a <xul:browser/> element, or > plugged straight into a standard container element like a <tabpanel/> or > <box> element?
Well, I wasn't even THAT sophisticated... I simply created my page just like I usually do and at the point where content normally lives, a <td/> I just identified that td with id='x'. Somewhere in my page is a wad of javascript placed there by an XSLT template match to some tag in my original source XML. That javascript finds the <td>, uses XMLHttpRequest() to request whatever component is supposed to go there, optionally gets an XSLT transform and applies it, and attaches the result to the DOM tree at the specified location. In addition to HTML this can also contain the javascript for event handlers etc. The only reason for even going through javascript is just that my concept was to build fairly large chunks of GUI and include them as needed. The nice thing in that case is that your DATA can be already in the page and remain local while you do whatever you want with the user interface. The same basic kinds of techniques can be used with smaller widgets though, and of course the XSLT can happen on either server or client, as is convenient. Something like XUL could be generated just as easily as HTML, and the syntax for specifying the components in the first place could be quite varied as well, XForms, etc. I built a little site map editor this way. In my case I built a javascript class that could load the sitemap, display it, save it, etc. Its nice because you can save the sitemap and still keep editing it without it needing to be reloaded as with conventional forms based systems, plus my editor is far nicer than any form.... The complete package consists of the data, a javascript .js file that defines the class, and an XSLT transform that turns the data into the HTML interface and 'glue' javascript to propagate events to my class. The whole thing is still fairly clunky, but I can send you some files. Currently it only works in Mozilla, but I could make it work in IE in theory. -- Tod Harter Giant Electronic Brain http://www.giantelectronicbrain.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
