Pastie seems to be down at the moment, but I can comment on your description. My suggestion was to return a string from parse_line on a mixin declaration, but just returning a normal Node from a mixin include. Then you could do the @mixin stuff in a parse_mixin method, and not add anything to the tree (actually, a more consistent way to do this would be to return :mixin), and an include wouldn't require much extra code at all.
- Nathan On Mon, Mar 31, 2008 at 11:14 AM, Garry Hill <[EMAIL PROTECTED]> wrote: > > > 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 -~----------~----~----~----~------~----~------~--~---
