Improve description of process to create JS/CSS for frontend (and data import)

[deeplook]

I succeeded in getting a kind-of working local version of this software on Debian 7.3 only after quite some help from Markus. This was mostly due to an incomplete description of the installation process in the Readme (section Style Integration). It would be nice to have that explained in a canonical way, so others can more easily install it and start contributing.

Alternatively, it would be also nice to put finished JS/CSS code into this repository, created once a day, maybe, automatically.

Also, some section on getting data into a running site would be nice, either minimal data, but ideally more than that, say at least the public stuff inside the CMS.

[veit]

Hello @deeplook, there is no one who can better update the documenttion than you ;-)

[deeplook]

@veit, maybe yes, there is someone else, because I'm not a node.js/ruby/compass/bower/grunt/honcho expert... ;-)

[DasIch]

I think we could solve the problem more easily by simply providing a script in some form that installs everything as far as that can be done without interacting with apt-get, homebrew etc.

In that case the documentation would turn into:

1. Install packages x, y, z using apt-get/homebrew
2. Run make install

Additionally a method of running migrations, updating/installing dependencies after pulling from the repository would definitely improve the development experience.

[zerok]

@DasIch You mean like the Vagrantfile that I provided a couple of days ago which provides a fully functional environment on Ubuntu 12.04? ;-)

[DasIch]

I think the Vagrantfile solution is slightly overkill for this problem and it introduces the overhead of having to run vagrant.

[zerok]

Compared to installing Python, NodeJS, Ruby, PostgreSQL, Compass, Sass manually... Don't get me wrong: I'm all for improving the setup documentation, but I don't consider Vagrant to be overkill here ;-)

[zerok]

@deeplook What exactly was missing in the documentation there?

[deeplook]

@zerok, I use Vagrant myself for other projects. I just looked into your Vagrantfile. Humbo-jumbo cool, but the point for me is: I don't really want to install a whole VM for every Website only for making more or less small contributions. I just don't have the space on my machine "to-go". And I'm not sure you can expect this from everybody who wants to make contributions, sometimes. That's different of course if one works all the time on a specific website. For me an DJEP this is just not the case.

So, yes, I think in this case it's overkill, and it would be more contributor-friendly to put the front-end stuff into this repo on a regular basis.

[MarkusH]

The only thing that is really missing is the command to install compass: gem install --user-install compass

[zerok]

Ah ok, I was afraid there was more missing than the "codification" of what is stated above the code snippet :-)

[MarkusH]

Waah, you're right. Gonna fix it.

@deeplook From my perspective this is the only thing that was really missing. If you have any ideas to improve the readme, I'm happy to hear them

[deeplook]

@Markush2010: I've also mentioned the missing data dependency/ies in my original issue description. Please reread...

[MarkusH]

@deeplook There already is a seperate ticket on initial data (#58).

I vote agains automatic commits to the repository with compiled css, this creates to much noise, so does including the css/js in general. @zerok, what do you think.

[led02]

From my point of view and what I teach the people at my company: Generated code is one of the artifacts that definately does not belong into a repository.

[veit]

IMO generated code shouldn’t be stored in a repository. @deeplook: It would be a good idea if you would work on #58 and improve yourself the description of the process to create JS/CSS for frontend. That would be a good basis for further discussions.

[deeplook]

@led02, if you want to emphasize academic purity over helpful contributions, I agree. An other pragmatic solution would be to pull the frontend stuff from somewhere else, call it whatever you like to read. BTW, #58 doesn't seem to describe a proposed solution. I won't add more to this...

[zerok]

The problem with "the Heroku way" when it comes to compiled assets is, that you have to put the debug version of these files either somewhere else or have to make sure that never the debug version is checked in at any time.

That's also the main reason why I prefer to have compile stylesheets and minified JavaScript sources generated on demand and require each contributor to have all the tools required to work on the whole project at their disposal.

@deeplook #58 should ideally provide a set of fixtures or a simple DB dump holding all required CMS pages etc. @Markush2010: could you please at your convenience add a description there? ;-)

[led02]

@deeplook It's less about "academic purity" than increased risk of conflicts. The best solution would be an automated build that does all that for you. However, this seems to exists to some extend already as I got my setup running within minutes (although I was aware of the compass 'issue' and installed it before).