Re: IAuthorizationStrategy and DropDownChoice
Did you notice this method in AbstractChoice? protected boolean isDisabled(final Object object, int index, String selected) It is designed to do exactly what you want. In Wicket 1.3 only, in wicket 1.2 you need to override protected void appendOptionHtml(AppendingStringBuffer buffer, Object choice, int index, String selected) and do it yourself. Maurice On 10/16/07, Jonas [EMAIL PROTECTED] wrote: While implementing a custom IAuthorizationStrategy for our web app, I noticed that DropDownChoice (and any other AbstractChoice) doesn't honor restrictions on Component.RENDER and Component.ENABLE. Is there a recommended way to make that work? Wouldn't it make sense that AbstractChoice did honor those restrictions, as e.g. AbstractLink does? That would probably require an extension of the IAuthorizationStrategy interface, since the selectable options are just any kind of objects, not wicket components. Maybe a method like boolean isActionAuthorized(Component component, Object item, Action action); would do the trick? Jonas - 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: authorize - hasAny / hasAll ?
Can't you create a role that implies all the other roles and then specifically check for that role? Maurice On 10/17/07, Eelco Hillenius [EMAIL PROTECTED] wrote: The wicket-auth project is intended more like an example then a full fledged project. Best thing you can do is just copy the things you need in your own project and tailor for your needs. Eelco On 10/10/07, Artur W. [EMAIL PROTECTED] wrote: Hi, I use MetaDataRoleAuthorizationStrategy.authorize but it authorize if user has ANY of the roles. It's ok, but sometimes I need to authorize when user has ALL the roles. It is possible? Thanks, Artur -- View this message in context: http://www.nabble.com/authorize---hasAny---hasAll---tf4600532.html#a13135051 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: IAuthorizationStrategy and DropDownChoice
I don't think that is what he's getting at, I guess the real questions are: 1) why is option enablement not forwarded to the authorization strategy? 2) Is there a blessed way to no render options depending on authorization. Of course you can hack it, but you'll end up with your authorization code sprinkled around your project instead of a single point. Thomas -Original Message- From: Maurice Marrink [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 17. Oktober 2007 09:07 To: users@wicket.apache.org Subject: Re: IAuthorizationStrategy and DropDownChoice Did you notice this method in AbstractChoice? protected boolean isDisabled(final Object object, int index, String selected) It is designed to do exactly what you want. In Wicket 1.3 only, in wicket 1.2 you need to override protected void appendOptionHtml(AppendingStringBuffer buffer, Object choice, int index, String selected) and do it yourself. Maurice On 10/16/07, Jonas [EMAIL PROTECTED] wrote: While implementing a custom IAuthorizationStrategy for our web app, I noticed that DropDownChoice (and any other AbstractChoice) doesn't honor restrictions on Component.RENDER and Component.ENABLE. Is there a recommended way to make that work? Wouldn't it make sense that AbstractChoice did honor those restrictions, as e.g. AbstractLink does? That would probably require an extension of the IAuthorizationStrategy interface, since the selectable options are just any kind of objects, not wicket components. Maybe a method like boolean isActionAuthorized(Component component, Object item, Action action); would do the trick? Jonas - 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: 1.3-beta4 development mode
I found out the problem causing it. It seems that when building the project, an older version of log4j (1.12.9) was added to the classpath as a transitive dependency, causing a conflict with the newer one (1.12.13). Thank you all! Nino.Martinez wrote: Hi Alex I cannot confirm this, I too have beta4 installed. And have not problems when refreshing html. At certain times there can be problems with the java classes, which I belive are known(there are some limitations on the hotspot vm I belive that causes this). This is using it with tomcat 5. Alex Objelean wrote: I've noticed that when working in development mode with beta4, changing the markup is not visible when browser page is refreshed (in beta3 was ok) - thus a restart is needed. Are there any ModificationWatcher changes in latest beta release? Thank you! Alex. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/1.3-beta4-development-mode-tf4624760.html#a13249032 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: Dot ( . ) in the URL !
Still I believe the HybridUrlCodingStrategy should be able to process such url. Can you please create a JIRA entry for this? Thanks. -Matej On 10/17/07, Martijn Dashorst [EMAIL PROTECTED] wrote: Not in the hybrid URL encoding. There the last two numbers are separated with a dot and represent page number and version number. The page mounted needs to be bookmarkable to be callable without prior session buildup, Martijn On 10/17/07, Eelco Hillenius [EMAIL PROTECTED] wrote: As far as I know, only : is reserved. But if you have a reproducible bug, please create an issue in JIRA. Eelco On 10/15/07, chickabee [EMAIL PROTECTED] wrote: The page was mount using HybridUrlCodingStrategy --thanks Matej Knopp-2 wrote: How did you mount the page? -Matej On 10/15/07, chickabee [EMAIL PROTECTED] wrote: Hi Guys, It seems that wicket has the special meaning of a dot ( . ) in the URL. Wicket expects anything after a dot to be a number and throws Number format exception if it is not, Is there is a way to use dots in the url?? Here is the example of the url where it is failing: https://lilo:8443/whisky/plist/c/Computers%3EComputer_Systems%3ELaptops/ps/1.00_-_1.99_GHz/ Thanks in advance.. -- View this message in context: http://www.nabble.com/Dot-%28-.-%29-in-the-URL-%21-tf4624550.html#a13206993 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] -- View this message in context: http://www.nabble.com/Dot-%28-.-%29-in-the-URL-%21-tf4624550.html#a13224511 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] -- 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
StringResourceModel toString() changed in Beta4 - why??? Must use getString() now.
Hi all,
I swapped beta3 for beta4 and to my surprise all of my StringResourceModels
that have worked (even back to 1.2) suddenly dont work. The toString() call
no longer returns the resource String. I dont see this in the release notes
so to say the least, this was a very frustrating find.
For example, this use to work:
public String getPageTitle()
{
return new StringResourceModel(page.title, this, new
Model(this)).toString();
}
Now I have to say:
public String getPageTitle()
{
StringResourceModel(page.title, this, new Model(this)).getString();
}
A subtle change that that took some time to finally track down... Why did
this change? I believe the toString() is referenced in many docs.
chris
--
View this message in context:
http://www.nabble.com/StringResourceModel-toString%28%29-changed-in-Beta4---why-Must-use-getString%28%29-now.-tf4638851.html#a13249098
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: Wicket Meetup: 33 attendees and counting
We're doing very well, with another 4 people signing up in the last two days for the Amsterdam meetup on November 30. why don't we involve the NL-Jug to get in touch with the developer community that may not be aware of this mailing list? Let me know what you think. If you'd like to say something, or if you'd like to *hear* something, speak up! :) I'd also like some kind of 'best practices' session. regards, Wouter -- Wouter Huijnink Func. Internet Integration W http://www.func.nl T +31 20 423 F +31 20 4223500 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wicket App/Component loading Portlets?
Hi, just out of curiosity - what has a portlet-server to provide a portlet? Would it be (easily) achievalbe to have a wicket-application or -component load/display a portlet? Regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: hi questions about DateField, thanks!
Thanks very much, I was looking at the log files in tomcat, but I don't think
I found anything but in the console (I am using eclipse), I saw:
17-Oct-2007 10:53:41 org.apache.catalina.core.StandardWrapperValve invoke
SEVERE: Servlet.service() for servlet NiceUrlApplication threw exception
javax.servlet.ServletException: Servlet execution threw an exception
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:313)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:175)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:263)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:844)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:584)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
at java.lang.Thread.run(Unknown Source)
Eelco Hillenius wrote:
Your code looks fine to me. We really need to see that stack trace.
Eelco
On 10/16/07, raybristol [EMAIL PROTECTED] wrote:
Hi, I try to add a datefield to my page, accroding to the examples in
http://www.wicketstuff.org/wicket13/index.html
but I get a error and then I try to do it on a sperate page just for
testing
but getting the same error:
type Exception report
message
description The server encountered an internal error () that prevented it
from fulfilling this request.
exception
javax.servlet.ServletException: Servlet execution threw an exception
note The full stack trace of the root cause is available in the Apache
Tomcat/6.0.14 logs.
However about error message doesn't tell me anything, and the code is
really
simple:
java code:
public class DateFieldTest extends WebPage{
private Date date = new Date();
public DateFieldTest(){
Form form = new Form(form);
DateTextField dateTextField = new DateTextField(dateTextField,
new
PropertyModel(this,
date), new StyleDateConverter(S-, true));
form.add(dateTextField);
dateTextField.add(new DatePicker());
add(form);
}
}
Html code:
?xml version=1.0 encoding=UTF-8?
html xmlns=http://www.w3.org/1999/xhtml;
head
titleWicket Examples - dates/title
/head
body
form wicket:id=form
input type=text wicket:id=dateTextField /
input type=submit value=submit /
/form
/body
/html
Thanks for this forum, I am getting lots help from here, many many thanks
again!
Ray
--
View this message in context:
http://www.nabble.com/hi-questions-about-DateField%2C-thanks%21-tf4635435.html#a13237803
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]
--
View this message in context:
http://www.nabble.com/hi-questions-about-DateField%2C-thanks%21-tf4635435.html#a13250347
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: StringResourceModel toString() changed in Beta4 - why??? Must use getString() now.
Hi Thomas, The javadoc pretty clearly says that this is useful for debugging and so on What lead you to believe this would always return a user-readable string? actually, I stumbled over this, too. I used StringResourceModel for IChoiceRenderer- and IOptionRenderer-Lists (where one assumes String within getDisplayValue/getIdValue). Now I have to do an if( obj instanceof StringResourceModel ) return( ((StringResourceModel) obj).getString() ); whereas for all other cases I just return 'toString()'. This wasn't a nice surprise actually. Regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Page expired upon file download + model update
On Thu, 11 Oct 2007 17:00:46 +0200 Federico Fanton [EMAIL PROTECTED] wrote: The button has setDefaultFormProcessing(false), and overrides onSubmit so that the form model object is sent to the persistence layer and printed immediately afterwards. The persistence layer *may* alter the object, so I have to reload it. My problem is that this reloading causes a page expired when I press the button for a second time. Ouch! Looks like it was simply a serialization issue.. ^^; Is there a way to trigger blocking Serialization exceptions instead of simply logging them? Many thanks :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: StringResourceModel toString() changed in Beta4 - why??? Must use getString() now.
Hi Thomas, Yes, but you were relying on an implementation detail which was in no way promised to remain stable. You should not have done that and you got properly burned. not really. The API of StringResourceModel.toString() says: Override of the default method to return the resource string represented by this string resource model. So, I would say it's an unforeseeable API change! Regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wicket logo and badges anywhere?
I thought I had seen the wicket logo and/or some small banners somewhere but maybe that's entirely made up in my head 'cause I just dont find it now (the logo, that is). Does it exist somewhere? /Per -- View this message in context: http://www.nabble.com/Wicket-logo-and-badges-anywhere--tf4639745.html#a13251371 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: VisitChildren + IComponentResolver broken in beta 4?
It depends on when you call the visitChildren method. The idea is that resolved components are on page only during page render. Otherwise they are removed from page. -Matej On 10/17/07, Juha Alatalo [EMAIL PROTECTED] wrote: In the JIRA issue following was commented: This doesn't seem to be a bug in Wicket. In fact, the bug was that it worked before. ... This new fix is kind of a show stopper for us. What actually is the idea of the componentResolver? Functions like visitChildren works for normally added component. Shouldn't those functions work also for components that are added using IComponentResolver as long as those are visible? - Juha Juha Alatalo wrote: https://issues.apache.org/jira/browse/WICKET-1077 - Juha Matej Knopp wrote: Please create a JIRA entry and assign the example to it. Thanks. -Matej On 10/15/07, Juha Alatalo [EMAIL PROTECTED] wrote: Hi, If the components are added on the page using ComponentResolver, visitChildren() method seems to be working incorrectly. Created following example which works in beta 3 but not in beta 4. http://download.syncrontech.com/public/VisitChildrenExample.zip - Juha - 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] - 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: StringResourceModel toString() changed in Beta4 - why??? Must use getString() now.
Fair enough, was I reading more importance into the second sentence (useful for debugging...). I still would not rely on toString() for anything but debugging purposes unless someone passes me an object of a well known, final class cheers Thomas -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 17. Oktober 2007 12:40 To: users@wicket.apache.org Subject: Re: StringResourceModel toString() changed in Beta4 - why??? Must use getString() now. Hi Thomas, Yes, but you were relying on an implementation detail which was in no way promised to remain stable. You should not have done that and you got properly burned. not really. The API of StringResourceModel.toString() says: Override of the default method to return the resource string represented by this string resource model. So, I would say it's an unforeseeable API change! Regards, --- Jan. - 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: StringResourceModel toString() changed in Beta4 - why??? Must use getString() now.
Hi Thomas, Fair enough, was I reading more importance into the second sentence (useful for debugging...). I still would not rely on toString() for anything but debugging purposes unless someone passes me an object of a well known, final class right - but there are exceptions to rules. :-) In my case, the documentation for IChoiceRenderer.getIdValue() explicitely suggest using toString(). Anyway, clearifcation of the API or a return to the old behavior is needed: https://issues.apache.org/jira/browse/WICKET-1080 Regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VisitChildren + IComponentResolver broken in beta 4?
Hi, But it looks like that in this case the visitChilder is performed during render, and it still won't find stuff added by autoAdd. It is not a very robust design if the behaviour of autoAdd/visitChilder would require some kind of component-hierarchy fine-tuning. This kind of approach might work with static-kind-of applications, but at least for us, the content in applications is very dynamic and interface like IComponentResolver has been very handy. Just a wild guess here - maybe the processing of IComponentResolver stuff was done earlier in beta3 than in beta4. Not getting this fixed can be pretty annoying for us - we have a couple of hundreds of pages done with wicket which rely on this. We could of course try to step back in time with svn to see which change has broken this, but I don't know how much sense it will make unless developers are not going to admit that this is a problem. Ari S. - Original Message - From: Matej Knopp [EMAIL PROTECTED] To: users@wicket.apache.org Sent: Wednesday, October 17, 2007 2:15 PM Subject: Re: VisitChildren + IComponentResolver broken in beta 4? It depends on when you call the visitChildren method. The idea is that resolved components are on page only during page render. Otherwise they are removed from page. -Matej On 10/17/07, Juha Alatalo [EMAIL PROTECTED] wrote: In the JIRA issue following was commented: This doesn't seem to be a bug in Wicket. In fact, the bug was that it worked before. ... This new fix is kind of a show stopper for us. What actually is the idea of the componentResolver? Functions like visitChildren works for normally added component. Shouldn't those functions work also for components that are added using IComponentResolver as long as those are visible? - Juha Juha Alatalo wrote: https://issues.apache.org/jira/browse/WICKET-1077 - Juha Matej Knopp wrote: Please create a JIRA entry and assign the example to it. Thanks. -Matej On 10/15/07, Juha Alatalo [EMAIL PROTECTED] wrote: Hi, If the components are added on the page using ComponentResolver, visitChildren() method seems to be working incorrectly. Created following example which works in beta 3 but not in beta 4. http://download.syncrontech.com/public/VisitChildrenExample.zip - Juha - 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] - 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 logo and badges anywhere?
You should take a look at the maven-site-skin version 1.2 in svn. I think there's one or two badges in the style dir. https://svn.apache.org/viewvc/wicket/common/wicket-site-skin/src/main/resources/style/ otherwise you can find some here: http://wicketframework.org/style/ Martijn On 10/17/07, Per Ejeklint [EMAIL PROTECTED] wrote: I thought I had seen the wicket logo and/or some small banners somewhere but maybe that's entirely made up in my head 'cause I just dont find it now (the logo, that is). Does it exist somewhere? /Per -- View this message in context: http://www.nabble.com/Wicket-logo-and-badges-anywhere--tf4639745.html#a13251371 Sent from the Wicket - User mailing list archive at Nabble.com. - 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]
[RFE] Transitive dependencies changes in parent/pom.xml
In parent/pom.xml there is a dependency on spring-2.0. I most of the projects, it is a best practice to not use the entire spring as a dependency, but to use modular dependencies (eg: spring-core, spring-web, etc). For instance, now you depend on spring-2.0 and the project we are building is depending on spring-core-2.0.7. When maven builds the war, the classpath contains both: spring-2.0 spring-core-2.0.7 which is causing some troubles depending on working environment. Thanks! Alex. -- View this message in context: http://www.nabble.com/-RFE--Transitive-dependencies-changes-in-parent-pom.xml-tf4640092.html#a13252196 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: [RFE] Transitive dependencies changes in parent/pom.xml
This has been discussed over and over. In our experience most people want to use the whole. And if not, then they *ONLY* need to exclude one dependency, whereas otherwise they have to do a lot more. We have made a conscious decision to use spring instead of spring-*. Martijn On 10/17/07, Alex Objelean [EMAIL PROTECTED] wrote: In parent/pom.xml there is a dependency on spring-2.0. I most of the projects, it is a best practice to not use the entire spring as a dependency, but to use modular dependencies (eg: spring-core, spring-web, etc). For instance, now you depend on spring-2.0 and the project we are building is depending on spring-core-2.0.7. When maven builds the war, the classpath contains both: spring-2.0 spring-core-2.0.7 which is causing some troubles depending on working environment. Thanks! Alex. -- View this message in context: http://www.nabble.com/-RFE--Transitive-dependencies-changes-in-parent-pom.xml-tf4640092.html#a13252196 Sent from the Wicket - User mailing list archive at Nabble.com. - 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: VisitChildren + IComponentResolver broken in beta 4?
Hi, I'm afraid you dont' really get what IComponentResolver is for. The purpose is to allow creating components from markup for a very short span of time - basically while the components are rendered and they should be removed immediate afterwards. So if you call visitChildren from another component, the resolved component will not be available. What changed in beta 4 is that we now remove the component immediately after it's rendered (inside the autoAdd call) because otherwise It caused us a nasty memory leak. Also from what I can guess you are doing your solution is really fragile, as you create a component during another component's rendering and then want to interact with that component form other place - but this depends on order in which are components rendered - doesn't seem like a solid solution. One thing necessary to realize is that in current status Wicket only knows the markup that belongs to each component during the render phase, which is wrong place to create components (except for components with extremely short lifespan added and rendered through auto add. but this is internal stuff even though it's not properly marked as such). -Matej On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: Hi, But it looks like that in this case the visitChilder is performed during render, and it still won't find stuff added by autoAdd. It is not a very robust design if the behaviour of autoAdd/visitChilder would require some kind of component-hierarchy fine-tuning. This kind of approach might work with static-kind-of applications, but at least for us, the content in applications is very dynamic and interface like IComponentResolver has been very handy. Just a wild guess here - maybe the processing of IComponentResolver stuff was done earlier in beta3 than in beta4. Not getting this fixed can be pretty annoying for us - we have a couple of hundreds of pages done with wicket which rely on this. We could of course try to step back in time with svn to see which change has broken this, but I don't know how much sense it will make unless developers are not going to admit that this is a problem. Ari S. - Original Message - From: Matej Knopp [EMAIL PROTECTED] To: users@wicket.apache.org Sent: Wednesday, October 17, 2007 2:15 PM Subject: Re: VisitChildren + IComponentResolver broken in beta 4? It depends on when you call the visitChildren method. The idea is that resolved components are on page only during page render. Otherwise they are removed from page. -Matej On 10/17/07, Juha Alatalo [EMAIL PROTECTED] wrote: In the JIRA issue following was commented: This doesn't seem to be a bug in Wicket. In fact, the bug was that it worked before. ... This new fix is kind of a show stopper for us. What actually is the idea of the componentResolver? Functions like visitChildren works for normally added component. Shouldn't those functions work also for components that are added using IComponentResolver as long as those are visible? - Juha Juha Alatalo wrote: https://issues.apache.org/jira/browse/WICKET-1077 - Juha Matej Knopp wrote: Please create a JIRA entry and assign the example to it. Thanks. -Matej On 10/15/07, Juha Alatalo [EMAIL PROTECTED] wrote: Hi, If the components are added on the page using ComponentResolver, visitChildren() method seems to be working incorrectly. Created following example which works in beta 3 but not in beta 4. http://download.syncrontech.com/public/VisitChildrenExample.zip - Juha - 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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VisitChildren + IComponentResolver broken in beta 4?
Hi, I'm afraid you dont' really get what IComponentResolver is for. The purpose is to allow creating components from markup for a very short span of time - basically while the components are rendered and they should be removed immediate afterwards. So if you call visitChildren from another component, the resolved component will not be available. Well. We have been using this from very early days of wicket without a problem. Also, there is no mention about this very short time in javadoc. Actually, if the autoAdded component was there previously for longer time and is now removed immediately this is a quite big change of behaviour if looking it from the application. What changed in beta 4 is that we now remove the component immediately after it's rendered (inside the autoAdd call) because otherwise It caused us a nasty memory leak. We have some rather large sites running with wicket 1.2 using autoAdd stuff, haven't noticed any huge leaks there. Couldn't you consider any other alternatives for fixing that leak instead of insisting that we are doing something so wrong ? I really like all these IWhateverNiceInterface -things in wicket. Usually, when there is a need in application architecture, wicket has had a nice interface to support it. But it seems that it is very easy to get yourself burnt when using them, since they tend to get either rewritten or their behaviour changes Which is not a problem for someone who writes a smaller web applications with just a couple of pages. But for someone who does larger ones, it's not so nice. Ari S. On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: Hi, But it looks like that in this case the visitChilder is performed during render, and it still won't find stuff added by autoAdd. It is not a very robust design if the behaviour of autoAdd/visitChilder would require some kind of component-hierarchy fine-tuning. This kind of approach might work with static-kind-of applications, but at least for us, the content in applications is very dynamic and interface like IComponentResolver has been very handy. Just a wild guess here - maybe the processing of IComponentResolver stuff was done earlier in beta3 than in beta4. Not getting this fixed can be pretty annoying for us - we have a couple of hundreds of pages done with wicket which rely on this. We could of course try to step back in time with svn to see which change has broken this, but I don't know how much sense it will make unless developers are not going to admit that this is a problem. Ari S. - Original Message - From: Matej Knopp [EMAIL PROTECTED] To: users@wicket.apache.org Sent: Wednesday, October 17, 2007 2:15 PM Subject: Re: VisitChildren + IComponentResolver broken in beta 4? It depends on when you call the visitChildren method. The idea is that resolved components are on page only during page render. Otherwise they are removed from page. -Matej On 10/17/07, Juha Alatalo [EMAIL PROTECTED] wrote: In the JIRA issue following was commented: This doesn't seem to be a bug in Wicket. In fact, the bug was that it worked before. ... This new fix is kind of a show stopper for us. What actually is the idea of the componentResolver? Functions like visitChildren works for normally added component. Shouldn't those functions work also for components that are added using IComponentResolver as long as those are visible? - Juha Juha Alatalo wrote: https://issues.apache.org/jira/browse/WICKET-1077 - Juha Matej Knopp wrote: Please create a JIRA entry and assign the example to it. Thanks. -Matej On 10/15/07, Juha Alatalo [EMAIL PROTECTED] wrote: Hi, If the components are added on the page using ComponentResolver, visitChildren() method seems to be working incorrectly. Created following example which works in beta 3 but not in beta 4. http://download.syncrontech.com/public/VisitChildrenExample.zip - Juha - 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] - 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
Re: StringResourceModel toString() changed in Beta4 - why??? Must use getString() now.
Beta3 said this for toString() /** * Override of the default method to return the resource string represented * by this string resource model. Useful in debugging and so on, to avoid * the explicit need to call the getString() method. * * @return The string for this model object */ and this for getString() /** * Gets the string currently represented by this string resource model. The * string that is returned may vary for each call to this method depending * on the values contained in the model and an the parameters that were * passed when this string resource model was created. * * @return The string */ It's arguable that it is/was saying that it could be used to avoid the explicit getString() call but as it no longer can (as it's being used to expose internal details for logging/debugging), then it should really be mentioned in a change note somewhere. /Gwyn On Wednesday, October 17, 2007, 11:21:56 AM, Maeder [EMAIL PROTECTED] wrote: Yes, but you were relying on an implementation detail which was in no way promised to remain stable. You should not have done that and you got properly burned. It's like when you call one of these public methods which are marked as not part of the Wicket API, don't call this. What my question was aimed at was more finding out whether the doc specifies anything about the return value of StringResourceModel.toString(). Thomas -Original Message- From: Jan Kriesten [mailto:[EMAIL PROTECTED] Sent: Mittwoch, 17. Oktober 2007 12:07 To: users@wicket.apache.org Subject: Re: StringResourceModel toString() changed in Beta4 - why??? Must use getString() now. Hi Thomas, The javadoc pretty clearly says that this is useful for debugging and so on What lead you to believe this would always return a user-readable string? actually, I stumbled over this, too. I used StringResourceModel for IChoiceRenderer- and IOptionRenderer-Lists (where one assumes String within getDisplayValue/getIdValue). Now I have to do an if( obj instanceof StringResourceModel ) return( ((StringResourceModel) obj).getString() ); whereas for all other cases I just return 'toString()'. This wasn't a nice surprise actually. Regards, --- Jan. - 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] /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [Wicket-Contrib-Scriptaculous] Effects Examples
Thanks. That's what I was looking for.
On 10/16/07, Ryan Sonnek [EMAIL PROTECTED] wrote:
I think this is what you're looking for:
add(new AjaxLink(myLink) {
protected void onClick(AjaxTarget target) {
target.appendJavascript(new Effect.Fade(myPanel).toJavascript());
}
});
On 10/16/07, Nick Heudecker [EMAIL PROTECTED] wrote:
Hi,
I'm looking for some examples using wicket-contrib-scriptaculous
Effects. I
looked around the examples project and didn't find
anything. Specifically,
I'm looking to make a panel fade out when a link inside the panel is
clicked. Any help is appreciated. Thanks.
-Nick
--
Nick Heudecker
Professional Wicket Training Consulting
http://www.systemmobile.com
Eventful - Intelligent Event Management
http://www.eventfulhq.com
Re: VisitChildren + IComponentResolver broken in beta 4?
Well, I believe we can keep the component instance until the end of request and then clean it up in detach, would this help you? (it still wouldn't be the same as before the fix, as the instance was (supposed to be) cleaned during the next request, but this means keeping additional state for no good reason. -Matej On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: Hi, I'm afraid you dont' really get what IComponentResolver is for. The purpose is to allow creating components from markup for a very short span of time - basically while the components are rendered and they should be removed immediate afterwards. So if you call visitChildren from another component, the resolved component will not be available. Well. We have been using this from very early days of wicket without a problem. Also, there is no mention about this very short time in javadoc. Actually, if the autoAdded component was there previously for longer time and is now removed immediately this is a quite big change of behaviour if looking it from the application. What changed in beta 4 is that we now remove the component immediately after it's rendered (inside the autoAdd call) because otherwise It caused us a nasty memory leak. We have some rather large sites running with wicket 1.2 using autoAdd stuff, haven't noticed any huge leaks there. Couldn't you consider any other alternatives for fixing that leak instead of insisting that we are doing something so wrong ? I really like all these IWhateverNiceInterface -things in wicket. Usually, when there is a need in application architecture, wicket has had a nice interface to support it. But it seems that it is very easy to get yourself burnt when using them, since they tend to get either rewritten or their behaviour changes Which is not a problem for someone who writes a smaller web applications with just a couple of pages. But for someone who does larger ones, it's not so nice. Ari S. On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: Hi, But it looks like that in this case the visitChilder is performed during render, and it still won't find stuff added by autoAdd. It is not a very robust design if the behaviour of autoAdd/visitChilder would require some kind of component-hierarchy fine-tuning. This kind of approach might work with static-kind-of applications, but at least for us, the content in applications is very dynamic and interface like IComponentResolver has been very handy. Just a wild guess here - maybe the processing of IComponentResolver stuff was done earlier in beta3 than in beta4. Not getting this fixed can be pretty annoying for us - we have a couple of hundreds of pages done with wicket which rely on this. We could of course try to step back in time with svn to see which change has broken this, but I don't know how much sense it will make unless developers are not going to admit that this is a problem. Ari S. - Original Message - From: Matej Knopp [EMAIL PROTECTED] To: users@wicket.apache.org Sent: Wednesday, October 17, 2007 2:15 PM Subject: Re: VisitChildren + IComponentResolver broken in beta 4? It depends on when you call the visitChildren method. The idea is that resolved components are on page only during page render. Otherwise they are removed from page. -Matej On 10/17/07, Juha Alatalo [EMAIL PROTECTED] wrote: In the JIRA issue following was commented: This doesn't seem to be a bug in Wicket. In fact, the bug was that it worked before. ... This new fix is kind of a show stopper for us. What actually is the idea of the componentResolver? Functions like visitChildren works for normally added component. Shouldn't those functions work also for components that are added using IComponentResolver as long as those are visible? - Juha Juha Alatalo wrote: https://issues.apache.org/jira/browse/WICKET-1077 - Juha Matej Knopp wrote: Please create a JIRA entry and assign the example to it. Thanks. -Matej On 10/15/07, Juha Alatalo [EMAIL PROTECTED] wrote: Hi, If the components are added on the page using ComponentResolver, visitChildren() method seems to be working incorrectly. Created following example which works in beta 3 but not in beta 4. http://download.syncrontech.com/public/VisitChildrenExample.zip - Juha - 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: hi questions about DateField, thanks!
I found the problem, it's because my Tomcat has confict severlet jar files...
thanks very much!
raybristol wrote:
Hi, I try to add a datefield to my page, accroding to the examples in
http://www.wicketstuff.org/wicket13/index.html
but I get a error and then I try to do it on a sperate page just for
testing but getting the same error:
type Exception report
message
description The server encountered an internal error () that prevented it
from fulfilling this request.
exception
javax.servlet.ServletException: Servlet execution threw an exception
note The full stack trace of the root cause is available in the Apache
Tomcat/6.0.14 logs.
However about error message doesn't tell me anything, and the code is
really simple:
java code:
public class DateFieldTest extends WebPage{
private Date date = new Date();
public DateFieldTest(){
Form form = new Form(form);
DateTextField dateTextField = new DateTextField(dateTextField, new
PropertyModel(this,
date), new StyleDateConverter(S-, true));
form.add(dateTextField);
dateTextField.add(new DatePicker());
add(form);
}
}
Html code:
?xml version=1.0 encoding=UTF-8?
html xmlns=http://www.w3.org/1999/xhtml;
head
titleWicket Examples - dates/title
/head
body
form wicket:id=form
input type=text wicket:id=dateTextField /
input type=submit value=submit /
/form
/body
/html
Thanks for this forum, I am getting lots help from here, many many thanks
again!
Ray
--
View this message in context:
http://www.nabble.com/hi-questions-about-DateField%2C-thanks%21-tf4635435.html#a13254937
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: StringResourceModel toString() changed in Beta4 - why??? Must use getString() now.
actually the check you should be doing is:
if (obj instanceof imodel) { return ((imodel)obj.getobject()).tostring(); }
that is the model contract and that is how it is used properly.
-igor
On 10/17/07, Jan Kriesten [EMAIL PROTECTED] wrote:
Hi Thomas,
The javadoc pretty clearly says that this is useful for debugging and
so on What lead you to believe this would always return a
user-readable string?
actually, I stumbled over this, too. I used StringResourceModel for
IChoiceRenderer- and IOptionRenderer-Lists (where one assumes String within
getDisplayValue/getIdValue). Now I have to do an
if( obj instanceof StringResourceModel )
return( ((StringResourceModel) obj).getString() );
whereas for all other cases I just return 'toString()'.
This wasn't a nice surprise actually.
Regards, --- Jan.
-
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: Portlet howto
Hello,
I have the beginning of a solution !
My code is based on Liferay's struts support with some adaptations.
At this time, Guestbook portlet sample is ok, and I've made a
modification in wicket to get Navomatic and other bookmarkablePage
working.
The main point is that Liferay want a new HttpServletRequest (from
theirs object) in ServletContextProvider implementation of
ServletContextProvider and we must copy the request's parameters from
the original request to the new one.
I translate also the "_wu" (WicketPortlet.WICKET_URL_PORTLET_PARAMETER)
parameter into differents parameters
You can have a look to my 3 classes at the end of this mail.
I've got a problem for all bookmarkablePage, because the argument are
encoded by Wicket, and Liferay encode it second time.
The parameter received is like
"%3Aorg.apache.wicket.examples.navomatic.Page2". So I add a call to
decode function from "org.apache.wicket.protocol.http.RequestUtils"
Here is my code modification (it's maybe possible to find a another
solution too)
in the class
"org.apache.wicket.protocol.http.request.WebRequestCodingStrategy",
method addBookmarkablePageParameters(final Request request, final
RequestParameters parameters)
(line : 521 / SVN revision : 585043)
I change from
final String[] components = Strings.split(requestString,
Component.PATH_SEPARATOR);
to
final String[] components =
Strings.split(RequestUtils.decode(requestString),Component.PATH_SEPARATOR);
(Note: I test it with jetspeed and it works)
The main remaining problem is about Ajax portlet. I have this Error :
===
15:38:53,248 ERROR [[default]:731] "Servlet.service()" pour la servlet
default a lanc une exception
java.lang.NullPointerException
at
org.apache.wicket.protocol.http.WebResponse.redirect(WebResponse.java:204)
at
org.apache.wicket.protocol.http.BufferedWebResponse.close(BufferedWebResponse.java:66)
at
org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:336)
at
org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:175)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:215)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:691)
at
org.apache.catalina.core.ApplicationDispatcher.doInclude(ApplicationDispatcher.java:594)
at
org.apache.catalina.core.ApplicationDispatcher.include(ApplicationDispatcher.java:505)
at
com.liferay.portlet.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:245)
at
com.liferay.portlet.PortletRequestDispatcherImpl.include(PortletRequestDispatcherImpl.java:87)
at
org.apache.wicket.protocol.http.portlet.WicketPortlet.processRequest(WicketPortlet.java:519)
at
org.apache.wicket.protocol.http.portlet.WicketPortlet.doView(WicketPortlet.java:416)
at javax.portlet.GenericPortlet.doDispatch(GenericPortlet.java:235)
()
===
How can I go forward ? any suggestion ?
===
Here is my 3 implementation classes :
===
package com.liferay.portlet;
import java.util.Map;
import javax.portlet.PortletConfig;
import javax.portlet.PortletException;
import javax.portlet.RenderRequest;
import javax.portlet.RenderResponse;
import org.apache.portals.bridges.common.PortletResourceURLFactory;
public class LiferayToPortalBridgePortletResourceURLFactory implements
PortletResourceURLFactory
{
public static final String WICKET_PREFIX =
"org.apache.wicket_";
public String createResourceURL( PortletConfig portletConfig,
RenderRequest renderRequest, RenderResponse renderResponse, Map
portletArg ) throws PortletException
{
String retval = "";
final long plid = ( (RenderResponseImpl)renderResponse
).getPlid();
final PortletURLImpl portletUrl = new PortletURLImpl(
(RenderRequestImpl)renderRequest, portletConfig.getPortletName(), plid,
true );
retval = portletUrl.toString();
return retval;
}
}
===
package com.liferay.portlet;
import java.io.IOException;
import java.util.Iterator;
import java.util.Map;
import javax.portlet.GenericPortlet;
import javax.portlet.PortletRequest;
import javax.portlet.PortletResponse;
import javax.servlet.ServletContext;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpServletResponse;
import org.apache.portals.bridges.common.ServletContextProvider;
import org.apache.wicket.protocol.http.portlet.WicketPortlet;
import com.liferay.portal.kernel.servlet.HttpHeaders;
import com.liferay.portal.kernel.util.ContentTypes;
import com.liferay.portlet.ActionRequestImpl;
import com.liferay.portlet.ActionResponseImpl;
import com.liferay.portlet.PortletContextImpl;
import com.liferay.portlet.RenderRequestImpl;
import com.liferay.portlet.RenderResponseImpl;
import
Re: StringResourceModel toString() changed in Beta4 - why??? Must use getString() now.
I also read documentation - it may have been on the Pro Wicket book.. I dont recall. Nonetheless I thought it was strange to also reley on toString().. but seeing documentation and examples of toString() pushed me into using it without much thought. And like I said this worked all the way back to Wicket 1.2 . I dont care what it is.. I'll refactor to getString(). It would just be nice to know ahead of time whats coming. Jan Kriesten wrote: Hi Thomas, Fair enough, was I reading more importance into the second sentence (useful for debugging...). I still would not rely on toString() for anything but debugging purposes unless someone passes me an object of a well known, final class right - but there are exceptions to rules. :-) In my case, the documentation for IChoiceRenderer.getIdValue() explicitely suggest using toString(). Anyway, clearifcation of the API or a return to the old behavior is needed: https://issues.apache.org/jira/browse/WICKET-1080 Regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/StringResourceModel-toString%28%29-changed-in-Beta4---why-Must-use-getString%28%29-now.-tf4638851.html#a13255680 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: Some help. I think I found a bug, but I am a wicket newbie anyway.
I fixed!!! It is working accurately now. Thanks a lot.
On 10/17/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
svn co https://svn.apache.org/repos/asf/wicket/trunk wicket
cd wicket
mvn install
-igor
On 10/16/07, Fernando Wermus [EMAIL PROTECTED] wrote:
I found a solution to my developing. I changed to beta 4 and that line
is
well formed, but I still have the panel in the wrong position. Testing a
little on the html, I realized that if I remove the height:0px from
the
div the page looks well. It seems as if Mozilla moved the panel because
of
that line.
I need some help. I need to recompile the wicket extracting the
height:0px
from the code and I am not used to recompile libraries. Could anyone
help me
on the issue?
Thanks a lot and in advance.
On 10/17/07, Fernando Wermus [EMAIL PROTECTED] wrote:
I have combine the signIn2 and the wizard for creating a new user. I
have
added both to my TabbedPanel. For some reason, the wizard appeared
wrongly
at the right when is clicked. This doesn't happen to the sigIn2. I
found
some strange html which I wanna share with you,
div
style=width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hi
ddeninput
So I don't know how to solve it. I am using wicket 1.3 beta 3. If I
remove
it from the html, I can see the page accurately. I googled this line
and I
found this wicket link
http://mail-archives.apache.org/mod_mbox/wicket-commits/200706.mbox/[EMAIL
PROTECTED]
this is where I add both of them in java. (it is mixed with some
spanish
words, I am sorry)
public PaginaSignIn(final PageParameters parameters)
{
ListAbstractTab solapas = new ArrayListAbstractTab();
solapas.add(new AbstractTab(new Model(Entrar)){
@Override
public Panel getPanel(String panelId) {
return new SolapaSignIn(panelId)
{
public boolean signIn(String username, String
password)
{
return
((SignIn2Session)getSession()).authenticate(username, password);
}
};
}
});
solapas.add(new AbstractTab(new Model(Nuevo usuario)){
@Override
public Panel getPanel(String panelId) {
return new NewUserWizard(panelId);
}
});
add(new TabbedPanel(tabs, solapas));
}
Part of the html rendered
div
class=wicketExtensionsWizard
form action=
?x=6-%3A0%3Atabs%3Apanel%3Aform%3A1%3AIFormSubmitListener%3A%3A
wicket:id=form class
=wicketExtensionsWizardForm method=post id=
form7
div style=display:none
input type=hidden name=form7_hf_0
id=form7_hf_0 /
/div
div
style=width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hiddeninput
type=text autocomplete=false
/input type=submit onclick=
var b=Wicket.$('next8'); if (typeof(b.onclick) != 'undefined')
{ var r = b.onclick.bind(this)(); if (r != false) b.click(); } else {
b.click(); }; return false;
/
/div
Thanks in advance
--
Fernando Wermus.
--
Fernando Wermus.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Fernando Wermus.
Re: Some help. I think I found a bug, but I am a wicket newbie anyway.
As you know I ve only changed the style in Form.java. I am using TabPanel
class, and if I switch to AjaxTabPanel doesn't work properly. For some
reason, the window Ajax debug close when I click in some panel. Anyway, I
will still use TabPanel with my fix. I don't know which is the connection
between changing the style (position:absolute; width:0; height:0) in a div
and AjaxTabPanel.
Bye!
On 10/17/07, Fernando Wermus [EMAIL PROTECTED] wrote:
I fixed!!! It is working accurately now. Thanks a lot.
On 10/17/07, Igor Vaynberg [EMAIL PROTECTED] wrote:
svn co https://svn.apache.org/repos/asf/wicket/trunk wicket
cd wicket
mvn install
-igor
On 10/16/07, Fernando Wermus [EMAIL PROTECTED] wrote:
I found a solution to my developing. I changed to beta 4 and that line
is
well formed, but I still have the panel in the wrong position. Testing
a
little on the html, I realized that if I remove the height:0px from
the
div the page looks well. It seems as if Mozilla moved the panel
because of
that line.
I need some help. I need to recompile the wicket extracting the
height:0px
from the code and I am not used to recompile libraries. Could anyone
help me
on the issue?
Thanks a lot and in advance.
On 10/17/07, Fernando Wermus [EMAIL PROTECTED] wrote:
I have combine the signIn2 and the wizard for creating a new user. I
have
added both to my TabbedPanel. For some reason, the wizard appeared
wrongly
at the right when is clicked. This doesn't happen to the sigIn2. I
found
some strange html which I wanna share with you,
div
style=width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hi
ddeninput
So I don't know how to solve it. I am using wicket 1.3 beta 3. If I
remove
it from the html, I can see the page accurately. I googled this line
and I
found this wicket link
http://mail-archives.apache.org/mod_mbox/wicket-commits/200706.mbox/[EMAIL
PROTECTED]
this is where I add both of them in java. (it is mixed with some
spanish
words, I am sorry)
public PaginaSignIn(final PageParameters parameters)
{
ListAbstractTab solapas = new ArrayListAbstractTab();
solapas.add(new AbstractTab(new Model(Entrar)){
@Override
public Panel getPanel(String panelId) {
return new SolapaSignIn(panelId)
{
public boolean signIn(String username, String
password)
{
return
((SignIn2Session)getSession()).authenticate(username, password);
}
};
}
});
solapas.add(new AbstractTab(new Model(Nuevo usuario)){
@Override
public Panel getPanel(String panelId) {
return new NewUserWizard(panelId);
}
});
add(new TabbedPanel(tabs, solapas));
}
Part of the html rendered
div
class=wicketExtensionsWizard
form action=
?x=6-%3A0%3Atabs%3Apanel%3Aform%3A1%3AIFormSubmitListener%3A%3A
wicket:id=form class
=wicketExtensionsWizardForm method=post id=
form7
div style=display:none
input type=hidden name=form7_hf_0
id=form7_hf_0 /
/div
div
style=width:0px;height:0px;position:absolute;left:-100px;top:-100px;overflow:hiddeninput
type=text autocomplete=false
/input type=submit onclick=
var b=Wicket.$('next8'); if (typeof(b.onclick) != 'undefined')
{ var r = b.onclick.bind(this)(); if (r != false) b.click(); } else {
b.click(); }; return false;
/
/div
Thanks in advance
--
Fernando Wermus.
--
Fernando Wermus.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Fernando Wermus.
--
Fernando Wermus.
(OT) Calendar UI?
A bit off-topic, but I need to port an event calendar on our site to Wicket (as part of our overall conversion). The backend stuff is all a piece of cake. But does anyone know of a good component or UI kit that will make a nice looking calendar UI easy? Something that looks like Google calendar would be good. Jeremy Thomerson -- sent from a wireless device - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
IFormValidator complaining...
I've got a page with a form with some checkboxes, and when one of the checkboxes is clicked, I make visible a settings panel (within the form). This panel itself has a form with a number of text fields, two of which are checked via a EqualInputValidator. The problem I have is that if I use the panel (I'm not cleat if it's show or submit) but then hide it again and submit the form, I get a warning: - IFormValidator in form `...optionsForm` depends on a component that has been removed from the page or is no longer visible. Offending component id `text1``. Are there any suggestions as to what the best approach might be? (Which might just be to accept the warning, as the case shouldn't happen often...) /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: VisitChildren + IComponentResolver broken in beta 4?
Hi, Well, I believe we can keep the component instance until the end of request and then clean it up in detach, would this help you? (it still wouldn't be the same as before the fix, as the instance was (supposed to be) cleaned during the next request, but this means keeping additional state for no good reason. I think for our case this could be perfect solution. We don't need the state after the render, the application is dependend on it only during it. Thanks, Ari S. -Matej On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: Hi, I'm afraid you dont' really get what IComponentResolver is for. The purpose is to allow creating components from markup for a very short span of time - basically while the components are rendered and they should be removed immediate afterwards. So if you call visitChildren from another component, the resolved component will not be available. Well. We have been using this from very early days of wicket without a problem. Also, there is no mention about this very short time in javadoc. Actually, if the autoAdded component was there previously for longer time and is now removed immediately this is a quite big change of behaviour if looking it from the application. What changed in beta 4 is that we now remove the component immediately after it's rendered (inside the autoAdd call) because otherwise It caused us a nasty memory leak. We have some rather large sites running with wicket 1.2 using autoAdd stuff, haven't noticed any huge leaks there. Couldn't you consider any other alternatives for fixing that leak instead of insisting that we are doing something so wrong ? I really like all these IWhateverNiceInterface -things in wicket. Usually, when there is a need in application architecture, wicket has had a nice interface to support it. But it seems that it is very easy to get yourself burnt when using them, since they tend to get either rewritten or their behaviour changes Which is not a problem for someone who writes a smaller web applications with just a couple of pages. But for someone who does larger ones, it's not so nice. Ari S. On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: Hi, But it looks like that in this case the visitChilder is performed during render, and it still won't find stuff added by autoAdd. It is not a very robust design if the behaviour of autoAdd/visitChilder would require some kind of component-hierarchy fine-tuning. This kind of approach might work with static-kind-of applications, but at least for us, the content in applications is very dynamic and interface like IComponentResolver has been very handy. Just a wild guess here - maybe the processing of IComponentResolver stuff was done earlier in beta3 than in beta4. Not getting this fixed can be pretty annoying for us - we have a couple of hundreds of pages done with wicket which rely on this. We could of course try to step back in time with svn to see which change has broken this, but I don't know how much sense it will make unless developers are not going to admit that this is a problem. Ari S. - Original Message - From: Matej Knopp [EMAIL PROTECTED] To: users@wicket.apache.org Sent: Wednesday, October 17, 2007 2:15 PM Subject: Re: VisitChildren + IComponentResolver broken in beta 4? It depends on when you call the visitChildren method. The idea is that resolved components are on page only during page render. Otherwise they are removed from page. -Matej On 10/17/07, Juha Alatalo [EMAIL PROTECTED] wrote: In the JIRA issue following was commented: This doesn't seem to be a bug in Wicket. In fact, the bug was that it worked before. ... This new fix is kind of a show stopper for us. What actually is the idea of the componentResolver? Functions like visitChildren works for normally added component. Shouldn't those functions work also for components that are added using IComponentResolver as long as those are visible? - Juha Juha Alatalo wrote: https://issues.apache.org/jira/browse/WICKET-1077 - Juha Matej Knopp wrote: Please create a JIRA entry and assign the example to it. Thanks. -Matej On 10/15/07, Juha Alatalo [EMAIL PROTECTED] wrote: Hi, If the components are added on the page using ComponentResolver, visitChildren() method seems to be working incorrectly. Created following example which works in beta 3 but not in beta 4. http://download.syncrontech.com/public/VisitChildrenExample.zip - Juha - 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
Re: VisitChildren + IComponentResolver broken in beta 4?
Hi, Well, I believe we can keep the component instance until the end of request and then clean it up in detach, would this help you? (it still wouldn't be the same as before the fix, as the instance was (supposed to be) cleaned during the next request, but this means keeping additional state for no good reason. I think for our case this could be perfect solution. We don't need the state after the render, the application is dependend on it only during it. Thanks, Ari S. -Matej On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: Hi, I'm afraid you dont' really get what IComponentResolver is for. The purpose is to allow creating components from markup for a very short span of time - basically while the components are rendered and they should be removed immediate afterwards. So if you call visitChildren from another component, the resolved component will not be available. Well. We have been using this from very early days of wicket without a problem. Also, there is no mention about this very short time in javadoc. Actually, if the autoAdded component was there previously for longer time and is now removed immediately this is a quite big change of behaviour if looking it from the application. What changed in beta 4 is that we now remove the component immediately after it's rendered (inside the autoAdd call) because otherwise It caused us a nasty memory leak. We have some rather large sites running with wicket 1.2 using autoAdd stuff, haven't noticed any huge leaks there. Couldn't you consider any other alternatives for fixing that leak instead of insisting that we are doing something so wrong ? I really like all these IWhateverNiceInterface -things in wicket. Usually, when there is a need in application architecture, wicket has had a nice interface to support it. But it seems that it is very easy to get yourself burnt when using them, since they tend to get either rewritten or their behaviour changes Which is not a problem for someone who writes a smaller web applications with just a couple of pages. But for someone who does larger ones, it's not so nice. Ari S. On 10/17/07, Ari Suutari [EMAIL PROTECTED] wrote: Hi, But it looks like that in this case the visitChilder is performed during render, and it still won't find stuff added by autoAdd. It is not a very robust design if the behaviour of autoAdd/visitChilder would require some kind of component-hierarchy fine-tuning. This kind of approach might work with static-kind-of applications, but at least for us, the content in applications is very dynamic and interface like IComponentResolver has been very handy. Just a wild guess here - maybe the processing of IComponentResolver stuff was done earlier in beta3 than in beta4. Not getting this fixed can be pretty annoying for us - we have a couple of hundreds of pages done with wicket which rely on this. We could of course try to step back in time with svn to see which change has broken this, but I don't know how much sense it will make unless developers are not going to admit that this is a problem. Ari S. - Original Message - From: Matej Knopp [EMAIL PROTECTED] To: users@wicket.apache.org Sent: Wednesday, October 17, 2007 2:15 PM Subject: Re: VisitChildren + IComponentResolver broken in beta 4? It depends on when you call the visitChildren method. The idea is that resolved components are on page only during page render. Otherwise they are removed from page. -Matej On 10/17/07, Juha Alatalo [EMAIL PROTECTED] wrote: In the JIRA issue following was commented: This doesn't seem to be a bug in Wicket. In fact, the bug was that it worked before. ... This new fix is kind of a show stopper for us. What actually is the idea of the componentResolver? Functions like visitChildren works for normally added component. Shouldn't those functions work also for components that are added using IComponentResolver as long as those are visible? - Juha Juha Alatalo wrote: https://issues.apache.org/jira/browse/WICKET-1077 - Juha Matej Knopp wrote: Please create a JIRA entry and assign the example to it. Thanks. -Matej On 10/15/07, Juha Alatalo [EMAIL PROTECTED] wrote: Hi, If the components are added on the page using ComponentResolver, visitChildren() method seems to be working incorrectly. Created following example which works in beta 3 but not in beta 4. http://download.syncrontech.com/public/VisitChildrenExample.zip - Juha - 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
is anybody using Wicket 1.3 and SiteMesh together?
Is anybody using Wicket 1.3 and SiteMesh together? http://www.opensymphony.com/sitemesh Sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: is anybody using Wicket 1.3 and SiteMesh together?
Why would you use SiteMesh, when wicket has such a nice templating? Sean Sullivan-3 wrote: Is anybody using Wicket 1.3 and SiteMesh together? http://www.opensymphony.com/sitemesh Sean - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/is-anybody-using-Wicket-1.3-and-SiteMesh-together--tf4642805.html#a13262181 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: redirect request for Page A to page B without contructing A?
Implemented a SimplePageAuthorizationStrategy; works but there is a gotcha:
Say the home page has a (non-ajax) login form:
1. unauthenticated users navigates to home page and is authorized
2. user submits valid login info.
3. At this point I'd assumed Home page would be re-requested (does wicket do
Redirect-after-form-submit?)
4. However, Home page is redisplayed and isAuthorized method is never
executed after form submit.
Workaround seems to be doing setResponsePage in onSubmit method. This,
however, seems to complicate creating a reusable LoginPanel which would
return user to same page.
-nikita
public class HomePageAuthorizationStrategy extends
SimplePageAuthorizationStrategy{
public HomePageAuthorizationStrategy(){
super(HomePage.class, ProfilePage.class);
}
/**
* if user's signed-in redirect request for Home Page to user's
dashboard/profile
*/
protected boolean isAuthorized() {
this.getLogger().info(checking auth for home page access...);
return ! ((MySession)Session.get()).isLoggedIn();
}
public Logger getLogger() {
return Logger.getLogger(this.getClass().getName());
}
}
Eelco Hillenius wrote:
If an already logged-in user types in our home URL we'd like the site to
redirect him/her to own profile page. If user's not logged in, they do
land
on home page. This is not to compel someone to sign in.
So, for example below, PageA = site home page; PageB = user's own profile
page
Sounds like a custom authorization strategy would work great here.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/redirect-request-for-Page-A-to-page-B-without-contructing-A--tf4636621.html#a13262795
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
[OT] Blocking, Persistent Queue suggestions?
A bit off-topic, as non-Wicket specific, but I'm stuck for ideas at the moment... I've got a simple servlet that gets requests and queues them for later asynch processing by a number of 'background' threads. The data's only a pair of short strings in each item, so I'm currently using an in-memory FIFO queue decorated by the Commons-Collections BufferUtils.blockingBuffer(). Now, however, I need to have the queue persist over a JVM restart maybe also to cap it's in-memory size. I've not been able to come up with anything that seems ideal, so I wondered if anyone had any suggestions. Has to run on JDK 1.4, by the way. Current options: - DB: e.g. HSQLDB. Maybe, seems a bit of overkill though - ehCache, wrapped somehow: Maybe, but haven't yet got a good way to present a cache as a FIFO queue... /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ajax question
I have a question that I hopefully someone will be able to answer. I have created a Wicket based framework on top of YUI Context menu in wicketstuff (menu2). Everything works as expected. It can be used on Tree/Table for those that are interested. However, the issue that I have come across is that the menu stops working when I send back the component that the contextmenu is listening on. I understand that the DOM has changed and the menu needs to be recreated to reestablish its association. What I don't know is what is the best way to reestablish the contextmenu. I resend the Javascript to recreate the menu but that doesn't work. Is there something that I am missing? How do I have the YUI ContextMenu (in Javascript) re-listen on the recently sent component? Thanks in advance, - Doug P.S. If you are interested in having a ContextMenu for your Wicket Application, please check out package org.wicketstuff.yui.markup.html.menu2.contextMenu. Please be aware that this is a work in progress but does work. There is also a working example in the wicketstuff-yui-examples. I hope to have an example for Tree up very soon. -- View this message in context: http://www.nabble.com/Ajax-question-tf4644668.html#a13267305 Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
