Re: Roadmap for Wicket 6

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

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
|

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
|

Re: Roadmap for Wicket 6

jcgarciam
@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
|

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
|

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
|

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
>
>