Hi, Kaspar. Hope you had a good weekend.
Bringing up this Transform action block environment issue again because I've
been struggling with it all week.
I've scrapped the idea of transforming my parse tree directly to a Nokogiri
node tree and instead I've created my own AST classes. That feels good. No
need for an instance variable (@doc) in the transform. Much cleaner.
Here's what's been hanging me up: My elements attributes come in in an array
of hashes, like: [{:class => "myclass"}, {:align => "left"}]. There's no way
around this because these attributes can come in any order, repeat, split
around other attributes, and aggregate. Anyway, I have a function that
merges these hashes according to certain rules. The output is then a nice,
pretty {:class=>"myclass", :align=>"left"}. I tried putting this in an AST
class, so you feed the crap into the AST and it sorts it out before storing
it in an instance variable. This felt icky, especially when deciding where
to test it.
If the Transform is really all about sorting out the crap the parser
generates into something nice and clean, my method to sort out those
attributes should be in the Transform, and indeed, it feels much better
there. The only problem is that the method needs to be applied in multiple
rules, so it needs to be a helper method outside the action block. This
necessitates a predictable context, which brings me back to the patch I
proposed.
Take a look at
https://github.com/jgarber/redcloth-parslet/blob/61bae3c7be36bb92f6da5d253a94582c2798de47/lib/redcloth-parslet/transform.rb
Am I doing it wrong? Do you have suggestions for doing what I want to do
within the existing confines of Parslet::Transform and yet avoid smelly
code?
Many thanks in advance for your help!
Jason
On Tue, May 10, 2011 at 11:44 AM, Kaspar Schiess <[email protected]> wrote:
> Hi Jason,
>
> > I get what you're saying about Transforms. I sensed it before and
> > resisted it, but now I really can't deny it. :)
> Come to the dark side ;)
>
> > So, Kaspar, perhaps in the documentation you'll find a way to downplay
> > the context of Transforms and communicate that in Parslet, parsing and
> > transformations go together like lexing and parsing, no? What you just
> > told me would be a great start:
> >
> > Transformations are good for one thing: Getting out of the horrible
> > Hash/Array/Slice mixture into the realm of your own AST classes
> > easily. Usually, no state is associated with that operation.
>
> I am keeping track of this here:
> https://github.com/kschiess/parslet/issues/40
> https://github.com/kschiess/parslet/issues/39
>
> Thanks for nudging me!
> kaspar
>
>
