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
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
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,
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
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
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
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
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
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
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
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,
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.
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
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
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:
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
[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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
37 matches
Mail list logo
