What Does A Web Framework Really Need?

There has been some discussions recently about the role of Plone. Is it a framework or a platform. Should we make a new CMS with Z3/Grok. So I will try to take a fresh approach and look at an absolute minimal system, that would not need a new version for many years.

That got me to think about what is really needed in a web framework to make a coherent user experience. Notice that I mean end-user experience. Not the programmers experience.

Plone has modules for many things

They are all coupled together in a tightly knit system. This is what makes Plone so usable out of the box. It is also the reason that Plone is so hard to learn.


access control, authentication.
security, roles and permissions, Workflow.
data storage, ZODB, ZEO, SQLAdapters.
traversing, ZPublisher, VirtualHostMonster.
content types, OFS types (Old Zope), CMS Types, AT Types, Calendaring. Content Type Translations (html -> txt etc.), Version Control.
form handling
css structure, resource registry.
Templating, zpt, dtml, python scripts, portal_skins.
Editing content, stx, rest, html, kupu, ajax.
Data Querying, ZCatalog, SQLAdapters.
Language support, PlacelessTranslationService, PloneLanguageTool.
Mail Handling
Product Installation


But if we are talking about a framework, most of these things are not necessary. you only need 3-4 technologies to make a stable and usable web framework. The most radical idea I have is a completely new way to think about the templating system.

In the following a "page" is any unique url in the site. AT is Archetypes.

CSS and design guidelines

If you are the user of a website, all you want is for the site to have a strong internal logic. The most important part of that is that the entire site should look the same.

That makes a common css for a site the most important part of a web framework ... go figure.

If all pages developed for a website shares the css, then you can work around the rest. Pages can be made in html, zope2, zope3, php etc. It will not matter as long as they follow the same design guidelines.

Templating

The second most important feature for the user to get a coherent feel for a site, is a system that makes as many of the pages follow a common page structure as possible.

In Plone there is the famous o-ring design. A Page Template called main_template that defines the look of the entire site. This model works well in most of the cases, but it hinders in many other.

If you want to create a new content type in Plone using AT, the O-ring design and shared css is a *big* help.

This was the main difference between plain old Zope 2 and Plone. You could add a product and it would look and feel the same as any other product.

AT got the look and feel integration locked down even tighter, AT content types would share the edit forms machinery.

But that was also where it started to get difficult to work in anything but AT. Because Plone and AT got so tightly integrated.

The main problem with the shared templates being integrated into the system, is that it is hard to use non framework software. Mailman is a great mail list system. Integrating it into Plone? Good luck! There are a lot of BBS systems written in php or other inferior languages ;-) Integrating them into Plone? Good luck!

Imagine if all that was required from the templating system was that the content would generate a well formed XML file with a defined DTD. Then the templating system would just convert that XML file into the actual file served by the http server. It would layer the o-ring, css etc. on top.

Outside applications would just need to be rewritten to output its content as XML and Python developers could use their templating system of choice.

I believe that the site theming / templating system currently is in the wrong layer. I guess it is the same thing that Paul Everit keeps talking about with his XML/XSLT stuff. This would be like WSGI in steroids. A kind of rendering layer between WSGI and the web apps.

Another way to look at it would be as a proxy that fetches content from several urls and rerenders them to fit a common template and site structure.

There could even be a visual tool for changing the layout, that all web apps could share.

Authentication

The two first two features are for anonymous users. If you want your users to be able to log in to the site you must have a common form of authentication. Separate pages requiring separate logins is just not considered cool by users.

Currently it is done in Plone. But it could just as easily be done by a separate authentication server that could run on another port or server:

http://localhost:8081/authenticate?user=admin&email=some@example.com&password=admin

That would make it pretty easy to share authentication.

Username and passwords could also be handed down from a traverser to each page, to automatically log on to 3rd part software.

Traverser

I am not to sure about this one. I don't know much about how the ZPublisher works. It seems like a job for WSGI, or a configuration system to make sure that a certain branch of pages is handled by (proxied from) a specific app server.

Conclusion

So that's it. I think you could make a very good web framework with just those few items. The rest of the things from the Plone stack does not really need to be in a core framework.

That is especially clear with something like content types or templating where many solutions have been used. We cannot get rid of any of them as it will destroy backwards compatibility. Even refactoring will destroy backwards compatibility.

If it was made as I described above, you could use Plone from some parts of a site and Zope 3 for other parts. A specific framework could be used for what it was especially good for. Like Plone for Content management and you could change a discussion board from PloneBoard to PHPBoard in a part of the site, while maintaining the look and feel.

Comments? Would a minimal web app like that be useful? A sort of meta framework.