Publicaciones hechas por por David Scotson

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:

XML situps diagram

What an interesting thread! Is it really true that Moodle is the only PHP project trying to create web forms that are:

  • consistent
  • valid XHTML
  • accessible
  • CSS styleable
  • AJAX'ble (e.g. allowing the user create 1 or 10 entries without a reload)
  • integrating with both client- and server-side validation
  • translatable (including i8n/l10n things like number and date formats, rtl text etc.)
  • integratable with WYSIWYG HTML editors
  • easy to create (both by programmers making 'specs' by hand in PHP or XML and in code e.g. for database module)

and so writing one (from scratch) only for Moodle makes sense?

Also, I'm not terribly familiar with XForms but how does this all relate to WHATWG's Web Form 2.0 stuff and related specs?

And also, on the topic of irrational XML-bashing and while I recoginize it's not a great argument, but aren't all the cool kids moving away from XML as format to be written, read or edited by humans? (Personally I much preferred the PHP example given above, and thought that most of it would only need to be typed once and stored as a variable, e.g. various salutations)

This is also relevantly interesting:

moodle notes Word doc

Appears to be notes on Moodle by the founder of the company providing the LGfL's learning platform, digitalbrain with some candid comments on their own products.

Looks like he's just left the company to concentrate on Open Source e-learning solutions of all things, such as porting Sakai to MySQL (which I thought it already ran on?) for/with/alongside the LGfL, Department of Education and BECTA.

I checked this out last week and it only seemed to be searching the wiki module content. Was I doing something wrong or do I just need to update from CVS?

Also, which Lucene search operators can I use e.g. "google" returns a hit for me but wildcard and fuzzy searches such as "goo?le", "goog*" and "googla~" don't.

(Also using quotes to group phrases seems to confuse it, as it escapse them with slashes.)

I get the impression that MochiKits goals (e.g. writing a layer on javascript to be more python-like, in depth technical documentation) while laudable, aren't fully compatible with the kind of javascript coding being discussed for Moodle.

Furthermore, while their comprehensive cross-browser unit testing seems the only sane way to proceed, I think Yahoo throwing lots of time, money and manpower at the problem is going to achieve almost the same, especially as they do actually use this library themselves in a variety of projects.

I think either is a good choice and admit to having a soft spot for MochiKit but I think YUI will grow more in the future, just based on branding and corporate support. I also think the YUI stuff has more to offer than just javascript.