Navigation/Pagelib/Blocks 2.0 design

Oleg Sychev 15:38, 25 February 2009 (CST): just some thoughts that occurs reading you plan. I can elaborate more if some of them will interest you.

Clear global navigation framework

"We are close to having this already, because each page in Moodle should have a list of links in the navbar that shows where it fits in the scheme of things. (Although sometimes not all links are shown here, for example, Course categories are not included, and the 'Forums' type link is controlled by an admin option, however, that is a presentation issue, it does not affect the underlying layout.) We should ensure that this is carried through consistently." - care should be taken there to not display too much on navigation bar (current state of thing have a nice balance what to show, and what not). I think about a one/several additional blocks, which can hold other useful links. They may include:

1. complete tree or complete current branch links
2. activity (page-generator) suggested links
3. user-choice links for that page (maybe teacher controller one too)
4. stat-generated links (i.e. links to the pages where this user go from that page more often)

Such way user can choose which links he whant to see, instead of very long navigation line he can't control. I also wondered, should not this line be produced by a function of some page class (which instances should be actual pages, not just one instance for outputted), so that any subclass will add their own links without bothering about parent ones (i.e. moodlepage->coursepage->activitypage etc hierarchy)

We already have the build-navigation function, which will build the correct parent navigation links based on the $COURSE global and a $cm object, if it is passed one.

I agree with you that one of the goals is to enable most of the navigation to be done with blocks, so people can easily experiment with different types of thing outside core code.--Tim Hunt 23:34, 25 February 2009 (CST)

Class for HTML generation/page class

Certainly my +1 there (thought it probably isn't weight much). But why you think only about function collection (HTML-generation) and data (page) classes instead of class which instances would be a pages? That will allow a real inheritance there, with some useful base classes (activityviewpage, activityindexpage, activityviewtabbedpage etc for instance). This also allows a better ensuring of login and basic capability checks thorought a base class methods, which should be very good for overall security (3d party modules included). When all pages are instances of subclasses of some class you are really can start to enforce some things.

I think that page class can have some additinal information too. It must contain a group-related information fields if a page uses group-selection combo control. That way such info can be passed directly to functions like get_users_by_capability (or there should be groups_get_user_by_capability), which should allow to circumvent a great deal of group (grouping, cohort, whatever else) related code from a modules code - that should significantly easier any group system modifications.

Maybe there will be also a standartised way to pass info from what page we go there (or returnurl), so the pages should not worry about passing it, only should they use it.

"This class will probably have very little code, it will just be information storage." - this class can be a good place to solidify code, that now distributed throught the pages, to avoid it endless duplication, like basic group handling, login enforcement or returnurl setting (these are just examples that come to the mind right away, there can be more).

There is a limit to how much we can refactor in the Moodle 2.0 timescale. Further changes may be possible in the future, and some of your ideas are interesting.

Moodle does currently have a page class hierarchy, but it is badly documented, and no one ever writes the classes they are supposed to for new plugins, which is why I think it would actually be better to get rid of it now.

Modern Object Oriented design tends to favour aggregation over inheritance, which is one of the reasons I think it correct to have a relatively small class for tracking page information, which may well start collaborating with other class hierarchies in future.

One of the reasons for prefering aggregation to inheritance is because we only have single inheritance, and there may be several different dimensions we want to subclass in in future, hence the fact I don't want to pick one particular dimension for subclassing the basic page class. If it becomes neccessary, I would rather link to classes in different hierarchies - the the different HTML renderer classes.--Tim Hunt 23:34, 25 February 2009 (CST)