It would make perfect sense for me if there appeared a wicketstuff project(subclasses necessary for compability with GAE) for this along with an example project..
2010/9/20 Jeremy Thomerson <jer...@wickettraining.com>: > On Mon, Sep 20, 2010 at 1:18 PM, tetsuo <ronald.tet...@gmail.com> wrote: > >> An auto-detected GAE-specific mode in Wicket core? I don't think this is a >> good idea... >> > > I agree that this shouldn't go in core, but I think if someone like Clint > has the motivation to do so, I'd love to see a project that provides > out-of-the-box GAE support. This might make it easier for newbs to get > something deployed to play with. This could potentially be done as a > standalone project that provides subclasses to WebApplication, etc, with the > default implementations switched out to GAE-compatible classes, configured > correctly, etc. Or, it could be a git clone of 1.4 and 1.5 (trunk) that > keeps current with the "vendor" (us, official Wicket), but adds in their > custom changes to make it GAE compatible. > > Why not use Jira sub tasks? > > > I think this is the way to go - create a master "make GAE compatible > version" task and subtasks for each individual thing. There should be a > differentiation made between ones that can be accepted in core and those > that can't. For example, we (probably) won't be accepting a WebApplication > subclass specific to GAE. But, we could accept some changes that need to be > made to make it compatible with, or easier to make compatible with, GAE. > For example, I'd love to see a task for "kill the use of stupid TreeModel > in 1.5" (and, really, any java.awt / javax.swing usage in core). But, this > would be better discussed as a separate thread. > > -- > Jeremy Thomerson > http://www.wickettraining.com >
