This will be fun. There is no one with your experience using M+S, and I'll be glad to learn more about Seaside, thanks!
I do hope the demo may afford the use of a MagmaCollectionReader somewhere in the inventory model; a great opportunity to demonstrate how they are used.
Need some way to deliver a nice sampling of SushiProducts; hardcoded or require user to enter?
I will brush up on Seaside.
- Chris
--- Brent Pinkney brent.pinkney@aircom.co.za wrote:
Hi Chris,
In reply to your mail regarding a demonstration of Magma + Seaside, I would advise just installing Seaside and going through the sample applications - they install out the box.
The most complex example is an online sushi shop.
Seaside allows for customisation of its session class to allow the Seaside session to open a database connection. It is this functionality I would like to demonstrate.
Seaside's BIG IDEA is to use continuation to manage state between http requests. A very nice use of this is to page though a collection of objects.
Finally I would like to demonstrate the ability to modify the sushi bar's inventory when a purchase is made.
I suggest we make a monticello which modifies the Seaside demo accordingly. ..
On 10/27/05, Chris Muller chris@funkyobjects.org wrote:
This will be fun. There is no one with your experience using M+S, and I'll be glad to learn more about Seaside, thanks!
Why do I always need to walk along the bleeding edge?
Anyway, I've been busy yesterday night moving some code from VisualWorks to Squeak, so I only had a short while to look at M+S.
The only/biggest issue is probably session handling. OmniBase allows multiple parallel transactions on a single database connection, so in every Seaside request handler, you simple grab the application-global connection, create a new transaction, and commit it at the end of the request handler (unless there's an error, then it does a rollback - of course, one could do it just as easily the other way: abort by default and commit on a special notification. The idea is that the request handling code is wrapped in a transaction).
With Magma, it looks like the best approach is to use a connection pool of Magma sessions. I have a simple, but servicable generic connection pool class (one of the things I moved over from TIO), and that's probably going to be my first attempt.
The idea is to include Mewa as well in the experiment, as well as the Timetravel code I ported over yesterday (see SqueakPeople). The end result should be a simple environment where you can immediately start writing a domain model and seaside compoments without having to worry about persistence - I want to rid myself of having to be concerned about that level, doing demos based on image persistence, etcetera, for once and for all :)
Why do I always need to walk along the bleeding edge?
The edge of the cliff is the only place you can see the view :)
The only/biggest issue is probably session handling.
Ok. We have a fair amount of experience here. The STTCPW is to have the Magma server in the same image as Seaside. The alternative is to have a separate Magma server image and connect from the Seaside image over TCP.
Assuming you take the 'in-image-server' advise then a subclass of WASession can quickly allocate new MagmaSession which can be closed in #expire.
Of course one can also have a single MagmaSession shared by all Seaside session and protected with a semaphore.
With Magma, it looks like the best approach is to use a connection pool of Magma sessions.
We have not found this to be necessary.
The end result should be a simple environment where you can immediately start writing a domain model and seaside compoments without having to worry about persistence - I want to rid myself of having to be concerned about that level, doing demos based on image persistence, etcetera, for once and for all :)
We are living in that future today.
It is our intention to enhance Seaside's Sushi shop demo to use Magma. Until then feel free to ask this list for tips and tricks - I monitor it.
On 10/27/05, Brent Pinkney brent.pinkney@aircom.co.za wrote:
Why do I always need to walk along the bleeding edge?
The edge of the cliff is the only place you can see the view :)
Yeah, but they never build a railing...
The only/biggest issue is probably session handling.
Assuming you take the 'in-image-server' advise then a subclass of WASession can quickly allocate new MagmaSession which can be closed in #expire.
Is that fast enough? That's my only concern...
We have not found this to be necessary.
Maybe not, but as it is almost for free because I've got the code lying around... ;)
We are living in that future today.
I'll be there tonight, probably.
Ok, a first version of Nags (which is Not A Groupware System) is on
MCHttpRepository location: 'http://kilana.unibe.ch:8888/SqueakPeople' user: '' password: ''
as NAGS-CdG.1 (or .2, or... I'm still working at it). It still needs to be checked, probably you want to wait a bit until version 2 or 3 arrives :)
It uses Magma, Seaside and Mewa to manage a simple todo list.
In the meantime, I added a package (prereq of NAGS) called Tric-SMAM Scaffolding (Seaside, Mewa and Magma. Sorry...) which is probably going to be the focus of the project - it will hold anything that I can push out of the Nags package as generic code...
On 10/27/05, Cees De Groot cdegroot@gmail.com wrote:
Ok, a first version of Nags (which is Not A Groupware System) is on
MCHttpRepository location: 'http://kilana.unibe.ch:8888/SqueakPeople' user: '' password: ''
And to finish the evening, v1.0 of the, err, product can be admired on http://de-1.tric.nl/seaside/sqp/nags
Login with your SqueakPeople username and password.
magma@lists.squeakfoundation.org
-
Brent Pinkney -
Cees De Groot -
Chris Muller