Front-End developer coordination
Locked
 
|
Hi,
We are doing a project with Seaside and there is a Front-end developer mostly for CSS creation. How do you approach this problem (coordination between Seaside developer and frontend developer) ? I mean in Seaside the HTML code is generated but it has to do some references to the CSS created by the frontend developer. One approach can be: 1) Add css class names (the css does no exist yet) in Seaside code (html div class: 'to-be-developed-by-frontend-dev'). 2) The frontend create the CSS file for classes in 1). Very simple but i wonder how do you solved this problem ? regards, bruno -- Sent from: http://forum.world.st/Seaside-General-f86180.html _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Front-End developer coordination
|
|
Isn’t that the whole point of Seaside and the way it creates well marked html with the ability to consistently put Id’s and structure in everything? It should be a dream for a CSS front end dev?
Even more - teach them a bit of Smalltalk and they can create all the hooks they need for pure css? Tim Sent from my iPhone > On 24 May 2019, at 20:09, BrunoBB <[hidden email]> wrote: > > Hi, > > We are doing a project with Seaside and there is a Front-end developer > mostly for CSS creation. > > How do you approach this problem (coordination between Seaside developer and > frontend developer) ? > > I mean in Seaside the HTML code is generated but it has to do some > references to the CSS created by the frontend developer. > > One approach can be: > 1) Add css class names (the css does no exist yet) in Seaside code (html div > class: 'to-be-developed-by-frontend-dev'). > 2) The frontend create the CSS file for classes in 1). > > Very simple but i wonder how do you solved this problem ? > > regards, > bruno > > > > > > -- > Sent from: http://forum.world.st/Seaside-General-f86180.html > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Front-End developer coordination
|
|
In reply to this post by BrunoBB
Hi Bruno,
Like Tim said it “should” be a dream, but in my experience it more often is not :) Since most dev roles have become sooooo specific, it’s hard to find a CSS developer with an interest in learning another programming language that they can’t perceive as a benefit their career as a “front-end” developer. In the end I found that creating a static versions of all my main components to hand over to the “front-end” developer got results the fastest. It allowed them to understand the page structure, as well as the “file” structure without lots of hand-holding. To keep it maintainable I created a small “dummy” site that exposed a version of each component and then created the static site with wget. The developer could then use their chosen SASS tools to create CSS that I could load directly into the WAFileMetadataLibrary and it all worked as expected. Still, there nothing better than a front end developer who wants to learn RenoitSt and improve their whole-life-experience :) Cheers, J > On 25 May 2019, at 5:09 am, BrunoBB <[hidden email]> wrote: > > Hi, > > We are doing a project with Seaside and there is a Front-end developer > mostly for CSS creation. > > How do you approach this problem (coordination between Seaside developer and > frontend developer) ? > > I mean in Seaside the HTML code is generated but it has to do some > references to the CSS created by the frontend developer. > > One approach can be: > 1) Add css class names (the css does no exist yet) in Seaside code (html div > class: 'to-be-developed-by-frontend-dev'). > 2) The frontend create the CSS file for classes in 1). > > Very simple but i wonder how do you solved this problem ? > > regards, > bruno > > > > > > -- > Sent from: http://forum.world.st/Seaside-General-f86180.html > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Front-End developer coordination
|
|
In reply to this post by BrunoBB
A UX designer/developer (because 'front-end’ is broader) should be able to give you both html and css structure for your pages and components.
If you already have pages and components, he/she should be able to give you the necessary changes in both html and css. They can just use the app’s html from the browser and start from there. You can then apply the necessary changes they design to the Seaside code that produces the html. I recommend creating Seaside brushes for recurring patterns of html+css or for small components that have no associated state. With Seaside components and, especially the ability to do subclassing, you can have a very flexible implementation of the UX designer’s work in your Seaside code. The most difficult problem is the common understanding of what are ‘components’ in the app, such that the UX designer knows what you can have reusable and what he/she should handle as a ‘component’ in the pages. The best thing to do for that is to develop a component library (exactly like what you can already find in Bootstrap or Material Design) and have that as the common ground between UX design/developer and the Seaside developers. Of course, I cannot know what kind of assignment or structure your project has, but in my experience, you _will_ need to change the html structure when a designer goes to work with it. A UX designer can not just create css classes for your existing html structure unless you want to end up with an unmaintainable mess of css definitions. Mind that this ‘issue’ is not specific to Seaside. The same issue arises if the UX designer/developer is not a fluent Javascript engineer to work with ReactJs. Sure, there are front-ends that can do all that but it’s more often not the case. Also: do not put those css files in a WAFileLibrary. Put them in plain text files and have them served by a frontend web server (or Zinc in Pharo). A good UX developer will use SaSS (or something similar) and generate the css files every time. You do not want to mess with WAFileLibrary in that development workflow... Cheers Johan > On 24 May 2019, at 21:09, BrunoBB <[hidden email]> wrote: > > Hi, > > We are doing a project with Seaside and there is a Front-end developer > mostly for CSS creation. > > How do you approach this problem (coordination between Seaside developer and > frontend developer) ? > > I mean in Seaside the HTML code is generated but it has to do some > references to the CSS created by the frontend developer. > > One approach can be: > 1) Add css class names (the css does no exist yet) in Seaside code (html div > class: 'to-be-developed-by-frontend-dev'). > 2) The frontend create the CSS file for classes in 1). > > Very simple but i wonder how do you solved this problem ? > > regards, > bruno > > > > > > -- > Sent from: http://forum.world.st/Seaside-General-f86180.html > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Front-End developer coordination
|
|
In reply to this post by BrunoBB
> Am 24.05.2019 um 21:09 schrieb BrunoBB <[hidden email]>: > > Hi, > > We are doing a project with Seaside and there is a Front-end developer > mostly for CSS creation. > > How do you approach this problem (coordination between Seaside developer and > frontend developer) ? > > I mean in Seaside the HTML code is generated but it has to do some > references to the CSS created by the frontend developer. > > One approach can be: > 1) Add css class names (the css does no exist yet) in Seaside code (html div > class: 'to-be-developed-by-frontend-dev'). > 2) The frontend create the CSS file for classes in 1). > > Very simple but i wonder how do you solved this problem ? > Norbert > regards, > bruno > > > > > > -- > Sent from: http://forum.world.st/Seaside-General-f86180.html > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Front-End developer coordination
|
|
Hi Bruno,
It's an interesting question. What are the tools and workflow preferences of your front-end developer? Cheers Siemen Sent from my iPhone > On 25 May 2019, at 09.04, Norbert Hartl <[hidden email]> wrote: > > > >> Am 24.05.2019 um 21:09 schrieb BrunoBB <[hidden email]>: >> >> Hi, >> >> We are doing a project with Seaside and there is a Front-end developer >> mostly for CSS creation. >> >> How do you approach this problem (coordination between Seaside developer and >> frontend developer) ? >> >> I mean in Seaside the HTML code is generated but it has to do some >> references to the CSS created by the frontend developer. >> >> One approach can be: >> 1) Add css class names (the css does no exist yet) in Seaside code (html div >> class: 'to-be-developed-by-frontend-dev'). >> 2) The frontend create the CSS file for classes in 1). >> >> Very simple but i wonder how do you solved this problem ? >> > You are using component like things in the backend and frontend. In the normal case seaside component will render something like a div defining the space for this component. So give it a class attribute containing information about the component like navigationBar or orderForm. This can be used in CSS to style according to the backend component. See it as an interface. The backend defines functional name hierarchy that the frontend can take to implement a view on it. Nowadays I would have a look into W3C components to save you from trouble with relative CSS. W3C components build isolated views of components. > > Norbert >> regards, >> bruno >> >> >> >> >> >> -- >> Sent from: http://forum.world.st/Seaside-General-f86180.html >> _______________________________________________ >> seaside mailing list >> [hidden email] >> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Front-End developer coordination
|
|
In reply to this post by BrunoBB
Hi Bruno,
In my experience, the UI design in HTML/CSS comes first, and then you build your components and/or render different tags/brushes to fulfill the needs of the specification. I have purchased Bootstrap 3 templates, that in most cases come with some "components" that are just some html structure plus assigning the right class to some tags, and I had no issues in building the needed brushes or components to get the same output as in the "showcased" example. In my last project I built an app using the base Bootstrap 3 classes (using Torsten's Seaside-Bootstrap package), and later on I built a theme from the ground up (using LESS), this plus some specific classes for components that I needed to render differently got me very far in terms of flexibility. Of course this is an iterative process, but if the designer is "detached" from the programmers pipeline, then the only alternative I see to "stylize" existing HTML output rendered by Seaside, is: 1. [Developer] Render whatever you're rendering with Seaside 2. [Designer] Takes the HTML+CSS output of step #1 and works statically on it (or using browser's Devtools) 3. [Designer] Gives Developer how it should stylize something, using a static HTML page + CSS rules 4. [Developer] Takes the output of step 3 and adapts what it had in step #1 to get the same output. Rinse and repeat. :) Regards, Esteban A. Maringolo On Fri, May 24, 2019 at 4:09 PM BrunoBB <[hidden email]> wrote: > > Hi, > > We are doing a project with Seaside and there is a Front-end developer > mostly for CSS creation. > > How do you approach this problem (coordination between Seaside developer and > frontend developer) ? > > I mean in Seaside the HTML code is generated but it has to do some > references to the CSS created by the frontend developer. > > One approach can be: > 1) Add css class names (the css does no exist yet) in Seaside code (html div > class: 'to-be-developed-by-frontend-dev'). > 2) The frontend create the CSS file for classes in 1). > > Very simple but i wonder how do you solved this problem ? > > regards, > bruno > > > > > > -- > Sent from: http://forum.world.st/Seaside-General-f86180.html > _______________________________________________ > seaside mailing list > [hidden email] > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by BrunoBB
---- On Fri, 24 May 2019 15:09:00 -0400 BrunoBB <[hidden email]> wrote ----
Have the CSS team build look-and-feel then implement them in Seaside. The Zurb CLI tools are very close to a live coding environment for css guys and they can get the layouts perfect with them. Then, look at their work, identify the components and build them so that they match the look. hth. _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Johan Brichau-2
Hi,
First of all thanks for your responses are very helpful ! /* /You do not want to mess with WAFileLibrary in that development workflow.../ */ Why this practice is bad ? You can update css file using Seaside Config component to uploads files. I do not see why this is a bad thing. Our project has a few Seaside components so is entirely possible to start from scratch again. Ask the designer for HTML + Style and render that as Seaside components. We are slowly exploring the possible options. At this early point i do not know yet if the designer it would be an UX designer. The frontend developer is going to be defined soon. /* /Of course, I cannot know what kind of assignment or structure your project has, but in my experience, you _will_ need to change the html structure when a designer goes to work with it. A UX designer can not just create css classes for your existing html structure unless you want to end up with an unmaintainable mess of css definitions./ */ Yes, got it ! regards, bruno -- Sent from: http://forum.world.st/Seaside-General-f86180.html _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by JupiterJones
Jupiter,
I never did what you mention but it seems a lot of work. It seems to me a more affordable approach to replicate in Seaside what the designer creates. But again is just a sensation it should be tested in practice and see the results. To create the static site with wget do you have an automatic way to do this ? Or is done manually ? regards, bruno -- Sent from: http://forum.world.st/Seaside-General-f86180.html _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
In reply to this post by Esteban A. Maringolo
Esteban,
It seems a very practical approach we will study this possibility. I think we should start from scratch and get the designer work first and the replicate that in some way with Seaside. In this case is possible because there are only few Seaside components created. regards, bruno -- Sent from: http://forum.world.st/Seaside-General-f86180.html _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Front-End developer coordination
|
|
In reply to this post by BrunoBB
Hi Bruno,
It’s not trivial, but with a little planning I found this worked well for larger sites. For sites with fewer pages I found it easier to use the browser to navigate to the page I wanted the CSS dev to work on, then used the “Save As…” menu to save the page as a Web Archive. This essentially does the same things as wget for a single page. Either way, load up the system with minimal example data. It’s best to use data “extremes” ie. if it’s a string title or label, add a short one, a typical length one, and a really long one. This way the CSS developer can take them all into account at once. Then browse to the page and save as web archive, or open a terminal and use wget: wget -r -l1 http://localhost:8080/MySeasideSite …and you’ll get a local static version of the site for the CSS developer to work with. Note: there are many wget options that can help depending on how your site is configured so it’s definitely worth finding one that works for you. All WAFileLibrary files will be in their appropriate relative locations (ie. ./files/SomeWAFileLibrary/<libraryRelativePathAndFileName>) so the front-end dev can correctly refer to them if required. I get the css dev to create all their files in the location: <siteRoot>/files/< MyFileLibraryName>/ That way, the css dev can use whatever directory structure they are comfortable with and we can upload them to a WAFileMetadataLibrary using: MyFileLibraryName recursivelyAddAllFilesIn: ‘<pathToSiteRoot>/files/MyFileLibraryName’ …and it should be ready to go. /* 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. 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. 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. Cheers, J _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
|
|
Am 27.05.19 um 23:10 schrieb Jupiter
Jones:
Hi Bruno, 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.
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)...?
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.
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.
Joachim _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
Re: Front-End developer coordination
|
|
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.
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.
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.
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 _______________________________________________ seaside mailing list [hidden email] http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside |
«
Return to Seaside General
|
1 view|%1 views
| Free forum by Nabble | Edit this page |