CompoundPropertyModel deprecated in 1.5 - what is the replacement?
I noticed that CompoundPropertyModel is deprecated in 1.5 but I can't find anything relating to this on the "Migration to Wicket 1.5" page. What is meant to be used instead of this class? DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. --
Models doco page typo?
At the bottom of this page: https://cwiki.apache.org/WICKET/working-with-wicket-models.html it says that the IModel interface was simplified in Wicket 2.0... should that really be Wicket 1.2? Never heard of Wicket 2 and I can see the 'new' style interface in Javadocs for 1.5. DISCLAIMER:--- This e-mail transmission and any documents, files and previous e-mail messages attached to it are private and confidential. They may contain proprietary or copyright material or information that is subject to legal professional privilege. They are for the use of the intended recipient only. Any unauthorised viewing, use, disclosure, copying, alteration, storage or distribution of, or reliance on, this message is strictly prohibited. No part may be reproduced, adapted or transmitted without the written permission of the owner. If you have received this transmission in error, or are not an authorised recipient, please immediately notify the sender by return email, delete this message and all copies from your e-mail system, and destroy any printed copies. Receipt by anyone other than the intended recipient should not be deemed a waiver of any privilege or protection. Thales Australia does not warrant or represent that this e-mail or any documents, files and previous e-mail messages attached are error or virus free. --
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 {
TextField firstField;
TextField lastField;
@Override protected void onInitialize() { super.onInitialize();
add(getFirst(), getLast()); }
public textfield getFirst() { if (firstField == null) firstField = new
TextField(); return firstField; }
public textfield getLast() { if (lastField == null) lastField = new
TextField(); return lastField; }
}
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Not bookmarkable setResponsePage(new MyPage(pageParameters, extraParam1, extraParam2))
Wicket only knows how to construct bookmarkable pages when they have either a default constructor or a constructor taking *only* pageparameters. Any other constructor is outside the realm of wicket's capabilities and responsibility. In your case, how could Wicket construct the page when it is directly navigated to without going through the form? That is bookmarkability. The only way is to add those extra parameters to the PageParameters object and use setResponsePage(MyPage.class, parameters) Martijn On Wed, Mar 9, 2011 at 5:09 AM, Alec Swan wrote: > Hello, > > I have a form which calls the following statement in its onSubmit() method: > > setResponsePage(new MyPage(pageParameters, extraParam1, extraParam2)) > > NOTE: The MyPage construtor calls WebPage constructor as > super(pageParameters) and then adds extraParam1 and extraParam2 to > WebPage.getPageParameters() map. > > The end-result is that a user is redirected to a URL that has no parameters > in it, which means it cannot be bookmarked by the user. > > The goal is to have onSubmit() redirect the user to a page that has all > pageParameters encoded in the URL. > > What are we doing wrong and what is the recommended way to do this? > > Thanks > -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: visural-wicket running on wicket 1.5?
Thanks. I'll give feedback if needed On Mar 9, 2011 4:22 AM, "Richard Nichols" wrote: > I've committed what appears to be a mostly working visural-wicket with 1.5 > (rc2) compatibility. > > http://code.google.com/p/visural-wicket/source/browse/#svn%2Fbranches%2F1.5 > > If there are any issues found, please report them at > http://code.google.com/p/visural-wicket/ > > cheers, > Richard. > > On Wed, Mar 9, 2011 at 4:30 AM, nino martinez wael < > nino.martinez.w...@gmail.com> wrote: > >> ok great.. I'll probably take at look at it monday then.. >> >> 2011/3/8 Richard Nichols >> >> > Hi Nino, >> > >> > The version in the public respository 1.5 branch is still a direct copy >> of >> > 1.4 - sorry I haven't commited the WIP 1.5 changes yet. >> > >> > I'll aim to get the WIP committed in this week. >> > >> > cheers, >> > Richard. >> > >> > On Mon, Mar 7, 2011 at 6:47 PM, nino martinez wael < >> > nino.martinez.w...@gmail.com> wrote: >> > >> > > Strange it compiles well, but does not work as wanted.. Any idea on >> which >> > > parts are causing the problems? On my dropdowns the dropdowns are >> empty, >> > > and in my textfields both the text and the span are added if in view >> > mode, >> > > and if not 2 textfields are added. >> > > >> > > 2011/3/5 Richard Nichols >> > > >> > > > I've created a 1.5 branch and it's in the works. 1.5 broke more stuff >> > > > than expected :) >> > > > >> > > > Hopefully I can have a beta 1.5 branch functional within a few weeks >> > > > >> > > > Sent from my iPhone >> > > > >> > > > On 05/03/2011, at 6:15 AM, nino martinez wael >> > > > wrote: >> > > > >> > > > > So does has anybody run it on wicket 1.5, or is there something in >> > the >> > > > works >> > > > > for it? >> > > > > >> > > > > regards Nino >> > > > >> > > > - >> > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org >> > > > For additional commands, e-mail: users-h...@wicket.apache.org >> > > > >> > > > >> > > >> > >> > >> > >> > -- >> > Richard Nichols >> > http://www.richardnichols.net/ :: http://onmydoorstep.com.au/ >> > >> > > > > -- > Richard Nichols > http://www.richardnichols.net/ :: http://onmydoorstep.com.au/
Re: shift / ctrl / alt keys + ajax
You can do this on the client side relatively easily. Just bind a javascript event handler to the onkeydown event in the browser. When these key(s) are depressed change a form input to indicate which keys are pressed. When your Ajax event submits, you can check the model of the component the input is bound to to determine if the key(s) were pressed. cheers, Richard. On Tue, Mar 8, 2011 at 9:59 PM, Antoine van Wel wrote: > Hi, > > when clicking an (ajax)link, or a checkbox, etc, on the server side > I'd like to know whether the shift, ctrl or alt keys are pressed at > the same time. > > So I figure I need to fetch via JavaScript and adapt the ajax call > with some extra parameters. > Any thoughts how to do that in a nice & clean way in 1.5 without too > much hacking involved? > > > regards, > Antoine > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Richard Nichols http://www.richardnichols.net/ :: http://onmydoorstep.com.au/
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On 08/03/2011 4:07 PM, Igor Vaynberg wrote:
On Tue, Mar 8, 2011 at 11:42 AM, Maarten Billemont wrote:
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.
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 :
class A extends Panel {
public A() {
super("anID");
add(new Label("ALabel"));
}
// Hypothetic method called when a component is added
@Override
protected void onComponentAdd(Component component) {
// do stuff
}
}
class B extends A {
private final Label label;
public B() {
label = new Label("BLabel");
// etc.
}
@Override
protected void onComponentAdd(Component component) {
super.onComponentAdd(component);
// do stuff, accessing member label => NULL pointer exception
}
}
When an instance of B is created, the "B" part of the object is not
constructed yet and B#onComponentAdd() is called anyway.
I have a c++ background and this kind of problem is even more dangerous
in c++ (virtual calls don't work as normal in constructors). In Java
also, I think making "this" known to the outside world before it is
fully constructed is unsafe, as illustrated above.
Regarding the problem of storing Page or Panel constructor parameters:
Would it be possible to add a factory method to create Panels and Pages
in Wicket like so :
public static T initPanel(T instance, PageParameters
parameters) {
instance.initialize(parameters); // new method used to add() components
instance.onInitialize();
}
This could be used like this :
setResponsePage(WicketClassSomewhere.initPanel(new MyPanel("id"),
parameters);
I'm not crazy about this construct, but I'm pitching it anyway to maybe
inspire someone else.
As an aside, I also just learned with this thread that I should not be
adding components to a Page or Panel in the constructor but rather do it
in onInitialize(). I based this design on examples, Wicket in Action and
also read the 1.5 migration notes. I must have missed that somewhere!
Regards,
Bertrand Guay-Paquet
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.
i think code like this should be possible:
NameEditor e=new NameEditor("name", firstNameModel, lastNameModel);
e.getFirstNameEditor().setRequired(true);
e.getLastNameEditor().setEnabled(false);
its simply the "good citizen pattern" where once you have an instance
that instance is fully constructed and is ready to use. i think this
applies to most components. i think there are much fewer components
that need a page or their environment to work, and most of them are
application-specific. wicket is all about reusability, and we should
not hinder how easy and convenient it is to create and use reusable
components.
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?
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"); }
}
without constructing components i would have to do this:
class nameeditor extends panel {
private boolean firstNameRequired, lastNameRequired;
private boolean firstNameEnabled,
Re: Not bookmarkable setResponsePage(new MyPage(pageParameters, extraParam1, extraParam2))
you cannot have a bookmarkable url for a page instance, only for a page class with parameters, so setResponsePage(MyPage.class, somePageParameters) will give you a bookmarkable url -igor On Tue, Mar 8, 2011 at 8:09 PM, Alec Swan wrote: > Hello, > > I have a form which calls the following statement in its onSubmit() method: > > setResponsePage(new MyPage(pageParameters, extraParam1, extraParam2)) > > NOTE: The MyPage construtor calls WebPage constructor as > super(pageParameters) and then adds extraParam1 and extraParam2 to > WebPage.getPageParameters() map. > > The end-result is that a user is redirected to a URL that has no parameters > in it, which means it cannot be bookmarked by the user. > > The goal is to have onSubmit() redirect the user to a page that has all > pageParameters encoded in the URL. > > What are we doing wrong and what is the recommended way to do this? > > Thanks > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Not bookmarkable setResponsePage(new MyPage(pageParameters, extraParam1, extraParam2))
Hello, I have a form which calls the following statement in its onSubmit() method: setResponsePage(new MyPage(pageParameters, extraParam1, extraParam2)) NOTE: The MyPage construtor calls WebPage constructor as super(pageParameters) and then adds extraParam1 and extraParam2 to WebPage.getPageParameters() map. The end-result is that a user is redirected to a URL that has no parameters in it, which means it cannot be bookmarked by the user. The goal is to have onSubmit() redirect the user to a page that has all pageParameters encoded in the URL. What are we doing wrong and what is the recommended way to do this? Thanks
Re: visural-wicket running on wicket 1.5?
I've committed what appears to be a mostly working visural-wicket with 1.5 (rc2) compatibility. http://code.google.com/p/visural-wicket/source/browse/#svn%2Fbranches%2F1.5 If there are any issues found, please report them at http://code.google.com/p/visural-wicket/ cheers, Richard. On Wed, Mar 9, 2011 at 4:30 AM, nino martinez wael < nino.martinez.w...@gmail.com> wrote: > ok great.. I'll probably take at look at it monday then.. > > 2011/3/8 Richard Nichols > > > Hi Nino, > > > > The version in the public respository 1.5 branch is still a direct copy > of > > 1.4 - sorry I haven't commited the WIP 1.5 changes yet. > > > > I'll aim to get the WIP committed in this week. > > > > cheers, > > Richard. > > > > On Mon, Mar 7, 2011 at 6:47 PM, nino martinez wael < > > nino.martinez.w...@gmail.com> wrote: > > > > > Strange it compiles well, but does not work as wanted.. Any idea on > which > > > parts are causing the problems? On my dropdowns the dropdowns are > empty, > > > and in my textfields both the text and the span are added if in view > > mode, > > > and if not 2 textfields are added. > > > > > > 2011/3/5 Richard Nichols > > > > > > > I've created a 1.5 branch and it's in the works. 1.5 broke more stuff > > > > than expected :) > > > > > > > > Hopefully I can have a beta 1.5 branch functional within a few weeks > > > > > > > > Sent from my iPhone > > > > > > > > On 05/03/2011, at 6:15 AM, nino martinez wael > > > > wrote: > > > > > > > > > So does has anybody run it on wicket 1.5, or is there something in > > the > > > > works > > > > > for it? > > > > > > > > > > regards Nino > > > > > > > > - > > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > > > > > > > > > > > > -- > > Richard Nichols > > http://www.richardnichols.net/ :: http://onmydoorstep.com.au/ > > > -- Richard Nichols http://www.richardnichols.net/ :: http://onmydoorstep.com.au/
Re: Run a standalone wicket app
Hello all! Nice replies, I really appreciate them. I liked the maven plugin, that was exactly what i was looking for. Winstone also looked like a good alternative. Thanks for the replies. Regards! On Tue, Mar 8, 2011 at 9:02 PM, Nitnatsnok wrote: > To create a runnable .war file with just a maven plugin I used this tool: > > http://simplericity.com/2009/11.html > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/Run-a-standalone-wicket-app-tp3339521p3342507.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 > > -- Mauro Ciancio http://about.me/maurociancio - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Run a standalone wicket app
To create a runnable .war file with just a maven plugin I used this tool: http://simplericity.com/2009/11.html -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/Run-a-standalone-wicket-app-tp3339521p3342507.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
Choice of Resource for my Image component
Hello,
I have been a naughty boy; I designed my form without using a
LoadableDetachableModel. Serves me right. I have now changed my page's
domain object so that it is used in the form and the form's WebPage using a
LoadableDetachableModel.
So far so good, but I have a problem with my Image component. I used to use
my page's domain object to populate my image component's model like this:
ByteArrayResource resImage = null;
if ((g_pidData.sUploadFileContentType != null)
&& (g_pidData.baUploadFileData != null))
resImage = new ByteArrayResource(g_pidData.sUploadFileContentType,
g_pidData.baUploadFileData);
Image g_imgImage = new Image("imgImage", resImage);
frmForm.add(g_imgImage);
Basically, I used the return value of
ByteArrayResource(String sUploadFileContentType, byte[] baUploadFileData);
as the model of my Image component, with g_pidData as my domain object.
Now I have replaced my domain object with a LoadableDetachableModel. This
model's load() method returns a ByteArrayResource instance, created by using
the data members of a g_pidData instance which is local to the page's
constructor. I copy the byte array using Arrays.copyOf(...) before
constructing my ByteArrayResource instance.
I now get the following exception once my page has shown:
08-Mar-2011 21:24:15 org.apache.wicket.RequestCycle logRuntimeException
SEVERE: Unable to write the response
org.apache.wicket.WicketRuntimeException: Unable to write the response
at org.apache.wicket.Response.handleException(Response.java:286)
at org.apache.wicket.Response.write(Response.java:310)
...
Caused by: java.io.IOException: Closed
at
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:629)
at
org.mortbay.jetty.AbstractGenerator$Output.write(AbstractGenerator.java:579)
at org.apache.wicket.util.io.Streams.copy(Streams.java:159)
at org.apache.wicket.util.io.Streams.copy(Streams.java:126)
at org.apache.wicket.Response.write(Response.java:306)
... 32 more
Am I using the correct resource for my image component, or should I use a
better one?
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/Choice-of-Resource-for-my-Image-component-tp3342289p3342289.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
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On Tue, Mar 8, 2011 at 11:42 AM, Maarten Billemont wrote:
> 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.
not really sure what you mean by subclass constructors or how they
come into play when constructing an instance...
> 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.
i think code like this should be possible:
NameEditor e=new NameEditor("name", firstNameModel, lastNameModel);
e.getFirstNameEditor().setRequired(true);
e.getLastNameEditor().setEnabled(false);
its simply the "good citizen pattern" where once you have an instance
that instance is fully constructed and is ready to use. i think this
applies to most components. i think there are much fewer components
that need a page or their environment to work, and most of them are
application-specific. wicket is all about reusability, and we should
not hinder how easy and convenient it is to create and use reusable
components.
>> 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?
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"); }
}
without constructing components i would have to do this:
class nameeditor extends panel {
private boolean firstNameRequired, lastNameRequired;
private boolean firstNameEnabled, lastNameEnabled;
protected void oninitialize() {
add(new textfield("first",..);
add(new textifled("last", ...);
}
protected void onconfigure() {
first.setrequired(firstNameRequired).setEnabled(firstNameEnabled);
last.setrequired(lastNameRequired).setEnabled(lastNameEnabled);
}
public void setFirstNameRequired(value) { firstNameRequired=value; }
public void setLastNameRequired(value) { lastNameRequired=value; }
public void setFirstNameEnabled(value) { firstNameEnabled=value; }
public void setLastNameEnabled(value) { lastNameEnabled=value; }
}
notice the verbosity, and four extra and redundant slots that this
component now takes up in memory and when serialized...
-igor
> -
> 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] WICKET-3218 - Component#onInitialize is broken for Pages
On Tue, Mar 8, 2011 at 6:03 PM, GOODWIN, MATTHEW (ATTCORP) wrote: > +1 for clear documentation/Javadoc explaining proper use of > onInitialize. > > Does this exist somewhere? As someone new to Wicket I'm trying to learn > as fast as I can and a lot of examples (almost exclusively) I see out > there show the add(..) from within the constructor - which is apparently > an anti-pattern from the sound of this thread. It is most certainly not an antipattern in my book. I find the reaction of the anti-constructor folks too strong and am trying to formulate a civil reaction to this whole anti constructor rant. Martijn - 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: visural-wicket running on wicket 1.5?
ok great.. I'll probably take at look at it monday then.. 2011/3/8 Richard Nichols > Hi Nino, > > The version in the public respository 1.5 branch is still a direct copy of > 1.4 - sorry I haven't commited the WIP 1.5 changes yet. > > I'll aim to get the WIP committed in this week. > > cheers, > Richard. > > On Mon, Mar 7, 2011 at 6:47 PM, nino martinez wael < > nino.martinez.w...@gmail.com> wrote: > > > Strange it compiles well, but does not work as wanted.. Any idea on which > > parts are causing the problems? On my dropdowns the dropdowns are empty, > > and in my textfields both the text and the span are added if in view > mode, > > and if not 2 textfields are added. > > > > 2011/3/5 Richard Nichols > > > > > I've created a 1.5 branch and it's in the works. 1.5 broke more stuff > > > than expected :) > > > > > > Hopefully I can have a beta 1.5 branch functional within a few weeks > > > > > > Sent from my iPhone > > > > > > On 05/03/2011, at 6:15 AM, nino martinez wael > > > wrote: > > > > > > > So does has anybody run it on wicket 1.5, or is there something in > the > > > works > > > > for it? > > > > > > > > regards Nino > > > > > > - > > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > > > > > > > > -- > Richard Nichols > http://www.richardnichols.net/ :: http://onmydoorstep.com.au/ >
RE: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
+1 for clear documentation/Javadoc explaining proper use of onInitialize. Does this exist somewhere? As someone new to Wicket I'm trying to learn as fast as I can and a lot of examples (almost exclusively) I see out there show the add(..) from within the constructor - which is apparently an anti-pattern from the sound of this thread. Thanks, Matt -Original Message- From: Hans Lesmeister 2 [mailto:hans.lesmeis...@lessy-software.de] Sent: Tuesday, March 08, 2011 11:38 AM To: users@wicket.apache.org Subject: Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages +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 clear documentation/Javadoc explaining proper use of onInitialize. (Developers who don't want to follow that explanation do also not have to be protected agains themselves) -1 for throwing an exception if add(..) is called from within a constructor (but maybe logging a warning instead?) I would also not have a problem with an alternative onInitialize()-method for the Pages. - -- Regards, Hans http://cantaa.de -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/VOTE-WICKET-3218-Component-on Initialize-is-broken-for-Pages-tp3341090p3341741.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: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
On Tue, 8 Mar 2011 17:46:26 +0100 Maarten Billemont wrote: > 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. I think there are good arguments for both constructors and onInitialize. But the developer needs to know what he/she is doing. I think that both options are useful and valid. This is certainly not a case of having the cake and eating it too. Constructor-only makes some initializations more difficult (though of course you can still use onBeforeRender or onConfigure, as we do now, after my patch had been rejected originally). onInitialize-only increases memory footprint and introduces conceptually unnecessary state by forcing you to carry *every* parameter via an instance field. Having both lets the developer choose the most appropriate strategy for the component at hand. Carl-Eric www.wicketbuch.de - 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 Tue, 8 Mar 2011 17:43:29 +0100 Maarten Billemont wrote: > 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. Fun fact: There is already a patch for that... > 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. I would like to use onInitialize for things that *need* to be done outside of the constructor. 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. 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. Carl-Eric www.wicketbuch.de - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: DataProvider calling a Service/Dao that requires a domain object
Thanks Michael for your quick response.
Let me know if I got it correctly:
I created the following generic model:
public class GenericDetachableModel extends LoadableDetachableModel {
private final long id;
private final Service service;
public GenericDetachableModel(T object, Service service) {
this(object, object.getId(), service);
}
public GenericDetachableModel(T object, long id, Service service) {
super(object);
if (id == 0) {
throw new IllegalArgumentException();
}
this.id = id;
this.service = service;
}
@Override
protected T load() {
return (T) service.find(id);
}
}
Now, when I create the DataProvider in my page I can use:
myModel = new GenericDetachableModel( domainObjectY, aService );
...
myDataProv = new MyDataProvider( myModel, aService );
And then inside MyDataProvider I can use:
public MyDataProvider(IModel myModel, Service aService) {
this.myModel = myModel;
this.aService = aService;
}
public int size() {
return service.countAllByDomainObjectY( myModel.getObject() );
}
public void detach() {
myModel.detach();
}
Is this ok?
Should myModel property in MyDataProvider be @Transient?
Is it ok to call myModel.detach() inside the MyDataProvider's detach? or
should I do it outside? (I mean, from the page where I created the
DataProvider)
Thanks in advance!
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/DataProvider-calling-a-Service-Dao-that-requires-a-domain-object-tp3341572p3341770.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
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 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
+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 clear documentation/Javadoc explaining proper use of onInitialize. (Developers who don't want to follow that explanation do also not have to be protected agains themselves) -1 for throwing an exception if add(..) is called from within a constructor (but maybe logging a warning instead?) I would also not have a problem with an alternative onInitialize()-method for the Pages. - -- Regards, Hans http://cantaa.de -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/VOTE-WICKET-3218-Component-onInitialize-is-broken-for-Pages-tp3341090p3341741.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
Re: Storing and loading escaped special characters.
call setescapemodelstrings(false) on the textfields to disable escaping.
-igor
On Tue, Mar 8, 2011 at 7:48 AM, Henrique Boregio wrote:
> Hi, quick question.
> Wicket automatically escapes special characters so when I type in:
> This is "my" house.
>
> What gets stored in my database is: This is "my" house
>
> When I try to display it using a Label, like:
> new Label("label", DAO.getValue(id));
>
> It does not convert the " to quotes.
>
> Is there a way to automatically do this or do I have to manually check
> and convert everything?
>
> Thanks.
>
> -
> 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: How to stop concurrent logins?
wont the user have two or more sessions if they are logged in concurrently? -igor On Tue, Mar 8, 2011 at 5:52 AM, shetc wrote: > Sorry Igor, I think I'm missing something obvious here. Won't the GUID from > the cookie and session > always match as the cookie was generated from the equivalent session? > > -- > View this message in context: > http://apache-wicket.1842946.n4.nabble.com/How-to-stop-concurrent-logins-tp3332127p3341407.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
Storing and loading escaped special characters.
Hi, quick question.
Wicket automatically escapes special characters so when I type in:
This is "my" house.
What gets stored in my database is: This is "my" house
When I try to display it using a Label, like:
new Label("label", DAO.getValue(id));
It does not convert the " to quotes.
Is there a way to automatically do this or do I have to manually check
and convert everything?
Thanks.
-
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
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.
If it is really important to have a callback method for path cognizant
components, than the API can be improved adding one more method like the awt
Component#addNotify, but with one change: this method needs to be called
again if the component is remove / re added and it will not be a good place
to add children.
- 1 for solution 2, it is up to user decide how to code objects, the related
problems in this thread can be addressed in different way, like I voted
before.
On Tue, Mar 8, 2011 at 8:11 AM, Maarten Billemont wrote:
> 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 IModel name = Model.of();
>
>public MyPanel(String id) {
>
>add(new TextField("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 TextField("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
Re: DataProvider calling a Service/Dao that requires a domain object
Hi,
Pass an IModelmodel into your dataprovider instead of the
DomainObject itself.
e.g.
class MyPanel
private final IModelmodel;
public MyPanel (String id) {
super (id);
model = new LoadableDetachableModel() {
protected DomainObject load() {// return object
}
add (new DataTable ("table", columns, new DomainObjectAwareProvider
(model), ...);
}
protected void detatchModels() {
model.detatch();
super.detatchModels();
}
}
The detachment of the model can be managed by the panel that creates the
model and you can just use the object returned from the model within
your data provider. This is better than passing the ID because your
provider can just work against the DomainObject without also having to
be responsible for loading it.
Regards,
Mike
Hi,
I have a DataProvider that implements IDataProvider, and for example in the
size method I need to call the service as follows:
public int size() {
return service.countAllByDomainObjectY(domainObjectY);
}
DomainObjectX contains a manytoone relationship with DomainObjectY.
So, this countAllByDomainObjectY internally searches by the domainObjectY's
id and returns the count of DomainObjectX associated with that specific
domainObjectY.
Now, in order to do this I would need to have domainObjectY as a property of
the DataProvider which I think it is not good because it would be
serialized.
Should I change the service to receive just the domainObjectY's id and only
"save" this id as a property of the DataProvider?
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/DataProvider-calling-a-Service-Dao-that-requires-a-domain-object-tp3341572p3341572.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
DataProvider calling a Service/Dao that requires a domain object
Hi,
I have a DataProvider that implements IDataProvider, and for example in the
size method I need to call the service as follows:
public int size() {
return service.countAllByDomainObjectY(domainObjectY);
}
DomainObjectX contains a manytoone relationship with DomainObjectY.
So, this countAllByDomainObjectY internally searches by the domainObjectY's
id and returns the count of DomainObjectX associated with that specific
domainObjectY.
Now, in order to do this I would need to have domainObjectY as a property of
the DataProvider which I think it is not good because it would be
serialized.
Should I change the service to receive just the domainObjectY's id and only
"save" this id as a property of the DataProvider?
--
View this message in context:
http://apache-wicket.1842946.n4.nabble.com/DataProvider-calling-a-Service-Dao-that-requires-a-domain-object-tp3341572p3341572.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
Re: [VOTE] WICKET-3218 - Component#onInitialize is broken for Pages
Interesting problem.
It helped me visualize the issue when I tried to suggest:
myPage() {
add(new Thing(this,...)); // 'this' doesn't exist yet
}
I think building component hierarchy from constructors feels natural and
it's going to be a hard sell to change to support this use case where some
components might need to know their parents.
I thought I was keeping pretty much up-to-speed on 1.5 changes, but I'm kind
of surprised this is the first I'm noticing this fairly substantial API
change.
Sorry if something like this has already been shot down - I didn't look -
but just off the top of my head, seems like there could be a way to have the
framework (as it is about to add a page to it's map or at some other
convenient early point) go back down thru the hierarchy and visit all the
components to offer them a parent reference? Maybe guarantee it would
happen before the first onBeforeRender or something like that?
Then, we could let these visitors 'vote' on when the hierarchy is finished
changing - (i.e. components could use this information to make additional
changes to the hierarchy) by returning a value. Perhaps call this new
component visitor something like int onParentChanged(Component parent) -
return flags that would let the framework interrupt and restart, repeat
after finish, or just continue visiting (or maybe just return boolean repeat
flag).
-- Jim Pinkham
TogetherAuction.com
On Tue, Mar 8, 2011 at 8:33 AM, Zoltán Nagy wrote:
> Hi!
>
> My idea is this: Somewhere in the future (for example in wicket 1.6)
> adding copmonents from the constructor will be prohibited, but till
> than it should be allowed.
>
> --
> Zoltán Nagy
>
> -
> To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
> For additional commands, e-mail: users-h...@wicket.apache.org
>
>
Re: preferred php framework by wicketeers...
On Tue, Mar 8, 2011 at 1:21 PM, Antoine van Wel wrote: > Since "you can't always have what you want".. > > Is there any PHP framework out there which comes even close to Wicket; > component based, strict separation between HTML and programming, > stateful, out-of-the-box Ajax support, event handling, URL mapping, > excellent testing features, and great community support? > > > it would probably have turned up in your google search if it existed ;-) A prototype is easy to make though; you should get a lot of benefits already from adopting the wicket session mgmt, component & rendering model to php. In fact, I built something like this for fun some time ago. No ajax, url mapping, models, other fancy stuff. But event handling and markup/code separation is pretty easy to accomplish. You'ld probably want to use smarty for the rendering though. It doesn't make a lot of sense to parse html on each request and smarty probably has the best tooling for php templating. cheers, Frank > regards > Antoine > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Hippo Europe • Amsterdam Oosteinde 11 • 1017 WT Amsterdam • +31 (0)20 522 4466 USA • San Francisco 755 Baywood Drive, Second Floor • Petaluma, CA. 94954 • +1 877 414 4776 (toll free) Canada• Montréal 5369 Boulevard St-Laurent #430 • Montréal QC H2T 1S5 • +1 (514) 316 8966 www.onehippo.com • www.onehippo.org • i...@onehippo.com This e-mail may be privileged and/or confidential, and the sender does not waive any related rights and obligations. Any distribution, use or copying of this e-mail or the information it contains by other than an intended recipient is unauthorized. If you received this e-mail in error, please advise me (by return e-mail or otherwise) immediately.
Re: Page reloading notification
Hi! If you use ajax, you can register js functions into wicket ajax js framework to show and hide notification and mask off layer: Wicket.Ajax.registerPreCallHandler(showBusysign); Wicket.Ajax.registerPostCallHandler(hideBusysign); Wicket.Ajax.registerFailureHandler(hideBusysign); You can use it as per component by adding IAjaxIndicatorAware interface to your component. But I don't know if these were implemented in wicket 1.3. 2011/3/8 Milan Křápek : > Hi I have system based on wicket 1.3.2 (I know it is very old but it is still > working good for me). Sometimes when I submit just local changes on page and > operation with database take long time, It would be nice to show some > notification that the request is processing and disable the whole page for > next operations until the first finished. > > Is there any support for this in wicket? > > Thanks for any advice > > Milan > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- Zoltán Nagy - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: How to stop concurrent logins?
Sorry Igor, I think I'm missing something obvious here. Won't the GUID from the cookie and session always match as the cookie was generated from the equivalent session? -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/How-to-stop-concurrent-logins-tp3332127p3341407.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
Re: preferred php framework by wicketeers...
I don't think you are going to get all that from a PHP-based framework. I have used CakePHP, which is sorta Rails-like, for production projects. It's pretty nifty and has good community support. -- View this message in context: http://apache-wicket.1842946.n4.nabble.com/preferred-php-framework-by-wicketeers-tp3341212p3341401.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
Re: preferred php framework by wicketeers...
> Sadly reality is that PHP is more widely adopted. Apache comes almost > by default with PHP. So I was wondering, does anything come close to > Wicket, to ease the pain.. Or to have a stronger case for Wicket in > discussions. Do you know Zeta Components which entered the apache incubator for a while? http://incubator.apache.org/projects/zetacomponents.html They have some MVC stuff inside. Thsi is mostly used in PHP world (unfortunately) An other approach is piwi: http://code.google.com/a/apache-extras.org/p/piwi/ I am involved in this project, so this i my first choice. But you should know that it's in an early state. Helping hands welcome. Anything like Wicket in PHP world is unknown to me. I am not sure if it makes sense tough Cheers Christian > > So Scala is not an option either... it's on my wish-list to learn > though. I'm aware of the Scala/Wicket integration. > > > Antoine > > > 2011/3/8 Josh Kamau : >> I dont know of any. If you prefer scripting languages, there is a >> scala+wicket integration. Just google it if you are interested. >> >> Josh. >> > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > > -- http://www.grobmeier.de - 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
Hi! My idea is this: Somewhere in the future (for example in wicket 1.6) adding copmonents from the constructor will be prohibited, but till than it should be allowed. -- Zoltán Nagy - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: preferred php framework by wicketeers...
Now wait a moment, let me be very clear that I prefer Wicket .. I don't want misunderstandings about that ;-) Sadly reality is that PHP is more widely adopted. Apache comes almost by default with PHP. So I was wondering, does anything come close to Wicket, to ease the pain.. Or to have a stronger case for Wicket in discussions. So Scala is not an option either... it's on my wish-list to learn though. I'm aware of the Scala/Wicket integration. Antoine 2011/3/8 Josh Kamau : > I dont know of any. If you prefer scripting languages, there is a > scala+wicket integration. Just google it if you are interested. > > Josh. > - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: preferred php framework by wicketeers...
2011/3/8 Josh Kamau : > I dont know of any. If you prefer scripting languages, there is a > scala+wicket integration. Just google it if you are interested. I would not call scala a scripting language. It is a statically typed, compiled JVM language. It's a scripting language in the same sense Java is a scripting language. Martijn -- Become a Wicket expert, learn from the best: http://wicketinaction.com - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: preferred php framework by wicketeers...
I dont know of any. If you prefer scripting languages, there is a scala+wicket integration. Just google it if you are interested. Josh.
Re: Attribute Inheritance or Copying?
Hi,
I quickly wrote this, it seems to work.. But, does anyone know if is there a
better (wicket) way to do it ?
Regards,
Yves-Marie
class CopyAttributesBehavior extends AbstractBehavior {
private static final long serialVersionUID = 1L;
private IValueMap attributes;
@Override
public void onComponentTag(Component component, ComponentTag tag) {
if (attributes != null)
tag.getAttributes().putAll(attributes);
}
public IValueMap getAttributes() {
return attributes;
}
public void setAttributes(IValueMap attributes) {
this.attributes = attributes;
}
}
public class TestPanel extends Panel {
private CopyAttributesBehavior copyAttributesBehavior;
private Label label;
public TestPanel(String id, IModel model) {
super(id, model);
label = new Label("label", model);
label.add(copyAttributesBehavior = new CopyAttributesBehavior());
setRenderBodyOnly(true);
add(label);
}
@Override
protected void onComponentTag(ComponentTag tag) {
super.onComponentTag(tag);
copyAttributesBehavior.setAttributes(tag.getAttributes());
}
}
2011/3/3 Hans Lesmeister 2
>
>
> > I've to access the ComponentTag of my Panel but dont know how, except
> > iam in "onComponentTag".
> >
>
> Yes, in onComponentTag of the surrounding WebmarkupContainer, you can get
> and preserve the desired attributes and then remove them.
>
> In onComponentTag of the TextArea you add the previously preserved
> attributes.
>
>
> -
> --
> Regards,
> Hans
>
> http://cantaa.de
>
> --
> View this message in context:
> http://apache-wicket.1842946.n4.nabble.com/Attribute-Inheritance-or-Copying-tp3332828p014.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
>
>
--
Yves-Marie LAINÉ
Re: preferred php framework by wicketeers...
+1 for Symfony, probably as good as you can get for PHP. But no, it won't work like wicket. Afaik there are no stateful PHP frameworks out there (but I could be wrong). /Robert On 03/08/2011 01:30 PM, Martin Makundi wrote: Sorry..not close but far...maybe I meant keep enemies closer ;) ** Martin 2011/3/8 Martin Makundi: Hmm.. I would personally stay as close as possible from non statically typed languages ;) Ofcourse it depends on what you are making, if it is worth making and so forth ;) ** Martin 2011/3/8 Antoine van Wel: Since "you can't always have what you want".. Is there any PHP framework out there which comes even close to Wicket; component based, strict separation between HTML and programming, stateful, out-of-the-box Ajax support, event handling, URL mapping, excellent testing features, and great community support? regards Antoine - 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: preferred php framework by wicketeers...
Sorry..not close but far...maybe I meant keep enemies closer ;) ** Martin 2011/3/8 Martin Makundi : > Hmm.. I would personally stay as close as possible from non statically > typed languages ;) > > Ofcourse it depends on what you are making, if it is worth making and > so forth ;) > > ** > Martin > > 2011/3/8 Antoine van Wel : >> Since "you can't always have what you want".. >> >> Is there any PHP framework out there which comes even close to Wicket; >> component based, strict separation between HTML and programming, >> stateful, out-of-the-box Ajax support, event handling, URL mapping, >> excellent testing features, and great community support? >> >> >> regards >> Antoine >> >> - >> 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: preferred php framework by wicketeers...
Hmm.. I would personally stay as close as possible from non statically typed languages ;) Ofcourse it depends on what you are making, if it is worth making and so forth ;) ** Martin 2011/3/8 Antoine van Wel : > Since "you can't always have what you want".. > > Is there any PHP framework out there which comes even close to Wicket; > component based, strict separation between HTML and programming, > stateful, out-of-the-box Ajax support, event handling, URL mapping, > excellent testing features, and great community support? > > > regards > Antoine > > - > 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
preferred php framework by wicketeers...
Since "you can't always have what you want".. Is there any PHP framework out there which comes even close to Wicket; component based, strict separation between HTML and programming, stateful, out-of-the-box Ajax support, event handling, URL mapping, excellent testing features, and great community support? regards Antoine - 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
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
[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 IModel name = Model.of();
public MyPanel(String id) {
add(new TextField("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 TextField("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 intuitive.
Addit
shift / ctrl / alt keys + ajax
Hi, when clicking an (ajax)link, or a checkbox, etc, on the server side I'd like to know whether the shift, ctrl or alt keys are pressed at the same time. So I figure I need to fetch via JavaScript and adapt the ajax call with some extra parameters. Any thoughts how to do that in a nice & clean way in 1.5 without too much hacking involved? regards, Antoine - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: visural-wicket running on wicket 1.5?
Hi Nino, The version in the public respository 1.5 branch is still a direct copy of 1.4 - sorry I haven't commited the WIP 1.5 changes yet. I'll aim to get the WIP committed in this week. cheers, Richard. On Mon, Mar 7, 2011 at 6:47 PM, nino martinez wael < nino.martinez.w...@gmail.com> wrote: > Strange it compiles well, but does not work as wanted.. Any idea on which > parts are causing the problems? On my dropdowns the dropdowns are empty, > and in my textfields both the text and the span are added if in view mode, > and if not 2 textfields are added. > > 2011/3/5 Richard Nichols > > > I've created a 1.5 branch and it's in the works. 1.5 broke more stuff > > than expected :) > > > > Hopefully I can have a beta 1.5 branch functional within a few weeks > > > > Sent from my iPhone > > > > On 05/03/2011, at 6:15 AM, nino martinez wael > > wrote: > > > > > So does has anybody run it on wicket 1.5, or is there something in the > > works > > > for it? > > > > > > regards Nino > > > > - > > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > > For additional commands, e-mail: users-h...@wicket.apache.org > > > > > -- Richard Nichols http://www.richardnichols.net/ :: http://onmydoorstep.com.au/
Page reloading notification
Hi I have system based on wicket 1.3.2 (I know it is very old but it is still working good for me). Sometimes when I submit just local changes on page and operation with database take long time, It would be nice to show some notification that the request is processing and disable the whole page for next operations until the first finished. Is there any support for this in wicket? Thanks for any advice Milan - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Run a standalone wicket app
you could also take a look at winstone: http://winstone.sourceforge.net/ 2011/3/7 Mauro Ciancio > Hello all, > I'd like to create a jar with a wicket application inside that can be > run from the command line as it were a desktop application. I'm using > maven and jetty and it would be great if jetty could start and listen > on a port. > > Any hints or links would be really appreciated. > > Thanks in advance. > Regards. > -- > Mauro Ciancio > http://about.me/maurociancio > > - > To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org > For additional commands, e-mail: users-h...@wicket.apache.org > >
