Re: Preserving user input after form error
http://wicket.apache.org/quickstart.html
On 11/3/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> Is there a page with guidelines on making a wicket quickstart?
>
> > why dont you submit a quickstart and then we can figure out why its
> > happening
> >
> > -igor
> >
> >
> > On 11/2/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> > > Could it be because the form page is bookmarkable?
> > >
> > > > thats odd, all the values should be preserved, thats our rawinput
> that
> > > > all formcomponents have. Do you have a repeater/listview around
> your
> > > > formcomponents.
> > > >
> > > > On 11/1/07, Chris Colman <[EMAIL PROTECTED]> wrote:
> > > > > I've created a form and set up some validators on various
> fields.
> > > When
> > > > > there is an error and the page is redisplayed showing the errors
> > > none of
> > > > > the previous values that the user typed in are there.
> > > > >
> > > > > Is there an easy way to preserve the values already entered by
> the
> > > user?
> > > > >
> > > > > I tried overriding onError but it didn't seem to do get it
> working:
> > > > >
> > > > > public final void onError()
> > > > > {
> > > > > // update model fields so the user doesn't have to type them
> in
> > > > > again
> > > > > // -> I was hoping that the next page render would get these
> > > > > //values from the updated model
> > > > > updateFormComponentModels();
> > > > > }
> > > > >
> > >
> > >
> -
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: [EMAIL PROTECTED]
> > >
> > >
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
--
Buy Wicket in Action: http://manning.com/dashorst
Apache Wicket 1.3.0-beta4 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0-beta4/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is Beta5 coming soon? Beta4 has caused these issues for us....
are you really sure that you dont have also an older version somewhere in the classpath? you can try to start java with -verbose:gc On 11/2/07, landry soules <[EMAIL PROTECTED]> wrote: > Actually, i didn't go on with maven, since my project is already quite > advanced now, i don't want to reconfigure it to use maven. I just tried to > create a sample project to figure out what is the correct combination of > slf4j/log4j to use (bad idea, since it appears to be broken in the original > wicket pom). > So i'm back in my real eclipse project, and this neverending error : > > Exception in thread "ModificationWatcher Task" java.lang.NoSuchMethodError: > org.slf4j.Logger.isTraceEnabled()Z > at org.apache.wicket.util.thread.Task$1.run(Task.java:103) > at java.lang.Thread.run(Thread.java:595) > > even though i'm using slf4j-log4j12-1.4.2.jar + log4j-1.2.14.jar. > > > > 2007/11/2, Gwyn Evans <[EMAIL PROTECTED]>: > > > > Hi landry, > > > > Did you modify the SLF version specified in the created pom.xml before > > trying to import it? > > > > /Gwyn > > > > Friday, November 2, 2007, 8:36:37 PM, landry soules < > > [EMAIL PROTECTED]> wrote: > > > > ls> Thanks for your answers, but still no success : > > ls> I tried (once again) to use maven to generate a brand new project, but > > ls> eclipse freezes when i import the project generated with "mvn > > ls> eclipse:eclipse -DdownloadSources=true"... > > > > ls> Is there something i'm missing ? In my classpath, i have > > ls> slf4j-log4j12-1.4.2.jar + log4j-1.2.14.jar, and still the infamous > > ls> "NoSuchMethodError" > > > > ls> Should i better rollback to wicket 1.3 beta2 ? > > > > > > ls> 2007/11/2, Gerolf Seitz <[EMAIL PROTECTED]>: > > >> > > >> you have to use slf4j version 1.4.2 (instead of 1.0.x) in your pom file > > >> > > >> Gerolf > > >> > > >> On Nov 2, 2007 8:11 PM, landry soules <[EMAIL PROTECTED]> > > wrote: > > >> > > >> > Hello > > >> > > > >> > Please Al, what is the fix for this problem with slf4j ? > > >> > I spent half a day trying every possible combination between log4j > > and > > >> > slf4j, and got nothing but a strong headache ( and > > "NoSuchMethodError") > > >> > !!! > > >> > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is Beta5 coming soon? Beta4 has caused these issues for us....
And what is the version of your slfj-api.jar? Erik. landry soules wrote: Thanks for your answers, but still no success : I tried (once again) to use maven to generate a brand new project, but eclipse freezes when i import the project generated with "mvn eclipse:eclipse -DdownloadSources=true"... Is there something i'm missing ? In my classpath, i have slf4j-log4j12-1.4.2.jar + log4j-1.2.14.jar, and still the infamous "NoSuchMethodError" Should i better rollback to wicket 1.3 beta2 ? -- Erik van Oosten http://2008.rubyenrails.nl/ http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
empty wicket:message
Hi, I was wondering if it is possible to configure wicket to make wicket:message output the key in braces when the key is not found (at least in development mode), because that would make it a lot easier to spot missing labels... That is, what I'd like to do is: And have wicket output "[bla]" if the key bla cannot be found. I know I could do this: [bla] but this is a lot more verbose and it requires me to correctly type the key name twice every time. Currently if the resource is not found it just outputs nothing at all (which is hard to spot). Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
RE: Wicket jBPM
When you download jBPM (http://www.jboss.com/products/jbpm/downloads) the deploy directory contains the "jBPM Web Console Application" (http://docs.jboss.com/jbpm/v3/userguide/introduction.html#d0e100) that... "The jBPM console web application serves two purposes. First, it serves as a central user interface for interacting with runtime tasks generated by the process executions. Secondly, it is an administration and monitoring console that allows to inspect and manipulate runtime instances. The third functionality is Business Activity Monitoring. These are statistics about process executions. This is useful information for managers to find bottlenecks or other kinds of optimisations." I was wondering if anyone has started a Wicket project (instead of the JSF endorsed one). I would hate to recreate the wheel if someone has already started a similar project. I don't know if it would be possible to have this as a contributed project under both Wicket and Red Hat licenses, but it would defiantly be a useful integration tool either way. Also, the RHDS Eclipse plug-in is a very robust tool that is able to generate not only the graphs, process definitions, etc. but is also capable of generating the corresponding JSF pages. There is a flash demo (http://docs.jboss.com/jbpm/v3/demos/movies/jbpm-overview.htm) that gives a simple demonstration of the plug-in, but it doesn't really show the full functionality of the tool- including JSF code generation (you can download the Eclipse plug-in to see how the JSF code generation works through the Eclipse auto update site: http://downloads.jboss.org/jbosside/updates/development). I would be interested in contributing a Wicket code generation module for this plug-in (if licenses allow). -Original Message- From: Eelco Hillenius [mailto:[EMAIL PROTECTED] Sent: Saturday, November 03, 2007 3:28 AM To: users@wicket.apache.org Subject: Re: Wicket jBPM On 11/2/07, William Hoover <[EMAIL PROTECTED]> wrote: > I guess what I'm really asking is if anyone actually composed the UI > integration piece that supports the API (similar to the JBoss jBPM webapp) so > that all of the controller variables could be seamlessly linked to models. I don't know whether someone did exactly that. Is there a public demo of that web app? Or can you expand a bit on what it does? Since it is super easy to create self-contained components with Wicket (see for instance Gerolf's JMX panel[1]), the sky is probably the limit when it comes to creating jBPM integration. From what I remember working with it about 2.5 years ago is that jBPM has a nice straightforward Java API, so the two should go together well. If you have more concrete ideas, you could consider starting a wicket-stuff project for it, and see whether other's hop on board (I for one might be interested in that, though I won't actually have time for that the next few months). Eelco [1] http://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicketstuff-jmx-panel - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Wicket jBPM
> I was wondering if anyone has started a Wicket project (instead of the JSF > endorsed one). I would hate to recreate the wheel if someone has already > started a similar project. Come on! Recreating the wheel is what us software engineers do best! Imagine how boring the wheel would be if we hadn't already recreated it 500 times. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is Beta5 coming soon? Beta4 has caused these issues for us....
This is what i use : log4j-1.2.15.jar slf4j-api-1.4.3.jar slf4j-log4j12-1.4.3.jar with wicket 1.3.0beta4. I got the same annoying exception before upgrading to those log4j/slf4 versions. On Nov 3, 2007 1:24 PM, Erik van Oosten <[EMAIL PROTECTED]> wrote: > > And what is the version of your slfj-api.jar? > > Erik. > > > landry soules wrote: > > Thanks for your answers, but still no success : > > I tried (once again) to use maven to generate a brand new project, but > > eclipse freezes when i import the project generated with "mvn > > eclipse:eclipse -DdownloadSources=true"... > > > > Is there something i'm missing ? In my classpath, i have > > slf4j-log4j12-1.4.2.jar + log4j-1.2.14.jar, and still the infamous > > "NoSuchMethodError" > > > > Should i better rollback to wicket 1.3 beta2 ? > > > > > > > > > > -- > Erik van Oosten > http://2008.rubyenrails.nl/ > http://day-to-day-stuff.blogspot.com/ > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty wicket:message
im afraid we cannot do that. because the contract is that when a resource is not found we output the body, which is supposed to be the default text. to do what you want we need to change that contract. i am not opposed to that per se, but there needs to be a discussion followed by a vote. -igor On 11/3/07, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: > Hi, > > I was wondering if it is possible to configure wicket to make > wicket:message output the key in braces when the key is not found (at > least in development mode), because that would make it a lot easier to > spot missing labels... > > That is, what I'd like to do is: > > > > And have wicket output "[bla]" if the key bla cannot be found. I know I > could do this: > > [bla] > > but this is a lot more verbose and it requires me to correctly type the > key name twice every time. Currently if the resource is not found it > just outputs nothing at all (which is hard to spot). > > Regards, > Sebastiaan > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Jira issue moved to the list: constructors and init of components
Moving to the list as suggested by Gwyn. >From Jira issue: https://issues.apache.org/jira/browse/WICKET-1108 Maybe I wasn't clear on what my problem with it was. 1) doing any extensive amount of work in a constructor is an anti-pattern AFAIK. 2) If the API is designed so that I am expected to build a complex component in it's constructor then I should be able to override any of the constructors and expect it to be called. If you don't want to include a specialized method for initializing a component (e.g. the way Servlet works) and expect the constructor to be the "primary" means of building up the component, then the constructors should follow good practice and all get called. This is a common Java pattern. There should be only one place in the code where properties are set from a constructor, all other constructors should pass on their parameters, defaults if required, to the one constructor that actually sets the properties. If you don't code well, you have three immediate problems which as an agile fan, I would cringe at: 1) You have duplicate code, no way around it. 2) you can never be certain which constructor is called by the API and any given point. You may be able to get it to work, but a future change to the API could break your code, and you might well not catch it with your own unit test (you have some right?). 3) in order to support having two overridden constructors, I now am *forced* to duplicate my own code (granted it could be one line, but its still duplication). Now... fixing the constructor calls is not impossible but may require a bit of thought (I don't believe thinking is a problem for the developers of Wicket as they have clearly done a lot of it already) however I personally would prefer a specific method call for initializing the component... at the very least so I don't have to do all that work in the constructor, but it also has the benefit of being *very* easy to implement with the current codebase. Despite my preference for an init override, I think the correct thing to do with or without it is to fix the constructor calls. - Brill Pappin
Re: Jira issue moved to the list: constructors and init of components
Ever heard of constructor chaining? -Matej On 11/3/07, Brill Pappin <[EMAIL PROTECTED]> wrote: > Moving to the list as suggested by Gwyn. > > From Jira issue: > https://issues.apache.org/jira/browse/WICKET-1108 > > Maybe I wasn't clear on what my problem with it was. > > 1) doing any extensive amount of work in a constructor is an anti-pattern > AFAIK. > 2) If the API is designed so that I am expected to build a complex component > in it's constructor then I should be able to override any of the > constructors and expect it to be called. > > If you don't want to include a specialized method for initializing a > component (e.g. the way Servlet works) and expect the constructor to be the > "primary" means of building up the component, then the constructors should > follow good practice and all get called. > > This is a common Java pattern. There should be only one place in the code > where properties are set from a constructor, all other constructors should > pass on their parameters, defaults if required, to the one constructor that > actually sets the properties. > > If you don't code well, you have three immediate problems which as an agile > fan, I would cringe at: > 1) You have duplicate code, no way around it. > 2) you can never be certain which constructor is called by the API and any > given point. You may be able to get it to work, but a future change to the > API could break your code, and you might well not catch it with your own > unit test (you have some right?). > 3) in order to support having two overridden constructors, I now am *forced* > to duplicate my own code (granted it could be one line, but its still > duplication). > > Now... fixing the constructor calls is not impossible but may require a bit > of thought (I don't believe thinking is a problem for the developers of > Wicket as they have clearly done a lot of it already) however I personally > would prefer a specific method call for initializing the component... at the > very least so I don't have to do all that work in the constructor, but it > also has the benefit of being *very* easy to implement with the current > codebase. > > Despite my preference for an init override, I think the correct thing to do > with or without it is to fix the constructor calls. > > > > - Brill Pappin > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is Beta5 coming soon? Beta4 has caused these issues for us....
landry soules wrote: Actually, i didn't go on with maven, since my project is already quite advanced now, i don't want to reconfigure it to use maven. I just tried to create a sample project to figure out what is the correct combination of slf4j/log4j to use (bad idea, since it appears to be broken in the original wicket pom). So i'm back in my real eclipse project, and this neverending error : Exception in thread "ModificationWatcher Task" java.lang.NoSuchMethodError: org.slf4j.Logger.isTraceEnabled()Z at org.apache.wicket.util.thread.Task$1.run(Task.java:103) at java.lang.Thread.run(Thread.java:595) even though i'm using slf4j-log4j12-1.4.2.jar + log4j-1.2.14.jar. You also need slf4j-api-1.4.2.jar. I'd lay money on your not having that version on your classpath (or having an earlier version as well). Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: difference between Link(SomePage.class) and Link(new SomePage())
auron wrote: Sorry to be the wicket newbie, but I was wondering if you guys could help me to understand how Links work. I understand that when you do Link(SomePage.class), it calls the zero param constructor of SomePage, and when you do Link(new SomePage(someParams)) you can call other constructors, but besides this, what are the other differences? I assume you're talking about PageLink not Link? new PageLink(id, SomePage.class) will generate a URL which will construct a new page when you click on it. new PageLink(id, new SomePage()) obviously creates a SomePage instance right then and there. The page instance is stored in the session and dug out if the user clicks on the link. You should obviously try to create links which create new pages when you click on them, not when you construct the link (i.e. the former). For this reason, in Wicket 1.3 we've deprecated the second form as this seemed to confuse people. Instead, use a normal Link and call setResponsePage() in the onClick(). At least, then it'll be obvious what you're doing and encourage people to only construct their new pages within a click handler, rather than within the constructor for the original page. Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty wicket:message
Sebastiaan van Erk wrote: I was wondering if it is possible to configure wicket to make wicket:message output the key in braces when the key is not found (at least in development mode), because that would make it a lot easier to spot missing labels... That is, what I'd like to do is: And have wicket output "[bla]" if the key bla cannot be found. I know I could do this: [bla] but this is a lot more verbose and it requires me to correctly type the key name twice every time. Currently if the resource is not found it just outputs nothing at all (which is hard to spot). Mmmm. I must say I agree with this. I'd actually prefer it to throw an exception. ;-) Maybe we should add this as a feature? getMarkupSettings().setThrowExceptionOnEmptyMessageTagKeyMissing(true) or something equally descriptive. ;-) Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira issue moved to the list: constructors and init of components
Brill Pappin wrote:
Moving to the list as suggested by Gwyn.
From Jira issue:
https://issues.apache.org/jira/browse/WICKET-1108
Maybe I wasn't clear on what my problem with it was.
1) doing any extensive amount of work in a constructor is an anti-pattern
AFAIK.
Blindly declaring things anti-patterns with no real rationale is dangerous.
Constructors are designed to ensure that your object is completely
initialised and ready for use. If your page doesn't have all its
components added, then it's not initialised and ready for use.
Therefore, I think putting all that logic in there is a perfectly valid
place for it.
There's nothing to stop you making your constructor call methods to
initialise things that people can then override. Generally you won't
want to make/let people completely override everything, so you need to
put some thought into this. If you do want this, then just use a blank
super constructor and you're done (you can then sit back and watch your
users hate you).
2) If the API is designed so that I am expected to build a complex component
in it's constructor then I should be able to override any of the
constructors and expect it to be called.
But, err, you can't override constructors. So if you're writing the API,
call overridable methods from your constructor. I don't understand what
you're doing discussing this on the Wicket user list - this is just
basic Java.
If you don't want to include a specialized method for initializing a
component (e.g. the way Servlet works) and expect the constructor to be the
"primary" means of building up the component, then the constructors should
follow good practice and all get called.
Errr, what? We don't get a choice here - this is all governed by the
language itself. I think you might be confused about how constructor
chaining works. Either that, or you're completely failing to make
yourself understood properly.
This is a common Java pattern. There should be only one place in the code
where properties are set from a constructor, all other constructors should
pass on their parameters, defaults if required, to the one constructor that
actually sets the properties.
This is nonsense. You write code to achieve what you want it to in the
most concise and simple way possible.
If that means a single constructor which actually does stuff with a
bunch of other constructors that delegate to it with default arguments,
then fine.
If it means you have a commonInit() method that all your constructors
call, then fine.
If that means you have a bunch of constructors that do different things,
then fine.
If you don't code well, you have three immediate problems which as an agile
fan, I would cringe at:
1) You have duplicate code, no way around it.
2) you can never be certain which constructor is called by the API and any
given point. You may be able to get it to work, but a future change to the
API could break your code, and you might well not catch it with your own
unit test (you have some right?).
Again; errr, what? No offense, but if you can't work out which
constructor is being called for a given bit of code, you probably
shouldn't be writing Java for a living.
Future API changes can always break your code. I don't see how that's
relevant specifically to constructors as opposed to anything else. If
someone changes the API and your unit test doesn't pick it up, your unit
tests are very obviously broken. Changing constructors is really no
different to changing other method signatures, with the possible
exception that you're slightly more likely to be doing reflection on
constructors than methods (although with the prevalence of Hibernate's
HQL and Wicket's PropertyModels even that is arguable).
3) in order to support having two overridden constructors, I now am *forced*
to duplicate my own code (granted it could be one line, but its still
duplication).
Errr, why?
Now... fixing the constructor calls is not impossible but may require a bit
of thought (I don't believe thinking is a problem for the developers of
Wicket as they have clearly done a lot of it already) however I personally
would prefer a specific method call for initializing the component... at the
very least so I don't have to do all that work in the constructor, but it
also has the benefit of being *very* easy to implement with the current
codebase.
Despite my preference for an init override, I think the correct thing to do
with or without it is to fix the constructor calls.
Fix them how? I still don't even remotely understand why you think
they're broken. I'm not being deliberately obtuse, defensive or
belligerent. I've read the original bug report. I just genuinely don't
understand where you're coming from.
What is to stop you going:
public BasePage() {
commonInit();
}
public BasePage(IModel model) {
super(model);
commonInit();
}
private void commonInit() {
add(new Label("myid1", "foo"));
}
?
Regard
Re: Wicket jBPM
> Come on! Recreating the wheel is what us software engineers do best! > Imagine how boring the wheel would be if we hadn't already recreated it > 500 times. That wheel would then also be rectangular ;-) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty wicket:message
+1 Al Maw wrote: Mmmm. I must say I agree with this. I'd actually prefer it to throw an exception. ;-) Maybe we should add this as a feature? getMarkupSettings().setThrowExceptionOnEmptyMessageTagKeyMissing(true) or something equally descriptive. ;-) -- Erik van Oosten http://2008.rubyenrails.nl/ http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket jBPM
On 11/3/07, William Hoover <[EMAIL PROTECTED]> wrote: > When you download jBPM (http://www.jboss.com/products/jbpm/downloads) the > deploy directory contains the "jBPM Web Console Application" > (http://docs.jboss.com/jbpm/v3/userguide/introduction.html#d0e100) that... > > "The jBPM console web application serves two purposes. First, it serves as a > central user interface for interacting with runtime tasks generated by the > process executions. Secondly, it is an administration and monitoring console > that allows to inspect and manipulate runtime instances. The third > functionality is Business Activity Monitoring. These are statistics about > process executions. This is useful information for managers to find > bottlenecks or other kinds of optimisations." So you would build a new one so that you can extend/ customize/ integrate in your own application, right? > I was wondering if anyone has started a Wicket project (instead of the JSF > endorsed one). I would hate to recreate the wheel if someone has already > started a similar project. I don't know if it would be possible to have this > as a contributed project under both Wicket and Red Hat licenses, but it would > defiantly be a useful integration tool either way. The license might be a problem for Wicket core projects, but it can have a place in the wicket-stuff repo. > Also, the RHDS Eclipse plug-in is a very robust tool that is able to generate > not only the graphs, process definitions, etc. but is also capable of > generating the corresponding JSF pages. There is a flash demo > (http://docs.jboss.com/jbpm/v3/demos/movies/jbpm-overview.htm) that gives a > simple demonstration of the plug-in, but it doesn't really show the full > functionality of the tool- including JSF code generation (you can download > the Eclipse plug-in to see how the JSF code generation works through the > Eclipse auto update site: > http://downloads.jboss.org/jbosside/updates/development). I would be > interested in contributing a Wicket code generation module for this plug-in > (if licenses allow). Would definitively be nice to have such a project for Wicket. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty wicket:message
Thanks for the reply, I was afraid I was going to get this answer. :-) I can understand it though. Igor Vaynberg wrote: im afraid we cannot do that. because the contract is that when a resource is not found we output the body, which is supposed to be the default text. Am I pushing my luck if I interpret this as: if the resource is not found, replace it by the body *if there is one*. :-))) Practically speaking if I don't supply a body I'd like to be informed (at least in development mode) if the resource is not found... If I really intend an empty string to be shown I can always define it to be empty in the properties file. Just my two cents... :-) Regards, Sebastiaan to do what you want we need to change that contract. i am not opposed to that per se, but there needs to be a discussion followed by a vote. -igor On 11/3/07, Sebastiaan van Erk <[EMAIL PROTECTED]> wrote: Hi, I was wondering if it is possible to configure wicket to make wicket:message output the key in braces when the key is not found (at least in development mode), because that would make it a lot easier to spot missing labels... That is, what I'd like to do is: And have wicket output "[bla]" if the key bla cannot be found. I know I could do this: [bla] but this is a lot more verbose and it requires me to correctly type the key name twice every time. Currently if the resource is not found it just outputs nothing at all (which is hard to spot). Regards, Sebastiaan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
Re: empty wicket:message
Al Maw wrote: Sebastiaan van Erk wrote: I was wondering if it is possible to configure wicket to make wicket:message output the key in braces when the key is not found (at least in development mode), because that would make it a lot easier to spot missing labels... That is, what I'd like to do is: And have wicket output "[bla]" if the key bla cannot be found. I know I could do this: [bla] but this is a lot more verbose and it requires me to correctly type the key name twice every time. Currently if the resource is not found it just outputs nothing at all (which is hard to spot). Mmmm. I must say I agree with this. I'd actually prefer it to throw an exception. ;-) Maybe we should add this as a feature? getMarkupSettings().setThrowExceptionOnEmptyMessageTagKeyMissing(true) or something equally descriptive. ;-) Regards, Al I really like this. :-) Exception is even better! :-) Regards, Sebastiaan smime.p7s Description: S/MIME Cryptographic Signature
Re: empty wicket:message
> Mmmm. I must say I agree with this. I'd actually prefer it to throw an > exception. ;-) I'm surprised we don't do this already! I would have expected that if IResourceSettings#getThrowExceptionOnMissingResource returns true, an exception would be thrown here as well. I think we should fix it. > Maybe we should add this as a feature? > getMarkupSettings().setThrowExceptionOnEmptyMessageTagKeyMissing(true) > or something equally descriptive. ;-) If we have the exception that outputs the missing key, that should be enough imho. I'm not against adding this, but I don't we we need it once we implement throwing that exception. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty wicket:message
then you are violating the contract of wicket:message. if we do this then there is little point to allowing body inside wicket:message -igor On 11/3/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > > Mmmm. I must say I agree with this. I'd actually prefer it to throw an > > exception. ;-) > > I'm surprised we don't do this already! > > I would have expected that if > IResourceSettings#getThrowExceptionOnMissingResource returns true, an > exception would be thrown here as well. I think we should fix it. > > > Maybe we should add this as a feature? > > getMarkupSettings().setThrowExceptionOnEmptyMessageTagKeyMissing(true) > > or something equally descriptive. ;-) > > If we have the exception that outputs the missing key, that should be > enough imho. I'm not against adding this, but I don't we we need it > once we implement throwing that exception. > > Eelco > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira issue moved to the list: constructors and init of components
On 11/3/07, Al Maw <[EMAIL PROTECTED]> wrote: > There's nothing to stop you making your constructor call methods to > initialise things that people can then override. erm. really? while there is nothing stopping you, you clearly shouldnt... -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: One Page Load Producing Three GETs
On Saturday 03 November 2007 01:27:53 Devin Venable wrote: > I've been trying to figure out why when I hit my wicket page, it loads > three times. I discovered this while debugging...my constructor was > called three times for my derived WebPage. > > I've captured the call stack produced by the three calls. (See below) > In my web browser I'm merely pasting the URL and pressing enter once. > It seems I'm getting three HTTP GETs. Stranger still, this seems to > be Firefox specific. IE or WGET only create on GET. I've seen similar thing. Most likely that is firefox requesting the page several times because you spend some time on breakpoints. Dima - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira issue moved to the list: constructors and init of components
On Saturday 03 November 2007 21:18:17 Brill Pappin wrote: > This is a common Java pattern. There should be only one place in the code > where properties are set from a constructor, all other constructors should > pass on their parameters, defaults if required, to the one constructor that > actually sets the properties. IMHO it does make sense. When I see several different super(...) calls in constructors the first thing that crosses my mind is that these superclass constructors have different logic. But it's not true for wicket and in most Component subclasses I can call super(id, (IModel)null). Can I? Dima - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira issue moved to the list: constructors and init of components
> IMHO it does make sense. When I see several different super(...) calls in > constructors the first thing that crosses my mind is that these superclass > constructors have different logic. But it's not true for wicket and in most > Component subclasses I can call super(id, (IModel)null). Can I? Yep, you could. Though some constructors in other classes (in or outside Wicket) might expect not-null arguments passed in in constructors. It just depends on who implemented it. There is no golden pattern that everyone follows; if there was, it should probably be enforced in the language. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty wicket:message
On 11/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > then you are violating the contract of wicket:message. if we do this > then there is little point to allowing body inside wicket:message Erm, where is that contract defined? The body is for previewing. I don't think I ever thought about this as a default, nor do I think we should, since that is inconsistent with what we do elsewhere. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty wicket:message
Btw, I would mind a decision about this in this weekend, as I'm finishing the chapter on localization right now :-) FWIW, I don't like the silent failure we have now, and believe that using the body as a default isn't very helpful; e.g. if you have the default body the same as what you intended to put in the properties file for the default locale (which is something that I often do, and I can imagine other people doing that as well), and you make a spelling error in the key (of either the tag or in the properties file), you'd never notice Wicket not finding the property. Either outputting the key as the body or throwing an exception is way better imho. However, I wouldn't vote against people wanting to stick with the current pattern as it is quite late in the game to change this. Eelco On 11/3/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: > On 11/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: > > then you are violating the contract of wicket:message. if we do this > > then there is little point to allowing body inside wicket:message > > Erm, where is that contract defined? The body is for previewing. I > don't think I ever thought about this as a default, nor do I think we > should, since that is inconsistent with what we do elsewhere. > > Eelco > - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira issue moved to the list: constructors and init of components
On Sunday 04 November 2007 01:23:39 Eelco Hillenius wrote: > > IMHO it does make sense. When I see several different super(...) calls in > > constructors the first thing that crosses my mind is that these > > superclass constructors have different logic. But it's not true for > > wicket and in most Component subclasses I can call super(id, > > (IModel)null). Can I? Sorry for commenting myself. The point was that using only one call to super(...) can make code more explicit. For instance to make sure that all WebPage constructors do afterall "the same" thing you have to go through hierarchy to Component. I guess that's what the original post was about. > Yep, you could. Though some constructors in other classes (in or > outside Wicket) might expect not-null arguments passed in in > constructors. It just depends on who implemented it. There is no > golden pattern that everyone follows; if there was, it should probably > be enforced in the language. Thanks. I agree there is no golden pattern, but to have in jdk something like @Nullable and @NotNull would be nice :) Dima - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira issue moved to the list: constructors and init of components
On 11/3/07, Dmitry Kandalov <[EMAIL PROTECTED]> wrote:
> On Sunday 04 November 2007 01:23:39 Eelco Hillenius wrote:
> > > IMHO it does make sense. When I see several different super(...) calls
> in
> > > constructors the first thing that crosses my mind is that these
> > > superclass constructors have different logic. But it's not true for
> > > wicket and in most Component subclasses I can call super(id,
> > > (IModel)null). Can I?
>
> Sorry for commenting myself. The point was that using only one call to
> super(...) can make code more explicit. For instance to make sure that all
> WebPage constructors do afterall "the same" thing you have to go through
> hierarchy to Component. I guess that's what the original post was about.
You just should call super of the same constructor you are in.
just give the super call everything you got. If you got a model, give it
but you don;t have to you can set it in the constructor with setModel
afterwards.
I still don't get what this discussion is more about
Things like this
public Constructor()
{
init()
}
private void init()
{
}
is still constructing in the constructor. Only handy if you have more then 1
constructor.
If you really want to have an init phase thats called after the constructor
is called (and finished)
then i think you should choose a different web framework, That uses managed
components/pages
johan
Re: empty wicket:message
Eelco Hillenius wrote: Btw, I would mind a decision about this in this weekend, as I'm finishing the chapter on localization right now :-) FWIW, I don't like the silent failure we have now, and believe that using the body as a default isn't very helpful; e.g. if you have the default body the same as what you intended to put in the properties file for the default locale (which is something that I often do, and I can imagine other people doing that as well), and you make a spelling error in the key (of either the tag or in the properties file), you'd never notice Wicket not finding the property. Either outputting the key as the body or throwing an exception is way better imho. However, I wouldn't vote against people wanting to stick with the current pattern as it is quite late in the game to change this. Eelco This is precisely the issue I was having, and the reason I was putting "[key]" in there, so I could actually see that it was getting the value from my properties file and not just the "preview" default, which happened to be the same (of course this kinda ruins the preview a bit). Thinking about it a bit more I agree with Eelco that I would like the exception thrown even if there is a default filled in (i.e., the message body is not empty) and the key is not defined, because it would kill previewability if you're forced to put empty wicket messages to get this behavior. I realize it's quite "late in the game" as Eelco puts it, but couldn't this just be a setting which you can turn on (and defaults to off), like Al Maw suggested? Or even defaults to on and in the migration notes it could say to get the old behavior you have to turn it off (being hopeful here ;-)) I really hate unresolved i18n messages, and with the silent failure it's just a pain to find them all. Regards, Sebastiaan On 11/3/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote: On 11/3/07, Igor Vaynberg <[EMAIL PROTECTED]> wrote: then you are violating the contract of wicket:message. if we do this then there is little point to allowing body inside wicket:message Erm, where is that contract defined? The body is for previewing. I don't think I ever thought about this as a default, nor do I think we should, since that is inconsistent with what we do elsewhere. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] smime.p7s Description: S/MIME Cryptographic Signature
WebWork and Wicket in the same application - session sharing?
Hi, I have a large application written in WebWork, Spring and iBATIS. After having started working with Wicket it really pains me that I have to continue developing with WebWork, so I want to start migrating this application on a page-by-page basis :) I'm thinking I'd add a filter for wicket with a "/w" filter-mapping, and migrate one page after another. The WebWork session holds information about currently logged in user, currently selected customer etc, and I need a way to sync this with a Wicket session. I could ofcourse add this information to the url everytime I hit a Wicket-page, but that seems really messy. Any suggestions? Sincerely, Edvin Syse - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebWork and Wicket in the same application - session sharing?
> I have a large application written in WebWork, Spring and iBATIS. After
> having started working with Wicket it really pains me that I have to
> continue developing with WebWork, so I want to start migrating this
> application on a page-by-page basis :)
>
> I'm thinking I'd add a filter for wicket with a "/w" filter-mapping, and
> migrate one page after another.
>
> The WebWork session holds information about currently logged in user,
> currently selected customer etc, and I need a way to sync this with a
> Wicket session. I could ofcourse add this information to the url
> everytime I hit a Wicket-page, but that seems really messy.
I don't know how WebWork stores it's sessions, but I imagine they do
that just in the HttpSession, right? So all you need then is knowing
what attribute (keys) are being used. You could write a custom Wicket
session that proxies these, such as:
class MySession extends WebSession {
...
public User getUser() {
return
(User)MyRequestCycle.get().getHttpSession().getAttribute("_webwork_user");
}
Note that for the other way around, you can use WicketSessionFilter.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty wicket:message
The easiest solution would be this:
Index:
/Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/resolver/WicketMessageResolver.java
===
---
/Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/resolver/WicketMessageResolver.java
(revision
591166)
+++
/Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4/wicket/src/main/java/org/apache/wicket/markup/resolver/WicketMessageResolver.java
(working
copy)
@@ -43,13 +43,6 @@
{
private static final Logger log =
LoggerFactory.getLogger(WicketMessageResolver.class);
- /**
-* If the key can't be resolved and the default is null, an
exception will be thrown. Instead,
-* we default to a unique string and check against this later. Don't
just use an empty string
-* here, as people might want to override wicket:messages to empty
strings.
-*/
- private static final String DEFAULT_VALUE =
"DEFAULT_WICKET_MESSAGE_RESOLVER_VALUE";
-
static
{
// register "wicket:message"
@@ -74,7 +67,7 @@
* @return true, if componentId was handle by the resolver. False,
otherwise
*/
public boolean resolve(final MarkupContainer container, final
MarkupStream markupStream,
- final ComponentTag tag)
+ final ComponentTag tag)
{
if (tag instanceof WicketTag)
{
@@ -85,7 +78,7 @@
if ((messageKey == null) ||
(messageKey.trim().length() == 0))
{
throw new MarkupException(
- "Wrong format of
: attribute 'key'
is missing");
+ "Wrong format of
: attribute 'key' is
missing");
}
final String id = "_message_" +
container.getPage().getAutoIndex();
@@ -91,7 +84,7 @@
final String id = "_message_" +
container.getPage().getAutoIndex();
MessageLabel label = new MessageLabel(id,
messageKey);
label.setRenderBodyOnly(container.getApplication().getMarkupSettings()
- .getStripWicketTags());
+ .getStripWicketTags());
container.autoAdd(label, markupStream);
// Yes, we handled the tag
@@ -125,8 +118,8 @@
protected void onComponentTagBody(MarkupStream markupStream,
ComponentTag openTag)
{
final String key = getModelObjectAsString();
- final String value = getLocalizer().getString(key,
getParent(),
DEFAULT_VALUE);
- if (value != null && !DEFAULT_VALUE.equals(value))
+ final String value = getLocalizer().getString(key,
getParent());
+ if (value != null)
{
replaceComponentTagBody(markupStream, openTag,
value.trim());
}
But that would produce a lousy error message:
WicketMessage: Exception in rendering component: [Component id =
_message_4, page = org.apache.wicket.examples.helloworld.HelloWorld,
path = 6:_message_4.WicketMessageResolver$MessageLabel, isVisible =
true, isVersioned = true]
Root cause:
java.util.MissingResourceException: Unable to find resource: test for
component: [class=org.apache.wicket.examples.helloworld.HelloWorld]
at org.apache.wicket.Localizer.getString(Localizer.java:261)
at org.apache.wicket.Localizer.getString(Localizer.java:91)
at
org.apache.wicket.markup.resolver.WicketMessageResolver$MessageLabel.onComponentTagBody(WicketMessageResolver.java:128)
at org.apache.wicket.Component.renderComponent(Component.java:2416)
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty wicket:message
Yes we could do that. Just remove that default value.
But what i would like to have IF you have a body specified then we don't
throw anything
This way we keep old behavior and we have the new one
Because if i specifiy a body then thats the default value for me. And if not
then i still can see
very easy that i miss a key.
But i guess that is not that easy to do because we have no idea inside the
tag that it really has a body right?
but i am fine with this change.
johan
On 11/4/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
>
> The easiest solution would be this:
>
> Index: /Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4
> /wicket/src/main/java/org/apache/wicket/markup/resolver/WicketMessageResolver.java
> ===
> --- /Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4
> /wicket/src/main/java/org/apache/wicket/markup/resolver/WicketMessageResolver.java
> (revision
> 591166)
> +++ /Users/eelcohillenius/Documents/workspace_wicket/trunk/jdk-1.4
> /wicket/src/main/java/org/apache/wicket/markup/resolver/WicketMessageResolver.java
> (working
> copy)
> @@ -43,13 +43,6 @@
> {
>private static final Logger log =
> LoggerFactory.getLogger(WicketMessageResolver.class);
>
> - /**
> -* If the key can't be resolved and the default is null, an
> exception will be thrown. Instead,
> -* we default to a unique string and check against this later.
> Don't
> just use an empty string
> -* here, as people might want to override wicket:messages to empty
> strings.
> -*/
> - private static final String DEFAULT_VALUE =
> "DEFAULT_WICKET_MESSAGE_RESOLVER_VALUE";
> -
>static
>{
>// register "wicket:message"
> @@ -74,7 +67,7 @@
> * @return true, if componentId was handle by the resolver. False,
> otherwise
> */
>public boolean resolve(final MarkupContainer container, final
> MarkupStream markupStream,
> - final ComponentTag tag)
> + final ComponentTag tag)
>{
>if (tag instanceof WicketTag)
>{
> @@ -85,7 +78,7 @@
>if ((messageKey == null) || (
> messageKey.trim().length() == 0))
>{
>throw new MarkupException(
> - "Wrong format of
> : attribute 'key'
> is missing");
> + "Wrong format of
> : attribute 'key' is
> missing");
>}
>
>final String id = "_message_" +
> container.getPage().getAutoIndex();
> @@ -91,7 +84,7 @@
>final String id = "_message_" +
> container.getPage().getAutoIndex();
>MessageLabel label = new MessageLabel(id,
> messageKey);
>label.setRenderBodyOnly(
> container.getApplication().getMarkupSettings()
> - .getStripWicketTags());
> + .getStripWicketTags());
>container.autoAdd(label, markupStream);
>
>// Yes, we handled the tag
> @@ -125,8 +118,8 @@
>protected void onComponentTagBody(MarkupStream
> markupStream,
> ComponentTag openTag)
>{
>final String key = getModelObjectAsString();
> - final String value = getLocalizer().getString(key,
> getParent(),
> DEFAULT_VALUE);
> - if (value != null && !DEFAULT_VALUE.equals(value))
> + final String value = getLocalizer().getString(key,
> getParent());
> + if (value != null)
>{
>replaceComponentTagBody(markupStream,
> openTag, value.trim());
>}
>
>
> But that would produce a lousy error message:
>
> WicketMessage: Exception in rendering component: [Component id =
> _message_4, page = org.apache.wicket.examples.helloworld.HelloWorld,
> path = 6:_message_4.WicketMessageResolver$MessageLabel, isVisible =
> true, isVersioned = true]
>
> Root cause:
>
> java.util.MissingResourceException: Unable to find resource: test for
> component: [class=org.apache.wicket.examples.helloworld.HelloWorld]
> at org.apache.wicket.Localizer.getString(Localizer.java:261)
> at org.apache.wicket.Localizer.getString(Localizer.java:91)
> at
> org.apache.wicket.markup.resolver.WicketMessageResolver$MessageLabel.onComponentTagBody
> (WicketMessageResolver.java:128)
> at org.apache.wicket.Component.renderComponent(Component.java:2416)
>
>
> Eelco
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [
Re: empty wicket:message
On 11/3/07, Johan Compagner <[EMAIL PROTECTED]> wrote: > Yes we could do that. Just remove that default value. > But what i would like to have IF you have a body specified then we don't > throw anything > This way we keep old behavior and we have the new one > Because if i specifiy a body then thats the default value for me. And if not > then i still can see > very easy that i miss a key. > But i guess that is not that easy to do because we have no idea inside the > tag that it really has a body right? Well, my point was that keeping the body as a default value is actually dangerous: > if you have the default body the same as what you intended to put in the properties file for the default locale (which is something that I often do, and I can imagine other people doing that as well), and you make a spelling error in the key (of either the tag or in the properties file), you'd never notice Wicket not finding the property You want to define a body for previewability, but you don't want to default to that because this silent failure makes it hard to detect errors in your message keys. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty wicket:message
Johan Compagner wrote: Yes we could do that. Just remove that default value. But what i would like to have IF you have a body specified then we don't throw anything This way we keep old behavior and we have the new one FWIW, I entirely agree with this. If we just change it for tags that have a "default" body then we'll almost certainly break people's sites. Regards, Al - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: empty wicket:message
On 11/3/07, Al Maw <[EMAIL PROTECTED]> wrote: > Johan Compagner wrote: > > Yes we could do that. Just remove that default value. > > But what i would like to have IF you have a body specified then we don't > > throw anything > > This way we keep old behavior and we have the new one > > FWIW, I entirely agree with this. If we just change it for tags that > have a "default" body then we'll almost certainly break people's sites. How about keeping this for the deployment mode (and log an error or warning once) but throw that exception in development mode? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebWork and Wicket in the same application - session sharing?
I don't know how WebWork stores it's sessions, but I imagine they do
that just in the HttpSession, right? So all you need then is knowing
what attribute (keys) are being used. You could write a custom Wicket
session that proxies these, such as:
class MySession extends WebSession {
...
public User getUser() {
return
(User)MyRequestCycle.get().getHttpSession().getAttribute("_webwork_user");
}
Sessions in WebWork are stored in the HttpSession like this:
ActionContext.getContext().getSession().put(key, value);
so this should be trivial. Thanks a lot!
I have never needed to override newRequestCycle() in the WebApplication
class before, and it seems getHttpSession() is not available in the
default RequestCycle implementation. How do I get a hold of the
HttpSession object?
-- Edvin
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebWork and Wicket in the same application - session sharing?
I did exactly this for an old application. I wrote all the new code in Wicket and just shared the log-in details from the session. They would log in using wicket and the WW pages would check for the user object in the HttpSession. Was very painless. On 3 Nov 2007, at 16:49, Edvin Syse wrote: Hi, I have a large application written in WebWork, Spring and iBATIS. After having started working with Wicket it really pains me that I have to continue developing with WebWork, so I want to start migrating this application on a page-by-page basis :) I'm thinking I'd add a filter for wicket with a "/w" filter- mapping, and migrate one page after another. The WebWork session holds information about currently logged in user, currently selected customer etc, and I need a way to sync this with a Wicket session. I could ofcourse add this information to the url everytime I hit a Wicket-page, but that seems really messy. Any suggestions? Sincerely, Edvin Syse - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebWork and Wicket in the same application - session sharing?
> Sessions in WebWork are stored in the HttpSession like this:
>
> ActionContext.getContext().getSession().put(key, value);
>
> so this should be trivial. Thanks a lot!
>
> I have never needed to override newRequestCycle() in the WebApplication
> class before, and it seems getHttpSession() is not available in the
> default RequestCycle implementation. How do I get a hold of the
> HttpSession object?
Something like this in your application:
private static class MyRequestCycle extends WebRequestCycle
{
public static MyRequestCycle get()
{
return (MyRequestCycle)RequestCycle.get();
}
public MyRequestCycle(WebApplication application, WebRequest
request, Response response)
{
super(application, request, response);
}
public HttpSession getHttpSession()
{
return
getWebRequest().getHttpServletRequest().getSession(false);
}
}
@Override
public RequestCycle newRequestCycle(Request request, Response response)
{
return new MyRequestCycle(this, (WebRequest)request, response);
}
Of course, you could do this in a custom Wicket session or utility
class as well if you use:
((WebRequestCycle)RequestCycle.get()).getWebRequest().getHttpServletRequest().getSession(false);
Ugly, but it works.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebWork and Wicket in the same application - session sharing?
On 11/3/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
> > Sessions in WebWork are stored in the HttpSession like this:
> >
> > ActionContext.getContext().getSession().put(key, value);
> >
> > so this should be trivial. Thanks a lot!
> >
> > I have never needed to override newRequestCycle() in the WebApplication
> > class before, and it seems getHttpSession() is not available in the
> > default RequestCycle implementation. How do I get a hold of the
> > HttpSession object?
>
> Something like this in your application:
>
> private static class MyRequestCycle extends WebRequestCycle
> {
> public static MyRequestCycle get()
> {
> return (MyRequestCycle)RequestCycle.get();
> }
>
> public MyRequestCycle(WebApplication application, WebRequest
> request, Response response)
> {
> super(application, request, response);
> }
>
> public HttpSession getHttpSession()
> {
> return
> getWebRequest().getHttpServletRequest().getSession(false);
> }
> }
>
> @Override
> public RequestCycle newRequestCycle(Request request, Response
> response)
> {
> return new MyRequestCycle(this, (WebRequest)request,
> response);
> }
>
> Of course, you could do this in a custom Wicket session or utility
> class as well if you use:
> ((WebRequestCycle)RequestCycle.get()).getWebRequest().getHttpServletRequest().getSession(false);
And... why I would do this in a custom session and just call
super.getAttribute("_webwork_user"):
* Wicket encodes attributes in it's own way (prepends the application
key to it), so you'd have to circumvent that;
* It is not a certainty that the session store implementation that the
Wicket session uses, is using the HttpSession to start with (might be
a database or plain RAM for instance)
So the safest thing to do here is go directly to the HttpSession. You
can pretty much depend on the RequestCycle being a WebRequestCycle
unless you're doing something really different.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: WebWork and Wicket in the same application - session sharing?
Perfect!
It worked, and now I just need to create my own AuthorizationStrategy to
check the loggedinUser etc :) Thank you for the super help!
-- Edvin
Eelco Hillenius wrote:
On 11/3/07, Eelco Hillenius <[EMAIL PROTECTED]> wrote:
Sessions in WebWork are stored in the HttpSession like this:
ActionContext.getContext().getSession().put(key, value);
so this should be trivial. Thanks a lot!
I have never needed to override newRequestCycle() in the WebApplication
class before, and it seems getHttpSession() is not available in the
default RequestCycle implementation. How do I get a hold of the
HttpSession object?
Something like this in your application:
private static class MyRequestCycle extends WebRequestCycle
{
public static MyRequestCycle get()
{
return (MyRequestCycle)RequestCycle.get();
}
public MyRequestCycle(WebApplication application, WebRequest
request, Response response)
{
super(application, request, response);
}
public HttpSession getHttpSession()
{
return
getWebRequest().getHttpServletRequest().getSession(false);
}
}
@Override
public RequestCycle newRequestCycle(Request request, Response response)
{
return new MyRequestCycle(this, (WebRequest)request, response);
}
Of course, you could do this in a custom Wicket session or utility
class as well if you use:
((WebRequestCycle)RequestCycle.get()).getWebRequest().getHttpServletRequest().getSession(false);
And... why I would do this in a custom session and just call
super.getAttribute("_webwork_user"):
* Wicket encodes attributes in it's own way (prepends the application
key to it), so you'd have to circumvent that;
* It is not a certainty that the session store implementation that the
Wicket session uses, is using the HttpSession to start with (might be
a database or plain RAM for instance)
So the safest thing to do here is go directly to the HttpSession. You
can pretty much depend on the RequestCycle being a WebRequestCycle
unless you're doing something really different.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Is Beta5 coming soon? Beta4 has caused these issues for us....
Sorry Al, but you lost your money ;-) I put back slf4j-api-1.4.2.jar , and still the same problem... Using the jars suggested by Cristi doesn't help either. But since it seems i'm the only one to still have the problem, must be a problem with my classpath. I will recheck after deploying the project in a war. Maybe it's just eclipse WTP that does some weird things with my classpath. As always, thanks a lot for your support, guys. 2007/11/3, Al Maw <[EMAIL PROTECTED]>: > > landry soules wrote: > > Actually, i didn't go on with maven, since my project is already quite > > advanced now, i don't want to reconfigure it to use maven. I just tried > to > > create a sample project to figure out what is the correct combination of > > slf4j/log4j to use (bad idea, since it appears to be broken in the > original > > wicket pom). > > So i'm back in my real eclipse project, and this neverending error : > > > > Exception in thread "ModificationWatcher Task" > java.lang.NoSuchMethodError: > > org.slf4j.Logger.isTraceEnabled()Z > > at org.apache.wicket.util.thread.Task$1.run(Task.java:103) > > at java.lang.Thread.run(Thread.java:595) > > > > even though i'm using slf4j-log4j12-1.4.2.jar + log4j-1.2.14.jar. > > You also need slf4j-api-1.4.2.jar. I'd lay money on your not having that > version on your classpath (or having an earlier version as well). > > Regards, > > Al > > - > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
Re: Jira issue moved to the list: constructors and init of components
Probably right.
In the example below, some may argue that the javadoc (here aimed at
sub-classers) on the parent class' constructor could say (as loudly as
possible, but probably never quite loudly enough) that doStuff() is called
before all state is fully initialised (in this case, eye is still null) ie
sub-classers over-riding doStuff() must be aware that getEye() will return
null during initialisation (construction) if called in the over-riding
doStuff() implementation. However, in java, sub-classers can't be forced to
pay any attention to this.
I agree that this variant of the "template method pattern" (for java
constructors) is at best dangerous: sub-classers are almost invited to try
to do stuff that their state may not yet be initialised for;
eg: if the over-ridden method (which is the implementation that will
actually be run by the super-class' constructor - as in polymorphism) tries
to use inherited state.
Here's an example for anyone who is still wondering what all the fuss is
about:
public class Parent{
private Eye eye;
public Parent{
doStuff();
eye = new Eye("black");
}
protected void doStuff(){ // consider marking this final
// do some stuff
}
final protected void getEye(){return eye;}
}
class Child extends Parent{
// for illustration; explicitly declared (and explicitly calls super() )
public Child(){
super(); // will throw an NPE (in doStuff() ); eye is not
initialised yet
}
public void doStuff(){
super.doStuff(); // nice try, but doesn't help here
getEye().getColour(); // getEye() will return null when called by
Parent's constructor
}
}
Regards - Cemal
http://jWeekend.co.uk jWeekend.co.uk
igor.vaynberg wrote:
>
> On 11/3/07, Al Maw <[EMAIL PROTECTED]> wrote:
>> There's nothing to stop you making your constructor call methods to
>> initialise things that people can then override.
>
> erm. really? while there is nothing stopping you, you clearly shouldnt...
>
> -igor
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
>
--
View this message in context:
http://www.nabble.com/Jira-issue-moved-to-the-list%3A-constructors-and-init-of-components-tf4743674.html#a13569154
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira issue moved to the list: constructors and init of components
that sb:
final protected Eye getEye(){return eye;}
jweekend wrote:
>
> Probably right.
>
> In the example below, some may argue that the javadoc (here aimed at
> sub-classers) on the parent class' constructor could say (as loudly as
> possible, but probably never quite loudly enough) that doStuff() is called
> before all state is fully initialised (in this case, eye is still null)
> ie sub-classers over-riding doStuff() must be aware that getEye() will
> return null during initialisation (construction) if called in the
> over-riding doStuff() implementation. However, in java, sub-classers can't
> be forced to pay any attention to this.
>
> I agree that this variant of the "template method pattern" (for java
> constructors) is at best dangerous: sub-classers are almost invited to try
> to do stuff that their state may not yet be initialised for;
> eg: if the over-ridden method (which is the implementation that will
> actually be run by the super-class' constructor - as in polymorphism)
> tries to use inherited state.
>
> Here's an example for anyone who is still wondering what all the fuss is
> about:
>
> public class Parent{
> private Eye eye;
> public Parent{
> doStuff();
> eye = new Eye("black");
> }
> protected void doStuff(){ // consider marking this final
> // do some stuff
> }
> final protected void getEye(){return eye;}
> }
>
> class Child extends Parent{
> // for illustration; explicitly declared (and explicitly calls super()
> )
> public Child(){
> super(); // will throw an NPE (in doStuff() ); eye is not
> initialised yet
> }
> public void doStuff(){
> super.doStuff(); // nice try, but doesn't help here
> getEye().getColour(); // getEye() will return null when called by
> Parent's constructor
> }
> }
>
> Regards - Cemal
> http://jWeekend.co.uk jWeekend.co.uk
>
>
>
> igor.vaynberg wrote:
>>
>> On 11/3/07, Al Maw <[EMAIL PROTECTED]> wrote:
>>> There's nothing to stop you making your constructor call methods to
>>> initialise things that people can then override.
>>
>> erm. really? while there is nothing stopping you, you clearly shouldnt...
>>
>> -igor
>>
>> -
>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>> For additional commands, e-mail: [EMAIL PROTECTED]
>>
>>
>>
>
>
--
View this message in context:
http://www.nabble.com/Jira-issue-moved-to-the-list%3A-constructors-and-init-of-components-tf4743674.html#a13569202
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira issue moved to the list: constructors and init of components
> > Yep, you could. Though some constructors in other classes (in or > > outside Wicket) might expect not-null arguments passed in in > > constructors. It just depends on who implemented it. There is no > > golden pattern that everyone follows; if there was, it should probably > > be enforced in the language. > > Thanks. I agree there is no golden pattern, but to have in jdk something like > @Nullable and @NotNull would be nice :) Or we need a better language :-) See for instance http://gbracha.blogspot.com/2007/06/constructors-considered-harmful.html (great post, don't forget to read the comments) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: {wicket 1.3 beta 4} Error handling (Internal error page)
Whatever you set in setInternalErrorPage is ignored if you override
onRuntimeException in a custom request cycle.
Eelco
On 11/1/07, Nino Saturnino Martinez Vazquez Wael
<[EMAIL PROTECTED]> wrote:
> Appears I was wrong. This is actually working. I would still like to
> know if this is the correct way to do it?
>
> regards Nino
>
> Nino Saturnino Martinez Vazquez Wael wrote:
> > Hi
> >
> > Im doing some finishing touches at our web application. And Im trying
> > to create a internal error page that gives the possibility for the
> > user to get back to the page that caused the error, just in case that
> > the circumstances that caused the error are gone.
> >
> > Now this is what I've done :
> >
> > in init of the application i've placed this:
> >
> >
> > getApplicationSettings().setInternalErrorPage(InternalErrorPage.class);
> >getExceptionSettings().setUnexpectedExceptionDisplay(
> >IExceptionSettings.SHOW_INTERNAL_ERROR_PAGE);
> >
> >@Override
> >public RequestCycle newRequestCycle(final Request request,
> >final Response response) {
> >return new WebRequestCycle(this, (WebRequest) request,
> >(WebResponse) response)[EMAIL PROTECTED]
> >public Page onRuntimeException(Page page,
> > RuntimeException e) {
> >return new InternalErrorPage(page, e);
> >}};
> > }
> >
> > But page are always null, is there something wrong with this approach?
> > I also have an idea that the overide makes setting the
> > applicationsettings/exceptionsettings unrelevant.
> >
> > PS have looked at the wiki:
> > http://cwiki.apache.org/WICKET/faqs.html#FAQs-HowdoIaddcustomerrorpages%2528likePageExpired%2529%253F
> >
> >
> > regards Nino
> >
> > -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> >
> >
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket-contrib-input-events : keyboard shortcuts for wicket
> Im wondering if we(wickeers) would need an integration for a window > manager possibly: http://www.vegui.org/ ? Havent checked it enough to > see how complex it are and how easy it would be to make an simple > integration. I don't know. It looks fancy, but I wonder how many people will actually need this. Unless you're making it your hobby, it's probably better to stick to components you plan on using yourself. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira issue moved to the list: constructors and init of components
yes, but its also easy to fix. Just don't call any overridible methods
inside constructors. And for everything else there is onbeforerender()
On 11/3/07, jweekend <[EMAIL PROTECTED]> wrote:
>
> that sb:
> final protected Eye getEye(){return eye;}
>
>
>
> jweekend wrote:
> >
> > Probably right.
> >
> > In the example below, some may argue that the javadoc (here aimed at
> > sub-classers) on the parent class' constructor could say (as loudly as
> > possible, but probably never quite loudly enough) that doStuff() is called
> > before all state is fully initialised (in this case, eye is still null)
> > ie sub-classers over-riding doStuff() must be aware that getEye() will
> > return null during initialisation (construction) if called in the
> > over-riding doStuff() implementation. However, in java, sub-classers can't
> > be forced to pay any attention to this.
> >
> > I agree that this variant of the "template method pattern" (for java
> > constructors) is at best dangerous: sub-classers are almost invited to try
> > to do stuff that their state may not yet be initialised for;
> > eg: if the over-ridden method (which is the implementation that will
> > actually be run by the super-class' constructor - as in polymorphism)
> > tries to use inherited state.
> >
> > Here's an example for anyone who is still wondering what all the fuss is
> > about:
> >
> > public class Parent{
> > private Eye eye;
> > public Parent{
> > doStuff();
> > eye = new Eye("black");
> > }
> > protected void doStuff(){ // consider marking this final
> > // do some stuff
> > }
> > final protected void getEye(){return eye;}
> > }
> >
> > class Child extends Parent{
> > // for illustration; explicitly declared (and explicitly calls super()
> > )
> > public Child(){
> > super(); // will throw an NPE (in doStuff() ); eye is not
> > initialised yet
> > }
> > public void doStuff(){
> > super.doStuff(); // nice try, but doesn't help here
> > getEye().getColour(); // getEye() will return null when called by
> > Parent's constructor
> > }
> > }
> >
> > Regards - Cemal
> > http://jWeekend.co.uk jWeekend.co.uk
> >
> >
> >
> > igor.vaynberg wrote:
> >>
> >> On 11/3/07, Al Maw <[EMAIL PROTECTED]> wrote:
> >>> There's nothing to stop you making your constructor call methods to
> >>> initialise things that people can then override.
> >>
> >> erm. really? while there is nothing stopping you, you clearly shouldnt...
> >>
> >> -igor
> >>
> >> -
> >> To unsubscribe, e-mail: [EMAIL PROTECTED]
> >> For additional commands, e-mail: [EMAIL PROTECTED]
> >>
> >>
> >>
> >
> >
>
> --
> View this message in context:
> http://www.nabble.com/Jira-issue-moved-to-the-list%3A-constructors-and-init-of-components-tf4743674.html#a13569202
> Sent from the Wicket - User mailing list archive at Nabble.com.
>
>
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Jira issue moved to the list: constructors and init of components
On Sunday 04 November 2007 02:37:39 Johan Compagner wrote:
> You just should call super of the same constructor you are in.
> just give the super call everything you got. If you got a model, give it
> but you don;t have to you can set it in the constructor with setModel
> afterwards.
That's what I do. But it makes my code look like those super calls have
different logic unless you know they are similar.
> I still don't get what this discussion is more about
I was trying to say that in my view this would be more readable.
protected WebPage(final IPageMap pageMap)
{
this(pageMap, null);
// commonInit();
}
protected WebPage(final IPageMap pageMap, final PageParameters parameters)
{
super(pageMap, parameters);
commonInit();
}
> If you really want to have an init phase thats called after the constructor
> is called (and finished)
> then i think you should choose a different web framework, That uses managed
> components/pages
No, I didn't mean that. I like wicket :)
Dima
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Problem closing a ModalWindow when used through an IFrame
Hi Matej! Have you been able to reproduce this problem? DM 2007/11/1, Deepak Mahavishnu <[EMAIL PROTECTED]>: > > Hi Matej! > And thanks for a quick response! > > I opened a jira issue related to this. The quick start is very straight > forward: > > Just create a html page with this source: > > > > http://www.wicket-library.com/wicket-examples/ajax/modal-window.1"; > width="100%" height="100%"> > > > > And then open "Show modal dialog with panel" and try to close the dialog. > > Mahavishnu > > 2007/11/1, Matej Knopp <[EMAIL PROTECTED]>: > > > > The modal window probably won't work well when paced in a page that is > > loaded in iframe. Still, if you can provide a quickstart assigned to a > > JIRA entry I will take a look if there is a quick fix for your > > problem. > > > > -Matej > > > > On 11/1/07, Deepak Mahavishnu <[EMAIL PROTECTED]> wrote: > > > Hello! > > > > > > I'm doing some POC testing to find out how a wicket application could > > be > > > used through an IFrame and noticed that closing of a ModalWindow > > fails. > > > > > > My setup: > > > > > > Application A: > > > -a dummy html page that has an IFrame > > > -the contents of the IFrame is requested from Application B > > > http://localhost:8080/mywicketapp/app/"; width="100%" > > > height="500"> > > > > > > Application B: > > > -a Wicket application that uses a ModalWindow > > > -deployed to tomcat: http://localhost:8080/mywicketapp/ > > > > > > > > > Problem: > > > The ModalWindow is not closed when OK ( or Cancel ) button is clicked > > when > > > Application B is used throug IFrame of Application A. > > > OK button performs the actual action (in my case deletes an item from > > a > > > list) but is not closed after the execution of the action. > > > > > > Closing of the ModalWindow works normally when Application B is not > > used > > > through an IFrame. > > > > > > Any suggestions how this could be solved? Or is the usage through an > > IFrame > > > a bad idea from start? > > > > > > Any help is appreciated! > > > > > > Mahavishnu > > > > > > > - > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > >
