The discussion related to the broken block drag and drop has come to an interesting point: There are some fundamental changes in Moodle necessary to solve the issue.
Mary's and my proposal to use a layout file for the /my page as part of a flexible solution is not seen as an option for Moodle. It would be interesting how other theme designers / Moodle developers interested in themes think about this aspect. I post the answer I have written in the tracker here again because I think a discussion about the layout file approach in Moodle makes sense in this context.
...
In one aspect I disagree - the /my page must be implemented with a layout file. This is my opinion based on the work I do and the experience I get from my work: PHP development, JavaScript development and theme design.
The /my page is a special page type in Moodle. With Moodle 2.x all page types are listed in the Moodle theme config:
base, standard, course, coursecategory, incourse, frontpage, admin, mydashboard, mypublic, login, popup, frametop, embedded, maintenance, print, redirect, report, secure
Each of this page types has its individual characteristics and is a candidate to get its own layout file. The reason to decide when to use a layout for a page in a theme should not be how many pages use this layout but should be if the layout helps developers and theme designers to display the content on the page in the appropriate way.
A coding tendency in Moodle is - as I see it - to handle most tasks programmatically in PHP - use renderers, methods etc. wherever possible and avoid the use of direct written HTML wherever possible. And now more and more code is written in JavaScript in addition to PHP. And a coding rule is to avoid code duplication wherever possible.
Layout files are HTML files with included PHP calls (direct written HTML). And several layout files contain the same basic page structure (code duplication). So the tendency is to use as few layout files as possible and solve individual demands for some pages with specially written PHP and JavaScript.
With the /my page we have a good example that the PHP/JavaScript coding approach leads to trouble if you change code in one place and don't change related/connected code in other places => drag and drop breaks. And we see how difficult it is to track the connected places where code needs to be changed. If for the /my page a layout file would have been used some themes could use the old method to include blocks and other themes could use the new method and nothing would break (I guess without having checked the details).
So please rethink the strict rules to always avoid direct written HTML and to always avoid code duplication and use layout files instead for all pages where otherwise special new methods in PHP and JavaScript would be necessary.
One advantage of using layout files is that theme designers can more easily adopt the page layout to design/client demands. With code written in PHP and JavaScript these changes are not possible if the code has not been implemented as a renderer.
So I am sure Moodle would work better using/offering more layout files for the different page types than adding complex code to core to handle differences - better for theme designers and better for developers too.
What do you think?
I think that it is paramount that the my page be it's own layout.
While I know it servers a special purpose. But so does every page in Moodle. A calendar, course, category list, report, etc pages all serve special and specific functions. Why should My be considered any different.
I agree that a rethink is in order. But lets look at this as an opportunity to standardise all these areas. Move ore of my code into renderers that can then be applied to the my page and other thoughts along that ilk.
Just my 2c
Julian
Hi Urs,
I've read the comments on the tracker and I think its a mess. There should only be one blocks / drag and drop rendering functionality as an API instead of two. When the new form was introduced and seen to be different and better it should have replaced the old completely. As a developer I would rather see progress being made even if each new major release means API changes for me.
Contradictions of implementation lead to complicated patch solutions. Simplicity of singular encapsulated functionality solutions is far easier to maintain and fix issues in. Therefore, stick to one solution per concept and then use OO theory to implement it such that it can be replaced in one location with minimal API changes so that lots of other code does not have to be changed.
So I would want Sam's idea of moving all of the old themes to the single 'blocks' method as the solution to underpin your idea of using the layout files as they should be rather than having too many layout files of a 'one size fits all'.
Gareth