General developer forum

To be fair XML has a lot of different uses, for many of which it is indeed the no-brainer solution. However, this particular situation I think it's non-controversial to say that idiomatic Python or Ruby programmers wouldn't use XML (they'd use Python or Ruby) while say Java programmers would use XML. Compare, for example Ant and Rake.

The big question then is whether PHP is closer to Java or Python and Ruby in this regard.

I was going to point to a nice blog article on this topic but it appears to have disappeared from the internet so I'll liberally copy and paste below:

XML is not the answer. It is not even the question. To paraphrase Jamie Zawinski on regular expressions, "Some people, when confronted with a problem, think "I know, I'll use XML." Now they have two problems."

This is a different situation than in Java, because compared to Java code, XML is agile and flexible. Compared to Python code, XML is a boat anchor, a ball and chain. In Python, XML is something you use for interoperability, not your core functionality, because you simply don't need it for that. In Java, XML can be your savior because it lets you implement domain-specific languages and increase the flexibility of your application "without coding". In Java, avoiding coding is an advantage because coding means recompiling. But in Python, more often than not, code is easier to write than XML. And Python can process code much, much faster than your code can process XML. (Not only that, but you have to write the XML processing code, whereas Python itself is already written for you.)

If you are a Java programmer, do not trust your instincts regarding whether you should use XML as part of your core application in Python. If you're not implementing an existing XML standard for interoperability reasons, creating some kind of import/export format, or creating some kind of XML editor or processing tool, then Just Don't Do It. At all. Ever. Not even just this once. Don't even think about it. Drop that schema and put your hands in the air, now! If your application or platform will be used by Python developers, they will only thank you for not adding the burden of using XML to their workload.

(The only exception to this is if your target audience really really needs XML for some strange reason. Like, they refuse to learn Python and will only pay you if you use XML, or if you plan to give them a nice GUI for editing the XML, and the GUI in question is something that somebody else wrote for editing XML and you get to use it for free. There are also other, very rare, architectural reasons to need XML. Trust me, they don't apply to your app. If in doubt, explain your use case for XML to an experienced Python developer. Or, if you have a thick skin and don't mind being laughed at, try explaining to a Lisp programmer why your application needs XML!)

from http://dirtsimple.org/2004/12/python-is-not-java.html (currently unavailable)

The point of the above isn't to convince anyone who's not convinced already but just to point out that it's perhaps a cultural/language thing, and certainly not Moodle-specific.

And finally, from the incomprehensible yet hilarous launch announcement of the Camping micro-framework:

Perhaps we can have both to keep everyone happy.

Indeed

the idea is to create the entire form structure first

Hmmm. Perhaps sometimes, only when needed?

I'll say something a bit crazy: Thinking only about forms is missing a good part of the picture. Any suport library needs to support HTML as we use a lot of HTML for presentation and layout.

So we may as well support HTML

The cases where we need to prepare it and manipulate it in memory can be addressed very simply, and more effectively even, with a simple array.

(I came back from lunch feeling bad about my "that's not my problem" reply earlier, so...) I was just going to extend my reply to Tim saying that for cases where you need that "in memory" form building (and it's just a subset of the cases we haven't really needed it yet) you can use a stack-like array.

So say:

 $html = new WeblibLikeClass;
 $form = array();
 $form[] = array(key=>'intro', 
                 value=>$html->h3('A name')
                        . $html->p('Blah-blah-blah'));
 $form[] = array(key=>'start', 
                 value=>$html->form_start(
                         array(method=>'POST',
                          action=>$CFG=>wwwroot.'/mod/foo/index.php')));
 $form[] = array(key=>'part1', 
                 value=>$html->input_hidden('moduleid',0)
                        . $html->input_text($form, 'name'));
 $form[] = array(key=>'part2', 
                 value=>$html->input_html($form, 'description')
                        . input_checkbox($form, $course));
 $form[] = array(key=>'end', 
                 value=>$html->form_end());

(Arguably, we should use some tricks to boil this down to a more elegant representation. Not trying to be elegant on this one )

And in that you have defined 4 sections which are clearly labelled and can be easily overridden. All you need is a little function to do the lookup of the position by key.

Quickforms forces a model that I don't like too much: you have to create templates, which calls for yet another templating scheme

<editform langfile='resourcepage'>
    <item type='text' name='modulename'/>
    ...
</editform>

<editform langfile='resourcepage'>
    <text name='modulename'/>
    ...
</editform>

    <text name='modulename' helpfile='' size='30'/>

1. Forms have an in-memory representation.
2. There is an optional XML format, optimised for ease of typing, that can be used to create the in-memory representation.
3. The in-memory representation can be manipulated. I think we should write some helper functions for this to make it easer for people. add_field(), remove_field(), etc. That way most people don't have to know or care what the in_memory representation is.
4. Then there is code to dump the in-memory representation out as HTML.

        $children=$parent->childNodes;
        foreach($children as $item) {
            if($item->nodeType!=XML_ELEMENT_NODE) {
                continue;
            }          
            // Call method depending on item type
            $type=$item->tagName;
            switch($type) {
                case 'display' :
                    $this->show_display($form,$item);
                    break;
                case 'text' :
                    $this->show_text($form,$item);
                    break;
                ...


    private function show_text($form,$item) {

        $name=$item->getAttribute('name');
        $size=$item->getAttribute('size');
        if(!$size) {
            $size=30;
        }
        $required=$item->getAttribute('required');

        ...