Hi Kris, Thanks, I'll try reopening the issue. From your work on refactoring the code, do you think the changes that will be needed so solve the problem are reasonably isolated?
Doug > -----Original Message----- > From: Kristian Marinkovic [mailto:[EMAIL PROTECTED] > Sent: Monday, November 17, 2008 1:28 AM > To: Tapestry users > Subject: Re: Changing the behavior of short-circuiting render phases > (re: TAP5-128, TAP5-126) > > hi doug, > > all we can do is to reopen the bug and vote for it ... :) > > <IMHO> > > i guess one of the reasons why this issue does not get resolved > is the added complexity to the page rendering. first because the > responsible class ComponentPageElementImpl is already very > complex (>1000 loc) and it would be necessary to add some state > information to the rendering process. currently the rendering is > completely stateless only relying on the static structure of the page. > > i've started to refactor ComponentPageElementImpl just to see > how it could be solved.... > > </IMHO> > > g, > kris > > > > > "Doug Hauge" <[EMAIL PROTECTED]> > 15.11.2008 01:57 > Bitte antworten an > "Tapestry users" <users@tapestry.apache.org> > > > An > "Tapestry users" <users@tapestry.apache.org> > Kopie > "Doug Hauge" <[EMAIL PROTECTED]>, "Adam Ayres" > <[EMAIL PROTECTED]>, "Matt Ayres" <[EMAIL PROTECTED]> > Thema > Changing the behavior of short-circuiting render phases (re: TAP5-128, > TAP5-126) > > > > > > > > > As of Tapestry 5.0.16 (after the fix for TAP5-128), we are now running > into > a problem related to that described in TAP5-126. You closed the TAP5- > 126 > issue > saying that the code was behaving as documented and designed, but it > seems > that this behavior leads to problems when trying to implement generic > mixins > that can safely be added to arbitrary components. I'd like to check > whether > there is any possibility of convincing you to change the behavior so > the > reverse phases of a component/mixin are only called if the positive > phase is > for the same component mixin (e.g. a component's cleanupRender is > called > if > and only if the component's setupRender was called). > > It also seems odd that returning 'true' will cause other methods within > the > same phase to be bypassed. There thus seems to be no way according to > the > documentation at > http://tapestry.apache.org/tapestry5/tapestry-core/guide/rendering.html > to design a mixin that will either short-circuit or continue rendering > as > if it didn't exist. The Tapestry code still seems to allow the behavior > we need by declaring the render phase method to return 'Boolean', and > return > 'null' instead of 'true' to continue processing. However, unless I am > missing > something obvious, this is not documented behavior, so it is not clear > that > I can rely on it continuing to work. > > The fundamental problem with the short-circuiting behavior as > documented > is > that if a mixin short-circuits a render phase by returning either true > or > false, any component that contains it must be carefully written so it > can > handle it. Consider a component > > class Component { > > void setupRender() {} > > void beginRender() {} > > void afterRender() {} > > void cleanupRender() {} > } > > Where 'setupRender' constructs some objects from the component > parameters, 'beginRender' begins > an HTML element, 'afterRender' closes the HTML element, and > 'cleanupRender' cleans up. > > And a mixin > > class Mixin { > Boolean setupRender() { ... } > > Boolean beforeRender() { ... } > > Boolean afterRender() { ... } > > Boolean cleanupRender() { ... } > } > > We are returning 'Boolean' here instead of 'boolean' so we have the > option of not short-circuiting > anything. If this is not considered supported, instead of returning > 'null' in the examples below > simply remove the render phase method from the mixin. > > 1) If 'Mixin.setupRender()' returns 'true', then > 'Component.cleanupRender()' is not called because > the phase is short-circuited, but 'Component.beginRender()' is called, > so 'Component.beginRender()' > would have to be written in such a way that it handles when > 'Component.setupRender()' is not called. > > 2) If 'Mixin.setupRender()' returns 'null', but 'Mixin.beforeRender()' > returns 'false', then rendering > is short-circuited to the after render phase and > 'Component.beforeRender()' is not called. However, the > 'Component.afterRender()' method is called, so it would have to be > written in such a way that it handles > The 'Component.beforeRender()' not being called, in this case it would > have to create a property that > records whether the HTML element was started, and only add an end tag > if > it was. > > Thus, in the most general case, each render phase in the component > would > have to be written assuming > that any subset of its previous render phase methods may not have been > called, which leads to overly > complicated code. > > Doug > > > > > > > > --------------------------------------------------------------------- > 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]
