integrations of preprocessors and new folder structure

[jonrandahl]

Hey Marcin,

just adding a new folder structure to allow for themes to be developed individually while maintaining the applicable hierarchy.

Also, while I'm using sass as a preprocessor, I'm working towards a vanilla css stylesheet to be applied.

As always, open to suggestions!

Super tak!

[mzajkowski]

Hi @jonrandahl!

Thanks for your changes - I really like the idea of including preprocessors as soon as it's possible TBH.

But first.. check #6 where @leekelleher added an interesting approach to retrieve themes by stylesheets names + some "meta" comments inside. Would be great to turn it into a wider discussion, as keeping themes in separated directories might have also it's benefits.

You've mentioned that it may help you in terms of development process in separation with other files. Can you describe more about this approach?

I may think too many steps ahead, but maybe thinking about "installation" of a theme for backoffice it would be also good to have this separation. But.. if we will be able to install directory, the same way we can proceed with single file too.

Just gather some more ideas as probably this change will require some polishing after merging the mentioned PR number 6.

Looking forward for more input from you both.

Cheers!

[leekelleher]

re: theme folders - I like this idea. It keeps the theme's assets (CSS and screenshot) together, rather than in separate /css and /img folders. 👍

---

re: preprocessors - I have little knowledge around them, so don't have much input at the moment. My only concern is how to build & test them? I guess that's when we get into a world of gulp/grunt/webpack, right?

[jonrandahl]

Okay, point by point below! :-D

Re: theme folders - With a separate folder structure, while it lends itself to better organisation and flow, it also leads to being able to create themes as packages which will allow for future theme development as all the infrastructure will be in place. Think of the "App_Themes" folder, but for the back office, maybe we could adopt this structured approach and integrate it in with @leekelleher's dashboard thereby bridging the gap between file structure and meta info?

Re: preprocessors - I know the HQ is using LESS for the current styles, and it might be better to stick with this direction if we're going to go for the idea of the processing to happen on the server; however, I use SASS to develop my stylesheets locally and then pass them up as "vanilla" css - while progressively developing using the latest features we have supported, like variables, mixins, etc. If you're not sure what you can do these days, I would highly suggest having a poke around google to see what you can find, but I'd be happy to show you some of the things I've been doing. Also, @leekelleher is right as we would probably need to develop a "build script" utilising webpack/gulp/grunt that would highlight the "best practices" and is included in the distributed repo.

Finally, as for theme installation, it should only ever be the raw files required for the theme - vanilla css alongside any specific images that are overriding the ones already in the back office. Otherwise, it can become too convoluted a process and thereby bog down things rather than keeping things DRY. Also, I'm not sure if we would need to ship any scripting alongside these - this would be better left to individual back office packages themselves however we could offer guidance by illustrating the way to do styling for packages?

J

[jonrandahl]

Not implemented so closing