Yes, I wouldn't think the "vendor lock-in" (in the traditional sense) doesn't really apply here. If you're choosing to use Wicket, then you're pretty much stuck with Wicket. You can't take your Wicket application code and plop it down in a JSF or Struts or Tapestry application and have it magically work.
As for your migration concerns, they are valid questions and they have been addressed. If you're concerned that Wicket is going to do stuff like Tapestry, I wouldn't worry too much about that. I left Tapestry for Wicket years ago because of that reason (check the email logs; I was one of the loudest voices against all of the crazy changes from version to version). Sure, the migration between major versions (the "x" in 1.x) isn't just a drop-in replacement, but it really isn't that painful. I migrated from 1.3. to 1.4 in a couple of hours by myself on our application. On Tue, May 25, 2010 at 6:12 AM, Sven Meier <[email protected]> wrote: > > It's funny how you combine Wicket (i.e. open source) and "vendor lock-in", > two antithetic terms I'd never put together in a single sentence. > Please search "lock" in the following post for arguments: > > http://ptrthomas.wordpress.com/2009/05/15/jsf-sucks/ > > If you choose JSF, all what's guaranteed is crappy support from your > implementation (IBM at least), EOL policy, migration after migration and > "vendor lock-in". > > My 2 cents > Sven > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Wicket-vendor-lockin-and-backwards-compatibility-1-4-1-5-tp2226109p2229767.html > Sent from the Wicket - User mailing list archive at Nabble.com. > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [email protected] > For additional commands, e-mail: [email protected] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
