Hi,

Take 2 of the Sass mixin/include code:

http://pastie.org/173254

For this version I've decided to do a global rename of 'include' to  
'mixin' because
it's a more immediately understandable ruby metaphor. I think it's  
clearer.

On 31 Mar 2008, at 15:46, Nathan Weizenbaum wrote:

> In general, I think a better way to go about this would be to avoid
> adding new Node types entirely. An include definition is really just  
> an
> array of Nodes; all you need to do when you encounter the include (in
> build_tree; you'd probably want to return the include name as a string
> from parse_tree) is to add all its children into an array and put that
> in a hash (@includes or something) keyed by the include name. Then  
> when
> you see an include directive, just insert all the associated  
> children as
> children of the current node. This way you can avoid all sorts of
> string-munging, since you're just dealing with tree nodes.

I couldn't make it work without creating a new node type. The problem  
comes with
the return types from parse_line and build_tree.

Basically, and let me see if I can get this right, the mixin syntax  
requires handling
two cases: the definition of the mixin and the (possibly multiple)  
calls to include it.

Your suggestion involves returning a string on mixin definition and  
then an array on
mixin include (I think). This would have worked except that there are  
various tests
lying around for Array return types, all of which generate exceptions  
complaining
of include directives not at the root level -- returning an array is  
already dealt
with by the include directive code and I never managed to find work my  
array of
childnodes into that scheme without raising those exceptions.

Instead I've added a very simple MixinNode that collects its children  
just like a
RuleNode but outputs nil instead of a String on its to_s call. This is  
created and
returned from parse_line on mixin definition. Mixin includes are  
handled by
returning the mixin name as a string, as you suggest, which then  
simply looks
up the appropriate MixinNode by name from the @mixins hash and appends  
its
children to the node that called the '+' include directive.

Just to tidy things up at the output stage, I made the Node object  
look at the
value of the top level nodes' to_s call and only append to the css if  
this returns
a true value. This avoided the inclusion of one blank line for each  
mixin definition.

The generated CSS is much better (the first version had very messy  
indentation),
and the use of nodes rather than strings means its all much cleaner.

The only exception I could think to test for was an invalid mixin name  
at the include
step. Perhaps there's something obvious I'm missing?

Oh, I've also added documentation into sass.rb and the README, as you  
suggested and
this time included the full diff in the pastie (last time i  
unwittingly editied out the header
lines).

Please let me know if there's anything I've missed or you don't  
like.... ;)

Best,

Garry




--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to