> > Hi all, > > I haven't yet posted to this list, although I have been lurking for quite > some time now and managed to turn a certain Dirk O. and Christian N. into > Tapestry fans - not to mention a customer. :-) > I'm also an old WO user, just like a seemingly increasing number of people > who feel the need to come out of their WOCloset here..but on with the > show:
Its been so long since I've used WOF (3 or 4 years); it would be good for a more systematic comparison. Unless Apple's improved things, Tapestry has WOF beat in a few areas, I think (such as templates). > > > > > (lots about automagic binding) > > > > For debate: should step #3 apply to scalar properties > > (boolean, int, double, etc.) or just to object > > properties? > > If possible, yes please. scalar values are just so nice to have instead of > the wrapper types, and AFAICS everything is already in place, so why not? Boxing and unboxing scalars is already handled nicely by reflection. This is about clearing out properties after renderComponent() is invoked. I've discussed it in another posting. > > > 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? > > IMHO whether a parameter is required or optional should be attribute of > the components' API. The component designer should be able to specify > which parameters are mandatory and/or optional. Makes it easier for a tool > to check a component for consistency, too. > > > There will be a small loss in efficiency. Tapestry > > Ignore it (at first, at least). > And this from someone who lives for performance! :-) Tapestry does have a required flag for parameters, but that just checks (at page construction time) that a binding is specified. Under the new scheme, Tapestry could also check that the binding provides a non-null value. > > > The plus side is that the codebase will shrink a bit. > > Significantly! Isn't that the most important aspect? Like you said, > futzing with bindings is counterintuitive and also..tiresome. More code == > more bugs. Code is evil. "Less code == good" is my mantra. > > > It should be pretty obvious that the new code is far > > more desirable. Note that none of the gobbledygook > > about static bindings is needed anymore ... if its > > static, it is set once and not changed. If it is > > dynamic, it is set before renderComponent() and cleared > > after. > > Yes. It would also make it easier for Spindle to update Java Source and > bindings in sync, just like a certain commercial program that shall remain > unnamed here. Yes, that's a good point. Spindle could create appropriately typed JavaBeans properties on the component Java class. > > > I'm really warming up to this change. Given that > > Tapestry is a component-based framework, it makes sense > > that making components easier to construct is a win on > > both the coding and marketing side of things. > > Yes, although Tapestry already is a very convincing 'sell' once you start > showing some JSP lump. :) Dirk told me about that! I need more time for Tapestry and a lot more time for Sabertooth. I'm forced to do work using JSPs and Struts under WebLogic of late. JSP tag libraries are a poor substitute for a real component; someone compared them more to a C macro. > > > So ... the final question is: when? 2.0.2, 2.0.3 ... or > > should this wait for the 2.1 series? > > IMHO keep 2.0 stable, new bindings for a 2.1 branch. Break everything! > I'm still of the thinking that 2.0.2, 2.0.3 will be leading up to a 2.1.0. At some point, it may be time to adopt a branch strategy for dealing with these code changes. As soon as other folks really step up to the plate and start coding Tapestry, it will be time. > Holger > -- > Holger Hoffst�tte > Daedalos Consulting GmbH > Ruhrtal 5, 58456 Witten, Germany > http://www.daedalos.com/ > > _______________________________________________ > Tapestry-developer mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/tapestry-developer > _______________________________________________ Tapestry-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/tapestry-developer
