librelist archives

home // archives //

« back to archive

Creating different HTML outlines per-page

Creating different HTML outlines per-page

From:
James Abbott
Date:
2011-03-23 @ 11:37 
Hi,-

I'm trying to create custom designs on Nesta and here's what I've done:

1) Imported the /view folder from the gem into the app
2) Created a /public folder where I store images, JS and CSS files. Nesta
loads styles from /public/css so that's where one can put one's CSS while
developing the design (I prefer raw CSS to SASS - more control).

What I haven't grokked yet is how to change the template mechanism to render
different structures of markup. So layout.haml calls yield, which inserts
page.haml (which conditionally inserts several sub-templates).

This results in an an overall document outline of:

html
 head
   body
     div#container
        div#content
           article [role="main"]

(Several nodes omitted). What if I want to make a page that "inserts itself"
entirely, like this:

<!DOCTYPE html>
page goes here
<html>

For one, this would allow one to hand-craft the page metadata in the "head"
element (good for SEO). Secondly, it would allow for a different document
outline. But I only want this *per-page*. How would Nesta know which layout
to render if my index page (that lists article summaries) uses the standard
layout but a "work" page is altogether custom? Right now, all pages just get
passed through layout.haml and there must be some conditional logic to make
these differentiated pages pass through?

Cheers,
James

Re: [nesta] Creating different HTML outlines per-page

From:
Graham Ashton
Date:
2011-03-23 @ 12:04 
Have you seen the docs for the layout, keyword and description metadata? 
They're all on the metadata reference page.

On 23 Mar 2011, at 11:37, James Abbott <abbottjam@gmail.com> wrote:

> Hi,-
> 
> I'm trying to create custom designs on Nesta and here's what I've done:
> 
> 1) Imported the /view folder from the gem into the app
> 2) Created a /public folder where I store images, JS and CSS files. 
Nesta loads styles from /public/css so that's where one can put one's CSS 
while developing the design (I prefer raw CSS to SASS - more control).
> 
> What I haven't grokked yet is how to change the template mechanism to 
render different structures of markup. So layout.haml calls yield, which 
inserts page.haml (which conditionally inserts several sub-templates).
> 
> This results in an an overall document outline of:
> 
> html
>  head
>    body
>      div#container
>         div#content
>            article [role="main"]
> 
> (Several nodes omitted). What if I want to make a page that "inserts 
itself" entirely, like this:
> 
> <!DOCTYPE html>   
> page goes here 
> <html>
> 
> For one, this would allow one to hand-craft the page metadata in the 
"head" element (good for SEO). Secondly, it would allow for a different 
document outline. But I only want this per-page. How would Nesta know 
which layout to render if my index page (that lists article summaries) 
uses the standard layout but a "work" page is altogether custom? Right 
now, all pages just get passed through layout.haml and there must be some 
conditional logic to make these differentiated pages pass through?
> 
> Cheers,
> James
> 
> 
>

Re: [nesta] Creating different HTML outlines per-page

From:
James Abbott
Date:
2011-03-23 @ 12:37 
Oh. I have now. You've really made this a breeze, and documented it; sorry
for the inconvenience.

On a different note, I'd never guess that layouting could be controlled
through page metadata; it's a very unusual solution. So perhaps a link from
one of these pages:

http://nestacms.com/docs/design/custom-designs
http://nestacms.com/docs/design/editing-default-templates

to the layout part of the metadata reference page would create a better
information architecture for task-based questions as regards custom layouts?

Cheers,
James


On Wed, Mar 23, 2011 at 1:04 PM, Graham Ashton <graham@effectif.com> wrote:

> Have you seen the docs for the layout, keyword and description metadata?
> They're all on the metadata reference page.
>
> On 23 Mar 2011, at 11:37, James Abbott <abbottjam@gmail.com> wrote:
>
> Hi,-
>
> I'm trying to create custom designs on Nesta and here's what I've done:
>
> 1) Imported the /view folder from the gem into the app
> 2) Created a /public folder where I store images, JS and CSS files. Nesta
> loads styles from /public/css so that's where one can put one's CSS while
> developing the design (I prefer raw CSS to SASS - more control).
>
> What I haven't grokked yet is how to change the template mechanism to
> render different structures of markup. So layout.haml calls yield, which
> inserts page.haml (which conditionally inserts several sub-templates).
>
> This results in an an overall document outline of:
>
> html
>  head
>    body
>      div#container
>         div#content
>            article [role="main"]
>
> (Several nodes omitted). What if I want to make a page that "inserts
> itself" entirely, like this:
>
> <!DOCTYPE html>
> page goes here
> <html>
>
> For one, this would allow one to hand-craft the page metadata in the "head"
> element (good for SEO). Secondly, it would allow for a different document
> outline. But I only want this *per-page*. How would Nesta know which
> layout to render if my index page (that lists article summaries) uses the
> standard layout but a "work" page is altogether custom? Right now, all pages
> just get passed through layout.haml and there must be some conditional logic
> to make these differentiated pages pass through?
>
> Cheers,
> James
>
>
>
>

Re: [nesta] Creating different HTML outlines per-page

From:
Graham Ashton
Date:
2011-03-23 @ 13:47 
On 23 Mar 2011, at 12:37, James Abbott wrote:

> perhaps a link from one of these pages:
> 
> http://nestacms.com/docs/design/custom-designs
> http://nestacms.com/docs/design/editing-default-templates
> 
> to the layout part of the metadata reference page would create a better 
information architecture for task-based questions as regards custom 
layouts?

Yes, you're probably right. I've added it to the todo list and will see 
what I can do next time I'm doing a round of updates.

Archives based on code by Armin Ronacher //