<html><head><meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; line-break: after-white-space;" class=""><div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><p class="">I'd be interested in how this works for pages/components other
than your typical login screen? How do you modify session state in
order to navigate the calls/answers to download a static version
of a page in the middle of your app? The only Way I can think of
here is to have some mechanism to navigate the app to a certain
point (Parasol?, manually?) and then replicate your _s and _k to
your wget.</p></div></div></blockquote><div>You end up with static pages named with s= & k= so the links work. It’s not a nice / clean solution, but it’s a workable one.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><blockquote type="cite" cite="mid:7F27EE19-2862-4B1E-8E1C-5C2C3D2AFDF6@mail.com" class=""><div class=""><div class=""><div class=""><div class=""><span class="" style="caret-color: rgb(0, 0,
0); float: none; display: inline !important;">This is in
the context of CSS development. The front-end dev could
be testing minor changes 10 times a minute and if they
need to upload the CSS files to a FileLibrary each time
- a minutes work becomes an hour.</span></div>
</div>
</div>
</div>
</blockquote><p class="">Hmmm. It shouldn't be too hard to make some handler in a
Smalltalk image that accepts uploads and compiles to a
WAFileLibrary. Or you could just have a directory somewhere
accessible for uplads and a button in your image that loads and
recompiles all files from there. This import of Strings to
WAFileLibrary methods take about a blink of an eye rather than
(an) hour(s)…?<br class=""></p></div></div></blockquote><div>You can, of course, do this. It comes down to what your css dev is comfortable with and how much time you have to spend with them. The dev’s I’ve worked with are comfortable using a SASS compiler and a grunt task that reloads the browser whenever they compile a new version. If you make them work with tools beyond that, it can mean a lot of hand holding and slower turnaround.</div><div><br class=""></div><blockquote type="cite" class=""><div class=""><div text="#000000" bgcolor="#FFFFFF" class=""><blockquote type="cite" cite="mid:7F27EE19-2862-4B1E-8E1C-5C2C3D2AFDF6@mail.com" class=""><div class=""><div class=""><div class=""><div class=""><span class="" style="caret-color: rgb(0, 0,
0); float: none; display: inline !important;">Obviously
the best solution is for the css dev to run a local web
server, and also a local Pharo/gemstone seaside server
(ie. a copy of the production setup.) This way they can
browse the working site to test their work. In this
case, their web server should be serving their css and
resources directly from </span><siteRoot>/files/< MyFileLibraryName>/
- exactly how it will be in production.</div>
</div>
</div>
</div>
</blockquote><p class="">I disagree, but would be interested in reasons for that. My
experience from real-world projects is limited here, so I would
like to learn from yours.<br class=""></p></div></div></blockquote><div>I’m inclined to agree with you considering the majority of css devs I’ve worked with. BUT, in the rare case you have someone who loves working with new tools, or someone who knows seaside well, then having a live site to play with will find potential problems quicker than working with a static version.</div><div><br class=""></div><div>It also means they can (if they know how) change the page structure if they need to - sometimes you need an additional tag or class to support the limitations of CSS that isn’t really required in strict XML/HTML. When that happens, it’s quicker if they can make the change rather than let you know what they need, you make the change in seaside, then provide them with a new static HTML doc.</div><div><br class=""></div><div>The whole idea of providing them with a mini static site, is to limit their exposure to anything out of their skill set - with the staggeringly narrow scope of so many development jobs, you have a much better chance of finding someone who is awesome at CSS design, but has no idea about seaside, smalltalk, or really any server technologies.</div><blockquote type="cite" class=""><div text="#000000" bgcolor="#FFFFFF" class=""><p class="">
</p><blockquote type="cite" cite="mid:7F27EE19-2862-4B1E-8E1C-5C2C3D2AFDF6@mail.com" class=""><div class=""><div class=""><div class=""><div class="">Once the css dev delivers you a finished
version of the files, upload them to
your WAFileMetadataLibrary for distribution and testing.
Once it moves into production, publish the FileLibrary to
disk and serve them via the HTTP server.</div>
</div>
</div>
</div>
</blockquote><p class="">You can, of course, skip the File Library Stuff completely if you
wish, either for all stages of your projects or only some. Web
Servers liek nginx and Apache offer a rich set of options for such
setups.<br class="">
</p></div></blockquote></div><div>Absolutely. I just love the convenience of being able to load up from Metacello into GemStone and have everything (javascript / images / css / fonts) all working right away. Can’t beat it for development. :) Pushing it to disk in production is simply to keep access to the image limited to requests that really need it.</div><div><br class=""></div><div>The styling / front-end development with seaside has always been the trickiest part of development for me. I’d love any advice others have on how they work with external designers. There is undoubtedly a better way I haven’t thought of.</div><div><br class=""></div><div>Cheers,</div><div><br class=""></div><div>J</div></body></html>