I think the Hunchentoot mailing list is a suitable starting point to discuss such a framework up to the point where enough traffic has been gathered to create a suitable standalone project. common-lisp.net is a free hosting service for Common Lisp projects, just let me know if you want me to set up infrastructure.

Yeah, but what are the chances that it will end up with something superior to weblocks? Pretty low I guess..

t

On Tue, 2009-01-20 at 11:35 +0100, Hans Hübner wrote:

On Tue, Jan 20, 2009 at 11:14, First name Last name zaries@global.co.za wrote:

...

What I was thinking about was free standing widgets that don't need a whole framework to carry them. A specification for something like this would include a list of common properties/functionality and general methodology (persistence,state...etc) that would fit in with hunchentoot's design and strong points.

Start with something new. I do not think that Hunchentoot itself should be extended to include a widget framework, and I also think that Edi's development model is not suitable for an effort similar to the one that you have suggested. Rather, I think what you are talking about is creating a web framework with certain properties that you don't seem to find in other frameworks.

I think the Hunchentoot mailing list is a suitable starting point to discuss such a framework up to the point where enough traffic has been gathered to create a suitable standalone project. common-lisp.net is a free hosting service for Common Lisp projects, just let me know if you want me to set up infrastructure.

I'd suggest that you go ahead and maybe start by detailing out what you think should be the common denominator for the "widgets" that you propose.

-Hans

---

tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel

I agree that hunchentoot should not be altered for the sake of widgets but in an effort to keep the framework as bare boned as possible I would like it to be as close as possible to hunchentoot + cl-who basics.

Here follows some high level ideas I have.

Basic Goals:

Widgets should be as free standing as possible.

Widgets should follow simple rules that create conformity from the view of the user and the implementer. These rules should be inforced by minimal plumbing/framework code.

Plumbing/framework code should be simple and light.

Widget Basics:

Widgets have properties that can be set and/or read. - Simple properties would be hunchentoot:parameter's - Complex properties would be clos objects or lists of objects - Complex properties that are objects or list of objects would free the widget from any persistance dependencies making persistance the resposibility of the user. There are just to many persistance models to comfortably integrate it into a light framework. Or widgets could be grouped/categorized according to their persistance models?

Widgets have events. - Mandatory events - Optional events

Only certain properties can be set and/or read in the context of an event. - This has to do with the fact that get or post form actions have limited access to hunchentoot parameters (see handlers)

A user should be able to register handlers for events. The handler registration code should use the plumbing/framework code to enforce the event property relationships. - Handlers are hunchentoot dispatchers

Widgets should be as generic as possible and as close to hunchentoot basics as possible. By this I mean that widgets should only use hunchentoot, cl-who and basic CL so that anybody with a basic understanding of lisp and web/html can hack them.

Widgets should be self documenting. By this I mean that events, properties and the fireing sequence of events should be accessible via code so that plumbing/framework code can enforce rules.

Questions:

The big question I have is whether the plumbing/framework code should use clos (my clos knowledge is very limited) to better group/package rules or whether plain CL would do. In deciding this we should consider both simplicity and cleanliness of the code that uses the pumbing/framework code.

Conclusions:

In my opinion the above would give the widget designer the option of being very generic or very prescriptive depending on the widgets goals, yet it would have enough conformity to be recognisable as a widget based on the plumbing/framework code.

Regards Phil