Forum OpenACS Development: Re: mktree.js uses a non-valid HTML attribute
The cookie-management code of mktree is not very efficient and has no simple interaction semantics with the CSS classes liOpen and LiClosed (controlled via backend). If OpenACS would set for every inner node of the tree a cookie, it would set example for the page openacs.org/xowiki about 40 cookies. The approach of mktree does not scale well, when e.g. a user is in many communities with many pages using mktree. We use a similar change in learn since a few years, and some users carry quite an impressive list of cookies for mktree with them. Once the users are used to the feature, one has to continue to support it, which makes the usage of nicer tree interfaces more effort.
The code based on IDs has some more problems, like e.g. the ID management (how to keep the IDs unique per page), esp. when pages content are included. In the case if the coockie management of mktree it is even worse, since if the same ID is used on *different* pages, the list item will open on a page B magically, when an other list item with the same ID was opened before on a different page A. This can be avoided by a clever ID construction, but i am not sure, we want to go that far now.
I am not aware of any application in openacs/dotlrn, that uses the "remember" attribute, so i am not sure whether your comment about validation concerns the dotlrn package and openacs in general or some tailored package.
My recommendation would be to either avoid the feature for the packages of the generic openacs/dotlrn release, or to make it conditional, controlled by the package programmer (as it is now) but to use instead of the non-standard attribute "remember" an additional CSS class (e.g. "cookie") to flag that the ID of this list item should be remembered.
I agree that the cookie-management of mktree is not efficient and doesn't scale well.
There are 2 package that use (or used) the "remember" attribute:
1. dotlrn itself in the main portlet, I removed it month ago so since then you always have to open the node to click on a club/class. But this one is not critical.
2. the SCORM player in lorsm. for this one, we really need to remember the state of the tree nodes.
I'll modify mktree.js to check for a "cookie" class then, or maybe better a "remember" class in the node.
Thanks for your comment.
Finally I didn't use a class to flag the item. IMO, a class should be used only to define a style and besides it would have required way too many changes in mktree.js.
I've committed at oacs-5-4 branch.