librelist archives

« back to archive

CoffeeScript Integration

CoffeeScript Integration

From:
aneesh
Date:
2011-09-12 @ 21:48
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

Re: [nesta] CoffeeScript Integration

From:
Graham Ashton
Date:
2011-09-13 @ 14:50
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

Re: [nesta] CoffeeScript Integration

From:
Adam Stacoviak
Date:
2011-09-13 @ 15:33
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
>

Re: [nesta] CoffeeScript Integration

From:
Nathanael D. Jones
Date:
2011-09-13 @ 16:39
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
>>
>
>

Re: [nesta] CoffeeScript Integration

From:
James Abbott
Date:
2011-09-14 @ 12:23
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
>>>
>>
>>
>

Re: [nesta] CoffeeScript Integration

From:
aneesh
Date:
2011-09-22 @ 13:36
@ 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
>