Hi all. This is my first topic on here. I'm working on my second project with Nesta. I'm a longtime Wordpress CMS user, but the switch has been great. Anyway, I'm having some trouble integrating CoffeeScript. I've got bundled the 'coffe-script' gem, required it in app.rb, and set up the routes in the app class, i.e: get '/layout.js' do coffee :layout end layout.coffee is located in ./views (i'm not using a theme). The script is included in layout.haml header: %script(src="/layout.js") Does anyone know what might be wrong with this configuration? Thanks Aneesh
On 12 Sep 2011, at 22:48, aneesh wrote:
> Does anyone know what might be wrong with this configuration?
There's nothing wrong with what you did (i.e. it was quite logical), but
Nesta doesn't support anything other than .haml, .sass or .scss in your
site's ./views directory.
Nesta sets Sinatra's views folder to a folder inside the contents of the
gem, and then overrides the path to the views folder if it can find the
file on disk. It does this jiggery pokery so that the default theme can be
located inside the gem, and you can get a site up and running without
worrying about installing themes.
I wonder if it's worth the complexity - it might make more sense to force
people to choose and install a theme when creating a site.
Anyway, this should get you going:
module Nesta
class App
helpers do
def coffee(template, options = {}, locals = {})
defaults, engine = Overrides.render_options(template, :coffee)
super(template, defaults.merge(options), locals)
end
end
get '/layout.js' do
coffee :layout, :layout => false
end
end
end
The coffee helper is based on the haml and sass helpers in lib/nesta/overrides.rb.
https://github.com/gma/nesta/blob/master/lib/nesta/overrides.rb
This might be a part of that "one way" to do theming for Nesta like we talked about Graham. -- *Adam Stacoviak* http://adamstacoviak.com @adamstac On Tue, Sep 13, 2011 at 9:50 AM, Graham Ashton <graham@effectif.com> wrote: > On 12 Sep 2011, at 22:48, aneesh wrote: > > > Does anyone know what might be wrong with this configuration? > > There's nothing wrong with what you did (i.e. it was quite logical), but > Nesta doesn't support anything other than .haml, .sass or .scss in your > site's ./views directory. > > Nesta sets Sinatra's views folder to a folder inside the contents of the > gem, and then overrides the path to the views folder if it can find the file > on disk. It does this jiggery pokery so that the default theme can be > located inside the gem, and you can get a site up and running without > worrying about installing themes. > > I wonder if it's worth the complexity - it might make more sense to force > people to choose and install a theme when creating a site. > > Anyway, this should get you going: > > module Nesta > class App > helpers do > def coffee(template, options = {}, locals = {}) > defaults, engine = Overrides.render_options(template, :coffee) > super(template, defaults.merge(options), locals) > end > end > > get '/layout.js' do > coffee :layout, :layout => false > end > end > end > > The coffee helper is based on the haml and sass helpers in > lib/nesta/overrides.rb. > > https://github.com/gma/nesta/blob/master/lib/nesta/overrides.rb >
This is kind of tangental, but I think it would be very good to offer a 'basic theme' that uses vanilla CSS and uses some erubis for the simpler views. Both are technologies that don't need any explanation to the average developer, whereas SASS and HAML take quite a bit of getting used to. Nesta's greatest strength (in my opinion) is its simplicity and flexibility. It's easy to wrap your head around the whole CMS, and it doesn't get in your way (much). In my opinion, a great CMS is one that has very little CMS-specific knowledge. The litmus test is how quickly you can make a change after having been away from it for a year. NestaCMS is a great CMS, but I feel SASS works against Nesta there, forcing users to learn 2 additional languages in order to customize their website. While I love Nesta (and am switching all my websites to it), I spent over 25 hours trying to debug SASS and HAML issues, and ended up replacing all the SASS with vanilla CSS. CSS debugging happens in the browser, and SASS (and even SCSS, to a lesser extent) really gets in the way for me. In comparison, I learned the Lua programming language and implemented a continuation-serialization-based web game framework in less time than it took for SCSS and I to get along, and we still decided the relationship wasn't going to work :) I think there are solid arguments for and against both SA(C)SS and HAML, but personal preference is the deciding factor, and I suspect most people coming to Nesta are looking for freedom and flexibility, and it would be nice to offer them a choice. HAML is ok, but I found the syntax quirks and poor error messages to be very frustrating as I tried to learn it. Erubis has a far gentler learning curve, and I think that out-of-the-box support for it would make Nesta more approachable for the average developer. Half of my HAML views are :plain with just 1 or 2 variable substitutions. I've switched some of my sections to erubis, to make them easier to read and work with. It would be very nice to see automatic support for erubis sections based on file extensions. Anyhow, that's my rambling 2 cents on making NestaCMS more approachable and lowering the learning curve. I really don't want to start a discussion or war about HAML or S(C)SS flaws or merits, that's not my intent - I believe both are great inventions. My point is that it would be really great to let users opt-out of learning them :) I strongly believe it would help Nesta get more adoption. Best regards, Nathanael Jones On Tue, Sep 13, 2011 at 5:33 PM, Adam Stacoviak <adam@stacoviak.com> wrote: > This might be a part of that "one way" to do theming for Nesta like we > talked about Graham. > > -- > *Adam Stacoviak* > http://adamstacoviak.com > @adamstac > > > > On Tue, Sep 13, 2011 at 9:50 AM, Graham Ashton <graham@effectif.com>wrote: > >> On 12 Sep 2011, at 22:48, aneesh wrote: >> >> > Does anyone know what might be wrong with this configuration? >> >> There's nothing wrong with what you did (i.e. it was quite logical), but >> Nesta doesn't support anything other than .haml, .sass or .scss in your >> site's ./views directory. >> >> Nesta sets Sinatra's views folder to a folder inside the contents of the >> gem, and then overrides the path to the views folder if it can find the file >> on disk. It does this jiggery pokery so that the default theme can be >> located inside the gem, and you can get a site up and running without >> worrying about installing themes. >> >> I wonder if it's worth the complexity - it might make more sense to force >> people to choose and install a theme when creating a site. >> >> Anyway, this should get you going: >> >> module Nesta >> class App >> helpers do >> def coffee(template, options = {}, locals = {}) >> defaults, engine = Overrides.render_options(template, :coffee) >> super(template, defaults.merge(options), locals) >> end >> end >> >> get '/layout.js' do >> coffee :layout, :layout => false >> end >> end >> end >> >> The coffee helper is based on the haml and sass helpers in >> lib/nesta/overrides.rb. >> >> https://github.com/gma/nesta/blob/master/lib/nesta/overrides.rb >> > >
My 2 cents: @Graham: Nesta sets Sinatra's views folder to a folder inside the contents of the > gem, and then overrides the path to the views folder if it can find the file > on disk. It does this jiggery pokery so that the default theme can be > located inside the gem, and you can get a site up and running without > worrying about installing themes. > > I wonder if it's worth the complexity - it might make more sense to force > people to choose and install a theme when creating a site. > I think forcing people to choose would be perceived as more complexity - and being able to get started quickly with a simple theme (the current way) as less complexity. In user interface design this idiom is called Deferred Choices (get started quickly and simply, get proof of concept, then change the defaults as you wish). @Nathaniel: I really don't want to start a discussion or war about HAML or S(C)SS flaws > or merits, that's not my intent - I believe both are great inventions. My > point is that it would be really great to let users opt-out of learning them > :) I strongly believe it would help Nesta get more adoption. > Strictly speaking, one needs only learn HAML when mastering Nesta. I recently released a theme with views in HAML (really no alternative there, and really it's not too bad in my view. HAML is easy to learn when one has been hand-crafting markup and having done some Python also helps) and styles in plain 'ole CSS. I like the idea behind SASS but the opportunity cost of learning it versus confidently and rapidly coding in CSS (something I've spent a lot of effort to achieve) makes me go with the latter option - for now. As long as you have you CSS files in /public/css that's what Nesta will serve - so you can use your custom HAML and CSS for any Nesta site. / James On Tue, Sep 13, 2011 at 6:39 PM, Nathanael D. Jones < nathanael.jones@gmail.com> wrote: > This is kind of tangental, but I think it would be very good to offer a > 'basic theme' that uses vanilla CSS and uses some erubis for the simpler > views. Both are technologies that don't need any explanation to the average > developer, whereas SASS and HAML take quite a bit of getting used to. > > Nesta's greatest strength (in my opinion) is its simplicity and > flexibility. It's easy to wrap your head around the whole CMS, and it > doesn't get in your way (much). In my opinion, a great CMS is one that has > very little CMS-specific knowledge. The litmus test is how quickly you can > make a change after having been away from it for a year. > > NestaCMS is a great CMS, but I feel SASS works against Nesta there, forcing > users to learn 2 additional languages in order to customize their website. > While I love Nesta (and am switching all my websites to it), I spent over 25 > hours trying to debug SASS and HAML issues, and ended up replacing all the > SASS with vanilla CSS. CSS debugging happens in the browser, and SASS (and > even SCSS, to a lesser extent) really gets in the way for me. In > comparison, I learned the Lua programming language and implemented a > continuation-serialization-based web game framework in less time than it > took for SCSS and I to get along, and we still decided the relationship > wasn't going to work :) > > I think there are solid arguments for and against both SA(C)SS and HAML, > but personal preference is the deciding factor, and I suspect most people > coming to Nesta are looking for freedom and flexibility, and it would be > nice to offer them a choice. > > HAML is ok, but I found the syntax quirks and poor error messages to be > very frustrating as I tried to learn it. Erubis has a far gentler learning > curve, and I think that out-of-the-box support for it would make Nesta more > approachable for the average developer. > > Half of my HAML views are :plain with just 1 or 2 variable substitutions. > I've switched some of my sections to erubis, to make them easier to read and > work with. It would be very nice to see automatic support for erubis > sections based on file extensions. > > Anyhow, that's my rambling 2 cents on making NestaCMS more approachable and > lowering the learning curve. > > I really don't want to start a discussion or war about HAML or S(C)SS flaws > or merits, that's not my intent - I believe both are great inventions. My > point is that it would be really great to let users opt-out of learning them > :) I strongly believe it would help Nesta get more adoption. > > Best regards, > Nathanael Jones > > On Tue, Sep 13, 2011 at 5:33 PM, Adam Stacoviak <adam@stacoviak.com>wrote: > >> This might be a part of that "one way" to do theming for Nesta like we >> talked about Graham. >> >> -- >> *Adam Stacoviak* >> http://adamstacoviak.com >> @adamstac >> >> >> >> On Tue, Sep 13, 2011 at 9:50 AM, Graham Ashton <graham@effectif.com>wrote: >> >>> On 12 Sep 2011, at 22:48, aneesh wrote: >>> >>> > Does anyone know what might be wrong with this configuration? >>> >>> There's nothing wrong with what you did (i.e. it was quite logical), but >>> Nesta doesn't support anything other than .haml, .sass or .scss in your >>> site's ./views directory. >>> >>> Nesta sets Sinatra's views folder to a folder inside the contents of the >>> gem, and then overrides the path to the views folder if it can find the file >>> on disk. It does this jiggery pokery so that the default theme can be >>> located inside the gem, and you can get a site up and running without >>> worrying about installing themes. >>> >>> I wonder if it's worth the complexity - it might make more sense to force >>> people to choose and install a theme when creating a site. >>> >>> Anyway, this should get you going: >>> >>> module Nesta >>> class App >>> helpers do >>> def coffee(template, options = {}, locals = {}) >>> defaults, engine = Overrides.render_options(template, :coffee) >>> super(template, defaults.merge(options), locals) >>> end >>> end >>> >>> get '/layout.js' do >>> coffee :layout, :layout => false >>> end >>> end >>> end >>> >>> The coffee helper is based on the haml and sass helpers in >>> lib/nesta/overrides.rb. >>> >>> https://github.com/gma/nesta/blob/master/lib/nesta/overrides.rb >>> >> >> >
@ Graham I looked back to reference this email and realized I hadn't thanked you profusely for your help. Thank you, profusely. This worked out great. On my current website I needed to manage some more tabular content (roster & schedule for a hockey team). Has anyone done something like this, and do you have any advice? Not positive I've done it right, but I kind of hacked something together with the .csv functionality in Ruby's stdlib. This was neat with the gdocs4ruby gem, I can schedule a daily parse of a google spreadsheet (edited by team captains) into the csv, then use that file for tabular data. Aneesh On Tue, Sep 13, 2011 at 10:50 AM, Graham Ashton <graham@effectif.com> wrote: > On 12 Sep 2011, at 22:48, aneesh wrote: > > > Does anyone know what might be wrong with this configuration? > > There's nothing wrong with what you did (i.e. it was quite logical), but > Nesta doesn't support anything other than .haml, .sass or .scss in your > site's ./views directory. > > Nesta sets Sinatra's views folder to a folder inside the contents of the > gem, and then overrides the path to the views folder if it can find the file > on disk. It does this jiggery pokery so that the default theme can be > located inside the gem, and you can get a site up and running without > worrying about installing themes. > > I wonder if it's worth the complexity - it might make more sense to force > people to choose and install a theme when creating a site. > > Anyway, this should get you going: > > module Nesta > class App > helpers do > def coffee(template, options = {}, locals = {}) > defaults, engine = Overrides.render_options(template, :coffee) > super(template, defaults.merge(options), locals) > end > end > > get '/layout.js' do > coffee :layout, :layout => false > end > end > end > > The coffee helper is based on the haml and sass helpers in > lib/nesta/overrides.rb. > > https://github.com/gma/nesta/blob/master/lib/nesta/overrides.rb >