OpenEuphoria

Re: New win32lib and XML

• Posted by Isaac Raway <isaac-topica at blueapples.org> Jan 05, 2004
• 372 views

Pete Lomax wrote:

>The new win32lib iirc is going to have some major changes to the way
>controls can be specified (so I guess this is mainly aimed at Derek).
>During my trawls on the web, one thing that seems increasingly to be a
>jolly good idea is to store gui layouts in a separate file, and xml is
>probably not the worst choice.
>  
>
I disagree. I have had too much exposure to XML to be able to consider 
it a serious method of storing data. I'm not kidding here, and yes I 
know I am going against the flow, however there are some serious issues 
with XML, at least two of which are:

1. It is far too verbose.  As illustrated in your example, XML requires 
a closing tag that repeats the name of the tag in order to be able to 
determine the hierarchy. I believe that the language LISP has a much 
better scheme (no pun intended)  when going about establishing the 
parent of an object.

2. There is not a clear reason to differentiate between attributes and 
child nodes, save for the fact that expressing every attribute as a 
child node would be to verbose. Attributes can easily be expressed in 
terms of child nodes, and indeed in many parsers are handled very 
similarly (There are often two collections for each node, one call 
attributes, the other children. The objects in both collections behave 
almost identically.).

These issues may seem to be irrelevant. However, I believe that they are 
important because a language that is too verbose is unpleasant to use 
(example, Cobol) and languages with inconstancies such as "Should this 
value be a string attribute or a #CDATA child?" are not well designed. 
That poor design seeps into any system developed with the language.

Forgive me, but I think this is a superior way of expressing the dialog 
example (approximately equivalent LISP code with some assumptions):

(dialog
    (caption "Dialog Example") (top 0) (left 0) (width 320) (height 200)
    (style 'popup 'clipsiblings 'caption 'sysmenu 'modalframe '3dlook 
'setfont)
    (control (class "Static") (top 29) (left 32) (width 70) (height 11) 
(text "Static Text Example"))
)

It could easily be expressed in terms of a Euphoria sequence as well:

sequence test_dialog
test_dialog = {"dialog"
                    {"caption" "Dialog Example"} {"top" 0} {"left" 0} 
{"width" 320} {"height" 200}
                    {"style" "popup" "clipsiblings" "caption" "sysmenu" 
"modalframe" "3dlook" "setfont"}
                    {"control" {"class" "Static"} {"top" 29} {"left" 32} 
{"width" 70} {"height" 11} {"text" "Static Text Example"}
}

The commands could easily also be stored as constants to make it a bit 
nicer looking:
test_dialog = {dialog
                    {caption "Dialog Example"} {top 0} {left 0} {width 
320} {height 200}
                    {style "popup" "clipsiblings" "caption" "sysmenu" 
"modalframe" "3dlook" "setfont"}
                    {control {class "Static"} {top 29} {left 32} {width 
70} {height 11} {text "Static Text Example"}
}

In fact...I'm quite sure I had a discussion (I believe in this list?) 
with a developer on the win32lib team that indicated something like this 
was to become the norm for window creation...perhaps I am mistaken.

At any rate, I believe it'd be much better to "keep it in the family" 
and express dialogs/windows/any object for use with win32lib as a 
Euphoria sequence. Euphoria already has a better data storage system 
than XML.


[snip]

>The major downside is that you can't link handlers directly to
>controls. 
>
How could we get around this? Use predefined handler names, like VB? 
(controlName_eventName is always the name of the event handler. Not good 
for more advanced event handling such as multiple controls attached to 
one function.)

>On the plus side, it divorces the gui alot more from the
>application code, making it much easier to translate to another
>language, remove (make invisible) a field not used by a particular
>client, etc.
>  
>
I agree with this. It's is generally better to not build GUIs within the 
actual code that manages them. It is a concept similar to that of 
template engines for web applications.

>I haven't yet managed to find a common format for such a file (is
>there one for wxWindows?) or a layout editor which stands out, maybe
>Judith's IDE could be hacked?
>  
>
I'd suggest writing a new form editor, even if Judith's IDE would be 
easy to convert (which I'm pretty sure it wouldn't be). It's better to 
have a fresh project that is designed from the ground up for a new 
format and makes no compromises.


Isaac