Client Framework - components widgets etc

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Client Framework - components widgets etc

keith1y
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
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Client Framework - components widgets etc

cedreek
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 <[hidden email]>:

> 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
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>


--
Cédrick

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
Reply | Threaded
Open this post in threaded view
|

Re: Client Framework - components widgets etc

keith1y
Cédrick Béler wrote:
> 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
>  
With the ability to use mock's in the back end as standard tutorials and
tests are going to be plausible.
> 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 ;)
>  
I am not ready to target 2.9 I havent even had time to take the wrapper off.

As long as WASession has a properties dictionary it would work ok.
> 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.
>  
Great.

Keith
> BTW, have all a good time for your holidays ;-)
>
>
> Cédrick
>  

_______________________________________________
seaside mailing list
[hidden email]
http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside