[Seaside] Front-End developer coordination

[Jupiter Jones]

> 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.
> 
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.

>> 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.
> 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)…?
> 
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.

>> 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 <siteRoot>/files/< MyFileLibraryName>/ - exactly how it will be in production.
> 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.
> 
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.

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.

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.
>> 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.
> 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.

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.

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.

Cheers,

J
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20190528/1de03691/attachment.html>