Support for Weblocks project

[ianeslick]

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 iane...@gmail.com if you might be interested.

Thank you,
Ian

[Tomasz Lipski]

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

[Leslie P. Polzer]

On Thu, Jan 19, 2012 at 02:21:21PM +0100, Tomasz Lipski wrote:
> 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)

I agree that such an approach would be very beneficial. I'd like to see
it put into place myself.

Leslie