You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Harish Krishnaswamy <hk...@comcast.net> on 2003/10/28 04:06:42 UTC
[Fwd: Re: Tapestry: design decision against component recursion?]
The previous one is lost in the web, I guess ;)
-------- Original Message --------
Subject: Re: Tapestry: design decision against component recursion?
Date: Mon, 27 Oct 2003 21:32:12 -0500
From: Harish Krishnaswamy <hk...@comcast.net>
To: Tapestry development <ta...@jakarta.apache.org>
References: <00...@mmlap>
This certainly is a very tricky problem. May be the solution is to
completely forbid recursion (both direct and indirect). May be I am not
getting the point but if it is going to be statically limited why can't
the Foreach be used instead? I am not sure if an adaptive approach is
feasible without some big changes, because at the time of loading the
page the bindings are only setup (not evaluated) so the actual values of
the bindings are unknown.
-Harish
Michael Müller wrote:
>A temporary workaround would be to statically limit the nesting
>depth during page/component loading. The maximum allowed nesting
>depth could be a configurable property. I admit this workaround
>is quite ugly as the maximum, in some way, has to correspond with
>the max. nesting level of the recursive data that is to be rendered
>(i.e. a tree structure). In case that the maximum is actually hit
>when the bindings are evaluated, there would have to be a warning
>message that the user probably should increase the maximum. (Even an
>adaptive approach comes to mind, where the maximum would be increased
>dynamically. Don't know if that would be feasible.:-?)
>
>
>I did some tests with this approach and it seems to work so far,
>at least with "simple" recursive components which directly reference
>other instances of themselves. I'm not confident that it works with
>a setup like the one that Geoff mentioned: X refers to Y refers
>to X. But I would be quite happy to have at least support for
>these "simple" recursive components in Tapestry. :-)
>
>Probably this workaround would not impact on the other users who
>don't use recursive components for now as it would not require
>any API changes. (I don't know about Geoff and Spindle, as I
>don't use Spindle (yet).)
>But you could even make this an optional feature that explicitly
>has to be activated via properties, so that the regular users
>would certainly not be affected.
>
>So, what do you think about such a (quite homogeneous) mini-extension?
>
>Regards,--micha
>
>--
>Michael Müller (mm@mmicha.de)
>
>
>
>>-----Ursprüngliche Nachricht-----
>>Von: mm@condat.de [mailto:mm@condat.de]
>>Gesendet: Montag, 27. Oktober 2003 20:34
>>An: mm@mmicha.de
>>Betreff: [Fwd: RE: Tapestry: design decision against
>>component recursion?]
>>
>>The idea that a component template could have a reference to
>>to another
>>instance of itself. I.e.
>>
>>Foo.html:
>>
>><span jwcid="@Foo"/>
>>
>>
>>Apparently, WebObjects allows this in some way. Because of
>>how Tapestry
>>creates and manages page instances (it builds them top to bottom,
>>including parsing templates) the above would result in an endless
>>recursion.
>>
>>At the very least, we probably need to add checks to prevent
>>endless loops
>>when someone attempts to do this.
>>
>>--
>>Howard M. Lewis Ship
>>Creator, Tapestry: Java Web Components
>>http://jakarta.apache.org/tapestry
>>http://jakarta.apache.org/commons/sandbox/hivemind/
>>http://javatapestry.blogspot.com
>>
>>
>>
>>>-----Original Message-----
>>>From: Geoff Longman [mailto:glongman@intelligentworks.com]
>>>Sent: Monday, October 27, 2003 6:54 AM
>>>To: Tapestry development; 'Michael Müller'
>>>Subject: Re: Tapestry: design decision against component recursion?
>>>
>>>
>>>What is meant by "component recursion"?
>>>
>>>Geoff
>>>----- Original Message -----
>>>From: "Howard M. Lewis Ship" <hl...@comcast.net>
>>>To: "'Michael Müller'" <mm...@mmicha.de>; "Tapestry-Dev"
>>><ta...@jakarta.apache.org>
>>>Sent: Sunday, October 26, 2003 9:37 PM
>>>Subject: RE: Tapestry: design decision against component recursion?
>>>
>>>
>>>This is a completely appropriate discussion for the
>>>
>>>
>>developer's list.
>>
>>
>>>HiveMind is "more perfect" than Tapestry because I've learned
>>>so much in the last four years. If I started Tapestry from
>>>scratch today, it would look much different ... but there is
>>>already a user base of Tapestry that is put in agony with
>>>each new, incompatible change ... not to mention Geoff and Spindle.
>>>
>>>So, recursive templates are difficult today, yes, but the
>>>question is how to allow for a recursive approach without
>>>impacting the 90+% of users for whom this is not an issue?
>>>
>>>--
>>>Howard M. Lewis Ship
>>>Creator, Tapestry: Java Web Components
>>>http://jakarta.apache.org/tapestry
>>>http://jakarta.apache.org/commons/sandbox/hivemind/
>>>http://javatapestry.blogspot.com
>>>
>>>
>>>
>>>>-----Original Message-----
>>>>From: Michael Müller [mailto:mm@mmicha.de]
>>>>Sent: Sunday, October 26, 2003 7:31 PM
>>>>To: hlship@comcast.net
>>>>Subject: Tapestry: design decision against component recursion?
>>>>
>>>>
>>>>Hello Mr. Ship,
>>>>
>>>>I address you directly because I'm not sure whether you
>>>>would have taken offense if I asked on the Tapestry
>>>>
>>>>
>>>developers mailing
>>>
>>>
>>>>list. Last year I had to do a J2EE project as a part-time
>>>>
>>>>
>>>freelancer
>>>
>>>
>>>>where I chose Struts for the presentation layer. Bad
>>>>
>>>>
>>>decision(!), as
>>>
>>>
>>>>this brought me almost physical pain during the development
>>>>
>>>>
>>>process.
>>>
>>>
>>>>Having 5 years of experience with WebObjects I was aghast at how
>>>>
>>>>
>>cumbersome web development can be. (Probably I forgot about
>>
>>
>>>>my early Perl and ASP days ;-)) So I swore myself to never
>>>>use that stuff again, if possible. But now that WO somewhat
>>>>loses its perspective, I'm considering a transition to a free
>>>>OpenSource web framework. As Tapestry is sometimes described
>>>>as "what WO5.0 should have been" (you certainly like Drew
>>>>Davidson's statement ;-)), I was certain that this was the
>>>>way to go. As a result, I instructed one of the trainees at
>>>>the company I work at to do some evaluation work on Tapestry
>>>>to check it out. He got along well until he had to migrate
>>>>our standard tree reusable, where he stumbled over the
>>>>"recursion problem". At first, I couldn't believe that
>>>>component recursion could be a problem in Tapestry. But after
>>>>some investigations in newsgroup archives and a quick look at
>>>>the source of the PageLoader class, I learned that:
>>>>* There is indeed a problem with recursive components because
>>>> during the page loading process PageLoader tries to build a
>>>> static representation of the whole component tree but has no end
>>>>
>>>>
>>condition for the recursion.
>>
>>
>>>>* "Recursive rendering could be a bit tough."
>>>> and "Block and RenderBlock are the way to go."
>>>> (your statements in:
>>>>
>>>>
>>>>
>>>http://www.geocrawler.com/mail/msg.php3?msg_id=9746124&list=19561)
>>>
>>>
>>>>I agree with Viktor (Szathmary (?)) from
>>>>
>>>>
>>>>
>>(http://www.geocrawler.com/mail/msg.php3?msg_id=9751130&list=19561)
>>that his recursion solution which is also used in the
>>
>>
>>>tacos-tree (?)
>>>
>>>
>>>>"is not very flexible/maintainable, since i'm not using a
>>>>
>>>>
>>tapestry
>>html template...".
>>
>>
>>>>Now don't get me wrong. Apart from this I'm convinced that
>>>>
>>>>
>>>Tapestry is
>>>
>>>
>>>>the web framework of choice, because it gives me the fewest pain
>>>>
>>>>
>>compared to the other ones and I'll do my very best to convince my
>>boss at my company that action-based frameworks like Struts are NOT
>>the way to go.
>>
>>
>>>>But I would like to understand if it was a kind of design
>>>>
>>>>
>>decision
>>that the naive way of using template recursion like in WO
>>
>>
>>>is not the
>>>
>>>
>>>>currect approach to do recursion in Tapestry. Or if it was just a
>>>>
>>>>
>>(maybe unwanted) consequence of another design
>>
>>
>>>decision/premise that
>>>
>>>
>>>>was made during Tapestry development.
>>>>
>>>>As you certainly know, WO solves the problem via a
>>>>
>>>>
>>>reference object to
>>>
>>>
>>>>the subcomponent which is only dereferenced dynamically
>>>>
>>>>
>>during the
>>render/rewind phase(s). For now, I know too little of the Tapestry
>>innards to comprehend whether this could also be a feasible
>>
>>
>>>approach
>>>
>>>
>>>>in Tapestry or not. And in case that it wouldn't, why
>>>>
>>>>
>>that would be.
>>
>>
>>>>How would you personally solve the task of rendering recursive
>>>>
>>>>
>>structures? Would you really use Block and RenderBlock?
>>
>>
>>>>In your Blog you recently stated that "a good framework
>>>>
>>>>
>>should make
>>the easiest approach the correct approach".
>>
>>
>>>>(http://javatapestry.blogspot.com/2003_09_28_javatapestry_arch
>>>>
>>>>
>>>ive.html)
>>>Wouldn't you agree that the approaches that these two guys
>>>took, are the easiest ones? :
>>>http://article.gmane.org/gmane.comp.java.tapes> try.user/3289
>>>
>>>
>>>
>>>
>>http://article.gmane.org/gmane.comp.java.tapestry.user/4129
>>
>>So, again, please don't take offense at this mail. I just want to
>>understand what the real problem is with recursive
>>components, whether it
>>could be solved in a kind of WO-like way and what would be
>>the common/best
>>solution at this time.
>>
>>Best regards,
>> --Michael Mueller
>>
>>--
>>Michael Müller (mm@mmicha.de)
>>
>>
>>--------------------------------------------------------------
>>------- To
>>unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org For
>>additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>>--------------------------------------------------------------
>>------- To
>>unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org For
>>additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>>--------------------------------------------------------------
>>------- To
>>unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org For
>>additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>>
>>
>>
>>
>>
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
>For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
>
>
>
>