On Feb 2, 5:55 pm, Hampton <[EMAIL PROTECTED]> wrote: > Where to put the Sass files was something I thought long and hard > about. Initially, they were going to go in the app/ folder. However, > the more I thought about it, I realized this was a Bad Thing. > > Why? [Snip] > The reason that the Sass file should be in public is because it should > be made public to anyone wanting to view it. Imagine a firefox plugin > that does conversion for you. I'm sure you're familiar with EditCSS or > Web Developer that allow you to edit the CSS in-page. Well, I'd really > like to modify EditCSS, to EditSass, so that what it does is loads up > the css files that are referenced on the page, and then it tries to > request where it guesses that a .sass file that corrolates might be. > If there is a Sass file, then you can edit the sass file in line and > have it update instantly on the page. Then, you just save that edited > Sass right over into your application just like we do with CSS these > days.
OK, you are of course free to reason however you like - and Sass is your creation to start with, but still, I can't agree with this. I really can not see the point in letting anyone get to the Sass files so they can *change* the CSS on *my* site. And in any case they can only do that in the context of a web developer plugin or the like. I am perfectly fine with people messing with my site source in any way they like *if I have provided them with the full source* myself. And if they want to try grabbing things out of my running production site, so be it, but in that case I will not help them. What you are saying is similar to me providing the Photoshop files used as source for the images on my site. While I may do that if I package the site to share with others, I'm sure you'll agree that you would not expect to find that on a production site. > Also! If we put them in /app, then people will *assume* dynamic. In > reality, what should happen in production mode is that when the server > starts up, it parses the Sass files and creates the CSS, then just > goes about its business and forgets that they ever existed. This is > incredibly fast on our servers. So, all we are doing is adding > something that will compile Sass into CSS if its floating around in > public and then both files are made truly public. Well, alright, but so what? People will assume that any file in /app is somehow data-driven? I don't think that is neccessarily the case, and even if so, I don't see that as a reason for not putting the Sass files there. > So, that is my reasoning. So what you are saying is basically that you want anyone to have access to the Sass files because it is neat that they can see how the source for the CSS files looks? OK, fine, but shouldn't then the entire application be in /public? People might be interested in my model files for instance. Well, I guess we'll just have to agree to disagree. I think that / public only should have a bale minimum of files that absolutely must be publically acessible for the application to work. Anything else should be somewhere else. Anyone else want to chime in? /sven axelsson --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/haml?hl=en -~----------~----~----~----~------~----~------~--~---
