I'm not sure about the proposed approach to hierarchy support by the db changes
- add field course_sections.parent (default 0) to allow sections hierarchy
- add field course_sections.visibleold to store original visibility when one of the parent sections is hidden
Given that in most cases we do not expect thousands or even hundreds of sections in a course it may be simpler to maintain a delimited list of sectionid-depth pairs in their order (the order is already there in the good old section field; please do rename to order or sortorder or similar).
0 56, 0 34, 1 57, 1 58, 0 35, 1 89, 2 111
which translates to the hierarchy
With such a list it should be fairly easy to handle moving/adding/deleting sections, to generate the navigation tree, to manage visibility and availability and most importantly to adjust in restore. That's how I implemented it in my (obsolete, thanks to your work on this important enhancement ) course format and it seemed to work reasonably well.
Of course, if the course manager doesn't set a hierarchy the field that holds the list remains empty and navigation is generated by the simpe order.
Marina, at present the detalt landing ground when you click on a course with single section layout ON is the Course main page.
Is it easy in your possible future to set it to go to the display of section 1?
Is it easy to have a format control Moodle pages to appear with blocks at the left? I'd like to have a menu block there.
I prefer to have a consistent navigation, and with the pages it goes away.
Derek, your second point should be covered by MDL-27509.
Marina, to generalize this point, it is not entirely clear from the dev docs how course/view.php is affected. Given the refactoring it seems that all the functionality currently done in course/view.php should be moved to the format base class because in effect the course is just a backend service provider for the format and modules.
In addition to Derek's comment about landing page (Re: Course formats refactoring 2.4) I think that current implementation of single/all in the course settings is not very useful. Displaying all sections or a particular section could be a navigation option. Forcing layout (all or single, current or any) should be done in the format level.
Also, the user's viewed section was used to be stored in user preferences. I'm not sure how (and if) the usr preference is handled in 2.3 or the 2.4 refactoring and how the user goes back to where he/she left off.
Hi. Sorry after the topic was moved I stopped receiving notifications.
Derek, is your question about if new API allows this for the contributed course formats or are you asking about core topics/weeks formats? If you ask about API, then you can do it already in your format.php. If you ask about topics/weeks formats, I do not have plans to change their functionality.
Itamar, options such as single/all section setting on the course level will become course format specific option. Topics and weeks formats will still have it but contributed formats do not have to.
Maria, apologies for the delay in responding.
I'm not sure I really understand your question. What I was hoping for is the option (when opening a course for the first time) to go to directly to section 1 (single page view) rather than to what is referred to as the Main course page.
ie in core moodle, to be able to set this, (or to be there as a default)
I've done a little bit of testing with users. I have developed the habit of using the first section as "Start Here" but if I make the page look nice (ie something reasonably consistent in each section description) and compact (without too much in each section) then it really doesn't provide a clear focus on where to start.
Or plan B: to be able to go direct to the "Highlighted weekly topic" page and show just this section.
Thanks for this, the specification looks good and it'll make creating exciting new course formats so much easier by the sounds of it.
I've been thinking a bit about how, while we're at it, we could look at moving some of the 'print' functions that still exist in course/lib.php to the format renderer and give the individual formats a little more control over sections and activity content while doing this full refactor? You touch briefly at the bottom of the specification about creating a 'Class Course' after this particular 2.4 targetted work is complete and mention print_section etc below the main ideas on that but not what, if anything, is being thought about their future so I'm interested if any of this has been discussed already and what the thoughts were.
I've often wished that at least print_section(..) was easier to modify on a case by case basis and the course format seems the more suitable location for them at least that I can find. I had a bit of a play on my 2.3 dev instance the other day, literally just copying the functions and amending the calls to them and it seemed to behave correctly without any obvious extra work being required to maintain the functionality but I could see areas that for robustness and better extensibility and theming the functions might also be worth refactoring independently - in particular also to ensure that the YUI 'drag/drop' requirements for <ul><li> structures aren't broken by contributed formats and that completion indicators and activity listings themselves could be drawn independently etc. I don't have any serious conclusions here though, more just awareness that there are points that might need extra focus or could be better worked as rendered elements to make it more usable.
Looking forward to seeing where this all goes, happy to help out if you need the extra pair of hands as well.
Hi Stacey, I also wanted to do it very much, just left it to the end.
It does not seem like a small thing, i'm not sure we can fit it in 2.4 especially considering that there was code freeze already. I created an issue MDL-36320 please feel free to comment there.