PHPless Version

I recently wrote a utility on Sourceforge called PageTabs (http://sourceforge.net/projects/pagetabs).

This does exactly what SleekTabs does, but without the need for PHP.

It's also much simpler to deploy.

Rob.

First of all, I'd ask you to remember that SleekTabs is still only in an early stage of development and so has not yet reached its final maturity. The installation and configuration process is hopefully going to get better over time and as development progresses.

SleekTabs being written in PHP has a number of benefits - it can be handled server-side and you will be able to utilise the PHP class to dynamically create tabbed interfaces directly from your server-side code.

Additionally, SleekTabs will have a much more developed fall-back system which will allow for the tabbed interfaces to gracefully degrade and still work where JavaScript is not enabled in the client browser.

I've got quite a bit planned for the next release, but I won't see a lot of development time for it for a few weeks.

Hope this answers your questions.

The class writes JavScript code to the browser to do the work, so is NOT server-side code.

In addition, you can't remove the JavaScript code, otherwise you can't hide the tabbed content without reloading the whole page. It also means you can't use AJAX to retrieve the data for the page content.

So, I still can't see where there is any advantage in embedding the code in PHP. By their very nature, JavaScript and CSS are best suited to .JS and .CSS files, not embedded into a server-side application where the code has to be transferred every time a page is requested.

Rob.

Sorry, I didn't explain myself clearly enough last time.

The server-side code benefit here means that the developer can more easily dynamically generate a set of tabs than with a 100% client side solution. The PHP code itself then dynamically generates the appropriate client-side code which is sent to the browser. The Ajax stuff, obviously, happens on the client end.

No, the fallback functionality does not use Ajax, but that is the whole point of gracefully degrading, that the interface still works for users without JavaScript, it's just not as flashy. In the next version (which may be coming significantly sooner than anticipated), I'm planning for a solution where the fallback functionality can be automatically implemented with no extra effort required on the part of the developer (at the moment this is not the case and the fallback is still quite difficult to use).

I will also investigate the possibility of having an option for using an external static CSS and JavaScript solution as this would address the problem you very rightly identified with the code being transferred on every pageload.