[Seaside] workflow for development..
peter.osburg at gmail.com
Tue Feb 23 06:24:40 UTC 2010
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
> 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
> 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.
> photographer, journalist, visionary
> seaside mailing list
> seaside at lists.squeakfoundation.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the seaside