Quantcast

Roadmap for Wicket 6

classic Classic list List threaded Threaded
23 messages Options
12
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Roadmap for Wicket 6

Martijn Dashorst
Administrator
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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Peter Ertl-3
- 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
>

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Igor Vaynberg-2
In reply to this post by Martijn Dashorst
* 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
<[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

jcgarciam
In reply to this post by Peter Ertl-3
@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] <[hidden email]> 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 [hidden email]
To unsubscribe from Apache Wicket, click here.



--

JC 


Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Igor Vaynberg-2
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 <[hidden email]> 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] <
> [hidden email]> 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
>> [hidden email]
>> To unsubscribe from Apache Wicket, click here<
>>
>>
>
>
>
> --
>
> 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.
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Clint Checketts
In reply to this post by Igor Vaynberg-2
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
> <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Brian Topping
In reply to this post by Brian Topping

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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Bruno Borges
# 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 <[hidden email]>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
>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Sven Meier
In reply to this post by Martijn Dashorst
#. 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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Martin Grigorov-4
- 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Bruno Borges
# Support for fallback style
# api for mobile browser detection
On Aug 30, 2011 6:29 AM, "Martin Grigorov" <[hidden email]> 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 <[hidden email]> 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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

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 <[hidden email]>wrote:

> # Support for fallback style
> # api for mobile browser detection
> On Aug 30, 2011 6:29 AM, "Martin Grigorov" <[hidden email]> 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 <[hidden email]> 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
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Attila Király
# 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 <[hidden email]>

> # 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 <[hidden email]
> >wrote:
>
> > # Support for fallback style
> > # api for mobile browser detection
> > On Aug 30, 2011 6:29 AM, "Martin Grigorov" <[hidden email]> 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 <[hidden email]> 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
> >
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Dominik Drzewiecki-2
In reply to this post by Martijn Dashorst
2011/8/30 Martijn Dashorst <[hidden email]>:
>
> 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 */
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Korbinian Bachl
In reply to this post by Martijn Dashorst
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 .setOutput****Id(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
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

tetsuo
- 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 <
[hidden email]> 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 .setOutput****Id(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
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

tetsuo
- 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 <[hidden email]> 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 <
> [hidden email]> 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 .setOutput****Id(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
>>>
>>
>
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Peter Ertl-3
In reply to this post by Korbinian Bachl
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 .setOutput****Id(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

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Roadmap for Wicket 6

Martin Grigorov-4
On Wed, Aug 31, 2011 at 4:10 PM, Peter Ertl <[hidden email]> 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 .setOutput****Id(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
12
Loading...