Hi all,
I am quite new to Squeak and Seaside development, but I am truly fascinated about the whole framework and the great work by Lucas. After 10 years Java development this is really mind-augmentating ;)
I want to use Seaside and Pier in Production and I wonder how the "normal" development/deployment cycle is. Currently, I am doing only changes locally and copy the whole image onto the server while keeping WACom running. The disadvantage is, that I have to change some settings after redeploying the image onto the server. Additionally, it would be easier to just export the settings and content from seaside and pier. Is there a way to do this?
Cheers, Michael
P.S.: I couldn't find out how to change the default password of pier - any hints?
One possible solution is to have different images for development and porduction use. For production I use the seaside-mini image and for development the squeak-dev image with web support. You can then develop your application, export it using Monticello and merge the changes into the production image. To transfer data, ReferenceStream may be employed as an example. (Or you use a DB backend, what makes copying the data easy as well) Have a look at the ReferenceStream class comment..
This approach has another advantage, my first real application uses lots of configuration, you'd always have to recreate all the config settings if you used a new image everytime. This is how I do it, maybe (probably) there are other better ways, I'm interested to hear how others are doing it, especially to see any flaws in my way, as I am quite new to the seaside world..
Greets, Malte Zacharias
Seaside has configurations that can be used to change application settings quickly.
http://www.shaffer-consulting.com/david/Seaside/Configurations/index.html
A question to Seaside Configuration users: Would it make sense to make configurations more powerful, so that they can be defined in dispatchers to affect multiple applications (in other words so that they are inherited along the dispatcher tree)?
Lukas
Hi,
I think so. For example, if I'm not mistaken, R2RSS implemented RSS as a new component without ties to the applications in which it may be inserted. It would be interesting to share configurations in this case.
Ronaldo
On Mon, Feb 25, 2008 at 10:58 AM, Lukas Renggli renggli@gmail.com wrote:
Seaside has configurations that can be used to change application settings quickly.
http://www.shaffer-consulting.com/david/Seaside/Configurations/index.html
A question to Seaside Configuration users: Would it make sense to make configurations more powerful, so that they can be defined in dispatchers to affect multiple applications (in other words so that they are inherited along the dispatcher tree)?
Lukas
-- Lukas Renggli http://www.lukas-renggli.ch
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
On Feb 25, 2008, at 6:58 AM, Lukas Renggli wrote:
A question to Seaside Configuration users: Would it make sense to
make
configurations more powerful, so that they can be defined in dispatchers to affect multiple applications (in other words so that they are inherited along the dispatcher tree)?
Yes, I think that would be very useful.
A question to Seaside Configuration users: Would it make sense to make configurations more powerful, so that they can be defined in dispatchers to affect multiple applications (in other words so that they are inherited along the dispatcher tree)?
Lukas
I'm not convinced. It'll complicate things unecessarily. Pragmatism: in which case we will have real applications using more than one seaside application per image? Then which *real* problems will be solving that feature for us?
cheers,
Sebastian Sastre
Additionally, it would be easier to just export the settings and content from seaside and pier. Is there a way to do this?
Cheers, Michael
I've made squeak to read a simple text file in the image path with some configs. Is just reading text that when compiled instantiates a dictionary with the (basic) values I configure from there. So I just clone the image and start it there with it's own values.
Cheers,
Sebastian PD: Welcome to the seaside. Refresh your mind !
I've made squeak to read a simple text file in the image path with some configs. Is just reading text that when compiled instantiates a dictionary with the (basic) values I configure from there. So I just clone the image and start it there with it's own values.
Cheers,
Sebastian PD: Welcome to the seaside. Refresh your mind !
I kind of do the same thing, I keep all my config data on the file system in text files and use my own config system rather than Seaside's. I don't like keeping config info in the image, it's too much of a hassle. I keep three profiles, dev, prod, test, with a file in the root that determines which profile is used (easily toggled). Inside the directory for a profile, each setting is stored in a separate file where the filename is the setting name and the file contents are the value.
Ramon Leon http://onsmalltalk.com
On Feb 25, 2008, at 11:19 AM, Ramon Leon wrote:
I kind of do the same thing, I keep all my config data on the file system in text files and use my own config system rather than Seaside's. I don't like keeping config info in the image, it's too much of a hassle. I keep three profiles, dev, prod, test, with a file in the root that determines which profile is used (easily toggled). Inside the directory for a profile, each setting is stored in a separate file where the filename is the setting name and the file contents are the value.
... And I'm just the other way ;-)
I create configuration classes and then I zip up the folder with the images and send them to my designers... they know how to use the web interface to make changes that are needed for db access or resource pathing, and don't have to look for files.
- Brian
I kind of do the same thing, I keep all my config data on the file system in text files and use my own config system rather than Seaside's. I don't like keeping config info in the image, it's too much of a hassle. I keep three profiles, dev, prod, test,
with a file
in the root that determines which profile is used (easily
toggled).
Inside the directory for a profile, each setting is stored in a separate file where the filename is the setting name and the file contents are the value.
... And I'm just the other way ;-)
I create configuration classes and then I zip up the folder with the images and send them to my designers... they know how to use the web interface to make changes that are needed for db access or resource pathing, and don't have to look for files.
- Brian
OK, but how do you easily move configs between images? What's nice about files of course is it makes it much easier to share configs between images and/or edit config from a shell, which matters to me since I manage my production servers via ssh. I think Unix/Linux proved long ago that plain text configuration files worked better than custom binary formats (like Windows) and since switching to Linux, I've come to appreciate that approach much much more.
Ramon Leon http://onsmalltalk.com
Same scenario here so +1,
cheers,
Sebastian Sastre
-----Mensaje original----- De: seaside-bounces@lists.squeakfoundation.org [mailto:seaside-bounces@lists.squeakfoundation.org] En nombre de Ramon Leon Enviado el: Viernes, 29 de Febrero de 2008 11:14 Para: 'Seaside - general discussion' Asunto: RE: [Seaside] Different Profiles for development and production
I kind of do the same thing, I keep all my config data on
the file
system in text files and use my own config system rather than Seaside's. I don't like keeping config info in the
image, it's too
much of a hassle. I keep three profiles, dev, prod, test,
with a file
in the root that determines which profile is used (easily
toggled).
Inside the directory for a profile, each setting is stored in a separate file where the filename is the setting name and the file contents are the value.
... And I'm just the other way ;-)
I create configuration classes and then I zip up the folder with the images and send them to my designers... they know how to use the web interface to make changes that are needed for db access or resource pathing, and don't have to look for files.
- Brian
OK, but how do you easily move configs between images? What's nice about files of course is it makes it much easier to share configs between images and/or edit config from a shell, which matters to me since I manage my production servers via ssh. I think Unix/Linux proved long ago that plain text configuration files worked better than custom binary formats (like Windows) and since switching to Linux, I've come to appreciate that approach much much more.
Ramon Leon http://onsmalltalk.com
seaside mailing list seaside@lists.squeakfoundation.org http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
seaside@lists.squeakfoundation.org
-
Brian Brown -
cdrick -
Lukas Renggli -
Malte Zacharias -
Michael Markowski -
Ramon Leon -
Ronaldo Ferraz -
Sebastian Sastre