David Scotson

That tracking bug pretty much matches my wish-list for TinyMCE in Moodle and it looks like they're all fixed in 2.4, yay!

I think the only thing left on my wishlist is an editor that switches between a small, simple non-threatening setup and then gives you the full power and flexibility if you hit the full screen button.

You joke about a css_writer but there's actually a bunch of solutions for CSS that do almost exactly that, e.g. the LESS compiler I use:

 

// LESS



.rounded-corners (@radius: 5px) {

  -webkit-border-radius: @radius;

  -moz-border-radius: @radius;

  -ms-border-radius: @radius;

  -o-border-radius: @radius;

  border-radius: @radius;

}



#header {

  .rounded-corners;

}

#footer {

  .rounded-corners(10px);

}



	



/* Compiled CSS */



#header {

  -webkit-border-radius: 5px;

  -moz-border-radius: 5px;

  -ms-border-radius: 5px;

  -o-border-radius: 5px;

  border-radius: 5px;

}

#footer {

  -webkit-border-radius: 10px;

  -moz-border-radius: 10px;

  -ms-border-radius: 10px;

  -o-border-radius: 10px;

  border-radius: 10px;

}

 

Writing CSS and HTML can be really tricky sometimes, but introducing systems to make it easier in some ways can make other things harder. It's a very messy problem space.

For the same reasons of changing in one place, it would be good if "links with icons" were created in one place, rather than built from scratch each time, then that code snippet could look something like:

 

 return html::div('editquestion', html::icon_link($editurl, 'edit', _('editquestion', 'question')));

 

Or if the wrapper div is standard (it's not really clear from just looking at this one) then it too could be written out within the standard function)

 

 return html::icon_link('editquestion', $editurl, 'edit', _('editquestion', 'question')));

 

As I said, I realise this is a more programmer-y way to think, HTML coders might think where do I figure out what the parameters are etc., but you don't really get the ability to change and theme without that level of encapsulation. Maybe if those functions were "templates" it might make more sense though I think once you start getting into small modular components the line between PHP functions and re-usable templates is fairly blurred.

The general concept is good if your doing some complex code to decide what the id, class, and href etc. for a tag is going to be. Then you want functions that will e.g. let you add or remove a class and not have to worry about quoting and adding a space between each name etc. . That rapidly gets nasty if you're just writing the low level code.

But for outputting "<div>" it's clearly overkill. Well, I say "clearly" but do we expect everyone working on renderers to understand when and where this is a good idea and what the tradeoffs are?

I would suggest that there is no simple speed test for Moodle, or any other web application.

The subject is so complex that almost everything you read is voodoo and superstition.

To give just one example of the complexity, for years people obsessed about the speed of their servers and databases etc. in generating the HTML document, then Steve Souders measured it and showed that for most sites that accounted for only 20% of the time that the actual user spends waiting.

http://developer.yahoo.com/blogs/ydn/posts/2007/03/high_performanc/

Which is a great, a better understanding of how things work is always good, but now you don't have to just understand Linux and MySQL and PHP, you also have to understand HTTP and Proxy behaviour and Browser Caching and the different javascript behaviour of different versions of IE to understand whether a change is actually an improvement or not. Oh, and have a better grasp of statistics than 90% of software developers, scientists and doctors have been shown to have. (There's a rant by an internet-famous ranty software guy, with lots of rude words in it, with the title of "Programmers Need To Learn Statistics Or I Will Kill Them All", which you can google for if you're interested)

So, if you follow the standard performance advice in setting up your server (i.e. use a PHP Cache, use gzip) and Moodle (i.e. don't leave theme designer mode on) and measure your server to ensure you're not hitting any bottlenecks then from that point on I'd just use whatever features appeal to you. It's a massive task to prove (in all but extreme cases) that one Moodle setting is better or worse than another to a noticeable degree, so I'd spend my time elsewhere.