This seems like a good candidate for a separate plugin. I don't like tying Haml and Sass too closely to Rails or to each other, and the idea of adding behavior for a certain workflow seems to map well to the idea of an individual plugin. I realize that monkeypatching Haml would be trickier than just modifying the source, but if you submit patches when you need more modularity, it should work out.
- Nathan [EMAIL PROTECTED] wrote: > I have The Next Big Idea: > > Typically, one could have the following setup: > > - in app/views/something/_form.html.haml: > .something_form > %input.whatever .... > .... > > - in public/stylesheets/sass/something/_form.sass: > .something_form > :border 1px solid black > ... > > THE PROBLEM (with the above approach and/or with *not* using the above > approach when styling partials) > > - That "something_form" HTML class name needs to be cleverly thought > out to make sure it's easy to remember *and* no other CSS (Sass) files > use it. > - The same name must be used in the Sass file as the Haml file, a > source of typos. > - Naming conflicts typically lie under the radar for ages, at which > point completely separate styles are mingled and separating them is a > chore. > - One must remember to put the classes in both Haml and Sass files. > - The entire Sass file is indented more than it need be, assuming the > convention that anything in public/stylesheets/sass/something/ > _form.sass is *only* meant to apply to the partial app/views/something/ > _form.html.haml > > In summary, there is no stylesheet namespacing and it is cumbersome to > enforce it through best practices. > > THE SOLUTION > > Imagine, if you will: > > In app/views/something/_form.html.haml: > ...whatever you want... > > In public/stylesheets/sass/something/_form.sass > ...whatever you want... > > And without any extra code, you are guaranteed that your styles in > something/_form.sass apply *only* to the something/form partial. (This > strategy would probably work very well with mix-ins, e.g., something/ > form's inputs would mix-in a global "fun_looking_input_box" as would > something_else/form's input.) > > Brief summary: namespacing by filename conventions. > > THE IMPLEMENTATION > > I want to implement this, and will try to get my company to let me go > the open-source route. I suspect the easiest method would be to patch > haml/sass directly. Here's what I'm thinking: > > - CONCEPT > > - Every template Haml renders will have a unique class name, based on > its path, applied to all root elements. For instance, if something/ > _form.html.haml looks like this: > > .some_div > ... > %span.other_div > ... > > The HTML spit out would look like this: > > <div class="some_div something___form"> > ... > </div> > <span class="other_div something___form"> > ... > </div> > > (The convention is to replace "/" in the path with "__", which is > arbitrary and likely inconsequential.) > > These extra class names are almost certainly conflict-free in any > project, and there is next-to-no real harm in adding them when > unnecessary. > > - PATCHING HAML > > Hack Haml::Buffer.open_tag to check if options[:namespacing] is set > and, if so, use options[:filename] to generate the namespace HTML > class name and add it to 'attributes', iff '@real_tabs == 0' > > - PATCHING SASS > > In Sass::Tree::Node.to_s, instead of calling child.to_s(1) on > RuleNodes, call child.to_s(1, > namespace_html_class_name_derived_from_filename), iff Sass::Engine was > initialized with options[:namespacing] set (an option which would have > to be passed to Sass::Tree::Node from within Sass::Engine). > > IN CONCLUSION > > Does this idea sound helpful enough to get buy-in from other users? > > Does it sound simple from an end-user point of view? (one would need > to set one Haml option and one Sass option, plus Capistrano rules for > deploying Sass.) I get the impression it would work better if all the > Sass files were nested into a particular subdirectory of public/ > stylesheets/sass, e.g., public/stylesheets/sass/namespaced, which > would differentiate auto-namespaced stylesheets with "global", un- > namespaced ones. > > And lastly: is my coding approach a good one, or are there other > places in the code I should be looking to best implement my design? > > Adam Hooper > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Haml" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/haml?hl=en -~----------~----~----~----~------~----~------~--~---
