[Seaside] workflow for development..

Peter Osburg peter.osburg at gmail.com
Tue Feb 23 06:24:40 UTC 2010

Hi Sergio,

you might want to have a look at this:

It describes how to update your code from within your webapp. So it won't be
necessary to have visual access to your image.

Maybe it helps a bit.
The post is not based on the newest application build by Lukas called
Gopher. Using Gopher would let the code look a little more easy. But I guess
you can get the point.

See comments further below.

2010/2/23 sergio_101 <sergiolist at village-buzz.com>

> currently, my workflow for a project in development goes something like
> this..
> developers work on the app / design in their editors on development
> versions of the app.. running on their machines..
> as changes are made, they commit their changes to the repository..
> they then deploy them via capistrano to the live server..
> the server restarts with the new changes..
> this continues until the project is deployed for real..
> once this happens.. work is pretty much the same, with each person
> running a database of their own for testing and the production
> database doing its thing..
> my question is.. will we be working the same way with seaside?
> when you make changes and upload everything via monticello, can you
> just attach to your production image and have it pull all new changes?
> how are conflicts settled?
> is the live data subject to any weirdness?

When there is any conflict you have to make sure to solve it before you
update your live/production/whatever image. But remember you have two
options of updating your code: On the one hand you can do a simple "update"
simply speaking: it adds the new code to the exisiting one. Or you load the
latest Monticello-File which updates the whole code and no conflicts should
happen then.

> ie.. if we have a 'person' class, and we add 'address2' to the person
> class.. are the previous 'person'-s still okay?

Thing is: You should handle the the situation when the value of address2 is
not set at older Persons. But if it is only about changing the attributes I
don't see any problem at all. Happens to me all the time :)
In those cases I prefer working with late bindings e.g. When you take a look
at the accessor of "address2" you could do something like

^address ifNil: [address2 := 'Default address']
That ensures that every created object of Person can access and work with
the new attribute regardless if it was nil or not.

> thanks!
> --
> ----
> peace,
> sergio
> photographer, journalist, visionary
> http://www.coffee-black.com
> http://www.painlessfrugality.com
> http://www.twitter.com/sergio_101
> http://www.facebook.com/sergio101
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20100223/2b61ee9c/attachment.htm

More information about the seaside mailing list