You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@isis.apache.org by Martin Grigorov <mg...@apache.org> on 2016/10/31 13:41:12 UTC
What else do we want to do before 8.0.0 final ?
Hi,
What other improvements do we need in 8.x/master before promoting it to
8.0.0 final ?
At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0
we still have:
- new DateTime APIs for wicket-datetime *WICKET-6105
<https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
more try but the problem is that I don't believe this is the proper way and
this demotivates me.
If someone else wants to give it a try - please assign it to yourself!
- Better SEO for stateful pages - the only way I see this is by using
ServiceWorker to add the pageId as a request header to all requests (normal
& Ajax)
Recently I wondered whether Redux.js could be in use for Wicket.
I don't have much experience with it, but both React and AngularJs
communities use it to manage the state for their components.
There are some Java impls, even a standard is coming:
https://github.com/jvm-redux/jvm-redux-api
What else ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
http://central.maven.org/maven2/org/danekja/jdk-serializable-functional/1.8.1/
@Emond: do you want to make the changes ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Nov 2, 2016 at 4:47 PM, Martin Grigorov <mg...@apache.org>
wrote:
>
> On Mon, Oct 31, 2016 at 10:15 PM, Martin Grigorov <mg...@apache.org>
> wrote:
>
>>
>> On Mon, Oct 31, 2016 at 5:11 PM, Emond Papegaaij <
>> emond.papegaaij@topicus.nl> wrote:
>>
>>> On maandag 31 oktober 2016 16:38:48 CET Martin Grigorov wrote:
>>> > Hi Emond,
>>> >
>>> > On Mon, Oct 31, 2016 at 4:28 PM, Emond Papegaaij <
>>> emond.papegaaij@topicus.nl
>>> > > wrote:
>>> > >
>>> > > Hi,
>>> > >
>>> > > I'm not sure about the duplicate functional interfaces in
>>> > > org.apache.wicket.lambda. The current solution ties these interfaces
>>> to
>>> > > Wicket, making it impossible to share function-libraries between
>>> wicket
>>> > > and
>>> > > non-wicket code.
>>> > >
>>> > > For example this method returns a function that prints a time with
>>> seconds
>>> > > in
>>> > >
>>> > > the given locale:
>>> > > public static WicketFunction<Instant, String>
>>> > >
>>> > > timeWithSeconds(final Supplier<Locale> localeSupplier) { ... }
>>> >
>>> > I am not sure this is true.
>>> > The important thing is the Wicket APIs to use WicketXyz. This tells the
>>> > compiler to use/create a java.lang.invoke.SerializedLambda.
>>> > You can pass any kind of Xyz as an argument and it will work just fine.
>>>
>>> Functional interfaces are just normal interfaces. A Function is not a
>>> WicketFunction and a TopicusFunction is not a WicketFunction either. You
>>> can
>>> create a serializable method reference to the apply method, but that's
>>> just
>>> ugly. A method taking a WicketFunction will not accept a Function nor a
>>> TopicusFunction. This is something we ran into when converting Guava
>>> code to
>>> java.util interfaces.
>>>
>>
>> OK. I see what you mean.
>> I've found https://github.com/danekja/jdk-serializable-functional but it
>> seems it is not at Maven Central. I've created an issue to ask the author.
>>
>
> https://github.com/danekja/jdk-serializable-functional/
> issues/1#issuecomment-257903712
> Happy customer!
>
>
>>
>>
>>>
>>> >
>>> > > The current WicketFunction is tied to wicket, so I cannot place this
>>> > > function
>>> > > in a shared library. When changing the type to java.util.Function, I
>>> > > cannot
>>> > > use it on pages, because it is not serializable. The only option that
>>> > > remains
>>> > >
>>> > > is changing it to and constructing functions on the spot:
>>> > > public static String timeWithSeconds(Instant instant, Locale
>>> locale) {
>>> > >
>>> > > ... }
>>> > >
>>> > > I propose to move the classes to a standalone maven module, rename
>>> them to
>>> > > SerializableFunction (etc.) and let them implement Serializable (not
>>> > > IClusterable). Maybe even change the package to something non-wicket.
>>> > >
>>> > > Also, the current interfaces do not override the default methods
>>> provided
>>> > > by
>>> > > the super-interfaces (such as compose and andThen). Using the
>>> methods on
>>> > > the
>>> > > current classes will give non-serializable versions of the
>>> interfaces.
>>> > >
>>> > > Finally, many commonly used interfaces are missing, such as:
>>> Runnable,
>>> > > Predicate, BiPredicate and more. Perhaps we should duplicate all
>>> > > FunctionalInterfaces, maybe only the ones most often used.
>>> >
>>> > I am not sure this is even needed and most definitely we cannot provide
>>> > serializable version for all interfaces out there.
>>>
>>> At Topicus we have the ones provided by Wicket, plus Runnable, Predicate
>>> and
>>> BiPredicate. That seems to be fine for most cases. It is important to
>>> provide
>>> all default methode though. Otherwise SerializablePredicate.negate() no
>>> longer
>>> is serializable, and that's not what you would expect.
>>>
>>> > > In all, I propose to create a simple library that provides many
>>> > > serializable
>>> > > versions of functional interfaces. I think such a library does not
>>> belong
>>> > > in
>>> > > Wicket, but that's the best we can do. Mayby the guys from commons
>>> are
>>> > > willing
>>> > > to take the code.
>>> > >
>>> > > What do you think?
>>> > >
>>> > > Best regards,
>>> > > Emond
>>> > >
>>> > > On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
>>> > > > Hi,
>>> > > >
>>> > > > What other improvements do we need in 8.x/master before promoting
>>> it to
>>> > > > 8.0.0 final ?
>>> > > >
>>> > > > At https://cwiki.apache.org/confluence/display/WICKET/
>>> > >
>>> > > Ideas+for+Wicket+8.0
>>> > >
>>> > > > we still have:
>>> > > >
>>> > > > - new DateTime APIs for wicket-datetime *WICKET-6105
>>> > > > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
>>> this
>>> > >
>>> > > one
>>> > >
>>> > > > more try but the problem is that I don't believe this is the
>>> proper way
>>> > >
>>> > > and
>>> > >
>>> > > > this demotivates me.
>>> > > > If someone else wants to give it a try - please assign it to
>>> yourself!
>>> > > >
>>> > > > - Better SEO for stateful pages - the only way I see this is by
>>> using
>>> > > > ServiceWorker to add the pageId as a request header to all requests
>>> > >
>>> > > (normal
>>> > >
>>> > > > & Ajax)
>>> > > >
>>> > > >
>>> > > > Recently I wondered whether Redux.js could be in use for Wicket.
>>> > > > I don't have much experience with it, but both React and AngularJs
>>> > > > communities use it to manage the state for their components.
>>> > > > There are some Java impls, even a standard is coming:
>>> > > > https://github.com/jvm-redux/jvm-redux-api
>>> > > >
>>> > > > What else ?
>>> > > >
>>> > > > Martin Grigorov
>>> > > > Wicket Training and Consulting
>>> > > > https://twitter.com/mtgrigorov
>>>
>>>
>>>
>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Oct 31, 2016 at 10:15 PM, Martin Grigorov <mg...@apache.org>
wrote:
>
> On Mon, Oct 31, 2016 at 5:11 PM, Emond Papegaaij <
> emond.papegaaij@topicus.nl> wrote:
>
>> On maandag 31 oktober 2016 16:38:48 CET Martin Grigorov wrote:
>> > Hi Emond,
>> >
>> > On Mon, Oct 31, 2016 at 4:28 PM, Emond Papegaaij <
>> emond.papegaaij@topicus.nl
>> > > wrote:
>> > >
>> > > Hi,
>> > >
>> > > I'm not sure about the duplicate functional interfaces in
>> > > org.apache.wicket.lambda. The current solution ties these interfaces
>> to
>> > > Wicket, making it impossible to share function-libraries between
>> wicket
>> > > and
>> > > non-wicket code.
>> > >
>> > > For example this method returns a function that prints a time with
>> seconds
>> > > in
>> > >
>> > > the given locale:
>> > > public static WicketFunction<Instant, String>
>> > >
>> > > timeWithSeconds(final Supplier<Locale> localeSupplier) { ... }
>> >
>> > I am not sure this is true.
>> > The important thing is the Wicket APIs to use WicketXyz. This tells the
>> > compiler to use/create a java.lang.invoke.SerializedLambda.
>> > You can pass any kind of Xyz as an argument and it will work just fine.
>>
>> Functional interfaces are just normal interfaces. A Function is not a
>> WicketFunction and a TopicusFunction is not a WicketFunction either. You
>> can
>> create a serializable method reference to the apply method, but that's
>> just
>> ugly. A method taking a WicketFunction will not accept a Function nor a
>> TopicusFunction. This is something we ran into when converting Guava code
>> to
>> java.util interfaces.
>>
>
> OK. I see what you mean.
> I've found https://github.com/danekja/jdk-serializable-functional but it
> seems it is not at Maven Central. I've created an issue to ask the author.
>
https://github.com/danekja/jdk-serializable-functional/issues/1#issuecomment-257903712
Happy customer!
>
>
>>
>> >
>> > > The current WicketFunction is tied to wicket, so I cannot place this
>> > > function
>> > > in a shared library. When changing the type to java.util.Function, I
>> > > cannot
>> > > use it on pages, because it is not serializable. The only option that
>> > > remains
>> > >
>> > > is changing it to and constructing functions on the spot:
>> > > public static String timeWithSeconds(Instant instant, Locale
>> locale) {
>> > >
>> > > ... }
>> > >
>> > > I propose to move the classes to a standalone maven module, rename
>> them to
>> > > SerializableFunction (etc.) and let them implement Serializable (not
>> > > IClusterable). Maybe even change the package to something non-wicket.
>> > >
>> > > Also, the current interfaces do not override the default methods
>> provided
>> > > by
>> > > the super-interfaces (such as compose and andThen). Using the methods
>> on
>> > > the
>> > > current classes will give non-serializable versions of the interfaces.
>> > >
>> > > Finally, many commonly used interfaces are missing, such as: Runnable,
>> > > Predicate, BiPredicate and more. Perhaps we should duplicate all
>> > > FunctionalInterfaces, maybe only the ones most often used.
>> >
>> > I am not sure this is even needed and most definitely we cannot provide
>> > serializable version for all interfaces out there.
>>
>> At Topicus we have the ones provided by Wicket, plus Runnable, Predicate
>> and
>> BiPredicate. That seems to be fine for most cases. It is important to
>> provide
>> all default methode though. Otherwise SerializablePredicate.negate() no
>> longer
>> is serializable, and that's not what you would expect.
>>
>> > > In all, I propose to create a simple library that provides many
>> > > serializable
>> > > versions of functional interfaces. I think such a library does not
>> belong
>> > > in
>> > > Wicket, but that's the best we can do. Mayby the guys from commons are
>> > > willing
>> > > to take the code.
>> > >
>> > > What do you think?
>> > >
>> > > Best regards,
>> > > Emond
>> > >
>> > > On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
>> > > > Hi,
>> > > >
>> > > > What other improvements do we need in 8.x/master before promoting
>> it to
>> > > > 8.0.0 final ?
>> > > >
>> > > > At https://cwiki.apache.org/confluence/display/WICKET/
>> > >
>> > > Ideas+for+Wicket+8.0
>> > >
>> > > > we still have:
>> > > >
>> > > > - new DateTime APIs for wicket-datetime *WICKET-6105
>> > > > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
>> this
>> > >
>> > > one
>> > >
>> > > > more try but the problem is that I don't believe this is the proper
>> way
>> > >
>> > > and
>> > >
>> > > > this demotivates me.
>> > > > If someone else wants to give it a try - please assign it to
>> yourself!
>> > > >
>> > > > - Better SEO for stateful pages - the only way I see this is by
>> using
>> > > > ServiceWorker to add the pageId as a request header to all requests
>> > >
>> > > (normal
>> > >
>> > > > & Ajax)
>> > > >
>> > > >
>> > > > Recently I wondered whether Redux.js could be in use for Wicket.
>> > > > I don't have much experience with it, but both React and AngularJs
>> > > > communities use it to manage the state for their components.
>> > > > There are some Java impls, even a standard is coming:
>> > > > https://github.com/jvm-redux/jvm-redux-api
>> > > >
>> > > > What else ?
>> > > >
>> > > > Martin Grigorov
>> > > > Wicket Training and Consulting
>> > > > https://twitter.com/mtgrigorov
>>
>>
>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Oct 31, 2016 at 5:11 PM, Emond Papegaaij <emond.papegaaij@topicus.nl
> wrote:
> On maandag 31 oktober 2016 16:38:48 CET Martin Grigorov wrote:
> > Hi Emond,
> >
> > On Mon, Oct 31, 2016 at 4:28 PM, Emond Papegaaij <
> emond.papegaaij@topicus.nl
> > > wrote:
> > >
> > > Hi,
> > >
> > > I'm not sure about the duplicate functional interfaces in
> > > org.apache.wicket.lambda. The current solution ties these interfaces to
> > > Wicket, making it impossible to share function-libraries between wicket
> > > and
> > > non-wicket code.
> > >
> > > For example this method returns a function that prints a time with
> seconds
> > > in
> > >
> > > the given locale:
> > > public static WicketFunction<Instant, String>
> > >
> > > timeWithSeconds(final Supplier<Locale> localeSupplier) { ... }
> >
> > I am not sure this is true.
> > The important thing is the Wicket APIs to use WicketXyz. This tells the
> > compiler to use/create a java.lang.invoke.SerializedLambda.
> > You can pass any kind of Xyz as an argument and it will work just fine.
>
> Functional interfaces are just normal interfaces. A Function is not a
> WicketFunction and a TopicusFunction is not a WicketFunction either. You
> can
> create a serializable method reference to the apply method, but that's just
> ugly. A method taking a WicketFunction will not accept a Function nor a
> TopicusFunction. This is something we ran into when converting Guava code
> to
> java.util interfaces.
>
OK. I see what you mean.
I've found https://github.com/danekja/jdk-serializable-functional but it
seems it is not at Maven Central. I've created an issue to ask the author.
>
> >
> > > The current WicketFunction is tied to wicket, so I cannot place this
> > > function
> > > in a shared library. When changing the type to java.util.Function, I
> > > cannot
> > > use it on pages, because it is not serializable. The only option that
> > > remains
> > >
> > > is changing it to and constructing functions on the spot:
> > > public static String timeWithSeconds(Instant instant, Locale locale)
> {
> > >
> > > ... }
> > >
> > > I propose to move the classes to a standalone maven module, rename
> them to
> > > SerializableFunction (etc.) and let them implement Serializable (not
> > > IClusterable). Maybe even change the package to something non-wicket.
> > >
> > > Also, the current interfaces do not override the default methods
> provided
> > > by
> > > the super-interfaces (such as compose and andThen). Using the methods
> on
> > > the
> > > current classes will give non-serializable versions of the interfaces.
> > >
> > > Finally, many commonly used interfaces are missing, such as: Runnable,
> > > Predicate, BiPredicate and more. Perhaps we should duplicate all
> > > FunctionalInterfaces, maybe only the ones most often used.
> >
> > I am not sure this is even needed and most definitely we cannot provide
> > serializable version for all interfaces out there.
>
> At Topicus we have the ones provided by Wicket, plus Runnable, Predicate
> and
> BiPredicate. That seems to be fine for most cases. It is important to
> provide
> all default methode though. Otherwise SerializablePredicate.negate() no
> longer
> is serializable, and that's not what you would expect.
>
> > > In all, I propose to create a simple library that provides many
> > > serializable
> > > versions of functional interfaces. I think such a library does not
> belong
> > > in
> > > Wicket, but that's the best we can do. Mayby the guys from commons are
> > > willing
> > > to take the code.
> > >
> > > What do you think?
> > >
> > > Best regards,
> > > Emond
> > >
> > > On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
> > > > Hi,
> > > >
> > > > What other improvements do we need in 8.x/master before promoting it
> to
> > > > 8.0.0 final ?
> > > >
> > > > At https://cwiki.apache.org/confluence/display/WICKET/
> > >
> > > Ideas+for+Wicket+8.0
> > >
> > > > we still have:
> > > >
> > > > - new DateTime APIs for wicket-datetime *WICKET-6105
> > > > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
> this
> > >
> > > one
> > >
> > > > more try but the problem is that I don't believe this is the proper
> way
> > >
> > > and
> > >
> > > > this demotivates me.
> > > > If someone else wants to give it a try - please assign it to
> yourself!
> > > >
> > > > - Better SEO for stateful pages - the only way I see this is by using
> > > > ServiceWorker to add the pageId as a request header to all requests
> > >
> > > (normal
> > >
> > > > & Ajax)
> > > >
> > > >
> > > > Recently I wondered whether Redux.js could be in use for Wicket.
> > > > I don't have much experience with it, but both React and AngularJs
> > > > communities use it to manage the state for their components.
> > > > There are some Java impls, even a standard is coming:
> > > > https://github.com/jvm-redux/jvm-redux-api
> > > >
> > > > What else ?
> > > >
> > > > Martin Grigorov
> > > > Wicket Training and Consulting
> > > > https://twitter.com/mtgrigorov
>
>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Emond Papegaaij <em...@topicus.nl>.
On maandag 31 oktober 2016 16:38:48 CET Martin Grigorov wrote:
> Hi Emond,
>
> On Mon, Oct 31, 2016 at 4:28 PM, Emond Papegaaij <emond.papegaaij@topicus.nl
> > wrote:
> >
> > Hi,
> >
> > I'm not sure about the duplicate functional interfaces in
> > org.apache.wicket.lambda. The current solution ties these interfaces to
> > Wicket, making it impossible to share function-libraries between wicket
> > and
> > non-wicket code.
> >
> > For example this method returns a function that prints a time with seconds
> > in
> >
> > the given locale:
> > public static WicketFunction<Instant, String>
> >
> > timeWithSeconds(final Supplier<Locale> localeSupplier) { ... }
>
> I am not sure this is true.
> The important thing is the Wicket APIs to use WicketXyz. This tells the
> compiler to use/create a java.lang.invoke.SerializedLambda.
> You can pass any kind of Xyz as an argument and it will work just fine.
Functional interfaces are just normal interfaces. A Function is not a
WicketFunction and a TopicusFunction is not a WicketFunction either. You can
create a serializable method reference to the apply method, but that's just
ugly. A method taking a WicketFunction will not accept a Function nor a
TopicusFunction. This is something we ran into when converting Guava code to
java.util interfaces.
>
> > The current WicketFunction is tied to wicket, so I cannot place this
> > function
> > in a shared library. When changing the type to java.util.Function, I
> > cannot
> > use it on pages, because it is not serializable. The only option that
> > remains
> >
> > is changing it to and constructing functions on the spot:
> > public static String timeWithSeconds(Instant instant, Locale locale) {
> >
> > ... }
> >
> > I propose to move the classes to a standalone maven module, rename them to
> > SerializableFunction (etc.) and let them implement Serializable (not
> > IClusterable). Maybe even change the package to something non-wicket.
> >
> > Also, the current interfaces do not override the default methods provided
> > by
> > the super-interfaces (such as compose and andThen). Using the methods on
> > the
> > current classes will give non-serializable versions of the interfaces.
> >
> > Finally, many commonly used interfaces are missing, such as: Runnable,
> > Predicate, BiPredicate and more. Perhaps we should duplicate all
> > FunctionalInterfaces, maybe only the ones most often used.
>
> I am not sure this is even needed and most definitely we cannot provide
> serializable version for all interfaces out there.
At Topicus we have the ones provided by Wicket, plus Runnable, Predicate and
BiPredicate. That seems to be fine for most cases. It is important to provide
all default methode though. Otherwise SerializablePredicate.negate() no longer
is serializable, and that's not what you would expect.
> > In all, I propose to create a simple library that provides many
> > serializable
> > versions of functional interfaces. I think such a library does not belong
> > in
> > Wicket, but that's the best we can do. Mayby the guys from commons are
> > willing
> > to take the code.
> >
> > What do you think?
> >
> > Best regards,
> > Emond
> >
> > On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
> > > Hi,
> > >
> > > What other improvements do we need in 8.x/master before promoting it to
> > > 8.0.0 final ?
> > >
> > > At https://cwiki.apache.org/confluence/display/WICKET/
> >
> > Ideas+for+Wicket+8.0
> >
> > > we still have:
> > >
> > > - new DateTime APIs for wicket-datetime *WICKET-6105
> > > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
> >
> > one
> >
> > > more try but the problem is that I don't believe this is the proper way
> >
> > and
> >
> > > this demotivates me.
> > > If someone else wants to give it a try - please assign it to yourself!
> > >
> > > - Better SEO for stateful pages - the only way I see this is by using
> > > ServiceWorker to add the pageId as a request header to all requests
> >
> > (normal
> >
> > > & Ajax)
> > >
> > >
> > > Recently I wondered whether Redux.js could be in use for Wicket.
> > > I don't have much experience with it, but both React and AngularJs
> > > communities use it to manage the state for their components.
> > > There are some Java impls, even a standard is coming:
> > > https://github.com/jvm-redux/jvm-redux-api
> > >
> > > What else ?
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Hi Emond,
On Mon, Oct 31, 2016 at 4:28 PM, Emond Papegaaij <emond.papegaaij@topicus.nl
> wrote:
> Hi,
>
> I'm not sure about the duplicate functional interfaces in
> org.apache.wicket.lambda. The current solution ties these interfaces to
> Wicket, making it impossible to share function-libraries between wicket and
> non-wicket code.
>
> For example this method returns a function that prints a time with seconds
> in
> the given locale:
>
> public static WicketFunction<Instant, String>
> timeWithSeconds(final Supplier<Locale> localeSupplier) { ... }
>
I am not sure this is true.
The important thing is the Wicket APIs to use WicketXyz. This tells the
compiler to use/create a java.lang.invoke.SerializedLambda.
You can pass any kind of Xyz as an argument and it will work just fine.
>
> The current WicketFunction is tied to wicket, so I cannot place this
> function
> in a shared library. When changing the type to java.util.Function, I cannot
> use it on pages, because it is not serializable. The only option that
> remains
> is changing it to and constructing functions on the spot:
>
> public static String timeWithSeconds(Instant instant, Locale locale) {
> ... }
>
> I propose to move the classes to a standalone maven module, rename them to
> SerializableFunction (etc.) and let them implement Serializable (not
> IClusterable). Maybe even change the package to something non-wicket.
>
> Also, the current interfaces do not override the default methods provided
> by
> the super-interfaces (such as compose and andThen). Using the methods on
> the
> current classes will give non-serializable versions of the interfaces.
>
> Finally, many commonly used interfaces are missing, such as: Runnable,
> Predicate, BiPredicate and more. Perhaps we should duplicate all
> FunctionalInterfaces, maybe only the ones most often used.
>
I am not sure this is even needed and most definitely we cannot provide
serializable version for all interfaces out there.
>
> In all, I propose to create a simple library that provides many
> serializable
> versions of functional interfaces. I think such a library does not belong
> in
> Wicket, but that's the best we can do. Mayby the guys from commons are
> willing
> to take the code.
>
> What do you think?
>
> Best regards,
> Emond
>
>
> On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
> > Hi,
> >
> > What other improvements do we need in 8.x/master before promoting it to
> > 8.0.0 final ?
> >
> > At https://cwiki.apache.org/confluence/display/WICKET/
> Ideas+for+Wicket+8.0
> > we still have:
> >
> > - new DateTime APIs for wicket-datetime *WICKET-6105
> > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
> one
> > more try but the problem is that I don't believe this is the proper way
> and
> > this demotivates me.
> > If someone else wants to give it a try - please assign it to yourself!
> >
> > - Better SEO for stateful pages - the only way I see this is by using
> > ServiceWorker to add the pageId as a request header to all requests
> (normal
> > & Ajax)
> >
> >
> > Recently I wondered whether Redux.js could be in use for Wicket.
> > I don't have much experience with it, but both React and AngularJs
> > communities use it to manage the state for their components.
> > There are some Java impls, even a standard is coming:
> > https://github.com/jvm-redux/jvm-redux-api
> >
> > What else ?
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
>
>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Emond Papegaaij <em...@topicus.nl>.
Hi,
I'm not sure about the duplicate functional interfaces in
org.apache.wicket.lambda. The current solution ties these interfaces to
Wicket, making it impossible to share function-libraries between wicket and
non-wicket code.
For example this method returns a function that prints a time with seconds in
the given locale:
public static WicketFunction<Instant, String>
timeWithSeconds(final Supplier<Locale> localeSupplier) { ... }
The current WicketFunction is tied to wicket, so I cannot place this function
in a shared library. When changing the type to java.util.Function, I cannot
use it on pages, because it is not serializable. The only option that remains
is changing it to and constructing functions on the spot:
public static String timeWithSeconds(Instant instant, Locale locale) { ... }
I propose to move the classes to a standalone maven module, rename them to
SerializableFunction (etc.) and let them implement Serializable (not
IClusterable). Maybe even change the package to something non-wicket.
Also, the current interfaces do not override the default methods provided by
the super-interfaces (such as compose and andThen). Using the methods on the
current classes will give non-serializable versions of the interfaces.
Finally, many commonly used interfaces are missing, such as: Runnable,
Predicate, BiPredicate and more. Perhaps we should duplicate all
FunctionalInterfaces, maybe only the ones most often used.
In all, I propose to create a simple library that provides many serializable
versions of functional interfaces. I think such a library does not belong in
Wicket, but that's the best we can do. Mayby the guys from commons are willing
to take the code.
What do you think?
Best regards,
Emond
On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
> Hi,
>
> What other improvements do we need in 8.x/master before promoting it to
> 8.0.0 final ?
>
> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0
> we still have:
>
> - new DateTime APIs for wicket-datetime *WICKET-6105
> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
> more try but the problem is that I don't believe this is the proper way and
> this demotivates me.
> If someone else wants to give it a try - please assign it to yourself!
>
> - Better SEO for stateful pages - the only way I see this is by using
> ServiceWorker to add the pageId as a request header to all requests (normal
> & Ajax)
>
>
> Recently I wondered whether Redux.js could be in use for Wicket.
> I don't have much experience with it, but both React and AngularJs
> communities use it to manage the state for their components.
> There are some Java impls, even a standard is coming:
> https://github.com/jvm-redux/jvm-redux-api
>
> What else ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
Re: What else do we want to do before 8.0.0 final ?
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi Sven,
great! Let us hear from you if this works well or not! :-)
kind regards
Tobias
> Am 31.10.2016 um 15:24 schrieb Sven Meier <sv...@meiers.net>:
>
> Hi,
>
> IMHO 8.x is ready to be promoted to final, as I don't see any additional major changes for it.
>
> I'll be upgrading a big application from 6.x soon, and I'd love to target 8.x instead of 7.x
>
> Sven
>
>
>> Am 31.10.2016 um 14:41 schrieb Martin Grigorov:
>> Hi,
>>
>> What other improvements do we need in 8.x/master before promoting it to
>> 8.0.0 final ?
>>
>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0
>> we still have:
>>
>> - new DateTime APIs for wicket-datetime *WICKET-6105
>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
>> more try but the problem is that I don't believe this is the proper way and
>> this demotivates me.
>> If someone else wants to give it a try - please assign it to yourself!
>>
>> - Better SEO for stateful pages - the only way I see this is by using
>> ServiceWorker to add the pageId as a request header to all requests (normal
>> & Ajax)
>>
>>
>> Recently I wondered whether Redux.js could be in use for Wicket.
>> I don't have much experience with it, but both React and AngularJs
>> communities use it to manage the state for their components.
>> There are some Java impls, even a standard is coming:
>> https://github.com/jvm-redux/jvm-redux-api
>>
>> What else ?
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Andrea Del Bene <an...@gmail.com>.
On 31/10/2016 15:24, Sven Meier wrote:
> Hi,
>
> IMHO 8.x is ready to be promoted to final, as I don't see any
> additional major changes for it.
>
> I'll be upgrading a big application from 6.x soon, and I'd love to
> target 8.x instead of 7.x
>
> Sven
+1
>
>
> Am 31.10.2016 um 14:41 schrieb Martin Grigorov:
>> Hi,
>>
>> What other improvements do we need in 8.x/master before promoting it to
>> 8.0.0 final ?
>>
>> At
>> https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0
>> we still have:
>>
>> - new DateTime APIs for wicket-datetime *WICKET-6105
>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
>> one
>> more try but the problem is that I don't believe this is the proper
>> way and
>> this demotivates me.
>> If someone else wants to give it a try - please assign it to yourself!
>>
>> - Better SEO for stateful pages - the only way I see this is by using
>> ServiceWorker to add the pageId as a request header to all requests
>> (normal
>> & Ajax)
>>
>>
>> Recently I wondered whether Redux.js could be in use for Wicket.
>> I don't have much experience with it, but both React and AngularJs
>> communities use it to manage the state for their components.
>> There are some Java impls, even a standard is coming:
>> https://github.com/jvm-redux/jvm-redux-api
>>
>> What else ?
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Actually https://issues.apache.org/jira/browse/WICKET-6247 (the new parser
for property expressions) is still open.
@Pedro: what is the status here ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Oct 31, 2016 at 6:52 PM, Sven Meier <sv...@meiers.net> wrote:
> Hi,
>
> >try to upgrade before we release the final.
> >This way you can find bugs/improvements before the "API break freeze".
>
> this was the idea: With 8.x final closing in, I might be able to persuade
> the project owners.
>
> Regards
> Sven
>
>
>
> Am 31.10.2016 um 16:09 schrieb Martin Grigorov:
>
>> On Mon, Oct 31, 2016 at 3:24 PM, Sven Meier <sv...@meiers.net> wrote:
>>
>> Hi,
>>>
>>> IMHO 8.x is ready to be promoted to final, as I don't see any additional
>>> major changes for it.
>>>
>>> I'll be upgrading a big application from 6.x soon, and I'd love to target
>>> 8.x instead of 7.x
>>>
>>> It would be good if you can try to upgrade before we release the final.
>> This way you can find bugs/improvements before the "API break freeze".
>>
>> I've migrated my current application to 8.0.0-M1 in a branch and I keep it
>> up-to-date to be able to test 8.x milestones.
>> As soon as you are ready and there are no major issues found we could
>> release 8.0.0 final.
>>
>>
>> Sven
>>>
>>>
>>> Am 31.10.2016 um 14:41 schrieb Martin Grigorov:
>>>
>>> Hi,
>>>>
>>>> What other improvements do we need in 8.x/master before promoting it to
>>>> 8.0.0 final ?
>>>>
>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>>> for+Wicket+8.0
>>>> we still have:
>>>>
>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
>>>> one
>>>> more try but the problem is that I don't believe this is the proper way
>>>> and
>>>> this demotivates me.
>>>> If someone else wants to give it a try - please assign it to yourself!
>>>>
>>>> - Better SEO for stateful pages - the only way I see this is by using
>>>> ServiceWorker to add the pageId as a request header to all requests
>>>> (normal
>>>> & Ajax)
>>>>
>>>>
>>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>>> I don't have much experience with it, but both React and AngularJs
>>>> communities use it to manage the state for their components.
>>>> There are some Java impls, even a standard is coming:
>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>
>>>> What else ?
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>>
>>>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Sven Meier <sv...@meiers.net>.
Hi,
>try to upgrade before we release the final.
>This way you can find bugs/improvements before the "API break freeze".
this was the idea: With 8.x final closing in, I might be able to
persuade the project owners.
Regards
Sven
Am 31.10.2016 um 16:09 schrieb Martin Grigorov:
> On Mon, Oct 31, 2016 at 3:24 PM, Sven Meier <sv...@meiers.net> wrote:
>
>> Hi,
>>
>> IMHO 8.x is ready to be promoted to final, as I don't see any additional
>> major changes for it.
>>
>> I'll be upgrading a big application from 6.x soon, and I'd love to target
>> 8.x instead of 7.x
>>
> It would be good if you can try to upgrade before we release the final.
> This way you can find bugs/improvements before the "API break freeze".
>
> I've migrated my current application to 8.0.0-M1 in a branch and I keep it
> up-to-date to be able to test 8.x milestones.
> As soon as you are ready and there are no major issues found we could
> release 8.0.0 final.
>
>
>> Sven
>>
>>
>> Am 31.10.2016 um 14:41 schrieb Martin Grigorov:
>>
>>> Hi,
>>>
>>> What other improvements do we need in 8.x/master before promoting it to
>>> 8.0.0 final ?
>>>
>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>> for+Wicket+8.0
>>> we still have:
>>>
>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
>>> more try but the problem is that I don't believe this is the proper way
>>> and
>>> this demotivates me.
>>> If someone else wants to give it a try - please assign it to yourself!
>>>
>>> - Better SEO for stateful pages - the only way I see this is by using
>>> ServiceWorker to add the pageId as a request header to all requests
>>> (normal
>>> & Ajax)
>>>
>>>
>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>> I don't have much experience with it, but both React and AngularJs
>>> communities use it to manage the state for their components.
>>> There are some Java impls, even a standard is coming:
>>> https://github.com/jvm-redux/jvm-redux-api
>>>
>>> What else ?
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Oct 31, 2016 at 3:24 PM, Sven Meier <sv...@meiers.net> wrote:
> Hi,
>
> IMHO 8.x is ready to be promoted to final, as I don't see any additional
> major changes for it.
>
> I'll be upgrading a big application from 6.x soon, and I'd love to target
> 8.x instead of 7.x
>
It would be good if you can try to upgrade before we release the final.
This way you can find bugs/improvements before the "API break freeze".
I've migrated my current application to 8.0.0-M1 in a branch and I keep it
up-to-date to be able to test 8.x milestones.
As soon as you are ready and there are no major issues found we could
release 8.0.0 final.
>
> Sven
>
>
> Am 31.10.2016 um 14:41 schrieb Martin Grigorov:
>
>> Hi,
>>
>> What other improvements do we need in 8.x/master before promoting it to
>> 8.0.0 final ?
>>
>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>> for+Wicket+8.0
>> we still have:
>>
>> - new DateTime APIs for wicket-datetime *WICKET-6105
>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
>> more try but the problem is that I don't believe this is the proper way
>> and
>> this demotivates me.
>> If someone else wants to give it a try - please assign it to yourself!
>>
>> - Better SEO for stateful pages - the only way I see this is by using
>> ServiceWorker to add the pageId as a request header to all requests
>> (normal
>> & Ajax)
>>
>>
>> Recently I wondered whether Redux.js could be in use for Wicket.
>> I don't have much experience with it, but both React and AngularJs
>> communities use it to manage the state for their components.
>> There are some Java impls, even a standard is coming:
>> https://github.com/jvm-redux/jvm-redux-api
>>
>> What else ?
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Sven Meier <sv...@meiers.net>.
Hi,
IMHO 8.x is ready to be promoted to final, as I don't see any additional
major changes for it.
I'll be upgrading a big application from 6.x soon, and I'd love to
target 8.x instead of 7.x
Sven
Am 31.10.2016 um 14:41 schrieb Martin Grigorov:
> Hi,
>
> What other improvements do we need in 8.x/master before promoting it to
> 8.0.0 final ?
>
> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0
> we still have:
>
> - new DateTime APIs for wicket-datetime *WICKET-6105
> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
> more try but the problem is that I don't believe this is the proper way and
> this demotivates me.
> If someone else wants to give it a try - please assign it to yourself!
>
> - Better SEO for stateful pages - the only way I see this is by using
> ServiceWorker to add the pageId as a request header to all requests (normal
> & Ajax)
>
>
> Recently I wondered whether Redux.js could be in use for Wicket.
> I don't have much experience with it, but both React and AngularJs
> communities use it to manage the state for their components.
> There are some Java impls, even a standard is coming:
> https://github.com/jvm-redux/jvm-redux-api
>
> What else ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
On Thu, Nov 10, 2016 at 2:47 PM, Marcel Barbosa Pinto <
marcel.power@gmail.com> wrote:
> Another idea.
>
> Reactive programing is trending now, frameworks like Spring (v5) are
> rewriting it's core using the project reactor and rxJava. Java 9 will also
> add support for it.
> I was just wondering if Wicket could use reactive patterns for things like
> behaviours, events, components, models, request cycle etc.
>
> I don't know how complex would be to implement it, what do you guys think
> (Maybe for Wicket 9)?
>
Yes, Wicket 9. Unless someone has pretty clear picture what should be done.
P.S. I still wonder why Play Framework, Akka HTTP, and some other reactive
web frameworks show pretty bad results at
https://www.techempower.com/benchmarks/previews/round13.
Only Vertx has good results!
>
>
>
>
>
> On Thu, Nov 10, 2016 at 10:52 AM, Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Hi Peter,
> >
> >
> > On Thu, Nov 10, 2016 at 1:44 PM, Peter Henderson <
> > peter.henderson@starjar.com> wrote:
> >
> > > Hi
> > >
> > > > What other improvements do we need in 8.x/master before promoting it
> to
> > >
> > > > > 8.0.0 final ?
> > > >
> > >
> > > A bit late. But one idea I've had in the back of my mind for a long
> > while.
> > > (I may well be barking up the wrong tree here..)
> > >
> > >
> > > Break IPageStore.
> > > Replace the simple int pageId identifier with a bit more detail.
> > >
> > > When pages are mounted to a path the path should be considered when
> > getting
> > > pages from the page store.
> > > e.g
> > > User A is looking at page
> > > www.example.com/pageA?5
> > >
> > >
> > > User B is looking at page
> > > www.example.com/pageB?5
> > >
> > > User A emails their url to B. When B clicks on the link he incorrectly
> > sees
> > > pageB because that page has the same pageId
> > >
> >
> > This is not the current behavior.
> > Currently if User A sends www.example.com/pageA?5 to User B then Wicket
> > will detect that page with id=5 is not from type PageA and won't render
> it.
> > Instead Wicket will create a new instance ot PageA and show it.
> >
> >
> > >
> > >
> > >
> > >
> > >
> > > > >
> > > > > At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for
> > > > +Wicket+8.0
> > > > > we still have:
> > > > >
> > > > > - new DateTime APIs for wicket-datetime *WICKET-6105
> > > > > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
> > this
> > > > one
> > > > > more try but the problem is that I don't believe this is the proper
> > way
> > > > and
> > > > > this demotivates me.
> > > > > If someone else wants to give it a try - please assign it to
> > yourself!
> > > > >
> > > > > - Better SEO for stateful pages - the only way I see this is by
> using
> > > > > ServiceWorker to add the pageId as a request header to all requests
> > > > (normal
> > > > > & Ajax)
> > > > >
> > > > >
> > > > > Recently I wondered whether Redux.js could be in use for Wicket.
> > > > > I don't have much experience with it, but both React and AngularJs
> > > > > communities use it to manage the state for their components.
> > > > > There are some Java impls, even a standard is coming:
> > > > https://github.com/
> > > > > jvm-redux/jvm-redux-api
> > > > >
> > > > > What else ?
> > > > >
> > > > > Martin Grigorov
> > > > > Wicket Training and Consulting
> > > > > https://twitter.com/mtgrigorov
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > Peter Henderson
> > >
> >
>
>
>
> --
>
> Marcel Barbosa Pinto
> 55 11 98255 8288
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Marcel Barbosa Pinto <ma...@gmail.com>.
Another idea.
Reactive programing is trending now, frameworks like Spring (v5) are
rewriting it's core using the project reactor and rxJava. Java 9 will also
add support for it.
I was just wondering if Wicket could use reactive patterns for things like
behaviours, events, components, models, request cycle etc.
I don't know how complex would be to implement it, what do you guys think
(Maybe for Wicket 9)?
On Thu, Nov 10, 2016 at 10:52 AM, Martin Grigorov <mg...@apache.org>
wrote:
> Hi Peter,
>
>
> On Thu, Nov 10, 2016 at 1:44 PM, Peter Henderson <
> peter.henderson@starjar.com> wrote:
>
> > Hi
> >
> > > What other improvements do we need in 8.x/master before promoting it to
> >
> > > > 8.0.0 final ?
> > >
> >
> > A bit late. But one idea I've had in the back of my mind for a long
> while.
> > (I may well be barking up the wrong tree here..)
> >
> >
> > Break IPageStore.
> > Replace the simple int pageId identifier with a bit more detail.
> >
> > When pages are mounted to a path the path should be considered when
> getting
> > pages from the page store.
> > e.g
> > User A is looking at page
> > www.example.com/pageA?5
> >
> >
> > User B is looking at page
> > www.example.com/pageB?5
> >
> > User A emails their url to B. When B clicks on the link he incorrectly
> sees
> > pageB because that page has the same pageId
> >
>
> This is not the current behavior.
> Currently if User A sends www.example.com/pageA?5 to User B then Wicket
> will detect that page with id=5 is not from type PageA and won't render it.
> Instead Wicket will create a new instance ot PageA and show it.
>
>
> >
> >
> >
> >
> >
> > > >
> > > > At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for
> > > +Wicket+8.0
> > > > we still have:
> > > >
> > > > - new DateTime APIs for wicket-datetime *WICKET-6105
> > > > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
> this
> > > one
> > > > more try but the problem is that I don't believe this is the proper
> way
> > > and
> > > > this demotivates me.
> > > > If someone else wants to give it a try - please assign it to
> yourself!
> > > >
> > > > - Better SEO for stateful pages - the only way I see this is by using
> > > > ServiceWorker to add the pageId as a request header to all requests
> > > (normal
> > > > & Ajax)
> > > >
> > > >
> > > > Recently I wondered whether Redux.js could be in use for Wicket.
> > > > I don't have much experience with it, but both React and AngularJs
> > > > communities use it to manage the state for their components.
> > > > There are some Java impls, even a standard is coming:
> > > https://github.com/
> > > > jvm-redux/jvm-redux-api
> > > >
> > > > What else ?
> > > >
> > > > Martin Grigorov
> > > > Wicket Training and Consulting
> > > > https://twitter.com/mtgrigorov
> > > >
> > >
> >
> >
> >
> > --
> > Peter Henderson
> >
>
--
Marcel Barbosa Pinto
55 11 98255 8288
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Hi Peter,
On Thu, Nov 10, 2016 at 1:44 PM, Peter Henderson <
peter.henderson@starjar.com> wrote:
> Hi
>
> > What other improvements do we need in 8.x/master before promoting it to
>
> > > 8.0.0 final ?
> >
>
> A bit late. But one idea I've had in the back of my mind for a long while.
> (I may well be barking up the wrong tree here..)
>
>
> Break IPageStore.
> Replace the simple int pageId identifier with a bit more detail.
>
> When pages are mounted to a path the path should be considered when getting
> pages from the page store.
> e.g
> User A is looking at page
> www.example.com/pageA?5
>
>
> User B is looking at page
> www.example.com/pageB?5
>
> User A emails their url to B. When B clicks on the link he incorrectly sees
> pageB because that page has the same pageId
>
This is not the current behavior.
Currently if User A sends www.example.com/pageA?5 to User B then Wicket
will detect that page with id=5 is not from type PageA and won't render it.
Instead Wicket will create a new instance ot PageA and show it.
>
>
>
>
>
> > >
> > > At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for
> > +Wicket+8.0
> > > we still have:
> > >
> > > - new DateTime APIs for wicket-datetime *WICKET-6105
> > > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
> > one
> > > more try but the problem is that I don't believe this is the proper way
> > and
> > > this demotivates me.
> > > If someone else wants to give it a try - please assign it to yourself!
> > >
> > > - Better SEO for stateful pages - the only way I see this is by using
> > > ServiceWorker to add the pageId as a request header to all requests
> > (normal
> > > & Ajax)
> > >
> > >
> > > Recently I wondered whether Redux.js could be in use for Wicket.
> > > I don't have much experience with it, but both React and AngularJs
> > > communities use it to manage the state for their components.
> > > There are some Java impls, even a standard is coming:
> > https://github.com/
> > > jvm-redux/jvm-redux-api
> > >
> > > What else ?
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> >
>
>
>
> --
> Peter Henderson
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Peter Henderson <pe...@starjar.com>.
Hi
> What other improvements do we need in 8.x/master before promoting it to
> > 8.0.0 final ?
>
A bit late. But one idea I've had in the back of my mind for a long while.
(I may well be barking up the wrong tree here..)
Break IPageStore.
Replace the simple int pageId identifier with a bit more detail.
When pages are mounted to a path the path should be considered when getting
pages from the page store.
e.g
User A is looking at page
www.example.com/pageA?5
User B is looking at page
www.example.com/pageB?5
User A emails their url to B. When B clicks on the link he incorrectly sees
pageB because that page has the same pageId
> >
> > At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for
> +Wicket+8.0
> > we still have:
> >
> > - new DateTime APIs for wicket-datetime *WICKET-6105
> > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
> one
> > more try but the problem is that I don't believe this is the proper way
> and
> > this demotivates me.
> > If someone else wants to give it a try - please assign it to yourself!
> >
> > - Better SEO for stateful pages - the only way I see this is by using
> > ServiceWorker to add the pageId as a request header to all requests
> (normal
> > & Ajax)
> >
> >
> > Recently I wondered whether Redux.js could be in use for Wicket.
> > I don't have much experience with it, but both React and AngularJs
> > communities use it to manage the state for their components.
> > There are some Java impls, even a standard is coming:
> https://github.com/
> > jvm-redux/jvm-redux-api
> >
> > What else ?
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
>
--
Peter Henderson
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
On Mon, Oct 31, 2016 at 3:19 PM, Marcel Barbosa Pinto <
marcel.power@gmail.com> wrote:
> For adding components we usually write some thing like this:
>
> Form f = new Form();
> add(f);
> RepeatingView imageList;
> f.add(imageList = new RepeatingView("imageList"));
>
> or
>
> Form f = new Form();
> add(f);
> RepeatingView imageList = new RepeatingView("imageList");
> f.add(imageList);
>
> You think this could be useful?
>
> Form f = new Form().addTo(this);
> new RepeatingView("imageList").addTo(f);
>
> Adding:
>
> Component.addTo(targetComponent);
>
This is not an API break so it could be added at any branch at any time.
> Component.replaceFrom(targetComponent);
>
There is #replaceWith() for this.
> Component.removeFrom(targetComponent);
>
Here there is only one option: #removeFromParent() because a component
cannot be a child of several parents (like in real life). It is valid for
Behaviors though!
I'd suggest you to play a bit with your idea to clear it out and start a
new thread and suggest it.
>
> Cheers.
>
>
> On Mon, Oct 31, 2016 at 11:48 AM, Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Forwarding to users@wicket.apache.org
> >
> > GMail autosuggest tricked me to send it to users@isis.apache.org.
> >
> > On Mon, Oct 31, 2016 at 2:41 PM, Martin Grigorov <mg...@apache.org>
> > wrote:
> >
> > > Hi,
> > >
> > > What other improvements do we need in 8.x/master before promoting it to
> > > 8.0.0 final ?
> > >
> > > At https://cwiki.apache.org/confluence/display/WICKET/
> > Ideas+for+Wicket+8.0
> > > we still have:
> > >
> > > - new DateTime APIs for wicket-datetime *WICKET-6105
> > > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
> > one
> > > more try but the problem is that I don't believe this is the proper way
> > and
> > > this demotivates me.
> > > If someone else wants to give it a try - please assign it to yourself!
> > >
> > > - Better SEO for stateful pages - the only way I see this is by using
> > > ServiceWorker to add the pageId as a request header to all requests
> > (normal
> > > & Ajax)
> > >
> > >
> > > Recently I wondered whether Redux.js could be in use for Wicket.
> > > I don't have much experience with it, but both React and AngularJs
> > > communities use it to manage the state for their components.
> > > There are some Java impls, even a standard is coming:
> > https://github.com/
> > > jvm-redux/jvm-redux-api
> > >
> > > What else ?
> > >
> > > Martin Grigorov
> > > Wicket Training and Consulting
> > > https://twitter.com/mtgrigorov
> > >
> >
>
>
>
> --
>
> Marcel Barbosa Pinto
> 55 11 98255 8288
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Marcel Barbosa Pinto <ma...@gmail.com>.
For adding components we usually write some thing like this:
Form f = new Form();
add(f);
RepeatingView imageList;
f.add(imageList = new RepeatingView("imageList"));
or
Form f = new Form();
add(f);
RepeatingView imageList = new RepeatingView("imageList");
f.add(imageList);
You think this could be useful?
Form f = new Form().addTo(this);
new RepeatingView("imageList").addTo(f);
Adding:
Component.addTo(targetComponent);
Component.replaceFrom(targetComponent);
Component.removeFrom(targetComponent);
Cheers.
On Mon, Oct 31, 2016 at 11:48 AM, Martin Grigorov <mg...@apache.org>
wrote:
> Forwarding to users@wicket.apache.org
>
> GMail autosuggest tricked me to send it to users@isis.apache.org.
>
> On Mon, Oct 31, 2016 at 2:41 PM, Martin Grigorov <mg...@apache.org>
> wrote:
>
> > Hi,
> >
> > What other improvements do we need in 8.x/master before promoting it to
> > 8.0.0 final ?
> >
> > At https://cwiki.apache.org/confluence/display/WICKET/
> Ideas+for+Wicket+8.0
> > we still have:
> >
> > - new DateTime APIs for wicket-datetime *WICKET-6105
> > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
> one
> > more try but the problem is that I don't believe this is the proper way
> and
> > this demotivates me.
> > If someone else wants to give it a try - please assign it to yourself!
> >
> > - Better SEO for stateful pages - the only way I see this is by using
> > ServiceWorker to add the pageId as a request header to all requests
> (normal
> > & Ajax)
> >
> >
> > Recently I wondered whether Redux.js could be in use for Wicket.
> > I don't have much experience with it, but both React and AngularJs
> > communities use it to manage the state for their components.
> > There are some Java impls, even a standard is coming:
> https://github.com/
> > jvm-redux/jvm-redux-api
> >
> > What else ?
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
>
--
Marcel Barbosa Pinto
55 11 98255 8288
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Forwarding to users@wicket.apache.org
GMail autosuggest tricked me to send it to users@isis.apache.org.
On Mon, Oct 31, 2016 at 2:41 PM, Martin Grigorov <mg...@apache.org>
wrote:
> Hi,
>
> What other improvements do we need in 8.x/master before promoting it to
> 8.0.0 final ?
>
> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0
> we still have:
>
> - new DateTime APIs for wicket-datetime *WICKET-6105
> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
> more try but the problem is that I don't believe this is the proper way and
> this demotivates me.
> If someone else wants to give it a try - please assign it to yourself!
>
> - Better SEO for stateful pages - the only way I see this is by using
> ServiceWorker to add the pageId as a request header to all requests (normal
> & Ajax)
>
>
> Recently I wondered whether Redux.js could be in use for Wicket.
> I don't have much experience with it, but both React and AngularJs
> communities use it to manage the state for their components.
> There are some Java impls, even a standard is coming: https://github.com/
> jvm-redux/jvm-redux-api
>
> What else ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Hi Emond,
I don't really see the need to merge the code into one module and to remove
he abstractions.
There is indeed no need of the abstractions anymore but also they do not do
any harm.
The only need I can foresee is WebSocket 2.0 in JEE, but with the current
speed of development of JEE this might be never.
I agree that the demo app could be merged to examples!
I see that OpenShift started providing WildFly 10 so we can create
examples8x.apache.wicket.org for 8.x.
I'll do it in the coming days.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Jan 13, 2017 at 8:56 PM, Emond Papegaaij <emond.papegaaij@topicus.nl
> wrote:
> Hi Martin,
>
> I noticed you didn't waste any time on this. Thanks for that!
>
> Do you think we should keep the separation between core and javax? I
> don't think we will ever build an integration with a different api.
> Perhaps we can also simplify the code afterwards, because this
> abstraction over different apis is not needed anymore.
>
> Emond
>
> On Fri, Jan 13, 2017 at 3:02 PM, Martin Grigorov <mg...@apache.org>
> wrote:
> > On Fri, Jan 13, 2017 at 10:46 AM, Emond Papegaaij <
> > emond.papegaaij@topicus.nl> wrote:
> >
> >> Hi,
> >>
> >> I was wondering if we still need to support Tomcat 7.0 with native
> >> websockets.
> >> As far as I can see, Tomcat 8.0 and 8.5 both support JSR 356 and Tomcat
> 7.0
> >> does not support Servlet 3.1, which is required for Wicket 8.
> Therefore, I
> >> think we should drop the wicket-native-websocket-tomcat module. Perhaps
> we
> >> should also merge javax into core and place the examples with the other
> >> examples.
> >>
> >>
> > Agreed!
> >
> >
> >> With websockets becomming more and more standard, I'm not sure we still
> >> need
> >> wicket-atmosphere. wicket-native-websocket provides the same
> functionallity
> >> and more. Also, Atmosphere has a history of bugs and problems. I
> wouldn't
> >> recommend anyone to use it.
> >>
> >
> > Agreed!
> >
> >
> >>
> >> Best regards,
> >> Emond
> >>
> >> On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
> >> > Hi,
> >> >
> >> > What other improvements do we need in 8.x/master before promoting it
> to
> >> > 8.0.0 final ?
> >> >
> >> > At https://cwiki.apache.org/confluence/display/WICKET/
> >> Ideas+for+Wicket+8.0
> >> > we still have:
> >> >
> >> > - new DateTime APIs for wicket-datetime *WICKET-6105
> >> > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
> >> one
> >> > more try but the problem is that I don't believe this is the proper
> way
> >> and
> >> > this demotivates me.
> >> > If someone else wants to give it a try - please assign it to yourself!
> >> >
> >> > - Better SEO for stateful pages - the only way I see this is by using
> >> > ServiceWorker to add the pageId as a request header to all requests
> >> (normal
> >> > & Ajax)
> >> >
> >> >
> >> > Recently I wondered whether Redux.js could be in use for Wicket.
> >> > I don't have much experience with it, but both React and AngularJs
> >> > communities use it to manage the state for their components.
> >> > There are some Java impls, even a standard is coming:
> >> > https://github.com/jvm-redux/jvm-redux-api
> >> >
> >> > What else ?
> >> >
> >> > Martin Grigorov
> >> > Wicket Training and Consulting
> >> > https://twitter.com/mtgrigorov
> >>
> >>
> >>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Emond Papegaaij <em...@topicus.nl>.
Hi Martin,
I noticed you didn't waste any time on this. Thanks for that!
Do you think we should keep the separation between core and javax? I
don't think we will ever build an integration with a different api.
Perhaps we can also simplify the code afterwards, because this
abstraction over different apis is not needed anymore.
Emond
On Fri, Jan 13, 2017 at 3:02 PM, Martin Grigorov <mg...@apache.org> wrote:
> On Fri, Jan 13, 2017 at 10:46 AM, Emond Papegaaij <
> emond.papegaaij@topicus.nl> wrote:
>
>> Hi,
>>
>> I was wondering if we still need to support Tomcat 7.0 with native
>> websockets.
>> As far as I can see, Tomcat 8.0 and 8.5 both support JSR 356 and Tomcat 7.0
>> does not support Servlet 3.1, which is required for Wicket 8. Therefore, I
>> think we should drop the wicket-native-websocket-tomcat module. Perhaps we
>> should also merge javax into core and place the examples with the other
>> examples.
>>
>>
> Agreed!
>
>
>> With websockets becomming more and more standard, I'm not sure we still
>> need
>> wicket-atmosphere. wicket-native-websocket provides the same functionallity
>> and more. Also, Atmosphere has a history of bugs and problems. I wouldn't
>> recommend anyone to use it.
>>
>
> Agreed!
>
>
>>
>> Best regards,
>> Emond
>>
>> On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
>> > Hi,
>> >
>> > What other improvements do we need in 8.x/master before promoting it to
>> > 8.0.0 final ?
>> >
>> > At https://cwiki.apache.org/confluence/display/WICKET/
>> Ideas+for+Wicket+8.0
>> > we still have:
>> >
>> > - new DateTime APIs for wicket-datetime *WICKET-6105
>> > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
>> one
>> > more try but the problem is that I don't believe this is the proper way
>> and
>> > this demotivates me.
>> > If someone else wants to give it a try - please assign it to yourself!
>> >
>> > - Better SEO for stateful pages - the only way I see this is by using
>> > ServiceWorker to add the pageId as a request header to all requests
>> (normal
>> > & Ajax)
>> >
>> >
>> > Recently I wondered whether Redux.js could be in use for Wicket.
>> > I don't have much experience with it, but both React and AngularJs
>> > communities use it to manage the state for their components.
>> > There are some Java impls, even a standard is coming:
>> > https://github.com/jvm-redux/jvm-redux-api
>> >
>> > What else ?
>> >
>> > Martin Grigorov
>> > Wicket Training and Consulting
>> > https://twitter.com/mtgrigorov
>>
>>
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Maxim Solodovnik <so...@gmail.com>.
Also +1 :))
On Sat, Jan 14, 2017 at 12:22 AM, Sebastien <se...@gmail.com> wrote:
> triple! :)
>
> On Jan 13, 2017 15:09, "Andrea Del Bene" <an...@gmail.com> wrote:
>
> double agree!
>
>
>
> On 13/01/2017 15:02, Martin Grigorov wrote:
>
>> On Fri, Jan 13, 2017 at 10:46 AM, Emond Papegaaij <
>> emond.papegaaij@topicus.nl> wrote:
>>
>> Hi,
>>>
>>> I was wondering if we still need to support Tomcat 7.0 with native
>>> websockets.
>>> As far as I can see, Tomcat 8.0 and 8.5 both support JSR 356 and Tomcat
>>> 7.0
>>> does not support Servlet 3.1, which is required for Wicket 8. Therefore, I
>>> think we should drop the wicket-native-websocket-tomcat module. Perhaps we
>>> should also merge javax into core and place the examples with the other
>>> examples.
>>>
>>>
>>> Agreed!
>>
>>
>> With websockets becomming more and more standard, I'm not sure we still
>>> need
>>> wicket-atmosphere. wicket-native-websocket provides the same
>>> functionallity
>>> and more. Also, Atmosphere has a history of bugs and problems. I wouldn't
>>> recommend anyone to use it.
>>>
>>> Agreed!
>>
>>
>> Best regards,
>>> Emond
>>>
>>> On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
>>>
>>>> Hi,
>>>>
>>>> What other improvements do we need in 8.x/master before promoting it to
>>>> 8.0.0 final ?
>>>>
>>>> At https://cwiki.apache.org/confluence/display/WICKET/
>>>>
>>> Ideas+for+Wicket+8.0
>>>
>>>> we still have:
>>>>
>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
>>>>
>>> one
>>>
>>>> more try but the problem is that I don't believe this is the proper way
>>>>
>>> and
>>>
>>>> this demotivates me.
>>>> If someone else wants to give it a try - please assign it to yourself!
>>>>
>>>> - Better SEO for stateful pages - the only way I see this is by using
>>>> ServiceWorker to add the pageId as a request header to all requests
>>>>
>>> (normal
>>>
>>>> & Ajax)
>>>>
>>>>
>>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>>> I don't have much experience with it, but both React and AngularJs
>>>> communities use it to manage the state for their components.
>>>> There are some Java impls, even a standard is coming:
>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>
>>>> What else ?
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>
>>>
>>>
--
WBR
Maxim aka solomax
Re: What else do we want to do before 8.0.0 final ?
Posted by Sebastien <se...@gmail.com>.
triple! :)
On Jan 13, 2017 15:09, "Andrea Del Bene" <an...@gmail.com> wrote:
double agree!
On 13/01/2017 15:02, Martin Grigorov wrote:
> On Fri, Jan 13, 2017 at 10:46 AM, Emond Papegaaij <
> emond.papegaaij@topicus.nl> wrote:
>
> Hi,
>>
>> I was wondering if we still need to support Tomcat 7.0 with native
>> websockets.
>> As far as I can see, Tomcat 8.0 and 8.5 both support JSR 356 and Tomcat
>> 7.0
>> does not support Servlet 3.1, which is required for Wicket 8. Therefore, I
>> think we should drop the wicket-native-websocket-tomcat module. Perhaps we
>> should also merge javax into core and place the examples with the other
>> examples.
>>
>>
>> Agreed!
>
>
> With websockets becomming more and more standard, I'm not sure we still
>> need
>> wicket-atmosphere. wicket-native-websocket provides the same
>> functionallity
>> and more. Also, Atmosphere has a history of bugs and problems. I wouldn't
>> recommend anyone to use it.
>>
>> Agreed!
>
>
> Best regards,
>> Emond
>>
>> On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
>>
>>> Hi,
>>>
>>> What other improvements do we need in 8.x/master before promoting it to
>>> 8.0.0 final ?
>>>
>>> At https://cwiki.apache.org/confluence/display/WICKET/
>>>
>> Ideas+for+Wicket+8.0
>>
>>> we still have:
>>>
>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
>>>
>> one
>>
>>> more try but the problem is that I don't believe this is the proper way
>>>
>> and
>>
>>> this demotivates me.
>>> If someone else wants to give it a try - please assign it to yourself!
>>>
>>> - Better SEO for stateful pages - the only way I see this is by using
>>> ServiceWorker to add the pageId as a request header to all requests
>>>
>> (normal
>>
>>> & Ajax)
>>>
>>>
>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>> I don't have much experience with it, but both React and AngularJs
>>> communities use it to manage the state for their components.
>>> There are some Java impls, even a standard is coming:
>>> https://github.com/jvm-redux/jvm-redux-api
>>>
>>> What else ?
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>
>>
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Andrea Del Bene <an...@gmail.com>.
double agree!
On 13/01/2017 15:02, Martin Grigorov wrote:
> On Fri, Jan 13, 2017 at 10:46 AM, Emond Papegaaij <
> emond.papegaaij@topicus.nl> wrote:
>
>> Hi,
>>
>> I was wondering if we still need to support Tomcat 7.0 with native
>> websockets.
>> As far as I can see, Tomcat 8.0 and 8.5 both support JSR 356 and Tomcat 7.0
>> does not support Servlet 3.1, which is required for Wicket 8. Therefore, I
>> think we should drop the wicket-native-websocket-tomcat module. Perhaps we
>> should also merge javax into core and place the examples with the other
>> examples.
>>
>>
> Agreed!
>
>
>> With websockets becomming more and more standard, I'm not sure we still
>> need
>> wicket-atmosphere. wicket-native-websocket provides the same functionallity
>> and more. Also, Atmosphere has a history of bugs and problems. I wouldn't
>> recommend anyone to use it.
>>
> Agreed!
>
>
>> Best regards,
>> Emond
>>
>> On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
>>> Hi,
>>>
>>> What other improvements do we need in 8.x/master before promoting it to
>>> 8.0.0 final ?
>>>
>>> At https://cwiki.apache.org/confluence/display/WICKET/
>> Ideas+for+Wicket+8.0
>>> we still have:
>>>
>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
>> one
>>> more try but the problem is that I don't believe this is the proper way
>> and
>>> this demotivates me.
>>> If someone else wants to give it a try - please assign it to yourself!
>>>
>>> - Better SEO for stateful pages - the only way I see this is by using
>>> ServiceWorker to add the pageId as a request header to all requests
>> (normal
>>> & Ajax)
>>>
>>>
>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>> I don't have much experience with it, but both React and AngularJs
>>> communities use it to manage the state for their components.
>>> There are some Java impls, even a standard is coming:
>>> https://github.com/jvm-redux/jvm-redux-api
>>>
>>> What else ?
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
On Fri, Jan 13, 2017 at 10:46 AM, Emond Papegaaij <
emond.papegaaij@topicus.nl> wrote:
> Hi,
>
> I was wondering if we still need to support Tomcat 7.0 with native
> websockets.
> As far as I can see, Tomcat 8.0 and 8.5 both support JSR 356 and Tomcat 7.0
> does not support Servlet 3.1, which is required for Wicket 8. Therefore, I
> think we should drop the wicket-native-websocket-tomcat module. Perhaps we
> should also merge javax into core and place the examples with the other
> examples.
>
>
Agreed!
> With websockets becomming more and more standard, I'm not sure we still
> need
> wicket-atmosphere. wicket-native-websocket provides the same functionallity
> and more. Also, Atmosphere has a history of bugs and problems. I wouldn't
> recommend anyone to use it.
>
Agreed!
>
> Best regards,
> Emond
>
> On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
> > Hi,
> >
> > What other improvements do we need in 8.x/master before promoting it to
> > 8.0.0 final ?
> >
> > At https://cwiki.apache.org/confluence/display/WICKET/
> Ideas+for+Wicket+8.0
> > we still have:
> >
> > - new DateTime APIs for wicket-datetime *WICKET-6105
> > <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
> one
> > more try but the problem is that I don't believe this is the proper way
> and
> > this demotivates me.
> > If someone else wants to give it a try - please assign it to yourself!
> >
> > - Better SEO for stateful pages - the only way I see this is by using
> > ServiceWorker to add the pageId as a request header to all requests
> (normal
> > & Ajax)
> >
> >
> > Recently I wondered whether Redux.js could be in use for Wicket.
> > I don't have much experience with it, but both React and AngularJs
> > communities use it to manage the state for their components.
> > There are some Java impls, even a standard is coming:
> > https://github.com/jvm-redux/jvm-redux-api
> >
> > What else ?
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
>
>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Sven Meier <sv...@meiers.net>.
Hi Edmond,
>Tomcat 7.0 does not support Servlet 3.1, which is required for Wicket 8.
>I think we should drop wicket-native-websocket-tomcat
+1
> I'm not sure we still need wicket-atmosphere
> Atmosphere has a history of bugs and problems
+1
Let's drop both for 8.x
Have fun
Sven
On 13.01.2017 10:46, Emond Papegaaij wrote:
> Hi,
>
> I was wondering if we still need to support Tomcat 7.0 with native websockets.
> As far as I can see, Tomcat 8.0 and 8.5 both support JSR 356 and Tomcat 7.0
> does not support Servlet 3.1, which is required for Wicket 8. Therefore, I
> think we should drop the wicket-native-websocket-tomcat module. Perhaps we
> should also merge javax into core and place the examples with the other
> examples.
>
> With websockets becomming more and more standard, I'm not sure we still need
> wicket-atmosphere. wicket-native-websocket provides the same functionallity
> and more. Also, Atmosphere has a history of bugs and problems. I wouldn't
> recommend anyone to use it.
>
> Best regards,
> Emond
>
> On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
>> Hi,
>>
>> What other improvements do we need in 8.x/master before promoting it to
>> 8.0.0 final ?
>>
>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0
>> we still have:
>>
>> - new DateTime APIs for wicket-datetime *WICKET-6105
>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
>> more try but the problem is that I don't believe this is the proper way and
>> this demotivates me.
>> If someone else wants to give it a try - please assign it to yourself!
>>
>> - Better SEO for stateful pages - the only way I see this is by using
>> ServiceWorker to add the pageId as a request header to all requests (normal
>> & Ajax)
>>
>>
>> Recently I wondered whether Redux.js could be in use for Wicket.
>> I don't have much experience with it, but both React and AngularJs
>> communities use it to manage the state for their components.
>> There are some Java impls, even a standard is coming:
>> https://github.com/jvm-redux/jvm-redux-api
>>
>> What else ?
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Emond Papegaaij <em...@topicus.nl>.
Hi,
I was wondering if we still need to support Tomcat 7.0 with native websockets.
As far as I can see, Tomcat 8.0 and 8.5 both support JSR 356 and Tomcat 7.0
does not support Servlet 3.1, which is required for Wicket 8. Therefore, I
think we should drop the wicket-native-websocket-tomcat module. Perhaps we
should also merge javax into core and place the examples with the other
examples.
With websockets becomming more and more standard, I'm not sure we still need
wicket-atmosphere. wicket-native-websocket provides the same functionallity
and more. Also, Atmosphere has a history of bugs and problems. I wouldn't
recommend anyone to use it.
Best regards,
Emond
On maandag 31 oktober 2016 14:41:12 CET Martin Grigorov wrote:
> Hi,
>
> What other improvements do we need in 8.x/master before promoting it to
> 8.0.0 final ?
>
> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0
> we still have:
>
> - new DateTime APIs for wicket-datetime *WICKET-6105
> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
> more try but the problem is that I don't believe this is the proper way and
> this demotivates me.
> If someone else wants to give it a try - please assign it to yourself!
>
> - Better SEO for stateful pages - the only way I see this is by using
> ServiceWorker to add the pageId as a request header to all requests (normal
> & Ajax)
>
>
> Recently I wondered whether Redux.js could be in use for Wicket.
> I don't have much experience with it, but both React and AngularJs
> communities use it to manage the state for their components.
> There are some Java impls, even a standard is coming:
> https://github.com/jvm-redux/jvm-redux-api
>
> What else ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
Re: What else do we want to do before 8.0.0 final ?
Posted by Pedro Santos <pe...@gmail.com>.
Hi,
I'm +1 to improve the fragment's markup identification [1] and Wicket's
property expression language [2] before promoting it.
1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
2 - http://wicket-dev.markmail.org/thread/3g4zsqykid3ia6xl
Pedro Santos
On Mon, Oct 31, 2016 at 11:41 AM, Martin Grigorov <mg...@apache.org>
wrote:
> Hi,
>
> What other improvements do we need in 8.x/master before promoting it to
> 8.0.0 final ?
>
> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0
> we still have:
>
> - new DateTime APIs for wicket-datetime *WICKET-6105
> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
> more try but the problem is that I don't believe this is the proper way and
> this demotivates me.
> If someone else wants to give it a try - please assign it to yourself!
>
> - Better SEO for stateful pages - the only way I see this is by using
> ServiceWorker to add the pageId as a request header to all requests (normal
> & Ajax)
>
>
> Recently I wondered whether Redux.js could be in use for Wicket.
> I don't have much experience with it, but both React and AngularJs
> communities use it to manage the state for their components.
> There are some Java impls, even a standard is coming:
> https://github.com/jvm-redux/jvm-redux-api
>
> What else ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Sven Meier <sv...@meiers.net>.
Hi Andrea,
my bad, this project here still uses the predecessor o_O
I'll switch to wicketstuff-select2 now.
Thanks
Sven
On 16.01.2017 17:19, Andrea Del Bene wrote:
>
>
> On 16/01/2017 17:14, Sven Meier wrote:
>> Hi,
>>
>> ok, found some time to continue my migration:
>>
>> We will have to migrate select2 to wicket-8.x because of WICKET-6137.
>>
>> Anyone working on this already? Otherwise I'll do it tomorrow.
>
> I don't know if it can help, but the select2 from WicketStuff master
> branch works correctly.
>
>>
>> Have fun
>> Sven
>>
>>
>>
>> On 13.01.2017 07:59, Maxim Solodovnik wrote:
>>> Hello Sven,
>>>
>>> please let me know if select2 need to be fixed/improved :)
>>>
>>> On Fri, Jan 13, 2017 at 1:54 PM, Sven Meier <sv...@meiers.net> wrote:
>>>> Hi Martin,
>>>>
>>>> yes, I gave it a shot this week:
>>>>
>>>> From 6.x to 8.x in one step with ~400 compile errors, mainly
>>>> related to
>>>> AjaxRequestTarget and ExportableColumn.
>>>>
>>>> I didn't have time to finish the migration when select2 showed some
>>>> weird
>>>> class hierarchy errors,
>>>> but I don't expect it to take me more than two days in total.
>>>>
>>>> I'll keep you all updated
>>>> Sven
>>>>
>>>>
>>>> On 13.01.2017 00:08, Martin Grigorov wrote:
>>>>> Hi,
>>>>>
>>>>> @Sven: have you started migrating your app ?
>>>>>
>>>>> @Pedro: any idea when you will have time to finish your
>>>>> improvements? Do
>>>>> you need any help ?
>>>>>
>>>>>
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>> https://twitter.com/mtgrigorov
>>>>>
>>>>> On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov
>>>>> <mg...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Probably we should stick to the principle: If it works, don't
>>>>>> touch it!
>>>>>> This is related to CGLib and ClassMetaCache
>>>>>>
>>>>>> Martin Grigorov
>>>>>> Wicket Training and Consulting
>>>>>> https://twitter.com/mtgrigorov
>>>>>>
>>>>>> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> We can replace ClassMetaCache used in wicket-ioc's Injector by a
>>>>>>> Jandex[1]
>>>>>>> class index.
>>>>>>>
>>>>>>> 1 - https://github.com/wildfly/jandex
>>>>>>>
>>>>>>> Pedro Santos
>>>>>>>
>>>>>>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov
>>>>>>> <mg...@apache.org>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> The main advantages of ByteBuddy are:
>>>>>>>> - actively developed
>>>>>>>> - Mockito 2 moved to it
>>>>>>>> - Hibernate 5.x is moving to it (
>>>>>>>> https://twitter.com/vlad_mihalcea/status/798971296910483456)
>>>>>>>> - Spring considers it (they actually already use it for the tests:
>>>>>>>> https://twitter.com/ankinson/status/799363435775586308)
>>>>>>>> - support for Java 9 (we will need it at some point)
>>>>>>>> - support for Android (I guess no one will ever run Wicket inside
>>>>>>> Android,
>>>>>>>> but who knows)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Martin Grigorov
>>>>>>>> Wicket Training and Consulting
>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>
>>>>>>>> On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> Replace CGLIB with ByteBuddy because it has better support for
>>>>>>>>> Java 8
>>>>>>>> and 9
>>>>>>>>> What are the advantages? Seems Spring hasn't decided on this yet:
>>>>>>>>>
>>>>>>>>> https://jira.spring.io/browse/SPR-8190
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Sven
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 20.11.2016 00:47, Martin Grigorov wrote:
>>>>>>>>>
>>>>>>>>>> Replace CGLIB with ByteBuddy because it has better support
>>>>>>>>>> for Java 8
>>>>>>>> and
>>>>>>>>>> 9
>>>>>>>>>> ?
>>>>>>>>>> CGLIB could stay as fallback (via system property) until 9.0.0.
>>>>>>>>>>
>>>>>>>>>> Martin Grigorov
>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>
>>>>>>>>>> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>>>>>>> an.delbene@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> yah, I think it's better
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 14/11/2016 19:54, Martin Grigorov wrote:
>>>>>>>>>>>
>>>>>>>>>>> +1
>>>>>>>>>>>> Maybe rename #forResource() to #of() ?
>>>>>>>>>>>>
>>>>>>>>>>>> Martin Grigorov
>>>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>>>>>>>> an.delbene@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'm wondering if there is room for an improvement for
>>>>>>>> ResourceReference,
>>>>>>>>>>>>> introducing lambda support also for this component.
>>>>>>>>>>>>> Actually it's
>>>>>>>>>>>>> something
>>>>>>>>>>>>> that can be done after the release of 8.0.0, but I'd like to
>>>>>>> collect
>>>>>>>>>>>>> your
>>>>>>>>>>>>> feedback anyway. The idea is to provide factory methods to
>>>>>>>>>>>>> build a
>>>>>>>>>>>>> ResourceReference using lambdas and avoiding anonymous
>>>>>>>>>>>>> classes to
>>>>>>>>>>>>> implement
>>>>>>>>>>>>> getResource().
>>>>>>>>>>>>> The following snippet should better explain what I mean:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Andrea.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> What other improvements do we need in 8.x/master before
>>>>>>> promoting it
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> 8.0.0 final ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>>>>>>>>>>>>> for+Wicket+8.0
>>>>>>>>>>>>>> we still have:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>>>>>>>>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* -
>>>>>>>>>>>>>> I'll give
>>>>>>>> this
>>>>>>>>>>>>>> one
>>>>>>>>>>>>>> more try but the problem is that I don't believe this is the
>>>>>>> proper
>>>>>>>>>>>>>> way
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> this demotivates me.
>>>>>>>>>>>>>> If someone else wants to give it a try - please assign it to
>>>>>>>> yourself!
>>>>>>>>>>>>>> - Better SEO for stateful pages - the only way I see this
>>>>>>>>>>>>>> is by
>>>>>>>> using
>>>>>>>>>>>>>> ServiceWorker to add the pageId as a request header to all
>>>>>>> requests
>>>>>>>>>>>>>> (normal
>>>>>>>>>>>>>> & Ajax)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Recently I wondered whether Redux.js could be in use for
>>>>>>>>>>>>>> Wicket.
>>>>>>>>>>>>>> I don't have much experience with it, but both React and
>>>>>>> AngularJs
>>>>>>>>>>>>>> communities use it to manage the state for their components.
>>>>>>>>>>>>>> There are some Java impls, even a standard is coming:
>>>>>>>>>>>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What else ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Martin Grigorov
>>>>>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>
>>>
>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Andrea Del Bene <an...@gmail.com>.
On 16/01/2017 17:14, Sven Meier wrote:
> Hi,
>
> ok, found some time to continue my migration:
>
> We will have to migrate select2 to wicket-8.x because of WICKET-6137.
>
> Anyone working on this already? Otherwise I'll do it tomorrow.
I don't know if it can help, but the select2 from WicketStuff master
branch works correctly.
>
> Have fun
> Sven
>
>
>
> On 13.01.2017 07:59, Maxim Solodovnik wrote:
>> Hello Sven,
>>
>> please let me know if select2 need to be fixed/improved :)
>>
>> On Fri, Jan 13, 2017 at 1:54 PM, Sven Meier <sv...@meiers.net> wrote:
>>> Hi Martin,
>>>
>>> yes, I gave it a shot this week:
>>>
>>> From 6.x to 8.x in one step with ~400 compile errors, mainly
>>> related to
>>> AjaxRequestTarget and ExportableColumn.
>>>
>>> I didn't have time to finish the migration when select2 showed some
>>> weird
>>> class hierarchy errors,
>>> but I don't expect it to take me more than two days in total.
>>>
>>> I'll keep you all updated
>>> Sven
>>>
>>>
>>> On 13.01.2017 00:08, Martin Grigorov wrote:
>>>> Hi,
>>>>
>>>> @Sven: have you started migrating your app ?
>>>>
>>>> @Pedro: any idea when you will have time to finish your
>>>> improvements? Do
>>>> you need any help ?
>>>>
>>>>
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>> On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov
>>>> <mg...@apache.org>
>>>> wrote:
>>>>
>>>>> Probably we should stick to the principle: If it works, don't
>>>>> touch it!
>>>>> This is related to CGLib and ClassMetaCache
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>> https://twitter.com/mtgrigorov
>>>>>
>>>>> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com>
>>>>> wrote:
>>>>>
>>>>>> We can replace ClassMetaCache used in wicket-ioc's Injector by a
>>>>>> Jandex[1]
>>>>>> class index.
>>>>>>
>>>>>> 1 - https://github.com/wildfly/jandex
>>>>>>
>>>>>> Pedro Santos
>>>>>>
>>>>>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov
>>>>>> <mg...@apache.org>
>>>>>> wrote:
>>>>>>
>>>>>>> The main advantages of ByteBuddy are:
>>>>>>> - actively developed
>>>>>>> - Mockito 2 moved to it
>>>>>>> - Hibernate 5.x is moving to it (
>>>>>>> https://twitter.com/vlad_mihalcea/status/798971296910483456)
>>>>>>> - Spring considers it (they actually already use it for the tests:
>>>>>>> https://twitter.com/ankinson/status/799363435775586308)
>>>>>>> - support for Java 9 (we will need it at some point)
>>>>>>> - support for Android (I guess no one will ever run Wicket inside
>>>>>> Android,
>>>>>>> but who knows)
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Martin Grigorov
>>>>>>> Wicket Training and Consulting
>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>
>>>>>>> On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> Replace CGLIB with ByteBuddy because it has better support for
>>>>>>>> Java 8
>>>>>>> and 9
>>>>>>>> What are the advantages? Seems Spring hasn't decided on this yet:
>>>>>>>>
>>>>>>>> https://jira.spring.io/browse/SPR-8190
>>>>>>>>
>>>>>>>> Regards
>>>>>>>> Sven
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 20.11.2016 00:47, Martin Grigorov wrote:
>>>>>>>>
>>>>>>>>> Replace CGLIB with ByteBuddy because it has better support for
>>>>>>>>> Java 8
>>>>>>> and
>>>>>>>>> 9
>>>>>>>>> ?
>>>>>>>>> CGLIB could stay as fallback (via system property) until 9.0.0.
>>>>>>>>>
>>>>>>>>> Martin Grigorov
>>>>>>>>> Wicket Training and Consulting
>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>
>>>>>>>>> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>>>>>> an.delbene@gmail.com
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> yah, I think it's better
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 14/11/2016 19:54, Martin Grigorov wrote:
>>>>>>>>>>
>>>>>>>>>> +1
>>>>>>>>>>> Maybe rename #forResource() to #of() ?
>>>>>>>>>>>
>>>>>>>>>>> Martin Grigorov
>>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>>>>>>> an.delbene@gmail.com>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> I'm wondering if there is room for an improvement for
>>>>>>> ResourceReference,
>>>>>>>>>>>> introducing lambda support also for this component.
>>>>>>>>>>>> Actually it's
>>>>>>>>>>>> something
>>>>>>>>>>>> that can be done after the release of 8.0.0, but I'd like to
>>>>>> collect
>>>>>>>>>>>> your
>>>>>>>>>>>> feedback anyway. The idea is to provide factory methods to
>>>>>>>>>>>> build a
>>>>>>>>>>>> ResourceReference using lambdas and avoiding anonymous
>>>>>>>>>>>> classes to
>>>>>>>>>>>> implement
>>>>>>>>>>>> getResource().
>>>>>>>>>>>> The following snippet should better explain what I mean:
>>>>>>>>>>>>
>>>>>>>>>>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Andrea.
>>>>>>>>>>>>
>>>>>>>>>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> Hi,
>>>>>>>>>>>>
>>>>>>>>>>>>> What other improvements do we need in 8.x/master before
>>>>>> promoting it
>>>>>>>>>>>>> to
>>>>>>>>>>>>> 8.0.0 final ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>>>>>>>>>>>> for+Wicket+8.0
>>>>>>>>>>>>> we still have:
>>>>>>>>>>>>>
>>>>>>>>>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>>>>>>>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* -
>>>>>>>>>>>>> I'll give
>>>>>>> this
>>>>>>>>>>>>> one
>>>>>>>>>>>>> more try but the problem is that I don't believe this is the
>>>>>> proper
>>>>>>>>>>>>> way
>>>>>>>>>>>>> and
>>>>>>>>>>>>> this demotivates me.
>>>>>>>>>>>>> If someone else wants to give it a try - please assign it to
>>>>>>> yourself!
>>>>>>>>>>>>> - Better SEO for stateful pages - the only way I see this
>>>>>>>>>>>>> is by
>>>>>>> using
>>>>>>>>>>>>> ServiceWorker to add the pageId as a request header to all
>>>>>> requests
>>>>>>>>>>>>> (normal
>>>>>>>>>>>>> & Ajax)
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> Recently I wondered whether Redux.js could be in use for
>>>>>>>>>>>>> Wicket.
>>>>>>>>>>>>> I don't have much experience with it, but both React and
>>>>>> AngularJs
>>>>>>>>>>>>> communities use it to manage the state for their components.
>>>>>>>>>>>>> There are some Java impls, even a standard is coming:
>>>>>>>>>>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>>>>>>>>>>
>>>>>>>>>>>>> What else ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Martin Grigorov
>>>>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>
>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Sven Meier <sv...@meiers.net>.
Hi,
ok, found some time to continue my migration:
We will have to migrate select2 to wicket-8.x because of WICKET-6137.
Anyone working on this already? Otherwise I'll do it tomorrow.
Have fun
Sven
On 13.01.2017 07:59, Maxim Solodovnik wrote:
> Hello Sven,
>
> please let me know if select2 need to be fixed/improved :)
>
> On Fri, Jan 13, 2017 at 1:54 PM, Sven Meier <sv...@meiers.net> wrote:
>> Hi Martin,
>>
>> yes, I gave it a shot this week:
>>
>> From 6.x to 8.x in one step with ~400 compile errors, mainly related to
>> AjaxRequestTarget and ExportableColumn.
>>
>> I didn't have time to finish the migration when select2 showed some weird
>> class hierarchy errors,
>> but I don't expect it to take me more than two days in total.
>>
>> I'll keep you all updated
>> Sven
>>
>>
>> On 13.01.2017 00:08, Martin Grigorov wrote:
>>> Hi,
>>>
>>> @Sven: have you started migrating your app ?
>>>
>>> @Pedro: any idea when you will have time to finish your improvements? Do
>>> you need any help ?
>>>
>>>
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>>
>>>> Probably we should stick to the principle: If it works, don't touch it!
>>>> This is related to CGLib and ClassMetaCache
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com>
>>>> wrote:
>>>>
>>>>> We can replace ClassMetaCache used in wicket-ioc's Injector by a
>>>>> Jandex[1]
>>>>> class index.
>>>>>
>>>>> 1 - https://github.com/wildfly/jandex
>>>>>
>>>>> Pedro Santos
>>>>>
>>>>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <mg...@apache.org>
>>>>> wrote:
>>>>>
>>>>>> The main advantages of ByteBuddy are:
>>>>>> - actively developed
>>>>>> - Mockito 2 moved to it
>>>>>> - Hibernate 5.x is moving to it (
>>>>>> https://twitter.com/vlad_mihalcea/status/798971296910483456)
>>>>>> - Spring considers it (they actually already use it for the tests:
>>>>>> https://twitter.com/ankinson/status/799363435775586308)
>>>>>> - support for Java 9 (we will need it at some point)
>>>>>> - support for Android (I guess no one will ever run Wicket inside
>>>>> Android,
>>>>>> but who knows)
>>>>>>
>>>>>>
>>>>>>
>>>>>> Martin Grigorov
>>>>>> Wicket Training and Consulting
>>>>>> https://twitter.com/mtgrigorov
>>>>>>
>>>>>> On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net> wrote:
>>>>>>
>>>>>>> Replace CGLIB with ByteBuddy because it has better support for Java 8
>>>>>> and 9
>>>>>>> What are the advantages? Seems Spring hasn't decided on this yet:
>>>>>>>
>>>>>>> https://jira.spring.io/browse/SPR-8190
>>>>>>>
>>>>>>> Regards
>>>>>>> Sven
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 20.11.2016 00:47, Martin Grigorov wrote:
>>>>>>>
>>>>>>>> Replace CGLIB with ByteBuddy because it has better support for Java 8
>>>>>> and
>>>>>>>> 9
>>>>>>>> ?
>>>>>>>> CGLIB could stay as fallback (via system property) until 9.0.0.
>>>>>>>>
>>>>>>>> Martin Grigorov
>>>>>>>> Wicket Training and Consulting
>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>
>>>>>>>> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>>>>> an.delbene@gmail.com
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> yah, I think it's better
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 14/11/2016 19:54, Martin Grigorov wrote:
>>>>>>>>>
>>>>>>>>> +1
>>>>>>>>>> Maybe rename #forResource() to #of() ?
>>>>>>>>>>
>>>>>>>>>> Martin Grigorov
>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>
>>>>>>>>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>>>>>> an.delbene@gmail.com>
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> I'm wondering if there is room for an improvement for
>>>>>> ResourceReference,
>>>>>>>>>>> introducing lambda support also for this component. Actually it's
>>>>>>>>>>> something
>>>>>>>>>>> that can be done after the release of 8.0.0, but I'd like to
>>>>> collect
>>>>>>>>>>> your
>>>>>>>>>>> feedback anyway. The idea is to provide factory methods to build a
>>>>>>>>>>> ResourceReference using lambdas and avoiding anonymous classes to
>>>>>>>>>>> implement
>>>>>>>>>>> getResource().
>>>>>>>>>>> The following snippet should better explain what I mean:
>>>>>>>>>>>
>>>>>>>>>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>>>>>>>>>>>
>>>>>>>>>>> Andrea.
>>>>>>>>>>>
>>>>>>>>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>>>>>>>>>>
>>>>>>>>>>> Hi,
>>>>>>>>>>>
>>>>>>>>>>>> What other improvements do we need in 8.x/master before
>>>>> promoting it
>>>>>>>>>>>> to
>>>>>>>>>>>> 8.0.0 final ?
>>>>>>>>>>>>
>>>>>>>>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>>>>>>>>>>> for+Wicket+8.0
>>>>>>>>>>>> we still have:
>>>>>>>>>>>>
>>>>>>>>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>>>>>>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
>>>>>> this
>>>>>>>>>>>> one
>>>>>>>>>>>> more try but the problem is that I don't believe this is the
>>>>> proper
>>>>>>>>>>>> way
>>>>>>>>>>>> and
>>>>>>>>>>>> this demotivates me.
>>>>>>>>>>>> If someone else wants to give it a try - please assign it to
>>>>>> yourself!
>>>>>>>>>>>> - Better SEO for stateful pages - the only way I see this is by
>>>>>> using
>>>>>>>>>>>> ServiceWorker to add the pageId as a request header to all
>>>>> requests
>>>>>>>>>>>> (normal
>>>>>>>>>>>> & Ajax)
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>>>>>>>>>>> I don't have much experience with it, but both React and
>>>>> AngularJs
>>>>>>>>>>>> communities use it to manage the state for their components.
>>>>>>>>>>>> There are some Java impls, even a standard is coming:
>>>>>>>>>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>>>>>>>>>
>>>>>>>>>>>> What else ?
>>>>>>>>>>>>
>>>>>>>>>>>> Martin Grigorov
>>>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Maxim Solodovnik <so...@gmail.com>.
Hello Sven,
please let me know if select2 need to be fixed/improved :)
On Fri, Jan 13, 2017 at 1:54 PM, Sven Meier <sv...@meiers.net> wrote:
> Hi Martin,
>
> yes, I gave it a shot this week:
>
> From 6.x to 8.x in one step with ~400 compile errors, mainly related to
> AjaxRequestTarget and ExportableColumn.
>
> I didn't have time to finish the migration when select2 showed some weird
> class hierarchy errors,
> but I don't expect it to take me more than two days in total.
>
> I'll keep you all updated
> Sven
>
>
> On 13.01.2017 00:08, Martin Grigorov wrote:
>>
>> Hi,
>>
>> @Sven: have you started migrating your app ?
>>
>> @Pedro: any idea when you will have time to finish your improvements? Do
>> you need any help ?
>>
>>
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <mg...@apache.org>
>> wrote:
>>
>>> Probably we should stick to the principle: If it works, don't touch it!
>>> This is related to CGLib and ClassMetaCache
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com>
>>> wrote:
>>>
>>>> We can replace ClassMetaCache used in wicket-ioc's Injector by a
>>>> Jandex[1]
>>>> class index.
>>>>
>>>> 1 - https://github.com/wildfly/jandex
>>>>
>>>> Pedro Santos
>>>>
>>>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <mg...@apache.org>
>>>> wrote:
>>>>
>>>>> The main advantages of ByteBuddy are:
>>>>> - actively developed
>>>>> - Mockito 2 moved to it
>>>>> - Hibernate 5.x is moving to it (
>>>>> https://twitter.com/vlad_mihalcea/status/798971296910483456)
>>>>> - Spring considers it (they actually already use it for the tests:
>>>>> https://twitter.com/ankinson/status/799363435775586308)
>>>>> - support for Java 9 (we will need it at some point)
>>>>> - support for Android (I guess no one will ever run Wicket inside
>>>>
>>>> Android,
>>>>>
>>>>> but who knows)
>>>>>
>>>>>
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>> https://twitter.com/mtgrigorov
>>>>>
>>>>> On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net> wrote:
>>>>>
>>>>>> Replace CGLIB with ByteBuddy because it has better support for Java 8
>>>>>
>>>>> and 9
>>>>>>
>>>>>> What are the advantages? Seems Spring hasn't decided on this yet:
>>>>>>
>>>>>> https://jira.spring.io/browse/SPR-8190
>>>>>>
>>>>>> Regards
>>>>>> Sven
>>>>>>
>>>>>>
>>>>>>
>>>>>> On 20.11.2016 00:47, Martin Grigorov wrote:
>>>>>>
>>>>>>> Replace CGLIB with ByteBuddy because it has better support for Java 8
>>>>>
>>>>> and
>>>>>>>
>>>>>>> 9
>>>>>>> ?
>>>>>>> CGLIB could stay as fallback (via system property) until 9.0.0.
>>>>>>>
>>>>>>> Martin Grigorov
>>>>>>> Wicket Training and Consulting
>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>
>>>>>>> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>>>>
>>>> an.delbene@gmail.com
>>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> yah, I think it's better
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 14/11/2016 19:54, Martin Grigorov wrote:
>>>>>>>>
>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> Maybe rename #forResource() to #of() ?
>>>>>>>>>
>>>>>>>>> Martin Grigorov
>>>>>>>>> Wicket Training and Consulting
>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>
>>>>>>>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>>>>>
>>>>> an.delbene@gmail.com>
>>>>>>>>>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I'm wondering if there is room for an improvement for
>>>>>
>>>>> ResourceReference,
>>>>>>>>>>
>>>>>>>>>> introducing lambda support also for this component. Actually it's
>>>>>>>>>> something
>>>>>>>>>> that can be done after the release of 8.0.0, but I'd like to
>>>>
>>>> collect
>>>>>>>>>>
>>>>>>>>>> your
>>>>>>>>>> feedback anyway. The idea is to provide factory methods to build a
>>>>>>>>>> ResourceReference using lambdas and avoiding anonymous classes to
>>>>>>>>>> implement
>>>>>>>>>> getResource().
>>>>>>>>>> The following snippet should better explain what I mean:
>>>>>>>>>>
>>>>>>>>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>>>>>>>>>>
>>>>>>>>>> Andrea.
>>>>>>>>>>
>>>>>>>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>> What other improvements do we need in 8.x/master before
>>>>
>>>> promoting it
>>>>>>>>>>>
>>>>>>>>>>> to
>>>>>>>>>>> 8.0.0 final ?
>>>>>>>>>>>
>>>>>>>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>>>>>>>>>> for+Wicket+8.0
>>>>>>>>>>> we still have:
>>>>>>>>>>>
>>>>>>>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>>>>>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
>>>>>
>>>>> this
>>>>>>>>>>>
>>>>>>>>>>> one
>>>>>>>>>>> more try but the problem is that I don't believe this is the
>>>>
>>>> proper
>>>>>>>>>>>
>>>>>>>>>>> way
>>>>>>>>>>> and
>>>>>>>>>>> this demotivates me.
>>>>>>>>>>> If someone else wants to give it a try - please assign it to
>>>>>
>>>>> yourself!
>>>>>>>>>>>
>>>>>>>>>>> - Better SEO for stateful pages - the only way I see this is by
>>>>>
>>>>> using
>>>>>>>>>>>
>>>>>>>>>>> ServiceWorker to add the pageId as a request header to all
>>>>
>>>> requests
>>>>>>>>>>>
>>>>>>>>>>> (normal
>>>>>>>>>>> & Ajax)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>>>>>>>>>> I don't have much experience with it, but both React and
>>>>
>>>> AngularJs
>>>>>>>>>>>
>>>>>>>>>>> communities use it to manage the state for their components.
>>>>>>>>>>> There are some Java impls, even a standard is coming:
>>>>>>>>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>>>>>>>>
>>>>>>>>>>> What else ?
>>>>>>>>>>>
>>>>>>>>>>> Martin Grigorov
>>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>
>
--
WBR
Maxim aka solomax
Re: What else do we want to do before 8.0.0 final ?
Posted by Sven Meier <sv...@meiers.net>.
Hi Martin,
yes, I gave it a shot this week:
From 6.x to 8.x in one step with ~400 compile errors, mainly related to
AjaxRequestTarget and ExportableColumn.
I didn't have time to finish the migration when select2 showed some
weird class hierarchy errors,
but I don't expect it to take me more than two days in total.
I'll keep you all updated
Sven
On 13.01.2017 00:08, Martin Grigorov wrote:
> Hi,
>
> @Sven: have you started migrating your app ?
>
> @Pedro: any idea when you will have time to finish your improvements? Do
> you need any help ?
>
>
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <mg...@apache.org>
> wrote:
>
>> Probably we should stick to the principle: If it works, don't touch it!
>> This is related to CGLib and ClassMetaCache
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com> wrote:
>>
>>> We can replace ClassMetaCache used in wicket-ioc's Injector by a Jandex[1]
>>> class index.
>>>
>>> 1 - https://github.com/wildfly/jandex
>>>
>>> Pedro Santos
>>>
>>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>>
>>>> The main advantages of ByteBuddy are:
>>>> - actively developed
>>>> - Mockito 2 moved to it
>>>> - Hibernate 5.x is moving to it (
>>>> https://twitter.com/vlad_mihalcea/status/798971296910483456)
>>>> - Spring considers it (they actually already use it for the tests:
>>>> https://twitter.com/ankinson/status/799363435775586308)
>>>> - support for Java 9 (we will need it at some point)
>>>> - support for Android (I guess no one will ever run Wicket inside
>>> Android,
>>>> but who knows)
>>>>
>>>>
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>> On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net> wrote:
>>>>
>>>>> Replace CGLIB with ByteBuddy because it has better support for Java 8
>>>> and 9
>>>>> What are the advantages? Seems Spring hasn't decided on this yet:
>>>>>
>>>>> https://jira.spring.io/browse/SPR-8190
>>>>>
>>>>> Regards
>>>>> Sven
>>>>>
>>>>>
>>>>>
>>>>> On 20.11.2016 00:47, Martin Grigorov wrote:
>>>>>
>>>>>> Replace CGLIB with ByteBuddy because it has better support for Java 8
>>>> and
>>>>>> 9
>>>>>> ?
>>>>>> CGLIB could stay as fallback (via system property) until 9.0.0.
>>>>>>
>>>>>> Martin Grigorov
>>>>>> Wicket Training and Consulting
>>>>>> https://twitter.com/mtgrigorov
>>>>>>
>>>>>> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>>> an.delbene@gmail.com
>>>>>> wrote:
>>>>>>
>>>>>> yah, I think it's better
>>>>>>>
>>>>>>>
>>>>>>> On 14/11/2016 19:54, Martin Grigorov wrote:
>>>>>>>
>>>>>>> +1
>>>>>>>> Maybe rename #forResource() to #of() ?
>>>>>>>>
>>>>>>>> Martin Grigorov
>>>>>>>> Wicket Training and Consulting
>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>
>>>>>>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>>>> an.delbene@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I'm wondering if there is room for an improvement for
>>>> ResourceReference,
>>>>>>>>> introducing lambda support also for this component. Actually it's
>>>>>>>>> something
>>>>>>>>> that can be done after the release of 8.0.0, but I'd like to
>>> collect
>>>>>>>>> your
>>>>>>>>> feedback anyway. The idea is to provide factory methods to build a
>>>>>>>>> ResourceReference using lambdas and avoiding anonymous classes to
>>>>>>>>> implement
>>>>>>>>> getResource().
>>>>>>>>> The following snippet should better explain what I mean:
>>>>>>>>>
>>>>>>>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>>>>>>>>>
>>>>>>>>> Andrea.
>>>>>>>>>
>>>>>>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>> What other improvements do we need in 8.x/master before
>>> promoting it
>>>>>>>>>> to
>>>>>>>>>> 8.0.0 final ?
>>>>>>>>>>
>>>>>>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>>>>>>>>> for+Wicket+8.0
>>>>>>>>>> we still have:
>>>>>>>>>>
>>>>>>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>>>>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
>>>> this
>>>>>>>>>> one
>>>>>>>>>> more try but the problem is that I don't believe this is the
>>> proper
>>>>>>>>>> way
>>>>>>>>>> and
>>>>>>>>>> this demotivates me.
>>>>>>>>>> If someone else wants to give it a try - please assign it to
>>>> yourself!
>>>>>>>>>> - Better SEO for stateful pages - the only way I see this is by
>>>> using
>>>>>>>>>> ServiceWorker to add the pageId as a request header to all
>>> requests
>>>>>>>>>> (normal
>>>>>>>>>> & Ajax)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>>>>>>>>> I don't have much experience with it, but both React and
>>> AngularJs
>>>>>>>>>> communities use it to manage the state for their components.
>>>>>>>>>> There are some Java impls, even a standard is coming:
>>>>>>>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>>>>>>>
>>>>>>>>>> What else ?
>>>>>>>>>>
>>>>>>>>>> Martin Grigorov
>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Tobias Soloschenko <to...@googlemail.com.INVALID>.
Hi,
great to hear and thanks for the feedback. :-)
kind regards
Tobias
> Am 01.02.2017 um 09:00 schrieb Maxim Solodovnik <so...@gmail.com>:
>
> Hello All,
>
> JFYI I have moved Apache OpenMeetings to Wicket-8 without any issues
> in ~30 minutes :)
Re: What else do we want to do before 8.0.0 final ?
Posted by Pedro Santos <pe...@gmail.com>.
Sure, working on it. Created WICKET-6318 to track the configurable
property resolver implementation.
Pedro Santos
On Tue, Feb 7, 2017 at 8:16 PM, Martin Grigorov <mg...@apache.org> wrote:
> Hi Pedro,
>
> Please create Pull Requests for your proposed changes!
> Thanks!
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Wed, Feb 1, 2017 at 9:00 AM, Maxim Solodovnik <so...@gmail.com>
> wrote:
>
>> Hello All,
>>
>> JFYI I have moved Apache OpenMeetings to Wicket-8 without any issues
>> in ~30 minutes :)
>>
>> On Wed, Feb 1, 2017 at 9:04 AM, Pedro Santos <pe...@gmail.com> wrote:
>> > Hi Martin,
>> >
>> >> The comparison with the component queueing is because again we are
>> going to introduce a change that no one ever asked for
>> >
>> > I asked for, and think I did a good job analyzing the current
>> > PropertyResolver and concluding that it's getting too complex and
>> > should be improved for better maintainability.
>> >
>> >> The parser will report errors at runtime so the developers will have to
>> go thru all the functionality of their apps to make sure it still works. So
>> the benefit is questionable! At least to me.
>> >
>> > If we have a page with conditionally visible components, it can
>> > happens that a problematic property expression goes unnoticed until we
>> > get its problematic component visible and rendered. With a parser we
>> > can detect and report syntax errors as soon as we construct a
>> > PropertyModel while initializing the page. In this case the developer
>> > would got an early exception that could otherwise go unnoticed for a
>> > long time. The benefit does exists, I will take that you think it's
>> > value is questionable.
>> >
>> >> Sven made this pluggable so if the application has custom needs then it
>> is possible to setup custom resolver.
>> >> I'd prefer to see the new parser as a pluggable replacement too! So if
>> it breaks someone's application then just switch back to the old impl.
>> >
>> > I addressed both points in my reply to Sven.
>> >
>> >> I'd like to see 8.0.0 released sooner rather than later.
>> >
>> > Me too. I have no clients under a promised Wicket 8 release date, it's
>> > my purely my personal view that Wicket 8 is the right place for
>> > proposed improvements.
>> >
>> > Pedro Santos
>> >
>> >
>> > On Tue, Jan 31, 2017 at 1:58 PM, Martin Grigorov <mg...@apache.org>
>> wrote:
>> >> Hi Pedro,
>> >>
>> >> On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@gmail.com>
>> wrote:
>> >>
>> >>> Hi Martin,
>> >>>
>> >>> you missed the point of the proposal at [1], it's a syntax change that
>> >>> would move Wicket's expression language closer to Unified Expression
>> >>> Language. This change would better welcome developers used to work
>> >>> with expressions like: bean.map["key"] and move Wicket closer to JSR
>> >>> 341 (we can continue on the linked thread).
>> >>>
>> >>
>> >> Yes, it seems I didn't understand it right. I thought both are related -
>> >> the parser is being introduced to be able to deal with the new syntax.
>> >>
>> >>
>> >>>
>> >>> The branch you pointed is the implementation of a parser to replace
>> >>> your current tokenizer inside PropertyResolver.
>> >>>
>> >>
>> >> It is not mine. It was already there when I started using Wicket.
>> >>
>> >>
>> >>>
>> >>> The comparison to the component queueing is vague. It was a new
>> >>> feature in Wicket 7 rather and a improvement aiming to give users
>> >>> earlier syntax errors plus to improve PropertyResolver's
>> >>> maintainability by replacing organic grown code with a structured
>> >>> syntax tree.
>> >>>
>> >>
>> >> The comparison with the component queueing is because again we are
>> going to
>> >> introduce a change that no one ever asked for (well technically, Martin
>> >> Makundi asked for Component Queueing but he still uses Wicket 1.4.x
>> >> nowadays!) and this change might break many applications in production.
>> >> The parser will report errors at runtime so the developers will have to
>> go
>> >> thru all the functionality of their apps to make sure it still works.
>> >> So the benefit is questionable! At least to me.
>> >>
>> >> WICKET-4088 is created 5 years ago and since then no one ever reported
>> any
>> >> problem related to this functionality (the map syntax).
>> >> The only related ticket I'm aware of is
>> >> https://issues.apache.org/jira/browse/WICKET-5623.
>> >> Sven made this pluggable so if the application has custom needs then it
>> is
>> >> possible to setup custom resolver.
>> >> I'd prefer to see the new parser as a pluggable replacement too! So if
>> it
>> >> breaks someone's application then just switch back to the old impl.
>> >>
>> >> So I'm -0 on this improvement but let's see what others think too!
>> >> I'd like to see 8.0.0 released sooner rather than later.
>> >>
>> >>
>> >>>
>> >>> I understand and share your concern about maintenance. It's my
>> >>> understand that the entire team signs a release, and that we all can
>> >>> support and maintain the features inside it. I will understand if
>> >>> anyone stops this improvement based on cost/benefit analysis or on the
>> >>> merit that it's hard to maintain a parser. I do not share such
>> >>> concerns and pointed out the benefits of such improvement at [2] (we
>> >>> can continue on the linked thread).
>> >>>
>> >>> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
>> >>> 2 - http://markmail.org/message/yc2pwmbmasx5rzim
>> >>>
>> >>> On Tue, Jan 31, 2017 at 10:13 AM, Martin Grigorov <
>> mgrigorov@apache.org>
>> >>> wrote:
>> >>> > Hi Pedro,
>> >>> >
>> >>> > On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@gmail.com>
>> >>> wrote:
>> >>> >
>> >>> >> Hi Martin,
>> >>> >>
>> >>> >> Wicket-4201 IPageProvider improvement: will work on the ticket
>> during
>> >>> the
>> >>> >> week
>> >>> >>
>> >>> >> Expression language change [1]: it's a big change and I think it
>> needs
>> >>> >> the team approval
>> >>> >>
>> >>> >
>> >>> > Here is the diff:
>> >>> > https://github.com/apache/wicket/compare/WICKET-4008-
>> >>> property-expression-parser
>> >>> >
>> >>> >
>> >>> >>
>> >>> >> Wicket-4008 expression language parser: the parser is functional and
>> >>> >> there isn't much work pending on it. I can finish and merge the work
>> >>> >> during the week.
>> >>> >>
>> >>> >> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
>> >>> >
>> >>> >
>> >>> > The linked discussion makes me feel a bit uncertain.
>> >>> > I want to avoid another "component queueing" case here, i.e. a rather
>> >>> > bigger refactoring for something that only few people asked for and
>> then
>> >>> > leave the maintenance to someone else. The fact that you didn't have
>> time
>> >>> > to work on these changes in the last few months makes me think you
>> may
>> >>> not
>> >>> > have time to answer questions and fix bugs once it is released. No
>> one
>> >>> can
>> >>> > guarantee that (s)he will be around to help with his/her expertize,
>> me
>> >>> > included, but if you know from now that you won't have time then
>> maybe it
>> >>> > would be better to not make these changes.
>> >>> >
>> >>> > I agree that the team should decide so anyone is welcome to express
>> his
>> >>> > opinion!
>> >>> >
>> >>> >
>> >>> >>
>> >>> >> Pedro Santos
>> >>> >>
>> >>> >>
>> >>> >> On Thu, Jan 12, 2017 at 9:08 PM, Martin Grigorov <
>> mgrigorov@apache.org>
>> >>> >> wrote:
>> >>> >> > Hi,
>> >>> >> >
>> >>> >> > @Sven: have you started migrating your app ?
>> >>> >> >
>> >>> >> > @Pedro: any idea when you will have time to finish your
>> improvements?
>> >>> Do
>> >>> >> > you need any help ?
>> >>> >> >
>> >>> >> >
>> >>> >> >
>> >>> >> > Martin Grigorov
>> >>> >> > Wicket Training and Consulting
>> >>> >> > https://twitter.com/mtgrigorov
>> >>> >> >
>> >>> >> > On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <
>> >>> mgrigorov@apache.org>
>> >>> >> > wrote:
>> >>> >> >
>> >>> >> >> Probably we should stick to the principle: If it works, don't
>> touch
>> >>> it!
>> >>> >> >> This is related to CGLib and ClassMetaCache
>> >>> >> >>
>> >>> >> >> Martin Grigorov
>> >>> >> >> Wicket Training and Consulting
>> >>> >> >> https://twitter.com/mtgrigorov
>> >>> >> >>
>> >>> >> >> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <
>> pedrosans@gmail.com>
>> >>> >> wrote:
>> >>> >> >>
>> >>> >> >>> We can replace ClassMetaCache used in wicket-ioc's Injector by a
>> >>> >> Jandex[1]
>> >>> >> >>> class index.
>> >>> >> >>>
>> >>> >> >>> 1 - https://github.com/wildfly/jandex
>> >>> >> >>>
>> >>> >> >>> Pedro Santos
>> >>> >> >>>
>> >>> >> >>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <
>> >>> mgrigorov@apache.org
>> >>> >> >
>> >>> >> >>> wrote:
>> >>> >> >>>
>> >>> >> >>> > The main advantages of ByteBuddy are:
>> >>> >> >>> > - actively developed
>> >>> >> >>> > - Mockito 2 moved to it
>> >>> >> >>> > - Hibernate 5.x is moving to it (
>> >>> >> >>> > https://twitter.com/vlad_mihalcea/status/798971296910483456)
>> >>> >> >>> > - Spring considers it (they actually already use it for the
>> tests:
>> >>> >> >>> > https://twitter.com/ankinson/status/799363435775586308)
>> >>> >> >>> > - support for Java 9 (we will need it at some point)
>> >>> >> >>> > - support for Android (I guess no one will ever run Wicket
>> inside
>> >>> >> >>> Android,
>> >>> >> >>> > but who knows)
>> >>> >> >>> >
>> >>> >> >>> >
>> >>> >> >>> >
>> >>> >> >>> > Martin Grigorov
>> >>> >> >>> > Wicket Training and Consulting
>> >>> >> >>> > https://twitter.com/mtgrigorov
>> >>> >> >>> >
>> >>> >> >>> > On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net>
>> >>> wrote:
>> >>> >> >>> >
>> >>> >> >>> > > Replace CGLIB with ByteBuddy because it has better support
>> for
>> >>> >> Java 8
>> >>> >> >>> > and 9
>> >>> >> >>> > >>
>> >>> >> >>> > >
>> >>> >> >>> > > What are the advantages? Seems Spring hasn't decided on this
>> >>> yet:
>> >>> >> >>> > >
>> >>> >> >>> > > https://jira.spring.io/browse/SPR-8190
>> >>> >> >>> > >
>> >>> >> >>> > > Regards
>> >>> >> >>> > > Sven
>> >>> >> >>> > >
>> >>> >> >>> > >
>> >>> >> >>> > >
>> >>> >> >>> > > On 20.11.2016 00:47, Martin Grigorov wrote:
>> >>> >> >>> > >
>> >>> >> >>> > >> Replace CGLIB with ByteBuddy because it has better support
>> for
>> >>> >> Java 8
>> >>> >> >>> > and
>> >>> >> >>> > >> 9
>> >>> >> >>> > >> ?
>> >>> >> >>> > >> CGLIB could stay as fallback (via system property) until
>> 9.0.0.
>> >>> >> >>> > >>
>> >>> >> >>> > >> Martin Grigorov
>> >>> >> >>> > >> Wicket Training and Consulting
>> >>> >> >>> > >> https://twitter.com/mtgrigorov
>> >>> >> >>> > >>
>> >>> >> >>> > >> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>> >>> >> >>> an.delbene@gmail.com
>> >>> >> >>> > >
>> >>> >> >>> > >> wrote:
>> >>> >> >>> > >>
>> >>> >> >>> > >> yah, I think it's better
>> >>> >> >>> > >>>
>> >>> >> >>> > >>>
>> >>> >> >>> > >>>
>> >>> >> >>> > >>> On 14/11/2016 19:54, Martin Grigorov wrote:
>> >>> >> >>> > >>>
>> >>> >> >>> > >>> +1
>> >>> >> >>> > >>>>
>> >>> >> >>> > >>>> Maybe rename #forResource() to #of() ?
>> >>> >> >>> > >>>>
>> >>> >> >>> > >>>> Martin Grigorov
>> >>> >> >>> > >>>> Wicket Training and Consulting
>> >>> >> >>> > >>>> https://twitter.com/mtgrigorov
>> >>> >> >>> > >>>>
>> >>> >> >>> > >>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>> >>> >> >>> > an.delbene@gmail.com>
>> >>> >> >>> > >>>> wrote:
>> >>> >> >>> > >>>>
>> >>> >> >>> > >>>> I'm wondering if there is room for an improvement for
>> >>> >> >>> > ResourceReference,
>> >>> >> >>> > >>>>
>> >>> >> >>> > >>>>> introducing lambda support also for this component.
>> Actually
>> >>> >> it's
>> >>> >> >>> > >>>>> something
>> >>> >> >>> > >>>>> that can be done after the release of 8.0.0, but I'd
>> like to
>> >>> >> >>> collect
>> >>> >> >>> > >>>>> your
>> >>> >> >>> > >>>>> feedback anyway. The idea is to provide factory methods
>> to
>> >>> >> build a
>> >>> >> >>> > >>>>> ResourceReference using lambdas and avoiding anonymous
>> >>> classes
>> >>> >> to
>> >>> >> >>> > >>>>> implement
>> >>> >> >>> > >>>>> getResource().
>> >>> >> >>> > >>>>> The following snippet should better explain what I mean:
>> >>> >> >>> > >>>>>
>> >>> >> >>> > >>>>> https://gist.github.com/bitstorm/
>> >>> >> 03cfe9905a3f86a7160ab49f0ce23f13
>> >>> >> >>> > >>>>>
>> >>> >> >>> > >>>>> Andrea.
>> >>> >> >>> > >>>>>
>> >>> >> >>> > >>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>> >>> >> >>> > >>>>>
>> >>> >> >>> > >>>>> Hi,
>> >>> >> >>> > >>>>>
>> >>> >> >>> > >>>>>> What other improvements do we need in 8.x/master before
>> >>> >> >>> promoting it
>> >>> >> >>> > >>>>>> to
>> >>> >> >>> > >>>>>> 8.0.0 final ?
>> >>> >> >>> > >>>>>>
>> >>> >> >>> > >>>>>> At https://cwiki.apache.org/confluence/display/WICKET/
>> >>> Ideas+
>> >>> >> >>> > >>>>>> for+Wicket+8.0
>> >>> >> >>> > >>>>>> we still have:
>> >>> >> >>> > >>>>>>
>> >>> >> >>> > >>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>> >>> >> >>> > >>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* -
>> >>> I'll
>> >>> >> give
>> >>> >> >>> > this
>> >>> >> >>> > >>>>>> one
>> >>> >> >>> > >>>>>> more try but the problem is that I don't believe this
>> is
>> >>> the
>> >>> >> >>> proper
>> >>> >> >>> > >>>>>> way
>> >>> >> >>> > >>>>>> and
>> >>> >> >>> > >>>>>> this demotivates me.
>> >>> >> >>> > >>>>>> If someone else wants to give it a try - please assign
>> it
>> >>> to
>> >>> >> >>> > yourself!
>> >>> >> >>> > >>>>>>
>> >>> >> >>> > >>>>>> - Better SEO for stateful pages - the only way I see
>> this
>> >>> is
>> >>> >> by
>> >>> >> >>> > using
>> >>> >> >>> > >>>>>> ServiceWorker to add the pageId as a request header to
>> all
>> >>> >> >>> requests
>> >>> >> >>> > >>>>>> (normal
>> >>> >> >>> > >>>>>> & Ajax)
>> >>> >> >>> > >>>>>>
>> >>> >> >>> > >>>>>>
>> >>> >> >>> > >>>>>> Recently I wondered whether Redux.js could be in use
>> for
>> >>> >> Wicket.
>> >>> >> >>> > >>>>>> I don't have much experience with it, but both React
>> and
>> >>> >> >>> AngularJs
>> >>> >> >>> > >>>>>> communities use it to manage the state for their
>> >>> components.
>> >>> >> >>> > >>>>>> There are some Java impls, even a standard is coming:
>> >>> >> >>> > >>>>>> https://github.com/jvm-redux/jvm-redux-api
>> >>> >> >>> > >>>>>>
>> >>> >> >>> > >>>>>> What else ?
>> >>> >> >>> > >>>>>>
>> >>> >> >>> > >>>>>> Martin Grigorov
>> >>> >> >>> > >>>>>> Wicket Training and Consulting
>> >>> >> >>> > >>>>>> https://twitter.com/mtgrigorov
>> >>> >> >>> > >>>>>>
>> >>> >> >>> > >>>>>>
>> >>> >> >>> > >>>>>>
>> >>> >> >>> > >>>>>>
>> >>> >> >>> > >
>> >>> >> >>> >
>> >>> >> >>>
>> >>> >> >>
>> >>> >> >>
>> >>> >>
>> >>>
>>
>>
>>
>> --
>> WBR
>> Maxim aka solomax
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Hi Pedro,
Please create Pull Requests for your proposed changes!
Thanks!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Feb 1, 2017 at 9:00 AM, Maxim Solodovnik <so...@gmail.com>
wrote:
> Hello All,
>
> JFYI I have moved Apache OpenMeetings to Wicket-8 without any issues
> in ~30 minutes :)
>
> On Wed, Feb 1, 2017 at 9:04 AM, Pedro Santos <pe...@gmail.com> wrote:
> > Hi Martin,
> >
> >> The comparison with the component queueing is because again we are
> going to introduce a change that no one ever asked for
> >
> > I asked for, and think I did a good job analyzing the current
> > PropertyResolver and concluding that it's getting too complex and
> > should be improved for better maintainability.
> >
> >> The parser will report errors at runtime so the developers will have to
> go thru all the functionality of their apps to make sure it still works. So
> the benefit is questionable! At least to me.
> >
> > If we have a page with conditionally visible components, it can
> > happens that a problematic property expression goes unnoticed until we
> > get its problematic component visible and rendered. With a parser we
> > can detect and report syntax errors as soon as we construct a
> > PropertyModel while initializing the page. In this case the developer
> > would got an early exception that could otherwise go unnoticed for a
> > long time. The benefit does exists, I will take that you think it's
> > value is questionable.
> >
> >> Sven made this pluggable so if the application has custom needs then it
> is possible to setup custom resolver.
> >> I'd prefer to see the new parser as a pluggable replacement too! So if
> it breaks someone's application then just switch back to the old impl.
> >
> > I addressed both points in my reply to Sven.
> >
> >> I'd like to see 8.0.0 released sooner rather than later.
> >
> > Me too. I have no clients under a promised Wicket 8 release date, it's
> > my purely my personal view that Wicket 8 is the right place for
> > proposed improvements.
> >
> > Pedro Santos
> >
> >
> > On Tue, Jan 31, 2017 at 1:58 PM, Martin Grigorov <mg...@apache.org>
> wrote:
> >> Hi Pedro,
> >>
> >> On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@gmail.com>
> wrote:
> >>
> >>> Hi Martin,
> >>>
> >>> you missed the point of the proposal at [1], it's a syntax change that
> >>> would move Wicket's expression language closer to Unified Expression
> >>> Language. This change would better welcome developers used to work
> >>> with expressions like: bean.map["key"] and move Wicket closer to JSR
> >>> 341 (we can continue on the linked thread).
> >>>
> >>
> >> Yes, it seems I didn't understand it right. I thought both are related -
> >> the parser is being introduced to be able to deal with the new syntax.
> >>
> >>
> >>>
> >>> The branch you pointed is the implementation of a parser to replace
> >>> your current tokenizer inside PropertyResolver.
> >>>
> >>
> >> It is not mine. It was already there when I started using Wicket.
> >>
> >>
> >>>
> >>> The comparison to the component queueing is vague. It was a new
> >>> feature in Wicket 7 rather and a improvement aiming to give users
> >>> earlier syntax errors plus to improve PropertyResolver's
> >>> maintainability by replacing organic grown code with a structured
> >>> syntax tree.
> >>>
> >>
> >> The comparison with the component queueing is because again we are
> going to
> >> introduce a change that no one ever asked for (well technically, Martin
> >> Makundi asked for Component Queueing but he still uses Wicket 1.4.x
> >> nowadays!) and this change might break many applications in production.
> >> The parser will report errors at runtime so the developers will have to
> go
> >> thru all the functionality of their apps to make sure it still works.
> >> So the benefit is questionable! At least to me.
> >>
> >> WICKET-4088 is created 5 years ago and since then no one ever reported
> any
> >> problem related to this functionality (the map syntax).
> >> The only related ticket I'm aware of is
> >> https://issues.apache.org/jira/browse/WICKET-5623.
> >> Sven made this pluggable so if the application has custom needs then it
> is
> >> possible to setup custom resolver.
> >> I'd prefer to see the new parser as a pluggable replacement too! So if
> it
> >> breaks someone's application then just switch back to the old impl.
> >>
> >> So I'm -0 on this improvement but let's see what others think too!
> >> I'd like to see 8.0.0 released sooner rather than later.
> >>
> >>
> >>>
> >>> I understand and share your concern about maintenance. It's my
> >>> understand that the entire team signs a release, and that we all can
> >>> support and maintain the features inside it. I will understand if
> >>> anyone stops this improvement based on cost/benefit analysis or on the
> >>> merit that it's hard to maintain a parser. I do not share such
> >>> concerns and pointed out the benefits of such improvement at [2] (we
> >>> can continue on the linked thread).
> >>>
> >>> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
> >>> 2 - http://markmail.org/message/yc2pwmbmasx5rzim
> >>>
> >>> On Tue, Jan 31, 2017 at 10:13 AM, Martin Grigorov <
> mgrigorov@apache.org>
> >>> wrote:
> >>> > Hi Pedro,
> >>> >
> >>> > On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@gmail.com>
> >>> wrote:
> >>> >
> >>> >> Hi Martin,
> >>> >>
> >>> >> Wicket-4201 IPageProvider improvement: will work on the ticket
> during
> >>> the
> >>> >> week
> >>> >>
> >>> >> Expression language change [1]: it's a big change and I think it
> needs
> >>> >> the team approval
> >>> >>
> >>> >
> >>> > Here is the diff:
> >>> > https://github.com/apache/wicket/compare/WICKET-4008-
> >>> property-expression-parser
> >>> >
> >>> >
> >>> >>
> >>> >> Wicket-4008 expression language parser: the parser is functional and
> >>> >> there isn't much work pending on it. I can finish and merge the work
> >>> >> during the week.
> >>> >>
> >>> >> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
> >>> >
> >>> >
> >>> > The linked discussion makes me feel a bit uncertain.
> >>> > I want to avoid another "component queueing" case here, i.e. a rather
> >>> > bigger refactoring for something that only few people asked for and
> then
> >>> > leave the maintenance to someone else. The fact that you didn't have
> time
> >>> > to work on these changes in the last few months makes me think you
> may
> >>> not
> >>> > have time to answer questions and fix bugs once it is released. No
> one
> >>> can
> >>> > guarantee that (s)he will be around to help with his/her expertize,
> me
> >>> > included, but if you know from now that you won't have time then
> maybe it
> >>> > would be better to not make these changes.
> >>> >
> >>> > I agree that the team should decide so anyone is welcome to express
> his
> >>> > opinion!
> >>> >
> >>> >
> >>> >>
> >>> >> Pedro Santos
> >>> >>
> >>> >>
> >>> >> On Thu, Jan 12, 2017 at 9:08 PM, Martin Grigorov <
> mgrigorov@apache.org>
> >>> >> wrote:
> >>> >> > Hi,
> >>> >> >
> >>> >> > @Sven: have you started migrating your app ?
> >>> >> >
> >>> >> > @Pedro: any idea when you will have time to finish your
> improvements?
> >>> Do
> >>> >> > you need any help ?
> >>> >> >
> >>> >> >
> >>> >> >
> >>> >> > Martin Grigorov
> >>> >> > Wicket Training and Consulting
> >>> >> > https://twitter.com/mtgrigorov
> >>> >> >
> >>> >> > On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <
> >>> mgrigorov@apache.org>
> >>> >> > wrote:
> >>> >> >
> >>> >> >> Probably we should stick to the principle: If it works, don't
> touch
> >>> it!
> >>> >> >> This is related to CGLib and ClassMetaCache
> >>> >> >>
> >>> >> >> Martin Grigorov
> >>> >> >> Wicket Training and Consulting
> >>> >> >> https://twitter.com/mtgrigorov
> >>> >> >>
> >>> >> >> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <
> pedrosans@gmail.com>
> >>> >> wrote:
> >>> >> >>
> >>> >> >>> We can replace ClassMetaCache used in wicket-ioc's Injector by a
> >>> >> Jandex[1]
> >>> >> >>> class index.
> >>> >> >>>
> >>> >> >>> 1 - https://github.com/wildfly/jandex
> >>> >> >>>
> >>> >> >>> Pedro Santos
> >>> >> >>>
> >>> >> >>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <
> >>> mgrigorov@apache.org
> >>> >> >
> >>> >> >>> wrote:
> >>> >> >>>
> >>> >> >>> > The main advantages of ByteBuddy are:
> >>> >> >>> > - actively developed
> >>> >> >>> > - Mockito 2 moved to it
> >>> >> >>> > - Hibernate 5.x is moving to it (
> >>> >> >>> > https://twitter.com/vlad_mihalcea/status/798971296910483456)
> >>> >> >>> > - Spring considers it (they actually already use it for the
> tests:
> >>> >> >>> > https://twitter.com/ankinson/status/799363435775586308)
> >>> >> >>> > - support for Java 9 (we will need it at some point)
> >>> >> >>> > - support for Android (I guess no one will ever run Wicket
> inside
> >>> >> >>> Android,
> >>> >> >>> > but who knows)
> >>> >> >>> >
> >>> >> >>> >
> >>> >> >>> >
> >>> >> >>> > Martin Grigorov
> >>> >> >>> > Wicket Training and Consulting
> >>> >> >>> > https://twitter.com/mtgrigorov
> >>> >> >>> >
> >>> >> >>> > On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net>
> >>> wrote:
> >>> >> >>> >
> >>> >> >>> > > Replace CGLIB with ByteBuddy because it has better support
> for
> >>> >> Java 8
> >>> >> >>> > and 9
> >>> >> >>> > >>
> >>> >> >>> > >
> >>> >> >>> > > What are the advantages? Seems Spring hasn't decided on this
> >>> yet:
> >>> >> >>> > >
> >>> >> >>> > > https://jira.spring.io/browse/SPR-8190
> >>> >> >>> > >
> >>> >> >>> > > Regards
> >>> >> >>> > > Sven
> >>> >> >>> > >
> >>> >> >>> > >
> >>> >> >>> > >
> >>> >> >>> > > On 20.11.2016 00:47, Martin Grigorov wrote:
> >>> >> >>> > >
> >>> >> >>> > >> Replace CGLIB with ByteBuddy because it has better support
> for
> >>> >> Java 8
> >>> >> >>> > and
> >>> >> >>> > >> 9
> >>> >> >>> > >> ?
> >>> >> >>> > >> CGLIB could stay as fallback (via system property) until
> 9.0.0.
> >>> >> >>> > >>
> >>> >> >>> > >> Martin Grigorov
> >>> >> >>> > >> Wicket Training and Consulting
> >>> >> >>> > >> https://twitter.com/mtgrigorov
> >>> >> >>> > >>
> >>> >> >>> > >> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
> >>> >> >>> an.delbene@gmail.com
> >>> >> >>> > >
> >>> >> >>> > >> wrote:
> >>> >> >>> > >>
> >>> >> >>> > >> yah, I think it's better
> >>> >> >>> > >>>
> >>> >> >>> > >>>
> >>> >> >>> > >>>
> >>> >> >>> > >>> On 14/11/2016 19:54, Martin Grigorov wrote:
> >>> >> >>> > >>>
> >>> >> >>> > >>> +1
> >>> >> >>> > >>>>
> >>> >> >>> > >>>> Maybe rename #forResource() to #of() ?
> >>> >> >>> > >>>>
> >>> >> >>> > >>>> Martin Grigorov
> >>> >> >>> > >>>> Wicket Training and Consulting
> >>> >> >>> > >>>> https://twitter.com/mtgrigorov
> >>> >> >>> > >>>>
> >>> >> >>> > >>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
> >>> >> >>> > an.delbene@gmail.com>
> >>> >> >>> > >>>> wrote:
> >>> >> >>> > >>>>
> >>> >> >>> > >>>> I'm wondering if there is room for an improvement for
> >>> >> >>> > ResourceReference,
> >>> >> >>> > >>>>
> >>> >> >>> > >>>>> introducing lambda support also for this component.
> Actually
> >>> >> it's
> >>> >> >>> > >>>>> something
> >>> >> >>> > >>>>> that can be done after the release of 8.0.0, but I'd
> like to
> >>> >> >>> collect
> >>> >> >>> > >>>>> your
> >>> >> >>> > >>>>> feedback anyway. The idea is to provide factory methods
> to
> >>> >> build a
> >>> >> >>> > >>>>> ResourceReference using lambdas and avoiding anonymous
> >>> classes
> >>> >> to
> >>> >> >>> > >>>>> implement
> >>> >> >>> > >>>>> getResource().
> >>> >> >>> > >>>>> The following snippet should better explain what I mean:
> >>> >> >>> > >>>>>
> >>> >> >>> > >>>>> https://gist.github.com/bitstorm/
> >>> >> 03cfe9905a3f86a7160ab49f0ce23f13
> >>> >> >>> > >>>>>
> >>> >> >>> > >>>>> Andrea.
> >>> >> >>> > >>>>>
> >>> >> >>> > >>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
> >>> >> >>> > >>>>>
> >>> >> >>> > >>>>> Hi,
> >>> >> >>> > >>>>>
> >>> >> >>> > >>>>>> What other improvements do we need in 8.x/master before
> >>> >> >>> promoting it
> >>> >> >>> > >>>>>> to
> >>> >> >>> > >>>>>> 8.0.0 final ?
> >>> >> >>> > >>>>>>
> >>> >> >>> > >>>>>> At https://cwiki.apache.org/confluence/display/WICKET/
> >>> Ideas+
> >>> >> >>> > >>>>>> for+Wicket+8.0
> >>> >> >>> > >>>>>> we still have:
> >>> >> >>> > >>>>>>
> >>> >> >>> > >>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
> >>> >> >>> > >>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* -
> >>> I'll
> >>> >> give
> >>> >> >>> > this
> >>> >> >>> > >>>>>> one
> >>> >> >>> > >>>>>> more try but the problem is that I don't believe this
> is
> >>> the
> >>> >> >>> proper
> >>> >> >>> > >>>>>> way
> >>> >> >>> > >>>>>> and
> >>> >> >>> > >>>>>> this demotivates me.
> >>> >> >>> > >>>>>> If someone else wants to give it a try - please assign
> it
> >>> to
> >>> >> >>> > yourself!
> >>> >> >>> > >>>>>>
> >>> >> >>> > >>>>>> - Better SEO for stateful pages - the only way I see
> this
> >>> is
> >>> >> by
> >>> >> >>> > using
> >>> >> >>> > >>>>>> ServiceWorker to add the pageId as a request header to
> all
> >>> >> >>> requests
> >>> >> >>> > >>>>>> (normal
> >>> >> >>> > >>>>>> & Ajax)
> >>> >> >>> > >>>>>>
> >>> >> >>> > >>>>>>
> >>> >> >>> > >>>>>> Recently I wondered whether Redux.js could be in use
> for
> >>> >> Wicket.
> >>> >> >>> > >>>>>> I don't have much experience with it, but both React
> and
> >>> >> >>> AngularJs
> >>> >> >>> > >>>>>> communities use it to manage the state for their
> >>> components.
> >>> >> >>> > >>>>>> There are some Java impls, even a standard is coming:
> >>> >> >>> > >>>>>> https://github.com/jvm-redux/jvm-redux-api
> >>> >> >>> > >>>>>>
> >>> >> >>> > >>>>>> What else ?
> >>> >> >>> > >>>>>>
> >>> >> >>> > >>>>>> Martin Grigorov
> >>> >> >>> > >>>>>> Wicket Training and Consulting
> >>> >> >>> > >>>>>> https://twitter.com/mtgrigorov
> >>> >> >>> > >>>>>>
> >>> >> >>> > >>>>>>
> >>> >> >>> > >>>>>>
> >>> >> >>> > >>>>>>
> >>> >> >>> > >
> >>> >> >>> >
> >>> >> >>>
> >>> >> >>
> >>> >> >>
> >>> >>
> >>>
>
>
>
> --
> WBR
> Maxim aka solomax
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Maxim Solodovnik <so...@gmail.com>.
Hello All,
JFYI I have moved Apache OpenMeetings to Wicket-8 without any issues
in ~30 minutes :)
On Wed, Feb 1, 2017 at 9:04 AM, Pedro Santos <pe...@gmail.com> wrote:
> Hi Martin,
>
>> The comparison with the component queueing is because again we are going to introduce a change that no one ever asked for
>
> I asked for, and think I did a good job analyzing the current
> PropertyResolver and concluding that it's getting too complex and
> should be improved for better maintainability.
>
>> The parser will report errors at runtime so the developers will have to go thru all the functionality of their apps to make sure it still works. So the benefit is questionable! At least to me.
>
> If we have a page with conditionally visible components, it can
> happens that a problematic property expression goes unnoticed until we
> get its problematic component visible and rendered. With a parser we
> can detect and report syntax errors as soon as we construct a
> PropertyModel while initializing the page. In this case the developer
> would got an early exception that could otherwise go unnoticed for a
> long time. The benefit does exists, I will take that you think it's
> value is questionable.
>
>> Sven made this pluggable so if the application has custom needs then it is possible to setup custom resolver.
>> I'd prefer to see the new parser as a pluggable replacement too! So if it breaks someone's application then just switch back to the old impl.
>
> I addressed both points in my reply to Sven.
>
>> I'd like to see 8.0.0 released sooner rather than later.
>
> Me too. I have no clients under a promised Wicket 8 release date, it's
> my purely my personal view that Wicket 8 is the right place for
> proposed improvements.
>
> Pedro Santos
>
>
> On Tue, Jan 31, 2017 at 1:58 PM, Martin Grigorov <mg...@apache.org> wrote:
>> Hi Pedro,
>>
>> On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@gmail.com> wrote:
>>
>>> Hi Martin,
>>>
>>> you missed the point of the proposal at [1], it's a syntax change that
>>> would move Wicket's expression language closer to Unified Expression
>>> Language. This change would better welcome developers used to work
>>> with expressions like: bean.map["key"] and move Wicket closer to JSR
>>> 341 (we can continue on the linked thread).
>>>
>>
>> Yes, it seems I didn't understand it right. I thought both are related -
>> the parser is being introduced to be able to deal with the new syntax.
>>
>>
>>>
>>> The branch you pointed is the implementation of a parser to replace
>>> your current tokenizer inside PropertyResolver.
>>>
>>
>> It is not mine. It was already there when I started using Wicket.
>>
>>
>>>
>>> The comparison to the component queueing is vague. It was a new
>>> feature in Wicket 7 rather and a improvement aiming to give users
>>> earlier syntax errors plus to improve PropertyResolver's
>>> maintainability by replacing organic grown code with a structured
>>> syntax tree.
>>>
>>
>> The comparison with the component queueing is because again we are going to
>> introduce a change that no one ever asked for (well technically, Martin
>> Makundi asked for Component Queueing but he still uses Wicket 1.4.x
>> nowadays!) and this change might break many applications in production.
>> The parser will report errors at runtime so the developers will have to go
>> thru all the functionality of their apps to make sure it still works.
>> So the benefit is questionable! At least to me.
>>
>> WICKET-4088 is created 5 years ago and since then no one ever reported any
>> problem related to this functionality (the map syntax).
>> The only related ticket I'm aware of is
>> https://issues.apache.org/jira/browse/WICKET-5623.
>> Sven made this pluggable so if the application has custom needs then it is
>> possible to setup custom resolver.
>> I'd prefer to see the new parser as a pluggable replacement too! So if it
>> breaks someone's application then just switch back to the old impl.
>>
>> So I'm -0 on this improvement but let's see what others think too!
>> I'd like to see 8.0.0 released sooner rather than later.
>>
>>
>>>
>>> I understand and share your concern about maintenance. It's my
>>> understand that the entire team signs a release, and that we all can
>>> support and maintain the features inside it. I will understand if
>>> anyone stops this improvement based on cost/benefit analysis or on the
>>> merit that it's hard to maintain a parser. I do not share such
>>> concerns and pointed out the benefits of such improvement at [2] (we
>>> can continue on the linked thread).
>>>
>>> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
>>> 2 - http://markmail.org/message/yc2pwmbmasx5rzim
>>>
>>> On Tue, Jan 31, 2017 at 10:13 AM, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>> > Hi Pedro,
>>> >
>>> > On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@gmail.com>
>>> wrote:
>>> >
>>> >> Hi Martin,
>>> >>
>>> >> Wicket-4201 IPageProvider improvement: will work on the ticket during
>>> the
>>> >> week
>>> >>
>>> >> Expression language change [1]: it's a big change and I think it needs
>>> >> the team approval
>>> >>
>>> >
>>> > Here is the diff:
>>> > https://github.com/apache/wicket/compare/WICKET-4008-
>>> property-expression-parser
>>> >
>>> >
>>> >>
>>> >> Wicket-4008 expression language parser: the parser is functional and
>>> >> there isn't much work pending on it. I can finish and merge the work
>>> >> during the week.
>>> >>
>>> >> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
>>> >
>>> >
>>> > The linked discussion makes me feel a bit uncertain.
>>> > I want to avoid another "component queueing" case here, i.e. a rather
>>> > bigger refactoring for something that only few people asked for and then
>>> > leave the maintenance to someone else. The fact that you didn't have time
>>> > to work on these changes in the last few months makes me think you may
>>> not
>>> > have time to answer questions and fix bugs once it is released. No one
>>> can
>>> > guarantee that (s)he will be around to help with his/her expertize, me
>>> > included, but if you know from now that you won't have time then maybe it
>>> > would be better to not make these changes.
>>> >
>>> > I agree that the team should decide so anyone is welcome to express his
>>> > opinion!
>>> >
>>> >
>>> >>
>>> >> Pedro Santos
>>> >>
>>> >>
>>> >> On Thu, Jan 12, 2017 at 9:08 PM, Martin Grigorov <mg...@apache.org>
>>> >> wrote:
>>> >> > Hi,
>>> >> >
>>> >> > @Sven: have you started migrating your app ?
>>> >> >
>>> >> > @Pedro: any idea when you will have time to finish your improvements?
>>> Do
>>> >> > you need any help ?
>>> >> >
>>> >> >
>>> >> >
>>> >> > Martin Grigorov
>>> >> > Wicket Training and Consulting
>>> >> > https://twitter.com/mtgrigorov
>>> >> >
>>> >> > On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <
>>> mgrigorov@apache.org>
>>> >> > wrote:
>>> >> >
>>> >> >> Probably we should stick to the principle: If it works, don't touch
>>> it!
>>> >> >> This is related to CGLib and ClassMetaCache
>>> >> >>
>>> >> >> Martin Grigorov
>>> >> >> Wicket Training and Consulting
>>> >> >> https://twitter.com/mtgrigorov
>>> >> >>
>>> >> >> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com>
>>> >> wrote:
>>> >> >>
>>> >> >>> We can replace ClassMetaCache used in wicket-ioc's Injector by a
>>> >> Jandex[1]
>>> >> >>> class index.
>>> >> >>>
>>> >> >>> 1 - https://github.com/wildfly/jandex
>>> >> >>>
>>> >> >>> Pedro Santos
>>> >> >>>
>>> >> >>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <
>>> mgrigorov@apache.org
>>> >> >
>>> >> >>> wrote:
>>> >> >>>
>>> >> >>> > The main advantages of ByteBuddy are:
>>> >> >>> > - actively developed
>>> >> >>> > - Mockito 2 moved to it
>>> >> >>> > - Hibernate 5.x is moving to it (
>>> >> >>> > https://twitter.com/vlad_mihalcea/status/798971296910483456)
>>> >> >>> > - Spring considers it (they actually already use it for the tests:
>>> >> >>> > https://twitter.com/ankinson/status/799363435775586308)
>>> >> >>> > - support for Java 9 (we will need it at some point)
>>> >> >>> > - support for Android (I guess no one will ever run Wicket inside
>>> >> >>> Android,
>>> >> >>> > but who knows)
>>> >> >>> >
>>> >> >>> >
>>> >> >>> >
>>> >> >>> > Martin Grigorov
>>> >> >>> > Wicket Training and Consulting
>>> >> >>> > https://twitter.com/mtgrigorov
>>> >> >>> >
>>> >> >>> > On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net>
>>> wrote:
>>> >> >>> >
>>> >> >>> > > Replace CGLIB with ByteBuddy because it has better support for
>>> >> Java 8
>>> >> >>> > and 9
>>> >> >>> > >>
>>> >> >>> > >
>>> >> >>> > > What are the advantages? Seems Spring hasn't decided on this
>>> yet:
>>> >> >>> > >
>>> >> >>> > > https://jira.spring.io/browse/SPR-8190
>>> >> >>> > >
>>> >> >>> > > Regards
>>> >> >>> > > Sven
>>> >> >>> > >
>>> >> >>> > >
>>> >> >>> > >
>>> >> >>> > > On 20.11.2016 00:47, Martin Grigorov wrote:
>>> >> >>> > >
>>> >> >>> > >> Replace CGLIB with ByteBuddy because it has better support for
>>> >> Java 8
>>> >> >>> > and
>>> >> >>> > >> 9
>>> >> >>> > >> ?
>>> >> >>> > >> CGLIB could stay as fallback (via system property) until 9.0.0.
>>> >> >>> > >>
>>> >> >>> > >> Martin Grigorov
>>> >> >>> > >> Wicket Training and Consulting
>>> >> >>> > >> https://twitter.com/mtgrigorov
>>> >> >>> > >>
>>> >> >>> > >> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>>> >> >>> an.delbene@gmail.com
>>> >> >>> > >
>>> >> >>> > >> wrote:
>>> >> >>> > >>
>>> >> >>> > >> yah, I think it's better
>>> >> >>> > >>>
>>> >> >>> > >>>
>>> >> >>> > >>>
>>> >> >>> > >>> On 14/11/2016 19:54, Martin Grigorov wrote:
>>> >> >>> > >>>
>>> >> >>> > >>> +1
>>> >> >>> > >>>>
>>> >> >>> > >>>> Maybe rename #forResource() to #of() ?
>>> >> >>> > >>>>
>>> >> >>> > >>>> Martin Grigorov
>>> >> >>> > >>>> Wicket Training and Consulting
>>> >> >>> > >>>> https://twitter.com/mtgrigorov
>>> >> >>> > >>>>
>>> >> >>> > >>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>>> >> >>> > an.delbene@gmail.com>
>>> >> >>> > >>>> wrote:
>>> >> >>> > >>>>
>>> >> >>> > >>>> I'm wondering if there is room for an improvement for
>>> >> >>> > ResourceReference,
>>> >> >>> > >>>>
>>> >> >>> > >>>>> introducing lambda support also for this component. Actually
>>> >> it's
>>> >> >>> > >>>>> something
>>> >> >>> > >>>>> that can be done after the release of 8.0.0, but I'd like to
>>> >> >>> collect
>>> >> >>> > >>>>> your
>>> >> >>> > >>>>> feedback anyway. The idea is to provide factory methods to
>>> >> build a
>>> >> >>> > >>>>> ResourceReference using lambdas and avoiding anonymous
>>> classes
>>> >> to
>>> >> >>> > >>>>> implement
>>> >> >>> > >>>>> getResource().
>>> >> >>> > >>>>> The following snippet should better explain what I mean:
>>> >> >>> > >>>>>
>>> >> >>> > >>>>> https://gist.github.com/bitstorm/
>>> >> 03cfe9905a3f86a7160ab49f0ce23f13
>>> >> >>> > >>>>>
>>> >> >>> > >>>>> Andrea.
>>> >> >>> > >>>>>
>>> >> >>> > >>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>> >> >>> > >>>>>
>>> >> >>> > >>>>> Hi,
>>> >> >>> > >>>>>
>>> >> >>> > >>>>>> What other improvements do we need in 8.x/master before
>>> >> >>> promoting it
>>> >> >>> > >>>>>> to
>>> >> >>> > >>>>>> 8.0.0 final ?
>>> >> >>> > >>>>>>
>>> >> >>> > >>>>>> At https://cwiki.apache.org/confluence/display/WICKET/
>>> Ideas+
>>> >> >>> > >>>>>> for+Wicket+8.0
>>> >> >>> > >>>>>> we still have:
>>> >> >>> > >>>>>>
>>> >> >>> > >>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>> >> >>> > >>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* -
>>> I'll
>>> >> give
>>> >> >>> > this
>>> >> >>> > >>>>>> one
>>> >> >>> > >>>>>> more try but the problem is that I don't believe this is
>>> the
>>> >> >>> proper
>>> >> >>> > >>>>>> way
>>> >> >>> > >>>>>> and
>>> >> >>> > >>>>>> this demotivates me.
>>> >> >>> > >>>>>> If someone else wants to give it a try - please assign it
>>> to
>>> >> >>> > yourself!
>>> >> >>> > >>>>>>
>>> >> >>> > >>>>>> - Better SEO for stateful pages - the only way I see this
>>> is
>>> >> by
>>> >> >>> > using
>>> >> >>> > >>>>>> ServiceWorker to add the pageId as a request header to all
>>> >> >>> requests
>>> >> >>> > >>>>>> (normal
>>> >> >>> > >>>>>> & Ajax)
>>> >> >>> > >>>>>>
>>> >> >>> > >>>>>>
>>> >> >>> > >>>>>> Recently I wondered whether Redux.js could be in use for
>>> >> Wicket.
>>> >> >>> > >>>>>> I don't have much experience with it, but both React and
>>> >> >>> AngularJs
>>> >> >>> > >>>>>> communities use it to manage the state for their
>>> components.
>>> >> >>> > >>>>>> There are some Java impls, even a standard is coming:
>>> >> >>> > >>>>>> https://github.com/jvm-redux/jvm-redux-api
>>> >> >>> > >>>>>>
>>> >> >>> > >>>>>> What else ?
>>> >> >>> > >>>>>>
>>> >> >>> > >>>>>> Martin Grigorov
>>> >> >>> > >>>>>> Wicket Training and Consulting
>>> >> >>> > >>>>>> https://twitter.com/mtgrigorov
>>> >> >>> > >>>>>>
>>> >> >>> > >>>>>>
>>> >> >>> > >>>>>>
>>> >> >>> > >>>>>>
>>> >> >>> > >
>>> >> >>> >
>>> >> >>>
>>> >> >>
>>> >> >>
>>> >>
>>>
--
WBR
Maxim aka solomax
Re: What else do we want to do before 8.0.0 final ?
Posted by Pedro Santos <pe...@gmail.com>.
Hi Martin,
> The comparison with the component queueing is because again we are going to introduce a change that no one ever asked for
I asked for, and think I did a good job analyzing the current
PropertyResolver and concluding that it's getting too complex and
should be improved for better maintainability.
> The parser will report errors at runtime so the developers will have to go thru all the functionality of their apps to make sure it still works. So the benefit is questionable! At least to me.
If we have a page with conditionally visible components, it can
happens that a problematic property expression goes unnoticed until we
get its problematic component visible and rendered. With a parser we
can detect and report syntax errors as soon as we construct a
PropertyModel while initializing the page. In this case the developer
would got an early exception that could otherwise go unnoticed for a
long time. The benefit does exists, I will take that you think it's
value is questionable.
> Sven made this pluggable so if the application has custom needs then it is possible to setup custom resolver.
> I'd prefer to see the new parser as a pluggable replacement too! So if it breaks someone's application then just switch back to the old impl.
I addressed both points in my reply to Sven.
> I'd like to see 8.0.0 released sooner rather than later.
Me too. I have no clients under a promised Wicket 8 release date, it's
my purely my personal view that Wicket 8 is the right place for
proposed improvements.
Pedro Santos
On Tue, Jan 31, 2017 at 1:58 PM, Martin Grigorov <mg...@apache.org> wrote:
> Hi Pedro,
>
> On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@gmail.com> wrote:
>
>> Hi Martin,
>>
>> you missed the point of the proposal at [1], it's a syntax change that
>> would move Wicket's expression language closer to Unified Expression
>> Language. This change would better welcome developers used to work
>> with expressions like: bean.map["key"] and move Wicket closer to JSR
>> 341 (we can continue on the linked thread).
>>
>
> Yes, it seems I didn't understand it right. I thought both are related -
> the parser is being introduced to be able to deal with the new syntax.
>
>
>>
>> The branch you pointed is the implementation of a parser to replace
>> your current tokenizer inside PropertyResolver.
>>
>
> It is not mine. It was already there when I started using Wicket.
>
>
>>
>> The comparison to the component queueing is vague. It was a new
>> feature in Wicket 7 rather and a improvement aiming to give users
>> earlier syntax errors plus to improve PropertyResolver's
>> maintainability by replacing organic grown code with a structured
>> syntax tree.
>>
>
> The comparison with the component queueing is because again we are going to
> introduce a change that no one ever asked for (well technically, Martin
> Makundi asked for Component Queueing but he still uses Wicket 1.4.x
> nowadays!) and this change might break many applications in production.
> The parser will report errors at runtime so the developers will have to go
> thru all the functionality of their apps to make sure it still works.
> So the benefit is questionable! At least to me.
>
> WICKET-4088 is created 5 years ago and since then no one ever reported any
> problem related to this functionality (the map syntax).
> The only related ticket I'm aware of is
> https://issues.apache.org/jira/browse/WICKET-5623.
> Sven made this pluggable so if the application has custom needs then it is
> possible to setup custom resolver.
> I'd prefer to see the new parser as a pluggable replacement too! So if it
> breaks someone's application then just switch back to the old impl.
>
> So I'm -0 on this improvement but let's see what others think too!
> I'd like to see 8.0.0 released sooner rather than later.
>
>
>>
>> I understand and share your concern about maintenance. It's my
>> understand that the entire team signs a release, and that we all can
>> support and maintain the features inside it. I will understand if
>> anyone stops this improvement based on cost/benefit analysis or on the
>> merit that it's hard to maintain a parser. I do not share such
>> concerns and pointed out the benefits of such improvement at [2] (we
>> can continue on the linked thread).
>>
>> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
>> 2 - http://markmail.org/message/yc2pwmbmasx5rzim
>>
>> On Tue, Jan 31, 2017 at 10:13 AM, Martin Grigorov <mg...@apache.org>
>> wrote:
>> > Hi Pedro,
>> >
>> > On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@gmail.com>
>> wrote:
>> >
>> >> Hi Martin,
>> >>
>> >> Wicket-4201 IPageProvider improvement: will work on the ticket during
>> the
>> >> week
>> >>
>> >> Expression language change [1]: it's a big change and I think it needs
>> >> the team approval
>> >>
>> >
>> > Here is the diff:
>> > https://github.com/apache/wicket/compare/WICKET-4008-
>> property-expression-parser
>> >
>> >
>> >>
>> >> Wicket-4008 expression language parser: the parser is functional and
>> >> there isn't much work pending on it. I can finish and merge the work
>> >> during the week.
>> >>
>> >> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
>> >
>> >
>> > The linked discussion makes me feel a bit uncertain.
>> > I want to avoid another "component queueing" case here, i.e. a rather
>> > bigger refactoring for something that only few people asked for and then
>> > leave the maintenance to someone else. The fact that you didn't have time
>> > to work on these changes in the last few months makes me think you may
>> not
>> > have time to answer questions and fix bugs once it is released. No one
>> can
>> > guarantee that (s)he will be around to help with his/her expertize, me
>> > included, but if you know from now that you won't have time then maybe it
>> > would be better to not make these changes.
>> >
>> > I agree that the team should decide so anyone is welcome to express his
>> > opinion!
>> >
>> >
>> >>
>> >> Pedro Santos
>> >>
>> >>
>> >> On Thu, Jan 12, 2017 at 9:08 PM, Martin Grigorov <mg...@apache.org>
>> >> wrote:
>> >> > Hi,
>> >> >
>> >> > @Sven: have you started migrating your app ?
>> >> >
>> >> > @Pedro: any idea when you will have time to finish your improvements?
>> Do
>> >> > you need any help ?
>> >> >
>> >> >
>> >> >
>> >> > Martin Grigorov
>> >> > Wicket Training and Consulting
>> >> > https://twitter.com/mtgrigorov
>> >> >
>> >> > On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <
>> mgrigorov@apache.org>
>> >> > wrote:
>> >> >
>> >> >> Probably we should stick to the principle: If it works, don't touch
>> it!
>> >> >> This is related to CGLib and ClassMetaCache
>> >> >>
>> >> >> Martin Grigorov
>> >> >> Wicket Training and Consulting
>> >> >> https://twitter.com/mtgrigorov
>> >> >>
>> >> >> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com>
>> >> wrote:
>> >> >>
>> >> >>> We can replace ClassMetaCache used in wicket-ioc's Injector by a
>> >> Jandex[1]
>> >> >>> class index.
>> >> >>>
>> >> >>> 1 - https://github.com/wildfly/jandex
>> >> >>>
>> >> >>> Pedro Santos
>> >> >>>
>> >> >>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <
>> mgrigorov@apache.org
>> >> >
>> >> >>> wrote:
>> >> >>>
>> >> >>> > The main advantages of ByteBuddy are:
>> >> >>> > - actively developed
>> >> >>> > - Mockito 2 moved to it
>> >> >>> > - Hibernate 5.x is moving to it (
>> >> >>> > https://twitter.com/vlad_mihalcea/status/798971296910483456)
>> >> >>> > - Spring considers it (they actually already use it for the tests:
>> >> >>> > https://twitter.com/ankinson/status/799363435775586308)
>> >> >>> > - support for Java 9 (we will need it at some point)
>> >> >>> > - support for Android (I guess no one will ever run Wicket inside
>> >> >>> Android,
>> >> >>> > but who knows)
>> >> >>> >
>> >> >>> >
>> >> >>> >
>> >> >>> > Martin Grigorov
>> >> >>> > Wicket Training and Consulting
>> >> >>> > https://twitter.com/mtgrigorov
>> >> >>> >
>> >> >>> > On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net>
>> wrote:
>> >> >>> >
>> >> >>> > > Replace CGLIB with ByteBuddy because it has better support for
>> >> Java 8
>> >> >>> > and 9
>> >> >>> > >>
>> >> >>> > >
>> >> >>> > > What are the advantages? Seems Spring hasn't decided on this
>> yet:
>> >> >>> > >
>> >> >>> > > https://jira.spring.io/browse/SPR-8190
>> >> >>> > >
>> >> >>> > > Regards
>> >> >>> > > Sven
>> >> >>> > >
>> >> >>> > >
>> >> >>> > >
>> >> >>> > > On 20.11.2016 00:47, Martin Grigorov wrote:
>> >> >>> > >
>> >> >>> > >> Replace CGLIB with ByteBuddy because it has better support for
>> >> Java 8
>> >> >>> > and
>> >> >>> > >> 9
>> >> >>> > >> ?
>> >> >>> > >> CGLIB could stay as fallback (via system property) until 9.0.0.
>> >> >>> > >>
>> >> >>> > >> Martin Grigorov
>> >> >>> > >> Wicket Training and Consulting
>> >> >>> > >> https://twitter.com/mtgrigorov
>> >> >>> > >>
>> >> >>> > >> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>> >> >>> an.delbene@gmail.com
>> >> >>> > >
>> >> >>> > >> wrote:
>> >> >>> > >>
>> >> >>> > >> yah, I think it's better
>> >> >>> > >>>
>> >> >>> > >>>
>> >> >>> > >>>
>> >> >>> > >>> On 14/11/2016 19:54, Martin Grigorov wrote:
>> >> >>> > >>>
>> >> >>> > >>> +1
>> >> >>> > >>>>
>> >> >>> > >>>> Maybe rename #forResource() to #of() ?
>> >> >>> > >>>>
>> >> >>> > >>>> Martin Grigorov
>> >> >>> > >>>> Wicket Training and Consulting
>> >> >>> > >>>> https://twitter.com/mtgrigorov
>> >> >>> > >>>>
>> >> >>> > >>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>> >> >>> > an.delbene@gmail.com>
>> >> >>> > >>>> wrote:
>> >> >>> > >>>>
>> >> >>> > >>>> I'm wondering if there is room for an improvement for
>> >> >>> > ResourceReference,
>> >> >>> > >>>>
>> >> >>> > >>>>> introducing lambda support also for this component. Actually
>> >> it's
>> >> >>> > >>>>> something
>> >> >>> > >>>>> that can be done after the release of 8.0.0, but I'd like to
>> >> >>> collect
>> >> >>> > >>>>> your
>> >> >>> > >>>>> feedback anyway. The idea is to provide factory methods to
>> >> build a
>> >> >>> > >>>>> ResourceReference using lambdas and avoiding anonymous
>> classes
>> >> to
>> >> >>> > >>>>> implement
>> >> >>> > >>>>> getResource().
>> >> >>> > >>>>> The following snippet should better explain what I mean:
>> >> >>> > >>>>>
>> >> >>> > >>>>> https://gist.github.com/bitstorm/
>> >> 03cfe9905a3f86a7160ab49f0ce23f13
>> >> >>> > >>>>>
>> >> >>> > >>>>> Andrea.
>> >> >>> > >>>>>
>> >> >>> > >>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>> >> >>> > >>>>>
>> >> >>> > >>>>> Hi,
>> >> >>> > >>>>>
>> >> >>> > >>>>>> What other improvements do we need in 8.x/master before
>> >> >>> promoting it
>> >> >>> > >>>>>> to
>> >> >>> > >>>>>> 8.0.0 final ?
>> >> >>> > >>>>>>
>> >> >>> > >>>>>> At https://cwiki.apache.org/confluence/display/WICKET/
>> Ideas+
>> >> >>> > >>>>>> for+Wicket+8.0
>> >> >>> > >>>>>> we still have:
>> >> >>> > >>>>>>
>> >> >>> > >>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>> >> >>> > >>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* -
>> I'll
>> >> give
>> >> >>> > this
>> >> >>> > >>>>>> one
>> >> >>> > >>>>>> more try but the problem is that I don't believe this is
>> the
>> >> >>> proper
>> >> >>> > >>>>>> way
>> >> >>> > >>>>>> and
>> >> >>> > >>>>>> this demotivates me.
>> >> >>> > >>>>>> If someone else wants to give it a try - please assign it
>> to
>> >> >>> > yourself!
>> >> >>> > >>>>>>
>> >> >>> > >>>>>> - Better SEO for stateful pages - the only way I see this
>> is
>> >> by
>> >> >>> > using
>> >> >>> > >>>>>> ServiceWorker to add the pageId as a request header to all
>> >> >>> requests
>> >> >>> > >>>>>> (normal
>> >> >>> > >>>>>> & Ajax)
>> >> >>> > >>>>>>
>> >> >>> > >>>>>>
>> >> >>> > >>>>>> Recently I wondered whether Redux.js could be in use for
>> >> Wicket.
>> >> >>> > >>>>>> I don't have much experience with it, but both React and
>> >> >>> AngularJs
>> >> >>> > >>>>>> communities use it to manage the state for their
>> components.
>> >> >>> > >>>>>> There are some Java impls, even a standard is coming:
>> >> >>> > >>>>>> https://github.com/jvm-redux/jvm-redux-api
>> >> >>> > >>>>>>
>> >> >>> > >>>>>> What else ?
>> >> >>> > >>>>>>
>> >> >>> > >>>>>> Martin Grigorov
>> >> >>> > >>>>>> Wicket Training and Consulting
>> >> >>> > >>>>>> https://twitter.com/mtgrigorov
>> >> >>> > >>>>>>
>> >> >>> > >>>>>>
>> >> >>> > >>>>>>
>> >> >>> > >>>>>>
>> >> >>> > >
>> >> >>> >
>> >> >>>
>> >> >>
>> >> >>
>> >>
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Pedro Santos <pe...@gmail.com>.
Hi Sven,
> PropertyResolver is very lenient currently, defining the dot (.) as a separator of properties only - there's not much more about it.
There is. Take the expression "a.b.c", there's no guarantee Wicket's
tokenizer will break it only by dots. A custom IPropertyLocator
currently has to handle possible scenarios where the tokens are "a.b"
+ "c" or "a" + "b.c". Plus there's a dot escaping logic that won't
allow a user to express a map value if its key contains a closing
bracket followed by a dot; as explained in WICKET-6247 and a possible
solution being Wicket's expression language syntax change proposed in
[1].
You and Martin have a good point saying the architecture should be
pluggable or configurable. Both use cases you pointed should be able
to be supported by a custom implementation of a pluggable property
resolver, and not as a one more complexity in an already tangled and
all purpose resolver as PropertyResolver has grown to be. Rather than
to open PropertyResolver to custom IPropertyLocator implementations,
we should open the Application to custom PropertyResolver
implementations. So even an expression language that is not as unique
as Wicket's one would have it's place.
> Both are no longer valid with your proposal, because they are no valid Java syntax or "unified EL".
The parser aims to be the default implementation offering early and
meaningful syntax errors plus offering the resolver a structured
syntax tree to work on. I invite the team to read
DefaultPropertyLocator's implementation to get the importance of it.
The parser wasn't meant to invalidate any other syntax and I would
support the choice to have a configurable resolver implementation in
the Application rather the current complex all purpose and
configurable resolver that only work for very specific dot tokenizer
logic.
> I don't understand (yet) what advantage justifies this restriction. For me a pluggable architecture is more valuable than a strict syntax.
Sure, my point is let's make the it pluggable in a better place and
the default resolver to be a simpler syntax closer to the standard
JSR-341.
1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
Pedro Santos
On Tue, Jan 31, 2017 at 7:59 PM, Sven Meier <sv...@meiers.net> wrote:
> Hi Pedro,
>
> PropertyResolver is very lenient currently, defining the dot (.) as a
> separator of properties only - there's not much more about it.
>
> With a custom IPropertyLocator (WICKET-5623) the following is supported too:
>
> PropertyResolver.getValue("foo.bar.path/to/node", document);
> PropertyResolver.getValue("foo.bar.attribute(name)", document);
>
> Both are no longer valid with your proposal, because they are no valid Java
> syntax or "unified EL".
> IMHO this goes in the wrong direction, it takes possibilities away instead
> of enabling users to customize property resolving.
>
> I don't understand (yet) what advantage justifies this restriction. For me a
> pluggable architecture is more valuable than a strict syntax.
>
> Regards
> Sven
>
>
>
> On 31.01.2017 16:58, Martin Grigorov wrote:
>>
>> Hi Pedro,
>>
>> On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@gmail.com> wrote:
>>
>>> Hi Martin,
>>>
>>> you missed the point of the proposal at [1], it's a syntax change that
>>> would move Wicket's expression language closer to Unified Expression
>>> Language. This change would better welcome developers used to work
>>> with expressions like: bean.map["key"] and move Wicket closer to JSR
>>> 341 (we can continue on the linked thread).
>>>
>> Yes, it seems I didn't understand it right. I thought both are related -
>> the parser is being introduced to be able to deal with the new syntax.
>>
>>
>>> The branch you pointed is the implementation of a parser to replace
>>> your current tokenizer inside PropertyResolver.
>>>
>> It is not mine. It was already there when I started using Wicket.
>>
>>
>>> The comparison to the component queueing is vague. It was a new
>>> feature in Wicket 7 rather and a improvement aiming to give users
>>> earlier syntax errors plus to improve PropertyResolver's
>>> maintainability by replacing organic grown code with a structured
>>> syntax tree.
>>>
>> The comparison with the component queueing is because again we are going
>> to
>> introduce a change that no one ever asked for (well technically, Martin
>> Makundi asked for Component Queueing but he still uses Wicket 1.4.x
>> nowadays!) and this change might break many applications in production.
>> The parser will report errors at runtime so the developers will have to go
>> thru all the functionality of their apps to make sure it still works.
>> So the benefit is questionable! At least to me.
>>
>> WICKET-4088 is created 5 years ago and since then no one ever reported any
>> problem related to this functionality (the map syntax).
>> The only related ticket I'm aware of is
>> https://issues.apache.org/jira/browse/WICKET-5623.
>> Sven made this pluggable so if the application has custom needs then it is
>> possible to setup custom resolver.
>> I'd prefer to see the new parser as a pluggable replacement too! So if it
>> breaks someone's application then just switch back to the old impl.
>>
>> So I'm -0 on this improvement but let's see what others think too!
>> I'd like to see 8.0.0 released sooner rather than later.
>>
>>
>>> I understand and share your concern about maintenance. It's my
>>> understand that the entire team signs a release, and that we all can
>>> support and maintain the features inside it. I will understand if
>>> anyone stops this improvement based on cost/benefit analysis or on the
>>> merit that it's hard to maintain a parser. I do not share such
>>> concerns and pointed out the benefits of such improvement at [2] (we
>>> can continue on the linked thread).
>>>
>>> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
>>> 2 - http://markmail.org/message/yc2pwmbmasx5rzim
>>>
>>> On Tue, Jan 31, 2017 at 10:13 AM, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>>>
>>>> Hi Pedro,
>>>>
>>>> On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@gmail.com>
>>>
>>> wrote:
>>>>>
>>>>> Hi Martin,
>>>>>
>>>>> Wicket-4201 IPageProvider improvement: will work on the ticket during
>>>
>>> the
>>>>>
>>>>> week
>>>>>
>>>>> Expression language change [1]: it's a big change and I think it needs
>>>>> the team approval
>>>>>
>>>> Here is the diff:
>>>> https://github.com/apache/wicket/compare/WICKET-4008-
>>>
>>> property-expression-parser
>>>>
>>>>
>>>>> Wicket-4008 expression language parser: the parser is functional and
>>>>> there isn't much work pending on it. I can finish and merge the work
>>>>> during the week.
>>>>>
>>>>> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
>>>>
>>>>
>>>> The linked discussion makes me feel a bit uncertain.
>>>> I want to avoid another "component queueing" case here, i.e. a rather
>>>> bigger refactoring for something that only few people asked for and then
>>>> leave the maintenance to someone else. The fact that you didn't have
>>>> time
>>>> to work on these changes in the last few months makes me think you may
>>>
>>> not
>>>>
>>>> have time to answer questions and fix bugs once it is released. No one
>>>
>>> can
>>>>
>>>> guarantee that (s)he will be around to help with his/her expertize, me
>>>> included, but if you know from now that you won't have time then maybe
>>>> it
>>>> would be better to not make these changes.
>>>>
>>>> I agree that the team should decide so anyone is welcome to express his
>>>> opinion!
>>>>
>>>>
>>>>> Pedro Santos
>>>>>
>>>>>
>>>>> On Thu, Jan 12, 2017 at 9:08 PM, Martin Grigorov <mg...@apache.org>
>>>>> wrote:
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> @Sven: have you started migrating your app ?
>>>>>>
>>>>>> @Pedro: any idea when you will have time to finish your improvements?
>>>
>>> Do
>>>>>>
>>>>>> you need any help ?
>>>>>>
>>>>>>
>>>>>>
>>>>>> Martin Grigorov
>>>>>> Wicket Training and Consulting
>>>>>> https://twitter.com/mtgrigorov
>>>>>>
>>>>>> On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <
>>>
>>> mgrigorov@apache.org>
>>>>>>
>>>>>> wrote:
>>>>>>
>>>>>>> Probably we should stick to the principle: If it works, don't touch
>>>
>>> it!
>>>>>>>
>>>>>>> This is related to CGLib and ClassMetaCache
>>>>>>>
>>>>>>> Martin Grigorov
>>>>>>> Wicket Training and Consulting
>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>
>>>>>>> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com>
>>>>>
>>>>> wrote:
>>>>>>>>
>>>>>>>> We can replace ClassMetaCache used in wicket-ioc's Injector by a
>>>>>
>>>>> Jandex[1]
>>>>>>>>
>>>>>>>> class index.
>>>>>>>>
>>>>>>>> 1 - https://github.com/wildfly/jandex
>>>>>>>>
>>>>>>>> Pedro Santos
>>>>>>>>
>>>>>>>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <
>>>
>>> mgrigorov@apache.org
>>>>>>>>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> The main advantages of ByteBuddy are:
>>>>>>>>> - actively developed
>>>>>>>>> - Mockito 2 moved to it
>>>>>>>>> - Hibernate 5.x is moving to it (
>>>>>>>>> https://twitter.com/vlad_mihalcea/status/798971296910483456)
>>>>>>>>> - Spring considers it (they actually already use it for the tests:
>>>>>>>>> https://twitter.com/ankinson/status/799363435775586308)
>>>>>>>>> - support for Java 9 (we will need it at some point)
>>>>>>>>> - support for Android (I guess no one will ever run Wicket inside
>>>>>>>>
>>>>>>>> Android,
>>>>>>>>>
>>>>>>>>> but who knows)
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Martin Grigorov
>>>>>>>>> Wicket Training and Consulting
>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>
>>>>>>>>> On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net>
>>>
>>> wrote:
>>>>>>>>>>
>>>>>>>>>> Replace CGLIB with ByteBuddy because it has better support for
>>>>>
>>>>> Java 8
>>>>>>>>>
>>>>>>>>> and 9
>>>>>>>>>>
>>>>>>>>>> What are the advantages? Seems Spring hasn't decided on this
>>>
>>> yet:
>>>>>>>>>>
>>>>>>>>>> https://jira.spring.io/browse/SPR-8190
>>>>>>>>>>
>>>>>>>>>> Regards
>>>>>>>>>> Sven
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> On 20.11.2016 00:47, Martin Grigorov wrote:
>>>>>>>>>>
>>>>>>>>>>> Replace CGLIB with ByteBuddy because it has better support for
>>>>>
>>>>> Java 8
>>>>>>>>>
>>>>>>>>> and
>>>>>>>>>>>
>>>>>>>>>>> 9
>>>>>>>>>>> ?
>>>>>>>>>>> CGLIB could stay as fallback (via system property) until 9.0.0.
>>>>>>>>>>>
>>>>>>>>>>> Martin Grigorov
>>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>>
>>>>>>>>>>> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>>>>>>>>
>>>>>>>> an.delbene@gmail.com
>>>>>>>>>>>
>>>>>>>>>>> wrote:
>>>>>>>>>>>
>>>>>>>>>>> yah, I think it's better
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 14/11/2016 19:54, Martin Grigorov wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> +1
>>>>>>>>>>>>>
>>>>>>>>>>>>> Maybe rename #forResource() to #of() ?
>>>>>>>>>>>>>
>>>>>>>>>>>>> Martin Grigorov
>>>>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>>>>
>>>>>>>>>>>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>>>>>>>>>
>>>>>>>>> an.delbene@gmail.com>
>>>>>>>>>>>>>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> I'm wondering if there is room for an improvement for
>>>>>>>>>
>>>>>>>>> ResourceReference,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> introducing lambda support also for this component. Actually
>>>>>
>>>>> it's
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> something
>>>>>>>>>>>>>> that can be done after the release of 8.0.0, but I'd like to
>>>>>>>>
>>>>>>>> collect
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> your
>>>>>>>>>>>>>> feedback anyway. The idea is to provide factory methods to
>>>>>
>>>>> build a
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> ResourceReference using lambdas and avoiding anonymous
>>>
>>> classes
>>>>>
>>>>> to
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> implement
>>>>>>>>>>>>>> getResource().
>>>>>>>>>>>>>> The following snippet should better explain what I mean:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> https://gist.github.com/bitstorm/
>>>>>
>>>>> 03cfe9905a3f86a7160ab49f0ce23f13
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Andrea.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What other improvements do we need in 8.x/master before
>>>>>>>>
>>>>>>>> promoting it
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> to
>>>>>>>>>>>>>>> 8.0.0 final ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> At https://cwiki.apache.org/confluence/display/WICKET/
>>>
>>> Ideas+
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> for+Wicket+8.0
>>>>>>>>>>>>>>> we still have:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>>>>>>>>>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* -
>>>
>>> I'll
>>>>>
>>>>> give
>>>>>>>>>
>>>>>>>>> this
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> one
>>>>>>>>>>>>>>> more try but the problem is that I don't believe this is
>>>
>>> the
>>>>>>>>
>>>>>>>> proper
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> way
>>>>>>>>>>>>>>> and
>>>>>>>>>>>>>>> this demotivates me.
>>>>>>>>>>>>>>> If someone else wants to give it a try - please assign it
>>>
>>> to
>>>>>>>>>
>>>>>>>>> yourself!
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> - Better SEO for stateful pages - the only way I see this
>>>
>>> is
>>>>>
>>>>> by
>>>>>>>>>
>>>>>>>>> using
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> ServiceWorker to add the pageId as a request header to all
>>>>>>>>
>>>>>>>> requests
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> (normal
>>>>>>>>>>>>>>> & Ajax)
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Recently I wondered whether Redux.js could be in use for
>>>>>
>>>>> Wicket.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> I don't have much experience with it, but both React and
>>>>>>>>
>>>>>>>> AngularJs
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> communities use it to manage the state for their
>>>
>>> components.
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> There are some Java impls, even a standard is coming:
>>>>>>>>>>>>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> What else ?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Martin Grigorov
>>>>>>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>
>>>>>>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Sven Meier <sv...@meiers.net>.
Hi Pedro,
PropertyResolver is very lenient currently, defining the dot (.) as a
separator of properties only - there's not much more about it.
With a custom IPropertyLocator (WICKET-5623) the following is supported too:
PropertyResolver.getValue("foo.bar.path/to/node", document);
PropertyResolver.getValue("foo.bar.attribute(name)", document);
Both are no longer valid with your proposal, because they are no valid
Java syntax or "unified EL".
IMHO this goes in the wrong direction, it takes possibilities away
instead of enabling users to customize property resolving.
I don't understand (yet) what advantage justifies this restriction. For
me a pluggable architecture is more valuable than a strict syntax.
Regards
Sven
On 31.01.2017 16:58, Martin Grigorov wrote:
> Hi Pedro,
>
> On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@gmail.com> wrote:
>
>> Hi Martin,
>>
>> you missed the point of the proposal at [1], it's a syntax change that
>> would move Wicket's expression language closer to Unified Expression
>> Language. This change would better welcome developers used to work
>> with expressions like: bean.map["key"] and move Wicket closer to JSR
>> 341 (we can continue on the linked thread).
>>
> Yes, it seems I didn't understand it right. I thought both are related -
> the parser is being introduced to be able to deal with the new syntax.
>
>
>> The branch you pointed is the implementation of a parser to replace
>> your current tokenizer inside PropertyResolver.
>>
> It is not mine. It was already there when I started using Wicket.
>
>
>> The comparison to the component queueing is vague. It was a new
>> feature in Wicket 7 rather and a improvement aiming to give users
>> earlier syntax errors plus to improve PropertyResolver's
>> maintainability by replacing organic grown code with a structured
>> syntax tree.
>>
> The comparison with the component queueing is because again we are going to
> introduce a change that no one ever asked for (well technically, Martin
> Makundi asked for Component Queueing but he still uses Wicket 1.4.x
> nowadays!) and this change might break many applications in production.
> The parser will report errors at runtime so the developers will have to go
> thru all the functionality of their apps to make sure it still works.
> So the benefit is questionable! At least to me.
>
> WICKET-4088 is created 5 years ago and since then no one ever reported any
> problem related to this functionality (the map syntax).
> The only related ticket I'm aware of is
> https://issues.apache.org/jira/browse/WICKET-5623.
> Sven made this pluggable so if the application has custom needs then it is
> possible to setup custom resolver.
> I'd prefer to see the new parser as a pluggable replacement too! So if it
> breaks someone's application then just switch back to the old impl.
>
> So I'm -0 on this improvement but let's see what others think too!
> I'd like to see 8.0.0 released sooner rather than later.
>
>
>> I understand and share your concern about maintenance. It's my
>> understand that the entire team signs a release, and that we all can
>> support and maintain the features inside it. I will understand if
>> anyone stops this improvement based on cost/benefit analysis or on the
>> merit that it's hard to maintain a parser. I do not share such
>> concerns and pointed out the benefits of such improvement at [2] (we
>> can continue on the linked thread).
>>
>> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
>> 2 - http://markmail.org/message/yc2pwmbmasx5rzim
>>
>> On Tue, Jan 31, 2017 at 10:13 AM, Martin Grigorov <mg...@apache.org>
>> wrote:
>>> Hi Pedro,
>>>
>>> On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@gmail.com>
>> wrote:
>>>> Hi Martin,
>>>>
>>>> Wicket-4201 IPageProvider improvement: will work on the ticket during
>> the
>>>> week
>>>>
>>>> Expression language change [1]: it's a big change and I think it needs
>>>> the team approval
>>>>
>>> Here is the diff:
>>> https://github.com/apache/wicket/compare/WICKET-4008-
>> property-expression-parser
>>>
>>>> Wicket-4008 expression language parser: the parser is functional and
>>>> there isn't much work pending on it. I can finish and merge the work
>>>> during the week.
>>>>
>>>> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
>>>
>>> The linked discussion makes me feel a bit uncertain.
>>> I want to avoid another "component queueing" case here, i.e. a rather
>>> bigger refactoring for something that only few people asked for and then
>>> leave the maintenance to someone else. The fact that you didn't have time
>>> to work on these changes in the last few months makes me think you may
>> not
>>> have time to answer questions and fix bugs once it is released. No one
>> can
>>> guarantee that (s)he will be around to help with his/her expertize, me
>>> included, but if you know from now that you won't have time then maybe it
>>> would be better to not make these changes.
>>>
>>> I agree that the team should decide so anyone is welcome to express his
>>> opinion!
>>>
>>>
>>>> Pedro Santos
>>>>
>>>>
>>>> On Thu, Jan 12, 2017 at 9:08 PM, Martin Grigorov <mg...@apache.org>
>>>> wrote:
>>>>> Hi,
>>>>>
>>>>> @Sven: have you started migrating your app ?
>>>>>
>>>>> @Pedro: any idea when you will have time to finish your improvements?
>> Do
>>>>> you need any help ?
>>>>>
>>>>>
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>> https://twitter.com/mtgrigorov
>>>>>
>>>>> On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <
>> mgrigorov@apache.org>
>>>>> wrote:
>>>>>
>>>>>> Probably we should stick to the principle: If it works, don't touch
>> it!
>>>>>> This is related to CGLib and ClassMetaCache
>>>>>>
>>>>>> Martin Grigorov
>>>>>> Wicket Training and Consulting
>>>>>> https://twitter.com/mtgrigorov
>>>>>>
>>>>>> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com>
>>>> wrote:
>>>>>>> We can replace ClassMetaCache used in wicket-ioc's Injector by a
>>>> Jandex[1]
>>>>>>> class index.
>>>>>>>
>>>>>>> 1 - https://github.com/wildfly/jandex
>>>>>>>
>>>>>>> Pedro Santos
>>>>>>>
>>>>>>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <
>> mgrigorov@apache.org
>>>>>>> wrote:
>>>>>>>
>>>>>>>> The main advantages of ByteBuddy are:
>>>>>>>> - actively developed
>>>>>>>> - Mockito 2 moved to it
>>>>>>>> - Hibernate 5.x is moving to it (
>>>>>>>> https://twitter.com/vlad_mihalcea/status/798971296910483456)
>>>>>>>> - Spring considers it (they actually already use it for the tests:
>>>>>>>> https://twitter.com/ankinson/status/799363435775586308)
>>>>>>>> - support for Java 9 (we will need it at some point)
>>>>>>>> - support for Android (I guess no one will ever run Wicket inside
>>>>>>> Android,
>>>>>>>> but who knows)
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> Martin Grigorov
>>>>>>>> Wicket Training and Consulting
>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>
>>>>>>>> On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net>
>> wrote:
>>>>>>>>> Replace CGLIB with ByteBuddy because it has better support for
>>>> Java 8
>>>>>>>> and 9
>>>>>>>>> What are the advantages? Seems Spring hasn't decided on this
>> yet:
>>>>>>>>> https://jira.spring.io/browse/SPR-8190
>>>>>>>>>
>>>>>>>>> Regards
>>>>>>>>> Sven
>>>>>>>>>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> On 20.11.2016 00:47, Martin Grigorov wrote:
>>>>>>>>>
>>>>>>>>>> Replace CGLIB with ByteBuddy because it has better support for
>>>> Java 8
>>>>>>>> and
>>>>>>>>>> 9
>>>>>>>>>> ?
>>>>>>>>>> CGLIB could stay as fallback (via system property) until 9.0.0.
>>>>>>>>>>
>>>>>>>>>> Martin Grigorov
>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>
>>>>>>>>>> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>>>>>>> an.delbene@gmail.com
>>>>>>>>>> wrote:
>>>>>>>>>>
>>>>>>>>>> yah, I think it's better
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> On 14/11/2016 19:54, Martin Grigorov wrote:
>>>>>>>>>>>
>>>>>>>>>>> +1
>>>>>>>>>>>> Maybe rename #forResource() to #of() ?
>>>>>>>>>>>>
>>>>>>>>>>>> Martin Grigorov
>>>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>>>
>>>>>>>>>>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>>>>>>>> an.delbene@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>>
>>>>>>>>>>>> I'm wondering if there is room for an improvement for
>>>>>>>> ResourceReference,
>>>>>>>>>>>>> introducing lambda support also for this component. Actually
>>>> it's
>>>>>>>>>>>>> something
>>>>>>>>>>>>> that can be done after the release of 8.0.0, but I'd like to
>>>>>>> collect
>>>>>>>>>>>>> your
>>>>>>>>>>>>> feedback anyway. The idea is to provide factory methods to
>>>> build a
>>>>>>>>>>>>> ResourceReference using lambdas and avoiding anonymous
>> classes
>>>> to
>>>>>>>>>>>>> implement
>>>>>>>>>>>>> getResource().
>>>>>>>>>>>>> The following snippet should better explain what I mean:
>>>>>>>>>>>>>
>>>>>>>>>>>>> https://gist.github.com/bitstorm/
>>>> 03cfe9905a3f86a7160ab49f0ce23f13
>>>>>>>>>>>>> Andrea.
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>
>>>>>>>>>>>>>> What other improvements do we need in 8.x/master before
>>>>>>> promoting it
>>>>>>>>>>>>>> to
>>>>>>>>>>>>>> 8.0.0 final ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> At https://cwiki.apache.org/confluence/display/WICKET/
>> Ideas+
>>>>>>>>>>>>>> for+Wicket+8.0
>>>>>>>>>>>>>> we still have:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>>>>>>>>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* -
>> I'll
>>>> give
>>>>>>>> this
>>>>>>>>>>>>>> one
>>>>>>>>>>>>>> more try but the problem is that I don't believe this is
>> the
>>>>>>> proper
>>>>>>>>>>>>>> way
>>>>>>>>>>>>>> and
>>>>>>>>>>>>>> this demotivates me.
>>>>>>>>>>>>>> If someone else wants to give it a try - please assign it
>> to
>>>>>>>> yourself!
>>>>>>>>>>>>>> - Better SEO for stateful pages - the only way I see this
>> is
>>>> by
>>>>>>>> using
>>>>>>>>>>>>>> ServiceWorker to add the pageId as a request header to all
>>>>>>> requests
>>>>>>>>>>>>>> (normal
>>>>>>>>>>>>>> & Ajax)
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Recently I wondered whether Redux.js could be in use for
>>>> Wicket.
>>>>>>>>>>>>>> I don't have much experience with it, but both React and
>>>>>>> AngularJs
>>>>>>>>>>>>>> communities use it to manage the state for their
>> components.
>>>>>>>>>>>>>> There are some Java impls, even a standard is coming:
>>>>>>>>>>>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> What else ?
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Martin Grigorov
>>>>>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>
>>>>>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Hi Pedro,
On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pe...@gmail.com> wrote:
> Hi Martin,
>
> you missed the point of the proposal at [1], it's a syntax change that
> would move Wicket's expression language closer to Unified Expression
> Language. This change would better welcome developers used to work
> with expressions like: bean.map["key"] and move Wicket closer to JSR
> 341 (we can continue on the linked thread).
>
Yes, it seems I didn't understand it right. I thought both are related -
the parser is being introduced to be able to deal with the new syntax.
>
> The branch you pointed is the implementation of a parser to replace
> your current tokenizer inside PropertyResolver.
>
It is not mine. It was already there when I started using Wicket.
>
> The comparison to the component queueing is vague. It was a new
> feature in Wicket 7 rather and a improvement aiming to give users
> earlier syntax errors plus to improve PropertyResolver's
> maintainability by replacing organic grown code with a structured
> syntax tree.
>
The comparison with the component queueing is because again we are going to
introduce a change that no one ever asked for (well technically, Martin
Makundi asked for Component Queueing but he still uses Wicket 1.4.x
nowadays!) and this change might break many applications in production.
The parser will report errors at runtime so the developers will have to go
thru all the functionality of their apps to make sure it still works.
So the benefit is questionable! At least to me.
WICKET-4088 is created 5 years ago and since then no one ever reported any
problem related to this functionality (the map syntax).
The only related ticket I'm aware of is
https://issues.apache.org/jira/browse/WICKET-5623.
Sven made this pluggable so if the application has custom needs then it is
possible to setup custom resolver.
I'd prefer to see the new parser as a pluggable replacement too! So if it
breaks someone's application then just switch back to the old impl.
So I'm -0 on this improvement but let's see what others think too!
I'd like to see 8.0.0 released sooner rather than later.
>
> I understand and share your concern about maintenance. It's my
> understand that the entire team signs a release, and that we all can
> support and maintain the features inside it. I will understand if
> anyone stops this improvement based on cost/benefit analysis or on the
> merit that it's hard to maintain a parser. I do not share such
> concerns and pointed out the benefits of such improvement at [2] (we
> can continue on the linked thread).
>
> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
> 2 - http://markmail.org/message/yc2pwmbmasx5rzim
>
> On Tue, Jan 31, 2017 at 10:13 AM, Martin Grigorov <mg...@apache.org>
> wrote:
> > Hi Pedro,
> >
> > On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@gmail.com>
> wrote:
> >
> >> Hi Martin,
> >>
> >> Wicket-4201 IPageProvider improvement: will work on the ticket during
> the
> >> week
> >>
> >> Expression language change [1]: it's a big change and I think it needs
> >> the team approval
> >>
> >
> > Here is the diff:
> > https://github.com/apache/wicket/compare/WICKET-4008-
> property-expression-parser
> >
> >
> >>
> >> Wicket-4008 expression language parser: the parser is functional and
> >> there isn't much work pending on it. I can finish and merge the work
> >> during the week.
> >>
> >> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
> >
> >
> > The linked discussion makes me feel a bit uncertain.
> > I want to avoid another "component queueing" case here, i.e. a rather
> > bigger refactoring for something that only few people asked for and then
> > leave the maintenance to someone else. The fact that you didn't have time
> > to work on these changes in the last few months makes me think you may
> not
> > have time to answer questions and fix bugs once it is released. No one
> can
> > guarantee that (s)he will be around to help with his/her expertize, me
> > included, but if you know from now that you won't have time then maybe it
> > would be better to not make these changes.
> >
> > I agree that the team should decide so anyone is welcome to express his
> > opinion!
> >
> >
> >>
> >> Pedro Santos
> >>
> >>
> >> On Thu, Jan 12, 2017 at 9:08 PM, Martin Grigorov <mg...@apache.org>
> >> wrote:
> >> > Hi,
> >> >
> >> > @Sven: have you started migrating your app ?
> >> >
> >> > @Pedro: any idea when you will have time to finish your improvements?
> Do
> >> > you need any help ?
> >> >
> >> >
> >> >
> >> > Martin Grigorov
> >> > Wicket Training and Consulting
> >> > https://twitter.com/mtgrigorov
> >> >
> >> > On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <
> mgrigorov@apache.org>
> >> > wrote:
> >> >
> >> >> Probably we should stick to the principle: If it works, don't touch
> it!
> >> >> This is related to CGLib and ClassMetaCache
> >> >>
> >> >> Martin Grigorov
> >> >> Wicket Training and Consulting
> >> >> https://twitter.com/mtgrigorov
> >> >>
> >> >> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com>
> >> wrote:
> >> >>
> >> >>> We can replace ClassMetaCache used in wicket-ioc's Injector by a
> >> Jandex[1]
> >> >>> class index.
> >> >>>
> >> >>> 1 - https://github.com/wildfly/jandex
> >> >>>
> >> >>> Pedro Santos
> >> >>>
> >> >>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <
> mgrigorov@apache.org
> >> >
> >> >>> wrote:
> >> >>>
> >> >>> > The main advantages of ByteBuddy are:
> >> >>> > - actively developed
> >> >>> > - Mockito 2 moved to it
> >> >>> > - Hibernate 5.x is moving to it (
> >> >>> > https://twitter.com/vlad_mihalcea/status/798971296910483456)
> >> >>> > - Spring considers it (they actually already use it for the tests:
> >> >>> > https://twitter.com/ankinson/status/799363435775586308)
> >> >>> > - support for Java 9 (we will need it at some point)
> >> >>> > - support for Android (I guess no one will ever run Wicket inside
> >> >>> Android,
> >> >>> > but who knows)
> >> >>> >
> >> >>> >
> >> >>> >
> >> >>> > Martin Grigorov
> >> >>> > Wicket Training and Consulting
> >> >>> > https://twitter.com/mtgrigorov
> >> >>> >
> >> >>> > On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net>
> wrote:
> >> >>> >
> >> >>> > > Replace CGLIB with ByteBuddy because it has better support for
> >> Java 8
> >> >>> > and 9
> >> >>> > >>
> >> >>> > >
> >> >>> > > What are the advantages? Seems Spring hasn't decided on this
> yet:
> >> >>> > >
> >> >>> > > https://jira.spring.io/browse/SPR-8190
> >> >>> > >
> >> >>> > > Regards
> >> >>> > > Sven
> >> >>> > >
> >> >>> > >
> >> >>> > >
> >> >>> > > On 20.11.2016 00:47, Martin Grigorov wrote:
> >> >>> > >
> >> >>> > >> Replace CGLIB with ByteBuddy because it has better support for
> >> Java 8
> >> >>> > and
> >> >>> > >> 9
> >> >>> > >> ?
> >> >>> > >> CGLIB could stay as fallback (via system property) until 9.0.0.
> >> >>> > >>
> >> >>> > >> Martin Grigorov
> >> >>> > >> Wicket Training and Consulting
> >> >>> > >> https://twitter.com/mtgrigorov
> >> >>> > >>
> >> >>> > >> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
> >> >>> an.delbene@gmail.com
> >> >>> > >
> >> >>> > >> wrote:
> >> >>> > >>
> >> >>> > >> yah, I think it's better
> >> >>> > >>>
> >> >>> > >>>
> >> >>> > >>>
> >> >>> > >>> On 14/11/2016 19:54, Martin Grigorov wrote:
> >> >>> > >>>
> >> >>> > >>> +1
> >> >>> > >>>>
> >> >>> > >>>> Maybe rename #forResource() to #of() ?
> >> >>> > >>>>
> >> >>> > >>>> Martin Grigorov
> >> >>> > >>>> Wicket Training and Consulting
> >> >>> > >>>> https://twitter.com/mtgrigorov
> >> >>> > >>>>
> >> >>> > >>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
> >> >>> > an.delbene@gmail.com>
> >> >>> > >>>> wrote:
> >> >>> > >>>>
> >> >>> > >>>> I'm wondering if there is room for an improvement for
> >> >>> > ResourceReference,
> >> >>> > >>>>
> >> >>> > >>>>> introducing lambda support also for this component. Actually
> >> it's
> >> >>> > >>>>> something
> >> >>> > >>>>> that can be done after the release of 8.0.0, but I'd like to
> >> >>> collect
> >> >>> > >>>>> your
> >> >>> > >>>>> feedback anyway. The idea is to provide factory methods to
> >> build a
> >> >>> > >>>>> ResourceReference using lambdas and avoiding anonymous
> classes
> >> to
> >> >>> > >>>>> implement
> >> >>> > >>>>> getResource().
> >> >>> > >>>>> The following snippet should better explain what I mean:
> >> >>> > >>>>>
> >> >>> > >>>>> https://gist.github.com/bitstorm/
> >> 03cfe9905a3f86a7160ab49f0ce23f13
> >> >>> > >>>>>
> >> >>> > >>>>> Andrea.
> >> >>> > >>>>>
> >> >>> > >>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
> >> >>> > >>>>>
> >> >>> > >>>>> Hi,
> >> >>> > >>>>>
> >> >>> > >>>>>> What other improvements do we need in 8.x/master before
> >> >>> promoting it
> >> >>> > >>>>>> to
> >> >>> > >>>>>> 8.0.0 final ?
> >> >>> > >>>>>>
> >> >>> > >>>>>> At https://cwiki.apache.org/confluence/display/WICKET/
> Ideas+
> >> >>> > >>>>>> for+Wicket+8.0
> >> >>> > >>>>>> we still have:
> >> >>> > >>>>>>
> >> >>> > >>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
> >> >>> > >>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* -
> I'll
> >> give
> >> >>> > this
> >> >>> > >>>>>> one
> >> >>> > >>>>>> more try but the problem is that I don't believe this is
> the
> >> >>> proper
> >> >>> > >>>>>> way
> >> >>> > >>>>>> and
> >> >>> > >>>>>> this demotivates me.
> >> >>> > >>>>>> If someone else wants to give it a try - please assign it
> to
> >> >>> > yourself!
> >> >>> > >>>>>>
> >> >>> > >>>>>> - Better SEO for stateful pages - the only way I see this
> is
> >> by
> >> >>> > using
> >> >>> > >>>>>> ServiceWorker to add the pageId as a request header to all
> >> >>> requests
> >> >>> > >>>>>> (normal
> >> >>> > >>>>>> & Ajax)
> >> >>> > >>>>>>
> >> >>> > >>>>>>
> >> >>> > >>>>>> Recently I wondered whether Redux.js could be in use for
> >> Wicket.
> >> >>> > >>>>>> I don't have much experience with it, but both React and
> >> >>> AngularJs
> >> >>> > >>>>>> communities use it to manage the state for their
> components.
> >> >>> > >>>>>> There are some Java impls, even a standard is coming:
> >> >>> > >>>>>> https://github.com/jvm-redux/jvm-redux-api
> >> >>> > >>>>>>
> >> >>> > >>>>>> What else ?
> >> >>> > >>>>>>
> >> >>> > >>>>>> Martin Grigorov
> >> >>> > >>>>>> Wicket Training and Consulting
> >> >>> > >>>>>> https://twitter.com/mtgrigorov
> >> >>> > >>>>>>
> >> >>> > >>>>>>
> >> >>> > >>>>>>
> >> >>> > >>>>>>
> >> >>> > >
> >> >>> >
> >> >>>
> >> >>
> >> >>
> >>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Pedro Santos <pe...@gmail.com>.
Hi Martin,
you missed the point of the proposal at [1], it's a syntax change that
would move Wicket's expression language closer to Unified Expression
Language. This change would better welcome developers used to work
with expressions like: bean.map["key"] and move Wicket closer to JSR
341 (we can continue on the linked thread).
The branch you pointed is the implementation of a parser to replace
your current tokenizer inside PropertyResolver.
The comparison to the component queueing is vague. It was a new
feature in Wicket 7 rather and a improvement aiming to give users
earlier syntax errors plus to improve PropertyResolver's
maintainability by replacing organic grown code with a structured
syntax tree.
I understand and share your concern about maintenance. It's my
understand that the entire team signs a release, and that we all can
support and maintain the features inside it. I will understand if
anyone stops this improvement based on cost/benefit analysis or on the
merit that it's hard to maintain a parser. I do not share such
concerns and pointed out the benefits of such improvement at [2] (we
can continue on the linked thread).
1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
2 - http://markmail.org/message/yc2pwmbmasx5rzim
On Tue, Jan 31, 2017 at 10:13 AM, Martin Grigorov <mg...@apache.org> wrote:
> Hi Pedro,
>
> On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@gmail.com> wrote:
>
>> Hi Martin,
>>
>> Wicket-4201 IPageProvider improvement: will work on the ticket during the
>> week
>>
>> Expression language change [1]: it's a big change and I think it needs
>> the team approval
>>
>
> Here is the diff:
> https://github.com/apache/wicket/compare/WICKET-4008-property-expression-parser
>
>
>>
>> Wicket-4008 expression language parser: the parser is functional and
>> there isn't much work pending on it. I can finish and merge the work
>> during the week.
>>
>> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
>
>
> The linked discussion makes me feel a bit uncertain.
> I want to avoid another "component queueing" case here, i.e. a rather
> bigger refactoring for something that only few people asked for and then
> leave the maintenance to someone else. The fact that you didn't have time
> to work on these changes in the last few months makes me think you may not
> have time to answer questions and fix bugs once it is released. No one can
> guarantee that (s)he will be around to help with his/her expertize, me
> included, but if you know from now that you won't have time then maybe it
> would be better to not make these changes.
>
> I agree that the team should decide so anyone is welcome to express his
> opinion!
>
>
>>
>> Pedro Santos
>>
>>
>> On Thu, Jan 12, 2017 at 9:08 PM, Martin Grigorov <mg...@apache.org>
>> wrote:
>> > Hi,
>> >
>> > @Sven: have you started migrating your app ?
>> >
>> > @Pedro: any idea when you will have time to finish your improvements? Do
>> > you need any help ?
>> >
>> >
>> >
>> > Martin Grigorov
>> > Wicket Training and Consulting
>> > https://twitter.com/mtgrigorov
>> >
>> > On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <mg...@apache.org>
>> > wrote:
>> >
>> >> Probably we should stick to the principle: If it works, don't touch it!
>> >> This is related to CGLib and ClassMetaCache
>> >>
>> >> Martin Grigorov
>> >> Wicket Training and Consulting
>> >> https://twitter.com/mtgrigorov
>> >>
>> >> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com>
>> wrote:
>> >>
>> >>> We can replace ClassMetaCache used in wicket-ioc's Injector by a
>> Jandex[1]
>> >>> class index.
>> >>>
>> >>> 1 - https://github.com/wildfly/jandex
>> >>>
>> >>> Pedro Santos
>> >>>
>> >>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <mgrigorov@apache.org
>> >
>> >>> wrote:
>> >>>
>> >>> > The main advantages of ByteBuddy are:
>> >>> > - actively developed
>> >>> > - Mockito 2 moved to it
>> >>> > - Hibernate 5.x is moving to it (
>> >>> > https://twitter.com/vlad_mihalcea/status/798971296910483456)
>> >>> > - Spring considers it (they actually already use it for the tests:
>> >>> > https://twitter.com/ankinson/status/799363435775586308)
>> >>> > - support for Java 9 (we will need it at some point)
>> >>> > - support for Android (I guess no one will ever run Wicket inside
>> >>> Android,
>> >>> > but who knows)
>> >>> >
>> >>> >
>> >>> >
>> >>> > Martin Grigorov
>> >>> > Wicket Training and Consulting
>> >>> > https://twitter.com/mtgrigorov
>> >>> >
>> >>> > On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net> wrote:
>> >>> >
>> >>> > > Replace CGLIB with ByteBuddy because it has better support for
>> Java 8
>> >>> > and 9
>> >>> > >>
>> >>> > >
>> >>> > > What are the advantages? Seems Spring hasn't decided on this yet:
>> >>> > >
>> >>> > > https://jira.spring.io/browse/SPR-8190
>> >>> > >
>> >>> > > Regards
>> >>> > > Sven
>> >>> > >
>> >>> > >
>> >>> > >
>> >>> > > On 20.11.2016 00:47, Martin Grigorov wrote:
>> >>> > >
>> >>> > >> Replace CGLIB with ByteBuddy because it has better support for
>> Java 8
>> >>> > and
>> >>> > >> 9
>> >>> > >> ?
>> >>> > >> CGLIB could stay as fallback (via system property) until 9.0.0.
>> >>> > >>
>> >>> > >> Martin Grigorov
>> >>> > >> Wicket Training and Consulting
>> >>> > >> https://twitter.com/mtgrigorov
>> >>> > >>
>> >>> > >> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>> >>> an.delbene@gmail.com
>> >>> > >
>> >>> > >> wrote:
>> >>> > >>
>> >>> > >> yah, I think it's better
>> >>> > >>>
>> >>> > >>>
>> >>> > >>>
>> >>> > >>> On 14/11/2016 19:54, Martin Grigorov wrote:
>> >>> > >>>
>> >>> > >>> +1
>> >>> > >>>>
>> >>> > >>>> Maybe rename #forResource() to #of() ?
>> >>> > >>>>
>> >>> > >>>> Martin Grigorov
>> >>> > >>>> Wicket Training and Consulting
>> >>> > >>>> https://twitter.com/mtgrigorov
>> >>> > >>>>
>> >>> > >>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>> >>> > an.delbene@gmail.com>
>> >>> > >>>> wrote:
>> >>> > >>>>
>> >>> > >>>> I'm wondering if there is room for an improvement for
>> >>> > ResourceReference,
>> >>> > >>>>
>> >>> > >>>>> introducing lambda support also for this component. Actually
>> it's
>> >>> > >>>>> something
>> >>> > >>>>> that can be done after the release of 8.0.0, but I'd like to
>> >>> collect
>> >>> > >>>>> your
>> >>> > >>>>> feedback anyway. The idea is to provide factory methods to
>> build a
>> >>> > >>>>> ResourceReference using lambdas and avoiding anonymous classes
>> to
>> >>> > >>>>> implement
>> >>> > >>>>> getResource().
>> >>> > >>>>> The following snippet should better explain what I mean:
>> >>> > >>>>>
>> >>> > >>>>> https://gist.github.com/bitstorm/
>> 03cfe9905a3f86a7160ab49f0ce23f13
>> >>> > >>>>>
>> >>> > >>>>> Andrea.
>> >>> > >>>>>
>> >>> > >>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>> >>> > >>>>>
>> >>> > >>>>> Hi,
>> >>> > >>>>>
>> >>> > >>>>>> What other improvements do we need in 8.x/master before
>> >>> promoting it
>> >>> > >>>>>> to
>> >>> > >>>>>> 8.0.0 final ?
>> >>> > >>>>>>
>> >>> > >>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>> >>> > >>>>>> for+Wicket+8.0
>> >>> > >>>>>> we still have:
>> >>> > >>>>>>
>> >>> > >>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>> >>> > >>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll
>> give
>> >>> > this
>> >>> > >>>>>> one
>> >>> > >>>>>> more try but the problem is that I don't believe this is the
>> >>> proper
>> >>> > >>>>>> way
>> >>> > >>>>>> and
>> >>> > >>>>>> this demotivates me.
>> >>> > >>>>>> If someone else wants to give it a try - please assign it to
>> >>> > yourself!
>> >>> > >>>>>>
>> >>> > >>>>>> - Better SEO for stateful pages - the only way I see this is
>> by
>> >>> > using
>> >>> > >>>>>> ServiceWorker to add the pageId as a request header to all
>> >>> requests
>> >>> > >>>>>> (normal
>> >>> > >>>>>> & Ajax)
>> >>> > >>>>>>
>> >>> > >>>>>>
>> >>> > >>>>>> Recently I wondered whether Redux.js could be in use for
>> Wicket.
>> >>> > >>>>>> I don't have much experience with it, but both React and
>> >>> AngularJs
>> >>> > >>>>>> communities use it to manage the state for their components.
>> >>> > >>>>>> There are some Java impls, even a standard is coming:
>> >>> > >>>>>> https://github.com/jvm-redux/jvm-redux-api
>> >>> > >>>>>>
>> >>> > >>>>>> What else ?
>> >>> > >>>>>>
>> >>> > >>>>>> Martin Grigorov
>> >>> > >>>>>> Wicket Training and Consulting
>> >>> > >>>>>> https://twitter.com/mtgrigorov
>> >>> > >>>>>>
>> >>> > >>>>>>
>> >>> > >>>>>>
>> >>> > >>>>>>
>> >>> > >
>> >>> >
>> >>>
>> >>
>> >>
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Hi Pedro,
On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pe...@gmail.com> wrote:
> Hi Martin,
>
> Wicket-4201 IPageProvider improvement: will work on the ticket during the
> week
>
> Expression language change [1]: it's a big change and I think it needs
> the team approval
>
Here is the diff:
https://github.com/apache/wicket/compare/WICKET-4008-property-expression-parser
>
> Wicket-4008 expression language parser: the parser is functional and
> there isn't much work pending on it. I can finish and merge the work
> during the week.
>
> 1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
The linked discussion makes me feel a bit uncertain.
I want to avoid another "component queueing" case here, i.e. a rather
bigger refactoring for something that only few people asked for and then
leave the maintenance to someone else. The fact that you didn't have time
to work on these changes in the last few months makes me think you may not
have time to answer questions and fix bugs once it is released. No one can
guarantee that (s)he will be around to help with his/her expertize, me
included, but if you know from now that you won't have time then maybe it
would be better to not make these changes.
I agree that the team should decide so anyone is welcome to express his
opinion!
>
> Pedro Santos
>
>
> On Thu, Jan 12, 2017 at 9:08 PM, Martin Grigorov <mg...@apache.org>
> wrote:
> > Hi,
> >
> > @Sven: have you started migrating your app ?
> >
> > @Pedro: any idea when you will have time to finish your improvements? Do
> > you need any help ?
> >
> >
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <mg...@apache.org>
> > wrote:
> >
> >> Probably we should stick to the principle: If it works, don't touch it!
> >> This is related to CGLib and ClassMetaCache
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com>
> wrote:
> >>
> >>> We can replace ClassMetaCache used in wicket-ioc's Injector by a
> Jandex[1]
> >>> class index.
> >>>
> >>> 1 - https://github.com/wildfly/jandex
> >>>
> >>> Pedro Santos
> >>>
> >>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <mgrigorov@apache.org
> >
> >>> wrote:
> >>>
> >>> > The main advantages of ByteBuddy are:
> >>> > - actively developed
> >>> > - Mockito 2 moved to it
> >>> > - Hibernate 5.x is moving to it (
> >>> > https://twitter.com/vlad_mihalcea/status/798971296910483456)
> >>> > - Spring considers it (they actually already use it for the tests:
> >>> > https://twitter.com/ankinson/status/799363435775586308)
> >>> > - support for Java 9 (we will need it at some point)
> >>> > - support for Android (I guess no one will ever run Wicket inside
> >>> Android,
> >>> > but who knows)
> >>> >
> >>> >
> >>> >
> >>> > Martin Grigorov
> >>> > Wicket Training and Consulting
> >>> > https://twitter.com/mtgrigorov
> >>> >
> >>> > On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net> wrote:
> >>> >
> >>> > > Replace CGLIB with ByteBuddy because it has better support for
> Java 8
> >>> > and 9
> >>> > >>
> >>> > >
> >>> > > What are the advantages? Seems Spring hasn't decided on this yet:
> >>> > >
> >>> > > https://jira.spring.io/browse/SPR-8190
> >>> > >
> >>> > > Regards
> >>> > > Sven
> >>> > >
> >>> > >
> >>> > >
> >>> > > On 20.11.2016 00:47, Martin Grigorov wrote:
> >>> > >
> >>> > >> Replace CGLIB with ByteBuddy because it has better support for
> Java 8
> >>> > and
> >>> > >> 9
> >>> > >> ?
> >>> > >> CGLIB could stay as fallback (via system property) until 9.0.0.
> >>> > >>
> >>> > >> Martin Grigorov
> >>> > >> Wicket Training and Consulting
> >>> > >> https://twitter.com/mtgrigorov
> >>> > >>
> >>> > >> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
> >>> an.delbene@gmail.com
> >>> > >
> >>> > >> wrote:
> >>> > >>
> >>> > >> yah, I think it's better
> >>> > >>>
> >>> > >>>
> >>> > >>>
> >>> > >>> On 14/11/2016 19:54, Martin Grigorov wrote:
> >>> > >>>
> >>> > >>> +1
> >>> > >>>>
> >>> > >>>> Maybe rename #forResource() to #of() ?
> >>> > >>>>
> >>> > >>>> Martin Grigorov
> >>> > >>>> Wicket Training and Consulting
> >>> > >>>> https://twitter.com/mtgrigorov
> >>> > >>>>
> >>> > >>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
> >>> > an.delbene@gmail.com>
> >>> > >>>> wrote:
> >>> > >>>>
> >>> > >>>> I'm wondering if there is room for an improvement for
> >>> > ResourceReference,
> >>> > >>>>
> >>> > >>>>> introducing lambda support also for this component. Actually
> it's
> >>> > >>>>> something
> >>> > >>>>> that can be done after the release of 8.0.0, but I'd like to
> >>> collect
> >>> > >>>>> your
> >>> > >>>>> feedback anyway. The idea is to provide factory methods to
> build a
> >>> > >>>>> ResourceReference using lambdas and avoiding anonymous classes
> to
> >>> > >>>>> implement
> >>> > >>>>> getResource().
> >>> > >>>>> The following snippet should better explain what I mean:
> >>> > >>>>>
> >>> > >>>>> https://gist.github.com/bitstorm/
> 03cfe9905a3f86a7160ab49f0ce23f13
> >>> > >>>>>
> >>> > >>>>> Andrea.
> >>> > >>>>>
> >>> > >>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
> >>> > >>>>>
> >>> > >>>>> Hi,
> >>> > >>>>>
> >>> > >>>>>> What other improvements do we need in 8.x/master before
> >>> promoting it
> >>> > >>>>>> to
> >>> > >>>>>> 8.0.0 final ?
> >>> > >>>>>>
> >>> > >>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
> >>> > >>>>>> for+Wicket+8.0
> >>> > >>>>>> we still have:
> >>> > >>>>>>
> >>> > >>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
> >>> > >>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll
> give
> >>> > this
> >>> > >>>>>> one
> >>> > >>>>>> more try but the problem is that I don't believe this is the
> >>> proper
> >>> > >>>>>> way
> >>> > >>>>>> and
> >>> > >>>>>> this demotivates me.
> >>> > >>>>>> If someone else wants to give it a try - please assign it to
> >>> > yourself!
> >>> > >>>>>>
> >>> > >>>>>> - Better SEO for stateful pages - the only way I see this is
> by
> >>> > using
> >>> > >>>>>> ServiceWorker to add the pageId as a request header to all
> >>> requests
> >>> > >>>>>> (normal
> >>> > >>>>>> & Ajax)
> >>> > >>>>>>
> >>> > >>>>>>
> >>> > >>>>>> Recently I wondered whether Redux.js could be in use for
> Wicket.
> >>> > >>>>>> I don't have much experience with it, but both React and
> >>> AngularJs
> >>> > >>>>>> communities use it to manage the state for their components.
> >>> > >>>>>> There are some Java impls, even a standard is coming:
> >>> > >>>>>> https://github.com/jvm-redux/jvm-redux-api
> >>> > >>>>>>
> >>> > >>>>>> What else ?
> >>> > >>>>>>
> >>> > >>>>>> Martin Grigorov
> >>> > >>>>>> Wicket Training and Consulting
> >>> > >>>>>> https://twitter.com/mtgrigorov
> >>> > >>>>>>
> >>> > >>>>>>
> >>> > >>>>>>
> >>> > >>>>>>
> >>> > >
> >>> >
> >>>
> >>
> >>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Pedro Santos <pe...@gmail.com>.
Hi Martin,
Wicket-4201 IPageProvider improvement: will work on the ticket during the week
Expression language change [1]: it's a big change and I think it needs
the team approval
Wicket-4008 expression language parser: the parser is functional and
there isn't much work pending on it. I can finish and merge the work
during the week.
1 - http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
Pedro Santos
On Thu, Jan 12, 2017 at 9:08 PM, Martin Grigorov <mg...@apache.org> wrote:
> Hi,
>
> @Sven: have you started migrating your app ?
>
> @Pedro: any idea when you will have time to finish your improvements? Do
> you need any help ?
>
>
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <mg...@apache.org>
> wrote:
>
>> Probably we should stick to the principle: If it works, don't touch it!
>> This is related to CGLib and ClassMetaCache
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com> wrote:
>>
>>> We can replace ClassMetaCache used in wicket-ioc's Injector by a Jandex[1]
>>> class index.
>>>
>>> 1 - https://github.com/wildfly/jandex
>>>
>>> Pedro Santos
>>>
>>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>>
>>> > The main advantages of ByteBuddy are:
>>> > - actively developed
>>> > - Mockito 2 moved to it
>>> > - Hibernate 5.x is moving to it (
>>> > https://twitter.com/vlad_mihalcea/status/798971296910483456)
>>> > - Spring considers it (they actually already use it for the tests:
>>> > https://twitter.com/ankinson/status/799363435775586308)
>>> > - support for Java 9 (we will need it at some point)
>>> > - support for Android (I guess no one will ever run Wicket inside
>>> Android,
>>> > but who knows)
>>> >
>>> >
>>> >
>>> > Martin Grigorov
>>> > Wicket Training and Consulting
>>> > https://twitter.com/mtgrigorov
>>> >
>>> > On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net> wrote:
>>> >
>>> > > Replace CGLIB with ByteBuddy because it has better support for Java 8
>>> > and 9
>>> > >>
>>> > >
>>> > > What are the advantages? Seems Spring hasn't decided on this yet:
>>> > >
>>> > > https://jira.spring.io/browse/SPR-8190
>>> > >
>>> > > Regards
>>> > > Sven
>>> > >
>>> > >
>>> > >
>>> > > On 20.11.2016 00:47, Martin Grigorov wrote:
>>> > >
>>> > >> Replace CGLIB with ByteBuddy because it has better support for Java 8
>>> > and
>>> > >> 9
>>> > >> ?
>>> > >> CGLIB could stay as fallback (via system property) until 9.0.0.
>>> > >>
>>> > >> Martin Grigorov
>>> > >> Wicket Training and Consulting
>>> > >> https://twitter.com/mtgrigorov
>>> > >>
>>> > >> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>>> an.delbene@gmail.com
>>> > >
>>> > >> wrote:
>>> > >>
>>> > >> yah, I think it's better
>>> > >>>
>>> > >>>
>>> > >>>
>>> > >>> On 14/11/2016 19:54, Martin Grigorov wrote:
>>> > >>>
>>> > >>> +1
>>> > >>>>
>>> > >>>> Maybe rename #forResource() to #of() ?
>>> > >>>>
>>> > >>>> Martin Grigorov
>>> > >>>> Wicket Training and Consulting
>>> > >>>> https://twitter.com/mtgrigorov
>>> > >>>>
>>> > >>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>>> > an.delbene@gmail.com>
>>> > >>>> wrote:
>>> > >>>>
>>> > >>>> I'm wondering if there is room for an improvement for
>>> > ResourceReference,
>>> > >>>>
>>> > >>>>> introducing lambda support also for this component. Actually it's
>>> > >>>>> something
>>> > >>>>> that can be done after the release of 8.0.0, but I'd like to
>>> collect
>>> > >>>>> your
>>> > >>>>> feedback anyway. The idea is to provide factory methods to build a
>>> > >>>>> ResourceReference using lambdas and avoiding anonymous classes to
>>> > >>>>> implement
>>> > >>>>> getResource().
>>> > >>>>> The following snippet should better explain what I mean:
>>> > >>>>>
>>> > >>>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>>> > >>>>>
>>> > >>>>> Andrea.
>>> > >>>>>
>>> > >>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>> > >>>>>
>>> > >>>>> Hi,
>>> > >>>>>
>>> > >>>>>> What other improvements do we need in 8.x/master before
>>> promoting it
>>> > >>>>>> to
>>> > >>>>>> 8.0.0 final ?
>>> > >>>>>>
>>> > >>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>> > >>>>>> for+Wicket+8.0
>>> > >>>>>> we still have:
>>> > >>>>>>
>>> > >>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>> > >>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
>>> > this
>>> > >>>>>> one
>>> > >>>>>> more try but the problem is that I don't believe this is the
>>> proper
>>> > >>>>>> way
>>> > >>>>>> and
>>> > >>>>>> this demotivates me.
>>> > >>>>>> If someone else wants to give it a try - please assign it to
>>> > yourself!
>>> > >>>>>>
>>> > >>>>>> - Better SEO for stateful pages - the only way I see this is by
>>> > using
>>> > >>>>>> ServiceWorker to add the pageId as a request header to all
>>> requests
>>> > >>>>>> (normal
>>> > >>>>>> & Ajax)
>>> > >>>>>>
>>> > >>>>>>
>>> > >>>>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>> > >>>>>> I don't have much experience with it, but both React and
>>> AngularJs
>>> > >>>>>> communities use it to manage the state for their components.
>>> > >>>>>> There are some Java impls, even a standard is coming:
>>> > >>>>>> https://github.com/jvm-redux/jvm-redux-api
>>> > >>>>>>
>>> > >>>>>> What else ?
>>> > >>>>>>
>>> > >>>>>> Martin Grigorov
>>> > >>>>>> Wicket Training and Consulting
>>> > >>>>>> https://twitter.com/mtgrigorov
>>> > >>>>>>
>>> > >>>>>>
>>> > >>>>>>
>>> > >>>>>>
>>> > >
>>> >
>>>
>>
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martijn Dashorst <ma...@gmail.com>.
I would like to add Sub Resource Integrity [1] to HeaderItems, similar
to what getbootstrap.com advocates on their links. For URL based
resource references this would mean an API addition, but for classpath
based resources we could generate the hashes ourselves.
<link rel="stylesheet"
href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap.min.css"
integrity="sha384-BVYiiSIFeK1dGmJRAkycuHAHRg32OmUcww7on3RYdg4Va+PmSTsz/K68vbdEjh4u"
crossorigin="anonymous">
<!-- Optional theme -->
<link rel="stylesheet"
href="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/css/bootstrap-theme.min.css"
integrity="sha384-rHyoN1iRsVXV4nD0JutlnGaslCJuC7uwjduW9SVrLvRYooPp2bWYgmgJQIXwl/Sp"
crossorigin="anonymous">
<!-- Latest compiled and minified JavaScript -->
<script src="https://maxcdn.bootstrapcdn.com/bootstrap/3.3.7/js/bootstrap.min.js"
integrity="sha384-Tc5IQib027qvyjSMfHjOMaLkfuWVxZxUPnCJA7l2mCWNIpG9mGCD8wGNIcPD7Txa"
crossorigin="anonymous"></script>
Martijn
[1] https://www.w3.org/TR/SRI/
On Fri, Jan 13, 2017 at 5:42 AM, Tobias Soloschenko
<to...@googlemail.com> wrote:
> Hi,
>
> I think that there is also a change need to be done before release - see: https://github.com/apache/wicket/pull/195#issuecomment-271501638
>
> For Wicket 8 this would require a release for open-json. Wicket 6+7 can be changed by code
>
> kind regards
>
> Tobias
>
>> Am 13.01.2017 um 00:08 schrieb Martin Grigorov <mg...@apache.org>:
>>
>> Hi,
>>
>> @Sven: have you started migrating your app ?
>>
>> @Pedro: any idea when you will have time to finish your improvements? Do
>> you need any help ?
>>
>>
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <mg...@apache.org>
>> wrote:
>>
>>> Probably we should stick to the principle: If it works, don't touch it!
>>> This is related to CGLib and ClassMetaCache
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>>> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com> wrote:
>>>>
>>>> We can replace ClassMetaCache used in wicket-ioc's Injector by a Jandex[1]
>>>> class index.
>>>>
>>>> 1 - https://github.com/wildfly/jandex
>>>>
>>>> Pedro Santos
>>>>
>>>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <mg...@apache.org>
>>>> wrote:
>>>>
>>>>> The main advantages of ByteBuddy are:
>>>>> - actively developed
>>>>> - Mockito 2 moved to it
>>>>> - Hibernate 5.x is moving to it (
>>>>> https://twitter.com/vlad_mihalcea/status/798971296910483456)
>>>>> - Spring considers it (they actually already use it for the tests:
>>>>> https://twitter.com/ankinson/status/799363435775586308)
>>>>> - support for Java 9 (we will need it at some point)
>>>>> - support for Android (I guess no one will ever run Wicket inside
>>>> Android,
>>>>> but who knows)
>>>>>
>>>>>
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>> https://twitter.com/mtgrigorov
>>>>>
>>>>>> On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net> wrote:
>>>>>>
>>>>>> Replace CGLIB with ByteBuddy because it has better support for Java 8
>>>>> and 9
>>>>>>>
>>>>>>
>>>>>> What are the advantages? Seems Spring hasn't decided on this yet:
>>>>>>
>>>>>> https://jira.spring.io/browse/SPR-8190
>>>>>>
>>>>>> Regards
>>>>>> Sven
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 20.11.2016 00:47, Martin Grigorov wrote:
>>>>>>>
>>>>>>> Replace CGLIB with ByteBuddy because it has better support for Java 8
>>>>> and
>>>>>>> 9
>>>>>>> ?
>>>>>>> CGLIB could stay as fallback (via system property) until 9.0.0.
>>>>>>>
>>>>>>> Martin Grigorov
>>>>>>> Wicket Training and Consulting
>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>
>>>>>>> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>>>> an.delbene@gmail.com
>>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>> yah, I think it's better
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> On 14/11/2016 19:54, Martin Grigorov wrote:
>>>>>>>>
>>>>>>>> +1
>>>>>>>>>
>>>>>>>>> Maybe rename #forResource() to #of() ?
>>>>>>>>>
>>>>>>>>> Martin Grigorov
>>>>>>>>> Wicket Training and Consulting
>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>
>>>>>>>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>>>>> an.delbene@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>>
>>>>>>>>> I'm wondering if there is room for an improvement for
>>>>> ResourceReference,
>>>>>>>>>
>>>>>>>>>> introducing lambda support also for this component. Actually it's
>>>>>>>>>> something
>>>>>>>>>> that can be done after the release of 8.0.0, but I'd like to
>>>> collect
>>>>>>>>>> your
>>>>>>>>>> feedback anyway. The idea is to provide factory methods to build a
>>>>>>>>>> ResourceReference using lambdas and avoiding anonymous classes to
>>>>>>>>>> implement
>>>>>>>>>> getResource().
>>>>>>>>>> The following snippet should better explain what I mean:
>>>>>>>>>>
>>>>>>>>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>>>>>>>>>>
>>>>>>>>>> Andrea.
>>>>>>>>>>
>>>>>>>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>>>>>>>>>
>>>>>>>>>> Hi,
>>>>>>>>>>
>>>>>>>>>>> What other improvements do we need in 8.x/master before
>>>> promoting it
>>>>>>>>>>> to
>>>>>>>>>>> 8.0.0 final ?
>>>>>>>>>>>
>>>>>>>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>>>>>>>>>> for+Wicket+8.0
>>>>>>>>>>> we still have:
>>>>>>>>>>>
>>>>>>>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>>>>>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
>>>>> this
>>>>>>>>>>> one
>>>>>>>>>>> more try but the problem is that I don't believe this is the
>>>> proper
>>>>>>>>>>> way
>>>>>>>>>>> and
>>>>>>>>>>> this demotivates me.
>>>>>>>>>>> If someone else wants to give it a try - please assign it to
>>>>> yourself!
>>>>>>>>>>>
>>>>>>>>>>> - Better SEO for stateful pages - the only way I see this is by
>>>>> using
>>>>>>>>>>> ServiceWorker to add the pageId as a request header to all
>>>> requests
>>>>>>>>>>> (normal
>>>>>>>>>>> & Ajax)
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>>>>>>>>>> I don't have much experience with it, but both React and
>>>> AngularJs
>>>>>>>>>>> communities use it to manage the state for their components.
>>>>>>>>>>> There are some Java impls, even a standard is coming:
>>>>>>>>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>>>>>>>>
>>>>>>>>>>> What else ?
>>>>>>>>>>>
>>>>>>>>>>> Martin Grigorov
>>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>>
--
Become a Wicket expert, learn from the best: http://wicketinaction.com
Re: What else do we want to do before 8.0.0 final ?
Posted by Tobias Soloschenko <to...@googlemail.com>.
Hi,
I think that there is also a change need to be done before release - see: https://github.com/apache/wicket/pull/195#issuecomment-271501638
For Wicket 8 this would require a release for open-json. Wicket 6+7 can be changed by code
kind regards
Tobias
> Am 13.01.2017 um 00:08 schrieb Martin Grigorov <mg...@apache.org>:
>
> Hi,
>
> @Sven: have you started migrating your app ?
>
> @Pedro: any idea when you will have time to finish your improvements? Do
> you need any help ?
>
>
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <mg...@apache.org>
> wrote:
>
>> Probably we should stick to the principle: If it works, don't touch it!
>> This is related to CGLib and ClassMetaCache
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>>> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com> wrote:
>>>
>>> We can replace ClassMetaCache used in wicket-ioc's Injector by a Jandex[1]
>>> class index.
>>>
>>> 1 - https://github.com/wildfly/jandex
>>>
>>> Pedro Santos
>>>
>>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <mg...@apache.org>
>>> wrote:
>>>
>>>> The main advantages of ByteBuddy are:
>>>> - actively developed
>>>> - Mockito 2 moved to it
>>>> - Hibernate 5.x is moving to it (
>>>> https://twitter.com/vlad_mihalcea/status/798971296910483456)
>>>> - Spring considers it (they actually already use it for the tests:
>>>> https://twitter.com/ankinson/status/799363435775586308)
>>>> - support for Java 9 (we will need it at some point)
>>>> - support for Android (I guess no one will ever run Wicket inside
>>> Android,
>>>> but who knows)
>>>>
>>>>
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>>> On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net> wrote:
>>>>>
>>>>> Replace CGLIB with ByteBuddy because it has better support for Java 8
>>>> and 9
>>>>>>
>>>>>
>>>>> What are the advantages? Seems Spring hasn't decided on this yet:
>>>>>
>>>>> https://jira.spring.io/browse/SPR-8190
>>>>>
>>>>> Regards
>>>>> Sven
>>>>>
>>>>>
>>>>>
>>>>>> On 20.11.2016 00:47, Martin Grigorov wrote:
>>>>>>
>>>>>> Replace CGLIB with ByteBuddy because it has better support for Java 8
>>>> and
>>>>>> 9
>>>>>> ?
>>>>>> CGLIB could stay as fallback (via system property) until 9.0.0.
>>>>>>
>>>>>> Martin Grigorov
>>>>>> Wicket Training and Consulting
>>>>>> https://twitter.com/mtgrigorov
>>>>>>
>>>>>> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>>> an.delbene@gmail.com
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> yah, I think it's better
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> On 14/11/2016 19:54, Martin Grigorov wrote:
>>>>>>>
>>>>>>> +1
>>>>>>>>
>>>>>>>> Maybe rename #forResource() to #of() ?
>>>>>>>>
>>>>>>>> Martin Grigorov
>>>>>>>> Wicket Training and Consulting
>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>
>>>>>>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>>>> an.delbene@gmail.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>> I'm wondering if there is room for an improvement for
>>>> ResourceReference,
>>>>>>>>
>>>>>>>>> introducing lambda support also for this component. Actually it's
>>>>>>>>> something
>>>>>>>>> that can be done after the release of 8.0.0, but I'd like to
>>> collect
>>>>>>>>> your
>>>>>>>>> feedback anyway. The idea is to provide factory methods to build a
>>>>>>>>> ResourceReference using lambdas and avoiding anonymous classes to
>>>>>>>>> implement
>>>>>>>>> getResource().
>>>>>>>>> The following snippet should better explain what I mean:
>>>>>>>>>
>>>>>>>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>>>>>>>>>
>>>>>>>>> Andrea.
>>>>>>>>>
>>>>>>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>>>>>>>>
>>>>>>>>> Hi,
>>>>>>>>>
>>>>>>>>>> What other improvements do we need in 8.x/master before
>>> promoting it
>>>>>>>>>> to
>>>>>>>>>> 8.0.0 final ?
>>>>>>>>>>
>>>>>>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>>>>>>>>> for+Wicket+8.0
>>>>>>>>>> we still have:
>>>>>>>>>>
>>>>>>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>>>>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
>>>> this
>>>>>>>>>> one
>>>>>>>>>> more try but the problem is that I don't believe this is the
>>> proper
>>>>>>>>>> way
>>>>>>>>>> and
>>>>>>>>>> this demotivates me.
>>>>>>>>>> If someone else wants to give it a try - please assign it to
>>>> yourself!
>>>>>>>>>>
>>>>>>>>>> - Better SEO for stateful pages - the only way I see this is by
>>>> using
>>>>>>>>>> ServiceWorker to add the pageId as a request header to all
>>> requests
>>>>>>>>>> (normal
>>>>>>>>>> & Ajax)
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>>>>>>>>> I don't have much experience with it, but both React and
>>> AngularJs
>>>>>>>>>> communities use it to manage the state for their components.
>>>>>>>>>> There are some Java impls, even a standard is coming:
>>>>>>>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>>>>>>>
>>>>>>>>>> What else ?
>>>>>>>>>>
>>>>>>>>>> Martin Grigorov
>>>>>>>>>> Wicket Training and Consulting
>>>>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>>
>>>>>
>>>>
>>>
>>
>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Hi,
@Sven: have you started migrating your app ?
@Pedro: any idea when you will have time to finish your improvements? Do
you need any help ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Nov 21, 2016 at 11:54 AM, Martin Grigorov <mg...@apache.org>
wrote:
> Probably we should stick to the principle: If it works, don't touch it!
> This is related to CGLib and ClassMetaCache
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com> wrote:
>
>> We can replace ClassMetaCache used in wicket-ioc's Injector by a Jandex[1]
>> class index.
>>
>> 1 - https://github.com/wildfly/jandex
>>
>> Pedro Santos
>>
>> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <mg...@apache.org>
>> wrote:
>>
>> > The main advantages of ByteBuddy are:
>> > - actively developed
>> > - Mockito 2 moved to it
>> > - Hibernate 5.x is moving to it (
>> > https://twitter.com/vlad_mihalcea/status/798971296910483456)
>> > - Spring considers it (they actually already use it for the tests:
>> > https://twitter.com/ankinson/status/799363435775586308)
>> > - support for Java 9 (we will need it at some point)
>> > - support for Android (I guess no one will ever run Wicket inside
>> Android,
>> > but who knows)
>> >
>> >
>> >
>> > Martin Grigorov
>> > Wicket Training and Consulting
>> > https://twitter.com/mtgrigorov
>> >
>> > On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net> wrote:
>> >
>> > > Replace CGLIB with ByteBuddy because it has better support for Java 8
>> > and 9
>> > >>
>> > >
>> > > What are the advantages? Seems Spring hasn't decided on this yet:
>> > >
>> > > https://jira.spring.io/browse/SPR-8190
>> > >
>> > > Regards
>> > > Sven
>> > >
>> > >
>> > >
>> > > On 20.11.2016 00:47, Martin Grigorov wrote:
>> > >
>> > >> Replace CGLIB with ByteBuddy because it has better support for Java 8
>> > and
>> > >> 9
>> > >> ?
>> > >> CGLIB could stay as fallback (via system property) until 9.0.0.
>> > >>
>> > >> Martin Grigorov
>> > >> Wicket Training and Consulting
>> > >> https://twitter.com/mtgrigorov
>> > >>
>> > >> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
>> an.delbene@gmail.com
>> > >
>> > >> wrote:
>> > >>
>> > >> yah, I think it's better
>> > >>>
>> > >>>
>> > >>>
>> > >>> On 14/11/2016 19:54, Martin Grigorov wrote:
>> > >>>
>> > >>> +1
>> > >>>>
>> > >>>> Maybe rename #forResource() to #of() ?
>> > >>>>
>> > >>>> Martin Grigorov
>> > >>>> Wicket Training and Consulting
>> > >>>> https://twitter.com/mtgrigorov
>> > >>>>
>> > >>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
>> > an.delbene@gmail.com>
>> > >>>> wrote:
>> > >>>>
>> > >>>> I'm wondering if there is room for an improvement for
>> > ResourceReference,
>> > >>>>
>> > >>>>> introducing lambda support also for this component. Actually it's
>> > >>>>> something
>> > >>>>> that can be done after the release of 8.0.0, but I'd like to
>> collect
>> > >>>>> your
>> > >>>>> feedback anyway. The idea is to provide factory methods to build a
>> > >>>>> ResourceReference using lambdas and avoiding anonymous classes to
>> > >>>>> implement
>> > >>>>> getResource().
>> > >>>>> The following snippet should better explain what I mean:
>> > >>>>>
>> > >>>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>> > >>>>>
>> > >>>>> Andrea.
>> > >>>>>
>> > >>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>> > >>>>>
>> > >>>>> Hi,
>> > >>>>>
>> > >>>>>> What other improvements do we need in 8.x/master before
>> promoting it
>> > >>>>>> to
>> > >>>>>> 8.0.0 final ?
>> > >>>>>>
>> > >>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>> > >>>>>> for+Wicket+8.0
>> > >>>>>> we still have:
>> > >>>>>>
>> > >>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>> > >>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
>> > this
>> > >>>>>> one
>> > >>>>>> more try but the problem is that I don't believe this is the
>> proper
>> > >>>>>> way
>> > >>>>>> and
>> > >>>>>> this demotivates me.
>> > >>>>>> If someone else wants to give it a try - please assign it to
>> > yourself!
>> > >>>>>>
>> > >>>>>> - Better SEO for stateful pages - the only way I see this is by
>> > using
>> > >>>>>> ServiceWorker to add the pageId as a request header to all
>> requests
>> > >>>>>> (normal
>> > >>>>>> & Ajax)
>> > >>>>>>
>> > >>>>>>
>> > >>>>>> Recently I wondered whether Redux.js could be in use for Wicket.
>> > >>>>>> I don't have much experience with it, but both React and
>> AngularJs
>> > >>>>>> communities use it to manage the state for their components.
>> > >>>>>> There are some Java impls, even a standard is coming:
>> > >>>>>> https://github.com/jvm-redux/jvm-redux-api
>> > >>>>>>
>> > >>>>>> What else ?
>> > >>>>>>
>> > >>>>>> Martin Grigorov
>> > >>>>>> Wicket Training and Consulting
>> > >>>>>> https://twitter.com/mtgrigorov
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >>>>>>
>> > >
>> >
>>
>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Probably we should stick to the principle: If it works, don't touch it!
This is related to CGLib and ClassMetaCache
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Nov 21, 2016 at 1:22 AM, Pedro Santos <pe...@gmail.com> wrote:
> We can replace ClassMetaCache used in wicket-ioc's Injector by a Jandex[1]
> class index.
>
> 1 - https://github.com/wildfly/jandex
>
> Pedro Santos
>
> On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <mg...@apache.org>
> wrote:
>
> > The main advantages of ByteBuddy are:
> > - actively developed
> > - Mockito 2 moved to it
> > - Hibernate 5.x is moving to it (
> > https://twitter.com/vlad_mihalcea/status/798971296910483456)
> > - Spring considers it (they actually already use it for the tests:
> > https://twitter.com/ankinson/status/799363435775586308)
> > - support for Java 9 (we will need it at some point)
> > - support for Android (I guess no one will ever run Wicket inside
> Android,
> > but who knows)
> >
> >
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net> wrote:
> >
> > > Replace CGLIB with ByteBuddy because it has better support for Java 8
> > and 9
> > >>
> > >
> > > What are the advantages? Seems Spring hasn't decided on this yet:
> > >
> > > https://jira.spring.io/browse/SPR-8190
> > >
> > > Regards
> > > Sven
> > >
> > >
> > >
> > > On 20.11.2016 00:47, Martin Grigorov wrote:
> > >
> > >> Replace CGLIB with ByteBuddy because it has better support for Java 8
> > and
> > >> 9
> > >> ?
> > >> CGLIB could stay as fallback (via system property) until 9.0.0.
> > >>
> > >> Martin Grigorov
> > >> Wicket Training and Consulting
> > >> https://twitter.com/mtgrigorov
> > >>
> > >> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <
> an.delbene@gmail.com
> > >
> > >> wrote:
> > >>
> > >> yah, I think it's better
> > >>>
> > >>>
> > >>>
> > >>> On 14/11/2016 19:54, Martin Grigorov wrote:
> > >>>
> > >>> +1
> > >>>>
> > >>>> Maybe rename #forResource() to #of() ?
> > >>>>
> > >>>> Martin Grigorov
> > >>>> Wicket Training and Consulting
> > >>>> https://twitter.com/mtgrigorov
> > >>>>
> > >>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
> > an.delbene@gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>> I'm wondering if there is room for an improvement for
> > ResourceReference,
> > >>>>
> > >>>>> introducing lambda support also for this component. Actually it's
> > >>>>> something
> > >>>>> that can be done after the release of 8.0.0, but I'd like to
> collect
> > >>>>> your
> > >>>>> feedback anyway. The idea is to provide factory methods to build a
> > >>>>> ResourceReference using lambdas and avoiding anonymous classes to
> > >>>>> implement
> > >>>>> getResource().
> > >>>>> The following snippet should better explain what I mean:
> > >>>>>
> > >>>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
> > >>>>>
> > >>>>> Andrea.
> > >>>>>
> > >>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
> > >>>>>
> > >>>>> Hi,
> > >>>>>
> > >>>>>> What other improvements do we need in 8.x/master before promoting
> it
> > >>>>>> to
> > >>>>>> 8.0.0 final ?
> > >>>>>>
> > >>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
> > >>>>>> for+Wicket+8.0
> > >>>>>> we still have:
> > >>>>>>
> > >>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
> > >>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
> > this
> > >>>>>> one
> > >>>>>> more try but the problem is that I don't believe this is the
> proper
> > >>>>>> way
> > >>>>>> and
> > >>>>>> this demotivates me.
> > >>>>>> If someone else wants to give it a try - please assign it to
> > yourself!
> > >>>>>>
> > >>>>>> - Better SEO for stateful pages - the only way I see this is by
> > using
> > >>>>>> ServiceWorker to add the pageId as a request header to all
> requests
> > >>>>>> (normal
> > >>>>>> & Ajax)
> > >>>>>>
> > >>>>>>
> > >>>>>> Recently I wondered whether Redux.js could be in use for Wicket.
> > >>>>>> I don't have much experience with it, but both React and AngularJs
> > >>>>>> communities use it to manage the state for their components.
> > >>>>>> There are some Java impls, even a standard is coming:
> > >>>>>> https://github.com/jvm-redux/jvm-redux-api
> > >>>>>>
> > >>>>>> What else ?
> > >>>>>>
> > >>>>>> Martin Grigorov
> > >>>>>> Wicket Training and Consulting
> > >>>>>> https://twitter.com/mtgrigorov
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>>
> > >
> >
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Pedro Santos <pe...@gmail.com>.
We can replace ClassMetaCache used in wicket-ioc's Injector by a Jandex[1]
class index.
1 - https://github.com/wildfly/jandex
Pedro Santos
On Sun, Nov 20, 2016 at 4:19 PM, Martin Grigorov <mg...@apache.org>
wrote:
> The main advantages of ByteBuddy are:
> - actively developed
> - Mockito 2 moved to it
> - Hibernate 5.x is moving to it (
> https://twitter.com/vlad_mihalcea/status/798971296910483456)
> - Spring considers it (they actually already use it for the tests:
> https://twitter.com/ankinson/status/799363435775586308)
> - support for Java 9 (we will need it at some point)
> - support for Android (I guess no one will ever run Wicket inside Android,
> but who knows)
>
>
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net> wrote:
>
> > Replace CGLIB with ByteBuddy because it has better support for Java 8
> and 9
> >>
> >
> > What are the advantages? Seems Spring hasn't decided on this yet:
> >
> > https://jira.spring.io/browse/SPR-8190
> >
> > Regards
> > Sven
> >
> >
> >
> > On 20.11.2016 00:47, Martin Grigorov wrote:
> >
> >> Replace CGLIB with ByteBuddy because it has better support for Java 8
> and
> >> 9
> >> ?
> >> CGLIB could stay as fallback (via system property) until 9.0.0.
> >>
> >> Martin Grigorov
> >> Wicket Training and Consulting
> >> https://twitter.com/mtgrigorov
> >>
> >> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <an.delbene@gmail.com
> >
> >> wrote:
> >>
> >> yah, I think it's better
> >>>
> >>>
> >>>
> >>> On 14/11/2016 19:54, Martin Grigorov wrote:
> >>>
> >>> +1
> >>>>
> >>>> Maybe rename #forResource() to #of() ?
> >>>>
> >>>> Martin Grigorov
> >>>> Wicket Training and Consulting
> >>>> https://twitter.com/mtgrigorov
> >>>>
> >>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <
> an.delbene@gmail.com>
> >>>> wrote:
> >>>>
> >>>> I'm wondering if there is room for an improvement for
> ResourceReference,
> >>>>
> >>>>> introducing lambda support also for this component. Actually it's
> >>>>> something
> >>>>> that can be done after the release of 8.0.0, but I'd like to collect
> >>>>> your
> >>>>> feedback anyway. The idea is to provide factory methods to build a
> >>>>> ResourceReference using lambdas and avoiding anonymous classes to
> >>>>> implement
> >>>>> getResource().
> >>>>> The following snippet should better explain what I mean:
> >>>>>
> >>>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
> >>>>>
> >>>>> Andrea.
> >>>>>
> >>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>>> What other improvements do we need in 8.x/master before promoting it
> >>>>>> to
> >>>>>> 8.0.0 final ?
> >>>>>>
> >>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
> >>>>>> for+Wicket+8.0
> >>>>>> we still have:
> >>>>>>
> >>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
> >>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give
> this
> >>>>>> one
> >>>>>> more try but the problem is that I don't believe this is the proper
> >>>>>> way
> >>>>>> and
> >>>>>> this demotivates me.
> >>>>>> If someone else wants to give it a try - please assign it to
> yourself!
> >>>>>>
> >>>>>> - Better SEO for stateful pages - the only way I see this is by
> using
> >>>>>> ServiceWorker to add the pageId as a request header to all requests
> >>>>>> (normal
> >>>>>> & Ajax)
> >>>>>>
> >>>>>>
> >>>>>> Recently I wondered whether Redux.js could be in use for Wicket.
> >>>>>> I don't have much experience with it, but both React and AngularJs
> >>>>>> communities use it to manage the state for their components.
> >>>>>> There are some Java impls, even a standard is coming:
> >>>>>> https://github.com/jvm-redux/jvm-redux-api
> >>>>>>
> >>>>>> What else ?
> >>>>>>
> >>>>>> Martin Grigorov
> >>>>>> Wicket Training and Consulting
> >>>>>> https://twitter.com/mtgrigorov
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>>
> >
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
The main advantages of ByteBuddy are:
- actively developed
- Mockito 2 moved to it
- Hibernate 5.x is moving to it (
https://twitter.com/vlad_mihalcea/status/798971296910483456)
- Spring considers it (they actually already use it for the tests:
https://twitter.com/ankinson/status/799363435775586308)
- support for Java 9 (we will need it at some point)
- support for Android (I guess no one will ever run Wicket inside Android,
but who knows)
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Sun, Nov 20, 2016 at 7:08 PM, Sven Meier <sv...@meiers.net> wrote:
> Replace CGLIB with ByteBuddy because it has better support for Java 8 and 9
>>
>
> What are the advantages? Seems Spring hasn't decided on this yet:
>
> https://jira.spring.io/browse/SPR-8190
>
> Regards
> Sven
>
>
>
> On 20.11.2016 00:47, Martin Grigorov wrote:
>
>> Replace CGLIB with ByteBuddy because it has better support for Java 8 and
>> 9
>> ?
>> CGLIB could stay as fallback (via system property) until 9.0.0.
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <an...@gmail.com>
>> wrote:
>>
>> yah, I think it's better
>>>
>>>
>>>
>>> On 14/11/2016 19:54, Martin Grigorov wrote:
>>>
>>> +1
>>>>
>>>> Maybe rename #forResource() to #of() ?
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <an...@gmail.com>
>>>> wrote:
>>>>
>>>> I'm wondering if there is room for an improvement for ResourceReference,
>>>>
>>>>> introducing lambda support also for this component. Actually it's
>>>>> something
>>>>> that can be done after the release of 8.0.0, but I'd like to collect
>>>>> your
>>>>> feedback anyway. The idea is to provide factory methods to build a
>>>>> ResourceReference using lambdas and avoiding anonymous classes to
>>>>> implement
>>>>> getResource().
>>>>> The following snippet should better explain what I mean:
>>>>>
>>>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>>>>>
>>>>> Andrea.
>>>>>
>>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>>>>
>>>>> Hi,
>>>>>
>>>>>> What other improvements do we need in 8.x/master before promoting it
>>>>>> to
>>>>>> 8.0.0 final ?
>>>>>>
>>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>>>>> for+Wicket+8.0
>>>>>> we still have:
>>>>>>
>>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
>>>>>> one
>>>>>> more try but the problem is that I don't believe this is the proper
>>>>>> way
>>>>>> and
>>>>>> this demotivates me.
>>>>>> If someone else wants to give it a try - please assign it to yourself!
>>>>>>
>>>>>> - Better SEO for stateful pages - the only way I see this is by using
>>>>>> ServiceWorker to add the pageId as a request header to all requests
>>>>>> (normal
>>>>>> & Ajax)
>>>>>>
>>>>>>
>>>>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>>>>> I don't have much experience with it, but both React and AngularJs
>>>>>> communities use it to manage the state for their components.
>>>>>> There are some Java impls, even a standard is coming:
>>>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>>>
>>>>>> What else ?
>>>>>>
>>>>>> Martin Grigorov
>>>>>> Wicket Training and Consulting
>>>>>> https://twitter.com/mtgrigorov
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Sven Meier <sv...@meiers.net>.
>Replace CGLIB with ByteBuddy because it has better support for Java 8 and 9
What are the advantages? Seems Spring hasn't decided on this yet:
https://jira.spring.io/browse/SPR-8190
Regards
Sven
On 20.11.2016 00:47, Martin Grigorov wrote:
> Replace CGLIB with ByteBuddy because it has better support for Java 8 and 9
> ?
> CGLIB could stay as fallback (via system property) until 9.0.0.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <an...@gmail.com>
> wrote:
>
>> yah, I think it's better
>>
>>
>>
>> On 14/11/2016 19:54, Martin Grigorov wrote:
>>
>>> +1
>>>
>>> Maybe rename #forResource() to #of() ?
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <an...@gmail.com>
>>> wrote:
>>>
>>> I'm wondering if there is room for an improvement for ResourceReference,
>>>> introducing lambda support also for this component. Actually it's
>>>> something
>>>> that can be done after the release of 8.0.0, but I'd like to collect your
>>>> feedback anyway. The idea is to provide factory methods to build a
>>>> ResourceReference using lambdas and avoiding anonymous classes to
>>>> implement
>>>> getResource().
>>>> The following snippet should better explain what I mean:
>>>>
>>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>>>>
>>>> Andrea.
>>>>
>>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>>>
>>>> Hi,
>>>>> What other improvements do we need in 8.x/master before promoting it to
>>>>> 8.0.0 final ?
>>>>>
>>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>>>> for+Wicket+8.0
>>>>> we still have:
>>>>>
>>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
>>>>> one
>>>>> more try but the problem is that I don't believe this is the proper way
>>>>> and
>>>>> this demotivates me.
>>>>> If someone else wants to give it a try - please assign it to yourself!
>>>>>
>>>>> - Better SEO for stateful pages - the only way I see this is by using
>>>>> ServiceWorker to add the pageId as a request header to all requests
>>>>> (normal
>>>>> & Ajax)
>>>>>
>>>>>
>>>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>>>> I don't have much experience with it, but both React and AngularJs
>>>>> communities use it to manage the state for their components.
>>>>> There are some Java impls, even a standard is coming:
>>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>>
>>>>> What else ?
>>>>>
>>>>> Martin Grigorov
>>>>> Wicket Training and Consulting
>>>>> https://twitter.com/mtgrigorov
>>>>>
>>>>>
>>>>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Replace CGLIB with ByteBuddy because it has better support for Java 8 and 9
?
CGLIB could stay as fallback (via system property) until 9.0.0.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <an...@gmail.com>
wrote:
> yah, I think it's better
>
>
>
> On 14/11/2016 19:54, Martin Grigorov wrote:
>
>> +1
>>
>> Maybe rename #forResource() to #of() ?
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <an...@gmail.com>
>> wrote:
>>
>> I'm wondering if there is room for an improvement for ResourceReference,
>>> introducing lambda support also for this component. Actually it's
>>> something
>>> that can be done after the release of 8.0.0, but I'd like to collect your
>>> feedback anyway. The idea is to provide factory methods to build a
>>> ResourceReference using lambdas and avoiding anonymous classes to
>>> implement
>>> getResource().
>>> The following snippet should better explain what I mean:
>>>
>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>>>
>>> Andrea.
>>>
>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>>
>>> Hi,
>>>>
>>>> What other improvements do we need in 8.x/master before promoting it to
>>>> 8.0.0 final ?
>>>>
>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>>> for+Wicket+8.0
>>>> we still have:
>>>>
>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
>>>> one
>>>> more try but the problem is that I don't believe this is the proper way
>>>> and
>>>> this demotivates me.
>>>> If someone else wants to give it a try - please assign it to yourself!
>>>>
>>>> - Better SEO for stateful pages - the only way I see this is by using
>>>> ServiceWorker to add the pageId as a request header to all requests
>>>> (normal
>>>> & Ajax)
>>>>
>>>>
>>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>>> I don't have much experience with it, but both React and AngularJs
>>>> communities use it to manage the state for their components.
>>>> There are some Java impls, even a standard is coming:
>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>
>>>> What else ?
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>>
>>>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Replace CGLIB with ByteBuddy because it has better support for Java 8 and 9
?
CGLIB could stay as fallback (via system property) until 9.0.0.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Nov 18, 2016 at 12:49 PM, Andrea Del Bene <an...@gmail.com>
wrote:
> yah, I think it's better
>
>
>
> On 14/11/2016 19:54, Martin Grigorov wrote:
>
>> +1
>>
>> Maybe rename #forResource() to #of() ?
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <an...@gmail.com>
>> wrote:
>>
>> I'm wondering if there is room for an improvement for ResourceReference,
>>> introducing lambda support also for this component. Actually it's
>>> something
>>> that can be done after the release of 8.0.0, but I'd like to collect your
>>> feedback anyway. The idea is to provide factory methods to build a
>>> ResourceReference using lambdas and avoiding anonymous classes to
>>> implement
>>> getResource().
>>> The following snippet should better explain what I mean:
>>>
>>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>>>
>>> Andrea.
>>>
>>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>>
>>> Hi,
>>>>
>>>> What other improvements do we need in 8.x/master before promoting it to
>>>> 8.0.0 final ?
>>>>
>>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>>> for+Wicket+8.0
>>>> we still have:
>>>>
>>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this
>>>> one
>>>> more try but the problem is that I don't believe this is the proper way
>>>> and
>>>> this demotivates me.
>>>> If someone else wants to give it a try - please assign it to yourself!
>>>>
>>>> - Better SEO for stateful pages - the only way I see this is by using
>>>> ServiceWorker to add the pageId as a request header to all requests
>>>> (normal
>>>> & Ajax)
>>>>
>>>>
>>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>>> I don't have much experience with it, but both React and AngularJs
>>>> communities use it to manage the state for their components.
>>>> There are some Java impls, even a standard is coming:
>>>> https://github.com/jvm-redux/jvm-redux-api
>>>>
>>>> What else ?
>>>>
>>>> Martin Grigorov
>>>> Wicket Training and Consulting
>>>> https://twitter.com/mtgrigorov
>>>>
>>>>
>>>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Andrea Del Bene <an...@gmail.com>.
yah, I think it's better
On 14/11/2016 19:54, Martin Grigorov wrote:
> +1
>
> Maybe rename #forResource() to #of() ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <an...@gmail.com>
> wrote:
>
>> I'm wondering if there is room for an improvement for ResourceReference,
>> introducing lambda support also for this component. Actually it's something
>> that can be done after the release of 8.0.0, but I'd like to collect your
>> feedback anyway. The idea is to provide factory methods to build a
>> ResourceReference using lambdas and avoiding anonymous classes to implement
>> getResource().
>> The following snippet should better explain what I mean:
>>
>> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>>
>> Andrea.
>>
>> On 31/10/2016 14:41, Martin Grigorov wrote:
>>
>>> Hi,
>>>
>>> What other improvements do we need in 8.x/master before promoting it to
>>> 8.0.0 final ?
>>>
>>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>>> for+Wicket+8.0
>>> we still have:
>>>
>>> - new DateTime APIs for wicket-datetime *WICKET-6105
>>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
>>> more try but the problem is that I don't believe this is the proper way
>>> and
>>> this demotivates me.
>>> If someone else wants to give it a try - please assign it to yourself!
>>>
>>> - Better SEO for stateful pages - the only way I see this is by using
>>> ServiceWorker to add the pageId as a request header to all requests
>>> (normal
>>> & Ajax)
>>>
>>>
>>> Recently I wondered whether Redux.js could be in use for Wicket.
>>> I don't have much experience with it, but both React and AngularJs
>>> communities use it to manage the state for their components.
>>> There are some Java impls, even a standard is coming:
>>> https://github.com/jvm-redux/jvm-redux-api
>>>
>>> What else ?
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>>
Re: What else do we want to do before 8.0.0 final ?
Posted by Sebastien <se...@gmail.com>.
Hi Martin,
Thanks for your useful & detailed answer!
That's was actually my understanding, but the reality may be a little bit
different on some use cases leading to the LDM being loaded several times
by request cycles...
As it seems to be an issue (if demonstrated :p) rather than a known
behavior, I will try to make a quickstart and open a new thread to discuss
this...
Thanks again & best regards,
Sebastien
On Thu, Nov 17, 2016 at 12:36 AM, Martin Grigorov <mg...@apache.org>
wrote:
> Hi Sebastien,
>
> What exactly is the problem ?
> LoadableDetachableModel loads its model object at first call to
> #getObject() in the request cycle and null-ifies it at #onDetach(), i.e. at
> the end of the request cycle.
>
> If a LDM is reused by several components then it will be null-ified when
> the first component detaches its model, so it will be detached when the
> other components call their #detachModel() method but this should be fine
> because at that time the model could not be used for anything because the
> rendering has finished.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Hi Sebastien,
What exactly is the problem ?
LoadableDetachableModel loads its model object at first call to
#getObject() in the request cycle and null-ifies it at #onDetach(), i.e. at
the end of the request cycle.
If a LDM is reused by several components then it will be null-ified when
the first component detaches its model, so it will be detached when the
other components call their #detachModel() method but this should be fine
because at that time the model could not be used for anything because the
rendering has finished.
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Wed, Nov 16, 2016 at 3:36 PM, Sebastien <se...@gmail.com> wrote:
> Hi devs,
>
> It is sometimes hard to deal with LDM if we want the model to be shared by
> several components and/or wrapped in other model(s).
> In other words, how to answer the recurring question: "I want my model to
> be loaded once by request-cycle and detached once at the end of the
> request".
>
> Maybe to have an optional extra argument in model ctors which specify the
> retention policy: Component (default) or RequestCycle/Page ?
>
> Any opinion ?
>
> Thanks,
> Sebastien.
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Sebastien <se...@gmail.com>.
Hi devs,
It is sometimes hard to deal with LDM if we want the model to be shared by
several components and/or wrapped in other model(s).
In other words, how to answer the recurring question: "I want my model to
be loaded once by request-cycle and detached once at the end of the
request".
Maybe to have an optional extra argument in model ctors which specify the
retention policy: Component (default) or RequestCycle/Page ?
Any opinion ?
Thanks,
Sebastien.
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
+1
Maybe rename #forResource() to #of() ?
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Fri, Nov 11, 2016 at 5:00 PM, Andrea Del Bene <an...@gmail.com>
wrote:
> I'm wondering if there is room for an improvement for ResourceReference,
> introducing lambda support also for this component. Actually it's something
> that can be done after the release of 8.0.0, but I'd like to collect your
> feedback anyway. The idea is to provide factory methods to build a
> ResourceReference using lambdas and avoiding anonymous classes to implement
> getResource().
> The following snippet should better explain what I mean:
>
> https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
>
> Andrea.
>
> On 31/10/2016 14:41, Martin Grigorov wrote:
>
>> Hi,
>>
>> What other improvements do we need in 8.x/master before promoting it to
>> 8.0.0 final ?
>>
>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>> for+Wicket+8.0
>> we still have:
>>
>> - new DateTime APIs for wicket-datetime *WICKET-6105
>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
>> more try but the problem is that I don't believe this is the proper way
>> and
>> this demotivates me.
>> If someone else wants to give it a try - please assign it to yourself!
>>
>> - Better SEO for stateful pages - the only way I see this is by using
>> ServiceWorker to add the pageId as a request header to all requests
>> (normal
>> & Ajax)
>>
>>
>> Recently I wondered whether Redux.js could be in use for Wicket.
>> I don't have much experience with it, but both React and AngularJs
>> communities use it to manage the state for their components.
>> There are some Java impls, even a standard is coming:
>> https://github.com/jvm-redux/jvm-redux-api
>>
>> What else ?
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Andrea Del Bene <an...@gmail.com>.
I'm wondering if there is room for an improvement for ResourceReference,
introducing lambda support also for this component. Actually it's
something that can be done after the release of 8.0.0, but I'd like to
collect your feedback anyway. The idea is to provide factory methods to
build a ResourceReference using lambdas and avoiding anonymous classes
to implement getResource().
The following snippet should better explain what I mean:
https://gist.github.com/bitstorm/03cfe9905a3f86a7160ab49f0ce23f13
Andrea.
On 31/10/2016 14:41, Martin Grigorov wrote:
> Hi,
>
> What other improvements do we need in 8.x/master before promoting it to
> 8.0.0 final ?
>
> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0
> we still have:
>
> - new DateTime APIs for wicket-datetime *WICKET-6105
> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
> more try but the problem is that I don't believe this is the proper way and
> this demotivates me.
> If someone else wants to give it a try - please assign it to yourself!
>
> - Better SEO for stateful pages - the only way I see this is by using
> ServiceWorker to add the pageId as a request header to all requests (normal
> & Ajax)
>
>
> Recently I wondered whether Redux.js could be in use for Wicket.
> I don't have much experience with it, but both React and AngularJs
> communities use it to manage the state for their components.
> There are some Java impls, even a standard is coming:
> https://github.com/jvm-redux/jvm-redux-api
>
> What else ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Forwarding to users@wicket.apache.org
GMail autosuggest tricked me to send it to users@isis.apache.org.
On Mon, Oct 31, 2016 at 2:41 PM, Martin Grigorov <mg...@apache.org>
wrote:
> Hi,
>
> What other improvements do we need in 8.x/master before promoting it to
> 8.0.0 final ?
>
> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0
> we still have:
>
> - new DateTime APIs for wicket-datetime *WICKET-6105
> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
> more try but the problem is that I don't believe this is the proper way and
> this demotivates me.
> If someone else wants to give it a try - please assign it to yourself!
>
> - Better SEO for stateful pages - the only way I see this is by using
> ServiceWorker to add the pageId as a request header to all requests (normal
> & Ajax)
>
>
> Recently I wondered whether Redux.js could be in use for Wicket.
> I don't have much experience with it, but both React and AngularJs
> communities use it to manage the state for their components.
> There are some Java impls, even a standard is coming: https://github.com/
> jvm-redux/jvm-redux-api
>
> What else ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Martin Grigorov <mg...@apache.org>.
Oh, GMail autosuggest ...
Thanks, Dan!
Martin Grigorov
Wicket Training and Consulting
https://twitter.com/mtgrigorov
On Mon, Oct 31, 2016 at 2:43 PM, Dan Haywood <da...@haywood-associates.co.uk>
wrote:
> Hi Martin,
>
> You sent this to dev@wicket but also users@isis ... I imagine you meant
> to send it to users@wicket instead?
>
> Dan
>
> On 31 October 2016 at 13:41, Martin Grigorov <mg...@apache.org> wrote:
>
>> Hi,
>>
>> What other improvements do we need in 8.x/master before promoting it to
>> 8.0.0 final ?
>>
>> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+
>> for+Wicket+8.0
>> we still have:
>>
>> - new DateTime APIs for wicket-datetime *WICKET-6105
>> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
>> more try but the problem is that I don't believe this is the proper way
>> and
>> this demotivates me.
>> If someone else wants to give it a try - please assign it to yourself!
>>
>> - Better SEO for stateful pages - the only way I see this is by using
>> ServiceWorker to add the pageId as a request header to all requests
>> (normal
>> & Ajax)
>>
>>
>> Recently I wondered whether Redux.js could be in use for Wicket.
>> I don't have much experience with it, but both React and AngularJs
>> communities use it to manage the state for their components.
>> There are some Java impls, even a standard is coming:
>> https://github.com/jvm-redux/jvm-redux-api
>>
>> What else ?
>>
>> Martin Grigorov
>> Wicket Training and Consulting
>> https://twitter.com/mtgrigorov
>>
>
>
Re: What else do we want to do before 8.0.0 final ?
Posted by Dan Haywood <da...@haywood-associates.co.uk>.
Hi Martin,
You sent this to dev@wicket but also users@isis ... I imagine you meant to
send it to users@wicket instead?
Dan
On 31 October 2016 at 13:41, Martin Grigorov <mg...@apache.org> wrote:
> Hi,
>
> What other improvements do we need in 8.x/master before promoting it to
> 8.0.0 final ?
>
> At https://cwiki.apache.org/confluence/display/WICKET/Ideas+for+Wicket+8.0
> we still have:
>
> - new DateTime APIs for wicket-datetime *WICKET-6105
> <https://issues.apache.org/jira/browse/WICKET-6105>* - I'll give this one
> more try but the problem is that I don't believe this is the proper way and
> this demotivates me.
> If someone else wants to give it a try - please assign it to yourself!
>
> - Better SEO for stateful pages - the only way I see this is by using
> ServiceWorker to add the pageId as a request header to all requests (normal
> & Ajax)
>
>
> Recently I wondered whether Redux.js could be in use for Wicket.
> I don't have much experience with it, but both React and AngularJs
> communities use it to manage the state for their components.
> There are some Java impls, even a standard is coming:
> https://github.com/jvm-redux/jvm-redux-api
>
> What else ?
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>