Yeah ... I didn't say this in my earlier post, I understand having multiple
methods to allow for easier upgrades. But after suitable discussion and
opportunity for users to try in the field, "one" correct method should be
chosen with the other options available as a optional plugin. Realistically
once you have thoousands of components written migrating to the latest "one"
true way is a pain-in-the-ass, no-value-added hassle that forces established
tapestry installations to stay with old versions -- so that optional plugin
is only optional from a "decision to use it" perspective not a "decision to
build it" perspective.
Ideally, we really want people to be able to move easily from Tap3 to Tap5.
And if it is not super easy many developers will never be able to convince
their managers that it is worth the hassle.
-Pat
On 1/28/07, RonPiterman <[EMAIL PROTECTED]> wrote:
Martin Strand wrote:
> No, leaving the decision up to the developer is not a solution at all.
> Tapestry should have one proper way to do things and if someone is not
> satisfied with it they can use a 3rd party lib that provides the
> functionality they need. This will also reduce confusion for newcomers.
> I'd prefer o leave parameters as they are (ie
> parameters={"color=color"}) but the most important thing is that there's
> one "proper" way to do things.
I thought to keep out of this discussion, but I couldn't help it:
Yes, where its possible: one way to do things. taking the xml out is a
bless, now one can define components in "only" two ways instead of 3...
but I would vote for the (until now unpopular) binding:
@Bindings([EMAIL PROTECTED](name="...",value="...")})
but I guess noone (except me) likes that extra typing... :(
Cheers,
Ron
I hate typing I am not Sam G :-)
