[hunchentoot-devel] Widget Guidlines

[Phil Marneweck]

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 at 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 at 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