# Support for multiple markup regions for one single component instance
*Bruno Borges* (21) 7672-7099 *www.brunoborges.com* On Mon, Aug 29, 2011 at 10:58 PM, Brian Topping <[email protected]>wrote: > > On Aug 29, 2011, at 6:31 PM, Brian Topping wrote: > > On Aug 29, 2011, at 6:12 PM, Martijn Dashorst wrote: > > > >> In order to start discussing what will constitute Wicket Next and > >> where we want to take our beloved framework, I'll start off with my > >> wish list: > >> > >> 1. Java 6 as a minimum requirement for *all* of wicket > >> 2. Servlet API 3.0 as a minimum requirement > >> 3. JavaEE 6 support for at least CDI > >> 4. Proper OSGi support > >> 5. Ajax refactoring to use JQuery and provide proper JQuery integration > in core > >> 6. Shorter release cycle > > > > 7. More granular modules that are released independently w/ version > ranges for dependencies. Addresses #6. > > 8. Modularized content management, allowing content to be loaded from > database or classpath, clustered, etc. > > 9. Modularized classloader whereby drop-ins can load from #8. > > I forgot to add a piece that I was planning to experiment with: > > 10. Modularized rendering paradigms (HTML5, portlet, jQuery, extJS, > prototype, etc) whereby #5 (above) is not built into core, but abstracted > into it's own module, and developers would choose which paradigm they wanted > to use at project inception. Basis of this comes from having a wiQuery > component cascade states (selected, enabled) across the UI, which is > unbearable on a slow connection. A pluggable rendering paradigm could make > optimizations for the JS framework it supports to avoid these kinds of > issues, without creating a "fragile base class" situation or crippling the > core strengths of a particular framework. > > Brian > >
