Re: LDMs load too early - hold outdated application data.
On 28 Oct 2011, at 17:52, Igor Vaynberg wrote: and here is a simple counter example. your form has five dropdowns, all of which are populated by various queries and all of which are not effected by the submit. now on every single submit you have to run 10 queries instead of 5, for no good reason. Would you mind explaining why every submit needs to run 10 queries and what causes those 10 queries to get executed? If the form has 5 DDCs which are populated with their own queries, and onSubmit uses only one of them, ideally, I would want the framework to do this: 1. Handle event 1.a. Trigger onSubmit 1.b. onSubmit accesses one of the DDCs' getObject. 1.c. The LDM is not loaded, so getObject delegates to load 1.d. load fires a query.- 1 query. 1.e. onSubmit logic finishes. 1.f. Wicket detaches all models, causing our LDM to get unloaded. 2. Render page 2.a. The DDCs get rendered. 2.b. The DDCs invoke their respective models' getObject 2.c. The LDMs are not loaded, so their getObjects delegate to load 2.d. loads fire queries.- 5 queries. 2.e. The DDCs render using the model data. 2.f. Wicket detaches all models post-render, causing our LDMs to get unloaded. I count only 6 queries. And when onSubmit does nothing, only 5. Exactly the same as if 1.f didn't happen. Now, from what you say I assume Wicket actually force-loads all models during phase 1, somewhere. Probably when handling the parameters submitted by the form before 1.a. All I'm asking here is whether perhaps we should make this process more lazy and postpone it to 1.b/c, so that we don't force-load all models, regardless of whether they're going to be used during event processing, but only do so for models that are actually used by the event handling. If I'm making any serious wrong assumptions about the way wicket works, please detail them extensively so I may understand better. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: LDMs load too early - hold outdated application data.
On 29 Oct 2011, at 17:14, Bertrand Guay-Paquet wrote: My understanding is that the queries need to be run in order to get the choice lists of the DDCs. Even if onSubmit uses only one of the DDC's model, the DDCs still need to convert their input. And my point is; why are we converting input to set model objects that we don't access? Perhaps we should make this process more lazy, and save in queries that way. That makes the whole reason to keep the currently broken solution in effect null and void. On 29/10/2011 4:40 AM, Maarten Billemont wrote: On 28 Oct 2011, at 17:52, Igor Vaynberg wrote: and here is a simple counter example. your form has five dropdowns, all of which are populated by various queries and all of which are not effected by the submit. now on every single submit you have to run 10 queries instead of 5, for no good reason. Would you mind explaining why every submit needs to run 10 queries and what causes those 10 queries to get executed? If the form has 5 DDCs which are populated with their own queries, and onSubmit uses only one of them, ideally, I would want the framework to do this: 1. Handle event 1.a. Trigger onSubmit 1.b. onSubmit accesses one of the DDCs' getObject. 1.c. The LDM is not loaded, so getObject delegates to load 1.d. load fires a query.- 1 query. 1.e. onSubmit logic finishes. 1.f. Wicket detaches all models, causing our LDM to get unloaded. 2. Render page 2.a. The DDCs get rendered. 2.b. The DDCs invoke their respective models' getObject 2.c. The LDMs are not loaded, so their getObjects delegate to load 2.d. loads fire queries.- 5 queries. 2.e. The DDCs render using the model data. 2.f. Wicket detaches all models post-render, causing our LDMs to get unloaded. I count only 6 queries. And when onSubmit does nothing, only 5. Exactly the same as if 1.f didn't happen. Now, from what you say I assume Wicket actually force-loads all models during phase 1, somewhere. Probably when handling the parameters submitted by the form before 1.a. All I'm asking here is whether perhaps we should make this process more lazy and postpone it to 1.b/c, so that we don't force-load all models, regardless of whether they're going to be used during event processing, but only do so for models that are actually used by the event handling. If I'm making any serious wrong assumptions about the way wicket works, please detail them extensively so I may understand better. - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: LDMs load too early - hold outdated application data.
Fair. To make this work, Wicket would need to get the chance to intervene in every model's getObject so that it can perform its lazy operation if necessary. On 29 Oct 2011, at 18:21, Igor Vaynberg wrote: because there is no way to know if the user will access the model object or not. eg if i use a property model to bind my form component to a field then there is no way for me to know if that field is accessed during a formsubmit or not, thus all form components always push their data. -igor On Sat, Oct 29, 2011 at 8:49 AM, Maarten Billemont lhun...@lyndir.com wrote: On 29 Oct 2011, at 17:14, Bertrand Guay-Paquet wrote: My understanding is that the queries need to be run in order to get the choice lists of the DDCs. Even if onSubmit uses only one of the DDC's model, the DDCs still need to convert their input. And my point is; why are we converting input to set model objects that we don't access? Perhaps we should make this process more lazy, and save in queries that way. That makes the whole reason to keep the currently broken solution in effect null and void. On 29/10/2011 4:40 AM, Maarten Billemont wrote: On 28 Oct 2011, at 17:52, Igor Vaynberg wrote: and here is a simple counter example. your form has five dropdowns, all of which are populated by various queries and all of which are not effected by the submit. now on every single submit you have to run 10 queries instead of 5, for no good reason. Would you mind explaining why every submit needs to run 10 queries and what causes those 10 queries to get executed? If the form has 5 DDCs which are populated with their own queries, and onSubmit uses only one of them, ideally, I would want the framework to do this: 1. Handle event 1.a. Trigger onSubmit 1.b. onSubmit accesses one of the DDCs' getObject. 1.c. The LDM is not loaded, so getObject delegates to load 1.d. load fires a query.- 1 query. 1.e. onSubmit logic finishes. 1.f. Wicket detaches all models, causing our LDM to get unloaded. 2. Render page 2.a. The DDCs get rendered. 2.b. The DDCs invoke their respective models' getObject 2.c. The LDMs are not loaded, so their getObjects delegate to load 2.d. loads fire queries.- 5 queries. 2.e. The DDCs render using the model data. 2.f. Wicket detaches all models post-render, causing our LDMs to get unloaded. I count only 6 queries. And when onSubmit does nothing, only 5. Exactly the same as if 1.f didn't happen. Now, from what you say I assume Wicket actually force-loads all models during phase 1, somewhere. Probably when handling the parameters submitted by the form before 1.a. All I'm asking here is whether perhaps we should make this process more lazy and postpone it to 1.b/c, so that we don't force-load all models, regardless of whether they're going to be used during event processing, but only do so for models that are actually used by the event handling. If I'm making any serious wrong assumptions about the way wicket works, please detail them extensively so I may understand better. - 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 - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: LDMs load too early - hold outdated application data.
On 26 Oct 2011, at 11:57, Wilhelmsen Tor Iver wrote: It seems to me that Wicket should detach its models again after events have triggered, in addition to after rendering has completed. That would reset the state of all models to what the developer expects it to be before rendering begins. That's nearly always - then you are just as well served with an AbstractReadOnlyModel that loads data on every call to getObject()... :) If you claim that an LDM's use is limited to avoiding a load in between event handling and rendering of a page, that would make LDMs damn near useless. Luckily, this is simply not true. An LDM's main use is to avoid multiple loads when the model is accessed multiple times during rendering. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: LDMs load too early - hold outdated application data.
On 26 Oct 2011, at 12:14, Sven Meier wrote: Hi, Or use a separate LDM for each of your list items I'm not sure I understand what you mean here. Could you illustrate? your LDM seems to return a list of items and you're iterating over them with a ListView. Note that ListView uses a ListItemModel for each item: Fair. Though my actual use case is an LDM that populates a dropdown. There is only one button in the form to delete the dropdown's selected object, whose onSubmit uses the dropdown's model to determine what object to delete. It seems to me that Wicket should detach its models again after events have triggered, in addition to after rendering has completed. That would resetthe state of all models to what the developer expects it to be before rendering begins. You can hook your own listener into Wicket (I*Listener) and detach the models yourself. If we can think of no issues with this approach, I'd much rather vote to make it standard behavior in Wicket, so that developers can trust their models behave as they'd expect. HTH Sven -Ursprüngliche Nachricht- Von: Maarten Billemont [mailto:lhun...@lyndir.com] Gesendet: Mittwoch, 26. Oktober 2011 11:50 An: users@wicket.apache.org Betreff: Re: LDMs load too early - hold outdated application data. On 26 Oct 2011, at 10:52, Sven Meier wrote: This is a common problem when working with LDM. You can detach the LDM by yourself after the event. I could. But it would be a work-around and it wouldn't solve the underlying issue. As a result, this bug will keep haunting us. Or use a separate LDM for each of your list items: This way the LDM of the list is loaded for rendering *after* the event only. Additionally the event won't crash when the list of users has changed while the page is displayed. I'm not sure I understand what you mean here. Could you illustrate? It seems to me that Wicket should detach its models again after events have triggered, in addition to after rendering has completed. That would reset the state of all models to what the developer expects it to be before rendering begins. HTH Sven -Ursprüngliche Nachricht- Von: Maarten Billemont [mailto:lhun...@lyndir.com] Gesendet: Mittwoch, 26. Oktober 2011 10:15 An: users@wicket.apache.org Betreff: LDMs load too early - hold outdated application data. I just had a bug in my application where my LDM lists all users to fill a form field, but that same form also has a button to delete the selected user from the database. The problem is that the button's onSubmit triggers AFTER the LDM is populated, because it apparently needs the LDM's information to figure out what user was selected in the form (so, to figure out what user to delete). Only, once the button's onSubmit has triggered, the user is deleted from persistence, and to render an up-to-date page, the LDM's model should NO LONGER include that user. I had initially assumed this would work fine because the LDM reloads its model for each page refresh, but in this scenario the LDM is only loaded before the persistence layer is up-to-date with the information that needs to be rendered. Which leads me to wonder the following: Shouldn't an LDM load its state from up-to-date data? Shouldn't its load() be invoked AFTER all events have been handled? Shouldn't the response page be rendered AFTER all logic has been processed? And shouldn't the LDM use FRESH data for that rendering, rather than using the state from BEFORE the logic was processed? Isn't this a bug in the way wicket handles model object loading? It certainly doesn't stroke with what a developer might intuitively expect from an LDM - so there's some kind of mismatch going on. And personally, I'd really like to be able to TRUST that my LDMs are ALWAYS populated from CURRENT data when the response rendering that uses it happens. - 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 - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: LDMs load too early - hold outdated application data.
On 27 Oct 2011, at 17:18, Igor Vaynberg wrote: On Thu, Oct 27, 2011 at 12:29 AM, Maarten Billemont lhun...@lyndir.com wrote: On 26 Oct 2011, at 12:14, Sven Meier wrote: Hi, Or use a separate LDM for each of your list items I'm not sure I understand what you mean here. Could you illustrate? your LDM seems to return a list of items and you're iterating over them with a ListView. Note that ListView uses a ListItemModel for each item: Fair. Though my actual use case is an LDM that populates a dropdown. There is only one button in the form to delete the dropdown's selected object, whose onSubmit uses the dropdown's model to determine what object to delete. It seems to me that Wicket should detach its models again after events have triggered, in addition to after rendering has completed. That would resetthe state of all models to what the developer expects it to be before rendering begins. You can hook your own listener into Wicket (I*Listener) and detach the models yourself. If we can think of no issues with this approach, I'd much rather vote to make it standard behavior in Wicket, so that developers can trust their models behave as they'd expect. this wont be a standard behavior as it would add a lot of overhead. during listener processing you may load five LDMs with database queries and only one of them will be effected by the form submission - Then those four will not get loaded before rendering and there is no problem. Their models will be detached from after the last rendering, their LDMs unloaded, and with no getObject to load them before render, when this new detach-before-render is called, their internal state will still be detached. No double loading if you're not being used during event processing. Or am I wrong? If not, then perhaps it is feasible still to do this. If wicket loads all models of form components regardless, then maybe it can be made more lazy. so why should we have to reload the other four? imho it is a well known fact that if you do something like this: ListFoo list=model.getobject(); Foo foo=list.get(0); removeFromDatabase(foo); we all understand that model.getobject() still returns an unchanged list, so if you want a refreshed list you have to call model.detach(); I've never actually thought it necessary to invoke this method myself; I mostly considered it internal-use. But perhaps, yes, the developer should be aware of needing to do this maintenance. the core of your problem here is that you are using a ListView to represent data in your database, which is something that ListView is *not* designed to be used for. it is designed to be used with lists, which your database tables are not. if you dont want to run into this then use a dataview or a datatable. I'm not using a ListView (at least not directly). I'm using a DDC. And AFAIK this issue would also exist for eg. ListDataProvider. -igor HTH Sven -Ursprüngliche Nachricht- Von: Maarten Billemont [mailto:lhun...@lyndir.com] Gesendet: Mittwoch, 26. Oktober 2011 11:50 An: users@wicket.apache.org Betreff: Re: LDMs load too early - hold outdated application data. On 26 Oct 2011, at 10:52, Sven Meier wrote: This is a common problem when working with LDM. You can detach the LDM by yourself after the event. I could. But it would be a work-around and it wouldn't solve the underlying issue. As a result, this bug will keep haunting us. Or use a separate LDM for each of your list items: This way the LDM of the list is loaded for rendering *after* the event only. Additionally the event won't crash when the list of users has changed while the page is displayed. I'm not sure I understand what you mean here. Could you illustrate? It seems to me that Wicket should detach its models again after events have triggered, in addition to after rendering has completed. That would reset the state of all models to what the developer expects it to be before rendering begins. HTH Sven -Ursprüngliche Nachricht- Von: Maarten Billemont [mailto:lhun...@lyndir.com] Gesendet: Mittwoch, 26. Oktober 2011 10:15 An: users@wicket.apache.org Betreff: LDMs load too early - hold outdated application data. I just had a bug in my application where my LDM lists all users to fill a form field, but that same form also has a button to delete the selected user from the database. The problem is that the button's onSubmit triggers AFTER the LDM is populated, because it apparently needs the LDM's information to figure out what user was selected in the form (so, to figure out what user to delete). Only, once the button's onSubmit has triggered, the user is deleted from persistence, and to render an up-to-date page, the LDM's model should NO LONGER include that user. I had initially assumed this would work fine because the LDM reloads its model for each page refresh
LDMs load too early - hold outdated application data.
I just had a bug in my application where my LDM lists all users to fill a form field, but that same form also has a button to delete the selected user from the database. The problem is that the button's onSubmit triggers AFTER the LDM is populated, because it apparently needs the LDM's information to figure out what user was selected in the form (so, to figure out what user to delete). Only, once the button's onSubmit has triggered, the user is deleted from persistence, and to render an up-to-date page, the LDM's model should NO LONGER include that user. I had initially assumed this would work fine because the LDM reloads its model for each page refresh, but in this scenario the LDM is only loaded before the persistence layer is up-to-date with the information that needs to be rendered. Which leads me to wonder the following: Shouldn't an LDM load its state from up-to-date data? Shouldn't its load() be invoked AFTER all events have been handled? Shouldn't the response page be rendered AFTER all logic has been processed? And shouldn't the LDM use FRESH data for that rendering, rather than using the state from BEFORE the logic was processed? Isn't this a bug in the way wicket handles model object loading? It certainly doesn't stroke with what a developer might intuitively expect from an LDM - so there's some kind of mismatch going on. And personally, I'd really like to be able to TRUST that my LDMs are ALWAYS populated from CURRENT data when the response rendering that uses it happens. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: LDMs load too early - hold outdated application data.
On 26 Oct 2011, at 10:52, Sven Meier wrote: This is a common problem when working with LDM. You can detach the LDM by yourself after the event. I could. But it would be a work-around and it wouldn't solve the underlying issue. As a result, this bug will keep haunting us. Or use a separate LDM for each of your list items: This way the LDM of the list is loaded for rendering *after* the event only. Additionally the event won't crash when the list of users has changed while the page is displayed. I'm not sure I understand what you mean here. Could you illustrate? It seems to me that Wicket should detach its models again after events have triggered, in addition to after rendering has completed. That would reset the state of all models to what the developer expects it to be before rendering begins. HTH Sven -Ursprüngliche Nachricht- Von: Maarten Billemont [mailto:lhun...@lyndir.com] Gesendet: Mittwoch, 26. Oktober 2011 10:15 An: users@wicket.apache.org Betreff: LDMs load too early - hold outdated application data. I just had a bug in my application where my LDM lists all users to fill a form field, but that same form also has a button to delete the selected user from the database. The problem is that the button's onSubmit triggers AFTER the LDM is populated, because it apparently needs the LDM's information to figure out what user was selected in the form (so, to figure out what user to delete). Only, once the button's onSubmit has triggered, the user is deleted from persistence, and to render an up-to-date page, the LDM's model should NO LONGER include that user. I had initially assumed this would work fine because the LDM reloads its model for each page refresh, but in this scenario the LDM is only loaded before the persistence layer is up-to-date with the information that needs to be rendered. Which leads me to wonder the following: Shouldn't an LDM load its state from up-to-date data? Shouldn't its load() be invoked AFTER all events have been handled? Shouldn't the response page be rendered AFTER all logic has been processed? And shouldn't the LDM use FRESH data for that rendering, rather than using the state from BEFORE the logic was processed? Isn't this a bug in the way wicket handles model object loading? It certainly doesn't stroke with what a developer might intuitively expect from an LDM - so there's some kind of mismatch going on. And personally, I'd really like to be able to TRUST that my LDMs are ALWAYS populated from CURRENT data when the response rendering that uses it happens. - 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 - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: wicket showing traces that we used wicket is it a problem
I can only imagine it fits in the security through obfuscation category. If
they don't know it's Wicket, they won't think to use a Wicket exploit on it!.
At any rate, I'd be more worried about the fact that you're running it in a
Java VM than the fact that the front-end of it is generated by Apache Wicket.
If anything is going to be exploitable to do anything useful, it's going to be
the VM. Or more likely, your own code.
Don't get sucked into this obfuscation crap. It buys you nothing. But if you
must, feel free to mount your pages with a .php extension and exhaust all the
script kiddie's patience in his attempts at SQL injection.
On 23 May 2011, at 20:56, Igor Vaynberg wrote:
thousands of applications show they use php with .php extensions.
thousands more show that they use jsp by .jsp extensions, and a lot
more show they use struts with a .do extension. why does it matter?
-igor
On Sat, May 21, 2011 at 9:01 AM, hariharansrc hariharan...@gmail.com wrote:
html
head
titleWicket form/title
/head
body
form id=id1 method=post
action=;jsessionid=90C6F4DC17391001C2B5A3575453976D?wicket:interface=:0:form::IFormSubmitListener::div
style=width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hiddeninput
type=hidden name=id1_hf_0 id=id1_hf_0 //div
input type=text value= name=username
button type=submit name=hello id=id2 onclick=var
wcall=wicketSubmitFormById('id1',
';jsessionid=90C6F4DC17391001C2B5A3575453976D?wicket:interface=:0:form:hello::IActivePageBehaviorListener:0:amp;wicket:ignoreIfNotActive=true',
'hello' ,function() { }.bind(this),function() { }.bind(this), function()
{return Wicket.$$(this)amp;amp;Wicket.$$('id1')}.bind(this));;; return
false;helloworld/button
/form
/body
/html
this is the html code i got for a simple program using ajax it shows many
traces that we used wicket i am imagining is it cause any problem to reveal
what we actually used to the users.
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/wicket-showing-traces-that-we-used-wicket-is-it-a-problem-tp3540810p3540810.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
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Ajax and browser Back button
Perhaps you can navigate to an anchor after each AJAX call. On 21 May 2011, at 12:54, meduolis wrote: I have noticed, that there is one issue when you click back button on browser. If it was ajaxified page and you click on any control after back button clicked in browser you will get exception that clicked component not found or something. I did some research and found this as one of solutions: http://www.richardnichols.net/2010/03/apache-wicket-force-page-reload-to-fix-ajax-back/ But this disables browser level cache. I think, this decreases performance. Is there any better solution to avoid this back button issue? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Ajax-and-browser-Back-button-tp3540454p3540454.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
Re: Serve Json in request and response
On 03 May 2011, at 10:20, Wicket wrote:
Hi,
When serving json I have built a WebService that responds with json and takes
json as request.
@WebMethod
@WebResult( name = JsonResponse )
public String onJsonRequest( @WebParam( name = JsonRequest ) String
jsonRequest );
I was wondering if I could handle this entirely in Wicket? Have a WebPage
that parsed the JsonRequets and returned JsonResponse.
I know how to return Json reponse from the page using application/json.
But how will I handle the request? The myhomepage.com/json?request={some
json code} is not looking very good.
Sounds like you want a servlet instead. Why do you want to do this in Wicket?
Wicket gives you nothing that you could use for handling or generating JSON.
Wicket is not the tool for the job.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wiquery experiences
On 07 Apr 2011, at 09:54, Hielke Hoeve wrote:
Maarten says:
Writing what should be JavaScript in your wicket Java code is quite
out-of-place, and generally all you need to do is place your code where it
belongs, in a .js or your markup.
I wonder if he ever really used WiQuery or even looked how it's used. Or for
that matter used jQuery. What you *don't* need to do with WiQuery is write js
code in your java classes and we recommend to put all js code in js files and
load them as a resource!
When I said Writing what *should* be JavaScript in your wicket Java code ...,
what I was referring to is things like (ref. wiQuery Quickstart):
JsScope.quickScope(alert('foo'));
to represent:
function() {
alert('foo');
}
Don't get me wrong, I'm sure wiQuery has its place and use. As I said, tightly
integrating jQuery components with your Wicket application logic is probably
much easier done with this abstraction layer.
It's just important to know that wiQuery isn't a requirement for being able to
do jQuery in a wicket application, or any sort of custom JS/AJAX for that
matter. And if wiQuery has indeed matured a lot, and you aren't at risk of
code injection, then sure, have at it - where it makes sense.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wiquery experiences
Unless WiQuery has matured a *lot* lately and the code has been cleaned up significantly, I can't recommend it, personally. Writing what should be JavaScript in your wicket Java code is quite out-of-place, and generally all you need to do is place your code where it belongs, in a .js or your markup. There may be some odd cases here or there where tighter integration of jQuery and Wicket can be beneficial, but those can usually be resolved some other way. I don't have enough experience or knowledge of the framework to cast a final vote though, all I'm saying is: beware of the quality of this library's code and make sure you actually need it first (I want to do jQuery stuff in my Wicket application is generally not reason enough). On 06 Apr 2011, at 11:09, ha...@dds.nl wrote: Hi, We are thinking of using wiquery for a project. We are interested in the experiences of people using it. Does wiquery work in the major browsers (IE7, IE8, IE9, FF3 and Chrome)? Are there any complications when different versions of jquery are used on other places in the HTML? What is the version of Wicket you used it? Please share your experiences. Thanks in advance, Haiko van der Schaaf - 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
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
On 02 Apr 2011, at 01:01, Maarten Billemont wrote: On 02 Apr 2011, at 00:13, Bruno Borges wrote: [] Please, check this box if you agree with EULA [ x ] Please, uncheck this box if you don't want to receive notifications In this case, I would set the first checkbox as required, and leave the later as optional. Vote for (1) +1 Please don't pretend a checkbox is a Radio component. This is irrelevant to this discussion. I totally missed that you have two different questions here, apologies. Nevertheless, you're disregarding my earlier statements. You're asking us to make setRequired do something that's completely different from what it's supposed to do. If you require a certain value, that's what validators are for. If you require a value to be given, you use setRequired. Checkboxes ALWAYS give a value. There is no I choose not to choose option with a checkbox. That is what setRequired is for. It forces you to make a *choice*. It does not force you to make a specific choice. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [ANNOUNCE] Wicketopia 0.9 Released...
Without knowing what RAD or Scaffolding is about, the examples on your site really make very little sense to me. You show a method, getDescription, with a bunch of annotations on them. You don't show what this method is a part of, or how that actually ties in with your actual wicket code underneath. The wicket Java code example shows a wicketopia Scaffold component that takes a wicketopia Widget class and a Spring persistence provider. How could this possibly be useful to me? What does it do? How does it tie in with my insanely annotated getDescription method? Also, does wicketopia depend on Spring? That would be a really *really* big downside. I don't need any frontend library telling me what persistence framework to use, and Spring is about much more than just persistence. Abstract that stuff. Perhaps when I can understand what Wicketopia is without having to UTSL, I'll consider giving it a try. Assuming I don't also need to suffocate my code under the weight of Spring. On 31 Mar 2011, at 19:34, James Carman wrote: Wicketopia is a Rapid Application Development (RAD) library for Wicket. There is some documentation available at: http://wicketopia.sourceforge.net The official release will be available in the main maven repository shortly, but you can download it via SVN (and run the example application) by doing: svn co http://wicketopia.svn.sourceforge.net/svnroot/wicketopia/tags/wicketopia-parent-0.9/ wicketopia I am trying to clean up the code a bit and tie up some loose ends, but I got the Scaffold component working, so I thought that at least deserved a release. Plus, I wanted to make sure my release process was all ironed out before 1.0. Thanks, James - 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
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
On 01 Apr 2011, at 20:56, Daniel Neugebauer wrote: I would stick with 1 (required to be checked). The main reason would be not to break compatibility with old versions. Lame reason. Don't fix bugged behavior because old code relies on it. All that got us is a renders-well-in-IE 6.0 web, which we only barely are struggling out of with the advent of Mozilla et al. who decided to do the right thing for a change. I actually used .setRequired(true) on legal checkboxes (disclaimers) in one of our applications because if I have a required checkbox I expect it to be needed to be checked. Get the context right. You are required to provide a value is not the same as You are required to provide this specific value. The context of the term required in the setRequired method refers to the former, not the latter. As Igor pointed out, the latter is accomplished with a validator. setRequired has no business looking at what your value is, just whether or not one exists. Changing that context for one component for whatever reason breaks the consistency and reliability of the API. Although I will change that in our project now that I know such a change is being discussed, I wouldn't expect others to be that observant of the issue and have unit tests that prevent anything from breaking on a future upgrade. I hope people test their web apps before they deploy a new release to production. I'm sure they'll notice the change if they do. I vote (2) +1, if it doesn't make sense to apply setRequired to a certain type of component because the HTML model simply does not permit it, giving setRequired a different meaning is not an acceptable alternative. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
On 01 Apr 2011, at 20:56, Daniel Neugebauer wrote: BTW an empty string (that's not null) is a string nevertheless. Following the argument that an unchecked (false) checkbox should be regarded as valid if it is required, an empty string should be accepted as a valid input as well. I don't see why you would think that. setRequired(true) means, You must provide a value for this component's model. An empty String and a null String mean the same thing (since you cannot input a null String); in both instances, it's the user saying: I have no value for this. Hence, it makes perfect sense that the setRequired(true) fails validation on an empty text field. Contrary to a text field, an unchecked checkbox does not mean: no value. It means: Off. As though I'd write false in my text field. If the web application asks me whether I want to gift-wrap my purchase, leaving the box unchecked does not mean I can't or don't want to make up my mind. It means I do not want it gift wrapped. It's me saying: No. I've just tested it with Wicket 1.4 and actually both of the following TextFields validate to a failed state: TextField tf1 = new TextField(text1, new PropertyModelString(this, test1)); tf1.setRequired(true); tf1.setConvertEmptyInputStringToNull(false); form.add(tf1); TextField tf2 = new TextField(text2, new PropertyModelString(this, test2)); tf2.setRequired(true); tf2.setConvertEmptyInputStringToNull(true); form.add(tf2); Regardless, setConvertEmptyInputStringToNull is not relevant during checkRequired. It is only used by the developer to say, if the user doesn't enter any characters, make my model object null instead of an empty string. checkRequired checks Strings.isEmpty(), which is perfectly sensible (ref. the first paragraph of this email). - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] Behavior of CheckBox With Respect to setRequired(true)
On 02 Apr 2011, at 00:13, Bruno Borges wrote: [] Please, check this box if you agree with EULA [ x ] Please, uncheck this box if you don't want to receive notifications In this case, I would set the first checkbox as required, and leave the later as optional. Vote for (1) +1 Please don't pretend a checkbox is a Radio component. This is irrelevant to this discussion. Best regards, Bruno Borges www.brunoborges.com.br +55 21 76727099 The glory of great men should always be measured by the means they have used to acquire it. - Francois de La Rochefoucauld On Fri, Apr 1, 2011 at 6:46 PM, Maarten Billemont lhun...@gmail.com wrote: On 01 Apr 2011, at 20:56, Daniel Neugebauer wrote: BTW an empty string (that's not null) is a string nevertheless. Following the argument that an unchecked (false) checkbox should be regarded as valid if it is required, an empty string should be accepted as a valid input as well. I don't see why you would think that. setRequired(true) means, You must provide a value for this component's model. An empty String and a null String mean the same thing (since you cannot input a null String); in both instances, it's the user saying: I have no value for this. Hence, it makes perfect sense that the setRequired(true) fails validation on an empty text field. Contrary to a text field, an unchecked checkbox does not mean: no value. It means: Off. As though I'd write false in my text field. If the web application asks me whether I want to gift-wrap my purchase, leaving the box unchecked does not mean I can't or don't want to make up my mind. It means I do not want it gift wrapped. It's me saying: No. I've just tested it with Wicket 1.4 and actually both of the following TextFields validate to a failed state: TextField tf1 = new TextField(text1, new PropertyModelString(this, test1)); tf1.setRequired(true); tf1.setConvertEmptyInputStringToNull(false); form.add(tf1); TextField tf2 = new TextField(text2, new PropertyModelString(this, test2)); tf2.setRequired(true); tf2.setConvertEmptyInputStringToNull(true); form.add(tf2); Regardless, setConvertEmptyInputStringToNull is not relevant during checkRequired. It is only used by the developer to say, if the user doesn't enter any characters, make my model object null instead of an empty string. checkRequired checks Strings.isEmpty(), which is perfectly sensible (ref. the first paragraph of this email). - 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
Re: DropDownChoices Removing Choose One after Ajax Call
On 13 Mar 2011, at 10:18, tech7 wrote: I have a dropdownchoice component on my page and according to some selections on my page, this component is updated by a ajax call. At the beginning it displays the choices without showing Choose One but after ajax call it displays Choose One. I know this issue is coming from any of the choices are not selected right there but I don't know how to say the component choose first one as selected for not displaying Choose One. The component will select the item that your model provides. If your model's object is not set, the component will not select anything. It would be crazy to think that the component should have an element selected that wasn't actually the model's object. So, if you want to select the first element, set your model's object to it. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 10 Mar 2011, at 00:42, Igor Vaynberg wrote: i am +0 for refactoring the code so that oninitialize() cascade is not started from page#add() but from somewhere before page#onconfigure(). this way oninitialize() is safe to override in pages because it will not be invoked from page's constructor but from some framework code at a later time. Then I think that's the only actual solution that has positive votes. Without any further feedback, can we agree to leave constructors as they are, make onInitialize overridable and do it this way? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
[drama] So to summarize my rant: -1 for removing the ability to use add inside a constructor. +0 for improving the handling of oninitialize +1 for improving the documentation on the lifecycle of components and the event chain called during processing [2] I assume that means you don't care if 3218 is marked as won't fix and onInitialize remains overridable by those that choose to use it. Documentation is a good enough alternative when there is an unresolved issue that only occurs in rare cases. So yes, document it, and let those that want to use onInitialize do so. I never claimed using constructors will make your webapps eat your young. I simply outlined the pros and cons of each approach and argued the design advantages of not touching your components from outside wicket lifecycle methods. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Redirecting to another page in a WebPage constructor
On 10 Mar 2011, at 13:25, vineetsemwal wrote: use restartresponseexception While drf may not have meant what he said, RestartResponseException will not actually redirect to another page, it will just load the other page as a response to the current page's URL. That is often very confusing for users, especially when the current page is mounted. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
yep, calling overridable methods from constructors is bad - you just made the case for making page.oninitialize() final... No, I've made the case for this issue. Either add() should be disallowed from the constructor (meaning onInitialize won't get called from it), onInitialize should be made final (meaning onInitialize will do nothing when it gets called), or Page should stop calling initialize() as a result of a component being added, and behave like any other component does. Would you mind addressing this third option? What exactly is the reason for Page behaving in this special way? On 09 Mar 2011, at 09:15, Igor Vaynberg wrote: Firstly, it's my opinion that you really shouldn't be doing anything to components directly, especially not from outside your class. As for why, see Encapsulation and Law of Demeter. neither of the two apply because nameeditor explicitly exposes the two components as part of its contract via public getters. Allow me to remind you: More formally, the Law of Demeter for functions requires that a method M of an object O may only invoke the methods of the following kinds of objects: • O itself • M's parameters • any objects created/instantiated within M • O's direct component objects • a global variable, accessible by O, in the scope of M Making your components available via getters does not excuse anything. The list does not include invoke methods on any objects created by any objects created within M, for good reason. Also, I really don't like condoning get(String), it's nasty and very type-unfriendly. It also breaks as soon as you do any refactoring in your component hierarchy. yes, i traded off some refactorability for better memory footprint. imho a perfectly valid trade off when memory and space are costly. there are still problems with this: *you still have the two extra memory slots that are a complete waste here - component references You're talking about the cost of a reference to a component. It's not like you've got a COPY of the component in your field. And no, it's not a good trade-off. You're writing Java applications, you'll be deploying in Java application containers, you're working with a web framework that goes to great lengths to help the container provide solid clustering. Your memory footprint is absolutely subordinate to decently maintainable and compile-time checked code. If you're a developer that doesn't appreciate the latter, you'll find that you can be a lot more flexible using a language with weak type checking, at the cost of maintainable code. Any Java developer should not be willing to make this trade-off, especially when it's as light as this one. Your component gets added to your page anyway! *the lazy init code is cumbersome to write Hardly, but you shouldn't be doing it anyway except for special cases where you can forgive yourself the bad design. *you are missing the two slots needed to pass models from constructor to the two textfields - so thats four extra slots total that you have now forced on users You really shouldn't be having references to your components and have only two slots for your models, but if you want to provide getters for your components, yes, you need instance fields for them. Because get(String) is nasty. This really doesn't have anything to do with the difference between constructor and onInitialize initialization, except for the added bonus that you can't do nasty get(String) in the latter case before your component is initialized. The second option is looking better and better to me. * the components i get from the getters are not added to their parent - for more complex components that need access to their markup this is a problem, eg if (text.equals(getFirst().getMarkupTag().get(type))...not necessarily a good example taking this particular custom component as context, but a valid usecase in plenty of other situations. Irrelevant, even if you added them in your constructor, you don't have access to your markup before you add your newly created NameEditor to a page hierarchy. This example does help to confirm the need for an onInitialize: Don't touch your components until onInitialize is called indicating that the page hierarchy and markup are available. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 09 Mar 2011, at 10:44, Gary Thomas wrote:
While a minority use-case, this allows for very elegant Wicket code when
using Scala:
add(new Form[Person](form, model) {
add (new TextArea[String](text, (getModel - text)) {
override def isVisible: Boolean = false
})
})
Style is great when there are no issues involved with doing it. If it turns
out that adding components from the constructor is indeed dangerous when
combined with other components (eg. in libraries) that use onInitialize then we
should reconsider.
I think the best solution so far would be to not invoke onInitialize when
adding components to a page, that would allow the constructor to be used still
if the developer really wants to.
With regards to your Scala code, while I don't know any Scala whatsoever,
wouldn't it be just as easy to do something like this:
add(new Form[Person](form, model) {
override def onInitialize: add (new TextArea[String](text, (getModel -
text)) {
override def isVisible: Boolean = false
})
})
Which would give you the added lazy component construction bonus that
onInitialize provides, as well as your elegance.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 09 Mar 2011, at 19:15, Gary Thomas wrote:
On 3/9/11 2:18 AM, Maarten Billemont wrote:
On 09 Mar 2011, at 10:44, Gary Thomas wrote:
While a minority use-case, this allows for very elegant Wicket code when
using Scala:
add(new Form[Person](form, model) {
add (new TextArea[String](text, (getModel - text)) {
override def isVisible: Boolean = false
})
})
Style is great when there are no issues involved with doing it. If it turns
out that adding components from the constructor is indeed dangerous when
combined with other components (eg. in libraries) that use onInitialize then
we should reconsider.
I think the best solution so far would be to not invoke onInitialize when
adding components to a page, that would allow the constructor to be used
still if the developer really wants to.
With regards to your Scala code, while I don't know any Scala whatsoever,
wouldn't it be just as easy to do something like this:
add(new Form[Person](form, model) {
override def onInitialize: add (new TextArea[String](text, (getModel -
text)) {
override def isVisible: Boolean = false
})
})
Thanks for the reply -
Yes it would be as simple as that - but again, not quite as elegant (imho).
I actually think that it's more elegant to be explicit about the fact that your
components are constructed lazily during initialization rather than object
construction.
Given the recent feedback, cede that forcing onInitialize on everybody may not
be necessary, although I am still very convinced that it is the right thing to
do design-wise.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 09 Mar 2011, at 18:56, Igor Vaynberg wrote:
On Wed, Mar 9, 2011 at 1:15 AM, Maarten Billemont lhun...@gmail.com wrote:
yep, calling overridable methods from constructors is bad - you just
made the case for making page.oninitialize() final...
No, I've made the case for this issue. Either add() should be disallowed
from the constructor (meaning onInitialize won't get called from it),
onInitialize should be made final (meaning onInitialize will do nothing when
it gets called), or Page should stop calling initialize() as a result of a
component being added, and behave like any other component does. Would you
mind addressing this third option? What exactly is the reason for Page
behaving in this special way?
page.add() is where the oninitialize cascade is initiated because that
is the earliest point at which the page instance is known. doing it
from there ensures that the page is more or less fully constructed
after it is instantiated allowing you to call methods on it.
Why should Page be a special case? Why not for Panels too?
In fact, if you take away this special casing for Page, this issue probably
wouldn't exist at all and we could go back to letting the constructor-favored
users use constructors and the others use onInitialize.
eg MyPage page=new MyPage();
page.foo() { where foo manipulates state of page's child components }
i know that is not the style you prefer to use in your applications,
but that doesnt mean no one should be able to use it.
This issue is about the fact that this style, which I've argued is flawed, is
basically causing you to finalize onInitialize, meaning no one will be able to
use the alternative. It cuts both ways, and I really don't see why
onInitialize should come out as the looser when it condones safer code.
On 09 Mar 2011, at 09:15, Igor Vaynberg wrote:
Firstly, it's my opinion that you really shouldn't be doing anything to
components directly, especially not from outside your class. As for why,
see Encapsulation and Law of Demeter.
neither of the two apply because nameeditor explicitly exposes the two
components as part of its contract via public getters.
Allow me to remind you:
More formally, the Law of Demeter for functions requires that a method M of
an object O may only invoke the methods of the following kinds of objects:
• O itself
• M's parameters
• any objects created/instantiated within M
• O's direct component objects
• a global variable, accessible by O, in the scope of M
Making your components available via getters does not excuse anything. The
list does not include invoke methods on any objects created by any objects
created within M, for good reason.
yes, and if we follow this good reason then i would have to add the
following methods:
nameditor {
setfirstnamevisible() {}
setlastnamevisible() {}
setfirstnameenabled() {}
setlastnameenabled() {}
setfirstnamerequired() {}
setlastnamerequired() {}
addfirstnamevalidator() {}
addlastnamevalidator() {}
setfirstnamelabel() {}
setlastnamelabel() {}
}
just to name a few, and all they do is forward stuff to the two inner
components. sounds like a lot of fun...
Actually, that would be a workaround to hack away a warning your IDE might give
you about the Law of Demeter. The point of the practice is that outside of
NameEditor, you shouldn't be doing anything that requires knowledge of how
NameEditor works. Which means you shouldn't be exposing any of its components,
and definitely none of its components' properties. If you want to do something
to your NameEditor that changes the way it shows your name, you should express
that in terms that make sense for a name editor.
new NameEditor(NameEditorMode.FIRST_NAME_ONLY);
Or whatever API makes sense to you. Just don't expose NameEditor's guts.
Also, I really don't like condoning get(String), it's nasty and very
type-unfriendly. It also breaks as soon as you do any refactoring in your
component hierarchy.
yes, i traded off some refactorability for better memory footprint.
imho a perfectly valid trade off when memory and space are costly.
there are still problems with this:
*you still have the two extra memory slots that are a complete waste
here - component references
You're talking about the cost of a reference to a component. It's not like
you've got a COPY of the component in your field. And no, it's not a good
trade-off. You're writing Java applications, you'll be deploying in Java
application containers, you're working with a web framework that goes to
great lengths to help the container provide solid clustering. Your memory
footprint is absolutely subordinate to decently maintainable and
compile-time checked code. If you're a developer that doesn't appreciate
the latter, you'll find that you can be a lot more flexible using a language
with weak type checking
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 09 Mar 2011, at 21:42, Igor Vaynberg wrote: oninitialize() is an atomic callback that notifies components when the page becomes available. the page is special because since a page is always available to itself it doesnt need such a callback. how is that for a rationalization... :) Only, you're special-casing initialize() in Pages so that onInitialize() gets called as soon as the page is available, only to then disallow developers from using onInitialize() by making it final. Kind of defeats the whole point, doesn't it. And I can't see initialize() doing anything else that the developer might notice. So really, just don't do it. In fact, if you take away this special casing for Page, this issue probably wouldn't exist at all and we could go back to letting the constructor-favored users use constructors and the others use onInitialize. that may very well be true. but weve come a long way from the beginning of this thread which was: forbid add() in constructors. We have come a long way, but if onInitialize didn't behave this way for pages, that would be an ideal solution to the issue that wouldn't force onInitialize or the constructor (or a lame onConfigure hack). interesting because in the beginning of this thread you wanted to blindly castrate constructors :) I explained the issue and proposed solutions. One of them involved not creating component hierarchies from the constructors. I wouldn't call that castrating: You still get to use them for what they're supposed to do: initialize your instance's state. i have proposed a way to deal with the issue. you can create your own one-time callback in the page from inside onconfigure(). So to round up, the proposed solutions are: 1. Forbid add() in constructor. 2. Forbid onInitialize() in pages (and fake one with onConfigure code that really has nothing to do with configuring but is onInitialize code in a block that requires a test of an instance field that takes up a whole boolean field in your page state, and do that for each of your pages). 3. Don't initialize() on add() in pages. * -1 to forbid add() from constructors * +0 to delay oninitialize() cascade until right before the first call to onconfigure() So that's [1] and [3] out the window, does that mean you vote +1 for [2]? Because as I mentioned before, you can't in all honesty argue the case of leaving the door open for add() in constructors if the developer want to do that and slam the door shut for add() in onInitialize() if the developer wants to do that. Perhaps we can add a [4]: 4. Allow both and ignore the fact that mixing them will break things in pages. Heck, if we can allow doing potentially bad things in constructors because the bad is rare anyway, why not, right? My vote, in order of preference, would be [1], [3], [4], [2]. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: CompoundPropertyModel deprecated in 1.5 - what is the replacement?
On 09 Mar 2011, at 22:01, Chris Colman wrote: Sorry, CompoundPropertyModel is not deprecated in 1.5, it's BoundCompoundPropertyModel that is. Too bad :-) Really, you use normal models and LDMs, or BindGen (http://code.google.com/p/bindgen-wicket/) and make your code type-safe. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 09 Mar 2011, at 23:31, Chris Colman wrote: Surely there must be a way to support both styles of 'construction' (I use that term loosely) within the one framework. My proposed [3] and [4] already does that without an external configuration option that would confuse things about as much as JSF's faces-config.xml and all that good stuff. But sure, you could implement [1] and allow the developer to turn off the RTE from an Application setting. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: CompoundPropertyModel deprecated in 1.5 - what is the replacement?
On 09 Mar 2011, at 22:36, Brown, Berlin [GCG-PFS] wrote: On 09 Mar 2011, at 22:01, Chris Colman wrote: Sorry, CompoundPropertyModel is not deprecated in 1.5, it's BoundCompoundPropertyModel that is. Too bad :-) Really, you use normal models and LDMs, or BindGen (http://code.google.com/p/bindgen-wicket/) and make your code type-safe. What is wrong with compoundpropertymodel (pre 1.5)? Your model object is not used in a type-safe and refactorable/compile-time checked (read maintainable) manner. Read the bindget URL I linked for more info or perhaps more informative: http://wicketinaction.com/2009/11/removing-fragile-string-expressions-from-wicket-code/ Usually though, I tend to just use normal IModels, Models, AROMs and LDMs, though. Those are perfectly safe thanks to Java's generics, albeit a bit verbose no thanks to Java's lacking support for closures. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: RestartResponseAtInterceptPageException not redirecting to source Page
On 10 Mar 2011, at 04:25, Henrique Boregio wrote:
Hi, I have a RestartResponseAtInterceptPageException working correctly in
one case and not so in another.
I have a Login page with a LoginForm. In this form's onSubmit method, right
after the user validation takes place, I have:
if(!continueToOriginalDestination()) {
setResponsePage(Dashboard.class);
}
In what wicket method is this?
When this is called form the following Page, it works correctly (the users
gets redirected to the Login page, and once he logs in correctly, he is
redirected back to the page below):
public class PublishItem {
public PublishItem() {
if(!UserLoggedInSession.get().isLoggedIn()) {
UserLoggedInSession.get().getFeedbackMessages().add(getPage(), You need to
Sign in before you can publish!, FeedbackMessage.INFO);
throw new RestartResponseAtInterceptPageException(Login.class);
}
}
}
getPage().info(You need to Sign in ..);
Also, you should probably do this check in an onBeforeRender, not in a
constructor.
However, when this same logics is applied from within a Link's onClick
method, it does not work:
AnotherPage.java
Link signinLink = new Link(siginLink) {
public void onClick() {
UserLoggedInSession.get().getFeedbackMessages().add(getPage(), Signin
before adding a comment!, FeedbackMessage.INFO);
throw new RestartResponseAtInterceptPageException(Login.class);
}
};
signinLink.setVisible(!userLoggedIn);
add(signinLink);
Your Link should override onConfigure and in there you should
setVisible(!userLoggedIn) instead of only performing this check on page
construction.
In this second case, the user does get redirected to the Login page, and
once the correct username/password combination is entered, he actually logs
into the system. The problem is that the Login page simply refreshes, and
does not get redirected back to AnotherPage.java
But none of those tips likely have anything to do with what you're saying the
problem is. I suggest you attach a debugger on the point where you complete
log-in and see what flow wicket follows and where it deviates from what you
expect it to do.
Any help is appreciated.
Thanks.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
[VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
Dear fellow wicket users,
Following is a call for your opinion and a vote on how Wicket should behave
with regards to post-constructing components in 1.5. The final solution that
is chosen will affect the way you construct your components and your component
hierarchies.
First, some background on what onInitialize is and why you should be using it.
THE PROBLEM
Historically, we've generally used our component constructors to build our
component's hierarchy. We call add() to put new components in our custom
component from our component's constructor:
public class MyPanel extends Panel {
private final IModelString name = Model.of();
public MyPanel(String id) {
add(new TextFieldString(name, name));
}
}
This can cause problems, however, when initializing a component requires
knowledge of the component's markup, or requires that the component's path in
the hierarchy is known (during construction, the component is not yet added to
any parent component).
THE SOLUTION
onInitialize was introduced to Component. This gives us a place to initialize
our component's hierarchy after our component has been added to its parent. As
a result, our component has a path to its page, making markup, parent and
sibling components accessible.
THE BAD
The downside of initializing your component hierarchy in onInitialize as
opposed to from the constructor, are:
1. You need to move all your component hierarchy initialization code into a
separate method. Usually, this is trivial work (cut/paste), but it is work
that needs to be done nonetheless.
2. You cannot put your components in final instance fields anymore.
3. You should never do anything with components from custom methods. You
should only ever reference your components directly from overridden wicket
methods, such as onConfigure, onBeforeRender, onSubmit, etc.
A little more on #3:
If you add custom methods to your component, eg.
void makeRequired() {
nameField.setRequired(true);
}
You allow things like: new MyPanel().makeRequired();
That would throw a NullPointerException, since nameField is no longer
initialized in the constructor, but much later, before the component first gets
rendered.
I would argue, though, that any custom methods that touch components are to be
avoided at all cost. Component behaviors should never be touched except from
wicket lifecycle methods (you probably want onConfigure) or right after you
construct it: add(new TextFieldString(name, name).setRequired(true)); If
you need a custom method such as makeRequired, it shouldn't touch components,
it should set state that gets used by onConfigure:
void makeRequired() {
this.required = true;
}
void onConfigure() {
setRequired(required);
}
(Obviously, the example is rather silly..)
Fast-forward to https://issues.apache.org/jira/browse/WICKET-3218, it seems
onInitialize has a problem.
THE PROBLEM
With regard to pages, if you add a component to a page from the constructor,
onInitialize is invoked immediately. As a result, onInitialize code is ran
even though your instance hasn't been fully constructed yet. This is bad.
The real issue here is that we can combine component hierarchy initialization
with constructors and onInitialize in a single class. However, doing so causes
dangerous situations. We really should do only one, not both at the same time.
THE SOLUTIONS
This is where we need your vote. Currently, two proposed solutions exist:
1. Make onInitialize final for all Pages. As a result, onInitialize will still
get called when the page is constructed and components are added, but you won't
be able to use it, avoiding the risk of you using it in a manner that requires
your instance to be constructed.
2. Make adding components from the constructor illegal. This would have to be
by means of a runtime exception thrown whenever you try to add components to
the hierarchy from the constructor.
THE GOOD
1. This will be least painful for existing code. In all components, you can
still mix constructor an onInitialize use, in pages, you can't use
onInitialize, but in all likelihood, the largest amount of existing wicket code
out there still uses constructors to create component hierarchies.
2. The safer onInitialize will always and consistently be used for any
component hierarchy construction. This also requires the good code habits that
you shouldn't be doing anything with your components outside of wicket
lifecycle methods.
THE BAD
1. Mixing constructor and onInitialize usage, whether it's within one class or
between different classes in your type and component hierarchy, is and will
always be dodgy. You really shouldn't do it. Also, to future-proof your code,
you should really already be moving your initialization code into onInitialize.
Additionally, this introduces an API inconsistency: For pages, you cannot use
onInitialize, for everything else, you should. That's not very
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
Perhaps one question: Why is onInitialize invoked immediately after a component is added to a page? Page#componentAdded(final Component component) (line 1603 in 1.4.15). Is it really necessary to initialize the page here, and if so, why? The only possibly useful thing I can see it doing is fireComponentInitializationListeners, but why can't that just happen later, before the first render? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 08 Mar 2011, at 16:39, Pedro Santos wrote: I vote for solution 3: postpone the onInitialize call, possible to the first Component#configure execution. Then the problem of initialization code being executed for not fully constructed components go away. I actually also thought of that, which is why I asked for the reason as to why initialize() is invoked as a result of components being added to a page. If it ends up not being necessary (delay the onInitialize to when it's called for any other component) then perhaps that's a fair middle ground. People can still use constructors if they like (though really, the only single *advantage* I can think of for this is that it means you don't have to go back and fix your existing codebase), and others are free to use onInitialize. Doing your work post-construct is a very common thing in Java. That's the whole point of there being a javax.annotation.PostConstruct, for example. Anyone that claims doing this is bad or counter-intuitive probably hasn't seen enough Java code yet. We're stuck with a legacy of how we used to do things in Wicket. And yes, that is a burden we should consider. But at some point, in favor of a clean API and consistency, you need to be able to give up legacy. Perhaps 1.5 is that time, perhaps it should be 1.6, but kid yourself not: it will be all that much harder the longer we wait. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 08 Mar 2011, at 17:38, Hans Lesmeister 2 wrote: +1 for making Page.onInitialize() non-final. Since 1.4.12 we have migrated a lot of code moving construction of the component hierarchies to onInitialize. We are really very happy with the way it is now in 1.4. -1 for throwing an exception if add(..) is called from within a constructor (but maybe logging a warning instead?) This is a valid vote if we can come up with a way of not having random failure side-effects from mixing the two (which is the whole reason the the issue exists in the first place), without a final onInitialize and an exception in add(). If such a solution is not suggested in this thread, we're gonna need either a final onInitialize or an exception in add(). You can't have your cake and eat it too. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 08 Mar 2011, at 17:54, Carl-Eric Menzel wrote: However, there are much better arguments than existing codebase for still allowing constructors. First, constructors are natural places to do stuff like that. Yes, they have limitations, and yes, PostConstruct exists for a reason, but that doesn't render constructors obsolete. Your constructors are the perfect place to initialize your instance, at least at the level of your constructor's type. Build all your instance variables there, handle your page parameters, and that stuff. Just like EJBs, you should be careful about how much interaction you do beyond your object's scope within the constructor. Your component doesn't have a hierarchy, getPage() cannot be accessed, none of your subclass constructors have been invoked and therefore your instance is not properly initialized and ready for use. You really shouldn't be doing anything in your constructor that is NOT related to initializing your constructor type's instance variables. Touch anything else, invoke any methods, and you are opening pandora's box. It's important to understand *what* constructors are a natural place for. Second, if you need to use any kind of parameters for stuff you do in onInitialize, you *must* store them in instance variables, even if you need them just once and could have long let them be garbage collected. Going purely post-construct would be a very bad idea for this reason. Sorry? Parameters? You mean arguments to your components' constructor? Of course, but you really shouldn't ever need these in onInitialize if they're not state. And yes, your component's state belongs in its instance variables. If this is an issue, could you enlighten me? - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
Just like EJBs, you should be careful about how much interaction you do
beyond your object's scope within the constructor. Your component doesn't
have a hierarchy, getPage() cannot be accessed, none of your subclass
constructors have been invoked and therefore your instance is not properly
initialized and ready for use.
not really sure what you mean by subclass constructors or how they
come into play when constructing an instance...
If I understand correctly, here is an example of what he means :
Exactly. If B extends A and I do something in A's constructor that goes beyond
the scope of setting up A's instance variables, then I risk a side-effect that
relies on the instance to be constructed at B's level as well. There's nothing
in the JVM that prevents this and these bugs are very hard to see and debug.
They should be avoided by good coding practices.
On 08 Mar 2011, at 22:07, Igor Vaynberg wrote:
i think code like this should be possible:
NameEditor e=new NameEditor(name, firstNameModel, lastNameModel);
e.getFirstNameEditor().setRequired(true);
e.getLastNameEditor().setEnabled(false);
taking the previous example of a name editor, with constructor we have:
class nameeditor extends panel {
public nameeditor(...) {
add(new textfield(first,..);
add(new textifled(last, ...);
}
public textfield getfirst() { return get(first); }
public textfield getlast() { return get(last); }
}
Firstly, it's my opinion that you really shouldn't be doing anything to
components directly, especially not from outside your class. As for why, see
Encapsulation and Law of Demeter.
But if you really wanted to use this pattern, it really wouldn't have to be as
cumbersome as you make it out to be. Also, I really don't like condoning
get(String), it's nasty and very type-unfriendly. It also breaks as soon as
you do any refactoring in your component hierarchy.
class NameEditor extends Panel {
TextFieldString firstField;
TextFieldString lastField;
@Override protected void onInitialize() { super.onInitialize();
add(getFirst(), getLast()); }
public textfield getFirst() { if (firstField == null) firstField = new
TextFieldString(); return firstField; }
public textfield getLast() { if (lastField == null) lastField = new
TextFieldString(); return lastField; }
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
