Re: Dynamically Processing Nodes
"Diez B. Roggisch" <[email protected]>
| Newsgroups | gmane.comp.java.enhydra.barracuda.general |
|---|---|
| Message-ID | <[email protected]> |
Hi, > Lets see if I have it correctly. > You are saying that we should take the existing 'tree' structure, > create a list from it and then render the rows from this list. > > If my interpretation is correct, then the rows would know in which > order they must be rendered but not how the hierarchy should look. > Therefore, I dont think this approach would work. > I think that the hierarchy problem can be solved by some type of > recursive functionality. > Is there not, perhaps, a recursive model (wishfull thinking) ? The recursion takes place when flattening the tree - in Kirks example, you then had to annotate the list items with context information like depth from this recursive decent. The reason for that was that Kirk had a linear table structure - no hierarchies there, only colspan/rowspans to indicate indentation and the like. So - you _have_ to break down things to a list. Now if you have actually hierarchies of objects to render and that strucure is reflected in the markup - then you go with parent-child models. Werner Koch just gave you an example how that works. Basically, for every level of your tree you have one model. His example has two levels, but you can have an arbitrary number of them. These models communicate, so the inner model gets notified of a new list of objects to render if the parent model approaches a new object with childs in it. Usually thats sufficient - its difficult to render content that has random depths. But of course one might think of such an example - e.g. a site-map. If you need to render such a thing, you should go for a custom component that will insert markup recursively. You for example do that kind of stuff using BLists. AFAIK this has been done before. Please keep in mind that BTemplate is about heavily layouted stuff - your designer gives you HTML that is suitable for lets say three levels. Just stuffing recursively the same template into itself won't result in predicable output - which is what we are after, at all :) Did that help? Diez