----- Original Message ----- From: "Richard Lewis-Shell" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]>; "Tapestry Developer" <[EMAIL PROTECTED]> Sent: Thursday, April 25, 2002 6:16 PM Subject: Re: [Tapestry-developer] Massive change to parameters / bindings
> > 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? I'm mostly concerned about memory management which is why I'm thinking that just object properties need to be cleared. > > > 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(). I know we've covered this before, but could you expand on the problems you are having today with required bindings? > > > 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. _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
