Thanks for responding Denis, Your approach (markup writer approach) will get the HTML out and to the client, but it still doesn't help much with problems #1 and #2, right?
As an update to the list, I'l explain what we are having to do to get at least close to achieving #1 and #2. You'll see it's very ugly, from a template perspective. We have an iterator that indicates when a node is being visited and being left (going down and going up the tree, respectively). So, as an example, if there is only one node in the tree, the iterator hits twice--the first time it indicates that the node is being visited, and the second it indicates that the visit is over. We invoke the template of the node every iteration, indicating to the template if it's the begin visit or end visit. Because there is this simple NodeVisitor-like pattern, each component of ours is extended from a base component that defines two extension- points, 'start' and 'end'. Base Component ------------------------ <?xml version="1.0" encoding="UTF-8"?> <t:container xmlns:t="http://tapestry.apache.org/schema/tapestry_5_1_0.xsd "> <t:if test="begin"> <t:extension-point id="start"></t:extension-point> </t:if> <t:if test="end"> <t:extension-point id="end"></t:extension-point> </t:if> </t:container> Here's where it gets ugly... because you have to jump through one hoop or another to avoid malformed markup, this is what our actual component templates look like (the hoop in this case is using outputRaw to serialize the <p> and </p> tags, which can not be written directly into the template because they would make the template malformed): <?xml version="1.0" encoding="UTF-8"?> <t:extend xmlns:t="http://tapestry.apache.org/schema/ tapestry_5_1_0.xsd"> <t:replace id="start"> <t:outputRaw value="literal:<p>" /> a brown fox </t:replace> <t:replace id="end"> runs through field <t:outputRaw value="literal:</p>"/> </t:replace> </t:extend> The output of visiting just that node would be two renderings of the component per node--first the 'start' extension would render, then the 'end' extension. For example, if we had just a one node tree, this would be the flow: start iteration ----------------- <p> a brown fox end iteration ----------------- runs through the field </p> resulting in : <p> a brown fox runs through the field </p> I'm not at all happy with this--but in trying to truly achieve #1 (put all markup in templates), and #2 (have a component for each node type in our tree to take advantage of behavior and modularization), this is the best we've come up with. If anyone has any suggestions, I'd be all ears! Seth On Jun 6, 2009, at 7:12 AM, DenisS (via Nabble) wrote: > Hi Seth, > > I have created Tree component http://pastebin.com/m134af976 for the > same purpose, basically you need to transform recursion to iteration. > > <div class="treeItem" t:type="tree" t:value="treeItem" > t:children="treeItem.children"> > ...tree item body... > </div> > > output will be: > > <div class="treeItem"> > ...tree item body... > <ul> > <li> > <div class="treeItem">...tree item body... <ul><li>...</li></ > ul></div> > </li> > <li> > <div class="treeItem">...tree item body... <ul><li>...</li></ > ul></div> > </li> > </ul> > </div> > > Denis > > This email is a reply to your post @ > http://n2.nabble.com/Stuck-on-implementing-recursion-%28or-something-like-it%29-cleanly-tp3032700p3035136.html > You can reply by email or by visting the link above. > -- View this message in context: http://n2.nabble.com/Stuck-on-implementing-recursion-%28or-something-like-it%29-cleanly-tp3032700p3035508.html Sent from the Tapestry Users mailing list archive at Nabble.com.
