[Seaside] is this workflow incorrect?

[Joachim Tuchel]

Sergio,

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.


hth

Joachim




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
>     files.
> 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
> incorrectly.
>
> 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
D-71640 Ludwigsburg
Telefon: +49 7141 56 10 86 0         Fax: +49 7141 56 10 86 1