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 |
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 |
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 |
Free forum by Nabble | Edit this page |