[Seaside] is this workflow incorrect?
jtuchel at objektfabrik.de
Thu Sep 27 18:51:44 UTC 2012
I guess I'd try and start development right in Gemstone and only use
Pharo for experiments with Seaside and stuff. There are quite a few
nifty differences between the two, and you should try to get a feel for
the transaction behavour of Gemstone in ordr to not make really stupid
mistakes. In addition, think about test data. How would you transport a
set of test data between GemStone and some Pharo image? Not that there
are no solutiuons for this, but they eat up your time and energy,
however clever they sound.
So my advice would be to install a development GemStone and a test
GemStone in your development environment. Pharo is great, don't get me
wrong. But if you want to deploy on GemStone, use GemStone as early as
possible. If portability is a concern (you don't say so, however), you
can use Pharo, of course.
Metacello, Monticello, git. I think Dale's work with FileTree is a thing
that we should absolutely keep an eye on. I like the idea of storing
Smalltalk code in git, be it as a primary repository or some backup or
place to exchenge code with others. It would be so cool if we finally
had a format and technology which all Smalltalks can access and use,
even if portability is a separate issue. Today, just loading/importing
code can be hard, so this is a first step.
I'd like to be very clear about File Libraries and files in the image.
You really shouldn't bother. It's extremely easy to export the files to
a file system when it comes to deployment, and you'll have to work with
RewriteRules and stuff for your deployment environment anyways when your
app is ready.
The problems you'll face with things you don't even imagine they exist
today will make this problem area look like a sunday afternoon walk on
the beach. For development, having all and everything in your image is
extremely handy, and a simple rewrite rule in your web server will make
it easy to redirect all requests for files to the file system with zero
changes to your Smalltalk code. The file library can still be in your
image and will never have to serve anything. Gi with file libraries and
worry about this later. Just my 2 cents on this one.
Am 27.09.12 14:44, schrieb sergio_101:
> i am trying to wrap my head around the development workflow, and i
> want to make sure i am doing this as efficiently as possible.
> can someone comment on this?
> 1. develop away in my local image. this includes all classes,
> components, and tests. this does not include editing static files.
> 2. my static files are served up by a local running version of apache,
> and my resource base is set to point there. at this point, the only
> way i can think of keeping these files wrapped up in the project is
> by using a file based system (git) to version and deploy static
> 3. pull my project into a local gemstone to make sure there are no
> problems. i am thinking that a more robust test bed would probably
> be good enough here. if my tests all pass in gemstone, i should be
> good to go.
> 4. pull project into deployed gemstone, run tests, and let it rip.
> there are only few things i don't like about this. i am not sure i
> like the idea of having to run a local gemstone and test the app in
> two places (gemstone and pharo). since i am new to this, i would
> imagine i can drop this step at some point.
> i don't like (at all) the idea of running monticello for my seaside
> project, and git for my static files. i am thinking i am doing this
> in a perfect world, i would have monticello somehow (without using
> file libraries) keep track of my css, image, and js files without having to
> run two versioning systems.
> i absolutely don't want to serve up static files through seaside, so i
> am not sure how to rectify all this.
> how are you guys handling these issues?
Objektfabrik Joachim Tuchel mailto:jtuchel at objektfabrik.de
Fliederweg 1 http://www.objektfabrik.de
Telefon: +49 7141 56 10 86 0 Fax: +49 7141 56 10 86 1
More information about the seaside