Urs Hunkler

Melissa, Moodle is an Open Source product with a vision, a strategy, a roadmap and a team with Martin as lead developer. This team takes care that development stays on the roadmap - besides all development work.

Martín Langhoff described a very important aspect about Moodle development which is not on the main Roadmap. You need to prove that your idea is working, either by proving with code or with arguments that convince the core team.

On both ways I too was able to successfully contribute to the Moodle development:

• With good arguments and layout scribbles I could show how a possible change of the XHTML hooks and CSS system might work. It has been implemented in Moodle 1.5.

• Besides arguing for Ajax and an JavaScript interface library I was showing a working Drag&Drop course and proposed a project for Google "Sommer of Code". In Moodle 1.7 a JavaScript library and the Drag&Drop course will be implemented. You may search the forums and will find several postings where people stated that Ajax is not important for Moodle. They spoke for that time and the needs evolved.

A very important benefit of this sometimes hard and in some cases frustrating procedure is that you do not only need a good idea but you also need to have good arguments or examples why this idea is important. And while discussing your idea you will see if it finds consensus. If not you will either see that the idea can't work or you will find new arguments, other point of views etc. to bring the discussion forward.

Keeping a complex software on a good way needs a strong protecting power. I suppose one of the reasons why Moodle is successful is this power. In most comparisons about CMS systems I read concerns about the reliability of Joomla! development because of the strange branching from Mambo. An everything goes strategy does not lead to a successful product.

Bring in your ideas, prove that they work and be successful with Moodle. If Moodle might not be the right product to work the way you want please be fair and choose another product without blaming the Moodle core team.

Urs

Martin even better. No need to say sorry. The admin setting is just the next step towards the perfectly working Drag&Drop course editing.

I am sure other steps will follow

John, Ken is right. The Ajax drag&drop feature has been deactivated.

It's better for the moment to go this way than to produce too many errors and may be angry bug reports The bugs will be resolved and the feature turned on again.

If you want to turn on Ajax for your Moodle installation, just comment out the return on line 12 in lib/ajax/ajaxlib.php. And be aware of possible inconsistent behaviour.

Thanks for your patience
Urs

Martin,

yep, you need to know a lot to change Moodle pages due to their complexity. It is crucial that Moodle can handle "many different scenarios".

A clear structure dividing the content generating part and the presentation part into two separate files would help a lot. On one hand to understand the logic and on the other to be more flexible with the presentation. I am not talking about an additional self contained templating system with it's own logic and programming structures. And it's heavy load on the server. I am talking about dividing.

I will stop to use the term "template" from now on. I will use the term "dedicated view file" instead to avoid misleading associations.

One example of systems dividing content, process/event controlling and presentation are MVC frameworks. By the way XForms and QT Toolkit since Qt4 release build on MVC frameworks. MVC is one way into the future I know about the controversial discussions about the MVC concept. And I know that Martin originally implemented a concept which comes very close to the MVC logic. The difference is that Moodle puts all parts into one file - MVC uses three files. What about "just" moving the view part out into a separate file?

The argumentation about either CSS or "dedicated view files" may not hit the point. To be really flexible and to be able to react on those many and sometimes very special real world needs we need both. You can change a page with CSS through absolute positioning which has a completely different structure built in. But you need a whole lot of CSS to overwrite the page structure. Cracking page structures is against the CSS concept. It is meant to build the page presentation. And the amount of CSS you need decreases page transmission time. I always try my best when I work on Moodle Themes. And most the time I am quite successful But do not ask how big the CSS files may become and how much time it may take to get there.

Julian, you are creating great Moodle sites which show Moodle's great flexibility. And I know what I am talking about too and I know the Moodle CSS system very well. I am constantly working on enhancing it. But I more than once come to the point where I must start to patch Moodle code to fulfill project needs.

"Dedicated view files" which theme designers can change when the project demands it are something completely different than just patching the Moodle core. "Dedicated view files" are a concept to offer theme designers and people more flexibility who are working on implementing Moodle into university networks, corporate intranets etc. They give you flexibility through the front door and not through a backdoor with patches or structure breaking CSS.

Do my arguments seam to suggest that Moodle has very low themeing capabilities? The opposite is true. Moodle offers very good possibilities. And it offers a unique feature for CSS work: Chameleon, which makes it stand out from many other web applications.

But you always need to consider to make a good product better when there is demand for enhancements.

Urs

Samuli, csszengarden.com is a great experiment with a very easy page structure to show the flexibility of CSS page layouts.

Moodle comes with much more complex page structures - due to it's many different areas. In Moodle you can do much with CSS but not everything. To close the gap "template" pages would come in handy. Theme developers or theme designers could adopt Moodle even more to the environmental needs users or customers have - exact integration into the intranet, special accessibility needs etc.

Your proposal in your last paragraph sounds great to me. You focus on the main two issues:

• "UI only" pages (aka templates)
• custom versions ... inside theme folders (template replacement)
• and a third one may be modular templates for special page areas like sideblocks, forms etc.

With which programming technique these aspects may be resolved in Moodle is not that important. And perhaps only some small steps are necessary to start going this way?