On 19 January 2012 02:39, ianeslick <[email protected]> wrote: > A few years ago I led the development of an open-source project based > on Weblocks and Elephant called LAMsight (www.lamsight.org) for a non- > profit partner organization, the LAM Treatment Alliance > (www.curelam.org). I'm going to be unable to provide regular support > for the site after this coming summer and so we're starting to look > for a Weblocks-savvy developer to take over maintenance and > improvements to the site and a sister site based on the same code base > called the International LAM Registry. > > I recently upgraded the site and code base to run on the latest > quicklisp libraries (validated and running on Nov'11 quicklisp) and > we're launching a patient study and a registration drive in the near > future. The site source is hosted on Github at > https://github.com/eslick/cl-registry > . > > If you would be interested in lending a hand to the project, we can > discuss what kind of arrangement might be worked out with the LTA that > would make it interesting and worthwhile for both parties. Please e- > mail me at [email protected] if you might be interested. >
Ian, First of all - great job on supporting weblocks. It is a great framework and I think that a lot of people appreciate your work and dedication. In my personal opinion, Weblocks would benefit greatly and became even easier to support and maintain only if it would have been split into some smaller components, for example: - weblocks-core - this is where weblocks really shines for me: integration with hunchentoot, session support, actions and continuations, dependencies - weblocks-components - simple HTML widgets, which can slowly grow into feature set provided for example by Vaadin (see http://demo.vaadin.com/sampler) - weblocks-scaffold - scaffolding features - weblocks-persistence-clsql - integration with clsql - weblocks-persistence-... - integration with other persistence providers (e.g. mongoDB) right now, even if someone has to make a simple web application with custom components, he/she has to deal with clsql/fluid dependencies. Also, such division of code would allow developers to split work more naturaly. Let me know what do you think about such approach. Best regards, Tomek Lipski -- 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.
