I realized that what we really need is the concept of a rendering context for scenarios such as this:
Put comma after the end of very child rendering, except those that result in empty content and the last node, to ensure valid data structure output. I played around a little... first I thought about using a stack. One could have a global stack which you would push on as you went down the tree and pop from as you came back up. That way children could access context info that their ancestors had set. You cold also just set an extra argument on the function call, as functions inherently work as a stack with their arguments... but I thought, why have this limit of a ancestor->child context. Why not have ancestor<-->child context? I played around with having a tree structure for this, first using nested hash maps. I later discovered rubytree http://rubyforge.org/projects/rubytree/ For more complex scenarios you need easy traversal of the context tree up and down etc. So why not use this!? Also rubytree takes content of any kind on each node :) The name of each node could be the tag name. So fx a cell node in a table could travel up the context tree to find the first ancestor of type "table" and use its context info to render itself. To build on this I could imagine an über-context, or just some global vars to say how the context in general should behave. One idea is to use this for gathering rendering sats. So you might set: uber_context = {:logging => true, :count_tags => true, :performance_stats => true} or sth similar. Then a diferrent rendering class (to avoid this complex logic in simpler cases and maintain higher speed) would be loaded/constructed, where the content for each context node would be populated with fx a :total_tag_count (of the subtree) and a count of each type of tag encountered in the subtree. Same could be done for rendering_performance of each type of tag in subtree and total rendering_time. This could be useful for debugging!? Just playing with ideas for what COULD be done. If DRYM was used completely outside the realms of rendering, fx tags making calls to external services or checking if links are valid, you might have certain subtrees which you want to be skipped because previous subtrees took too much time or a subtree contacting services "out of service" (broken links or some other HTTP error!) should be skipped... I could also imagine this kind of usecase <x> <y stats="on"> ... <a stats="off"> ... </a> </y> ... <b stats="on"> ... </b> </x> So you could potentially turn "stats gathering" on and off selectively on a subtree ;) Back to my original example. Using this context, a child could add {:empty => true} to its context and the parent node could use this info, fx in my case to decide, whether to render a comma or not before the node, to render valid data structures (in Javascript - ExtJS widgets). Suddenly what was hard and required an ugly hack before becomes very easy! Suddenly DRYML has made a leap so that it is not designed strictly for rendering HTML but can be used in lots of other scenarios. Your imagination might be the only limit!!! What do you think? Kristian --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Hobo Users" 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/hobousers?hl=en -~----------~----~----~----~------~----~------~--~---
