hi,
i was just wondering, does Rails offer, or plan to offer,
HTML::Mason-like AOP for templates?
the Masonic notion does not map directly to the Rails way of doing
things, i suspect,
i think the closest thing Rails has to a component in Mason
terminology is the template, and i'll use template below when i mean
"component" in HTML::Mason terms.
with HTML::Mason, you can define a "autohandler" for any particular
path. what this means is that the autohandler is a parent (for the
purposes of presentational output) for any template contained at or
below that path.
it has complete control of the output and can decide where the output
of any contained templates should go. you can obviously override it
selectively for components that you don't want this behaviour to apply
to.
the concept is very powerful though, as the wrapped component need
know nothing about how its being wrapped. this is also vastly superior
to include mechanisms, as it is completely DRYish 
Mason examples:
/autohandler - gets invoked for all paths
/admin/autohandler - gets invoked for everything below /admin
there is of course also the Mason concept of "dhandler", or "default
handler", when nonexistent paths are attempted to be accessed, but
thats a whole different discussion.
the autohandler feature is something i would not be able to live
without though, as it has meant a vast reduction in LOC for my web
apps.
comments?
leon
hi!
not sure if i understand you correct, but maybe you
search for something like html decoration stuff? check out
the 'layout' method for the actionpack controllers...
http://ap.rubyonrails.org/classes/ActionController/Layout/ClassMethods.html
ciao!
florian
···
On Jul 26, 2004, at 10:20 Uhr, leon breedt wrote:
hi,
i was just wondering, does Rails offer, or plan to offer,
HTML::Mason-like AOP for templates?
the Masonic notion does not map directly to the Rails way of doing
things, i suspect,
i think the closest thing Rails has to a component in Mason
terminology is the template, and i'll use template below when i mean
"component" in HTML::Mason terms.
with HTML::Mason, you can define a "autohandler" for any particular
path. what this means is that the autohandler is a parent (for the
purposes of presentational output) for any template contained at or
below that path.
it has complete control of the output and can decide where the output
of any contained templates should go. you can obviously override it
selectively for components that you don't want this behaviour to apply
to.
the concept is very powerful though, as the wrapped component need
know nothing about how its being wrapped. this is also vastly superior
to include mechanisms, as it is completely DRYish 
Mason examples:
/autohandler - gets invoked for all paths
/admin/autohandler - gets invoked for everything below /admin
there is of course also the Mason concept of "dhandler", or "default
handler", when nonexistent paths are attempted to be accessed, but
thats a whole different discussion.
the autohandler feature is something i would not be able to live
without though, as it has meant a vast reduction in LOC for my web
apps.
comments?
leon
seems like i'll have to a bit more reading, but from the documentation
available there, it looks like layouts are intended to address exactly
the concerns i had regarding duplication.
thanks!
leon
···
On Mon, 26 Jul 2004 17:26:26 +0900, Florian Weber <csshsh@structbench.com> wrote:
http://ap.rubyonrails.org/classes/ActionController/Layout/
ClassMethods.html
For those that know, would this be akin to Tiles in Struts (in a somewhat different form)?
Thanks,
Nick
leon breedt wrote:
···
On Mon, 26 Jul 2004 17:26:26 +0900, Florian Weber ><csshsh@structbench.com> wrote:
http://ap.rubyonrails.org/classes/ActionController/Layout/
ClassMethods.html
seems like i'll have to a bit more reading, but from the documentation
available there, it looks like layouts are intended to address exactly
the concerns i had regarding duplication.
thanks!
leon
For those that know, would this be akin to Tiles in Struts (in a somewhat different form)?
I looked at both SiteMesh and Tiles before doing layouts in Action Pack. So yes, there was indeed inspiration, but mostly in the sense of what _not_ to do. I think both approaches are over-engineered to the point of being laborious and hard to understand. But I feel that about many things, so...
Anyway, in my opinion, the benefit of SiteMesh and Tiles is the inversion principle. Instead of having content templates reference common layout (through include header/footer and the like), you make the layout reference the content. That's where at least 80% of the benefit is hidden to me. And layouts in Action Pack implements that for 5% of the effort (it's really just a string!).
···
--
David Heinemeier Hansson,
http://www.rubyonrails.org/ -- Web-application framework for Ruby
http://www.instiki.org/ -- A No-Step-Three Wiki in Ruby
http://www.basecamphq.com/ -- Web-based Project Management
http://www.loudthinking.com/ -- Broadcasting Brain
http://www.nextangle.com/ -- Development & Consulting Services