> > > For debate: should step #3 apply to scalar properties > > > (boolean, int, double, etc.) or just to object > > > properties? > > > > For consistency if nothing else, also apply this to scalars. > > There's no question that scalar properties will be set (reflection actually > takes care of automatic boxing and unboxing of scalars). The question is > ... should properties be reset (to 0, false or null) after renderComponent() > is invoked?
Yes, reset all properties - both objects (for memory management, and to save the developer from worrying about it), and scalars (to save the developer from worrying about it). > > > For debate: Tapestry can now automate the process of > > > checking for required parameters ... that is, it can > > > enforce that a binding exists and that the binding's > > > value is non-null ... or should this check stay in > > > component code? > > > > I would _LOVE_ for Tapestry to automatically apply the required parameter > > check at render time rather than page loading time. We have had to stop > > using required="yes" on all our 'reusable' components despite our usage of > > those components ensuring that they do in fact have the required bindings. > > If Tapestry were to check these things at render time (and render time > > only), we could put the required setting back, and gain a whole lot more > > confidence in our code. Do it, do it do it! In all seriousness, anything > > that can be done to make initial development of components easier is a > great > > idea - if it means that in order to get more performance out of an app > > you've gotta do a little more coding, so be it - as long as there are > > controls/hooks that allow optimisation. > > In Tapestry today, required means that a binding must be specified. > > In Tapestry tomorrow, required *could* mean that, plus that a non-null value > is acquired inside render(). It seems to me that the page construction binding check is only really useful for 'output' parameters. Input parameters don't really care if they have a binding so much as they care that their binding has a value. The value check is the more useful check IMO - especially given the relative proportion of 'input' parameters : 'output' parameters - both in a real app, and in the Tapesty framework itself. > I know we've covered this before, but could you expand on the problems you > are having today with required bindings? Well, I haven't mentioned the problem with required bindings before as it's really just a side-effect of the way we are using/abusing Tapestry, and trying to find a way around that usage/abusage has seemed more important than the loss of required parameter checking. But that's not to say I wouldn't love to get the required parameter checking back! So, this is what we are doing... (warning - this might go on a bit) We have (I'm guessing) 30-50 business domain objects that need to be manipulated in our Tapestry UI. These are naturally persisted in a DB, and thus require fetching and displaying so the user can choose some to manipulate. Now, we do not want to write 20-50 pages to perform DB fetching/displaying/selecting - even if we had time to create all those pages, we do not want to be maintaining that many pages that all do essentialyl the same thing. So, instead, we have a single page that can fetch from the DB, and display the results. To do this requires two main things to be 'passed' to the seach page - a component that asks for appropriate search criteria, and a component that can display each search result. The way that one passes components around with Tapestry is via the Block/InsertBlock mechanism. These do not work for us because the search page HAS to interact with these components - the fetch component has to set the search results in the search page and the search page has to tell the display component which object to display (inside a Foreach of course). The find/display components need to be defined somewhere other than the search page, so relying on some page property to communicate is not an attractive option, but as far as I could figure out that was the only option for using Block/Insert block. A key ideal I'm chasing with this is that a component should work regardless of it's surroundings - it should not have to know whether its being used on the search page or not, and it should not impose requirements on its surroundings (these applies mainly to the display components which are reused outside of this search/display mechanism). So to allow the communication between page and the search/display components we use modified Block/InsertBlocks that copy bindings around each time they are rendered. And that is the problem - Tapestry doesn't like bindings changing, as it is designed for these things to be done once, and lfet alone thereafter. So our display component has to be defined like this: <component id="displayABanana" type="BananaDisplay" /> - ie. no bindings - as they will be provided when its surrounding InsertBlock variant renders (via the InsertBLock variant's informal parameters). The bindings ARE provided, yet it is not possible to state a parameter as required, because the component definition doesn't have any bindings on its page. Phew. I wonder if that makes any sense?!? Regardless, the required parameter problem is not the big issue here IMO - the bigger issue is having a way to elegantly construct/change bindings during the life of a component. > > > So ... the final question is: when? 2.0.2, 2.0.3 ... or > > > should this wait for the 2.1 series? > > > > 2.1. Even though there aren't any other changes planned, I'd love to see > > the magnitude of the version increment reflect the magnitude of the > change, > > and this is not a 0.0.1 change! > > <major>.<minor>.<incremental> > > Perception. I think the incremental releases represent the accumulation of > changes and bug fixes since the last minor release. When those changes and > fixes are stable, it is time for a new minor release. > > People using Tapestry in production should not chase the incremental > releases, they should be using stable minor (x.x.0) releases. > > I'm beginning to feel that I should follow Jetty's pattern and marking > release candidates explicitly. So the next releases of Tapestry might be > 2.0.2, 2.0.3., 2.1.0rc1, 2.1.0rc2 ... 2.1.0. This sounds good. Just to be sure I am following - if you had applied this system to earlier releases, we'd have: 1.0.0, 1.1.0rc1 (=1.0.1), 1.1.0rc2 (=1.0.2), 1.1.0rc3 (=1.0.3) ... 1.1.0 (=1.0.11/2.0 - OK bad example due to the marketing increment). Actually, I guess there might have been cause for another minor increment in there rather than 10 release candidates. R _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
