Hi Emond,

On Mon, Oct 31, 2016 at 4:28 PM, Emond Papegaaij <[email protected]
> 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
>
>
>

Reply via email to