[Seaside] Client Framework - components widgets etc

Cédrick Béler cdrick65 at gmail.com
Sat Dec 20 13:31:26 UTC 2008


I don't know if this example make sense but I really think we should
organize to make layers around seaside core.
-User management + login is certainly one direction...
-General widgets too, especially cool data grid...
...
-and also, small tutorials... on all entry points...  pattern and
anti-patterns...
...

I think 2.9 is the target...  Do someone has news about the book ? I'm
really looking forward to it...  I could be a beta reader ;)

We don't need to have the expertise of the core developper, but we
need to do it well and clean. Can we organize ? I'll have some spare
time in 2009 so I'll be happy to join.

BTW, have all a good time for your holidays ;-)


Cédrick

2008/12/20 Keith Hodges <keith_hodges at yahoo.co.uk>:
> I hear the call for widgets, and I wish there were more bits I could
> just use "out of the box", but in the current situation (2.8) it is
> really difficult to make "components" given that seaside only serves the
> web application side of things. The model, and back end persistence is
> up to you, so I cant write, or find a login widget that is generic enough.
>
> Enter - the "Client Framework"
>
> Requirements:
>
> 1) I am developing web applications for several clients, and it is
> likely that each will have different database requirements, and I would
> prefer to use magma myself.
>
> 2) I want one class to have all the configuration that my client asks
> for. If the client says "change that error message", I dont want to have
> to go hunting around in the component code, especially since the other
> clients are happy the way it is. I cant put every little thing in the
> seaside/config app, and I want everything under scm.
>
> 3) I want to be able to configure/switch my app to run with
>
> 1 - In-memory mock database - for testing the UI
> 2 - Mini test database - for testing the backend
> 3 - Backup database - for debugging in a non-live real environment
> 4 - Live database
>
> So this is the basic architecture:
>
> WASession-#client <---> WAClient(mode is one of #live #backup #test
> #mock) ---> WADataInterface
>
> To use it, I subclass WAClient with MyShop
>
> MyShop-#dbClass ^MyShopDataMySql
> MyShop-#dbClassMock ^MyShopDataMock
>
> where WADataShopMySql, and WADataShopMock are subclasses of WADataInterface.
>
> With this basic architecture in place we can publish some UI components,
> adding the api to WAClient. Subscribers fill in their own Client
> subclasses to configure the components, and to connect to their real data.
>
> ================================
> Example usage: A Seaside Login Component
> ================================
> (published as Client-Login)
>
> WALoginComponent-#doLogin
>
>    "ask the client framework to log us in, any errors are raised as
> WALoginFailedNotification,
>      the user record is available for this session at self client
> userAccountRecord"
>
>    ^ self client loginUser: self username password: self password
>
> ---
> since WAClient-#loginUser: name password: secret
>
> ^ self db loginUser: name password: secret
>
> I need to implement back-end methods for the following, and we are done.
>
> WADataShopMySql-#loginUser: name password: secret
> WADataShopMock-#loginUser: name password: secret
>
> am I making sense?
>
> Keith
>
>
>
>
>
>
>
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>



-- 
Cédrick


More information about the seaside mailing list