You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship" <hl...@comcast.net> on 2003/10/27 03:37:25 UTC
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.tapestry.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
Re: Tapestry: design decision against component recursion?
Posted by Geoff Longman <gl...@intelligentworks.com>.
Spindle will detect this. (can't recall if I'm putting up an error - the
hook is there).
>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.
Spindle builds the same way Tapestry does.
What happens in Tapestry if X refers to Y refers to Z refers to X? Spindle
might tank or succeed in certain cases but right now it notices this and
stops processing X.
----- Original Message -----
From: "Howard M. Lewis Ship" <hl...@comcast.net>
To: "'Tapestry development'" <ta...@jakarta.apache.org>
Sent: Monday, October 27, 2003 7:19 AM
Subject: 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"/>
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
Tree component
Posted by tsvetelin <ts...@rushmore-digital.com>.
Hi All,
I have planed to commit the Tree component after releasing the version 3.0.
But I see that the version is delayed in time. At the other hand a few
people have questions about the old version of the tree in tacos project.
There are a few improvements features in the version for contrib library.
So I would like to commit it in contrib now.
Any comments?
Tsvetelin
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
RE: Tapestry: design decision against component recursion?
Posted by "Howard M. Lewis Ship" <hl...@comcast.net>.
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
Re: Tapestry: design decision against component recursion?
Posted by Geoff Longman <gl...@intelligentworks.com>.
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.tapestry.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