Re: Quick start and https/TLS/SSL
> The quickstart itself is stateless, so no sessions/cookies are created. Good point, one can even never navigate to the self signed certificate error page. Even so, it sounds a good idea for me to remove such unnecessary complexity (HTTPS setup) for newcomers. > Any code added by the developer can break the application in many different > ways... > > No quickstart, no problems :-) Sure, but we can make non Wicket related problems more unlikely to happen to newcomers playing around. I thought this was the point of the proposal Pedro Santos On Tue, Jan 16, 2018 at 1:59 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > On Tue, Jan 16, 2018 at 4:33 PM, Pedro Santos <pedros...@gmail.com> wrote: > > > +0 > > > > Sounds a good idea since the quickstart is the fist contact most of new > > users will have with Wicket. It makes sense to keep is as simple as > > possible, focusing on showcasing components like WebPage, Label. > > > > Also the HTTPS configuration can easily go wrong as it will set a secure > > cookie on the browser, and cause any following non secure access to fail > in > > to set a session cookie. Its not a Wicket problem, but its an avoidable > > scenario for newcomers, and one that is already reported on the users > list > > > > The quickstart itself is stateless, so no sessions/cookies are created. > Any code added by the developer can break the application in many different > ways... > > No quickstart, no problems :-) > > > > [1] > > > > 1 - > > http://apache-wicket.1842946.n4.nabble.com/Endless- > > Redirect-with-tracking-mode-COOKIE-and-Cookies-Disabled- > > in-Browser-td4679364.html#a4679370 > > > > > > Pedro Santos > > > > On Tue, Jan 16, 2018 at 6:17 AM, Emond Papegaaij < > > emond.papega...@topicus.nl > > > wrote: > > > > > -1 > > > > > > I agree, application servers, such as WildFly provide similar > solutions. > > By > > > default WildFly will generate a self-signed certificate for the > https/h2 > > > listener. > > > > > > Emond > > > > > > On dinsdag 16 januari 2018 05:10:32 CET Maxim Solodovnik wrote: > > > > -1 > > > > > > > > I believe it's good to have HTTPS configuration ready for the tests. > > > > It is impossible to provide non-self-signed, so IMO security warning > > > > is OK here > > > > > > > > On Mon, Jan 15, 2018 at 3:42 AM, Martin Grigorov < > mgrigo...@apache.org > > > > > > wrote: > > > > > -1 > > > > > > > > > > The current setup makes it easier to debug HTTPS related issues. > > > > > I, personally, do not want to deal with openssl, keytool and > > > > > jetty-https.xml just to debug an issue in HttpsMapper or related > > code. > > > > > > > > > > A user can use http://localhost if (s)he doesn't want to accept > self > > > > > signed > > > > > certs. > > > > > > > > > > My 2c. > > > > > > > > > > On Sun, Jan 14, 2018 at 8:16 PM, Martijn Dashorst < > > > > > > > > > > martijn.dasho...@gmail.com> wrote: > > > > >> The quick start uses a self signed certificate that gives errors > in > > > > >> browsers and requires folks to accept the certificate in their > trust > > > > >> chain. > > > > >> > > > > >> I suggest we remove the secure layer part from our quickstart just > > to > > > > >> make sure we don't train our users to accept any certificate. > WDYT? > > > > >> > > > > >> Martijn > > > > > > > > > > > >
Re: Quick start and https/TLS/SSL
+0 Sounds a good idea since the quickstart is the fist contact most of new users will have with Wicket. It makes sense to keep is as simple as possible, focusing on showcasing components like WebPage, Label. Also the HTTPS configuration can easily go wrong as it will set a secure cookie on the browser, and cause any following non secure access to fail in to set a session cookie. Its not a Wicket problem, but its an avoidable scenario for newcomers, and one that is already reported on the users list [1] 1 - http://apache-wicket.1842946.n4.nabble.com/Endless-Redirect-with-tracking-mode-COOKIE-and-Cookies-Disabled-in-Browser-td4679364.html#a4679370 Pedro Santos On Tue, Jan 16, 2018 at 6:17 AM, Emond Papegaaij <emond.papega...@topicus.nl > wrote: > -1 > > I agree, application servers, such as WildFly provide similar solutions. By > default WildFly will generate a self-signed certificate for the https/h2 > listener. > > Emond > > On dinsdag 16 januari 2018 05:10:32 CET Maxim Solodovnik wrote: > > -1 > > > > I believe it's good to have HTTPS configuration ready for the tests. > > It is impossible to provide non-self-signed, so IMO security warning > > is OK here > > > > On Mon, Jan 15, 2018 at 3:42 AM, Martin Grigorov <mgrigo...@apache.org> > wrote: > > > -1 > > > > > > The current setup makes it easier to debug HTTPS related issues. > > > I, personally, do not want to deal with openssl, keytool and > > > jetty-https.xml just to debug an issue in HttpsMapper or related code. > > > > > > A user can use http://localhost if (s)he doesn't want to accept self > > > signed > > > certs. > > > > > > My 2c. > > > > > > On Sun, Jan 14, 2018 at 8:16 PM, Martijn Dashorst < > > > > > > martijn.dasho...@gmail.com> wrote: > > >> The quick start uses a self signed certificate that gives errors in > > >> browsers and requires folks to accept the certificate in their trust > > >> chain. > > >> > > >> I suggest we remove the secure layer part from our quickstart just to > > >> make sure we don't train our users to accept any certificate. WDYT? > > >> > > >> Martijn > > >
Re: @PMC: Request permission for a HyderabadJUG meetup for Wicket
+1: yes you can use the Apache Wicket™ brand for the HyderabadJUG good meetup Martijn Pedro Santos On Thu, Dec 21, 2017 at 3:24 PM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > Apparently to abide by the rules of the ComDev [1] I have to ask > permission to use the Apache Wicket name for organizing a meetup event > for the HyderabadJUG concerning Wicket. > > So here it goes: > > Can I, in conjunction with my co-organizers of the HyderabadJUG and > our local business partner use the Apache Wicket name to organize an > event concerning our project with one or two talks about Wicket? > > [ ] +1: yes you can use the Apache Wicket™ brand for the HyderabadJUG > [ ] -1: Nope > > Martijn > > [1] http://community.apache.org/events/small-events.html >
Re: Proposal to move @FunctionalInteface from IModel
Hi Andrea,
thx for the reference. Michael's proposal is awesome and I'm I think we
should go for a better model interface hierarchy. But this proposal, of an
IReadyOnlyModel as an IModel extension, wasn't discussed. My point is that
we can provide an interface "designed" to provide a function as a model and
have a little impact on existent Wicket projects at the same time. Just to
be clear, I'm 1+ for Michael's proposal, but if don't pass, I would be 1+
for this proposal.
Hi Emond,
> Your proposal will not work because Java does not resolve functional
> interfaces to subtypes of the target type. For example, take the Label
> constructor:
I know, and that is just a good thing. Take TextField for example, we don't
want it constructed with a function as a model:
new TextField("id", Bean::getMethod())
this proposal is correctly preventing the user from assigning a read-only
model to a component designed to write on it.
> In Wicket 8 this works, because IModel is a functional interface, so Java
> knows how to convert a method taking no arguments and returning a double
into
> a IModel by mapping that method to getObject().
Sure, and it's our job to provide good a API allowing the user to benefit
from Java 8 features *where it does make sense*. A good set of constructors
for a Label would include:
public Label(String id, IReadyOnlyModel model){ ... }
Cheers
Pedro Santos
On Mon, Apr 10, 2017 at 3:27 AM, Emond Papegaaij <emond.papega...@topicus.nl
> wrote:
> Hi Pedro,
>
> Your proposal will not work because Java does not resolve functional
> interfaces to subtypes of the target type. For example, take the Label
> constructor:
>
> public Label(String id, IModel model)
>
> I would like to use this constructor as follows:
>
> new Label("id", Math::random)
>
> In Wicket 8 this works, because IModel is a functional interface, so Java
> knows how to convert a method taking no arguments and returning a double
> into
> a IModel by mapping that method to getObject().
>
> With your proposal, this code needs to be changed to:
>
> new Label("id", (IReadOnlyModel) Math::random)
>
> So time ago, we tried to make IModel extend a ReadOnlyModel. In that case,
> it
> would work, but the change did not work out very well.
>
> Best regards,
> Emond
>
> On vrijdag 7 april 2017 12:45:53 CEST Pedro Santos wrote:
> > Hi devs,
> >
> > IModel isn't an interface designed to provide a function, it's rather an
> > interface designed to provide and manipulate (setObject and detach
> methods)
> > internal state.
> >
> > IMO a better alternative to benefit from Java 8 features would be to move
> > the FunctionalInterface annotation to an interface that actually is
> > designed to provide one function.
> >
> > I propose that we add a new interface extending IModel to provide this
> > functional interface, instead of to misplace it in an interface made for
> > objects with internal state.
> >
> > e.g.
> >
> > @FunctionalInterface
> > interface IReadyOnlyModel / IModelFunction / IFunction extends from
> IModel{
> >
> > default void setObject(final T object)
> > {
> > throw new UnsupportedOperationException("unsuported");
> > }
> >
> > default void detach()
> > {
> > throw new UnsupportedOperationException("unsuported");
> > }
> >
> > }
> >
> > Cheers
> >
> > Pedro Santos
>
>
>
Proposal to move @FunctionalInteface from IModel
Hi devs,
IModel isn't an interface designed to provide a function, it's rather an
interface designed to provide and manipulate (setObject and detach methods)
internal state.
IMO a better alternative to benefit from Java 8 features would be to move
the FunctionalInterface annotation to an interface that actually is
designed to provide one function.
I propose that we add a new interface extending IModel to provide this
functional interface, instead of to misplace it in an interface made for
objects with internal state.
e.g.
@FunctionalInterface
interface IReadyOnlyModel / IModelFunction / IFunction extends from IModel{
default void setObject(final T object)
{
throw new UnsupportedOperationException("unsuported");
}
default void detach()
{
throw new UnsupportedOperationException("unsuported");
}
}
Cheers
Pedro Santos
Re: [VOTE] Proposal to remove IDetachable from IModel hierarchy
Hi Emond, > TL;DR Vote at the bottom What does it mean? That your email can be skipped to the voting part or that I was prolix in my last email? > I think we are not going to agree on this proposal. No problem. Having different opinions being discussed is just a sign of a healthy project. Carl, Indeed, and it's really nice to get you option on this. I also see this as a tradeoff situation. Martijn, > models only live during > actual request processing They live longer. They even implement IClusterable (IDetachable's superinterface) to do so. IClusterable being IDetachable's superinterface is a living paradox for me. [x] Yes, remove IDetachable from IModel Pedro Santos On Mon, Apr 3, 2017 at 10:49 AM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > While I appreciate the effort in questioning our fundamentals and > trying to improve even the oldest parts of our API, I don't think that > the detach method is semantically wrong for models. Semantics are > defined by what we say the semantics are. In a request/response > oriented environment a detach is an essential part of the lifecycle of > a request in general, and for models in particular. > > Were Wicket a Swing framework, I would consider modifying the API, but > as Wicket lives in an environment where the models only live during > actual request processing, and are literally detached otherwise, > IModel implementations should have detach behavior, and therefore the > framework must guarantee that it can call the detach logic at > appropriate times. Therefore IModels *are* IDetachable. > > So I don't think we should remove IDetachable from IModel as it is an > essential, integral and semantically correct part of models. > > [X] No, keep IModel detachable. > > Martijn > > > On Mon, Apr 3, 2017 at 9:38 AM, Emond Papegaaij > <emond.papega...@topicus.nl> wrote: > > Something went wrong sending this mail. I did write some more, but > somehow my > > mail client lost it. So here's the vote again: > > > > I think we are not going to agree on this proposal. I think it is not an > > improvement and I do not agree with you that IModel should not be > > detachable by default. So lets vote on this. > > > > [ ] Yes, remove IDetachable from IModel > > [ ] No, keep IModel detachable > > > > My vote: > > -1 keep IModel detachable > > > > Best regards, > > Emond > > > > > > > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com >
Re: Proposal to remove IDetachable from IModel hierarchy
> Most of our models have detach logic. However, we do not have that many custom > model implementations. Most of these detach implementations are custom types > implementing IDetachable and those methods are not empty either. So you are good here, all those detachable model specializations will remain being detachable (this proposal touches IModel interface only, not its subtypes that were meant to be detachable). Just specialize the variables types you said were typed as IModel. Wicket's core also has such variables typed as IModel and I had no problem invoking the detach method [1]. > The major concern I have with this change is that it does not improve > anything. This change has impact on both the calling and implementing side of > detach. Neither side becomes easier. It does improve the IModel interface hierarchy by removing an unnecessary superinterface, and by fixing the code semantic by removing an empty method that wasn't default, but was written as one. > The caller (i.e. component) still always has to call detach on all models (now > guared by an instanceof), because it can never be sure that the actual > implementation will or will not be detachable. No, the caller needs to call detach if the model is detachable only. > For example, if the type is > MyCustomModel (which does not implement IDetachable), a subclass of this type > might implement IDetachable. Also, the implementation of MyCustomModel might > change in the future. You are clearly generalizing a very specific use case, you can't say "still always has to call detach". In this specific use case, where you have a polymorphic type, yes you do have to check if the instance is detachable. This occurs in Wicket's core because it's the place where generic model wrappers abstractions are defined and provided for the final user. If Wicket's core abstractions do their job right, this complexity should be taken away from the final user. Even by having to check for the model implementation, there's no need to guard the detach call inside an instanceof. You can just delegate this job to a helper class, or to bind the model to a component. > This problem is already visible in your branch with > models like PropertyModel, GenericBaseModel en Model. Why are these > IDetachable? Because the content might be (but often is not). What do those models have in common? They are all wrappers to other models. If we pass through this proposal, we will be able to go ahead and propose to remove their IDetachable interface; that was wrongfully ( and unthoughtful because it was forced via IModel ) add as their superinterface. > On the side of the implementation for new models not much changes. You don't > need to implement detach() when you don't need it. No, you *do need*, and you *already implemented* it by choosing to implement IModel. You clearly mean here that you successfully hide from the user an empty method, written with a semantically wrong word, enforced by a contract that shouldn't be there in the first place. It's just trickery, not a good interface not enforcing an unneeded method. > If you do need it, you now > need 2 changes: implement IDetachable *and* implement detach(). No, a detachable model *always needed* to implement IDetacheble interface, no changes here. > For all > existing IModel implementations you do need to make a change: either implement > IDetachable or remove detach(). Most of Wicket's detachable model abstractions already add the IDetachable contract in the hierarchy. Yes, you do need to remove the detach method from models that aren't detachable. Wicket's core developers are already doing it just to have a clear code. > Your change violates the Liskov substitution principle. A component should be > able to handle all types of IModel in the same way, regardless of its > implementation. The fact that you now need an instanceof check is an > indication of this violation. This proposal can't possibly be violating the substitution principle, because of one reason: it removes a superinteface, not adds one that could not be substituted by its subtype. But the person who added the IDetachable interface to IModel, did violate this principle, and the need of the IIAmNotActuallyDetachabe interface to test if the model is actually detachable is a clear indication of this violation. 1 - https://github.com/pedrosans/wicket/commit/ca818adcc1df0d8 aae7f65be8ee09777325cf9f1#diff-6032b412b69768c08b1fe4a7b099d574R49 Pedro Santos On Fri, Mar 31, 2017 at 5:29 AM, Emond Papegaaij <emond.papega...@topicus.nl > wrote: > On donderdag 30 maart 2017 17:49:40 CEST Pedro Santos wrote: > > > 1674 calls to IDetachable.detach() from our codebase, most for models > > > > hard to conclude anything from this number, because this proposal didn't > > change the most commonly used models abstractions: > > Load
Re: Proposal to remove IDetachable from IModel hierarchy
> It's difficult to get exact numbers, but here are some: > 48137 java files, 74565 class files, not all wicket related, that's > the entire codebase I'm working on thanks for sharing > 1674 calls to IDetachable.detach() from our codebase, most for models hard to conclude anything from this number, because this proposal didn't change the most commonly used models abstractions: LoadableDetachableModel, GenericBaseModel, Model; neither changed the interface IWrapModel. They all remain being, as they were meant to be, detachable. > 1338 implementations of detach(), I don't know how many come from > IModel implementations and I don't know how many are empty. that would be an amazing info. Can't you take a sample of 10 randomly IModel implementations and tell how much of them actually have detach logic? As I reported before, this number is surprisingly low in wicket-examples and wicketstuff. > As you can see, this change will probably cause between 1000 and 2000 > errors in my workspace. Yes, but you have a codebase of 48137 java files! Were you truly expecting an easy migration with a codebase that big? And expecting it at the expense of a wrong interface hierarchy for the rest of Wicket developers, including new comers that shouldn't be having to understand a so tangled and meaningless set of interfaces (IModel, as Sven pointed, isn't the only semantically wrong interface, and there's even a ticket proposing more errors - WICKET-6347)? Pedro Santos On Thu, Mar 30, 2017 at 3:55 PM, Emond Papegaaij <emond.papega...@gmail.com> wrote: > It's difficult to get exact numbers, but here are some: > 48137 java files, 74565 class files, not all wicket related, that's > the entire codebase I'm working on > 1674 calls to IDetachable.detach() from our codebase, most for models > 1338 implementations of detach(), I don't know how many come from > IModel implementations and I don't know how many are empty. > > As you can see, this change will probably cause between 1000 and 2000 > errors in my workspace. > > On Thu, Mar 30, 2017 at 8:08 PM, Pedro Santos <pedros...@gmail.com> wrote: > > Emond, > > > > The numbers from wicketstuff: > > > > 2957 classes in total > > 71 empty detaches causing compilation errors > > 34 in wicket-fondation > > 2 detache methods that werent a dummy empty methods; on in a test case in > > LazyModelTest; one in the FutureModel in wicketstuff-minis project > > > > The project I'm currently working: > > > > 331 classes in total > > 2 empty detaches causing compilation errors > > 0 detach logic in an IModel implementation > > > > Wicket-examples: > > > > 391 classes in total > > ~5 empty detaches that would cause compilation error (from my search in > the > > logs [1]) > > > > I don't mind to analyse another project using Wicket if it's available in > > GitHub of some where public if you think it will give me more insights. > > Models just implementing IModel are rarely detachable. > > > > if you don't share any information about your code base, it will be hard > to > > understand the dimension of your problem. > > > > 1 - https://github.com/apache/wicket/commit/ > e93eb0ae99c0c0257a151173951232 > > 6ecf00cc73 > > > > Pedro Santos > > > > On Thu, Mar 30, 2017 at 4:09 AM, Francois Meillet < > > francois.meil...@gmail.com> wrote: > > > >> Totally agree with Ernesto. > >> > >> François > >> > >> > >> > >> > Le 30 mars 2017 à 09:04, Ernesto Reinaldo Barreiro < > reier...@gmail.com> > >> a écrit : > >> > > >> > Hi, > >> > > >> > As a wicket user I would hate to have to ask myself if my model are > >> > detachable or not. I work as freelance wicket consultant and I have > got > >> to > >> > the opportunity to see quite a few wicket projects, most of them > already > >> > started/mature projects, and the hard time some developers have to > figure > >> > out how to properly use models. IMHO adding more complexity would not > >> help > >> > at all. > >> > > >> > On Thu, Mar 30, 2017 at 8:33 AM, Martin Grigorov < > mgrigo...@apache.org> > >> > wrote: > >> > > >> >> On Wed, Mar 29, 2017 at 11:03 PM, Pedro Santos <pedros...@gmail.com> > >> >> wrote: > >> >> > >> >>>> -1 > >> >>> > >> >>> is it a veto or a vote against the proposal? > >> >>> > >> >> > >> >> It means "I don
Re: Proposal to remove IDetachable from IModel hierarchy
Hi Ernesto, this proposal aims to provide a semantically correct interface. Wicket core will remain being the one responsible to handle user's models lifecycle, as Emond correctly pointed this out: > Storing state directly in components is > considered bad practise. The same is true for behaviors. Only very few > components need specific detach logic themselves. so you should be good here. While this better semantic will make the code easier to be understood by newcomers that weren't hardened by years of bad semantic, long time users will be forced to remove a bunch of empty e useless methods when migrating to Wicket 8. This undesired effect (force users to remove junk) has also a positive effect; it will get a code that is easier to understand, cleaner and by consequence more maintainable. Even without being forced to do so, we already choose at Apache [1] to remove all those empty detach methods and happily got ~25 less lines of bad code forced into the code base by years of bad semantic. 1 - https://github.com/apache/wicket/commit/e93eb0ae99c0c0257a15 11739512326ecf00cc73 Pedro Santos On Thu, Mar 30, 2017 at 4:04 AM, Ernesto Reinaldo Barreiro < reier...@gmail.com> wrote: > Hi, > > As a wicket user I would hate to have to ask myself if my model are > detachable or not. I work as freelance wicket consultant and I have got to > the opportunity to see quite a few wicket projects, most of them already > started/mature projects, and the hard time some developers have to figure > out how to properly use models. IMHO adding more complexity would not help > at all. > > On Thu, Mar 30, 2017 at 8:33 AM, Martin Grigorov <mgrigo...@apache.org> > wrote: > > > On Wed, Mar 29, 2017 at 11:03 PM, Pedro Santos <pedros...@gmail.com> > > wrote: > > > > > > -1 > > > > > > is it a veto or a vote against the proposal? > > > > > > > It means "I don't like the proposal" > > > > Honestly I don't really know how vetoing works here at Apache... > > > > > > > > > > Pedro Santos > > > > > > On Wed, Mar 29, 2017 at 4:34 PM, Martin Grigorov <mgrigo...@apache.org > > > > > wrote: > > > > > > > Fully agree with Emond! > > > > As a user I will hate such kind of change. > > > > Several years ago this change might be OKish, but now with Java 8 > > default > > > > methods it would be insane to break everyone's code when default > > methods > > > > make it invisible. > > > > Until 7.x I'd have to add empty impl for detach() when I don't need > it. > > > > With Wicket 8.x I won't bother at all! > > > > > > > > Is your branch complete ? I see no changes in wicket-examples. Maybe > it > > > is > > > > because several months ago I've cleaned all empty impls of > #detach(). I > > > did > > > > it because I did it. It was compiling even without removing them. But > > > with > > > > your changes everyone will have to go all over his/her code and fix > it! > > > > If you remember the days when people migrated from 1.4.x to 1.5.x, or > > > from > > > > 1.5.x to 6.x - many users sent a lot of negative feedback for such > kind > > > of > > > > changes. Changes without deprecation cycle and changes without real > > > benefit > > > > from user point of view. > > > > > > > > -1 > > > > > > > > On Wed, Mar 29, 2017 at 7:53 PM, Emond Papegaaij < > > > > emond.papega...@gmail.com> > > > > wrote: > > > > > > > > > Hi Pedro, > > > > > > > > > > I fail to see why it is a problem for IModel to be IDetachable. It > is > > > > > an integral part of the lifecycle of IModel. One could say that the > > > > > sole purpose of the detach traversal is to detach all models. A > model > > > > > knows how to retrieve data, update data and to detach its internal > > > > > representation from the backend for future request handling. A > model > > > > > that does not require special processing to detach, simply omits > this > > > > > method: it has a default, empty implementation. Calling this empty > > > > > method is cheap and likely to cause problems. > > > > > > > > > > Changing this part of the API will break the world. All > > > > > implementations of IModel need to either implement IDetachable or > > > > > remove detach(). All calls to detach() need to be guar
Re: Proposal to remove IDetachable from IModel hierarchy
Emond, The numbers from wicketstuff: 2957 classes in total 71 empty detaches causing compilation errors 34 in wicket-fondation 2 detache methods that werent a dummy empty methods; on in a test case in LazyModelTest; one in the FutureModel in wicketstuff-minis project The project I'm currently working: 331 classes in total 2 empty detaches causing compilation errors 0 detach logic in an IModel implementation Wicket-examples: 391 classes in total ~5 empty detaches that would cause compilation error (from my search in the logs [1]) I don't mind to analyse another project using Wicket if it's available in GitHub of some where public if you think it will give me more insights. Models just implementing IModel are rarely detachable. if you don't share any information about your code base, it will be hard to understand the dimension of your problem. 1 - https://github.com/apache/wicket/commit/e93eb0ae99c0c0257a151173951232 6ecf00cc73 Pedro Santos On Thu, Mar 30, 2017 at 4:09 AM, Francois Meillet < francois.meil...@gmail.com> wrote: > Totally agree with Ernesto. > > François > > > > > Le 30 mars 2017 à 09:04, Ernesto Reinaldo Barreiro <reier...@gmail.com> > a écrit : > > > > Hi, > > > > As a wicket user I would hate to have to ask myself if my model are > > detachable or not. I work as freelance wicket consultant and I have got > to > > the opportunity to see quite a few wicket projects, most of them already > > started/mature projects, and the hard time some developers have to figure > > out how to properly use models. IMHO adding more complexity would not > help > > at all. > > > > On Thu, Mar 30, 2017 at 8:33 AM, Martin Grigorov <mgrigo...@apache.org> > > wrote: > > > >> On Wed, Mar 29, 2017 at 11:03 PM, Pedro Santos <pedros...@gmail.com> > >> wrote: > >> > >>>> -1 > >>> > >>> is it a veto or a vote against the proposal? > >>> > >> > >> It means "I don't like the proposal" > >> > >> Honestly I don't really know how vetoing works here at Apache... > >> > >> > >>> > >>> Pedro Santos > >>> > >>> On Wed, Mar 29, 2017 at 4:34 PM, Martin Grigorov <mgrigo...@apache.org > > > >>> wrote: > >>> > >>>> Fully agree with Emond! > >>>> As a user I will hate such kind of change. > >>>> Several years ago this change might be OKish, but now with Java 8 > >> default > >>>> methods it would be insane to break everyone's code when default > >> methods > >>>> make it invisible. > >>>> Until 7.x I'd have to add empty impl for detach() when I don't need > it. > >>>> With Wicket 8.x I won't bother at all! > >>>> > >>>> Is your branch complete ? I see no changes in wicket-examples. Maybe > it > >>> is > >>>> because several months ago I've cleaned all empty impls of #detach(). > I > >>> did > >>>> it because I did it. It was compiling even without removing them. But > >>> with > >>>> your changes everyone will have to go all over his/her code and fix > it! > >>>> If you remember the days when people migrated from 1.4.x to 1.5.x, or > >>> from > >>>> 1.5.x to 6.x - many users sent a lot of negative feedback for such > kind > >>> of > >>>> changes. Changes without deprecation cycle and changes without real > >>> benefit > >>>> from user point of view. > >>>> > >>>> -1 > >>>> > >>>> On Wed, Mar 29, 2017 at 7:53 PM, Emond Papegaaij < > >>>> emond.papega...@gmail.com> > >>>> wrote: > >>>> > >>>>> Hi Pedro, > >>>>> > >>>>> I fail to see why it is a problem for IModel to be IDetachable. It is > >>>>> an integral part of the lifecycle of IModel. One could say that the > >>>>> sole purpose of the detach traversal is to detach all models. A model > >>>>> knows how to retrieve data, update data and to detach its internal > >>>>> representation from the backend for future request handling. A model > >>>>> that does not require special processing to detach, simply omits this > >>>>> method: it has a default, empty implementation. Calling this empty > >>>>> method is cheap and likely to cause problems. > >>>>> > >>>>> Changing
Re: Proposal to remove IDetachable from IModel hierarchy
Hi Emond,
> It is an integral part of the lifecycle of IModel
Most of the models in Wicket and Wicketstuff have no detach logic, hardly
an integral part.
> One could say that the sole purpose of the detach traversal is to detach
all models.
Wicket detaches all components in the page in pre-order and each component
is responsible to detach any detachable object used during the request, not
only models. Just to be clear, no changes being proposed here.
> Changing this part of the API will break the world. All
> implementations of IModel need to either implement IDetachable or
> remove detach().
This change is not being proposed to Wicket 7, to break the world is an
exaggeration.
> All calls to detach() need to be guarded with an
> instanceof check and a cast. You can be sure many users will be very
> upset with such a change.
They didn't get upset by adding a bunch of empty detach methods in their
models that weren't detachable. It will be trick to say how sad or upset
users will be. Also I explained in my reply to Sven how this instanceof can
be abstracted from the user.
> What is your usecase for IIAmNotActuallyDetachabe? Why not simply call
> detach and have it do nothing when nothing needs to be done?
If a logic inside the component depends on the model being detachable or
not, it wouldn't be able to determine it testing the current interface. No
specific usecase in mind.
Pedro Santos
On Wed, Mar 29, 2017 at 2:53 PM, Emond Papegaaij <emond.papega...@gmail.com>
wrote:
> Hi Pedro,
>
> I fail to see why it is a problem for IModel to be IDetachable. It is
> an integral part of the lifecycle of IModel. One could say that the
> sole purpose of the detach traversal is to detach all models. A model
> knows how to retrieve data, update data and to detach its internal
> representation from the backend for future request handling. A model
> that does not require special processing to detach, simply omits this
> method: it has a default, empty implementation. Calling this empty
> method is cheap and likely to cause problems.
>
> Changing this part of the API will break the world. All
> implementations of IModel need to either implement IDetachable or
> remove detach(). All calls to detach() need to be guarded with an
> instanceof check and a cast. You can be sure many users will be very
> upset with such a change.
>
> What is your usecase for IIAmNotActuallyDetachabe? Why not simply call
> detach and have it do nothing when nothing needs to be done?
>
> Best regards,
> Emond
>
> On Wed, Mar 29, 2017 at 6:12 PM, Pedro Santos <pedros...@gmail.com> wrote:
> > From user's perspective this is a symmetrical problem. This sadness is
> > carried over to an user in the other side, in need to avoid any detach
> > logic or processing in his component or model if the target model isn't
> > detachable. Right know he would have to come up with his own marker e.g.:
> > IIAmNotActuallyDetachabe interface. Given the symmetry, I would choose
> the
> > side that is not semantically wrong.
> >
> > Also this instanceof test is more common for us, Wicket's core
> developers.
> > For the final user the AbstractWrapModel class and a helper function (I
> can
> > propose one) should hide this complexity. We can't judge how sad it's for
> > the final user base on how common it's for *us* to have this instanceof
> > check, and without even try to abstract this complexity.
> >
> > Yes, I think this fix should be carried over to FeedbackMessage,
> > ICellPopulator and IDataProvider.
> >
> >>The current solution - even if semantically wrong - is simpler.
> >
> > It's simpler only because of the instanceof test that should be
> abstracted
> > from the user?
> >
> >
> > Pedro Santos
> >
> > On Wed, Mar 29, 2017 at 11:48 AM, Sven Meier <s...@meiers.net> wrote:
> >
> >> Hi Pedro,
> >>
> >> for Wicket your changes look fine.
> >>
> >> But I have an objection from a user's perspective:
> >> If I hold a reference to a model (in a component or another wrapping
> >> model), I'll always have to check the instance and do a cast before
> >> detaching it:
> >>
> >> class MyComponent {
> >> private IModel foo;
> >>
> >> @Override
> >> public void detachModels() {
> >> if (foo instanceof IDetachable) {
> >> ((IDetachable)foo).detach();
> >> }
> >> }
> >> }
> >>
> >> Sad :/.
> >>
> >> Furthermore what about FeedbackMessage, ICellPopulator and
> IDataProvider?
> >> Will their implementation
Re: Proposal to remove IDetachable from IModel hierarchy
>From user's perspective this is a symmetrical problem. This sadness is
carried over to an user in the other side, in need to avoid any detach
logic or processing in his component or model if the target model isn't
detachable. Right know he would have to come up with his own marker e.g.:
IIAmNotActuallyDetachabe interface. Given the symmetry, I would choose the
side that is not semantically wrong.
Also this instanceof test is more common for us, Wicket's core developers.
For the final user the AbstractWrapModel class and a helper function (I can
propose one) should hide this complexity. We can't judge how sad it's for
the final user base on how common it's for *us* to have this instanceof
check, and without even try to abstract this complexity.
Yes, I think this fix should be carried over to FeedbackMessage,
ICellPopulator and IDataProvider.
>The current solution - even if semantically wrong - is simpler.
It's simpler only because of the instanceof test that should be abstracted
from the user?
Pedro Santos
On Wed, Mar 29, 2017 at 11:48 AM, Sven Meier <s...@meiers.net> wrote:
> Hi Pedro,
>
> for Wicket your changes look fine.
>
> But I have an objection from a user's perspective:
> If I hold a reference to a model (in a component or another wrapping
> model), I'll always have to check the instance and do a cast before
> detaching it:
>
> class MyComponent {
> private IModel foo;
>
> @Override
> public void detachModels() {
> if (foo instanceof IDetachable) {
> ((IDetachable)foo).detach();
> }
> }
> }
>
> Sad :/.
>
> Furthermore what about FeedbackMessage, ICellPopulator and IDataProvider?
> Will their implementations no longer be forced to implement IDetachable too?
>
> IMHO your missing an important aspect of IDetachable: yes, many
> implementations really don't need to detach anything. But many places
> *have* to detach these objects, *iff* they are detachable.
> The current solution - even if semantically wrong - is simpler.
>
> Best regards
> Sven
>
>
>
> On 29.03.2017 15:52, Pedro Santos wrote:
>
>> Hi team,
>>
>> Not every model is detachable, but right now all models extends from
>> IDetachable because this contract is forced to any implementation for
>> IModel.
>>
>> The only way users have to communicate their model isn't detachable, for
>> their own purpose, is by creating their own mechanism; but I think
>> IDetachable interface should serve its purpose and to mark / be extended
>> by
>> detachable models, like documented in its own javadoc.
>>
>> I did the changes necessary for this improvement in the branch
>> 'not-detachable' at [1], and hope you can give your input. While working
>> on
>> the branch I noticed a few problems in Wicket's code and already added a
>> fix:
>>
>> - LabeledWebMarkupContainer called wrapped model detach twice (fixed)
>>
>> - SessionSizeModel has no detach logic but was being detached at
>> SessionSizeDebugPanel (fixed)
>>
>> - The following classes had anonymous model wrappers that weren't
>> extending
>> from IWrapModel, that would better communicates their purpose(fixed):
>> LambdaColumn, IModel, LambdaModel, AjaxEditableLabel, LambdaColumn
>>
>> 1 - https://github.com/pedrosans/wicket/tree/not-detachable
>>
>> Pedro Santos
>>
>>
>
Proposal to remove IDetachable from IModel hierarchy
Hi team, Not every model is detachable, but right now all models extends from IDetachable because this contract is forced to any implementation for IModel. The only way users have to communicate their model isn't detachable, for their own purpose, is by creating their own mechanism; but I think IDetachable interface should serve its purpose and to mark / be extended by detachable models, like documented in its own javadoc. I did the changes necessary for this improvement in the branch 'not-detachable' at [1], and hope you can give your input. While working on the branch I noticed a few problems in Wicket's code and already added a fix: - LabeledWebMarkupContainer called wrapped model detach twice (fixed) - SessionSizeModel has no detach logic but was being detached at SessionSizeDebugPanel (fixed) - The following classes had anonymous model wrappers that weren't extending from IWrapModel, that would better communicates their purpose(fixed): LambdaColumn, IModel, LambdaModel, AjaxEditableLabel, LambdaColumn 1 - https://github.com/pedrosans/wicket/tree/not-detachable Pedro Santos
Re: [wicket8] Use default method for IModel#detach()?
Hi Sven,
yes, I want to work on the proposals:
- to not force IDetachable to IModel
- IModel without the functional interface annotation
- named LambdaModel subclasses and a better name for this class
>IIRC Michael Mosmann tried to work on something similar but it never quite
worked out.
Indeed it looks a big change and I wouldn't propose it to Wicket 8, but
yes, I would like to give it a try in the future.
Pedro Santos
On Mon, Mar 27, 2017 at 1:50 PM, Sven Meier <s...@meiers.net> wrote:
> Hi Pedro,
>
> >Why don't we make AbstractReadyOnlyModel the superinterface of IModel
>
> IIRC Michael Mosmann tried to work on something similar but it never quite
> worked out.
>
> Do you want to work on a proposal?
>
> Before you invest too much time into this: I'm pretty sure most devs won't
> be in favor of doing another round of IModel refactoring in Wicket 8
> because of semantics.
>
> Regards
> Sven
>
>
>
> On 27.03.2017 01:39, Pedro Santos wrote:
>
>> -0
>>
>> I see no good reason for IModel to extend from IDetachable. Users should
>> be
>> able to add this interface at their will.
>>
>> If IModel were a @FunctionalInterface, then you wouldn't need something
>>> like
>>>
>> a SupplierModel; you could just use a lambda directly:
>>
>> IModel, as it's now, isn't a functional interface.
>>
>> Then maybe just make IModel#setObject() default too ..
>>>
>> There's no default implementation for IModel#setObject(). The one that was
>> added is as much semantically wrong as to say IModel is a functional
>> interface.
>>
>> Proposal:
>>
>> Why don't we make AbstractReadyOnlyModel the superinterface of IModel
>> instead of to keep it as an abstract adaptor for IModel? So we would have
>> a
>> semantically correct functional interface.
>>
>>
>>
>> Pedro Santos
>>
>> On Tue, Oct 6, 2015 at 6:42 PM, Martin Grigorov <mgrigo...@apache.org>
>> wrote:
>>
>> Ugh, right!
>>>
>>> Then maybe just make IModel#setObject() default too ...
>>> We will experiment! :)
>>>
>>> Martin Grigorov
>>> Wicket Training and Consulting
>>> https://twitter.com/mtgrigorov
>>>
>>> On Tue, Oct 6, 2015 at 11:27 PM, Michael Mosmann <mich...@mosmann.de>
>>> wrote:
>>>
>>> .. @IReadOnlyModel: i hope, it will be easier to change then the last
>>>>
>>> time
>>>
>>>> i tried it. Watch out for component default model stuff...
>>>>
>>>> :)
>>>>
>>>> Am 6. Oktober 2015 22:54:37 MESZ, schrieb Martin Grigorov <
>>>> mgrigo...@apache.org>:
>>>>
>>>>> On Tue, Oct 6, 2015 at 10:43 PM, Andrew Geery <andrew.ge...@gmail.com>
>>>>> wrote:
>>>>>
>>>>> If IModel were a @FunctionalInterface, then you wouldn't need
>>>>>>
>>>>> something
>>>>>
>>>>>> like a SupplierModel; you could just use a lambda directly:
>>>>>>
>>>>>> new Label("label", () -> "The current time is " + LocalDate.now());
>>>>>>
>>>>>> This looks good indeed.
>>>>> It seems we will add IReadOnlyModel soon!
>>>>>
>>>>>
>>>>> And since IModel is Serializable, the lambda will be too, without
>>>>>>
>>>>> having to
>>>>>
>>>>>> have an artificial interface that is both Serializable & a Supplier.
>>>>>>
>>>>>> Thanks
>>>>>> Andrew
>>>>>>
>>>>>> On Tue, Oct 6, 2015 at 4:21 PM, Martin Grigorov
>>>>>>
>>>>> <mgrigo...@apache.org>
>>>>>
>>>>>> wrote:
>>>>>>
>>>>>> Same for IRequestHandler#detach()
>>>>>>>
>>>>>>> Martin Grigorov
>>>>>>> Wicket Training and Consulting
>>>>>>> https://twitter.com/mtgrigorov
>>>>>>>
>>>>>>> On Mon, Oct 5, 2015 at 10:42 PM, Martijn Dashorst <
>>>>>>> martijn.dasho...@gmail.com> wrote:
>>>>>>>
>>>>>>> Should we use an empty default implementation for IModel#detach?
>>>>>>>>
>>>>>>>>
>>>>>>>> public class IModel extends IDetachable
>>>>>>>> {
>>>>>>>> ...
>>>>>>>>
>>>>>>>> @Override
>>>>>>>> default void detach()
>>>>>>>> {
>>>>>>>> }
>>>>>>>> }
>>>>>>>>
>>>>>>>> This won't break existing applications, but might make it a bit
>>>>>>>>
>>>>>>> easier
>>>>>
>>>>>> on the eyes to implement IModel directly.
>>>>>>>>
>>>>>>>> I'm not in favor of applying the default method to IDetachable,
>>>>>>>> because that would defeat the interface's purpose IMO.
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> Martijn
>>>>>>>>
>>>>>>>> --
>>>> Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
>>>> gesendet.
>>>>
>>>
>
Re: [wicket8] Use default method for IModel#detach()?
Neither I am sure I understand you. By dating the email thread and the
IModel interface hierarchy you mean that by them being old we can't discuss
their merit?
I meant that IModel isn't a functional interface, not that it isn't
annotated as one. Same for the setObject method not having a default
implementation.
IModel is the interface of objects with two behaviours, they can set and
get model objects. A functional interface is a contract promising only one
behavior.
How to throw an exception is the default functionality of setObject method?
Nothing is being set there, so it doesn't fit as a default implementation.
On Mar 27, 2017 3:22 AM, "Martin Grigorov" <mgrigo...@apache.org> wrote:
Hi Pedro,
I am not sure I understand you!
This discussion was 1.5 years ago ...
On Mon, Mar 27, 2017 at 1:39 AM, Pedro Santos <pedros...@gmail.com> wrote:
> -0
>
> I see no good reason for IModel to extend from IDetachable. Users should
be
> able to add this interface at their will.
>
IModel extends IDetachable since forever
https://github.com/apache/wicket/blob/wicket-1.3.x/jdk-
1.4/wicket/src/main/java/org/apache/wicket/model/IModel.java#L56
>
> >If IModel were a @FunctionalInterface, then you wouldn't need something
> like
> a SupplierModel; you could just use a lambda directly:
>
> IModel, as it's now, isn't a functional interface.
>
Yes, it is!
https://github.com/apache/wicket/blob/8a4e1b3c24f4ce1fc3e44ca1b5a923
0158d9b584/wicket-core/src/main/java/org/apache/wicket/model/IModel.java#L63
>
> >Then maybe just make IModel#setObject() default too ..
>
> There's no default implementation for IModel#setObject(). The one that was
>
Yes, there is!
https://github.com/apache/wicket/blob/8a4e1b3c24f4ce1fc3e44ca1b5a923
0158d9b584/wicket-core/src/main/java/org/apache/wicket/model/IModel.java#L81
> added is as much semantically wrong as to say IModel is a functional
> interface.
> Proposal:
>
> Why don't we make AbstractReadyOnlyModel the superinterface of IModel
> instead of to keep it as an abstract adaptor for IModel? So we would have
a
> semantically correct functional interface.
>
IMO the current design looks and works quite good! No need to change
anything!
>
>
>
> Pedro Santos
>
> On Tue, Oct 6, 2015 at 6:42 PM, Martin Grigorov <mgrigo...@apache.org>
> wrote:
>
> > Ugh, right!
> >
> > Then maybe just make IModel#setObject() default too ...
> > We will experiment! :)
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> > On Tue, Oct 6, 2015 at 11:27 PM, Michael Mosmann <mich...@mosmann.de>
> > wrote:
> >
> > > .. @IReadOnlyModel: i hope, it will be easier to change then the last
> > time
> > > i tried it. Watch out for component default model stuff...
> > >
> > > :)
> > >
> > > Am 6. Oktober 2015 22:54:37 MESZ, schrieb Martin Grigorov <
> > > mgrigo...@apache.org>:
> > > >On Tue, Oct 6, 2015 at 10:43 PM, Andrew Geery <andrew.ge...@gmail.com
> >
> > > >wrote:
> > > >
> > > >> If IModel were a @FunctionalInterface, then you wouldn't need
> > > >something
> > > >> like a SupplierModel; you could just use a lambda directly:
> > > >>
> > > >> new Label("label", () -> "The current time is " + LocalDate.now());
> > > >>
> > > >
> > > >This looks good indeed.
> > > >It seems we will add IReadOnlyModel soon!
> > > >
> > > >
> > > >>
> > > >> And since IModel is Serializable, the lambda will be too, without
> > > >having to
> > > >> have an artificial interface that is both Serializable & a
Supplier.
> > > >>
> > > >> Thanks
> > > >> Andrew
> > > >>
> > > >> On Tue, Oct 6, 2015 at 4:21 PM, Martin Grigorov
> > > ><mgrigo...@apache.org>
> > > >> wrote:
> > > >>
> > > >> > Same for IRequestHandler#detach()
> > > >> >
> > > >> > Martin Grigorov
> > > >> > Wicket Training and Consulting
> > > >> > https://twitter.com/mtgrigorov
> > > >> >
> > > >> > On Mon, Oct 5, 2015 at 10:42 PM, Martijn Dashorst <
> > > >> > martijn.dasho...@gmail.com> wrote:
> > > >> >
> > > >> > > Should we use an empty default implementation for
IModel#detach?
> > > >> > >
> > > >> > >
> > > >> > > public class IModel extends IDetachable
> > > >> > > {
> > > >> > > ...
> > > >> > >
> > > >> > > @Override
> > > >> > > default void detach()
> > > >> > > {
> > > >> > > }
> > > >> > > }
> > > >> > >
> > > >> > > This won't break existing applications, but might make it a bit
> > > >easier
> > > >> > > on the eyes to implement IModel directly.
> > > >> > >
> > > >> > > I'm not in favor of applying the default method to IDetachable,
> > > >> > > because that would defeat the interface's purpose IMO.
> > > >> > >
> > > >> > > WDYT?
> > > >> > >
> > > >> > > Martijn
> > > >> > >
> > > >> >
> > > >>
> > >
> > > --
> > > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> > > gesendet.
> >
>
Re: [wicket8] Use default method for IModel#detach()?
-0
I see no good reason for IModel to extend from IDetachable. Users should be
able to add this interface at their will.
>If IModel were a @FunctionalInterface, then you wouldn't need something like
a SupplierModel; you could just use a lambda directly:
IModel, as it's now, isn't a functional interface.
>Then maybe just make IModel#setObject() default too ..
There's no default implementation for IModel#setObject(). The one that was
added is as much semantically wrong as to say IModel is a functional
interface.
Proposal:
Why don't we make AbstractReadyOnlyModel the superinterface of IModel
instead of to keep it as an abstract adaptor for IModel? So we would have a
semantically correct functional interface.
Pedro Santos
On Tue, Oct 6, 2015 at 6:42 PM, Martin Grigorov <mgrigo...@apache.org>
wrote:
> Ugh, right!
>
> Then maybe just make IModel#setObject() default too ...
> We will experiment! :)
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Tue, Oct 6, 2015 at 11:27 PM, Michael Mosmann <mich...@mosmann.de>
> wrote:
>
> > .. @IReadOnlyModel: i hope, it will be easier to change then the last
> time
> > i tried it. Watch out for component default model stuff...
> >
> > :)
> >
> > Am 6. Oktober 2015 22:54:37 MESZ, schrieb Martin Grigorov <
> > mgrigo...@apache.org>:
> > >On Tue, Oct 6, 2015 at 10:43 PM, Andrew Geery <andrew.ge...@gmail.com>
> > >wrote:
> > >
> > >> If IModel were a @FunctionalInterface, then you wouldn't need
> > >something
> > >> like a SupplierModel; you could just use a lambda directly:
> > >>
> > >> new Label("label", () -> "The current time is " + LocalDate.now());
> > >>
> > >
> > >This looks good indeed.
> > >It seems we will add IReadOnlyModel soon!
> > >
> > >
> > >>
> > >> And since IModel is Serializable, the lambda will be too, without
> > >having to
> > >> have an artificial interface that is both Serializable & a Supplier.
> > >>
> > >> Thanks
> > >> Andrew
> > >>
> > >> On Tue, Oct 6, 2015 at 4:21 PM, Martin Grigorov
> > ><mgrigo...@apache.org>
> > >> wrote:
> > >>
> > >> > Same for IRequestHandler#detach()
> > >> >
> > >> > Martin Grigorov
> > >> > Wicket Training and Consulting
> > >> > https://twitter.com/mtgrigorov
> > >> >
> > >> > On Mon, Oct 5, 2015 at 10:42 PM, Martijn Dashorst <
> > >> > martijn.dasho...@gmail.com> wrote:
> > >> >
> > >> > > Should we use an empty default implementation for IModel#detach?
> > >> > >
> > >> > >
> > >> > > public class IModel extends IDetachable
> > >> > > {
> > >> > > ...
> > >> > >
> > >> > > @Override
> > >> > > default void detach()
> > >> > > {
> > >> > > }
> > >> > > }
> > >> > >
> > >> > > This won't break existing applications, but might make it a bit
> > >easier
> > >> > > on the eyes to implement IModel directly.
> > >> > >
> > >> > > I'm not in favor of applying the default method to IDetachable,
> > >> > > because that would defeat the interface's purpose IMO.
> > >> > >
> > >> > > WDYT?
> > >> > >
> > >> > > Martijn
> > >> > >
> > >> >
> > >>
> >
> > --
> > Diese Nachricht wurde von meinem Android-Mobiltelefon mit K-9 Mail
> > gesendet.
>
Re: [VOTE] Release Apache Wicket 8.0.0-M5
+1 built locally and ran wicket-examples. I noticed the error while starting the jetty server: ERROR - servletJetty - WELD-ENV-001202: Unable to create JettyWeldInjector. CDI injection will not be available in Servlets, Filters or Listeners. but the CDI example is working fine since we aren't injecting managed beans in JEE types cheers Pedro Santos On Sat, Mar 25, 2017 at 5:35 PM, Tobias Soloschenko < tobiassolosche...@googlemail.com> wrote: > +1 > > kind regards > > Tobias > > > Am 25.03.2017 um 16:32 schrieb Andrea Del Bene <an.delb...@gmail.com>: > > > > This is a vote to release Apache Wicket 8.0.0-M5 > > > > Please download the source distributions found in our staging area > > linked below. > > > > I have included the signatures for both the source archives. This vote > > lasts for 72 hours minimum. > > > > [ ] Yes, release Apache Wicket 8.0.0-M5 > > [ ] No, don't release Apache Wicket 8.0.0-M5, because ... > > > > Distributions, changelog, keys and signatures can be found at: > > > >https://dist.apache.org/repos/dist/dev/wicket/8.0.0-M5 > > > > Staging repository: > > > > https://repository.apache.org/content/repositories/orgapachewicket-1084 > > > > The binaries are available in the above link, as are a staging > > repository for Maven. Typically the vote is on the source, but should > > you find a problem with one of the binaries, please let me know, I can > > re-roll them some way or the other. > > > > Staging git repository data: > > > >Repository: g...@github.com:bitstorm/wicket.git > >Branch: build/wicket-8.0.0-M5 > >Release tag: rel/wicket-8.0.0-M5 > > > > > > > > > >The signatures for the source release artefacts: > > > > > > Signature for apache-wicket-8.0.0-M5.zip: > > > >-BEGIN PGP SIGNATURE- > > Version: GnuPG v1 > > > > iQIcBAABAgAGBQJY1oVeAAoJEAzCjx+CMhBVplUP/18Y2qXGdgnsMhn3j7T2yEuS > > uzgxs8ZlMBG+OzMp+b/Sewocppfcc5uWEinMfLWcjU0Gplk9y9fqC+IhUreWbI/Y > > VSnykzwkYWzbxL975bgXBimiindcOLBf5VAnaw5DaN5I8o2csa6Na8WQvhTjIV87 > > 9/8unxIIoJvmPt/eqXms/xVZwC52ggbYNsRExRa+bfFqaHPH0udfvBUkYW5jdK5y > > PiBFFF1H3P9SFDnVezp++7h7uZBNg2trfZUhxDUUNxu169hUqpCYEmWXE/Suby1c > > 1vBVWzaICJf+cStSVD8LRibLD8yp4UriyeQj5yD9puA4HpoONdOkb0+9EtBrr6U9 > > 7JC0s3sUP8WPqYawPRW7FWa+Lkfm4YHyKp0N4uwP4Q5i4FQQOJcGKQCJGxp92cqC > > b0Ww2xjgJi+z24mDq9r3lICiL3IAbYe9gbFKm6c2S9wvtaeyUTF4Zi+Cgk1zk/qR > > 34MMXqD1wY4HxEriBsHA94WROCMlKVRXIc41NZE/ZNxdiXqTHaNEctWo88V9EElx > > t7ov/uwKVlMvFxMBOYFr9p/FAjH50zWTbx/asV/Fz0NdWDE79++Bd2OnUahFB9wh > > wXFZDo6iB7s6zh08hK68TTRGdDrZ7BGIgBMHR40tAqiJML6821hcKaNfpdemqptv > > SBxLZI3zI4Fc81w7jnrv > > =gYYk > > -END PGP SIGNATURE- > > > > Signature for apache-wicket-8.0.0-M5.tar.gz: > > > >-BEGIN PGP SIGNATURE- > > Version: GnuPG v1 > > > > iQIcBAABAgAGBQJY1oVeAAoJEAzCjx+CMhBVK2wP+gM11Ve4SKnavA+VH0w9u1HK > > kKFHMx+nMX2uQ9lsSwbR9D0Ql0v03lctlMsr8LnzNTazZPiLrcilFKGrzlGZOAx8 > > XXu1+9oPKPAUTvrpvXUmKXSqsm5XLuC74OP2w3rwV82hnIfs/CKs32X1hBRe1c+u > > S+EtBWZSJKI8qAOdZEq+ZvoVGEeUGFosPhfF98rOkleUXP9LfSppYwlHO1/8s9PE > > 3Fl1CR9smDRfNOhVwv2GvlfrH8D4bF31doQUZ2yxdWlnKRYOp1gVzUf91jZ2V2kv > > oUFQb673qP3TptyH6AwFjuZ8WHXpsbo2BAXtCKCP+6cqGczKZ+ntv2IKiVQwr1lX > > LTfUey+ZXfVWq/xkF3SCTzO7BFEp91mupqWljR/YPs3zhOT5dyGArX0XcbRiz+rZ > > yETYFlw9mmpwrZkjudfyfgZic2pcesUZOgwnq0F/BW5vuVYgFCWRFOvKChAM2G8v > > Rcsh2rV/T2/U+pIbqwCPcgOSN1OUZ4siUGSKC1ELSdIcCtfqgP3rft9tvZbmWIiv > > sGFJwZBLDIOqWzeyLxE5QvWtR9aIybqE9mJ4Y9Y2PPNJfNJsn1s/pD5qnvO3d6Ym > > +7LztPmkS4OQeVHqY9e9EnCdd9ndTe0aLHzU3kZ51oTRPwLLb6Wztxily0V15PII > > kN/0C0NMZ6Sy0Q5QgynI > > =ci2t > > -END PGP SIGNATURE- > > > > > > > >CHANGELOG for 8.0.0-M5: > > > > > > ** Bug > > > >* [WICKET-6317] - AuthenticatedWebSession#signOut() calls twice > after session invalidation > >* [WICKET-6319] - AutoCompleteTextField: popup is hidden when > clicking on scrollbar in IE > >* [WICKET-6329] - org.json migration issue > >* [WICKET-6337] - Wrong class type in PageAccessSynchronizer > >* [WICKET-6340] - The Ajax reponse of an AjaxSubmitButton creates > invalid XHTML markup for multipart forms > >* [WICKET-6342] - Wrong baseUrl in BaseWebSocketBehavior > > > > ** Improvement > > > >* [WICKET-6212] - CheckChoice / add a getAdditi
Moving property resolver to a configurable option at the applicaiton
Hi team, I moved the current property expression resolution logic to OGNLPropertyExpressionResolver and made it a configurable option at the application, so we have a room for new property expression resolvers like the one using a parser. I also made some code cleanup like removing IPropertyReflectionAwareModel and moved some methods with no internal state their own utility class so they can be used by anyone needing to get the same class metadata via reflection. The work is just in its initial state, but I pushed it anyway to share my idea and to get your input on it. You can check it at the branch "WICKET-6318-configurable-property-expression-resolver" and I add more detailed description of the changes at the ticket WICKET-6318 Cheers Pedro Santos 1 - https://github.com/apache/wicket/tree/WICKET-6318-configurable-property-expression-resolver 2 - https://issues.apache.org/jira/browse/WICKET-6318
Re: What else do we want to do before 8.0.0 final ?
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 <mgrigo...@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 <solomax...@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 <pedros...@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 <mgrigo...@apache.org> >> wrote: >> >> Hi Pedro, >> >> >> >> On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pedros...@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 repo
Re: [VOTE] Release Apache Wicket 8.0.0-M4
+1 to release. Built the branch locally and runned wicket-examples. Only I think your public key used to sign the release is missing on Wicket's keys file at http://archive.apache.org/dist/wicket/KEYS Cheers Pedro Santos On Sun, Feb 5, 2017 at 12:35 PM, Andrea Del Bene <an.delb...@gmail.com> wrote: > +1 to release > > On 5 Feb 2017 12:16, "Sebastien" <seb...@gmail.com> wrote: > >> [x] Yes, release Apache Wicket 8.0.0-M4 >> >> Thanks Andrea! >> >> >> On Fri, Feb 3, 2017 at 10:56 PM, Andrea Del Bene <an.delb...@gmail.com> >> wrote: >> >> > This is a vote to release Apache Wicket 8.0.0-M4 >> > >> > Please download the source distributions found in our staging area >> > linked below. >> > >> > I have included the signatures for both the source archives. This vote >> > lasts for 72 hours minimum. >> > >> > [ ] Yes, release Apache Wicket 8.0.0-M4 >> > [ ] No, don't release Apache Wicket 8.0.0-M4, because ... >> > >> > Distributions, changelog, keys and signatures can be found at: >> > >> > https://dist.apache.org/repos/dist/dev/wicket/8.0.0-M4 >> > >> > Staging repository: >> > >> > >> > https://repository.apache.org/content/repositories/orgapachewicket-1083/ >> > >> > The binaries are available in the above link, as are a staging >> > repository for Maven. Typically the vote is on the source, but should >> > you find a problem with one of the binaries, please let me know, I can >> > re-roll them some way or the other. >> > >> > Staging git repository data: >> > >> > Repository: g...@github.com:bitstorm/wicket.git >> > Branch: build/wicket-8.0.0-M4 >> > Release tag: rel/wicket-8.0.0-M4 >> > >> > >> > >> > >> > The signatures for the source release artefacts: >> > >> > >> > Signature for apache-wicket-8.0.0-M4.zip: >> > >> > -BEGIN PGP SIGNATURE- >> > Version: GnuPG v1 >> > >> > iQIcBAABAgAGBQJYlPh/AAoJEAzCjx+CMhBVtxUP/izBwSXEepYpZ0sy5doD+e4r >> > m2S9cMvOgrYLCIyKrPTm8v64ltmQUVnzN+06THhLhLdHjpmquYQzC48wZzfCMlrw >> > Ev16DCOniQezMqsvFjlJXqNgBwZo+pRHgDif856BknqxvjmVmD6bCLkgpJDdAJt4 >> > EakVaLhNMV6ZcXcFRREGVgMRCmVcuzRub7A/xsNf8mMWthw+ykybjngw2TU/CxiP >> > LQAK2tfoJ/bAnpWb3nz89Z80PQCLg2QYpdQOZCfxqKgf7ASHicFbY8BM0Niy1ZI5 >> > 0peUT6CHgKE7ah2Sf1xuT/tQk8IAP74PW+6Od0lrpqEds8JzwMtqgIEHmDHhQ1ri >> > /v4U5nyBYdXOQtFBHogjcUhWlQj5LPjE0Qje/PbxQFyQeD8S4+rqaScLHKnaUrMu >> > xdQMenn/gnAUJsRXesND/RcWHk1d8Kcopk2ZhTpQJmk1R5eGR0GJ5gsdMHmfvORi >> > EKZtDfgoWTYjYRKL9dyVDXLDdj9OXERZKTkKXLSSgPuUcmU6hMFWzxaiUoLS2zwh >> > g9t+KUVUVOCp/Pi1qJbUNOnnadUGB56hxwhj0H2mvnXrkI82f8+vcJyRf0Ro3ZY1 >> > /IZ1rkyW558ikZ+qpHfOSMSKxwUezj0lIktYohK+MiTUJCADRObdUSM3Huz2Q0Gx >> > ov6tXqisp3fSsea6ptvi >> > =7Tck >> > -END PGP SIGNATURE- >> > >> > Signature for apache-wicket-8.0.0-M4.tar.gz: >> > >> > -BEGIN PGP SIGNATURE- >> > Version: GnuPG v1 >> > >> > iQIcBAABAgAGBQJYlPh/AAoJEAzCjx+CMhBVdUcQAJ8EruKrRhTA27n3XAtXFZ3f >> > UmeSlnOYiG4xkISHJjQzwx5Uc+i4H2b8M2bguEjGtE2z3SJ4SoP1GGyEC7aXHrkA >> > ToI7yNGp+I4EnUbQ3K7FUukOcoVoj0TJ2NQIz0kl8/37+mHOsytS0O0G5hvVYi3p >> > O9b84EoPPxryaEHSlMMaoADZqd67VQdj+D2eu/X8fgcHKxGWQ2oK92lAi0C/8f8K >> > m0fTfVI1H0GpsTGYqbRj8BzLRjfuCfN4gRsKgvDxC7uO4IYaWlLuoHfA9Yjgv8l8 >> > tLHK7rKVy1KLCIquo8RQdl3qZptCUS78axZrblY9WI0sH+9KQ80LL0/8gooBxKGe >> > jK7/0I29qOo0MdswIgTSCZuFyHtapJ+qOqvGOStDvo3tuJ1Vk9q36YdeWX6V6/DT >> > qdn60/FLONg18Ycr6lwuVvuvpOoMMOLnln9v7mkUCvOv2hGjsgsWDOMg9oLAeTMy >> > N15j3ItzfcLtw2av/1st7EFFgayRxTWK2/LfGe1WYspOazBZEldhNPrioDyPJ/ai >> > WioyAqzaBQBuvCdXFrwdc1hvbU41EzBVX/dDheTnS0U8U5TUC3ctHuPg86cU4Yoq >> > jO0X27f+8MPtzbhIVaGYsMsyW90wbpMMNYxV5gk+7FqTO9QUZOcEPhCVRReUGWhg >> > vQE8t5096d+rtjbXo7Fl >> > =oUy1 >> > -END PGP SIGNATURE- >> > >> > >> > >> > CHANGELOG for 8.0.0-M4: >> > >> > ** Bug >> > >> > * [WICKET-6165] - Inconsistent behavior of Markupstream.hasMore vs. >> > MarkupStream.next. >> > * [WICKET-6288] - StatelessLink not working >> > * [WICKET-6303] - renderHead method of a Behavior added to a Border >> > body is not called
PageProvider improvement proposal
Hi team, I worked on the ticket WICKET-4201 [1] proposing an improved PageProvider implementation and API. The improvement is at the branch [2] "WICKET-4201-improved-page-provider" and I added more details in the ticket. Just cross-referencing here as it would be great to get your input. Cheers Pedro Santos 1 - https://issues.apache.org/jira/browse/WICKET-4201 2 - https://github.com/apache/wicket/tree/WICKET-4201-improved-page-provider
Re: buildbot failure in on wicket-branch-6.x
I compared the failing log [2] with the last successful one [1] and it
looks we are getting an error at the line
"(function(){xyz.foo.event.triggerQueue( 'postupdate' )})();" for a
while, but this time it counted as a failed assertion. I'm not
familiar with the frontend plugin, can someone help to fix the 6.x
build?
Cheers
1 -
https://ci.apache.org/builders/wicket-branch-6.x/builds/206/steps/compile/logs/stdio
2 -
https://ci.apache.org/builders/wicket-branch-6.x/builds/207/steps/compile/logs/stdio
Pedro Santos
On Fri, Feb 3, 2017 at 1:23 AM, <build...@apache.org> wrote:
> The Buildbot has detected a new failure on builder wicket-branch-6.x while
> building wicket. Full details are available at:
> https://ci.apache.org/builders/wicket-branch-6.x/builds/207
>
> Buildbot URL: https://ci.apache.org/
>
> Buildslave for this Build: bb_slave1_ubuntu
>
> Build Reason: The SingleBranchScheduler scheduler named
> 'on-wicket-branch-6.x-commit' triggered this build
> Build Source Stamp: [branch wicket-6.x]
> 3ac7cfcc9842c80caf9683a02efafd8a2732ec4b
> Blamelist: Pedro Henrique Oliveira dos Santos <pe...@apache.org>
>
> BUILD FAILED: failed compile
>
> Sincerely,
> -The Buildbot
>
>
>
Re: What else do we want to do before 8.0.0 final ?
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 <mgrigo...@apache.org> wrote: > Hi Pedro, > > On Tue, Jan 31, 2017 at 3:14 PM, Pedro Santos <pedros...@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 <mgrigo...@apache.org> >> wrote: >> > Hi Pedro, >> > >> > On Tue, Jan 31, 2017 at 10:25 AM, Pedro Sa
Re: What else do we want to do before 8.0.0 final ?
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 <s...@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 <pedros...@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
Re: What else do we want to do before 8.0.0 final ?
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 <mgrigo...@apache.org> wrote: > Hi Pedro, > > On Tue, Jan 31, 2017 at 10:25 AM, Pedro Santos <pedros...@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 <mgrigo...@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 <mgrigo...@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 <pedros...@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 <mgrigo...@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) >>
Re: What else do we want to do before 8.0.0 final ?
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 <mgrigo...@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 <mgrigo...@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 <pedros...@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 <mgrigo...@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 <s...@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.delb...@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.delb...@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 >>>
Re: [VOTE] Release Apache Wicket 6.26.0
Oh, you are right. I double checked and I indeed had Java 1.6 / toolchains configured here (had it set for another project in the past). Cheers On Jan 2, 2017 7:19 AM, "Andrea Del Bene" <an.delb...@gmail.com> wrote: Hi, I've updated the Clirr plugin because I use to work with java 8 for Maven and toolchains properly configured to find suitable jdk for 6.x and 7.x branches. So in short, this build has actually been done with java 6. Andrea. On 02/01/2017 04:58, Pedro Santos wrote: > Hi Andrea, > > Couldn't build using java 1.6 because of the Clirr plugin update. > Using java 1.7 it's all fine, I built the branch and tested some > random pages in wicket-examples. > > If to build with 1.6 is not a requirement, +1 > > cheers > Pedro Santos > > > On Sat, Dec 31, 2016 at 4:04 PM, Andrea Del Bene <an.delb...@gmail.com> > wrote: > >> +1 to release. Tested ajax examples and some other random examples. >> >> >> >> On 28/12/2016 18:20, Andrea Del Bene wrote: >> >>> This is a vote to release Apache Wicket 6.26.0 >>> >>> Please download the source distributions found in our staging area >>> linked below. >>> >>> I have included the signatures for both the source archives. This vote >>> lasts for 72 hours minimum. >>> >>> [ ] Yes, release Apache Wicket 6.26.0 >>> [ ] No, don't release Apache Wicket 6.26.0, because ... >>> >>> Distributions, changelog, keys and signatures can be found at: >>> >>> https://dist.apache.org/repos/dist/dev/wicket/6.26.0 >>> >>> Staging repository: >>> >>> https://repository.apache.org/content/repositories/orgapachewicket-1082/ >>> >>> The binaries are available in the above link, as are a staging >>> repository for Maven. Typically the vote is on the source, but should >>> you find a problem with one of the binaries, please let me know, I can >>> re-roll them some way or the other. >>> >>> Staging git repository data: >>> >>> Repository: g...@github.com:bitstorm/wicket.git >>> Branch: build/wicket-6.26.0 >>> Release tag: rel/wicket-6.26.0 >>> >>> >>> >>> >>> The signatures for the source release artefacts: >>> >>> >>> Signature for apache-wicket-6.26.0.zip: >>> >>> -BEGIN PGP SIGNATURE- >>> Version: GnuPG v1 >>> >>> iQIcBAABAgAGBQJYY/F4AAoJEAzCjx+CMhBVPk0QAILzw08Gd3xHoVnpco916yJ5 >>> fpBMqZ6e3NfZV/hQONBknRvNSABayJn6xmQWUd/qCQLbzE3RwVxim28lPVGHOPru >>> CR0ycjetLoBdZPyXc42n0KcrOvsvvbAr8d0uBHSKxYtjTRkMxILY6rJMSkAwLdnl >>> xzvGN9VMP4icmvmt6Ut///YBBDwXsgNSO7DL9AF6T9ZJ7aou+Y2FfERz9OQz76NQ >>> Bche7TyXrPfvt7AHnWWGft/DrIi3t5MNXniixzEsW2rZJajIwwzRiwDv4jBCwMjy >>> V0vQiyWgZ8PEVouzlwN9KsXqFNnpR6oTU+1KOzODIqTKwFR4TQrydNyq2r54pO6J >>> UTA2ZydIv8yvM+dHSe0LZaZEl9oiGd7uJXa6URbIs0ZxWttoN3t2HS5hu4XkvlKz >>> 2RX97HrxI9cy8j7xKfv/rQzee1Ja/0QLjOaXOwmj2qn+BiZzD8HxORrPLbIbVHW7 >>> Zt+FfnZSp2Da57Y4EUcaaDUzrSElb2Usruphvd8vE7LejlBU8urj869GuQ2017J7 >>> 2yBIvOgUtF60ZJTty2AB2dumkMsysnZ8o93kjl4hn75MgzC0v2QP8h1Y9LT6ke6Z >>> 0W0hTrpt17GerlAzNxx33o0RyZiS+wvnqNnn06wepTvOQmsPoKPhjVYG+AO0pkoA >>> lmCWlFL2QKAldUCR9iw6 >>> =8P9f >>> -END PGP SIGNATURE- >>> >>> Signature for apache-wicket-6.26.0.tar.gz: >>> >>> -BEGIN PGP SIGNATURE- >>> Version: GnuPG v1 >>> >>> iQIcBAABAgAGBQJYY/F4AAoJEAzCjx+CMhBVACkP/j9qo36wJGT3HK6XkgrG0BgA >>> 2Z1UNKyMXIV8CQrHyK89Rm7ZFN0y4KTWYNHRC8nxlToZIE4+DzArM8DjItl5sGLC >>> CMxOo6PVXQsHjKTsJgrc9qQMZVc7gEgQZ7SoiMBydG6GDRmcGBcPT6Bo1LWvbclw >>> pe4Saj+L5MhUcnYNSNXUuYKwmncZZvCOQuDtX2fKHFjgGBdzdpkW3btnqDjCkxda >>> 6YZE9f/AJgI3o3z5I+TZ5Dz/iRiCJjeSvUj4OVR7J3EdEXs4YzSc02Vo7RUmvN6J >>> zRkUBQhYcXS9j7ZcLHt5zdLMk8kRnopvzSkZzywnnuFX6iYWioIgu6Pi4q1ECzWQ >>> WyN8pturMjkM7PgMNuzvRLjTysZviq/HY8EG+CpPNwYZbRG4GBj+tQFo9vFP6RoS >>> j96gZjHRVfPvwNGMBSPatx9OCXMMm3u2Nt11QAte0OOuH3pqIiQcelL/ALmZlUEE >>> Y3VvF0xXqyhltNxgD1/bIcNEcTZyjoPhm3rZASRyg4Q2622KugFwX0p+bkcuz3gL >>> dOxBo7kHZ8tPXTEtx+F7bYq6l5XOO0po1llUAoi8ZOVZPlUGJz6IVYryocZ5asnJ >>> xgZd+RX2SEMtuejAH6f7aojBKOa3cQ4xf1CKbvdDF8k+OtN2SztI9fqZwqO7QCjt >>> AsXFCWmef6o87oikYsEY >>> =JLkI >>> -END PGP SIGNATURE- >>> >>> >>> >>> CHANGELOG for 6.26.0: &g
Re: [VOTE] Release Apache Wicket 6.26.0
Hi Andrea, Couldn't build using java 1.6 because of the Clirr plugin update. Using java 1.7 it's all fine, I built the branch and tested some random pages in wicket-examples. If to build with 1.6 is not a requirement, +1 cheers Pedro Santos On Sat, Dec 31, 2016 at 4:04 PM, Andrea Del Bene <an.delb...@gmail.com> wrote: > +1 to release. Tested ajax examples and some other random examples. > > > > On 28/12/2016 18:20, Andrea Del Bene wrote: >> >> This is a vote to release Apache Wicket 6.26.0 >> >> Please download the source distributions found in our staging area >> linked below. >> >> I have included the signatures for both the source archives. This vote >> lasts for 72 hours minimum. >> >> [ ] Yes, release Apache Wicket 6.26.0 >> [ ] No, don't release Apache Wicket 6.26.0, because ... >> >> Distributions, changelog, keys and signatures can be found at: >> >> https://dist.apache.org/repos/dist/dev/wicket/6.26.0 >> >> Staging repository: >> >> https://repository.apache.org/content/repositories/orgapachewicket-1082/ >> >> The binaries are available in the above link, as are a staging >> repository for Maven. Typically the vote is on the source, but should >> you find a problem with one of the binaries, please let me know, I can >> re-roll them some way or the other. >> >> Staging git repository data: >> >> Repository: g...@github.com:bitstorm/wicket.git >> Branch: build/wicket-6.26.0 >> Release tag: rel/wicket-6.26.0 >> >> >> >> >> The signatures for the source release artefacts: >> >> >> Signature for apache-wicket-6.26.0.zip: >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1 >> >> iQIcBAABAgAGBQJYY/F4AAoJEAzCjx+CMhBVPk0QAILzw08Gd3xHoVnpco916yJ5 >> fpBMqZ6e3NfZV/hQONBknRvNSABayJn6xmQWUd/qCQLbzE3RwVxim28lPVGHOPru >> CR0ycjetLoBdZPyXc42n0KcrOvsvvbAr8d0uBHSKxYtjTRkMxILY6rJMSkAwLdnl >> xzvGN9VMP4icmvmt6Ut///YBBDwXsgNSO7DL9AF6T9ZJ7aou+Y2FfERz9OQz76NQ >> Bche7TyXrPfvt7AHnWWGft/DrIi3t5MNXniixzEsW2rZJajIwwzRiwDv4jBCwMjy >> V0vQiyWgZ8PEVouzlwN9KsXqFNnpR6oTU+1KOzODIqTKwFR4TQrydNyq2r54pO6J >> UTA2ZydIv8yvM+dHSe0LZaZEl9oiGd7uJXa6URbIs0ZxWttoN3t2HS5hu4XkvlKz >> 2RX97HrxI9cy8j7xKfv/rQzee1Ja/0QLjOaXOwmj2qn+BiZzD8HxORrPLbIbVHW7 >> Zt+FfnZSp2Da57Y4EUcaaDUzrSElb2Usruphvd8vE7LejlBU8urj869GuQ2017J7 >> 2yBIvOgUtF60ZJTty2AB2dumkMsysnZ8o93kjl4hn75MgzC0v2QP8h1Y9LT6ke6Z >> 0W0hTrpt17GerlAzNxx33o0RyZiS+wvnqNnn06wepTvOQmsPoKPhjVYG+AO0pkoA >> lmCWlFL2QKAldUCR9iw6 >> =8P9f >> -END PGP SIGNATURE- >> >> Signature for apache-wicket-6.26.0.tar.gz: >> >> -BEGIN PGP SIGNATURE- >> Version: GnuPG v1 >> >> iQIcBAABAgAGBQJYY/F4AAoJEAzCjx+CMhBVACkP/j9qo36wJGT3HK6XkgrG0BgA >> 2Z1UNKyMXIV8CQrHyK89Rm7ZFN0y4KTWYNHRC8nxlToZIE4+DzArM8DjItl5sGLC >> CMxOo6PVXQsHjKTsJgrc9qQMZVc7gEgQZ7SoiMBydG6GDRmcGBcPT6Bo1LWvbclw >> pe4Saj+L5MhUcnYNSNXUuYKwmncZZvCOQuDtX2fKHFjgGBdzdpkW3btnqDjCkxda >> 6YZE9f/AJgI3o3z5I+TZ5Dz/iRiCJjeSvUj4OVR7J3EdEXs4YzSc02Vo7RUmvN6J >> zRkUBQhYcXS9j7ZcLHt5zdLMk8kRnopvzSkZzywnnuFX6iYWioIgu6Pi4q1ECzWQ >> WyN8pturMjkM7PgMNuzvRLjTysZviq/HY8EG+CpPNwYZbRG4GBj+tQFo9vFP6RoS >> j96gZjHRVfPvwNGMBSPatx9OCXMMm3u2Nt11QAte0OOuH3pqIiQcelL/ALmZlUEE >> Y3VvF0xXqyhltNxgD1/bIcNEcTZyjoPhm3rZASRyg4Q2622KugFwX0p+bkcuz3gL >> dOxBo7kHZ8tPXTEtx+F7bYq6l5XOO0po1llUAoi8ZOVZPlUGJz6IVYryocZ5asnJ >> xgZd+RX2SEMtuejAH6f7aojBKOa3cQ4xf1CKbvdDF8k+OtN2SztI9fqZwqO7QCjt >> AsXFCWmef6o87oikYsEY >> =JLkI >> -END PGP SIGNATURE- >> >> >> >> CHANGELOG for 6.26.0: >> >> ** Sub-task >> >> * [WICKET-6278] - Backport TagTester fix to 6.x and 7.x >> >> ** Bug >> >> * [WICKET-6250] - FileUploadField does not deteach models and fails to >> null the reference to the transient fileUploads field if >> forceCloseStreamsOnDetach is false >> * [WICKET-6267] - Native Websocket exception when the page is expired >> * [WICKET-6270] - No upload is seen as empty upload after WICKET-6210 >> * [WICKET-6279] - AttributeModifier.VALUELESS_ATTRIBUTE_REMOVE does >> not work after deserialisation >> * [WICKET-6289] - Autolinking adds onclick attribute to tags >> * [WICKET-6290] - CssUrlReplacer doesn't understand data: urls and >> breaks them >> * [WICKET-6295] - Clicking Link in BrowserInfoPage results in infinite >> request loop >> * [WICKET
Re: Christmas / new year [NON-BIZ]
Thank you! Feliz ano novo! (portuguese :) Cheers Pedro Santos Pedro Santos On Sat, Dec 24, 2016 at 9:33 AM, Tobias Soloschenko <tobiassolosche...@googlemail.com> wrote: > Hi all, > > I wish you a merry christmas and happy new year. :-) > > kind regards > > Tobias > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org >
[ANNOUNCE] CVE-2016-6793 Apache Wicket deserialization vulnerability
CVE-2016-6793: Apache Wicket deserialization vulnerability Severity: Low Vendor: The Apache Software Foundation Versions Affected: Apache Wicket 6.x and 1.5.x Description: Depending on the ISerializer set in the Wicket application, it's possible that a Wicket's object deserialized from an untrusted source and utilized by the application to causes the code to enter in an infinite loop. Specifically, Wicket's DiskFileItem class, serialized by Kryo, allows an attacker to hack its serialized form to put a client on an infinite loop if the client attempts to write on the DeferredFileOutputStream attribute. Mitigation: Upgrade to Apache Wicket 6.25.0 or 1.5.17 Credit: This issue was discovered by Jacob Baines, Tenable Network Security and Pedro Santos References: https://wicket.apache.org/news
Re: What else do we want to do before 8.0.0 final ?
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 <mgrigo...@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 <s...@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.delb...@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.delb...@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: [Vote] Release Apache Wicket 1.5.17
[ X ] Yes, release Apache Wicket 1.5.17 We have 3 votes approving the release, the vote passes! Will complete the release. Pedro Santos On Mon, Oct 31, 2016 at 9:48 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > [ X ] Yes, release Apache Wicket 1.5.17 > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Fri, Oct 28, 2016 at 8:17 PM, Pedro Santos <pe...@apache.org> wrote: > > > This is a vote to release Apache Wicket 1.5.17 > > > > [ ] Yes, release Apache Wicket 1.5.17 > > [ ] No, don't release Apache Wicket 1.5.17, because ... > > > > Distributions, changelog, keys and signatures can be found at: > > > > https://dist.apache.org/repos/dist/dev/wicket/1.5.17 > > > > Staging repository: > > > > https://repository.apache.org/content/repositories/ > > orgapachewicket-1078/ > > > > Staging git repository data: > > > > Repository: g...@github.com:pedrosans/wicket.git > > Branch: build/wicket-1.5.17 > > > > This vote lasts for 72 hours minimum. Please test the release and offer > > your vote. > > > > The Wicket team! > > >
Re: What else do we want to do before 8.0.0 final ?
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 <mgrigo...@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 >
[Vote] Release Apache Wicket 1.5.17
This is a vote to release Apache Wicket 1.5.17 [ ] Yes, release Apache Wicket 1.5.17 [ ] No, don't release Apache Wicket 1.5.17, because ... Distributions, changelog, keys and signatures can be found at: https://dist.apache.org/repos/dist/dev/wicket/1.5.17 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-1078/ Staging git repository data: Repository: g...@github.com:pedrosans/wicket.git Branch: build/wicket-1.5.17 This vote lasts for 72 hours minimum. Please test the release and offer your vote. The Wicket team!
Re: [VOTE] Release Apache Wicket 6.25.0 take 2
[ X ] Yes, release Apache Wicket 6.25.0 Pedro Santos On Mon, Oct 24, 2016 at 5:42 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > [ X ] Yes, release Apache Wicket 6.25.0 > > Tested local build + ramdom examples > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Oct 19, 2016 at 10:04 PM, Martijn Dashorst < > martijn.dasho...@gmail.com> wrote: > > > This is a vote to release Apache Wicket 6.25.0, take 2 > > > > Please download the source distributions found in our staging area > > linked below. > > > > I have included the signatures for both the source archives. This vote > > lasts for 72 hours minimum. > > > > [ ] Yes, release Apache Wicket 6.25.0 > > [ ] No, don't release Apache Wicket 6.25.0, because ... > > > > Distributions, changelog, keys and signatures can be found at: > > > > https://dist.apache.org/repos/dist/dev/wicket/6.25.0 > > > > Staging repository: > > > > https://repository.apache.org/content/repositories/ > > orgapachewicket-1077/ > > > > The binaries are available in the above link, as are a staging > > repository for Maven. Typically the vote is on the source, but should > > you find a problem with one of the binaries, please let me know, I can > > re-roll them some way or the other. > > > > Staging git repository data: > > > > Repository: g...@github.com:dashorst/wicket.git > > Branch: build/wicket-6.25.0 > > Release tag: rel/wicket-6.25.0 > > > > > > > > > > The signatures for the source release artefacts: > > > > > > Signature for apache-wicket-6.25.0.zip: > > > > -BEGIN PGP SIGNATURE- > > Comment: GPGTools - https://gpgtools.org > > > > iEYEABECAAYFAlgH0UkACgkQJBX8W/xy/UXmgQCfUwVfCDkCU1ZNdFnf32HSeUs4 > > tFYAoJYkHA4eO4IvKeq8OIV19MBTNdvL > > =qs0y > > -END PGP SIGNATURE- > > > > Signature for apache-wicket-6.25.0.tar.gz: > > > > -BEGIN PGP SIGNATURE- > > Comment: GPGTools - https://gpgtools.org > > > > iEYEABECAAYFAlgH0UkACgkQJBX8W/xy/UXO/QCgs4t/TD3K7XQWmOi0Q0BHYUY4 > > o3MAoKiK1OWSjev2vG9T0xH9j7/QkQ48 > > =bH45 > > -END PGP SIGNATURE- > > > > > > > > CHANGELOG for 6.25.0: > > > > ** Sub-task > > > > * [WICKET-6218] - backport fix for WICKET-6172 to Wicket 6.x > > > > ** Bug > > > > * [WICKET-5972] - Datepicker "Close" text overlays 'x' icon. > > * [WICKET-6136] - AutoCompleteTextField issue in Android 5.1.1 > > * [WICKET-6209] - requesting focus on disabled field fails with error > > in IE8 > > * [WICKET-6214] - ModalWindow broken on IE > > * [WICKET-6219] - Fragment fails to report an error in development > mode > > * [WICKET-6225] - Button wrongly sets its model object as 'value' > > attribute > > * [WICKET-6227] - CharSequenceResource calculates wrong length > > when there are unicode symbols > > * [WICKET-6230] - Infinite redirection when using > > UrlPathPageParametersEncoder > > * [WICKET-6232] - When sending binary data from server to client, > > wicket-websocket-jquery.js throws error "message.indexOf is not a > > function" > > * [WICKET-6235] - TableTree#updateNode() fails if no corresponding > > node is visible > > * [WICKET-6236] - Files.remove() causes a 5 seconds delay instead > > of 500ms as was intended > > * [WICKET-6237] - PageRequestHandlerTracker doesn't work with > > IRequestHandlerDelegate > > * [WICKET-6245] - Open up CsrfPreventionRequestCycleListener for > > extension > > * [WICKET-6246] - WebSocket request while Ajax request leads to > > error regarding HtmlHeaderCotnainer > > > > ** Improvement > > > > * [WICKET-6206] - Allow to use custom anticache parameter value > > for Image component > > * [WICKET-6210] - FileUpload does not support files of zero size > > * [WICKET-6226] - DOCTYPE URL in properties.xml example in wicket > > documentation won't work. > > * [WICKET-6233] - Add component info in the error messages related > > to WicketTester#assertComponentOnAjaxResponse() > > * [WICKET-6234] - Log the decrypted url in CryptoMapper for > > debugging purposes > > * [WICKET-6239] - Use Response#addHeader() instead of > > #setContentLength() > > >
Re: [VOTE] Release Apache Wicket 7.5.0
+1, thanks Martijn Pedro Santos On Fri, Oct 21, 2016 at 9:26 AM, Jonas <barney...@gmail.com> wrote: > [X] Yes, release Apache Wicket 7.5.0 (non-binding) > [ ] No, don't release Apache Wicket 7.5.0, because ... > > Tested our main webapp - works fine. > > cheers, > Jonas > > > > On Wed, Oct 19, 2016 at 9:28 PM, Martijn Dashorst < > martijn.dasho...@gmail.com> wrote: > > > This is a vote to release Apache Wicket 7.5.0 > > > > Please download the source distributions found in our staging area > > linked below. > > > > I have included the signatures for both the source archives. This vote > > lasts for 72 hours minimum. > > > > [ ] Yes, release Apache Wicket 7.5.0 > > [ ] No, don't release Apache Wicket 7.5.0, because ... > > > > Distributions, changelog, keys and signatures can be found at: > > > > https://dist.apache.org/repos/dist/dev/wicket/7.5.0 > > > > Staging repository: > > > > https://repository.apache.org/content/repositories/ > > orgapachewicket-1075/ > > > > The binaries are available in the above link, as are a staging > > repository for Maven. Typically the vote is on the source, but should > > you find a problem with one of the binaries, please let me know, I can > > re-roll them some way or the other. > > > > Staging git repository data: > > > > Repository: g...@github.com:dashorst/wicket.git > > Branch: build/wicket-7.5.0 > > Release tag: rel/wicket-7.5.0 > > > > > > > > > > The signatures for the source release artefacts: > > > > > > Signature for apache-wicket-7.5.0.zip: > > > > -BEGIN PGP SIGNATURE- > > Comment: GPGTools - https://gpgtools.org > > > > iEYEABECAAYFAlgHyLgACgkQJBX8W/xy/UVtJQCfazMNKzMMG5y+GTnCNg0YloBB > > IB0Amwdp/H6z78kXds8kTJNBXJAVlCVc > > =yXrI > > -END PGP SIGNATURE- > > > > Signature for apache-wicket-7.5.0.tar.gz: > > > > -BEGIN PGP SIGNATURE- > > Comment: GPGTools - https://gpgtools.org > > > > iEYEABECAAYFAlgHyLgACgkQJBX8W/xy/UUVtgCgx2kALIRDUGdXHjl1hQwOPhzW > > NVYAn0VNdt96cd5VmIW7nIFSb0PidYbH > > =ob3v > > -END PGP SIGNATURE- > > > > > > > > CHANGELOG for 7.5.0: > > > > ** Sub-task > > > > * [WICKET-6243] - ResourceReferenceAutolink component resolved by > > AutoLinkResolver ignores session locale changes > > > > ** Bug > > > > * [WICKET-5972] - Datepicker "Close" text overlays 'x' icon. > > * [WICKET-6136] - AutoCompleteTextField issue in Android 5.1.1 > > * [WICKET-6192] - Remove recreateBookmarkablePagesAfterExpiry > > check in AbstractBookmarkableMapper#mapHandler > > * [WICKET-6209] - requesting focus on disabled field fails with error > > in IE8 > > * [WICKET-6214] - ModalWindow broken on IE > > * [WICKET-6215] - Test fail when non empty model is set to > > PasswordTextField > > * [WICKET-6216] - Problem with queued components and border > > * [WICKET-6217] - Enclosure broken within Border/Panel > > * [WICKET-6219] - Fragment fails to report an error in development > mode > > * [WICKET-6221] - WicketTester - missing border path > > * [WICKET-6222] - renderHead not called with anonymous inner Border > > class > > * [WICKET-6225] - Button wrongly sets its model object as 'value' > > attribute > > * [WICKET-6227] - CharSequenceResource calculates wrong length > > when there are unicode symbols > > * [WICKET-6230] - Infinite redirection when using > > UrlPathPageParametersEncoder > > * [WICKET-6231] - wicket:enclosure and getVariation(). > > * [WICKET-6232] - When sending binary data from server to client, > > wicket-websocket-jquery.js throws error "message.indexOf is not a > > function" > > * [WICKET-6235] - TableTree#updateNode() fails if no corresponding > > node is visible > > * [WICKET-6236] - Files.remove() causes a 5 seconds delay instead > > of 500ms as was intended > > * [WICKET-6237] - PageRequestHandlerTracker doesn't work with > > IRequestHandlerDelegate > > * [WICKET-6238] - pub2 Wicket example isn't switching the beer images > > * [WICKET-6241] - CheckingObjectOutputStream should track the > > original instance, before writeReplace() > > * [WICKET-6242] -
Re: [VOTE] Release Apache Wicket 6.25.0
As we updated our Jetty dependency version from 7.6.13.v20130916 to 7.6.21.v20160908 [1], we unfortunately broke our quickstart's jetty-maven-plugin since this new version is not released under the old Jetty host Mortbay [2], as configured in our quickstart pom.xml. Actually I can't find this plugin version even in the new Jetty host releases [3]. Given that the quickstart is the entry point for new developers in Wicket, and that I don't know how common is this plugin usage ( I use it to start wicket-examples ), I'm -0 to release this version. On another topic, the pom.xml's version in the build/wicket-6.25.0 branch is 6.26.0-SNAPSHOT. Is it OK? Even the wicket-examples site is showing me 6.26.0-SNAPSHOT. Cheers 1 - https://git1-us-west.apache.org/repos/asf?p=wicket.git;a=blobdiff;f=archetypes/quickstart/src/main/resources/archetype-resources/pom.xml;h=2afc43303ce865479144e2ec35b7efcf41c1450b;hp=07e39fd9955d1d673fbb66f5fa8110fcd4eacb09;hb=52f0b8af;hpb=6ec87eeba13500b89b6c81c757d8a946c68e8222 2 - https://repo.maven.apache.org/maven2/org/mortbay/jetty/jetty-maven-plugin/ 3 - https://repo.maven.apache.org/maven2/org/eclipse/jetty/jetty-maven-plugin/ Pedro Santos On Tue, Sep 27, 2016 at 6:43 AM, Andrea Del Bene <an.delb...@gmail.com> wrote: > +1 Built and tested random examples > > > > On 26/09/2016 17:11, Sven Meier wrote: > >> +1 release 6.25.0 >> >> Built, checked md5 and poked some examples. >> >> Thanks >> Sven >> >> >> On 24.09.2016 15:22, Martijn Dashorst wrote: >> >>> This is a vote to release Apache Wicket 6.25.0 >>> >>> Please download the source distributions found in our staging area >>> linked below. >>> >>> I have included the signatures for both the source archives. This vote >>> lasts for 72 hours minimum. >>> >>> [ ] Yes, release Apache Wicket 6.25.0 >>> [ ] No, don't release Apache Wicket 6.25.0, because ... >>> >>> Distributions, changelog, keys and signatures can be found at: >>> >>> https://dist.apache.org/repos/dist/dev/wicket/6.25.0 >>> >>> Staging repository: >>> >>> https://repository.apache.org/content/repositories/orgapachewicket-1074/ >>> >>> The binaries are available in the above link, as are a staging >>> repository for Maven. Typically the vote is on the source, but should >>> you find a problem with one of the binaries, please let me know, I can >>> re-roll them some way or the other. >>> >>> Staging git repository data: >>> >>> Repository: g...@github.com:dashorst/wicket.git >>> Branch: build/wicket-6.25.0 >>> Release tag: rel/wicket-6.25.0 >>> >>> >>> >>> >>> The signatures for the source release artefacts: >>> >>> >>> Signature for apache-wicket-6.25.0.zip: >>> >>> -BEGIN PGP SIGNATURE- >>> Comment: GPGTools - https://gpgtools.org >>> >>> iEYEABECAAYFAlfmfCEACgkQJBX8W/xy/UXaZACdFBqxuvFcai65YtX+tWD09OEy >>> AxkAnA9PUgDJQL+0iV23RK6FbLRJCEoZ >>> =issT >>> -END PGP SIGNATURE- >>> >>> Signature for apache-wicket-6.25.0.tar.gz: >>> >>> -BEGIN PGP SIGNATURE- >>> Comment: GPGTools - https://gpgtools.org >>> >>> iEYEABECAAYFAlfmfCEACgkQJBX8W/xy/UUUgQCfUbwPNEK3DW+EoyJE2ukoCjgF >>> CPYAnRk58qx7E4s0PlWDEVW2Y+c08LcZ >>> =kttX >>> -END PGP SIGNATURE- >>> >>> >>> >>> CHANGELOG for 6.25.0: >>> >>> ** Sub-task >>> >>> * [WICKET-6218] - backport fix for WICKET-6172 to Wicket 6.x >>> >>> ** Bug >>> >>> * [WICKET-5972] - Datepicker "Close" text overlays 'x' icon. >>> * [WICKET-6136] - AutoCompleteTextField issue in Android 5.1.1 >>> * [WICKET-6209] - requesting focus on disabled field fails with >>> error in IE8 >>> * [WICKET-6214] - ModalWindow broken on IE >>> * [WICKET-6219] - Fragment fails to report an error in development >>> mode >>> * [WICKET-6225] - Button wrongly sets its model object as 'value' >>> attribute >>> * [WICKET-6227] - CharSequenceResource calculates wrong length >>> when there are unicode symbols >>> * [WICKET-6230] - Infinite redirection when using >>> UrlPathPageParametersEncoder >>> *
Re: Proposal to improve property expression resolution for Wicket 8 by using a parser
Hi,
we can look for a better name, but imo it's correct. Lets say that the user
wrote a very weir list like:
class WeirdList implements List{
int get0(){ return internal;}
void set0( p ){ internal = p;}
}
In this case:
- the expression "weirList.0" has "0" correctly parsed to a bean property
named "0"
- the expression "weirdList[0]" has the "[0]" correctly parsed to an index
In the case you pointed out, were we have a non weird list:
- the expression "regularList.0" correctly parses "0" to bean property.
Yes, our resolver will resolve this expression to a list position as if it
was resolving an index expression, but only because it failed to find a
bean property
- the expression "regularList[0]" correctly parses "[0]" to an index and
will allow the resolver to skip any code trying to resolve "[0]" as a bean
property
Pedro Santos
On Wed, Sep 28, 2016 at 3:58 PM, Sven Meier <s...@meiers.net> wrote:
> Hi,
>
> > the plan is to change PropertyResolver to use a syntax tree insteadof
> the current list of lexemes
>
> good, I missed that.
>
> > return resolveListOrArrayIndex(object, expression.beanProperty);
>
> Well, then expression.beanProperty is wrongly named, isn't it?
>
> Sven
>
>
>
> On 28.09.2016 19:24, Pedro Santos wrote:
>
>> Hi Sven, thx. Sending the response inline.
>>
>> Cheers
>>
>> Pedro Santos
>>
>> On Wed, Sep 28, 2016 at 3:08 AM, Sven Meier <s...@meiers.net> wrote:
>>
>> Hi Pedro,
>>>
>>> very interesting work, thank you very much.
>>>
>>> I have a little nitpick though:
>>>
>>> The expression "addressList.1" is parsed into a PropertyExpression with
>>> JavaProperty-"person" followed by BeanProperty-"1".
>>>
>>> When PropertyResolver converts the parsed expression into {"addressList",
>>> "1"}, the syntactic analysis is lost though.
>>>
>>> Indeed. The plan is to change PropertyResolver to use a syntax tree
>> instead
>> of the current list of lexemes. One of the devs can go ahead and make this
>> change, but I would rather wait to get the team's thoughts on the parser
>> first. As a side note, I moved the current tokenizer code from
>> PropertyResolver to the inner class PropertyResolverTokenizer only to make
>> the current code clearer; this class should be deleted in the future.
>>
>>
>> With the lexical analysis remaining only, the expression results in
>>> invocation of #getAdressList() followed by #get(1) instead,
>>> i.e. "1" is interpreted as a list index.
>>>
>>> It seems our current grammar is more lenient than what your parser is
>>> expecting.
>>>
>>> To be exact, our property resolution logic is lenient, not the current
>> grammar. It's perfectly fine to have a lenient property resolution logic
>> that falls back the property expression "myArray.1" to "myArray[1]". But
>> using a syntax tree, the resolution code would be much clear about it.
>> e.g.
>>
>> PropertyResolver {
>>IGetAndSet resolve(object, expression) {
>> ...
>> if(expression.beanProperty != null) {
>>try {
>> return resolveBeanProperty(object, expression.beanProperty);
>>} catch(ParserException e){
>> if(isANumber(expression.beanProperty))
>>//can't resolve the bean property "1", since it's a number,
>> fallback to test a List/Array index as if the beanProperty were an index
>> expression like "[1]"
>>return resolveListOrArrayIndex(object,
>> expression.beanProperty);
>> else
>>//fallback to test if the beanProperty can be a map key
>>...
>>}
>> }
>> ...
>>}
>> }
>>
>>
>> Regards
>>> Sven
>>>
>>>
>>>
>>>
>>> On 25.09.2016 09:40, Pedro Santos wrote:
>>>
>>> Hi devs,
>>>>
>>>> Currently PropertyResolver is doing all the tokenizer plus property
>>>> resolution logic to resolve property expressions to IGetAndSet
>>>> interfaces.
>>>> To improve its cohesion and to add new messages explaining syntax error
>>>> in
>>>> the property expression entered by users, I propose us to use a parser
>>>> for
>>>> the grammar below.
>>>>
>>>> I created the branch [1] to show the parser and, if t
Re: Proposal to improve property expression resolution for Wicket 8 by using a parser
Hi Sven, thx. Sending the response inline.
Cheers
Pedro Santos
On Wed, Sep 28, 2016 at 3:08 AM, Sven Meier <s...@meiers.net> wrote:
> Hi Pedro,
>
> very interesting work, thank you very much.
>
> I have a little nitpick though:
>
> The expression "addressList.1" is parsed into a PropertyExpression with
> JavaProperty-"person" followed by BeanProperty-"1".
>
> When PropertyResolver converts the parsed expression into {"addressList",
> "1"}, the syntactic analysis is lost though.
>
Indeed. The plan is to change PropertyResolver to use a syntax tree instead
of the current list of lexemes. One of the devs can go ahead and make this
change, but I would rather wait to get the team's thoughts on the parser
first. As a side note, I moved the current tokenizer code from
PropertyResolver to the inner class PropertyResolverTokenizer only to make
the current code clearer; this class should be deleted in the future.
> With the lexical analysis remaining only, the expression results in
> invocation of #getAdressList() followed by #get(1) instead,
> i.e. "1" is interpreted as a list index.
>
> It seems our current grammar is more lenient than what your parser is
> expecting.
>
To be exact, our property resolution logic is lenient, not the current
grammar. It's perfectly fine to have a lenient property resolution logic
that falls back the property expression "myArray.1" to "myArray[1]". But
using a syntax tree, the resolution code would be much clear about it. e.g.
PropertyResolver {
IGetAndSet resolve(object, expression) {
...
if(expression.beanProperty != null) {
try {
return resolveBeanProperty(object, expression.beanProperty);
} catch(ParserException e){
if(isANumber(expression.beanProperty))
//can't resolve the bean property "1", since it's a number,
fallback to test a List/Array index as if the beanProperty were an index
expression like "[1]"
return resolveListOrArrayIndex(object, expression.beanProperty);
else
//fallback to test if the beanProperty can be a map key
...
}
}
...
}
}
>
> Regards
> Sven
>
>
>
>
> On 25.09.2016 09:40, Pedro Santos wrote:
>
>> Hi devs,
>>
>> Currently PropertyResolver is doing all the tokenizer plus property
>> resolution logic to resolve property expressions to IGetAndSet interfaces.
>> To improve its cohesion and to add new messages explaining syntax error in
>> the property expression entered by users, I propose us to use a parser for
>> the grammar below.
>>
>> I created the branch [1] to show the parser and, if the team agrees with
>> the proposal, I will move to the next step that is to change the
>> PropertyResolver to use the generated syntax tree object instead of the
>> current lexemes. I'm using the ticket WICKET-4008 to track the work.
>>
>> Proposed grammar in an EBNF like description:
>>
>>java letter = "_" | "$" | "A" | "a" | "B" | "b" | (...);
>>
>>java letter or digit = java letter | "0" | "1" | (...) ;
>>char = java letter or digit | "." | "(" | ")" | "[" | "]" | "!" | "@" |
>> "#" | (...);
>>index char = char - "]";
>>
>>empty space = { " " };
>>java identifier = java letter , {java letter or digit};
>>property name = java letter or digit , {java letter or digit};
>>method sign = "(" , empty space , ")";
>>index = "[" , index char , { index char } , "]";
>>
>>bean property = property name, [ index ];
>>java property = java identifier , [ index | method sign ];
>>property expression = [ bean property | java property | index ] , {
>> "." ,
>> property expression };
>>
>> Main goals:
>>
>> - To remove from PropertyResolver its current tokenizer code
>> - To validate property expressions syntax
>>
>> To exemplify the new messages explaining syntax errors:
>>
>> - Given the expression: "bean.method(parameter)", we can explain that no
>> parameter is allowed inside the brackets
>> - Given the expression "array[]", we can explain that the empty brackets
>> aren't allowed
>> - Given the expression "bean.prop#name", we can explain that
>> "bean.prop#name" isn't a valid bean property name
>> - Given the expression "bean.0method()", we can explain that "0method"
>> i
Proposal to improve property expression resolution for Wicket 8 by using a parser
Hi devs,
Currently PropertyResolver is doing all the tokenizer plus property
resolution logic to resolve property expressions to IGetAndSet interfaces.
To improve its cohesion and to add new messages explaining syntax error in
the property expression entered by users, I propose us to use a parser for
the grammar below.
I created the branch [1] to show the parser and, if the team agrees with
the proposal, I will move to the next step that is to change the
PropertyResolver to use the generated syntax tree object instead of the
current lexemes. I'm using the ticket WICKET-4008 to track the work.
Proposed grammar in an EBNF like description:
java letter = "_" | "$" | "A" | "a" | "B" | "b" | (...);
java letter or digit = java letter | "0" | "1" | (...) ;
char = java letter or digit | "." | "(" | ")" | "[" | "]" | "!" | "@" |
"#" | (...);
index char = char - "]";
empty space = { " " };
java identifier = java letter , {java letter or digit};
property name = java letter or digit , {java letter or digit};
method sign = "(" , empty space , ")";
index = "[" , index char , { index char } , "]";
bean property = property name, [ index ];
java property = java identifier , [ index | method sign ];
property expression = [ bean property | java property | index ] , { "." ,
property expression };
Main goals:
- To remove from PropertyResolver its current tokenizer code
- To validate property expressions syntax
To exemplify the new messages explaining syntax errors:
- Given the expression: "bean.method(parameter)", we can explain that no
parameter is allowed inside the brackets
- Given the expression "array[]", we can explain that the empty brackets
aren't allowed
- Given the expression "bean.prop#name", we can explain that
"bean.prop#name" isn't a valid bean property name
- Given the expression "bean.0method()", we can explain that "0method"
isn't a valid java identifier, thus the method call is invalid
Collateral benefits:
- We will be able to map keys in map expressions using the '[' character
like "may[key[weird]"
Obs. 1: even having the open square bracket '[', the parser is able to
understand the key because of grammar's production rule: index char = char
- "]";
Obs. 2: a better solution was proposed in the thread
http://wicket-dev.markmail.org/thread/unwdqpxulw7tcd5l
- Allows empty spaces inside method call brackets ( )
Obs.: because of grammar's production rule: method sign = "(" , empty
space, ")";
- Improves Wicket's performance since every detected syntax error prevents
PropertyResolver from to test bean's classes via reflection, know to add
performance overhead [2].
Future benefits:
- The parser enables us to easily enforce that expressions like
"bean.map[key]" will have the key tested only against a map, and won't be
resolved as to object's get/set methods.
- PropertyResolver resolves expressions like "bean.attributeAt.1" to the
methods: bean.getAttributeAt(1) and bean.setAttributeAt(1, value). This
resolution logic can be improved to only test for this kind of method
signatures if the analyzed input allows such usage (currently the resolver
always test for such signatures).
1 -
https://github.com/apache/wicket/commits/WICKET-4008-property-expression-parser
2 - http://docs.oracle.com/javase/tutorial/reflect/index.html
Cheers
Pedro Santos
Re: New releases for 6.x, 7.x and 8.Mx?
My bad, missed to import wicket-devutils in my workspace. No hold ups from me. Thanks Martijn! Pedro Santos On Fri, Sep 23, 2016 at 9:43 PM, Pedro Santos <pedros...@gmail.com> wrote: > Looking through wicket examples in Wicket 7 branch, it looks like the ajax > debug bar is missing. I would hold up the release. > > Pedro Santos > > On Fri, Sep 23, 2016 at 11:12 AM, Martijn Dashorst < > martijn.dasho...@gmail.com> wrote: > >> Are there any holdups for issuing new releases for the aforementioned >> branches? >> >> Martijn >> >> -- >> Become a Wicket expert, learn from the best: http://wicketinaction.com >> > >
Re: New releases for 6.x, 7.x and 8.Mx?
Looking through wicket examples in Wicket 7 branch, it looks like the ajax debug bar is missing. I would hold up the release. Pedro Santos On Fri, Sep 23, 2016 at 11:12 AM, Martijn Dashorst < martijn.dasho...@gmail.com> wrote: > Are there any holdups for issuing new releases for the aforementioned > branches? > > Martijn > > -- > Become a Wicket expert, learn from the best: http://wicketinaction.com >
Re: Change in expression property for Wicket 8 proposal
Hi Martin, sure! I guess you mean the parser I'm developing int the WICKET-4008 branch. Just want to clear that this proposal has no relation with the parser. As Martijn, I have mixed feelings regarding this proposal, for the same reasons. Regarding the parser that I will propose and am developing in WICKET-4008 branch, 1-) Looks an overcomplicated configuration, the framework parser should do its work. But yes, it can be. 2-) The parser only parses the expression to better explain syntax errors and to provide PropertyResolver with an analyzed input that meaningful and easier to navigate (not implemented yet). Plus will allow us to remove parsing logic mixed in the expression resolution code, like PropertyResolver#getNextDotIndex and its usages in through the code. My guess is that the fancy properties of the language are barely used. "[" is pretty much a reserved character right now and to simply have it inside square bracket would be enough to cause problems. Plus a simple empty space inside the method call brackets like "method( )" would fail without even informing that the method call syntax wasn't accepted/valid. I'm already open tickets to track those problems regardless of how we choose to parse the expression. I'm not using map key in the grammar nor in the parser implementation, maybe in the test cases which is OK. You are right, the index should be identified as a list/array position or as a map key during the property expression resolution inside PropertyResolver, not by the parser. Pedro Santos On Thu, Sep 22, 2016 at 4:25 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi Pedro, > > There were no complains about the current parser, but that doesn't mean we > should not improve! > > Two questions: > 1) can it be switchable? i.e. if someone faces a problem with the new > parser then by using a JVM setting (-Dxyz=...) to switch to the old parser > 2) does it cover all current funtionality ? I don't use fancy property > expressions in my apps but I remember seeing support for array and list > indexing. Your branch talks about map keys but since the syntax is the same > maybe it is already supported. But if it is then the index should be parsed > to int at the usage side. > > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Wed, Sep 21, 2016 at 2:30 AM, Pedro Santos <pedros...@gmail.com> wrote: > > > Hi devs, > > > > currently we can't have expression properties for map keys containing the > > '[' character, even though it's a valid key character. My proposal is to > > change our current string literal to a quoted one. So the expression > > *map[myKey]* would no longer be valid in benefit of *map["myKey"]* or > > *map['myKey']*. Any quote and escape character would need to be escaped, > > and I suggest us to use the same escape logic from the Unified Expression > > Language [1] and the original OGNL[2]. > > > > 1 - http://docs.oracle.com/javaee/5/tutorial/doc/bnahq.html#bnahu > > 2 - http://commons.apache.org/proper/commons-ognl/language-guide.html > > > > cheers > > > > Pedro Santos > > >
Change in expression property for Wicket 8 proposal
Hi devs, currently we can't have expression properties for map keys containing the '[' character, even though it's a valid key character. My proposal is to change our current string literal to a quoted one. So the expression *map[myKey]* would no longer be valid in benefit of *map["myKey"]* or *map['myKey']*. Any quote and escape character would need to be escaped, and I suggest us to use the same escape logic from the Unified Expression Language [1] and the original OGNL[2]. 1 - http://docs.oracle.com/javaee/5/tutorial/doc/bnahq.html#bnahu 2 - http://commons.apache.org/proper/commons-ognl/language-guide.html cheers Pedro Santos
Re: wicket git commit: WICKET-6243 testing session's locale on each auto linked resource rendering
Hi Martin, thx!
In this case I need to make sure of to set a default locale before
instantiate the tester. But actually I can add this in a @BeforeAll and
still extend from WicketTestCase. Will improve the test next.
Pedro Santos
On Tue, Sep 13, 2016 at 4:19 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:
> Hi Pedro,
>
> On Sun, Sep 11, 2016 at 8:28 AM, <pe...@apache.org> wrote:
>
> > Repository: wicket
> > Updated Branches:
> > refs/heads/wicket-7.x 6f530a925 -> ec1ff11dd
> >
> >
> > WICKET-6243 testing session's locale on each auto linked resource
> rendering
> >
> >
> > Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
> > Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/ec1ff11d
> > Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/ec1ff11d
> > Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/ec1ff11d
> >
> > Branch: refs/heads/wicket-7.x
> > Commit: ec1ff11dd625017a932229c43d77c5d3cd3a07dc
> > Parents: 6f530a9
> > Author: Pedro Henrique Oliveira dos Santos <pe...@apache.org>
> > Authored: Sun Sep 11 03:27:40 2016 -0300
> > Committer: Pedro Henrique Oliveira dos Santos <pe...@apache.org>
> > Committed: Sun Sep 11 03:27:40 2016 -0300
> >
> > --
> > .../markup/resolver/AutoLinkResolver.java | 3 +-
> > .../markup/resolver/AutoLinkResolverTest.java | 44
>
> > .../PageWithAutoLinkedLocalResource.html| 1 +
> > .../PageWithAutoLinkedLocalResource.java| 26
> > .../apache/wicket/markup/resolver/resource.ext | 0
> > .../wicket/markup/resolver/resource_en_CA.ext | 0
> > .../wicket/markup/resolver/resource_en_US.ext | 0
> > 7 files changed, 72 insertions(+), 2 deletions(-)
> > --
> >
> >
> > http://git-wip-us.apache.org/repos/asf/wicket/blob/
> > ec1ff11d/wicket-core/src/main/java/org/apache/wicket/markup/
> > resolver/AutoLinkResolver.java
> > --
> > diff --git a/wicket-core/src/main/java/org/apache/wicket/markup/
> resolver/AutoLinkResolver.java
> > b/wicket-core/src/main/java/org/apache/wicket/markup/
> > resolver/AutoLinkResolver.java
> > index cbd2f1f..c9c59a3 100644
> > --- a/wicket-core/src/main/java/org/apache/wicket/markup/
> > resolver/AutoLinkResolver.java
> > +++ b/wicket-core/src/main/java/org/apache/wicket/markup/
> > resolver/AutoLinkResolver.java
> > @@ -603,8 +603,7 @@ public final class AutoLinkResolver implements
> > IComponentResolver
> > if (PackageResource.exists(clazz, href,
> > getLocale(), getStyle(), getVariation()))
> > {
> > // Create the component implementing the
> > link
> > - resourceReference = new
> > PackageResourceReference(clazz, href, getLocale(),
> > - getStyle(), getVariation());
> > + resourceReference = new
> > PackageResourceReference(clazz, href, null, null, null);
> > }
> > else
> > {
> >
> > http://git-wip-us.apache.org/repos/asf/wicket/blob/
> > ec1ff11d/wicket-core/src/test/java/org/apache/wicket/markup/
> > resolver/AutoLinkResolverTest.java
> > --
> > diff --git a/wicket-core/src/test/java/org/apache/wicket/markup/
> > resolver/AutoLinkResolverTest.java b/wicket-core/src/test/java/
> > org/apache/wicket/markup/resolver/AutoLinkResolverTest.java
> > new file mode 100644
> > index 000..32ed85c
> > --- /dev/null
> > +++ b/wicket-core/src/test/java/org/apache/wicket/markup/
> > resolver/AutoLinkResolverTest.java
> > @@ -0,0 +1,44 @@
> > +/*
> > + * Licensed to the Apache Software Foundation (ASF) under one or more
> > + * contributor license agreements. See the NOTICE file distributed with
> > + * this work for additional information regarding copyright ownership.
> > + * The ASF licenses this file to You under the Apache License, Version
> 2.0
> > + * (the "License"); you may not use this file except in compliance with
> > + * the License. You may obtain a copy of the License at
> > + *
> > + * http://www.apache.org/licenses/LICENSE-2.0
> &
Re: wicket git commit: WICKET-6165 renaming MarkupStream#hasMore to MarkupStream#isCurrentIndexInsideTheStream
Created a branch [1] to elaborate on how the purely improvement in the stream API can be backported without the bug fix and no impact to current apps, while providing a correct API to the few future users who may want to use the MarkupStream. 1 - https://github.com/apache/wicket/commits/stream-api-improvement Pedro Santos On Wed, Sep 7, 2016 at 4:09 AM, Pedro Santos <pedros...@gmail.com> wrote: > Hi Sven, > > I think you meant the bug fix shouldn't be backported given this change is > both a bug fix and a consistency improvement, and that the consistency > improvement can indeed be merged into 6.x and 7.x with no impact on > existing applications. > > I may have chosen the wrong words in the commit message since the change > rather adds the isCurrentIndexInsideTheStream method next to the current > hasMore method than to rename hasMore to isCurrentIndexInsideTheStream. > > cheers > > Pedro Santos > > On Wed, Sep 7, 2016 at 3:08 AM, Sven Meier <s...@meiers.net> wrote: > >> Hi, >> >> IMHO this change should *not* be merged into 6.x and 7.x: >> It's important to improve consistency on master, but we shouldn't risk >> breaking existing applications. >> >> Regards >> Sven >> >> >> >> On 07.09.2016 08:01, Tobias Soloschenko wrote: >> >>> Hi, >>> >>> can we somehow announce this / list this up? >>> >>> Maybe in the release news and migration guide? >>> >>> Otherwise devs will wonder why something is not working like with the >>> file part parse call in forms some months ago. >>> >>> kind regards >>> >>> Tobias >>> >>> Am 07.09.2016 um 04:33 schrieb Martin Grigorov <mgrigo...@apache.org>: >>>> >>>> Hi, >>>> >>>> I'm -0 to backport this to 6.x/7.x. >>>> IMO there is a small chance that this will break some applications >>>> silently. >>>> >>>> Martin Grigorov >>>> Wicket Training and Consulting >>>> https://twitter.com/mtgrigorov >>>> >>>> On Mon, Sep 5, 2016 at 7:10 AM, Pedro Santos <pedros...@gmail.com> >>>>> wrote: >>>>> >>>>> I searched of MarkupStream#hasMore usages inside Wicket Stuff, which >>>>> should >>>>> give a good idea of how often this method is used, and I think it's >>>>> safe to >>>>> apply the fix on the 1.6.x and 1.7.x branches. >>>>> >>>>> Pedro Santos >>>>> >>>>> On Mon, Sep 5, 2016 at 2:01 AM, <pe...@apache.org> wrote: >>>>>> >>>>>> Repository: wicket >>>>>> Updated Branches: >>>>>> refs/heads/master 7da317e51 -> e3e09fd00 >>>>>> >>>>>> >>>>>> WICKET-6165 renaming MarkupStream#hasMore to MarkupStream# >>>>>> isCurrentIndexInsideTheStream >>>>>> >>>>>> >>>>>> Project: http://git-wip-us.apache.org/repos/asf/wicket/repo >>>>>> Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/e3e09fd0 >>>>>> Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/e3e09fd0 >>>>>> Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/e3e09fd0 >>>>>> >>>>>> Branch: refs/heads/master >>>>>> Commit: e3e09fd002452c8d2ea4be18f2733cffda78fc10 >>>>>> Parents: 7da317e >>>>>> Author: Pedro Henrique Oliveira dos Santos <pe...@apache.org> >>>>>> Authored: Mon Sep 5 02:00:29 2016 -0300 >>>>>> Committer: Pedro Henrique Oliveira dos Santos <pe...@apache.org> >>>>>> Committed: Mon Sep 5 02:00:29 2016 -0300 >>>>>> >>>>>> >>>>>> -- >>>>>> .../java/org/apache/wicket/MarkupContainer.java | 2 +- >>>>>> .../org/apache/wicket/markup/MarkupStream.java| 18 >>>>>> >>>>> +- >>>>> >>>>>> .../java/org/apache/wicket/markup/TagUtils.java | 2 +- >>>>>> .../html/TransparentWebMarkupContainer.java | 2 +- >>>>>> .../wicket/markup/html/border/BorderBehavior.java | 6 +++--- >>>>>> .../wicket/markup/html/internal/Enclosure.java| 2 +- >>>>>> .../markup/r
Re: wicket git commit: WICKET-6165 renaming MarkupStream#hasMore to MarkupStream#isCurrentIndexInsideTheStream
Hi Sven, I think you meant the bug fix shouldn't be backported given this change is both a bug fix and a consistency improvement, and that the consistency improvement can indeed be merged into 6.x and 7.x with no impact on existing applications. I may have chosen the wrong words in the commit message since the change rather adds the isCurrentIndexInsideTheStream method next to the current hasMore method than to rename hasMore to isCurrentIndexInsideTheStream. cheers Pedro Santos On Wed, Sep 7, 2016 at 3:08 AM, Sven Meier <s...@meiers.net> wrote: > Hi, > > IMHO this change should *not* be merged into 6.x and 7.x: > It's important to improve consistency on master, but we shouldn't risk > breaking existing applications. > > Regards > Sven > > > > On 07.09.2016 08:01, Tobias Soloschenko wrote: > >> Hi, >> >> can we somehow announce this / list this up? >> >> Maybe in the release news and migration guide? >> >> Otherwise devs will wonder why something is not working like with the >> file part parse call in forms some months ago. >> >> kind regards >> >> Tobias >> >> Am 07.09.2016 um 04:33 schrieb Martin Grigorov <mgrigo...@apache.org>: >>> >>> Hi, >>> >>> I'm -0 to backport this to 6.x/7.x. >>> IMO there is a small chance that this will break some applications >>> silently. >>> >>> Martin Grigorov >>> Wicket Training and Consulting >>> https://twitter.com/mtgrigorov >>> >>> On Mon, Sep 5, 2016 at 7:10 AM, Pedro Santos <pedros...@gmail.com> >>>> wrote: >>>> >>>> I searched of MarkupStream#hasMore usages inside Wicket Stuff, which >>>> should >>>> give a good idea of how often this method is used, and I think it's >>>> safe to >>>> apply the fix on the 1.6.x and 1.7.x branches. >>>> >>>> Pedro Santos >>>> >>>> On Mon, Sep 5, 2016 at 2:01 AM, <pe...@apache.org> wrote: >>>>> >>>>> Repository: wicket >>>>> Updated Branches: >>>>> refs/heads/master 7da317e51 -> e3e09fd00 >>>>> >>>>> >>>>> WICKET-6165 renaming MarkupStream#hasMore to MarkupStream# >>>>> isCurrentIndexInsideTheStream >>>>> >>>>> >>>>> Project: http://git-wip-us.apache.org/repos/asf/wicket/repo >>>>> Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/e3e09fd0 >>>>> Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/e3e09fd0 >>>>> Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/e3e09fd0 >>>>> >>>>> Branch: refs/heads/master >>>>> Commit: e3e09fd002452c8d2ea4be18f2733cffda78fc10 >>>>> Parents: 7da317e >>>>> Author: Pedro Henrique Oliveira dos Santos <pe...@apache.org> >>>>> Authored: Mon Sep 5 02:00:29 2016 -0300 >>>>> Committer: Pedro Henrique Oliveira dos Santos <pe...@apache.org> >>>>> Committed: Mon Sep 5 02:00:29 2016 -0300 >>>>> >>>>> -- >>>>> .../java/org/apache/wicket/MarkupContainer.java | 2 +- >>>>> .../org/apache/wicket/markup/MarkupStream.java| 18 >>>>> >>>> +- >>>> >>>>> .../java/org/apache/wicket/markup/TagUtils.java | 2 +- >>>>> .../html/TransparentWebMarkupContainer.java | 2 +- >>>>> .../wicket/markup/html/border/BorderBehavior.java | 6 +++--- >>>>> .../wicket/markup/html/internal/Enclosure.java| 2 +- >>>>> .../markup/resolver/WicketMessageResolver.java| 4 ++-- >>>>> 7 files changed, 22 insertions(+), 14 deletions(-) >>>>> -- >>>>> >>>>> >>>>> http://git-wip-us.apache.org/repos/asf/wicket/blob/ >>>>> e3e09fd0/wicket-core/src/main/java/org/apache/wicket/ >>>>> >>>> MarkupContainer.java >>>> >>>>> -- >>>>> diff --git a/wicket-core/src/main/java/org/apache/wicket/ >>>>> >>>> MarkupContainer.java >>>> >>>>> b/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java >>>>> index 09705ff..6df5316 100644 >>>>> --- a/wicket-core
Re: wicket git commit: WICKET-6165 renaming MarkupStream#hasMore to MarkupStream#isCurrentIndexInsideTheStream
Hi,
@martin: indeed. But it's a small chance and that the bug fix will benefit
future devs who may want to use Wicket 6 or 7 to parse and iterate markup.
Does -0 means in doubt but inclined to -1? In I'm in doubt whether to
backport or not as well.
@tobias: to list this bug fix in the release change log looks enough to me.
Any dev using Wicket to parse and iterate a markup would have ran in the
same problem. As WICKET-6165 is the first ticket I see on this matter, it
looks like this steam API, even being public, wasn't being used outside
Wicket core.
cheers
Pedro Santos
On Wed, Sep 7, 2016 at 3:01 AM, Tobias Soloschenko <
tobiassolosche...@googlemail.com> wrote:
> Hi,
>
> can we somehow announce this / list this up?
>
> Maybe in the release news and migration guide?
>
> Otherwise devs will wonder why something is not working like with the file
> part parse call in forms some months ago.
>
> kind regards
>
> Tobias
>
> > Am 07.09.2016 um 04:33 schrieb Martin Grigorov <mgrigo...@apache.org>:
> >
> > Hi,
> >
> > I'm -0 to backport this to 6.x/7.x.
> > IMO there is a small chance that this will break some applications
> silently.
> >
> > Martin Grigorov
> > Wicket Training and Consulting
> > https://twitter.com/mtgrigorov
> >
> >> On Mon, Sep 5, 2016 at 7:10 AM, Pedro Santos <pedros...@gmail.com>
> wrote:
> >>
> >> I searched of MarkupStream#hasMore usages inside Wicket Stuff, which
> should
> >> give a good idea of how often this method is used, and I think it's
> safe to
> >> apply the fix on the 1.6.x and 1.7.x branches.
> >>
> >> Pedro Santos
> >>
> >>> On Mon, Sep 5, 2016 at 2:01 AM, <pe...@apache.org> wrote:
> >>>
> >>> Repository: wicket
> >>> Updated Branches:
> >>> refs/heads/master 7da317e51 -> e3e09fd00
> >>>
> >>>
> >>> WICKET-6165 renaming MarkupStream#hasMore to MarkupStream#
> >>> isCurrentIndexInsideTheStream
> >>>
> >>>
> >>> Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
> >>> Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/e3e09fd0
> >>> Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/e3e09fd0
> >>> Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/e3e09fd0
> >>>
> >>> Branch: refs/heads/master
> >>> Commit: e3e09fd002452c8d2ea4be18f2733cffda78fc10
> >>> Parents: 7da317e
> >>> Author: Pedro Henrique Oliveira dos Santos <pe...@apache.org>
> >>> Authored: Mon Sep 5 02:00:29 2016 -0300
> >>> Committer: Pedro Henrique Oliveira dos Santos <pe...@apache.org>
> >>> Committed: Mon Sep 5 02:00:29 2016 -0300
> >>>
> >>> --
> >>> .../java/org/apache/wicket/MarkupContainer.java | 2 +-
> >>> .../org/apache/wicket/markup/MarkupStream.java| 18
> >> +-
> >>> .../java/org/apache/wicket/markup/TagUtils.java | 2 +-
> >>> .../html/TransparentWebMarkupContainer.java | 2 +-
> >>> .../wicket/markup/html/border/BorderBehavior.java | 6 +++---
> >>> .../wicket/markup/html/internal/Enclosure.java| 2 +-
> >>> .../markup/resolver/WicketMessageResolver.java| 4 ++--
> >>> 7 files changed, 22 insertions(+), 14 deletions(-)
> >>> --
> >>>
> >>>
> >>> http://git-wip-us.apache.org/repos/asf/wicket/blob/
> >>> e3e09fd0/wicket-core/src/main/java/org/apache/wicket/
> >> MarkupContainer.java
> >>> --
> >>> diff --git a/wicket-core/src/main/java/org/apache/wicket/
> >> MarkupContainer.java
> >>> b/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
> >>> index 09705ff..6df5316 100644
> >>> --- a/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
> >>> +++ b/wicket-core/src/main/java/org/apache/wicket/MarkupContainer.java
> >>> @@ -1643,7 +1643,7 @@ public abstract class MarkupContainer extends
> >>> Component implements Iterable >>> */
> >>>protected final void renderAll(final MarkupStream markupStream,
> >>> final ComponentTag openTag)
> >>>{
> >>> - while (markupStream.hasMore())
> >>> + while (ma
Re: wicket git commit: better test dependencies defaults as in wicket 7 and 8 plus changing wicket-core hamcrest dependency scope to test
Hi Martin, Indeed, thx. Just removed the duplicated dependencies. I noticed that we have a few more redundant scopes across 6.x, 7.x and master branches; will run a larger cleanup later so we can have a meaningful setup inside . Pedro Santos On Tue, Sep 6, 2016 at 5:02 AM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi Pedro, > > On Tue, Sep 6, 2016 at 12:11 AM, <pe...@apache.org> wrote: > >> Repository: wicket >> Updated Branches: >> refs/heads/wicket-6.x 5d5af682d -> 635b21c6e >> >> >> better test dependencies defaults as in wicket 7 and 8 plus changing >> wicket-core hamcrest dependency scope to test >> >> >> Project: http://git-wip-us.apache.org/repos/asf/wicket/repo >> Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/635b21c6 >> Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/635b21c6 >> Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/635b21c6 >> >> Branch: refs/heads/wicket-6.x >> Commit: 635b21c6e2c2862f9fc196e4af653bb209c06b36 >> Parents: 5d5af68 >> Author: Pedro Henrique Oliveira dos Santos <pe...@apache.org> >> Authored: Mon Sep 5 19:11:31 2016 -0300 >> Committer: Pedro Henrique Oliveira dos Santos <pe...@apache.org> >> Committed: Mon Sep 5 19:11:31 2016 -0300 >> >> -- >> pom.xml | 20 >> wicket-core/pom.xml | 16 >> wicket-util/pom.xml | 4 >> 3 files changed, 20 insertions(+), 20 deletions(-) >> -- >> >> >> http://git-wip-us.apache.org/repos/asf/wicket/blob/635b21c6/pom.xml >> -- >> diff --git a/pom.xml b/pom.xml >> index c20552c..c104886 100644 >> --- a/pom.xml >> +++ b/pom.xml >> @@ -523,6 +523,26 @@ >> test >> >> >> + org.hamcrest >> + hamcrest-library >> + test >> + >> + >> + org.hamcrest >> + hamcrest-core >> + test >> + >> + >> + org.hamcrest >> + hamcrest-library >> + test >> + >> + >> + org.hamcrest >> + hamcrest-core >> + test >> + >> > > Those new entries look duplicated to me. > If they are in section then they don't need the > setting. It comes from . > > >> + >> org.mockito >> mockito-all >> test >> >> http://git-wip-us.apache.org/repos/asf/wicket/blob/635b21c6/ >> wicket-core/pom.xml >> -- >> diff --git a/wicket-core/pom.xml b/wicket-core/pom.xml >> index 06c5dd2..7689a14 100644 >> --- a/wicket-core/pom.xml >> +++ b/wicket-core/pom.xml >> @@ -50,22 +50,6 @@ >> provided >> >> >> - >> - org.mockito >> - mockito-all >> - provided >> - >> - >> - >> - org.hamcrest >> - hamcrest-library >> - provided >> - >> - >> - org.hamcrest >> - hamcrest-core >> - provided >> - >> >> >> >> >> http://git-wip-us.apache.org/repos/asf/wicket/blob/635b21c6/ >> wicket-util/pom.xml >> -- >> diff --git a/wicket-util/pom.xml b/wicket-util/pom.xml >> index 0da1693..edd0bb9 100755 >> --- a/wicket-util/pom.xml >> +++ b/wicket-util/pom.xml >> @@ -31,10 +31,6 @@ >> junit >> provided >> >> - >> - org.hamcrest >> - hamcrest-library >> - >> >> >> >> >> >
Re: Fragment's markup identifier change proposals for Wicket 8
Oh, good point. Indeed my first idea is pretty much not possible [1].
I meant the snippet with concrete subclasses only to illustrate the idea
since fragments can be created even without a Fragment subclass. My point
here is that even the Fragment being a concrete class, it still is an
abstract Wicket markup container. A concrete Wicket markup container has an
associated markup. When we associate the a markup to a Fragment, we are
creating a concrete Wicket type, and this type needs a name. Therefore the
importance I see in to keeping the "type" word in the identifier attribute.
Regarding the attribute namespace, I'm +1 to default it to Wicket's
namespece (like the "key" attribute in wicket:message tag usually defaults)
rather than to explicitly write the namespace. e.g.:
Given the .java
...
add(new Fragment("myId", "MyFragment", this);
...
I would prefer the following usage in the .xhtml
...
...
rather than
...
...
1 - https://www.w3.org/TR/REC-xml/#id
Pedro Santos
On Sun, Aug 28, 2016 at 4:34 AM, Martin Grigorov <mgrigo...@apache.org>
wrote:
> Hi Pedro,
>
> In both examples you make the assumption that there is a concrete class
> extending from Fragment.
> As with many other cases in Wicket it is quite common to use anonymous
> inner class: return new Fragment(...) {}
> In this case the name/id would be something like "MyContainer$1" which is
> not so nice and more importantly it is not stable! It will change as soon
> as another anonymous inner class is added before the Fragment.
>
> My personal preference would be: wicket:name="myCustomFragmentName">
>
> The problem that I see with is that 'id' has a
> special meaning in XML - it has to be unique in the document.
> Most of the time s are defined as top-level elements in
> MyPanel.html and have unique (wicket:)ids but it is perfectly fine to have
> something like:
>
> <wicket;panel>
>
>
>
>
>
>
>
>
> .
>
>
>
>
> In this case any XML validation tool will complain that there are two
> elements with the same id. The IDE as well.
>
> Martin Grigorov
> Wicket Training and Consulting
> https://twitter.com/mtgrigorov
>
> On Sun, Aug 28, 2016 at 7:28 AM, Pedro Santos <pedros...@gmail.com> wrote:
>
> > Hi devs,
> >
> > the "wicket:id" tag attribute is commonly used to identify Component's
> > instances and its markup, and IMO it should be reserved to this end for
> > clarity.
> >
> > While fragment's markup is identified by the "associatedMarkupId"
> attribute
> > inside the Fragment class, its associated markup is identified by the tag
> > attribute "wicket:id" in the "wicket:fragment" tag. This new case of an
> > associated markup being identified for a type rather than an instance
> would
> > benefit from a new identifier name. Therefore some proposals.
> >
> > 1 - Without changing the Fragment class, a natural tag attribute
> identifier
> > would "wicket:markup-id", matching the class attribute name. Since the
> > identifier is already inside a markup, even more natural would be:
> > "wicket:id" (yeah, I know). Given that we are already inside a tag in
> > Wicket's namespace, a simpler identifier would be: "id".
> >
> > So instead of the current fragment definition:
> >
> > class MyFragment extends Fragment {
> > ...
> > super(id, "myFragmentMarkupId", markupContainer);
> > ...
> > }
> >
> >
> > We would have:
> >
> >
> >
> > 2 - To change Fragment's "associatedMarkupId" attribute to "typeName".
> Even
> > if the user chooses to not specialize the Fragment class by creating a
> > subclass of it, conceptually he is still specializing the markup
> container
> > when associating a markup to it. Following the same
> logic,"wicket:fragment"
> > tag's identifier attribute would be: "type-name". So we would have:
> >
> > class MyFragment extends Fragment {
> > ...
> > super(id, MyFragment.class.getSimpleName(), markupContainer);
> > ...
> > }
> >
> >
> > What are your thought?
> >
> > Cheers
> >
> > Pedro Santos
> >
>
Re: Container rendering change proposal
Martijn, thanks! I put my thoughts on the id change in a different thread. Giving it a closer look, I no longer see a relation with the rendering change. Martin, Ernesto, Andrea, thanks! All tests are welcome. Really happy that it worked fine there, Martin. Cheers, Pedro Santos Pedro Santos On Sat, Aug 27, 2016 at 3:16 PM, Martin Grigorov <mgrigo...@apache.org> wrote: > Hi Pedro, > > I've tested our main application against your branch and everything looks > OK! > The diff also looks good! > > Martin Grigorov > Wicket Training and Consulting > https://twitter.com/mtgrigorov > > On Sat, Aug 20, 2016 at 12:50 PM, Martin Grigorov <mgrigo...@apache.org> > wrote: > > > Hi Pedro, > > > > I won't be able to review and test this change in the next few days. > > We use 7.4.0 in our main app and we have 22 usages of . > > Should be enough to validate the changes. > > I'll let you know when I'm done! > > > > Martin Grigorov > > Wicket Training and Consulting > > https://twitter.com/mtgrigorov > > > > On Sat, Aug 20, 2016 at 6:02 AM, Pedro Santos <pedros...@gmail.com> > wrote: > > > >> Hi devs, > >> > >> Wicket's container rendering creates a new component for each > >> wicket:fragment it finds in the markup, and puts it in the component > tree. > >> This process has a few issues and I prose us to simplify it. > >> > >> issues: > >> > >> - the new component for the fragment can conflict with user's components > >> since we need a wicket:id for it and we don't have a reserved namespace > >> - can cause unexpected behaviours like a container with no children > >> testing > >> true for container.size() > 0 > >> - adds an unnecessary object in the tree > >> - adds unnecessary complexity like custom component versioning (we are > >> setting this component to be not versioned) > >> - causes misleading exception messages since the fragment markup can be > >> mistaken by an actual component markup > >> > >> My idea it to simple skip wicket:fragment's markup while rendering > >> containers. The only place we need to load this markup inside the markup > >> sourcing strategy when providing for a Fragment. > >> > >> The implications are to remove FragmentResolver and possible to change > >> wicket:fragment tag's id attribute from wicket:id to fragment-id or id > in > >> Wicket 8. > >> > >> I see this as a non trivial internal change for Wicket 6 and 7, so I > >> worked > >> on a branch[1] to showcase the idea and to get your thoughts while > >> resolving WICKET-6219 in wicket-7.x branch. > >> > >> cheers, > >> > >> Pedro Santos > >> > >> 1 - https://github.com/apache/wicket/tree/WICKET-6219-no-fragmen > >> t-resolver > >> > > > > >
Fragment's markup identifier change proposals for Wicket 8
Hi devs,
the "wicket:id" tag attribute is commonly used to identify Component's
instances and its markup, and IMO it should be reserved to this end for
clarity.
While fragment's markup is identified by the "associatedMarkupId" attribute
inside the Fragment class, its associated markup is identified by the tag
attribute "wicket:id" in the "wicket:fragment" tag. This new case of an
associated markup being identified for a type rather than an instance would
benefit from a new identifier name. Therefore some proposals.
1 - Without changing the Fragment class, a natural tag attribute identifier
would "wicket:markup-id", matching the class attribute name. Since the
identifier is already inside a markup, even more natural would be:
"wicket:id" (yeah, I know). Given that we are already inside a tag in
Wicket's namespace, a simpler identifier would be: "id".
So instead of the current fragment definition:
class MyFragment extends Fragment {
...
super(id, "myFragmentMarkupId", markupContainer);
...
}
We would have:
2 - To change Fragment's "associatedMarkupId" attribute to "typeName". Even
if the user chooses to not specialize the Fragment class by creating a
subclass of it, conceptually he is still specializing the markup container
when associating a markup to it. Following the same logic,"wicket:fragment"
tag's identifier attribute would be: "type-name". So we would have:
class MyFragment extends Fragment {
...
super(id, MyFragment.class.getSimpleName(), markupContainer);
...
}
What are your thought?
Cheers
Pedro Santos
Container rendering change proposal
Hi devs, Wicket's container rendering creates a new component for each wicket:fragment it finds in the markup, and puts it in the component tree. This process has a few issues and I prose us to simplify it. issues: - the new component for the fragment can conflict with user's components since we need a wicket:id for it and we don't have a reserved namespace - can cause unexpected behaviours like a container with no children testing true for container.size() > 0 - adds an unnecessary object in the tree - adds unnecessary complexity like custom component versioning (we are setting this component to be not versioned) - causes misleading exception messages since the fragment markup can be mistaken by an actual component markup My idea it to simple skip wicket:fragment's markup while rendering containers. The only place we need to load this markup inside the markup sourcing strategy when providing for a Fragment. The implications are to remove FragmentResolver and possible to change wicket:fragment tag's id attribute from wicket:id to fragment-id or id in Wicket 8. I see this as a non trivial internal change for Wicket 6 and 7, so I worked on a branch[1] to showcase the idea and to get your thoughts while resolving WICKET-6219 in wicket-7.x branch. cheers, Pedro Santos 1 - https://github.com/apache/wicket/tree/WICKET-6219-no-fragment-resolver
Re: Throw exception when setOutputMarkupId() on non-renderable component
+1 Pedro Santos On Thu, Aug 18, 2016 at 7:56 AM, Andrea Del Bene <an.delb...@gmail.com> wrote: > +1 for me too > > > > On 18/08/2016 00:47, Martijn Dashorst wrote: > >> Sounds good to me >> >> Martijn >> >> On Wednesday, 17 August 2016, Martin Grigorov <mgrigo...@apache.org> >> wrote: >> >> Hi, >>> >>> What do you think on adding a new setting to ExceptionSettings that says >>> whether to log a WARN (default, as it does now) or to throw exception >>> when >>> setOutputMarkupId/setOutputMarkupPlaceholderTag() are used on component >>> with #setRenderBodyOnly(true) or attached to ? >>> >>> I've had few occasions in the past few months where colleagues of mine >>> use >>> and later try to update it with Ajax. The WARN log is >>> buried amongst other logs (and developers usually simply ignore WARNs) >>> and >>> I see it is hard for them to find out the reason. >>> >>> If the setting proves to be useful then we can throw an exception in DEV >>> mode and log a WARN in PROD mode. >>> >>> https://github.com/apache/wicket/blob/bec52515f1bb2570f09140ba6f457c >>> 369f3a56b1/wicket-core/src/main/java/org/apache/wicket/ >>> Component.java#L4019-L4035 >>> >>> >>> Martin Grigorov >>> Wicket Training and Consulting >>> https://twitter.com/mtgrigorov >>> >>> >> >
Re: git commit: WICKET-4932: testing if the page is bookmarkable before to encode the callback url for a component inside it
Not sure, they are closely related to its outer class and their code next
to each other exposes their fundamental difference giving it readability.
It's your call.
Pedro Santos
On Fri, Jan 11, 2013 at 6:28 AM, Martin Grigorov mgrigo...@apache.orgwrote:
On Thu, Jan 10, 2013 at 7:39 PM, Pedro Santos pedros...@gmail.com wrote:
Wow, thx, found other typo in the commentary article as well, should be
ok
now.
Yep, I would rather to keep both as public. We need BookmarkablePage
with a
public constructor receiving a PageParameters or no parameters in order
to
be tested as bookmarkable.
The majority of pages we have in the tests are public classes, even the
inner ones. The problem is that if you downgrade their visibility, the
framework will not be able to create instances for them or to test their
bookmarkable aspect.
Yes, this is a good reason.
Also it's all ok they show up in some IDE took since they can easily
be useful in some other test.
In this case I think the class should not be inner.
Pedro Santos
On Thu, Jan 10, 2013 at 7:29 AM, Martin Grigorov mgrigo...@apache.org
wrote:
On Thu, Jan 10, 2013 at 12:58 AM, pe...@apache.org wrote:
Updated Branches:
refs/heads/sandbox/bookmarkable-callback-url fba8bddd9 - 1ec0b8b36
WICKET-4932: testing if the page is bookmarkable before to encode the
callback url for a component inside it
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit:
http://git-wip-us.apache.org/repos/asf/wicket/commit/1ec0b8b3
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/1ec0b8b3
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/1ec0b8b3
Branch: refs/heads/sandbox/bookmarkable-callback-url
Commit: 1ec0b8b3637feb19da4f87b485e96bfc7ce4e992
Parents: fba8bdd
Author: Pedro Santos pe...@apache.com
Authored: Wed Jan 9 20:58:40 2013 -0200
Committer: Pedro Santos pe...@apache.com
Committed: Wed Jan 9 20:58:40 2013 -0200
--
.../request/mapper/AbstractBookmarkableMapper.java |2 +-
.../mapper/AbstractBookmarkableMapperTest.java | 70
++-
.../request/mapper/BookmarkableMapperTest.java |6 ++
.../wicket/request/mapper/PackageMapperTest.java |6 ++
4 files changed, 80 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/1ec0b8b3/wicket-core/src/main/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapper.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapper.java
b/wicket-core/src/main/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapper.java
index 47ac13a..7e164dd 100644
---
a/wicket-core/src/main/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapper.java
+++
b/wicket-core/src/main/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapper.java
@@ -333,7 +333,7 @@ public abstract class AbstractBookmarkableMapper
extends AbstractComponentMapper
protected boolean checkPageClass(Class? extends
IRequestablePage
pageClass)
{
- return true;
+ return
Application.get().getPageFactory().isBookmarkable(pageClass);
}
public Url mapHandler(IRequestHandler requestHandler)
http://git-wip-us.apache.org/repos/asf/wicket/blob/1ec0b8b3/wicket-core/src/test/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapperTest.java
--
diff --git
a/wicket-core/src/test/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapperTest.java
b/wicket-core/src/test/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapperTest.java
index 693adec..705f14c 100644
---
a/wicket-core/src/test/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapperTest.java
+++
b/wicket-core/src/test/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapperTest.java
@@ -17,13 +17,22 @@ package org.apache.wicket.request.mapper;
* limitations under the License.
*/
+import static org.hamcrest.CoreMatchers.notNullValue;
+import static org.hamcrest.CoreMatchers.nullValue;
+
import org.apache.wicket.MockPage;
import org.apache.wicket.WicketTestCase;
+import org.apache.wicket.markup.html.link.ILinkListener;
import org.apache.wicket.protocol.http.PageExpiredException;
import org.apache.wicket.request.Request;
import org.apache.wicket.request.Url;
+import
Re: git commit: WICKET-4932: testing if the page is bookmarkable before to encode the callback url for a component inside it
Wow, thx, found other typo in the commentary article as well, should be ok
now.
Yep, I would rather to keep both as public. We need BookmarkablePage with a
public constructor receiving a PageParameters or no parameters in order to
be tested as bookmarkable.
The majority of pages we have in the tests are public classes, even the
inner ones. The problem is that if you downgrade their visibility, the
framework will not be able to create instances for them or to test their
bookmarkable aspect.
Also it's all ok they show up in some IDE took since they can easily
be useful in some other test.
Pedro Santos
On Thu, Jan 10, 2013 at 7:29 AM, Martin Grigorov mgrigo...@apache.orgwrote:
On Thu, Jan 10, 2013 at 12:58 AM, pe...@apache.org wrote:
Updated Branches:
refs/heads/sandbox/bookmarkable-callback-url fba8bddd9 - 1ec0b8b36
WICKET-4932: testing if the page is bookmarkable before to encode the
callback url for a component inside it
Project: http://git-wip-us.apache.org/repos/asf/wicket/repo
Commit: http://git-wip-us.apache.org/repos/asf/wicket/commit/1ec0b8b3
Tree: http://git-wip-us.apache.org/repos/asf/wicket/tree/1ec0b8b3
Diff: http://git-wip-us.apache.org/repos/asf/wicket/diff/1ec0b8b3
Branch: refs/heads/sandbox/bookmarkable-callback-url
Commit: 1ec0b8b3637feb19da4f87b485e96bfc7ce4e992
Parents: fba8bdd
Author: Pedro Santos pe...@apache.com
Authored: Wed Jan 9 20:58:40 2013 -0200
Committer: Pedro Santos pe...@apache.com
Committed: Wed Jan 9 20:58:40 2013 -0200
--
.../request/mapper/AbstractBookmarkableMapper.java |2 +-
.../mapper/AbstractBookmarkableMapperTest.java | 70
++-
.../request/mapper/BookmarkableMapperTest.java |6 ++
.../wicket/request/mapper/PackageMapperTest.java |6 ++
4 files changed, 80 insertions(+), 4 deletions(-)
--
http://git-wip-us.apache.org/repos/asf/wicket/blob/1ec0b8b3/wicket-core/src/main/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapper.java
--
diff --git
a/wicket-core/src/main/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapper.java
b/wicket-core/src/main/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapper.java
index 47ac13a..7e164dd 100644
---
a/wicket-core/src/main/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapper.java
+++
b/wicket-core/src/main/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapper.java
@@ -333,7 +333,7 @@ public abstract class AbstractBookmarkableMapper
extends AbstractComponentMapper
protected boolean checkPageClass(Class? extends
IRequestablePage
pageClass)
{
- return true;
+ return
Application.get().getPageFactory().isBookmarkable(pageClass);
}
public Url mapHandler(IRequestHandler requestHandler)
http://git-wip-us.apache.org/repos/asf/wicket/blob/1ec0b8b3/wicket-core/src/test/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapperTest.java
--
diff --git
a/wicket-core/src/test/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapperTest.java
b/wicket-core/src/test/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapperTest.java
index 693adec..705f14c 100644
---
a/wicket-core/src/test/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapperTest.java
+++
b/wicket-core/src/test/java/org/apache/wicket/request/mapper/AbstractBookmarkableMapperTest.java
@@ -17,13 +17,22 @@ package org.apache.wicket.request.mapper;
* limitations under the License.
*/
+import static org.hamcrest.CoreMatchers.notNullValue;
+import static org.hamcrest.CoreMatchers.nullValue;
+
import org.apache.wicket.MockPage;
import org.apache.wicket.WicketTestCase;
+import org.apache.wicket.markup.html.link.ILinkListener;
import org.apache.wicket.protocol.http.PageExpiredException;
import org.apache.wicket.request.Request;
import org.apache.wicket.request.Url;
+import org.apache.wicket.request.component.IRequestableComponent;
+import
org.apache.wicket.request.handler.BookmarkableListenerInterfaceRequestHandler;
+import
org.apache.wicket.request.handler.ListenerInterfaceRequestHandler;
+import org.apache.wicket.request.handler.PageAndComponentProvider;
import org.apache.wicket.request.mapper.info.PageInfo;
import org.junit.Assert;
+import org.junit.Before;
import org.junit.Test;
/**
@@ -34,7 +43,14 @@ public class AbstractBookmarkableMapperTest extends
WicketTestCase
private static final int NOT_RENDERED_COUNT = 2;
private static final int EXPIRED_ID = 2;
+ private AbstractBookmarkableMapperStub
Re: Need more context on the recreateMountedPagesAfterExpiry flag
Thx Martin, I cleaned up the code. I found one more issue, our bookmarkable mapper isn't testing if the page is bookmarkable or not at AbstractBookmarkableMapper#checkPageClass, which can make the mapper to create URLs that would be mapped to handlers that couldn't be resolved; already fixed it on the branch [1]. Also checked in some test expectations so you can have an idea of what will change [2]. There are more 50 exactly same expectation to be updated still :) Lets first make sure we are in the right path. 1 - https://github.com/apache/wicket/commit/1ec0b8b3637feb19da4f87b485e96bfc7ce4e992 2 - https://github.com/apache/wicket/commit/fba8bddd98da943ea74c9c04d90f17c75417c2fe Cheers, Pedro Santos On Wed, Jan 9, 2013 at 6:35 PM, Martin Grigorov mgrigo...@apache.orgwrote: I've commented in the commit thread. On Wed, Jan 9, 2013 at 9:53 PM, Pedro Santos pedros...@gmail.com wrote: Nice, I moved the logic to AbstractBookmarkableMapper in this branch: sandbox/bookmarkable-callback-url Let me know if the changes are ok before I start to update our test cases expectations to assert the new encoded URL. Please do these additional changes in the same branch so we can see what expectations have changed. Cheers, Pedro Santos On Sun, Jan 6, 2013 at 8:34 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi Pedro, I agree with you. https://issues.apache.org/jira/browse/WICKET-4686 is similar - the support for path parameters should be moved the same way too. On Mon, Jan 7, 2013 at 12:05 AM, Pedro Santos pedros...@gmail.com wrote: Hi, we have the recreateMountedPagesAfterExpiry flag at page settings to tell mounted mapper to encode enough info at callback urls so the mounted page can be recreated after expired and the callback be invoked. Why this flag works only for mounted pages? It looks we are segmenting too much a functionality. I think that a more consistent way of to honor such flag is by improving AbstractBookmarkableMapper itself and not only one of its extension (MountedMapper). Let me know what you think so we can improve bookmarkable mapper. Cheers, Pedro Santos -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/ -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/
Need more context on the recreateMountedPagesAfterExpiry flag
Hi, we have the recreateMountedPagesAfterExpiry flag at page settings to tell mounted mapper to encode enough info at callback urls so the mounted page can be recreated after expired and the callback be invoked. Why this flag works only for mounted pages? It looks we are segmenting too much a functionality. I think that a more consistent way of to honor such flag is by improving AbstractBookmarkableMapper itself and not only one of its extension (MountedMapper). Let me know what you think so we can improve bookmarkable mapper. Cheers, Pedro Santos
Re: [VOTE] Release Apache Wicket 6.2.0
+1 Pedro Santos On Fri, Oct 19, 2012 at 5:51 PM, Bruno Borges bruno.bor...@gmail.comwrote: +1 *Bruno Borges* (11) 99564-9058 *www.brunoborges.com* On Fri, Oct 19, 2012 at 5:42 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: +1 -igor On Fri, Oct 19, 2012 at 1:10 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: Please download the source distributions found on my people.apache.org distribution area linked below. I have included the signatures for both the source archives. This vote lasts for 72 hours minimum. [ ] Yes, release Apache Wicket 6.2.0 [ ] No, don't release Apache Wicket 6.2.0, because ... Distributions, changelog, keys and signatures can be found at: http://people.apache.org/~dashorst/wicket-6.2.0 Staging repository: https://repository.apache.org/content/repositories/orgapachewicket-143/ The binaries are available in the above link, as are a staging repository for Maven. Typically the vote is on the source, but should you find a problem with one of the binaries, please let me know, I can re-roll them some way or the other. Signature for apache-wicket-6.2.0.tar.gz: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iEYEABECAAYFAlCBq9cACgkQJBX8W/xy/UV1AwCg0nYpvPC2ImS6SN5o0uk9MgL5 uOYAn11kfDfnHB5+opoE5b9WiMjyEbK0 =o4SQ -END PGP SIGNATURE- Signature for apache-wicket-6.2.0.zip: -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (Darwin) iEYEABECAAYFAlCBq9cACgkQJBX8W/xy/UWsYwCg1I9cfQMgrY8eMsItZCiGzIii zREAnApoWxAlEv1k9R8ITzg+cIoVoZId =6oZp -END PGP SIGNATURE- Martijn
Re: [VOTE] Release Wicket 6.0.0 final
+1 Pedro Santos On Fri, Aug 24, 2012 at 11:44 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: +1 -igor On Thu, Aug 23, 2012 at 2:13 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: No fuzz, no separate RC releases. This is the real deal. Please vote for releasing the following source artifacts after checking them thoroughly for any misgivings: - tag: wicket-6.0.0 - release branch: builds/wicket-6.0.0 - artifacts: - apache-wicket-6.0.0.tar.gz - apache-wicket-6.0.0.zip They can be found at my p.a.o place: http://people.apache.org/~dashorst/wicket-6.0.0 I have uploaded the signatures and hashes as well. I also signed the release tag (wicket-6.0.0). Probably you can sign the tag as well if you find the release to be OK (I haven't done such a thing myself, so you need to look it up somewhere—Emond?) [ ] +1 release Apache Wicket 6.0.0 [ ] -1 don't release Apache Wicket 6.0.0 This vote lasts for 4 days, due to the weekend coming up. I'll tally tuesday morning CET. Martijn
Re: wicketAjaxGet in 1.6
Hi Daniel, if you want to call back a AJAX behaviour, you can also check the method AbstractDefaultAjaxBehavior#getCallbackScript() cheers, Pedro Santos 2012/6/20 Martin Dilger martin.dil...@googlemail.com Check the wiki to see what changed https://cwiki.apache.org/confluence/display/WICKET/Wicket+Ajax , there method names have been aligned, wicketajaxget now is wicket.ajax.get. regard Martin Dilger Am 19.06.2012 22:58 schrieb Daniel Simons daniel.simo...@gmail.com: I recently upgraded to 6.0.0-beta2 and it appears that wicketAjaxGet function has been removed from the API. Uncaught ReferenceError: wicketAjaxGet is not defined Is there a new way to get back to the server from javascript in 1.6? Thanks, Daniel Simons
Re: [Discuss] Bootstrap in wicket proper?
Hi guys, I'm planning to use bootstrap in a project using Wicket and I also think that https://github.com/l0rdn1kk0n/wicket-bootstrap requires some work before to be adopted. I outlined some thoughts about how it can be improved at https://github.com/l0rdn1kk0n/wicket-bootstrap/issues and would value your input on the matter. Cheers, Pedro Santos 2012/5/29 Martin Grigorov mgrigo...@apache.org On Tue, May 29, 2012 at 3:40 PM, Martijn Dashorst martijn.dasho...@gmail.com wrote: On Tue, May 29, 2012 at 2:24 PM, Martin Grigorov mgrigo...@apache.org wrote: - [...] should we provide a development mode integration with wro4j for less css? (I'd suggest using the maven plugin for deployment) what do you mean by development mode integration ? the maven plugin compiles from less to css at build time and at runtime you just refer to the css files Having a Wicket resource loader that integrates wro4j sounds more Wicket-y rather than depend on a maven plugin to run side-by-side. I haven't used wro4j myself, so I might be off base, but I figure that running Wicket in development mode, and having a Wicket resource loader that recompiles on changes and adjusts headers/caching etc accordingly gives us more control. As I hear that wro4j is quite slow, this wouldn't be my deployment mode of operation, but I can imagine that people also want to deploy with a Wicket wro4j resource loader. I see. This will work. Wro4J uses Rhino, that's why it is slow and memory consuming. Martijn -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com
Re: Please welcome Emond Papegaaij as a committer for Wicket
Welcome Emond! Pedro Henrique Oliveira dos Santos 2011/12/30 Peter Ertl pe...@gmx.org Welcome aboard, Emond ! :-) Am 30.12.2011 um 20:42 schrieb Sven Meier: Welcome :) Sven On 12/30/2011 04:26 PM, Emond Papegaaij wrote: Thank you all for the confidence you have in my work! I'm really proud to be a member of the Wicket team and am looking forward to get some real work done. I've already pushed some patches for a few tickets, broke most testcases and fixed them again, so it's looking good :) On Friday 30 December 2011 14:59:39 Martijn Dashorst wrote: I am pleased to announce that the Wicket PMC has voted Emond Papegaaij as our newest member. Please welcome him to our team! Welcome Emond! Enjoy the New Year with Wicket! Martijn
Re: [vote] release wicket 1.5.3
+1 Pedro Henrique Oliveira dos Santos 2011/11/11 Andrea Del Bene adelb...@ciseonweb.it: +1 This vote is to release wicket 1.5.3 Branch http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5.3 Artifacts http://people.apache.org/~ivaynberg/wicket-1.5.3/dist/ Maven repo https://repository.apache.org/content/repositories/orgapachewicket-172/ Changelog https://issues.apache.org/jira/secure/IssueNavigator.jspa?jqlQuery=fixVersion+%3D+%221.5.3%22+AND+project+%3D+WICKET This vote ends Saturday, November 12th at 1:00pm (GMT-8) Please test the release and offer your vote. The Wicket team!
Re: [vote] check wicket 1.5.0 artifacts
+1 2011/9/4 jcgarciam jcgarc...@gmail.com +1 On Sun, Sep 4, 2011 at 6:01 AM, Peter Ertl-3 [via Apache Wicket] ml-node+3788932-1962192371-65...@n4.nabble.com wrote: +1 Am 03.09.2011 um 22:49 schrieb Bruno Borges: + 1 On Sep 3, 2011 1:11 PM, Ron Smits [hidden email] http://user/SendEmail.jtp?type=nodenode=3788932i=0 wrote: +1 I Haven't Lost My Mind - It's Backed Up On Disk Somewhere On Sat, Sep 3, 2011 at 17:54, Igor Vaynberg [hidden email] http://user/SendEmail.jtp?type=nodenode=3788932i=1 wrote: +1 -igor On Fri, Sep 2, 2011 at 8:46 AM, Igor Vaynberg [hidden email] http://user/SendEmail.jtp?type=nodenode=3788932i=2 wrote: this is a vote to check 1.5.0 artifacts which include rc7 as base along with some non-functional changes made to readme/notice files. maven: https://repository.apache.org/content/repositories/orgapachewicket-017/ distro: http://people.apache.org/~ivaynberg/wicket-1.5.0/dist/ this vote will end with 3 +1 binding votes -igor -- If you reply to this email, your message will be added to the discussion below: http://apache-wicket.1842946.n4.nabble.com/vote-check-wicket-1-5-0-artifacts-tp3786438p3788932.html To start a new topic under Apache Wicket, email ml-node+1842946-398011874-65...@n4.nabble.com To unsubscribe from Apache Wicket, click here http://apache-wicket.1842946.n4.nabble.com/template/NamlServlet.jtp?macro=unsubscribe_by_codenode=1842946code=amNnYXJjaWFtQGdtYWlsLmNvbXwxODQyOTQ2fDEyNTYxMzc3ODY= . -- JC -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/vote-check-wicket-1-5-0-artifacts-tp3786438p3789372.html Sent from the Forum for Wicket Core developers mailing list archive at Nabble.com. -- Pedro Henrique Oliveira dos Santos
Re: Increase compatibility score for PageInstanceMapper (PIM) and BookmarkableMapper (BM) ?!
+1 to copy the compatibility score logic from BufferedResponseMapper to PIM 2011/8/29 Martin Grigorov mgrigo...@apache.org Hi, Currently the compatibility score of PIM and BM is 0 so that users' mappers have priority. I think this is a bit wrong because mounting more pages in YourApp#init() will increase the time to get to PIM's mapRequest(). Most of the time stateful apps work with PIM because every callback url is processed by PIM (e.g. wicket/page?3-1.IBehaviorListener-form-button) I.e. there is no need to ask N MountedMappers before PIM when the chance that the request is for PIM is quite high. I suggest to make its #getCompatibilityScore() logic the same as BufferedResponseMapper, i.e. if the request url starts with 'wicket/page' then the score should be high (Int.MAX_VALUE). I see no problems with that for small apps but I see big gain for apps like Topicus' with 1000+ page (@Topicus devs: are they mounted pages?) The same is valid for BM. What do you think ? -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- Pedro Henrique Oliveira dos Santos
Re: Increase compatibility score for PageInstanceMapper (PIM) and BookmarkableMapper (BM) ?!
Helps a bit because it will be tested first in the list of MapperWithScore in CompoundRequestMapper 2011/8/29 Igor Vaynberg igor.vaynb...@gmail.com you can do this once in SystemMapper. if url starts with the namespace give it a high value. however, this wont solve the problem where you have thousands of mappers and we have to try them all. -igor On Mon, Aug 29, 2011 at 12:07 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, Currently the compatibility score of PIM and BM is 0 so that users' mappers have priority. I think this is a bit wrong because mounting more pages in YourApp#init() will increase the time to get to PIM's mapRequest(). Most of the time stateful apps work with PIM because every callback url is processed by PIM (e.g. wicket/page?3-1.IBehaviorListener-form-button) I.e. there is no need to ask N MountedMappers before PIM when the chance that the request is for PIM is quite high. I suggest to make its #getCompatibilityScore() logic the same as BufferedResponseMapper, i.e. if the request url starts with 'wicket/page' then the score should be high (Int.MAX_VALUE). I see no problems with that for small apps but I see big gain for apps like Topicus' with 1000+ page (@Topicus devs: are they mounted pages?) The same is valid for BM. What do you think ? -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com -- Pedro Henrique Oliveira dos Santos
Re: [vote] promote 1.5-RC7 to 1.5.0
+1 I'm already using successfully 1.5-RC7 in production apps. 2011/8/29 Igor Vaynberg igor.vaynb...@gmail.com +1 -igor On Mon, Aug 29, 2011 at 1:39 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: this vote is to promote 1.5-RC7 to 1.5.0. current bug fixes already made to trunk will be part of 1.5.1 this vote ends Thursday, September 1st at 2pm GMT-7 -igor -- Pedro Henrique Oliveira dos Santos
Re: Please welcome Sven Meier to the Wicket Team
Welcome! On Wed, Jun 29, 2011 at 5:19 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: The Wicket PMC is proud to have Sven Meier join our team. Sven has been active with Wicket since 2007, helping out on the mailing lists and has provided numerous patches. Welcome Sven! Martijn -- Pedro Henrique Oliveira dos Santos
Re: [vote] release 1.5-RC5
+1 On Thu, Jun 16, 2011 at 8:34 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: This vote is to release wicket 1.5-RC5 Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-RC5/ Artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-RC5/dist/ Maven repo: https://repository.apache.org/content/repositories/orgapachewicket-022/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12316423 This vote ends Thursday, March 19st at 5:00pm (GMT-8) Please test the release and offer your vote. The Wicket team! -- Pedro Henrique Oliveira dos Santos
Re: [VOTE] Release Wicket 1.5-RC4.2
+1 On Tue, May 10, 2011 at 11:38 AM, Andrea Del Bene adelb...@ciseonweb.it wrote: +1 for me. This vote is to release wicket 1.5-RC4.2. Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-RC4.2/ Artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-RC4.2/dist/ Maven repo: https://repository.apache.org/content/repositories/orgapachewicket-030 Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12316330 This vote ends Thursday, May 10th at 12:00pm (GMT+2) Please test the release and offer your vote. The Wicket team! -- Pedro Henrique Oliveira dos Santos
Re: Missing XML declaration in error page.
He Petr, by add the prolog in the html files those pages are not correctly rendered in IE8, IMO opinion the best option we have now is to move the Apache header in those files to inside the html tag plus restore the prolog [1]. Devs, I don't know if we can freely move the Apache header to outside the top of our files. Also reading the header politic site [2], I don't get if we can simple remove it. Does the exception page fits the without any degree of creativity requirement since it has no programming code? It is just static markup... 1 - https://issues.apache.org/jira/browse/WICKET-3566 2 - http://www.apache.org/legal/src-headers.html https://issues.apache.org/jira/browse/WICKET-3566 On Thu, Apr 21, 2011 at 2:26 AM, Petr Gladkikh petrg...@gmail.com wrote: I am trying to upgrage from wicket 1.4.1 to 1.4.17 and have following problem. In our application we configure getMarkupSettings().setThrowExceptionOnMissingXmlDeclaration(true); This prevents all Wicket's default pages from rendering since none of them contain XML prolog anymore. E.g. none of HTML files in apache-wicket-1.4.17/src/wicket/src/main/java/org/apache/wicket/markup/html/pages contain XML declaration prolog. When wicket tries to show error page exception is thrown. Top of stack trace is: at org.apache.wicket.markup.MarkupParser.parse(MarkupParser.java:280) at org.apache.wicket.markup.loader.SimpleMarkupLoader.loadMarkup(SimpleMarkupLoader.java:52) at org.apache.wicket.markup.loader.InheritedMarkupMarkupLoader.loadMarkup(InheritedMarkupMarkupLoader.java:62) at org.apache.wicket.markup.loader.DefaultMarkupLoader.loadMarkup(DefaultMarkupLoader.java:55) at org.apache.wicket.markup.MarkupCache.loadMarkup(MarkupCache.java:465) at org.apache.wicket.markup.MarkupCache.loadMarkupAndWatchForChanges(MarkupCache.java:561) at org.apache.wicket.markup.MarkupCache.getMarkup(MarkupCache.java:325) at org.apache.wicket.markup.MarkupCache.getMarkupStream(MarkupCache.java:216) at org.apache.wicket.MarkupContainer.getAssociatedMarkupStream(MarkupContainer.java:351) at org.apache.wicket.Page.onRender(Page.java:1587) at org.apache.wicket.Component.render(Component.java:2521) at org.apache.wicket.Page.renderPage(Page.java:932) I can work around by switching these exceptions off. But I think that the problem should be fixed otherwise since even when these exceptions are switched off following message is written to log: log.debug(The markup file does not have a XML declaration prolog: + markupResourceData.getResource() + . It is more save to use it. E.g. ?xml version=\1.0\ encoding=\UTF-8\ ?); -- Petr Gladkikh - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org -- Pedro Henrique Oliveira dos Santos
Wicketstuff commit access
Hi, I want to contribute to minis project with a new request handler responsible to respond some table component as a XLS file. I already forked the project and sent 2 examples[1], next I will to write some doc in the wiki also. [1] https://github.com/pedrosans/core/commit/5b5b1e0e3447acc9367028e493c4feb070d2ab97 -- Pedro Henrique Oliveira dos Santos
Re: [vote] release wicket 1.5-RC3
+1 On Tue, Mar 29, 2011 at 5:27 AM, Andrea Del Bene adelb...@ciseonweb.itwrote: +1 to release works just fine for me. On behalf of Igor Vaynberg: This vote is to release wicket 1.5-RC3 Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-RC3/ Artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-RC3/dist/ Maven repo: https://repository.apache.org/content/repositories/orgapachewicket-046 Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12316220 This vote ends Thursday, March 31st at 1:00am (GMT-8) Please test the release and offer your vote. The Wicket team! -- Pedro Henrique Oliveira dos Santos
Re: 1.5 visitParents problem?
Component#visitParents expects Component as the type to be visited, IMO
should expect the same type of the first parameter.
On Tue, Mar 29, 2011 at 5:22 AM, nino martinez wael
nino.martinez.w...@gmail.com wrote:
why is this not valid?
message.getReporter().visitParents(Form.class, new
IVisitorForm, Void() {
@Override
public void component(Form object, IVisitVoid
visit) {
// TODO Auto-generated method stub
}
});
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
Re: [vote] release wicket 1.4.17
+1 just compiled the branch, played on wicket-examples, it is all fine. As a side note, I played a bit at wicket-examples on wicket stuff also and some repeater examples are not working. e.g. OrderedRepeatingView example at http://wicketstuff.org/wicket14/repeater/ After the 1.4.17 being released I will test it again. On Mon, Mar 28, 2011 at 5:10 AM, Martin Grigorov mgrigo...@apache.orgwrote: On behalf of Igor Vaynberg: This vote is to release wicket 1.4.17. This is a bugfix release on the 1.4.x (stable) branch. Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.17/ Artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.17/dist Maven repo: https://repository.apache.org/content/repositories/orgapachewicket-045/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12316219 This vote ends Thursday, March 31st at 1:00am (GMT-8) Please test the release and offer your vote. The Wicket team -- Pedro Henrique Oliveira dos Santos
Re: HEADS UP: A change in web.xml setup is required
PersistentPageManager$SessionEntry is the serializable piece of Wicket inside the servlet session, IMO it should serialize/deserialize regardless of the Wicket lifecycle. Can the DefaultPageStore be changed to be a singleton an not a per application instance? On Fri, Mar 18, 2011 at 12:42 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: i would say that the lack of response shows that people dont care about a couple more xml lines they have to add to web.xml once and forget about. -igor On Fri, Mar 18, 2011 at 7:47 AM, Martin Grigorov mgrigo...@apache.org wrote: On Thu, Mar 17, 2011 at 10:54 PM, Martin Grigorov mgrigo...@apache.org wrote: Hi, To solve https://issues.apache.org/jira/browse/WICKET-3470 we need to introduce ServletContextListener in Wicket. In comment https://issues.apache.org/jira/browse/WICKET-3470?focusedCommentId=13008166page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13008166Idescribed a proposal how we can change web.xml configuration to make it working. The proposal is based on a discussion between me and Igor in IRC. This is a rather big change and we need more opinions, so please share if you have ideas. By big here I mean conceptually, not code wise. Technically it doesn't seem to be big or complex. --martin-g P.S. I'm interested to understand why there is no such problem with Wicket 1.4? I guess sessions in 1.4 are cleared earlier and never persisted between web container restarts. -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/ -- Martin Grigorov jWeekend Training, Consulting, Development http://jWeekend.com http://jweekend.com/ -- Pedro Henrique Oliveira dos Santos
Re: [vote] release wicket 1.5-rc2
+1 On Tue, Feb 22, 2011 at 1:35 PM, Jeremy Thomerson jer...@wickettraining.com wrote: +1 release On Tue, Feb 22, 2011 at 10:31 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: +1 -igor On Sun, Feb 20, 2011 at 8:34 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: This vote is to release wicket 1.5-rc2 Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.5-rc2/ Artifacts: http://people.apache.org/~ivaynberg/wicket-1.5-rc2/dist Maven repo: https://repository.apache.org/content/repositories/orgapachewicket-031/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12316059 This vote ends Wednesday, February 23 at 9:00am (GMT-8) Please test the release and offer your vote. -igor -- Jeremy Thomerson http://wickettraining.com *Need a CMS for Wicket? Use Brix! http://brixcms.org* -- Pedro Henrique Oliveira dos Santos
Re: [vote] release wicket 1.4.16
+1 On Tue, Feb 22, 2011 at 1:30 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: +1 -igor On Sun, Feb 20, 2011 at 8:33 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: This vote is to release wicket 1.4.16. This is a bugfix release on the 1.4.x (stable) branch. Branch: http://svn.apache.org/repos/asf/wicket/branches/wicket-1.4.16/ Artifacts: http://people.apache.org/~ivaynberg/wicket-1.4.16/dist Maven repo: https://repository.apache.org/content/repositories/orgapachewicket-031/ Changelog: https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12310561version=12316020 This vote ends Wednesday, February 23rd at 9:00am (GMT-8) Please test the release and offer your vote. -igor -- Pedro Henrique Oliveira dos Santos
Fwd: [jira] Commented: (WICKET-3424) Modal with a fragment containing 2 forms, 2nd form doesn't properly submit.
I think the Form or even the Component needs another property to make visible the hierarchy mismatch between Wicket components and its HTML. The problem is that the modal window components has its markup on top of the markup hierarchy, but the same is not true for the component hierarchy. Some time ago, I coded in the progress bar some test like: if getParent(ModalWindow) != null do ... This is horrible (the progress bar can't be move out from wicket-extensions for now), but I couldn't figure out at the time a better way of detect the hierarchy mismatch and respond appropriately (there was an bug going on). If the component had this property, ModalWindow would had it set to true, Form would test its parents to see if there is an mismatch, and decide to output an form or an div tag. Pros - user can decide to have or not an nested form inside the modal window - currently it is mandatory to be nested, root forms inside the modal window output invalid markup - progress bar can stop depend on being in the same project as ModalWindow - easy to create custom components that behave like the modal window -- Forwarded message -- From: Martin Grigorov (JIRA) j...@apache.org Date: Mon, Feb 14, 2011 at 5:52 PM Subject: [jira] Commented: (WICKET-3424) Modal with a fragment containing 2 forms, 2nd form doesn't properly submit. To: comm...@wicket.apache.org [ https://issues.apache.org/jira/browse/WICKET-3424?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12994453#comment-12994453] Martin Grigorov commented on WICKET-3424: - The issue is easily reproducible. I think range.createContextualFragment() doesn't create the form because there is another form that wraps the fragment (the modal window's form) and since nesting of forms is not allowed by spec this method doesn't create the new one. I have no idea how to resolve it for now. There are several other tickets about removing the modal window's form but this is a tough component, who knows what will break when touch it. Modal with a fragment containing 2 forms, 2nd form doesn't properly submit. --- Key: WICKET-3424 URL: https://issues.apache.org/jira/browse/WICKET-3424 Project: Wicket Issue Type: Bug Components: wicket-extensions Affects Versions: 1.4.15 Environment: Windows xp pro, java 1.6 Reporter: Nathan Collette Labels: form, modal, multiple Attachments: multipleFormsInModal.zip Click a link that opens a modal window with a fragment containing 2 forms. The forms visibility is switched on or off. An error is given when the second form is made visible and a submit is made on it. Trying to submit for with id id that is not in document -- This message is automatically generated by JIRA. - For more information on JIRA, see: http://www.atlassian.com/software/jira -- Pedro Henrique Oliveira dos Santos
Re: Reducing JIRA spam
fine by me also, can hudson integration messages be disabled also? On Tue, Feb 8, 2011 at 8:58 AM, Martijn Dashorst martijn.dasho...@gmail.com wrote: It appears that we can reduce the amount of spam JIRA sends to our commits list by telling it not to send notifications when the fix-in version is modified. I'd like that feature to be enabled... Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com -- Pedro Henrique Oliveira dos Santos
Re: StatelessForm growing url when there is errorvalidation
There is one: https://issues.apache.org/jira/browse/WICKET-3438
It was fixed, but I don't know if it was the right fix, why Wicket 1.4 is
cloning the request parameters to bookmarkable targets in
RequestCycle#urlFor(Component,RequestListenerInterface,ValueMap)
If it just use those on params ValueMap this problem would not happen.
On Wed, Feb 9, 2011 at 2:27 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
hrm. i thought this was fixed a long time ago. please file a bug with
a quickstart.
-igor
On Wed, Feb 9, 2011 at 2:09 AM, Olivier Dutrieux
olivier.dutri...@pasteur.fr wrote:
Hello,
I have a strange problem with statelessForm :
I would like a stateless application with 2 statelessForm and with somes
required validators on form :
public class HomePage extends WebPage {
private static final long serialVersionUID = 1L;
public HomePage(final PageParameters parameters) {
super(parameters);
setVersioned(false);
Form form1 = new StatelessForm(form1) {
@Override
protected void onSubmit() {
setResponsePage(ResultPage.class);
}
};
form1.add(new TextFieldString(input1).setRequired(true));
add(form1);
Form form2 = new StatelessForm(form2) {
@Override
protected void onSubmit() {
setResponsePage(ResultPage.class);
}
};
form2.add(new TextFieldString(input1).setRequired(true));
add(form2);
}
}
The problem is when I submit alternatively each form (I don't fill the
Textfield required intentionally), the url growing like this :
1st submit :
http://localhost:8080/Wicket-Test/HomePage.html?wicket:interface=:0:form2::IFormSubmitListener
::
2nd submit :
http://localhost:8080/Wicket-Test/HomePage.html?form22_hf_0=wicket:interface=:0:form1::IFormSubmitListener
::
3th submit :
http://localhost:8080/Wicket-Test/HomePage.html?form22_hf_0=form12_hf_0=wicket:interface=:0:form2::IFormSubmitListener
::
4th submit :
http://localhost:8080/Wicket-Test/HomePage.html?form22_hf_0=form22_hf_0=form12_hf_0=wicket:interface=:0:form1::IFormSubmitListener
::
...
Is there a solution to solve this problem ?
Best regards
I use wicket 1.4.15
http://apache-wicket.1842946.n4.nabble.com/file/n3296950/Wicket-test.rar
Wicket-test.rar
-
Duto
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/StatelessForm-growing-url-when-there-is-errorvalidation-tp3296950p3296950.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
Re: StatelessForm growing url when there is errorvalidation
My mistake, RequestCycle is cloning the page parameters, not in every case
it will be those in request.
On Wed, Feb 9, 2011 at 2:59 PM, Pedro Santos pedros...@gmail.com wrote:
There is one: https://issues.apache.org/jira/browse/WICKET-3438
It was fixed, but I don't know if it was the right fix, why Wicket 1.4 is
cloning the request parameters to bookmarkable targets in
RequestCycle#urlFor(Component,RequestListenerInterface,ValueMap)
If it just use those on params ValueMap this problem would not happen.
On Wed, Feb 9, 2011 at 2:27 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote:
hrm. i thought this was fixed a long time ago. please file a bug with
a quickstart.
-igor
On Wed, Feb 9, 2011 at 2:09 AM, Olivier Dutrieux
olivier.dutri...@pasteur.fr wrote:
Hello,
I have a strange problem with statelessForm :
I would like a stateless application with 2 statelessForm and with somes
required validators on form :
public class HomePage extends WebPage {
private static final long serialVersionUID = 1L;
public HomePage(final PageParameters parameters) {
super(parameters);
setVersioned(false);
Form form1 = new StatelessForm(form1) {
@Override
protected void onSubmit() {
setResponsePage(ResultPage.class);
}
};
form1.add(new TextFieldString(input1).setRequired(true));
add(form1);
Form form2 = new StatelessForm(form2) {
@Override
protected void onSubmit() {
setResponsePage(ResultPage.class);
}
};
form2.add(new TextFieldString(input1).setRequired(true));
add(form2);
}
}
The problem is when I submit alternatively each form (I don't fill the
Textfield required intentionally), the url growing like this :
1st submit :
http://localhost:8080/Wicket-Test/HomePage.html?wicket:interface=:0:form2::IFormSubmitListener
::
2nd submit :
http://localhost:8080/Wicket-Test/HomePage.html?form22_hf_0=wicket:interface=:0:form1::IFormSubmitListener
::
3th submit :
http://localhost:8080/Wicket-Test/HomePage.html?form22_hf_0=form12_hf_0=wicket:interface=:0:form2::IFormSubmitListener
::
4th submit :
http://localhost:8080/Wicket-Test/HomePage.html?form22_hf_0=form22_hf_0=form12_hf_0=wicket:interface=:0:form1::IFormSubmitListener
::
...
Is there a solution to solve this problem ?
Best regards
I use wicket 1.4.15
http://apache-wicket.1842946.n4.nabble.com/file/n3296950/Wicket-test.rar
Wicket-test.rar
-
Duto
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/StatelessForm-growing-url-when-there-is-errorvalidation-tp3296950p3296950.html
Sent from the Users forum mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
--
Pedro Henrique Oliveira dos Santos
Re: final Page.onInitialize()
I think onInitialize is playing the role of the Component#addNotify method from awt framework. It is an useful callback to not root components, were they can adjust their sate based on the existing component tree. And if we rename it to onAddedToComponentTree or addNotify as in the awt framework? After doing so we can even recreate the onInitialize method but as a callback for an fully constructed component. The problem about this idea is that we would end up increasing the API, maybe without the need. Anyway I'm 1+ to delay the onInitialize call until the first onConfigure call, because makes sense to provide an callback from a more mature component state. On Tue, Feb 1, 2011 at 2:52 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: apparently some people also use it as a post-construct callback, which sort of makes sense. for example, to call overridable factory methods, which you cannot do from the constructor. the solution is to delay all calls to oninitialize until just before the very first call to onconfigure. i have mixed feelings about it because essentially when instantiating a new page you get an incomplete/lazy-initialized object and it is hard to have any useful methods on it that configure it further. -igor On Tue, Feb 1, 2011 at 3:35 AM, Pedro Santos pedros...@gmail.com wrote: onInitialize is only there to provide an place on the component code where you can rely on a path to the page from the component. It is useless inside an page. On Tue, Feb 1, 2011 at 9:25 AM, tetsuo ronald.tet...@gmail.com wrote: Overriding onInitialize() on Pages certainly may cause some problems, if you mix adding components there and in constructors in the same class hierarchy, but it will work with some care. I'm using onInitialize() to build Pages, because, in the infrastructure already built in a project I'm working on, I have to instantiate Pages to determine if a link to it is enabled or not. I don't use its 'construction', I don't need components. I just instantiate it to call a method 'hasPermission()' on it. Well, please don't tell me I shouldn't do it, it works and works well. The only problem is that in 1.5 the method is final on Pages. Is there any workaround? Would you consider reverting this change? Or will I have to stay with 1.4 forever? Tetsuo -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
Re: final Page.onInitialize()
onInitialize is only there to provide an place on the component code where you can rely on a path to the page from the component. It is useless inside an page. On Tue, Feb 1, 2011 at 9:25 AM, tetsuo ronald.tet...@gmail.com wrote: Overriding onInitialize() on Pages certainly may cause some problems, if you mix adding components there and in constructors in the same class hierarchy, but it will work with some care. I'm using onInitialize() to build Pages, because, in the infrastructure already built in a project I'm working on, I have to instantiate Pages to determine if a link to it is enabled or not. I don't use its 'construction', I don't need components. I just instantiate it to call a method 'hasPermission()' on it. Well, please don't tell me I shouldn't do it, it works and works well. The only problem is that in 1.5 the method is final on Pages. Is there any workaround? Would you consider reverting this change? Or will I have to stay with 1.4 forever? Tetsuo -- Pedro Henrique Oliveira dos Santos
Re: [discuss] How to resolve wicket aggregate classes / sources jar issues
Spring distribution hasn't the spring.jar anymore: https://fisheye.springsource.org/browse/spring-framework/trunk/build-spring-framework/resources/readme.txt?r=2858r=2854r=2940r=3872 On Tue, Jan 25, 2011 at 10:27 AM, tetsuo ronald.tet...@gmail.com wrote: When you don't use maven. For example, most Ant-based projects I've worked with use spring.jar, instead of spring-core.jar+spring-tx.jar+spring-jdbc.jar+spring-orm.jar+spring-web.jar+spring-webmvc.jar+spring-beans.jar+spring-context.jar+spring-expression.jar+spring-aop.jar+spring-aspects.jar+spring-hibernate3.jar+aopalliance.jar With maven this is a non-issue, since you'd simply declare spring-hibernate3 and spring-webmvc, and everything else would come as transitive dependencies, but to do it by hand is pretty daunting, especially for beginners trying out the library. Tetsuo On Tue, Jan 25, 2011 at 9:11 AM, Max Bowsher m...@f2s.com wrote: On 25/01/11 10:44, tetsuo wrote: What about having the aggregated jar only for the bundle (zip) download, not to be available in maven central? In my experience aggregated jars tend to prove more of confusion in the end, than a help, with users who misunderstand and end up with multiple copies of a classes on their classpath. Are there any build/deployment scenarios where adding several jars to a classpath isn't just as easy as adding one? Max. -- Pedro Henrique Oliveira dos Santos
Re: Annotation for classes which should not be serialized
Currently the serializable checker is only triggered when an NotSerializableException was thrown. Means that @WicketDontSerialize annotated beams will not get detected only by changing the SerializableChecker. Perhaps an IObjectStreamFactory that return an ObjectInputStream doing the check? Would work, and user can plug by Objects.setObjectStreamFactory(new ObjectInputStreamThatChecksFor WicketDontSerializeAnnotation()); On Tue, Jan 25, 2011 at 1:31 PM, Martin Grigorov martin.grigo...@gmail.comwrote: Hi, Someone just asked in ##wicket something like: for some reason my entity is serialized. it is wrapped in LDM, but still something went wrong and instead just the entity id, the whole entity is serialized https://gist.github.com/795052 Here are suggest introducing an annotation which serves like JSR-305's @NotNill - @WicketDontSerialize. I.e. if an object which class is annotated with this marker is sent to SerializableChecker#check() then throw an exception with the nice path to the object saying this class may be Serializable but it shouldn't be serialized. This way hopefully the user will see when there is a leak reference which ties the object in the serialization. Writing this email I realize that we can make it even better by extending the checker to use pluggable sub-checkers: checker for implements Serializable, checker based on an annotation, based on a black/white list, or some other logic. This way the user app can pass a checker that disallows classes coming from third party libs (i.e. cannot be annotated). In DEV mode it can be replaced with no-op checker. What do you think ? martin-g -- Pedro Henrique Oliveira dos Santos
Fwd: wicket nested form and modal
At the linked thread Matej wrote about serialize the parent form of the
modal inner form on its submit. I think it would end up sending unnecessary
data back to server, since it is quite safe assume that user did not change
anything outside the modal window.
The FormComponent#inputChanged method are assuming that if the form
component is nullable it can live with the nullified rawInput. But it is not
true, it would be better assume when form input name is not set in request
parameters that there is no raw input. I tested this change on 1.4, fix the
quickstart and all tests on the wicket 1.4.
I'll give this change more test, but if you already know an potential
problem on it give me a tip.
-- Forwarded message --
From: Martin Makundi martin.maku...@koodaripalvelut.com
Date: Mon, Jan 24, 2011 at 3:31 AM
Subject: Re: wicket nested form and modal
To: us...@wicket.apache.org
Here is a workaround
http://www.mail-archive.com/users@wicket.apache.org/msg35946.html
**
Martin
2011/1/24 Clément Tamisier clement.tamis...@gmail.com:
Hi, I have something strange with wicket 1.4 and I don't find what.
I have 2 nested forms. The inner form (form2) is in a modal window, and
when
I validate this form (form2) the checkbox of main form (form1) become
unchecked (which is initially checked).
to test: click on click and submit the form of modal window showed -
checkbox become unchecked.
PS : if I uncheck my checkbox manually and retry, it's works.
I include this this project in the mail. You can launch it with: mvn
clean
compile jetty:run
Do you have any ideas. Thank you very much.
Clément
HelloWorld.java
public class HelloWorld extends WebPage {
private CheckBox checkbox;
private ModalWindow modalWindow;
@SuppressWarnings(serial)
public HelloWorld() {
FormObject form = new FormObject(form1);
add(new AjaxLinkObject(click) {
@Override
public void onClick(AjaxRequestTarget target) {
modalWindow.show(target);
}
});
checkbox = new CheckBox(checkbox, new ModelBoolean(true));
checkbox.add(new OnChangeAjaxBehavior() {
@Override
protected void onUpdate(AjaxRequestTarget target) {
System.out.println(checkbox set to :+checkbox.getModelObject());
}
});
checkbox.setOutputMarkupId(true);
modalWindow = new ModalWindow(modal);
SubmitPanel panel = new SubmitPanel(content, checkbox, modalWindow);
modalWindow.setContent(panel);
form.add(checkbox);
form.add(modalWindow);
form.add(new AjaxButton(submitForm) {
@Override
protected void onSubmit(AjaxRequestTarget target, Form? form) {
System.out.println(on submit checkbox is :+checkbox.getModelObject());
}
});
add(form);
}
}
HelloWorld.html
html
body
form wicket:id=form1
div wicket:id=modal/div
input type=checkbox wicket:id=checkbox /
input type=submit wicket:id=submitForm /
/form
a wicket:id=clickclick/a
/body
/html
SubmitPanel.java
public class SubmitPanel extends Panel{
public SubmitPanel(String id, final CheckBox checkbox, final ModalWindow
modalWindow) {
super(id);
FormObject form =new FormObject(form2);
form.add(new AjaxButton(submitForm2) {
@Override
protected void onSubmit(AjaxRequestTarget target, Form? form) {
checkbox.setModelObject(true);
target.addComponent(checkbox);
modalWindow.close(target);
}
});
add(form);
}
}
SubmitPanel.html
wicket:panel
form wicket:id=form2
input type=submit wicket:id=submitForm2 /
/form
/wicket:panel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
Re: wicket nested form and modal
Linking the thread with the existing ticket:
https://issues.apache.org/jira/browse/WICKET-1826
https://issues.apache.org/jira/browse/WICKET-1826I attached the described
patch in it.
On Mon, Jan 24, 2011 at 5:30 PM, Pedro Santos pedros...@gmail.com wrote:
At the linked thread Matej wrote about serialize the parent form of the
modal inner form on its submit. I think it would end up sending unnecessary
data back to server, since it is quite safe assume that user did not change
anything outside the modal window.
The FormComponent#inputChanged method are assuming that if the form
component is nullable it can live with the nullified rawInput. But it is not
true, it would be better assume when form input name is not set in request
parameters that there is no raw input. I tested this change on 1.4, fix the
quickstart and all tests on the wicket 1.4.
I'll give this change more test, but if you already know an potential
problem on it give me a tip.
-- Forwarded message --
From: Martin Makundi martin.maku...@koodaripalvelut.com
Date: Mon, Jan 24, 2011 at 3:31 AM
Subject: Re: wicket nested form and modal
To: us...@wicket.apache.org
Here is a workaround
http://www.mail-archive.com/users@wicket.apache.org/msg35946.html
**
Martin
2011/1/24 Clément Tamisier clement.tamis...@gmail.com:
Hi, I have something strange with wicket 1.4 and I don't find what.
I have 2 nested forms. The inner form (form2) is in a modal window, and
when
I validate this form (form2) the checkbox of main form (form1) become
unchecked (which is initially checked).
to test: click on click and submit the form of modal window showed -
checkbox become unchecked.
PS : if I uncheck my checkbox manually and retry, it's works.
I include this this project in the mail. You can launch it with: mvn
clean
compile jetty:run
Do you have any ideas. Thank you very much.
Clément
HelloWorld.java
public class HelloWorld extends WebPage {
private CheckBox checkbox;
private ModalWindow modalWindow;
@SuppressWarnings(serial)
public HelloWorld() {
FormObject form = new FormObject(form1);
add(new AjaxLinkObject(click) {
@Override
public void onClick(AjaxRequestTarget target) {
modalWindow.show(target);
}
});
checkbox = new CheckBox(checkbox, new ModelBoolean(true));
checkbox.add(new OnChangeAjaxBehavior() {
@Override
protected void onUpdate(AjaxRequestTarget target) {
System.out.println(checkbox set to :+checkbox.getModelObject());
}
});
checkbox.setOutputMarkupId(true);
modalWindow = new ModalWindow(modal);
SubmitPanel panel = new SubmitPanel(content, checkbox, modalWindow);
modalWindow.setContent(panel);
form.add(checkbox);
form.add(modalWindow);
form.add(new AjaxButton(submitForm) {
@Override
protected void onSubmit(AjaxRequestTarget target, Form? form) {
System.out.println(on submit checkbox is :+checkbox.getModelObject());
}
});
add(form);
}
}
HelloWorld.html
html
body
form wicket:id=form1
div wicket:id=modal/div
input type=checkbox wicket:id=checkbox /
input type=submit wicket:id=submitForm /
/form
a wicket:id=clickclick/a
/body
/html
SubmitPanel.java
public class SubmitPanel extends Panel{
public SubmitPanel(String id, final CheckBox checkbox, final ModalWindow
modalWindow) {
super(id);
FormObject form =new FormObject(form2);
form.add(new AjaxButton(submitForm2) {
@Override
protected void onSubmit(AjaxRequestTarget target, Form? form) {
checkbox.setModelObject(true);
target.addComponent(checkbox);
modalWindow.close(target);
}
});
add(form);
}
}
SubmitPanel.html
wicket:panel
form wicket:id=form2
input type=submit wicket:id=submitForm2 /
/form
/wicket:panel
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pedro Henrique Oliveira dos Santos
--
Pedro Henrique Oliveira dos Santos
Turn focus log info optional and false by default in the wicket-ajax.js
Often Wicket Ajax Debug Window has a lot of lines like: INFO: focus removed from INFO: focus set on INFO: focus removed from INFO: focus set on INFO: focus removed from INFO: focus set on and you have to navigate some to find AJAX processing info messages that is the majority of devs use cases. Wouldn't the console be simpler to read without those info? -- Pedro Henrique Oliveira dos Santos
Re: more explicit handling of null values - yay or nay?
Not simplifing (not complicating also), but making clear that an specific parameter is optional, it can prevent some runtime NPE by exposing in a very clear way at development time that some parameter may be null. On Wed, Jan 5, 2011 at 3:53 PM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: How would it simplify actual code? ** Martin 2011/1/5 Igor Vaynberg igor.vaynb...@gmail.com: ive recently ran into a few cases where while implementing ajaxfallbacklink i forgot to test the passed in request target for null, causing NPEs when the app was accessed from browsers where ajax failed for whatever reason. with all this talk of scala recently i figured why not try and translate one of the feature i really like in scala Option/Null/Some to our code base. i came up with a simple value class: https://gist.github.com/c38456ee75fed541c932 and changed the ajaxfallbacklink to use it https://gist.github.com/2f648c7feacacf18fc40 the cascade from this change was pretty impressive, a lot of places in our code support passing a possibly null request target but make no mention of it: https://gist.github.com/d9933e24c21f061c6ac2 so advantages: makes possible null value handling explicit no more checking the javadoc to see if the method supports null as a parameter value or ever returns a null an api break before 1.5 rc1 i think overall makes lives of wicket users easier disadvantages: a bit wordier code an api break just about when we are ready to release 1.5 m4/rc1 whatever we call it yay or nay? obviously if we say yay there are a lot more places in our code that can benefit from this -igor -- Pedro Henrique Oliveira dos Santos
Re: Tester loses all submit parameters after ajax call
Hi Zilvinas, thank u for the test! We actually have different issues. I described mine at https://issues.apache.org/jira/browse/WICKET-3272 The tester setup the next request cycle just after process the request triggered by the mocked AJAX event. It differs from 1.4 where the request setup was made just before the next processRequestCycle. So in the 1.5 you don't need methods like setParametersForNextRequest, because the current request set on tester is the one that will be dispatched. So if you want to access it after process the request, you need to use methods like getLastRequest. I'm sending your test case back with mentioned changes. On Sat, Dec 18, 2010 at 4:14 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Pedro, One more thing, i have updated WicketTesterTest, which fails with issue i have described. I'm attaching patch file, maybe it will be of any help for you. On Sat, Dec 18, 2010 at 8:07 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Pedro, Thanks for reply. Yeah i have workaround for this - i just reset submit parameters from last request to current request. On Sat, Dec 18, 2010 at 6:30 PM, Pedro Santos pedros...@gmail.comwrote: Hi Zilvinas, I'm taking a look at your described issue, for now try to set the parameter as a POST one. On Sat, Dec 18, 2010 at 2:15 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Hello, I'm experiencing strange behavior with WicketTester in 1.5 when using FormTester with ajax events. It works as follows: 1. Set some value via the FormTester to input field. 2. Invoke ajax event. In my case behaviour is AjaxFormComponentUpdatingBehavior. 3. After the ajax event was executed input fields getInput method returns null. And it should, since there are no submit parameters available anymore. Is that bug? It was working in 1.4, so my guess that its bug. Greetings, Zilvinas. -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
Re: Tester loses all submit parameters after ajax call
IMO it is not a bug, rather an improvement: set the form components value as parameter in form submit request. the scenario is: - a new form is created - a form components receive a new value in the first submit - in the second submit the new value at the form component didn't get add as an request parameter, like if the user manually removed the text in an text field for instance, or like if the form component get invisible. I don't know if FormTester was designed to simulate a second submit. On Tue, Dec 21, 2010 at 1:15 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Hi Pedro, Yeah those are different issues. I understand that in 1.5 its different how tester works. I know how can i access those parameters through request. The issue i have, is that if you do ajax call in the middle between setting value to input and submiting from, FormTester loses that value (unless of course you reset parameters from previous request to current). So, my question is, what should I do with the issue I have, do you want me to create jira task? Is it bug at all? On Tue, Dec 21, 2010 at 4:31 PM, Pedro Santos pedros...@gmail.com wrote: Hi Zilvinas, thank u for the test! We actually have different issues. I described mine at https://issues.apache.org/jira/browse/WICKET-3272 The tester setup the next request cycle just after process the request triggered by the mocked AJAX event. It differs from 1.4 where the request setup was made just before the next processRequestCycle. So in the 1.5 you don't need methods like setParametersForNextRequest, because the current request set on tester is the one that will be dispatched. So if you want to access it after process the request, you need to use methods like getLastRequest. I'm sending your test case back with mentioned changes. On Sat, Dec 18, 2010 at 4:14 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Pedro, One more thing, i have updated WicketTesterTest, which fails with issue i have described. I'm attaching patch file, maybe it will be of any help for you. On Sat, Dec 18, 2010 at 8:07 PM, zkybar...@gmail.com zkybar...@gmail.com wrote: Pedro, Thanks for reply. Yeah i have workaround for this - i just reset submit parameters from last request to current request. On Sat, Dec 18, 2010 at 6:30 PM, Pedro Santos pedros...@gmail.com wrote: Hi Zilvinas, I'm taking a look at your described issue, for now try to set the parameter as a POST one. On Sat, Dec 18, 2010 at 2:15 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Hello, I'm experiencing strange behavior with WicketTester in 1.5 when using FormTester with ajax events. It works as follows: 1. Set some value via the FormTester to input field. 2. Invoke ajax event. In my case behaviour is AjaxFormComponentUpdatingBehavior. 3. After the ajax event was executed input fields getInput method returns null. And it should, since there are no submit parameters available anymore. Is that bug? It was working in 1.4, so my guess that its bug. Greetings, Zilvinas. -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
Re: Tester loses all submit parameters after ajax call
In the 1.4 the executeAjaxEvent method do not create an request to be processed as in the 1.5. I prefer how it works in the 1.5, because when we don't use an AJAX request to trigger the default request cycle we need some hack in the tester, like: checkUsability. Perhaps we can even remove this method in the 1.5. On Tue, Dec 21, 2010 at 1:40 PM, Pedro Santos pedros...@gmail.com wrote: IMO it is not a bug, rather an improvement: set the form components value as parameter in form submit request. the scenario is: - a new form is created - a form components receive a new value in the first submit - in the second submit the new value at the form component didn't get add as an request parameter, like if the user manually removed the text in an text field for instance, or like if the form component get invisible. I don't know if FormTester was designed to simulate a second submit. On Tue, Dec 21, 2010 at 1:15 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Hi Pedro, Yeah those are different issues. I understand that in 1.5 its different how tester works. I know how can i access those parameters through request. The issue i have, is that if you do ajax call in the middle between setting value to input and submiting from, FormTester loses that value (unless of course you reset parameters from previous request to current). So, my question is, what should I do with the issue I have, do you want me to create jira task? Is it bug at all? On Tue, Dec 21, 2010 at 4:31 PM, Pedro Santos pedros...@gmail.com wrote: Hi Zilvinas, thank u for the test! We actually have different issues. I described mine at https://issues.apache.org/jira/browse/WICKET-3272 The tester setup the next request cycle just after process the request triggered by the mocked AJAX event. It differs from 1.4 where the request setup was made just before the next processRequestCycle. So in the 1.5 you don't need methods like setParametersForNextRequest, because the current request set on tester is the one that will be dispatched. So if you want to access it after process the request, you need to use methods like getLastRequest. I'm sending your test case back with mentioned changes. On Sat, Dec 18, 2010 at 4:14 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Pedro, One more thing, i have updated WicketTesterTest, which fails with issue i have described. I'm attaching patch file, maybe it will be of any help for you. On Sat, Dec 18, 2010 at 8:07 PM, zkybar...@gmail.com zkybar...@gmail.com wrote: Pedro, Thanks for reply. Yeah i have workaround for this - i just reset submit parameters from last request to current request. On Sat, Dec 18, 2010 at 6:30 PM, Pedro Santos pedros...@gmail.com wrote: Hi Zilvinas, I'm taking a look at your described issue, for now try to set the parameter as a POST one. On Sat, Dec 18, 2010 at 2:15 PM, zkybar...@gmail.com zkybar...@gmail.comwrote: Hello, I'm experiencing strange behavior with WicketTester in 1.5 when using FormTester with ajax events. It works as follows: 1. Set some value via the FormTester to input field. 2. Invoke ajax event. In my case behaviour is AjaxFormComponentUpdatingBehavior. 3. After the ajax event was executed input fields getInput method returns null. And it should, since there are no submit parameters available anymore. Is that bug? It was working in 1.4, so my guess that its bug. Greetings, Zilvinas. -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
Re: Wicket JavaScript structure
UploadProgressBar is using its own AJAX transportation and don't need to contribute with the wicket-ajax.js to header. I will try to change it to use the wicket-ajax.js API instead, than I the wicket-event.js code will be fine. On Fri, Dec 10, 2010 at 8:02 AM, Igor Vaynberg igor.vaynb...@gmail.comwrote: event should not need ajax, probably an oversight. we should fix it. -igor On Thu, Dec 9, 2010 at 10:33 PM, Martin Grigorov mgrigo...@apache.org wrote: There are plans to rework those in Wicket 1.6. The idea is to replace the custom code with one using some of the popular JS libraries, most probably JQuery. Introducing wicket-util.js will mean to add another resource reference (like WicketAjaxReference and WicketEventReference) and add dependencies between them, so loading any of -ajax.js or -event.js should load also -util.js. I don't remember any complains about that in the mailing lists, but if you want you can play with it. On Thu, Dec 9, 2010 at 8:51 PM, Pedro Santos pedros...@gmail.com wrote: The Wicket.Event.handle function at wicket-event.js calls the Wicket.$ one defined at wicket-ajax.js. But it is not safe call Wicket.$ because the page can be not using AJAX. Is interest separate utility methods at an wicket-util.js file? -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
Wicket JavaScript structure
The Wicket.Event.handle function at wicket-event.js calls the Wicket.$ one defined at wicket-ajax.js. But it is not safe call Wicket.$ because the page can be not using AJAX. Is interest separate utility methods at an wicket-util.js file? -- Pedro Henrique Oliveira dos Santos
Re: overriding isVisible bad?
Component can continue having the public isVisible/Enabled method always returning its correct state avaliable to use. Just the core request code will use an safe version that can be: isVisible/EnabledOnRequest. I really value an request cycle protected against volatile component states. I like the idea of using composition. We can refactor all the Component state code to an StateManager object. Its main goal can be: - maintain the components state: all its flags, the data object and respective API - define how close the visible/enabledOnRequest state will be to the user logic: we can define the check points, by default will be only the onConfigure. Perhaps user will can even override the SateManager, coding specific component logic (can solve some security restrictions). On Fri, Dec 3, 2010 at 11:12 PM, Eelco Hillenius eelco.hillen...@gmail.comwrote: That's actually also an example of why I prefer overriding isVisible: I can have that button and other widgets (maybe completely unrelated) widgets that depend on a particular state (like whether a record exists), and a function (override of isVisible) will always yield the correct result. In contrast, relying on the internal component state (set/isVisible) puts the responsibility of updating the relevant components on the handler (or worse, it may have to be triggered from the business layer). Eelco On Fri, Dec 3, 2010 at 10:46 AM, Igor Vaynberg igor.vaynb...@gmail.com wrote: ldm also doesnt always work nicely. suppose you have a delete button that is only visible if the record exists. the page renders, the user clicks the button. the onclick handler invoked, and isvisible is checked - at which point it is true. the record is deleted in the onclick handler, the page is rerendered - delete button is still visible because the ldm has cached the visibility value from before onclick handler is invoked. to make it work correctly the ldm would have to be detached manually after onclick handler. -igor On Thu, Dec 2, 2010 at 6:36 PM, Clint Checketts checke...@gmail.com wrote: Yesterday a friend following this thread pointed out that we should rethink our overriding of onVisible and use onConfigure. I've used LoadabledDetachableModels to cache the value used in my isVisible/isEnabled overriding so changing values mid request aren't a problem. That is its whole purpose. Also calling .detach() on that model isn't hacky, that is its design. While I appreciate having onConfigure as an option it seems like overriding isVisible is still the cleaner and clearer way. Folks just need to follow the rule that expensive calls should be contained in an LDM. Am I stuck in the past in holding this view? -Clint On Thu, Dec 2, 2010 at 4:03 AM, Martin Makundi martin.maku...@koodaripalvelut.com wrote: What about using onconfigure to replace loadabledetachablemodel ? We have had some trouble with loadabledetachablemodels when their state is frozen before a dependent model has been initialized (for example) and we need to call model.detach() from within our code, which seems bit hacky. Initializing also models at a specific known requestcycle moment might be beneficial. Ofcourse it is not so straightforward as with enable/visible state. ** Martin 2010/12/1 Igor Vaynberg igor.vaynb...@gmail.com: i would be happy if that was good enough. in the past it hasnt been, thats why we have the current solution. maybe we can try it again in 1.5 and see what happens. -igor On Tue, Nov 30, 2010 at 11:44 AM, Pedro Santos pedros...@gmail.com wrote: I have a different point of view, the HTTP imposes us some limitations, we will hardly have an good synchronization between the component state on browser and server using only HTTP conversation. So it is mandatory the service layer to respect the described security restriction. On Tue, Nov 30, 2010 at 5:32 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: an easy example is security. a user views a page that allows them to delete another user meanwhile their permissions are tweaked and they can no longer delete other users half an hour later the user clicks the delete button - this should fail, but wont if we are using last-rendered state. -igor On Tue, Nov 30, 2010 at 11:18 AM, Pedro Santos pedros...@gmail.com wrote: I need to look better on which core components are relying on an updated visibility/enabled state at the process event time, and why the last rendered state wouldn't be enough to them to work nicely. On Tue, Nov 30, 2010 at 3:19 PM, Igor Vaynberg igor.vaynb...@gmail.com wrote: currently we only invoke configure before the render. this would mean we would have to invoke it before processing a listener, clearing the cache, and then invoking it again before render. i wonder if that is enough
Re: [bug?] onInitialize() for Pages?
On Thu, Dec 2, 2010 at 8:39 AM, Carl-Eric Menzel cmen...@wicketbuch.dewrote:
Hi Pedro,
thanks for your reply.
I find the current behavior of onInitialize in Pages *very* surprising
and unexpected. It doesn't say anywhere in the documentation that using
onInitialize prohibits use of constructors.
Also, this only seems to affect pages. In all other components it seems
to work fine, which makes this behavior rather inconsistent.
Also, this quickstart is of course somewhat simplified. My real-world
issue is that I am extending from a chain of superclasses that all do
something in their constructors. It's not realistic to switch the
entire hierarchy from constructors to onInitialize.
Also again ;-), right now onInitialize for Pages is broken. For all
other components, onInitialize is called *after* all constructors have
run. Only for Pages this is done in the middle of the constructor.
I think either Page should have a final onInitialize implementation to
really prohibit onInitialize being used at all, or there should be a
special case for Page causing onInitialize to be called just before
onBeforeRender.
Make onInitialize final on pages is an good idea. It is designed to children
have a guaranty that the path to page exists, not to guaranty that an parent
has all its children on the hierarchy already. So it is fairly more useful
to children than for parent components. I just don't know if that change
implies in rename the onInitialize to notifyHierarchy or similar.
This would be consistent with Java object construction
and also consistent with the contract of onInitialize, which simply
says it is called sometime before onBeforeRender().
Would that be an acceptable solution? Want me to provide a patch?
Thanks
Carl-Eric
www.wicketbuch.de
On Wed, 1 Dec 2010 20:31:35 -0200
Pedro Santos pedros...@gmail.com wrote:
Hi Carl, you are mixing two different initializations strategies,
that is why you are finding it weird. If you are using an overwritten
onInitialize to initialize your component, do all your initialization
there, even add your component's children.
For example, your quickstart works fine as:
@Override
protected void onInitialize() {
super.onInitialize();
add(new Label(message,
If you see this message wicket is properly
configured and running));
if (!constructorDone) {
throw new IllegalStateException();
}
}
On Wed, Dec 1, 2010 at 7:24 PM, cmen...@wicketbuch.de wrote:
Hi,
we just ran into an interesting problem. We are using inheritance a
lot in our pages, but at one point we need something in the super
page that depends on the constructor of the sub page. Just like
with regular components, I thought I'd just use onInitialize() for
that.
Unfortunately, that didn't work:
at
comMySubPage.onInitialize(...)
at org.apache.wicket.Component.fireInitialize(Component.java:4050)
at
org.apache.wicket.MarkupContainer.initialize(MarkupContainer.java:413)
at org.apache.wicket.Page.componentAdded(Page.java:1589) at
org.apache.wicket.MarkupContainer.addedComponent(MarkupContainer.java:979)
at org.apache.wicket.MarkupContainer.add(MarkupContainer.java:142)
at comMySuperPage.init(...)
See the quickstart at
https://github.com/duesenklipper/wicket-oninitialize
or just do this in the HomePage of any Wicket app:
private final boolean constructorDone;
public HomePage(final PageParameters parameters) {
add(new Label(message, blah));
this.constructorDone = true;
}
@Override
protected void onInitialize() {
super.onInitialize();
if (!constructorDone) {
throw new IllegalStateException();
}
}
As soon as I add() the first component to the page in the super
constructor, the page's initialize() is called, which fires
onInitialize. At this time, my onInitialize can't do anything, since
not even the super constructor has been run completely!
Should this really happen this way? I.e., should the Page be
initialized at this point, or should the page's onInitialize call be
deferred later? Or is onInitialize not the right spot to do this
for a page - what would the right way be then?
Thanks
Carl-Eric
www.wicketbuch.de
--
Pedro Henrique Oliveira dos Santos
Re: [bug?] onInitialize() for Pages?
Page will always be the root node at the components tree, we don't need an useless hotspot on the framework, that is why I think the page should have an final onInitialize. On Thu, Dec 2, 2010 at 4:53 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: No. the contract is that the parent is initialized before the children. Initialization of the entire hierarchy can be delayed until right before configure is called. Igor On Dec 2, 2010 10:00 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: Okay, I decided should just go ahead and put my money where my mouth is :) Delaying onInitialize for pages isn't really feasible, I think. So I created a patch that would make onInitialize final in Page (as Pedro said) and introduces a new event onPageInitialize that is only called on pages. It honors the same contract as onInitialize, i.e. it is called only once per page object, at some point before onBeforeRender. See https://issues.apache.org/jira/browse/WICKET-3218 for details. Carl-Eric www.wicketbuch.de On Thu, 2 Dec 2010 13:50:30 +0100 Carl-Eric Menzel cmen...@wicketbuch.de wrote: Make onInitialize final on pages is an good idea. It is designed to children have a guaranty... -- Pedro Henrique Oliveira dos Santos
Re: [bug?] onInitialize() for Pages?
yes, delaying onInitialize until the constructor ends for pages isn't the goal. On Thu, Dec 2, 2010 at 5:03 PM, Pedro Santos pedros...@gmail.com wrote: Page will always be the root node at the components tree, we don't need an useless hotspot on the framework, that is why I think the page should have an final onInitialize. On Thu, Dec 2, 2010 at 4:53 PM, Igor Vaynberg igor.vaynb...@gmail.comwrote: No. the contract is that the parent is initialized before the children. Initialization of the entire hierarchy can be delayed until right before configure is called. Igor On Dec 2, 2010 10:00 AM, Carl-Eric Menzel cmen...@wicketbuch.de wrote: Okay, I decided should just go ahead and put my money where my mouth is :) Delaying onInitialize for pages isn't really feasible, I think. So I created a patch that would make onInitialize final in Page (as Pedro said) and introduces a new event onPageInitialize that is only called on pages. It honors the same contract as onInitialize, i.e. it is called only once per page object, at some point before onBeforeRender. See https://issues.apache.org/jira/browse/WICKET-3218 for details. Carl-Eric www.wicketbuch.de On Thu, 2 Dec 2010 13:50:30 +0100 Carl-Eric Menzel cmen...@wicketbuch.de wrote: Make onInitialize final on pages is an good idea. It is designed to children have a guaranty... -- Pedro Henrique Oliveira dos Santos -- Pedro Henrique Oliveira dos Santos
