Eelco Hillenius wrote:
> A major issue in the discussion is that not everyone is convinced
> anymore that the constructor change in 2.0 is for the better. There
> are pros and cons for sure, but we want to get your opinion on this.
I'm a committer, but I'm also a user, and I feel pretty strongly about
this on both fronts. Apologies that this is a bit long. I've tried to
condense it a bit, but there are a lot of things to talk about. :-)
The constructor change effectively means that for a big project you'll
need to almost completely rewrite it to go from 1.x to 2.0 - there will
be lots of fundamental logic changes. This seems misguided at best, for
the following reasons...
1.x is not going to go away. With all the recent buzz, we now have an
awful lot of 1.x users with growing code-bases (I'm one of them). Not
providing all these users with a sensible upgrade path between versions
is a big mistake, IMO. Users of Tapestry often complain that each big
version is such a big API break that they effectively have to start from
scratch each time. We surely don't want to make the same mistake?
Because 1.x isn't going to go away, people will want bugs fixing and new
features adding on that branch. 1.x isn't going to go into "maintenance
mode" any time soon - we'll have to continue to support two very active
branches for months and quite possibly years to come.
Dividing effort and duplicating everything like this is a terrible waste
of developer resources. I've no idea what quantitative impact it has/
will have, but I'd bet it's very large (25% or something).
We're also less likely to attract people who want to work on the project
either as core committers or JIRA patch providers if they need to
effectively do their work and testing twice. The fork already annoys me
no end, and I'd definitely be inclined to fix more bugs if it wasn't
like that.
If we have two active branches, they'll each be (on average) half as
well tested in real world applications. This seems like a bad idea, for
obvious reasons.
Most developers seem to have live or near-production systems running on
1.3, so they are often scratching that itch first, and have limited time
to forward port things to 2.0. This means that things lag a bit and make
bug reporting and the like more of a hassle. I've lost track of the
number of times someone has had to ask "which branch are you using?" in
response to a bug report. I also sense that users are already getting
frustrated with people saying things like "ah, yes, that's fixed on the
other branch".
So why did we do the constructor refactor? The argument for javascript
IDs seems reasonable, but I'd counter it with two things:
- You can use a unique ID instead to get around the problem (in fact,
maybe setOutputMarkupId() should use a globally unique ID by default
rather than a path, so you don't even need to worry about this?).
- If you do use the ID from the constructor that 2.0 makes possible, it
will break if you do component replacement, because this will change.
So really, you should be using the current approach of pulling the ID
during the render or using a GUID anyway.
So we're left with marginally nicer error reporting. Is this much of an
improvement? Is our current reporting that deficient? Might there be
another way of improving this similarly, but without the constructor change?
Al
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys-and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
Wicket-user mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wicket-user
