In D5 I've gotten remote tabs working. The strategy I used was as follows:

in the theme_tabset() function I take the page content and cache it using the key:

md5($_GET['q'].$element['#tabset_name'] .'-'. $element[$key]['#index']);

Then, I set the href to /dynamic/cache/

Finally, I added the menu item in hook_menu to redirect dynamic/cache/arg() to a function that simply retrieved the item from cache, (based on that key), and printed/exited.

The one obvious problem with this solution is the cache dependencies - if a person views a tab after the cache is invalidated. I've thought about a few solutions to this, each with their own downsides.

But this type of behavior would be a great addition to tabs.module!

Comments

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Interesting approach and an often requested feature.

Whenever we open up a new menu item, we're exposing data in new ways and need to ask: can we ensure access is appropriately handled?

This would be implemented in a #process callback on the 'tabset' element type. It could be done in a separate module or directly in tabs.module.

I'd welcome a patch.

SolomonGifford’s picture

SolomonGifford commented

Access is an issue as you say. The inherent problem with caching tabbed content is that the tab doesn't "know" the permissions of its content. The block_cache module allows each block to be cached per user or per page. If the wrong selection is made, a security violation or a performance hit are likely results. The same issues apply here.

By caching the data and then opening it up to everyone via the md5 key, someone could "guess" the url if they can guess the tab name. In fact, dynamic/cache/ could theoretically allow access to any tabbed data, though guessing the md5 string is obviously a hurdle and may be acceptable if documented. Additionally, a tab could contain multiple variations, depending on the user's permissions. The current scheme would not take these differences into consideration.

Improved Scheme:

If for each dynamic tab the programmer had to specify whether the tab was cached per user, per role, or per page, then we could either store the content in the session (for per user) or in the cache (for per page). Finally, for per "role" caching, we could include the specified role as an argument in the dynamic/cache/role/md5 and then make the key equal to concat(md5,role), only accessing the cached content if the user is a member of that role.

Does this solve the access problem?

Another known limitation inherent with cached forms:
Forms that use validation tokens will most likely not work in cached tabs. This is true for any cached form.

nedjo’s picture

nedjo
he/him/his
Primary language English
commented

Maybe using the $_SESSION is the way to ensure we're getting the appropriate tabs.

solomongifford , could you post a patch?

moshe weitzman’s picture

moshe weitzman commented

Not sure I follow this request - remote tabs are a core feature of tabs plugin. see http://docs.jquery.com/UI/Tabs#Ajax_mode

moshe weitzman’s picture

moshe weitzman commented

It seems like theme_tabset() is written such that it assumes local tabs. Would be nice to tweak it and the APi so author can do ajax tabs as defined at http://docs.jquery.com/UI/Tabs#Ajax_mode

nedjo’s picture

nedjo
he/him/his
Primary language English
commented
Status: Active » Fixed

I've added support for a new attribute that can be set for tabpage elements: '#ajax_url'. This can be a relative or absolute url. See docs/tabsexample.module for a sample implementation.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.