After attending the Pycon 2010 Forms panel (video link)and reading Ian’s latest post on the subject. I figured I should write my thoughts on this to see if someone agrees with me and maybe I can finally release some code that implements this.
The main problem here is that All frameworks (including ian’s anti-framework) are focused on solving the “forms” problem and they totally sidetrack having “display widgets” and more advanced controls.
Take for example Twitter.com after you login at http://twitter.com/ all you see is a ton of links and a couple of buttons, if you look closer there is one form and it’s very tailored to that specific post which is something none of the “form frameworks” allow because their hole goal is to shield you from the complexity of the html/CSS and JS code by coding the form in python. And as Ian puts it you have to dive deep into the framework to figure out where and how to replace that template.
Now the missing part of the and again I’ll use twitter as an example http://twitter.com/followers it’s all buttons! there is not a single form in there yet they are all widgets I’m pretty sure the internal code to render each one of the people following you it’s a widget and the drop down controls are probably widgets too.
If you take a look at other popular sites like facebook, digg, reddit, tumblr, etc. they all follow this pattern of display widgets with ajax callbacks to the backend. And this is where I think all current widgets/forms libraries fail. None of them have this type of setup and the few that do (Sprox & FormAlchemy to my knowledge) end up having to make the problem several degrees more complex than what it should.
And this is why I think we need a totally new tool for Widgets, one that is not trying to solve (once more) the Forms problem but focuses on solving the display and interaction problem.
This tool should have the following components
- handle render and validation client-side and leaving the server-side to the framework
- handle rendering “display widgets” for each object type, that is if you have a Comment object, they should all render the same way.
- Injection of resources, like ToscaWidgets where rendering the widget will inject it’s CSS and JS files, this is actually just a fix because html and JS lack a proper import directive.
- Handle callbacks and errors.
The problem I see with this library is that implementing it in python means making it obscure by hiding the details, while implementing it in JS will tie it to a single framework.
Thoughts and Comments appreciated
-
elpargo posted this