explicit partials support?
Jon
http://groups.google.com/group/sinatrarb/browse_thread/thread/4b0b737e1b03b30a/15cc2ef959b863df
there was discussion of potentially setting :layout => false in the
core Sinatra code when rendering templates starting with "_".
Other threads have discussed various ways of using helpers. What's
the latest thoughts on pulling something "standard" into
Sinatra::Base?
Jon
Damian Janowski
Changing the value of :layout depending on the filename starting with
an underscore sounds like a really bad API.
I simply use this:
http://github.com/monkrb/glue/blob/1a5a2ad8beb6275692394f35b3401b8b9a67ae53/lib/monk/glue.rb#L54-56
I don't think it's worth including in core, at all.
Damian Janowski
<damian....@gmail.com> wrote:
> Changing the value of :layout depending on the filename starting with
> an underscore sounds like a really bad API.
That said, if you use a helper, there's nothing stopping you from
using your own convention if you feel the need to:
!= partial :foo
!= partial :_foo
!= partial :"partials/foo"
etc.
Jon
> > Changing the value of :layout depending on the filename starting with
> > an underscore sounds like a really bad API.
>
> That said, if you use a helper, there's nothing stopping you from
> using your own convention if you feel the need to:
>
> != partial :foo
> != partial :_foo
> != partial :"partials/foo"
the :_foo, :"my/nested/sub/dirs/_foo" convention already and don't see
have any real heartburn with "_". One can always tailor to their
unique needs with a helper if needed, and having in core already is
nice to be able to count on.
The concern I have is in the implementation of anything that would go
in core.
As my_convention != your_convention, the impl can quickly slide down
the slope into a furball trying to deal with a bunch of oddball corner
cases in order to please everyone. If this would be the case, I think
it would cause a strong allergic reaction and go against the things
people really like about Sinatra.
I'm really just trying to find out the latest thoughts of the
contributors on this.
Damian Janowski
> I see some value with including in core if people are using
> the :_foo, :"my/nested/sub/dirs/_foo" convention already and don't see
> have any real heartburn with "_". One can always tailor to their
> unique needs with a helper if needed, and having in core already is
> nice to be able to count on.
>
> The concern I have is in the implementation of anything that would go
> in core.
Agreed. It's not that I want to keep a status quo, just that the
current implementation (no extra checks for "_") allows you to write
your own helper with your convention (you can subclass, define #haml,
and call super). The same wouldn't be true if we changed the
implementation.
In any case, I think template rendering code is frozen until Tilt is
integrated, so we might need to wait a little bit on that...
Nicolás Sanguinetti
In any case, Tilt is only used internally, the rendering API is still
the same. Ie, you call haml/erb/whatever, which in turn calls
render(:haml, *args), etc.
-foca
> >
>
DAZ
it is of some use, DAZ
http://gist.github.com/167191
Usage
------------
All partials go in the 'views' folder and start with an
underscore (e.g. '_shop.erb')
To call a partial, just call it by name: render_partial :shop
If you include a second argument, this is passed on as the value of
the local variable with the same name as the template.
e.g.
render_partial :shop,"ikea"
will render '_shop.erb' and set the local shop variable to be 'ikea'
You can also pass an array
e.g.
render_partial :shop,["ikea","tesco","footlocker"]
will render the '_shop.erb' template 3 times, passing the 3 shops
into
the local variable shop each time.
If you have local variable that is not the same name as the template
name, then just pass a hash:
e.g.
render_partial :shop,{ :owner => 'Bob', :city => 'Man' }
will render the '_shop.erb' template and set the local variable owner
to 'Bob' and the local variable city to 'Man'.
You can pass objects as the argument:
e.g.
render_partial @shop
This will render the '_shop.erb' partial and set the local variable
shop=@shop
You can also give arrarys of objects as the argument:
e.g.
render_partial @shops
This will render a partial for each shop object in the @shops array
and pass each shop object into the local variable called shop.
On Oct 30, 6:18 pm, Nicolás Sanguinetti <godf...@gmail.com> wrote:
> On Fri, Oct 30, 2009 at 4:08 PM, Damian Janowski
>
>
>
>
>
Kyle Drake
<damian....@gmail.com> wrote:
>
> Changing the value of :layout depending on the filename starting with
> an underscore sounds like a really bad API.
>
> I simply use this:
> http://github.com/monkrb/glue/blob/1a5a2ad8beb6275692394f35b3401b8b9a67ae53/lib/monk/glue.rb#L54-56
>
> I don't think it's worth including in core, at all.
>
We use something very similar (to the Monk code) for partials, and
have never had any problems with it. Ours is also three lines of code.
I think all this does is make Sinatra act more like Rails, with no
real added value (we're talking about one more character when you're
typing in a file name here). We've implemented partials a few
different ways that don't make any sense with the underscore. For
example, we've implemented "super partials", which are partials
re-used by multiple controller routes, by putting a partials folder in
the view root.
-Kyle
Ryan Tomayko
false when inside another template render:
https://sinatra.lighthouseapp.com/projects/9779/tickets/181
http://github.com/rtomayko/sinatra/commit/autopartial
That would let you omit `:layout => false` from calls to render
methods, giving everything partial-ish semantics when called from
templates or helpers in templates.
# tomayko.com/about