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.
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.
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.
While I think these points are painful enough on their own, it does
raise some questions about the framework's usefulness in specific
situations. My main concern is in relation to CMS features. Many
applications require support for some level of features that would be
considered CMS functionality. This static structure imposed makes
creating dynamic sites, well, painful. When you are attempting to
build an application that must adapt to known types of "runtime" or
user-configuration driven alterations that have many variants during
runtime (eg. depth of a tree, etc.) the static structure is limiting.
Tapestry is a great framework. However, the intention of the static
structure, while clearly advantageous in many respects, limits the use
case coverage for the framework at worst and makes certain otherwise
easy tasks very difficult at best.
Perhaps the rules for the static structure could be allowed to bend
from time to time as a nod to those of us that do require greater
flexibility. I'm sure this is easier suggested than done, but what are
the options?
On 7/17/07, Francois Armand <[EMAIL PROTECTED]> wrote:
> Dmitry Sidorenko wrote:
> > Hi all.
> >
>
> Hi,
>
> > In my project I need to generate edit form for a class like this:
> >
> > class Section{
> > List<Section> subSectionList;
> > List<Field> fieldList;
> > }
> > [...]
> > Probably I'm doing something wrong, maybe my task should be done in
> > completely different manner.. Any ideas?
> > Is there any way to develop visual editor for such a recursive classes?
> I don't know how T4 works, but if it's like in T5, their is no support
> of recursive template/class.
> So, for tree structure, you have to use a non-recursive algorithm (I
> think that in your example, you wish to use a non-recursive preorder
> traversal).
> It's not really natural, but the non-support of recursive structure
> seems to bring a lots of simplification with it.
>
> You can look at this How To entry :
> http://wiki.apache.org/tapestry/Tapestry5HowToCreateYourOwnComponents
>
>
> I wish it would help.
>
> Francois
>
> ---------------------------------------------------------------------
> 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]
