> "Often, the BeanEditForm can create the object as needed (assuming a public, > no arguments constructor). " I believe the java docs are out of date. The change happened in a dependent class and the docs don't reflect the change. As Thiago said, the current strategy is to try to make the most complete object is built based on the available constructors. This lets you build beans that have access to services via constructor injection (like a service).
I think failing to pick the correct constructor is a defect that Tapestry *should* solve. Principle 2 is Adaptive API, which should "adapt to your code". One option is to try them until you get one that works... this could lead to frustration during development if it's not obvious which constructor is getting called... Date has multiple constructors, so this is essentially the same problem. Josh On Tue, Oct 5, 2010 at 8:17 AM, Michal Gruca <michalgr...@gmail.com> wrote: > > I must disagree. > But first to clarify. I described two cases. > 1. BeanEditForm that cannot instantiate my object > 2. Same issue for SSO creating java.util.Date > > AD 1. > Quote from BeanEditForm doc: > "Often, the BeanEditForm can create the object as needed (assuming a public, > no arguments constructor). " > So i provided such constructor in my entity (public no agrs) + I added > another one that taken String and custom enum. What I assumed was that T5 > will just use the one that it can use and leave other one alone. Due to that > behavior no object handled to BeanEditForm should have more constructors > than default one, or should be always created manually, and that is bit more > than user need to do. > > Ad 2. > Quote from linked documentation: > "The first time you access an SSO, it is created automatically. Typically, > the SSO will have a public no-args constructor ... but you may inject > dependencies into the SSO via its constructor, as you can with a Tapestry > IoC service implementation." > In this case I wanted to use Date. Maybe not some real case scenario, so > let's think about shoping basket for example. It may have default no args > for T5 and second one if I want to instantiate it with some products. If T5 > always takes constructor with most arguments it will fail on that scenario > also, meaning that I will have to check boolean variable companion exist on > every page on which I wan't to use my object. > IMHO the best would be try to use no-args constructor or use one with most > args and if You fail try another one and another till You succeed (meaning > reach default no-args or error when there is no default no-args > constructor). > > Regards > Michał > -- > View this message in context: > http://tapestry-users.832.n2.nabble.com/T5-2-Constructor-issue-tp5603058p5603560.html > Sent from the Tapestry Users mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > > -- -- http://www.bodylabgym.com - a private, by appointment only, one-on-one health and fitness facility. -- http://www.ectransition.com - Quality Electronic Cigarettes at a reasonable price! -- TheDailyTube.com. Sign up and get the best new videos on the internet delivered fresh to your inbox. --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
