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] > >
