Interesting, I hit this same wall a while ago when trying to render a
tree. It seems to be a common occurrence, so supporting it in the
framework would be highly desirable. I ended up doing almost all the
rendering in Java code, using the template only to hold blocks which I
called to render from the Java code. This allowed me to at least specify
some "blocks" of HTML in the template, rather than doing it all in code.
Damien
> I couldn't believe it, so I made an example. And I had to discover that
> it is true:
>
> org.apache.tapestry.ioc.internal.util.TapestryException
> The template for component example.recursive.components.Node is
> recursive (contains another direct or indirect reference to component
> example.recursive.components.Node). This is not supported (components
> may not contain themselves).
>
> I consider this a bug that has to do with the alpha state of T5.
> Otherwise I have doubts on the usefulness of T5 at all.
>
>
> 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.
>>
>> 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]
>>
>>
>>
>
>
> --
> SPRICOM Informatik GmbH
> Firmensitz: Brucknerstraße 29, 53721 Siegburg
> Registergericht: Amtsgericht Siegburg, HRB 8808
> Geschäftsführer: Hans Jörg Hessmann
> http://www.spricom.de
>
>
>
> ---------------------------------------------------------------------
> 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]
