[Seaside] workflow for development..

[Peter Osburg]

Hi Sergio,

you might want to have a look at this:
http://www.experiencedwebprogramming.com/2008/11/11/monticello-update-within-a-live-environment/

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
>

Hth,
Peter

-- 
www.peter-osburg.de
www.experiencedwebprogramming.com
www.mix-rss.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside/attachments/20100223/2b61ee9c/attachment.htm