Re: [Setup-tool-hackers] Re: XML front-end ideas

[Martijn Klingens <mklingens yahoo com>]

Why not write a three-tiered model then? A Backend that does all processing 
and returns the configuration, a frontend that actually renders the widgets 
and a shared piece of middleware that is still written in C (C++ ?) and 
communicates between frontend and backend.

The middleware is still toolkit independent, but remains in memory, unlike 
the backend which is stateless by nature. It makes designing and maintaining 
a bit easier IMO. The backend spits out the XML like it does now, the 
middleware generates an XML UI and the frontend renders the UI.

Just my thoughts,

Martijn

On Monday 21 May 2001 05:54, Andreas Pour wrote:
> David Joham wrote:
> > <<Well both KDE and GNOME already have XML-based dialogs.  Most of the
> > work would be in implementing the original XML language and then finding
> > some XSLT to convert to the KDE (Qt Designer?) and GNOME (GLADE?)
> > formats.  Alternatively, the backend could load a module which has a
> > common API for generating the GUI XML which spits out the required
> > formats directly.>>
> >
> > I'm still a little unclear about how the whole idea of an XML GUI would
> > work. If I understand the idea correctly, the thought would be that the
> > back-end told the front-end how it needs to be rendered. That's all well
> > and good, but how does the back end tell the front-end what happens for
> > example when "buttonWidget1" is pressed. That logic needs to be in the
> > front-end GUI somewhere or we won't have a very impressive application :)
>
> Well, not really.  I've done a project like this.  When a button gets
> pressed, you can specify an "onClicked" event in the XML.  Since we want
> the frontend to be simple, you can do it like this:
>
>   <BUTTON name="OK" label="OK" onClicked="send('<CLICK button="OK">')">
>
> or something like that.  Send means send this info back to the backend
> (so either you need two pipes or a socket for communication but that's
> pretty straightforward).  If someone clicks, the backend is notified and
> it can open a new dialog, close the existing one, or some other
> primitive things.  Probably only 3-4 actions need to be supported.
>
> For the prior project I did, you can see the DTD (sort of) at
> http://www.mieterra.com/documentation/XML-MT.html -- if you want you can
> download the engine too, though it is based on KDE 1.  For purposes of
> this we don't need anything as complex as that (it includes a
> mini-scripting language as well and has a lot of widgets we don't need).
>
> > My question to the XML proponents is this: since the logic of how the GUI
> > interacts with itself needs to be known to the front-end, where is this
> > logic going to be stored?
>
> I don't think the frontend needs to know anything.  Just imagine the
> frontend is GTK and the backend is your C code.  GTK knows nothing about
> what your code does; it only knows about widgets.
>
> XML GUI is the same.  However, instead of passing function pointers,
> callbacks are implemented using the "onClick" and so tags and by sending
> XML (which a marshalling function then converts into function calls in
> Perl -- you can use XML to describe this as well, e.g., if you get back
> the OK click, execute funtion xyz).
>
> > If it is stored on the back-end with the GUI
> > definition, how do you propose to propagate that information to the
> > front-end client? How will it then be executed? If it is stored on the
> > front end client, what is the real advantage of having the GUI defined in
> > XML when its behavior is already pre-defined in the code?
>
> My view is that the frontend is stupid.  It just displays widgets based
> on XML description and returns text strings when events occur based on
> the XML definition.  Looking at kmiescultptor (for which I linked the
> DTD above), I wrote a PHP version that does the marshalling and
> implements actually the entire DTD in 2 days (OK, they were 2 *long*
> days).  So the backend stuff (replace Perl with PHP here) should be
> relatively easy.  And the nice thing is you just have to do it once and
> then it's used with all frontends and all backend modules.
>
> Ciao,
>
> Dre

_______________________________________________
setup-tool-hackers maillist  -  setup-tool-hackers@helixcode.com
http://lists.helixcode.com/mailman/listinfo/setup-tool-hackers