Forum OpenACS Development: Re: mktree.js uses a non-valid HTML attribute

Posted by Gustaf Neumann on
Dear Emma,

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 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.

Posted by Emmanuelle Raffenne on
Hi Gustaf,

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.

Posted by Emmanuelle Raffenne on

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 added a global javascript variable "mktree_remember", that defaults to false, to be set in the head block before loading mktree.js. The difference now is that the "remember" flag is not set on a per-node basis but on a per-page one. I think it's a minor issue though given the use of mktree in the toolkit.

I've committed at oacs-5-4 branch.