I'm creating a new site with .scss as the format for stylesheets; the main sheet with all the imports is /views/screen.scss. I've also imported app.rb into the site's root because there's some stuff in there I need to overwrite. With the app.rb in there the styles don't get applied: /css/screen.css isn't generated. When I remove everything in app.rb, everything is fine again. I'm guessing I have to re-declare that "I'm using a stylesheet and by the way, its name is screen.scss and it is actually right there where it's supposed to be", but I'm blinking on the "right way to do it". Help? :-) /J.
Never copy app.rb in from the gem, just make a blank app.rb file and define what you need to override inside it. It seems to be a surprisingly (to me) common misunderstanding, so if there's a part of the docs that suggest this is the way forward, please let me know so I can fix it sharpish. Cheers. > On 29 Jun 2014, at 14:26, James Abbott <abbottjam@gmail.com> wrote: > > I'm creating a new site with .scss as the format for stylesheets; the main sheet with all the imports is /views/screen.scss. > > I've also imported app.rb into the site's root because there's some stuff in there I need to overwrite. > > With the app.rb in there the styles don't get applied: /css/screen.css isn't generated. When I remove everything in app.rb, everything is fine again. > > I'm guessing I have to re-declare that "I'm using a stylesheet and by the way, its name is screen.scss and it is actually right there where it's supposed to be", but I'm blinking on the "right way to do it". > > Help? > > :-) > > /J.
Actually, the file was copied from another Nesta site (and tweaked some);
it doesn't come straight from the gem. Here's what it looks like:
https://gist.github.com/abbottjam/2035999f0d916e2ca335
As for instructions in the docs, I don't think there's anything in there
that explicitly encourages the copying of app.rb from the gem. Although
implicitly this may be the case. The parts that talk about creating custom
themes instruct one to copy the /views folder into the site and tweak them.
If one were to construct an analogy ("copy Nesta file from gem to site"),
this *could* be interpreted as being true for app.rb as well:
http://nestacms.com/docs/design/editing-default-templates
Cheers,
/J.
On Sun, Jun 29, 2014 at 3:38 PM, Graham Ashton <graham@effectif.com> wrote:
> Never copy app.rb in from the gem, just make a blank app.rb file and
> define what you need to override inside it.
>
> It seems to be a surprisingly (to me) common misunderstanding, so if
> there's a part of the docs that suggest this is the way forward, please let
> me know so I can fix it sharpish.
>
> Cheers.
>
> > On 29 Jun 2014, at 14:26, James Abbott <abbottjam@gmail.com> wrote:
> >
> > I'm creating a new site with .scss as the format for stylesheets; the
> main sheet with all the imports is /views/screen.scss.
> >
> > I've also imported app.rb into the site's root because there's some
> stuff in there I need to overwrite.
> >
> > With the app.rb in there the styles don't get applied: /css/screen.css
> isn't generated. When I remove everything in app.rb, everything is fine
> again.
> >
> > I'm guessing I have to re-declare that "I'm using a stylesheet and by
> the way, its name is screen.scss and it is actually right there where it's
> supposed to be", but I'm blinking on the "right way to do it".
> >
> > Help?
> >
> > :-)
> >
> > /J.
>
On 30 Jun 2014, at 07:18, James Abbott <abbottjam@gmail.com> wrote: > Actually, the file was copied from another Nesta site (and tweaked some); it doesn't come straight from the gem. Here's what it looks like: > > https://gist.github.com/abbottjam/2035999f0d916e2ca335 Okay, I think I can see what’s happened. The code in the gem contains a `get ‘*’` block that will match all GET requests that haven’t been matched by any of the request handlers that are already defined. If you define a request handler after that wildcard handler, Sinatra will ignore it. Nesta therefore loads your app.rb file before it loads its own wildcard matcher, so you get a chance to define your own request handlers. If your app.rb file contains a handler that matches the wildcard, well you can guess what happens. It’s loaded first, so none of Nesta’s existing routes match. I’m planning on writing a method to allow you to define a wildcard handler to replace the default one, rather than having it eat every request. This would avoid the need to copy all of Nesta’s routes in above it in your own app.rb (which will be brittle if they get updated in a future version of Nesta, though the risk is small). The real solution to what you’re doing (rendering Erb) is built-in support for rendering templates in any syntax, and then you could just use Nesta's built-in request handlers. https://github.com/gma/nesta/issues/74 > As for instructions in the docs, I don't think there's anything in there that explicitly encourages the copying of app.rb from the gem. Although implicitly this may be the case. The parts that talk about creating custom themes instruct one to copy the /views folder into the site and tweak them. If one were to construct an analogy ("copy Nesta file from gem to site"), this *could* be interpreted as being true for app.rb as well. Thanks. Unless I know people are actually making that inference I’ll avoid mentioning it on that page though (it would seem a little out of context).
OK, so the wildcard handler in /app.rb gets loaded first, preventing the one in the gem from getting loaded. I get that. What I don't get is how to start using Erb (you're right, I want to move to Erb from HAML for all my static templates). For one, the issue opened by Nathaniel Jones seems to be open still so it looks like the proposal hasn't been incorporated in Nesta. Secondly, ...and then you could just use Nesta's built-in request handlers. > What are these handlers and how to I use them without resorting to this in app.rb? erb(@page.template, :layout => @page.layout) I'm building this site from scratch so I've only got layout.haml and page.haml. Converting these to .erb format results in errors... /J. On Mon, Jun 30, 2014 at 10:21 AM, Graham Ashton <graham@effectif.com> wrote: > On 30 Jun 2014, at 07:18, James Abbott <abbottjam@gmail.com> wrote: > > > Actually, the file was copied from another Nesta site (and tweaked > some); it doesn't come straight from the gem. Here's what it looks like: > > > > https://gist.github.com/abbottjam/2035999f0d916e2ca335 > > Okay, I think I can see what’s happened. > > The code in the gem contains a `get ‘*’` block that will match all GET > requests that haven’t been matched by any of the request handlers that are > already defined. > > If you define a request handler after that wildcard handler, Sinatra will > ignore it. Nesta therefore loads your app.rb file before it loads its own > wildcard matcher, so you get a chance to define your own request handlers. > > If your app.rb file contains a handler that matches the wildcard, well you > can guess what happens. It’s loaded first, so none of Nesta’s existing > routes match. > > I’m planning on writing a method to allow you to define a wildcard handler > to replace the default one, rather than having it eat every request. This > would avoid the need to copy all of Nesta’s routes in above it in your own > app.rb (which will be brittle if they get updated in a future version of > Nesta, though the risk is small). > > The real solution to what you’re doing (rendering Erb) is built-in support > for rendering templates in any syntax, and then you could just use Nesta's > built-in request handlers. > > https://github.com/gma/nesta/issues/74 > > > As for instructions in the docs, I don't think there's anything in there > that explicitly encourages the copying of app.rb from the gem. Although > implicitly this may be the case. The parts that talk about creating custom > themes instruct one to copy the /views folder into the site and tweak them. > If one were to construct an analogy ("copy Nesta file from gem to site"), > this *could* be interpreted as being true for app.rb as well. > > Thanks. Unless I know people are actually making that inference I’ll avoid > mentioning it on that page though (it would seem a little out of context). >
Sorry, I explained the problem but not the solution! Open the app.rb file in the gem and copy all the request handlers (the blocks that start with `get`) into your own app.rb. This is what the templating engine docs you've been following mean when they say "copy the default routes": http://nestacms.com/docs/design/templating-engines Clearly "default routes" isn't an adequate explanation. Once you've copied them, edit the wildcard one so it uses erb instead. This will cease to be necessary when I add a way to override just the default route, or when I sort out #74. And you're right, I haven't applied Nathaniel's patch. It has some great ideas in it, and is great inspiration for how to solve it, but I'd like to re-implement it test-first. > On 30 Jun 2014, at 13:07, James Abbott <abbottjam@gmail.com> wrote: > > OK, so the wildcard handler in /app.rb gets loaded first, preventing the one in the gem from getting loaded. I get that. > > What I don't get is how to start using Erb (you're right, I want to move to Erb from HAML for all my static templates). > > For one, the issue opened by Nathaniel Jones seems to be open still so it looks like the proposal hasn't been incorporated in Nesta. > > Secondly, > >> ...and then you could just use Nesta's built-in request handlers. > > What are these handlers and how to I use them without resorting to this in app.rb? > > erb(@page.template, :layout => @page.layout) > > I'm building this site from scratch so I've only got layout.haml and page.haml. Converting these to .erb format results in errors... > > /J.
> > Open the app.rb file in the gem and copy all the request handlers (the > blocks that start with `get`) into your own app.rb. This is what the > templating engine docs you've been following mean when they say "copy the > default routes": > OK, so basically replicate all 'get' handlers so that the "catch-all" handler doesn't end up gobbling up all possible requests. Clearly "default routes" isn't an adequate explanation. > "Pre-defined 'get' handlers" maybe? This will cease to be necessary when I add a way to override just the > default route, or when I sort out #74. And you're right, I haven't applied > Nathaniel's patch. It has some great ideas in it, and is great inspiration > for how to solve i t, but I'd like to re-implement it test-first. > > Sounds good, maybe this issue can provide a usage scenario for a good test case or edge case. Thanks! /J. On Mon, Jun 30, 2014 at 2:43 PM, Graham Ashton <graham@effectif.com> wrote: > Sorry, I explained the problem but not the solution! > > Open the app.rb file in the gem and copy all the request handlers (the > blocks that start with `get`) into your own app.rb. This is what the > templating engine docs you've been following mean when they say "copy the > default routes": > > http://nestacms.com/docs/design/templating-engines > > Clearly "default routes" isn't an adequate explanation. > > Once you've copied them, edit the wildcard one so it uses erb instead. > > This will cease to be necessary when I add a way to override just the > default route, or when I sort out #74. And you're right, I haven't applied > Nathaniel's patch. It has some great ideas in it, and is great inspiration > for how to solve i t, but I'd like to re-implement it test-first. > > On 30 Jun 2014, at 13:07, James Abbott <abbottjam@gmail.com> wrote: > > OK, so the wildcard handler in /app.rb gets loaded first, preventing the > one in the gem from getting loaded. I get that. > > What I don't get is how to start using Erb (you're right, I want to move > to Erb from HAML for all my static templates). > > For one, the issue opened by Nathaniel Jones seems to be open still so it > looks like the proposal hasn't been incorporated in Nesta. > > Secondly, > > ...and then you could just use Nesta's built-in request handlers. >> > > What are these handlers and how to I use them without resorting to this in > app.rb? > > erb(@page.template, :layout => @page.layout) > > I'm building this site from scratch so I've only got layout.haml and > page.haml. Converting these to .erb format results in errors... > > /J. > >