Re: [hunchentoot-devel] Widget Guidlines
Hi
I have been using hunchentoot for the last two months and I have created a
DB-Grid widget for myself. I pass relevant info in through parameters like
table name and columns to display and the widget generates a html grid with
paging, edit/delete and search functionality.
Hi,
I believe that attempt for such standardization could be weblocks
(based on hunchentoot)...
Best regards,
Tomek Lipski
Tomek I think weblocks is a bit of a over kill. I have never used it but from what I saw in the documentation it is big and in my opinion might carry to much over head. I am sure it has its right full place but I am not sure this is it. 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. Regards Phil PS. Apologies for re-posting but I am still getting the hang of using the mailing list....for some reason the previous post lost the text (think it is because my web client wraps replies in table)
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
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, Jan 20, 2009 at 12:15, Tomasz Lipski <tomek.lipski@gmail.com> wrote:
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..
Not all needs are the same, and it may be that there is an interest in whatever Phil comes up with as a mission statement for his widget library. I don't know Weblocks, but I have glanced at its web site enough to know that it is not a fit for my development model. I'm assuming that other people feel the same. My point is: Hunchentoot is and will stay being a HTTP server library and not include any "widget like" functionality that interoperates with a database, requires a certain development model, supplies or assumes a model for flow of control between server and all that. Hunchentoot does not even know about HTML, and rightfully so. -Hans
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
participants (4)
-
First name Last name -
Hans Hübner -
Phil Marneweck
-
Tomasz Lipski