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]
