Current state
"Polluting" global namespace, code that makes you cry, no rules how to write javascript and no tests at all, that's what we have in Plone with one sentence. Our widgets suck big time. Best example how much they suck is when you have a textarea for Contributors field. text-fucking-area people. Like its 1995. Oh and you have to somehow memorize all usernames, so sorry if I don't remember that out Mary's username is "hornyashell".
Yes it's bad, but once you're this low it can only get better, right?
How can we improve
Maybe I over emphasized how bad the situation is, but if we don't do anything in near future, this is exactly what somebody is going to tell about Plone.
We need to:
- start ripping out old javascript code and replacing it with something sane.
- untested javascript should NOT make it into Plone FROM TODAY ON.
- get our shit together and learn this freaking javascript.
Plone Mockup
For reasons mentioned above I started a project called Plone Mockup. Goals of this project are:
- Front end developer should never ever have to hear the word buildout. Well I believe word buildout should only be used in jokes, but thats the whole different story.
- Develop javascript code outside python packages and provide bundled and compiled version of javascript. Why? Because tools that help you work with javascipt will never be as good in python as they are in javascript. It makes me throw up when I see another javascript minifier written in python. Let javascript folks take care of their stuff.
- There is almost no way we'll find enough time to replace all bad javascript code at once. That's why slowly replacing bad parts and creating bundles for those python packages is a nice compromise.
- Use modern javascript tools / techniques. eg: RequireJS to mention one. And don't be scared to experiment.
- Plone Mockup - at some point - should become fully functional Plone interface.
I've mentioned bundles quite often, maybe it also nice to actually explain what they are. Bundle is a collection of many javascript modules. Instead of registering tens of javascript files with ResourceRegistries you only register one.
First bundle: Widgets
Is a collection of different widgets which should be part of Plone since last year. To provide modern widgets I'm depending on 2 external libraries: select2 and pickadate which are wrapped as patterns and registered with Patternslib.
I saw some comments in last blogpost that were concerned about why depend on Patternslib at all. Just to clarify, we don't depend on whole Patternslib, but only its registry. registry is keeping track of patterns, which can be then initialized over some context. This becomes incredibly useful when you inject some content via ajax (eg. modal/overlay) and you wish to initialize javascript only on that part of DOM.
That said, we can only benefit from depending on Patternslib, since if there are any interesting patterns that we can use we can easily include them. In other case we still have a unified way how javascript is triggered in Plone.
Patternslib also gives us nice way to trigger patterns via pat-<pattern-name> class. This is something that is not forced on you, since every pattern is also jQuery plugin and pattern can be triggered as jQuery plugin.
Many would also say that using data-* attributes for providing options to pattern, reminds them on something we are trying to get away, KSS. But there is a clear difference. KSS tried to invent new language, while we are just passing options via data attributes. Also many other frameworks (eg. Twitter Bootstrap) is using this technique and many seem to like it.
Also I'm using RequireJS to define dependencies, but once compiling them to bundle I'm using almond which is a lot lighter version of RequireJS (but also does a lot less). Now if we at some point decide to go with some other implementation of AMD for whatever reason, we'll have dependencies already defined.
Last to mention is a tool call jam which is used to keep track of all dependencies. jam automatically creates RequireJS configuration for our dependencies. And jam wouldn't be complete if there wasn't a nice way to create bundles, it provides compile subcommand which does this for us.
Now, I've mentioned many new tools which are used in Plone Mockup but that is only what is under the hood.
Next?
I hope I explained some parts of Plone Mockup and how all works. I'll try to improve documentation about it and would also like to hear more concerns about decisions that I already took with Plone Mockup.
I think plone.app.widgets is ready to be submitted as PLIP and hopefully plone.app.toolbar will follow soon after that.
Please look at documentation provided at http://plone.github.com/mockup and if something is not explained well I'm always looking to improve it.