> > I have a pretty big project written in Python/Django, but I got pretty > tired of Python and I want to move to a more productive environment. >
Without making this OT, I thought Django was considered very productive? Somehow lately I've been hearing more negatives about it.. > So I'm considering two solutions: > 1. Clojure + Vaadin + some ORM > I semi-evaluated Vaadin some while back. It is promising, and has a similar philosophy to weblocks -- everything is done at the backend using seamless ajax, so malicious manipulation at the front end is less effective. In terms of baked in widgets etc. Vaadin is quite complete, far more so than weblocks is. It wasn't really an option because we didn't want to work in java. Perhaps you could evaluate how easy it would be to extend with custom widgets (and hey, while I'm at it how about a tutorial? ;-) > 2. Common Lisp + Weblocks + some ORM > > I learned Common Lisp ages ago, and just recently I started learning > Clojure. I read a lot about both Vaadin and Weblocks, and I did a > sample app in Vaadin - not yet in Weblocks (probably will do > tomorrow). > Tutorial, tutorial! Or paste.lisp at least? > But it's a hard decision so I wanted to ask you the following > questions: > 1. is it easy/possible to implement long poll for continuous updates > of content from the server to the client in weblocks (for a chat > feature, and similiar)? > I would suggest using node.js for comet-y kind of scenarios. Otherwise at any significant load you'll have issues. > 2. what is the ORM/database layer that is preferred for weblocks and > consistent with it's design patterns and core ideas? > I guess most people use clsql. There is also postmodern, and Harag recently wrote a weblocks connector for that (iirc). I use cl-prevalence and dispense with ORMs and dbs, so I hope someone else with more knowledge chimes in. > 3. how hard will it be to build/integrate neat widgets like > autocompleters, tabs, datepickers and so on with weblocks? > Autocompleters exist, you can look at render-suggest to see how it suits you. Basically (render-suggest "field-name" field-fn) is all it takes, field-fn accepts some input (what the user's typed in so far) and returns a list of matches. Date pickers, tabs, are easy with your choice of javascript widget-kit/framework. Basically you can write any widget you want, and use javascript quite effectively to communicate between front-end widgets and back-end ones. render-suggest is a good example of how to do it. There's also multiple js backends coming along, but at the moment you're limited to prototype (we use YUI). > 4. what else am I missing that I will need to build in order to create > a complicated interface with weblocks? Perhaps you can outline what kind of widgets you wish to see? There are distinct advantages in following a widget-based approach (I don't know how close Vaadin comes to that, but I'd put out some example code a while back which showed multiple continuation flows in a page, that sort of thing is imho nigh-impossible in a non-widget approach). I would recommend keeping as much separation as possible between your frontend javascript powered UI and the backend, weblocks powered one (as a general rule). Weblocks works really well to keep your backend in sync with the changes the user is seeing in the frontend (browser) widgets. If you don't want to do this, you can also write RESTY style weblocks code. Another great feature is that the user can just go back to a particular URL, even if the original browser window was closed, and the UI state is unchanged (unless he's logged out). In that sense incremental, javascript-drawn widgets just cannot compete. There have to be some kind of embedded params in the URL if you want js to redraw the "last state" of the UI, whereas with weblocks, it's available "for free". hth, nb -- You received this message because you are subscribed to the Google Groups "weblocks" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/weblocks?hl=en.
