Roadmap for Wicket 6
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 I +1000 #1 in my wish list, since then I'll be able to build releases again. Regarding #6 I aim to release Wicket 6 final in December. Martijn
Re: Roadmap for Wicket 6
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. Brian
Re: Roadmap for Wicket 6
- Introduce @WicketBean (as a replacement for @Inject, @SpringBean, etc.) in wicket-ioc Am 30.08.2011 um 00:31 schrieb Brian Topping: > > 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. > > Brian >
Re: Roadmap for Wicket 6
* investigate "component queuing" ** https://github.com/ivaynberg/wicket/tree/component-queuing ** WICKET-3335 ** goals: only force developers to provide hierarchy information where necessary, lazy-build from markup otherwise ** investigate if the main add() method can be reworked to work like queue() and what effect that will have on symmetry with get(string) and remove(string) once components are placed into proper parents. * rework examples into a proper showcase app -igor On Mon, Aug 29, 2011 at 3: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 > > I +1000 #1 in my wish list, since then I'll be able to build releases again. > > Regarding #6 I aim to release Wicket 6 final in December. > > Martijn >
Re: Roadmap for Wicket 6
@Peter, i would say drop @SpringBean and use single notation for IOC regardless the module. In this case im in favor of using @Inject. On Mon, Aug 29, 2011 at 8:03 PM, Peter Ertl-3 [via Apache Wicket] < ml-node+3777607-1439127942-65...@n4.nabble.com> wrote: > - Introduce @WicketBean (as a replacement for @Inject, @SpringBean, etc.) > in wicket-ioc > > Am 30.08.2011 um 00:31 schrieb Brian Topping: > > > > > 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. > > > > Brian > > > > > > -- > If you reply to this email, your message will be added to the discussion > below: > > http://apache-wicket.1842946.n4.nabble.com/Re-Roadmap-for-Wicket-6-tp3777539p3777607.html > To start a new topic under Apache Wicket, email > ml-node+1842946-398011874-65...@n4.nabble.com > To unsubscribe from Apache Wicket, click > here<http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1842946&code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=>. > > -- JC -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Roadmap-for-Wicket-6-tp3777610p3777661.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com.
Re: Roadmap for Wicket 6
lets not discuss the details here, simply throw out ideas for features themselves. once we construct the roadmap we will have threads to discuss each feature in detail... -igor On Mon, Aug 29, 2011 at 4:35 PM, jcgarciam wrote: > @Peter, i would say drop @SpringBean and use single notation for IOC > regardless the module. In this case im in favor of using @Inject. > > > On Mon, Aug 29, 2011 at 8:03 PM, Peter Ertl-3 [via Apache Wicket] < > ml-node+3777607-1439127942-65...@n4.nabble.com> wrote: > >> - Introduce @WicketBean (as a replacement for @Inject, @SpringBean, etc.) >> in wicket-ioc >> >> Am 30.08.2011 um 00:31 schrieb Brian Topping: >> >> > >> > 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. >> > >> > Brian >> > >> >> >> >> -- >> If you reply to this email, your message will be added to the discussion >> below: >> >> http://apache-wicket.1842946.n4.nabble.com/Re-Roadmap-for-Wicket-6-tp3777539p3777607.html >> To start a new topic under Apache Wicket, email >> ml-node+1842946-398011874-65...@n4.nabble.com >> To unsubscribe from Apache Wicket, click >> here<http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_code&node=1842946&code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY=>. >> >> > > > > -- > > JC > > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Roadmap-for-Wicket-6-tp3777610p3777661.html > Sent from the Forum for Wicket Core developers mailing list archive at > Nabble.com.
Re: Roadmap for Wicket 6
I'd second 'rework examples into proper tutorial app', and aim for it a beginning section to be a step by step intro to new concepts, like an 'intro to wicket' app that has a sequential setup (ie #1 getting started, #2 navigating between pages, #3 pageparameters) etc. > * rework examples into a proper showcase app > > -igor > > > On Mon, Aug 29, 2011 at 3: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 > > > > I +1000 #1 in my wish list, since then I'll be able to build releases > again. > > > > Regarding #6 I aim to release Wicket 6 final in December. > > > > Martijn > > >
Re: Roadmap for Wicket 6
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
Re: Roadmap for Wicket 6
# 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 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 > >
Re: Roadmap for Wicket 6
#. rework Wicket components: ModalWindow, Wizard and Trees #. try to boil down Wicket core to its essentials (e.g. without most components) Sven On 08/30/2011 12:12 AM, 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 > > I +1000 #1 in my wish list, since then I'll be able to build releases again. > > Regarding #6 I aim to release Wicket 6 final in December. > > Martijn
Re: Roadmap for Wicket 6
- component queueing - introduce JQuery and migrate the problematic parts of wicket-ajax.js/wicket-event.js to use it. The bigger refactoring of Ajax should be postponed for later release On Tue, Aug 30, 2011 at 10:03 AM, Sven Meier wrote: > #. rework Wicket components: ModalWindow, Wizard and Trees > #. try to boil down Wicket core to its essentials (e.g. without most > components) > > Sven > > On 08/30/2011 12:12 AM, 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 >> >> I +1000 #1 in my wish list, since then I'll be able to build releases again. >> >> Regarding #6 I aim to release Wicket 6 final in December. >> >> Martijn > > -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: Roadmap for Wicket 6
# Support for fallback style # api for mobile browser detection On Aug 30, 2011 6:29 AM, "Martin Grigorov" wrote: > - component queueing > - introduce JQuery and migrate the problematic parts of > wicket-ajax.js/wicket-event.js to use it. The bigger refactoring of > Ajax should be postponed for later release > > On Tue, Aug 30, 2011 at 10:03 AM, Sven Meier wrote: >> #. rework Wicket components: ModalWindow, Wizard and Trees >> #. try to boil down Wicket core to its essentials (e.g. without most >> components) >> >> Sven >> >> On 08/30/2011 12:12 AM, 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 >>> >>> I +1000 #1 in my wish list, since then I'll be able to build releases again. >>> >>> Regarding #6 I aim to release Wicket 6 final in December. >>> >>> Martijn >> >> > > > > -- > Martin Grigorov > jWeekend > Training, Consulting, Development > http://jWeekend.com
Re: Roadmap for Wicket 6
# More mobile-related stuff (screen size, touchscreen javascripts) # Support for nondirectional markup inherance (class A extends B, but A inherents class C's markup) *Bruno Borges* (21) 7672-7099 *www.brunoborges.com* On Tue, Aug 30, 2011 at 10:23 AM, Bruno Borges wrote: > # Support for fallback style > # api for mobile browser detection > On Aug 30, 2011 6:29 AM, "Martin Grigorov" wrote: > > - component queueing > > - introduce JQuery and migrate the problematic parts of > > wicket-ajax.js/wicket-event.js to use it. The bigger refactoring of > > Ajax should be postponed for later release > > > > On Tue, Aug 30, 2011 at 10:03 AM, Sven Meier wrote: > >> #. rework Wicket components: ModalWindow, Wizard and Trees > >> #. try to boil down Wicket core to its essentials (e.g. without most > >> components) > >> > >> Sven > >> > >> On 08/30/2011 12:12 AM, 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 > >>> > >>> I +1000 #1 in my wish list, since then I'll be able to build releases > again. > >>> > >>> Regarding #6 I aim to release Wicket 6 final in December. > >>> > >>> Martijn > >> > >> > > > > > > > > -- > > Martin Grigorov > > jWeekend > > Training, Consulting, Development > > http://jWeekend.com >
Re: Roadmap for Wicket 6
# Embrace META-INF resources feature if Servlet 3.0 is available (let the container do the heavy lifting of serving static files) - merge MetaInfStaticResourceReference into PackageResourceReference - move static resources coming with wicket to the META-INF folders # Remove parser api dependency on string positions (o.a.w.markup.parser.IXmlPullParser & co) - makes it easier for example to implement a DOM based IXmlPullParser - positions can still be used for error messages when available # Make some code analysis to remove dead/old code Attila 2011/8/30 Bruno Borges > # More mobile-related stuff (screen size, touchscreen javascripts) > > # Support for nondirectional markup inherance (class A extends B, but A > inherents class C's markup) > > > *Bruno Borges* > (21) 7672-7099 > *www.brunoborges.com* > > > > On Tue, Aug 30, 2011 at 10:23 AM, Bruno Borges >wrote: > > > # Support for fallback style > > # api for mobile browser detection > > On Aug 30, 2011 6:29 AM, "Martin Grigorov" wrote: > > > - component queueing > > > - introduce JQuery and migrate the problematic parts of > > > wicket-ajax.js/wicket-event.js to use it. The bigger refactoring of > > > Ajax should be postponed for later release > > > > > > On Tue, Aug 30, 2011 at 10:03 AM, Sven Meier wrote: > > >> #. rework Wicket components: ModalWindow, Wizard and Trees > > >> #. try to boil down Wicket core to its essentials (e.g. without most > > >> components) > > >> > > >> Sven > > >> > > >> On 08/30/2011 12:12 AM, 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 > > >>> > > >>> I +1000 #1 in my wish list, since then I'll be able to build releases > > again. > > >>> > > >>> Regarding #6 I aim to release Wicket 6 final in December. > > >>> > > >>> Martijn > > >> > > >> > > > > > > > > > > > > -- > > > Martin Grigorov > > > jWeekend > > > Training, Consulting, Development > > > http://jWeekend.com > > >
Re: Roadmap for Wicket 6
2011/8/30 Martijn Dashorst : > > 1. Java 6 as a minimum requirement for *all* of wicket ...and thus make igor's bindgen-wicket part of core wicket regz, /dd -- /* Spelin donut mader if iz ina coment */
Re: Roadmap for Wicket 6
My wish list: 1. Java 6 2. JEE6 where possible like e.g. CDI; 3. Modularization using OSGI 4. AJAX overhaul: currently Ajax is a pain in case it gets more complicated as one -> needs to add components to target AND page hierarchy; -> needs to do .setOutputId(true) all over -> can't touch "invisible" containers in e.g.: DataTable 5. look at side-efforts done by matej, igor and co to bring the nice things to wicket and enhance/ or replace the affected counterparts of wicket (e.g.: DataTable vs. InMethod Grid; bindgen-wicket etc.) 6. Not 100% sure: let the HTML templates feed via a single place so one can switch to e.g. a JCR implementation - however, I dont know how this could work in conjunction with added jars etc. to path. Idea is to allow the templates to live outside the java part (e.g.: CMS); 7. @RequireHTTPS logic overhaul (currently: either must use SSL or mustn't use SSL, no "may use SSL"); Am 30.08.11 00:12, schrieb Martijn Dashorst: 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 I +1000 #1 in my wish list, since then I'll be able to build releases again. Regarding #6 I aim to release Wicket 6 final in December. Martijn
Re: Roadmap for Wicket 6
- I echo the .setOutput*() thing. There should be some global setting for these. - some preparation for Java 8/closures support (Single-Method Interfaces) - more/refined debug tools - revive portlet support On Wed, Aug 31, 2011 at 9:26 AM, Korbinian Bachl - privat < korbinian.ba...@whiskyworld.de> wrote: > My wish list: > > 1. Java 6 > > 2. JEE6 where possible like e.g. CDI; > > 3. Modularization using OSGI > > 4. AJAX overhaul: currently Ajax is a pain in case it gets more complicated > as one > -> needs to add components to target AND page hierarchy; > -> needs to do .setOutputId(true) all over > -> can't touch "invisible" containers in e.g.: DataTable > > 5. look at side-efforts done by matej, igor and co to bring the nice things > to wicket and enhance/ or replace the affected counterparts of wicket (e.g.: > DataTable vs. InMethod Grid; bindgen-wicket etc.) > > 6. Not 100% sure: let the HTML templates feed via a single place so one can > switch to e.g. a JCR implementation - however, I dont know how this could > work in conjunction with added jars etc. to path. Idea is to allow the > templates to live outside the java part (e.g.: CMS); > > 7. @RequireHTTPS logic overhaul (currently: either must use SSL or mustn't > use SSL, no "may use SSL"); > > > > Am 30.08.11 00:12, schrieb Martijn Dashorst: > > 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 >> >> I +1000 #1 in my wish list, since then I'll be able to build releases >> again. >> >> Regarding #6 I aim to release Wicket 6 final in December. >> >> Martijn >> >
Re: Roadmap for Wicket 6
- Refactor things out of WicketFilter (and removing any direct dependency on it from the core processing), so that we could tweak the request processing cycle (more low-level things, that are not possible with RequestCycleListeners) without having to patch its source code. The way things are now, it is a big blob of code with lots of private/final methods, impossible to customize. On Wed, Aug 31, 2011 at 10:33 AM, tetsuo wrote: > - I echo the .setOutput*() thing. There should be some global setting for > these. > > - some preparation for Java 8/closures support (Single-Method Interfaces) > > - more/refined debug tools > > - revive portlet support > > > > On Wed, Aug 31, 2011 at 9:26 AM, Korbinian Bachl - privat < > korbinian.ba...@whiskyworld.de> wrote: > >> My wish list: >> >> 1. Java 6 >> >> 2. JEE6 where possible like e.g. CDI; >> >> 3. Modularization using OSGI >> >> 4. AJAX overhaul: currently Ajax is a pain in case it gets more >> complicated as one >> -> needs to add components to target AND page hierarchy; >> -> needs to do .setOutputId(true) all over >> -> can't touch "invisible" containers in e.g.: DataTable >> >> 5. look at side-efforts done by matej, igor and co to bring the nice >> things to wicket and enhance/ or replace the affected counterparts of wicket >> (e.g.: DataTable vs. InMethod Grid; bindgen-wicket etc.) >> >> 6. Not 100% sure: let the HTML templates feed via a single place so one >> can switch to e.g. a JCR implementation - however, I dont know how this >> could work in conjunction with added jars etc. to path. Idea is to allow the >> templates to live outside the java part (e.g.: CMS); >> >> 7. @RequireHTTPS logic overhaul (currently: either must use SSL or mustn't >> use SSL, no "may use SSL"); >> >> >> >> Am 30.08.11 00:12, schrieb Martijn Dashorst: >> >> 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 >>> >>> I +1000 #1 in my wish list, since then I'll be able to build releases >>> again. >>> >>> Regarding #6 I aim to release Wicket 6 final in December. >>> >>> Martijn >>> >> >
Re: Roadmap for Wicket 6
Ok, so since this is brainstorming time I can probably ask for cool features
without getting punished :-)
- partial ajax updates on repeaters (insert/modify/delete)
- some kind of intuitive support from wicket to synchronize access to session
or page data when processing multiple, concurrent ajax requests
- easier interaction between javascript and page with less magic. Especially I
would love to have stable urls for ajax callbacks that are relative to the page.
[disclaimer] consider the following example just non-functional(!) pseudo(!)
code to get the idea what I mean... no idea if this could possibly work ...
please excuse if this is complete b**s** :-)
EXAMPLE
public class CheckoutPage extends WebPage
{
private OrderLineItems items;
private PaymentMethod payment;
public CheckoutPage()
{
mountPageResponder("order/items", new PageResponder()
{
@Override
public void onGet(Request request, Response response)
{
// convert order line items into json
// send json to client
}
});
mountPageResponder("payment/change", new PageResponder()
{
@Override
public void onPost(Request request, Response response)
{
// move : request.getParameter("method") ->
this.payment
}
});
}
}
So gettting the shopping items from within javascript in the checkout page with
jQuery would simply be
$.get("order/items", function(data) {
// process order line item data and refresh markup
})
Change the payment method to master card:
$.ajax({ type: 'POST', url: "payment/change", data: { method: 'master-card'
}, success: updatePaymentInfoCallback, error: showError )
(please excuse possibly errors in the above javascript)
so no need for stuff like this:
add(new Behavior()
{
@Override
public void renderHead(Component component,
IHeaderResponse response)
{
response.renderOnLoadJavaScript("initCheckoutScript('" + urlFor(someListener) +
"');");
}
})
Cheers
Peter
Am 31.08.2011 um 14:26 schrieb Korbinian Bachl - privat:
> My wish list:
>
> 1. Java 6
>
> 2. JEE6 where possible like e.g. CDI;
>
> 3. Modularization using OSGI
>
> 4. AJAX overhaul: currently Ajax is a pain in case it gets more complicated
> as one
> -> needs to add components to target AND page hierarchy;
> -> needs to do .setOutputId(true) all over
> -> can't touch "invisible" containers in e.g.: DataTable
>
> 5. look at side-efforts done by matej, igor and co to bring the nice things
> to wicket and enhance/ or replace the affected counterparts of wicket (e.g.:
> DataTable vs. InMethod Grid; bindgen-wicket etc.)
>
> 6. Not 100% sure: let the HTML templates feed via a single place so one can
> switch to e.g. a JCR implementation - however, I dont know how this could
> work in conjunction with added jars etc. to path. Idea is to allow the
> templates to live outside the java part (e.g.: CMS);
>
> 7. @RequireHTTPS logic overhaul (currently: either must use SSL or mustn't
> use SSL, no "may use SSL");
>
>
>
> Am 30.08.11 00:12, schrieb Martijn Dashorst:
>> 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
>>
>> I +1000 #1 in my wish list, since then I'll be able to build releases again.
>>
>> Regarding #6 I aim to release Wicket 6 final in December.
>>
>> Martijn
Re: Roadmap for Wicket 6
On Wed, Aug 31, 2011 at 4:10 PM, Peter Ertl wrote:
> Ok, so since this is brainstorming time I can probably ask for cool features
> without getting punished :-)
>
> - partial ajax updates on repeaters (insert/modify/delete)
> - some kind of intuitive support from wicket to synchronize access to session
> or page data when processing multiple, concurrent ajax requests
> - easier interaction between javascript and page with less magic. Especially
> I would love to have stable urls for ajax callbacks that are relative to the
> page.
>
> [disclaimer] consider the following example just non-functional(!) pseudo(!)
> code to get the idea what I mean... no idea if this could possibly work ...
> please excuse if this is complete b**s** :-)
>
> EXAMPLE
>
> public class CheckoutPage extends WebPage
> {
> private OrderLineItems items;
> private PaymentMethod payment;
>
> public CheckoutPage()
> {
> mountPageResponder("order/items", new PageResponder()
> {
> @Override
> public void onGet(Request request, Response response)
> {
> // convert order line items into json
> // send json to client
> }
> });
> mountPageResponder("payment/change", new PageResponder()
> {
> @Override
> public void onPost(Request request, Response response)
> {
> // move : request.getParameter("method") ->
> this.payment
> }
> });
> }
> }
>
> So gettting the shopping items from within javascript in the checkout page
> with jQuery would simply be
>
> $.get("order/items", function(data) {
> // process order line item data and refresh markup
> })
>
> Change the payment method to master card:
>
> $.ajax({ type: 'POST', url: "payment/change", data: { method: 'master-card'
> }, success: updatePaymentInfoCallback, error: showError )
>
> (please excuse possibly errors in the above javascript)
>
> so no need for stuff like this:
>
> add(new Behavior()
> {
> @Override
> public void renderHead(Component component,
> IHeaderResponse response)
> {
>
> response.renderOnLoadJavaScript("initCheckoutScript('" + urlFor(someListener)
> + "');");
> }
> })
I use templates for this (PackageTextTemplate and Co.). Works like a charm.
>
>
>
> Cheers
> Peter
>
>
> Am 31.08.2011 um 14:26 schrieb Korbinian Bachl - privat:
>
>> My wish list:
>>
>> 1. Java 6
>>
>> 2. JEE6 where possible like e.g. CDI;
>>
>> 3. Modularization using OSGI
>>
>> 4. AJAX overhaul: currently Ajax is a pain in case it gets more complicated
>> as one
>> -> needs to add components to target AND page hierarchy;
>> -> needs to do .setOutputId(true) all over
>> -> can't touch "invisible" containers in e.g.: DataTable
>>
>> 5. look at side-efforts done by matej, igor and co to bring the nice things
>> to wicket and enhance/ or replace the affected counterparts of wicket (e.g.:
>> DataTable vs. InMethod Grid; bindgen-wicket etc.)
>>
>> 6. Not 100% sure: let the HTML templates feed via a single place so one can
>> switch to e.g. a JCR implementation - however, I dont know how this could
>> work in conjunction with added jars etc. to path. Idea is to allow the
>> templates to live outside the java part (e.g.: CMS);
>>
>> 7. @RequireHTTPS logic overhaul (currently: either must use SSL or mustn't
>> use SSL, no "may use SSL");
>>
>>
>>
>> Am 30.08.11 00:12, schrieb Martijn Dashorst:
>>> 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
>>>
>>> I +1000 #1 in my wish list, since then I'll be able to build releases again.
>>>
>>> Regarding #6 I aim to release Wicket 6 final in December.
>>>
>>> Martijn
>
>
--
Martin Grigorov
jWeekend
Training, Consulting, Development
http://jWeekend.com
Re: Roadmap for Wicket 6
A few more ideas for Wicket 6:
- Use findbugs annotations in the api (like @Nonnull for arguments/return
values, an example library doing this is google guava). It is good for two
reasons: works like a documentation and findbugs can do some static code
analysis based on it. However it does not replace the current runtime checks
(like Args.*) it just helps a bit in the area.
- Hide wicket implementation details (like methods marked with "THIS IS A
WICKET INTERNAL API. DO NOT USE IT.") behind single entry points. For
example:
public class Component {
public class ComponentInternalApi {
public void doSomething() {
}
protected final void doSomethingElse() {
}
}
private final ComponentInternalApi internalApi = new ComponentInternalApi();
@Nonnull
public ComponentInternalApi internals() {
return internalApi;
}
}
This is a cosmetic change. The downside of this would be a slightly
increased memory footprint for wicket objects. The gain is a cleaner api.
This a bit similar to Martin's functionality grouping for WicketTester:
https://issues.apache.org/jira/browse/WICKET-3747.
Regards,
Attila
2011/8/31 Martin Grigorov
> On Wed, Aug 31, 2011 at 4:10 PM, Peter Ertl wrote:
> > Ok, so since this is brainstorming time I can probably ask for cool
> features without getting punished :-)
> >
> > - partial ajax updates on repeaters (insert/modify/delete)
> > - some kind of intuitive support from wicket to synchronize access to
> session or page data when processing multiple, concurrent ajax requests
> > - easier interaction between javascript and page with less magic.
> Especially I would love to have stable urls for ajax callbacks that are
> relative to the page.
> >
> > [disclaimer] consider the following example just non-functional(!)
> pseudo(!) code to get the idea what I mean... no idea if this could possibly
> work ... please excuse if this is complete b**s** :-)
> >
> > EXAMPLE
> >
> > public class CheckoutPage extends WebPage
> > {
> >private OrderLineItems items;
> >private PaymentMethod payment;
> >
> >public CheckoutPage()
> >{
> >mountPageResponder("order/items", new PageResponder()
> >{
> >@Override
> >public void onGet(Request request, Response response)
> > {
> > // convert order line items into json
> > // send json to client
> > }
> >});
> >mountPageResponder("payment/change", new PageResponder()
> >{
> >@Override
> >public void onPost(Request request, Response response)
> > {
> > // move : request.getParameter("method") ->
> this.payment
> > }
> >});
> >}
> > }
> >
> > So gettting the shopping items from within javascript in the checkout
> page with jQuery would simply be
> >
> > $.get("order/items", function(data) {
> >// process order line item data and refresh markup
> > })
> >
> > Change the payment method to master card:
> >
> > $.ajax({ type: 'POST', url: "payment/change", data: { method:
> 'master-card' }, success: updatePaymentInfoCallback, error: showError )
> >
> > (please excuse possibly errors in the above javascript)
> >
> > so no need for stuff like this:
> >
> >add(new Behavior()
> >{
> >@Override
> >public void renderHead(Component component,
> IHeaderResponse response)
> >{
> >
> response.renderOnLoadJavaScript("initCheckoutScript('" +
> urlFor(someListener) + "');");
> >}
> >})
> I use templates for this (PackageTextTemplate and Co.). Works like a charm.
> >
> >
> >
> > Cheers
> > Peter
> >
> >
> > Am 31.08.2011 um 14:26 schrieb Korbinian Bachl - privat:
> >
> >> My wish list:
> >>
> >> 1. Java 6
> >>
> >> 2. JEE6 where possible like e.g. CDI;
> >>
> >> 3. Modularization using OSGI
> >>
> >> 4. AJAX overhaul: currently Ajax is a pain in case it gets more
> complicated as one
> >> -> needs to add components to target AND page hierarchy;
> >> -> needs to do .setOutputId(true) all over
> >> -> can't touch "invisible" containers in e.g.: DataTable
> >>
> >> 5. look at side-efforts done by matej, igor and co to bring the nice
> things to wicket and enhance/ or replace the affected counterparts of wicket
> (e.g.: DataTable vs. InMethod Grid; bindgen-wicket etc.)
> >>
> >> 6. Not 100% sure: let the HTML templates feed via a single place so one
> can switch to e.g. a JCR implementation - however, I dont know how this
> could work in conjunction with added jars etc. to path. Idea is to allow the
> templates to live outside the java part (e.g.: CMS);
> >>
> >> 7. @RequireHTTPS logic overhaul (currently: either must use SSL
Re: Roadmap for Wicket 6
On Mon, Oct 24, 2011 at 11:23 AM, Attila Király
wrote:
> A few more ideas for Wicket 6:
> - Use findbugs annotations in the api (like @Nonnull for arguments/return
> values, an example library doing this is google guava). It is good for two
> reasons: works like a documentation and findbugs can do some static code
> analysis based on it. However it does not replace the current runtime checks
> (like Args.*) it just helps a bit in the area.
>
> - Hide wicket implementation details (like methods marked with "THIS IS A
> WICKET INTERNAL API. DO NOT USE IT.") behind single entry points. For
> example:
> public class Component {
> public class ComponentInternalApi {
> public void doSomething() {
> }
>
> protected final void doSomethingElse() {
> }
> }
>
> private final ComponentInternalApi internalApi = new ComponentInternalApi();
>
> @Nonnull
> public ComponentInternalApi internals() {
> return internalApi;
> }
> }
> This is a cosmetic change. The downside of this would be a slightly
> increased memory footprint for wicket objects. The gain is a cleaner api.
> This a bit similar to Martin's functionality grouping for WicketTester:
> https://issues.apache.org/jira/browse/WICKET-3747.
this will be a big memory overhead. its a new memory slot per
component instance which is 64 bits. i would rather do new
ComponentInternals(this).doSomething() like what we do with Behaviors.
or simply rename all internal methods with internal*
-igor
>
> Regards,
> Attila
>
> 2011/8/31 Martin Grigorov
>
>> On Wed, Aug 31, 2011 at 4:10 PM, Peter Ertl wrote:
>> > Ok, so since this is brainstorming time I can probably ask for cool
>> features without getting punished :-)
>> >
>> > - partial ajax updates on repeaters (insert/modify/delete)
>> > - some kind of intuitive support from wicket to synchronize access to
>> session or page data when processing multiple, concurrent ajax requests
>> > - easier interaction between javascript and page with less magic.
>> Especially I would love to have stable urls for ajax callbacks that are
>> relative to the page.
>> >
>> > [disclaimer] consider the following example just non-functional(!)
>> pseudo(!) code to get the idea what I mean... no idea if this could possibly
>> work ... please excuse if this is complete b**s** :-)
>> >
>> > EXAMPLE
>> >
>> > public class CheckoutPage extends WebPage
>> > {
>> > private OrderLineItems items;
>> > private PaymentMethod payment;
>> >
>> > public CheckoutPage()
>> > {
>> > mountPageResponder("order/items", new PageResponder()
>> > {
>> > @Override
>> > public void onGet(Request request, Response response)
>> > {
>> > // convert order line items into json
>> > // send json to client
>> > }
>> > });
>> > mountPageResponder("payment/change", new PageResponder()
>> > {
>> > @Override
>> > public void onPost(Request request, Response response)
>> > {
>> > // move : request.getParameter("method") ->
>> this.payment
>> > }
>> > });
>> > }
>> > }
>> >
>> > So gettting the shopping items from within javascript in the checkout
>> page with jQuery would simply be
>> >
>> > $.get("order/items", function(data) {
>> > // process order line item data and refresh markup
>> > })
>> >
>> > Change the payment method to master card:
>> >
>> > $.ajax({ type: 'POST', url: "payment/change", data: { method:
>> 'master-card' }, success: updatePaymentInfoCallback, error: showError )
>> >
>> > (please excuse possibly errors in the above javascript)
>> >
>> > so no need for stuff like this:
>> >
>> > add(new Behavior()
>> > {
>> > @Override
>> > public void renderHead(Component component,
>> IHeaderResponse response)
>> > {
>> >
>> response.renderOnLoadJavaScript("initCheckoutScript('" +
>> urlFor(someListener) + "');");
>> > }
>> > })
>> I use templates for this (PackageTextTemplate and Co.). Works like a charm.
>> >
>> >
>> >
>> > Cheers
>> > Peter
>> >
>> >
>> > Am 31.08.2011 um 14:26 schrieb Korbinian Bachl - privat:
>> >
>> >> My wish list:
>> >>
>> >> 1. Java 6
>> >>
>> >> 2. JEE6 where possible like e.g. CDI;
>> >>
>> >> 3. Modularization using OSGI
>> >>
>> >> 4. AJAX overhaul: currently Ajax is a pain in case it gets more
>> complicated as one
>> >> -> needs to add components to target AND page hierarchy;
>> >> -> needs to do .setOutputId(true) all over
>> >> -> can't touch "invisible" containers in e.g.: DataTable
>> >>
>> >> 5. look at side-efforts done by matej, igor and co to bring the nice
>> things to wicket and enhan
