I think this issue is a moot point. But I will say that the tree example is a perfect example because of it's nature.
> Any tree can be easily walked through like a list, > but then rendered (indented) to look like a tree to the user. Of course it can. That's not really the point. The point is that it is far more complex, verbose, and therefore error-prone. Using recursion to create a tree is the "best" way in these terms. If recursion existed you wouldn't even need a "tree component". You could just create a component that deals directly with the problem domain (domain object) and have it recurse on itself to do any number of things - in this case, create a tree - with such minimal difficulty. Here we are forced to create a framework (a tree component) simply to display a tree. It not a question of whether it's possible to do recursive work iteratively. It's simply a question a why - why do something that is so simple via a recursive algorithm in a far more complex iterative manner. I know this is "principle 1", and its is the Tapestry way, and etc. I'm still failing to see the major difference between a loop (iterative) and nested components (recursive). In both cases the actual number of components displayed is determined at runtime. In the case of the loop we know that some combination of components (within the loop) will be displayed some number of times at runtime. With recursion we still know both of these things. So, I still need to explore where the relevant code is, but my gut is telling me there should be some work around to allow recursion as a depth bound process (compared to the loop's breadth bound) - for lack of better words. If you love the iterative approach, by all means go ahead and work that way. If, on the other hand, you feel that recursion is the right tool for these types of jobs and shouldn't be supplanted with alternative iterative approaches with excessive code. No, it's not science fiction, rocket science, or any extremely complicated stereotype to perform recursive work iteratively. It is simply more work than it should be. On 8/23/07, Davor Hrg <[EMAIL PROTECTED]> wrote: > I can't really see why is not having recursive components > such a problem. > > Any tree can be easily walked through like a list, > but then rendered (indented) to look like a tree to the user. > > So, rendering recursive data, like BeanEditForm should be > no science fiction. Like any other thing, providing a good > example can suffice. Using recursiive component to create > a tree is the first thing we can think of, but it doesn't mean > it's the best way. > > Davor Hrg > > On 8/22/07, Francois Armand <[EMAIL PROTECTED]> wrote: > > > > Hello Todd, > > > > Todd Orr wrote: > > > I'm also trying to perform this type of recursive structure. I don't > > > agree that this makes anything simpler. Recursion is a powerful and > > > concise tool for these situations. I will say that it is often abused, > > > but this is a perfect use case. A recursive solution to this problem > > > is far simpler and maybe more "correct" than this iterative approach. > > > > > > > I read again my post and saw that I didn't express myself properly (put > > it on my low level in English). > > I should have write :"The non-support of recursive structure seems to > > bring a lots of simplification with it _for Tapestry internal, > > replication and performance problematics_". It seems to be a design > > choice, and as I'm not a Tapestry developer, I can't explain exactly why > > it was done, even if replication/pool of pages seems to be around. I > > came from functional programming projects where this kind of structure > > is quite common, so personaly, I find that it's a real lake. > > > First off, the proposed solution requires complicated logic. Fine, > > > it's not rocket science, but the recursive alternative (if there was > > > one in tap) is far easier to read and understand. From a > > > tech-management point of view the simplicity of the code is a major > > > factor in its long term maintainability as well as its bugginess. > > > > > > Secondly, the proposed solution requires adding raw HTML output to > > > code. This may be a more esoteric and arguable point, but Tapestry > > > excels in having a clear and easy to use separation between the > > > view/presentation and the logic components of the application's > > > construction. Again, with regards to maintainability, it is twice as > > > hard to maintain code if the concerns are spread throughout > > > conceptually separate pieces of code. > > > > > If you look at the source code for "for" component, you will see that it > > is far from being trivial. It also deals with raw output, and different > > case are need if the loop is in a form or not... But the use of "for" > > component is quite simple. You could design a "Tree" component that > > handle this stuff and just use it elsewhere in a simple way. with a > > clear separation between template using this component and the > > component. It's what I did in a tree component : > > > > http://svn.forge.objectweb.org/cgi-bin/viewcvs.cgi/interldap/interldap-wui-t5/trunk/src/main/java/org/interldap/wui/tapestry/components/Tree.java?view=markup&rev=97 > > > > > Third, this approach makes it impossible for any "node" in the tree to > > > contain any non-trivial nested components. I see that you can create > > > links...wow. Kinda limiting if you ask me. This limits the usefulness > > > and extendability of the code. If more complex functionality is > > > required (lets say by a major client or some other critical business > > > need) within this pseudo-recursive implementation it might force the > > > developers to completely switch out frameworks to one more suitable > > > for the job. This is a huge risk from a business perspective. > > > > > Ok, so here, the problem is that the tree component is not well designed > > (or not as much generic as it should be). Perhaps a real tree component > > in standard lib would be good. But it has little to do with the lack of > > recursion structure, that is painful. A tree structure would be (at > > best) a bypass for this lack. > > > > -- > > Francois Armand > > Etudes & Développements J2EE > > LINAGORA SA - http://www.linagora.com > > Tél.: +33 (0)1 58 18 68 28 > > ----------- > > InterLDAP - http://interldap.org > > FederID - http://www.federid.org/ > > Open Source identities management and federation > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
