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]
