Re: Clearing Feedback Messages from the Session
that method has javadoc... -igor On Sat, Mar 15, 2008 at 9:41 PM, Warren [EMAIL PROTECTED] wrote: What is cleanupFeedbackMessages() used for ? -Original Message- From: Warren [mailto:[EMAIL PROTECTED] Sent: Saturday, March 15, 2008 9:37 PM To: users@wicket.apache.org Subject: RE: Clearing Feedback Messages from the Session That's what I was looking for, Thanks -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Saturday, March 15, 2008 8:38 PM To: users@wicket.apache.org Subject: Re: Clearing Feedback Messages from the Session message.markrendered() ? -igor On Sat, Mar 15, 2008 at 12:39 PM, Warren [EMAIL PROTECTED] wrote: I am displaying feedback messages using a js alert window instead of a feedback panel. Everything works except that I end up displaying the same message twice. Once for the original request and then again for the following request. I am retrieving the messages from the Session when the page's onBeforeRender() is called. I call getFeedbackMessages().messages(null) and then immediately call cleanupFeedbackMessages(). I basically am looking to duplicate what a feedback panel does. What do I need to do to clear all the messages from the Session after I retrieve them? Thanks, Warren Bell - 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: getPageParameters() NullPointer
Hi, I was actually trying to use getPageParameters() as well, and it was returning null too... The reason I want to use it is, I have a base page which adds a context panel fragment in the page, which it gets by an abstract method getContextPanel(). Now in the sub page I wanted to use the state that was set in the constructor using the page parameters to build my context panel. But this does not work: the constructor of my sub page has not been called yet... the stack is: MyPage.getContextPanel() BasePage.init() MyPage.init(PageParams params) So I figured, I'd use getPageParams() in my context panel and explicitly initialize the state as a (very ugly) workaround. (If we get multiple wicket:child in 1.4 this problem is completely and nicely solved). If anybody knows a nicer way to work around this, let me know. (I'm actually against using overridable methods in constructors... but I see no alternative). Anyway, checking the source code I noticed why getPageParams() returned null... I didn't do a super() call to my BasePage with the parameters, which in turn didn't do super() call to WebPage with the parameters... I just expected it to work. :-) Maybe it would be useful to explicitly state in the getPageParams() method JavaDoc that you explicitly need to call the super() with the page parameters. :-) Regards, Sebastiaan Martijn Dashorst wrote: OK, hangon... You need to define a constructor *taking* a pageparameters object. In that object you can find the parameters. Martijn On 1/22/08, Martijn Dashorst [EMAIL PROTECTED] wrote: Stating the obvious, but did you check if the parameter was actually present in the URL? Martijn On 1/22/08, Stephan Koch [EMAIL PROTECTED] wrote: Hi all, I'm experiencing a problem using getPageParameters(). The parameter id is passed to MyPage: setResponsePage(MyPage.class, new PageParameters(id=+evalId)); In the constructor of MyPage I try to access the parameter id: Integer evalId = Integer.parseInt(getPageParameters().getKey(id)); This fails with a NullPointerException. I thought the usage of PageParameters was pretty straightforward- did I miss something here? I'm using Wicket 1.3. Regards, Stephan - 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 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.0 smime.p7s Description: S/MIME Cryptographic Signature
Component.getPreferredTag()?
Is there any way to ask a component what its preferred tag type is? For instance, TextField would return input and DropDownChoice would return select. This would be useful if one were to want to dynamically generate a form (using Velocity) based on a list of Components (property editors). If there's no way to do it, I guess I could set up my own registry of sorts that allows me to register the preferred tag type for specific component types (classes). - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning Wicket Next Generation
+1 for moving to java 5 On Sun, Mar 16, 2008 at 12:45 AM, Gabor Szokoli [EMAIL PROTECTED] wrote: Hi, Your conclusion covers our case, but I'd debate your reasoning: We use java 5, deploy to GlassFish. No nostalgic attachments to pre-generics Java :-) But we believe these (including wicket) to be established technologies, and would hate to jump to significantly less mature platforms (like java 7 :-) ) Gabor Szokoli On 3/15/08, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I'd say people using wicket now who did not mind switching from other framework might not mind upgrading web server to java5 (even 7:-), or deploy it on a new web server instead of mixing them with the old app servers. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning Wicket Next Generation
On 3/16/08, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 for moving to java 5 +1 for moving to Java 5 *quickly* :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning Wicket Next Generation
java 5 now definitely On Sun, Mar 16, 2008 at 7:48 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 for moving to java 5 +1 for moving to Java 5 *quickly* :) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning Wicket Next Generation
+1 to java 5 atul singh wrote: java 5 now definitely On Sun, Mar 16, 2008 at 7:48 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 for moving to java 5 +1 for moving to Java 5 *quickly* :) - 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]
Models loosing their values problem with IE6/7 and Wicket 1.3.0-RC1
Hi, strange problem: when changing language in my app which is a Form done with Wicket 1.3.0-RC1, the Models loose their values when the browser is IE6/7. With Firefox everything is ok. Component streetaddress = get(customerInfo+:contactInfo+:streetaddress); String modelAsString = streetaddress.getModelObjectAsString(); This String is empty () when using IE6/7 but in FF it contains the correct value. Is there a bug, should I update Wicket to fix this issue? br, Marcus - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Models loosing their values problem with IE6/7 and Wicket 1.3.0-RC1
Update first, ask questions later. There are roughly 300 issues solved between your version and 1.3.2. Martijn On 3/16/08, Marcus Mattila [EMAIL PROTECTED] wrote: Hi, strange problem: when changing language in my app which is a Form done with Wicket 1.3.0-RC1, the Models loose their values when the browser is IE6/7. With Firefox everything is ok. Component streetaddress = get(customerInfo+:contactInfo+:streetaddress); String modelAsString = streetaddress.getModelObjectAsString(); This String is empty () when using IE6/7 but in FF it contains the correct value. Is there a bug, should I update Wicket to fix this issue? br, Marcus - 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.1 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: css menu and wicket
Thanks! This works. Just need some adjustments in the css :) -- View this message in context: http://www.nabble.com/css-menu-and-wicket-tp16062124p16079941.html 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: Planning Wicket Next Generation
Another YES for 1.5 Phil On Sun, Mar 16, 2008 at 10:12 AM, Maurice Marrink [EMAIL PROTECTED] wrote: +1 (non binding) for a quick x-m1 with only generics release Maurice On Sun, Mar 16, 2008 at 3:32 PM, Thijs [EMAIL PROTECTED] wrote: +1 to java 5 atul singh wrote: java 5 now definitely On Sun, Mar 16, 2008 at 7:48 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 for moving to java 5 +1 for moving to Java 5 *quickly* :) - 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] -- Phil Grimm Mobile: (858) 335-3426 Skype: philgrimm336
Autolinking Relative Paths
Suppose I have a package structure like this... com.mycompany.myproject --- module1 --- page - Page1.html --- module2 --- page - Page2.html If I want to autolink from Page1.html to Page2.html, it would look like: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link Correct? This doesn't appear to be working for me. I get a warning from AutolinkResolver: WARN - AutoLinkResolver - Did not find corresponding java class: .module2.page.Page2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning Wicket Next Generation
On Mar 16, 2008, at 16:58 , Phil Grimm wrote: Another YES for 1.5 Phil +1 -- Fabrizio Giudici, Ph.D. - Java Architect, Project Manager Tidalwave s.a.s. - We make Java work. Everywhere. weblogs.java.net/blog/fabriziogiudici - www.tidalwave.it/blog [EMAIL PROTECTED] - mobile: +39 348.150.6941 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Autolinking Relative Paths
That's funny, I was about to post regarding the numerous issues with wicket:link... And one suggestion I was going to give was to add support for ../packge/Page.html. I don't think it currently supports this, at least I couldn't see it from a code examination. Your only option, I believe, is to resort to absolute path... /com/mycompany/myproject/module1/page/Page1.html or .com.mycompany.myproject.module1.page.Page1.html This of course breaks if you refactor your packages. BTW, this absolute path syntax is not documented anywhere I could find. Not even in the WIA book. I found it only be going to the source. My thinking is that wicket:link works great if you keep all your pages in the same package, but has numerous issues if you separate your pages into their own packages, as I have done. I think the uber feature would be to have it search the entire classpath (if not found in the current pages package). This would solve the issue of wicket:link paths breaking when pages are refactored to other packages. Phil On Sun, Mar 16, 2008 at 11:07 AM, James Carman [EMAIL PROTECTED] wrote: Suppose I have a package structure like this... com.mycompany.myproject --- module1 --- page - Page1.html --- module2 --- page - Page2.html If I want to autolink from Page1.html to Page2.html, it would look like: wicket:link a href=../../module2/page/Page2.htmlClick Here!/a /wicket:link Correct? This doesn't appear to be working for me. I get a warning from AutolinkResolver: WARN - AutoLinkResolver - Did not find corresponding java class: .module2.page.Page2 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Grimm Mobile: (858) 335-3426 Skype: philgrimm336
Re: Autolinking Relative Paths
On 3/16/08, Phil Grimm [EMAIL PROTECTED] wrote: That's funny, I was about to post regarding the numerous issues with wicket:link... And one suggestion I was going to give was to add support for ../packge/Page.html. I don't think it currently supports this, at least I couldn't see it from a code examination. Ok, thanks, Phil. I thought I was doing it correctly. My HTML can be viewed in the browser for a preview just fine. Maybe we should file a JIRA enhancement request? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Autolinking Relative Paths
I think a JIRA request is appropriate. Perhaps we'll hear a confirmation from the Wicket developers. I'd add the following to the request... 1. Add support for ../ relative path resolution 2. Add support for searching the classpath (if absolute and relative search fails) -- I think this is reasonable, but there may be issues here -- This is the only way to have wicket:link paths continue to work even after refactoring pages/packages. 3. Document the valid path syntax (and limitations) in the Wiki, WIA, etc. Phil On Sun, Mar 16, 2008 at 11:46 AM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Phil Grimm [EMAIL PROTECTED] wrote: That's funny, I was about to post regarding the numerous issues with wicket:link... And one suggestion I was going to give was to add support for ../packge/Page.html. I don't think it currently supports this, at least I couldn't see it from a code examination. Ok, thanks, Phil. I thought I was doing it correctly. My HTML can be viewed in the browser for a preview just fine. Maybe we should file a JIRA enhancement request? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Grimm Mobile: (858) 335-3426 Skype: philgrimm336
Re: Autolinking Relative Paths
On 3/16/08, Phil Grimm [EMAIL PROTECTED] wrote: I think a JIRA request is appropriate. Perhaps we'll hear a confirmation from the Wicket developers. I'd add the following to the request... 1. Add support for ../ relative path resolution +1 - This is essential and shouldn't be very difficult, IMHO (without looking at the code). A few unit tests should verify this behavior. I might even submit the patch myself. 2. Add support for searching the classpath (if absolute and relative search fails) -- I think this is reasonable, but there may be issues here -- This is the only way to have wicket:link paths continue to work even after refactoring pages/packages. I don't know about this. In my IDE (IntelliJ IDEA), if I move the HTML template, the links in my other pages automatically get updated. So, this is a non-issue for me. Also, pages could be named the same thing in multiple packages. For instance, suppose you have a project with multiple modules (customers, inventory, accounts, etc.). Each module could have its own HomePage. 3. Document the valid path syntax (and limitations) in the Wiki, WIA, etc. +1 - but it should at least be in the Wiki, though. I remember getting frustrated when seeing replies on the Tapestry lists that said Buy Kent Tong's book. Don't get me wrong, his book was/is good, but having to pay for documentation for an Apache project just seems wrong to me. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Component.getPreferredTag()?
no there isnt such a thing. usually the beanstuff we have done uses some metadata to generate both markup and components...there is wicket-stuff-crud project that generates crud views based on a bean...maybe look into that for inspiration -igor On Sun, Mar 16, 2008 at 7:02 AM, James Carman [EMAIL PROTECTED] wrote: Is there any way to ask a component what its preferred tag type is? For instance, TextField would return input and DropDownChoice would return select. This would be useful if one were to want to dynamically generate a form (using Velocity) based on a list of Components (property editors). If there's no way to do it, I guess I could set up my own registry of sorts that allows me to register the preferred tag type for specific component types (classes). - 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: Planning Wicket Next Generation
its binding now... -igor On Sun, Mar 16, 2008 at 8:12 AM, Maurice Marrink [EMAIL PROTECTED] wrote: +1 (non binding) for a quick x-m1 with only generics release Maurice On Sun, Mar 16, 2008 at 3:32 PM, Thijs [EMAIL PROTECTED] wrote: +1 to java 5 atul singh wrote: java 5 now definitely On Sun, Mar 16, 2008 at 7:48 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 for moving to java 5 +1 for moving to Java 5 *quickly* :) - 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]
Pagination Problems
In our application we have three basic pages: - search page - results page - details page Search page has a form with all of the search criteria. On submit, the search is saved to the database and response page is set to the results page, with the ID of the search as a page parameter. The results page gets the ID page parameter, gets the search object from the database, and uses a GridView to display results from an IDataProvider. We use pagination as there can be many hundreds of results. A small overview of each item is displayed on results page, and it links to that item's details page. So far, all of this works perfectly. The pagination links on results pages work fine, until I go to an item's details page then hit Back in the browser to get back to results page. After I hit Back, all of the pagination links are broken. Clicking any of them takes me back to first page of results. We're using both PagingNavigationIncrementLink to generate next previous links, as well as PagingNavigation to generate links to specific pages of results. All of those links, after viewing details page and hitting Back, take me to first page of results, no matter which page I'm currently on. I'm sure I'm just not understanding something about the state that Wicket stores on the server, but does anyone know why the pagination links don't work after viewing the details page and then hitting Back? Thanks, Zach - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Autolinking Relative Paths
you guys do both realize that wicket:link is nothing more then convinience. it isnt really meant to support all these complex usecases. it is nice when you need to quickly include an image or link to a near by page, but nothing more then that. -igor On Sun, Mar 16, 2008 at 10:24 AM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Phil Grimm [EMAIL PROTECTED] wrote: I think a JIRA request is appropriate. Perhaps we'll hear a confirmation from the Wicket developers. I'd add the following to the request... 1. Add support for ../ relative path resolution +1 - This is essential and shouldn't be very difficult, IMHO (without looking at the code). A few unit tests should verify this behavior. I might even submit the patch myself. 2. Add support for searching the classpath (if absolute and relative search fails) -- I think this is reasonable, but there may be issues here -- This is the only way to have wicket:link paths continue to work even after refactoring pages/packages. I don't know about this. In my IDE (IntelliJ IDEA), if I move the HTML template, the links in my other pages automatically get updated. So, this is a non-issue for me. Also, pages could be named the same thing in multiple packages. For instance, suppose you have a project with multiple modules (customers, inventory, accounts, etc.). Each module could have its own HomePage. 3. Document the valid path syntax (and limitations) in the Wiki, WIA, etc. +1 - but it should at least be in the Wiki, though. I remember getting frustrated when seeing replies on the Tapestry lists that said Buy Kent Tong's book. Don't get me wrong, his book was/is good, but having to pay for documentation for an Apache project just seems wrong to me. - 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: Autolinking Relative Paths
On 3/16/08, Igor Vaynberg [EMAIL PROTECTED] wrote: you guys do both realize that wicket:link is nothing more then convinience. it isnt really meant to support all these complex usecases. it is nice when you need to quickly include an image or link to a near by page, but nothing more then that. The usecase we're talking about is hardly complex. Nor is it unreasonable to think that wicket:link should be able to handle it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Autolinking Relative Paths
Yeah, as a new user to Wicket, I just see it as another feature of Wicket. There's no issues with it, if all your pages are in the same package. Is that what most Wicket developers do? I agree that searching the classpath could be problematic and more involved to implement. But, the ../ support seems reasonable and would really help when you'd otherwise have to resort to full absolute paths (which it seems to me is most the time). In general, if a framework allows things to break easily when refactoring occurs, this is not good. BTW, NetBeans (even with the Wicket plugin) does not fix the paths when I refactor the package name. It's nice that IDEA does. NetBeans kinda blows (buggy as hell), but I'm stuck with it for now :( Phil On Sun, Mar 16, 2008 at 1:21 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Igor Vaynberg [EMAIL PROTECTED] wrote: you guys do both realize that wicket:link is nothing more then convinience. it isnt really meant to support all these complex usecases. it is nice when you need to quickly include an image or link to a near by page, but nothing more then that. The usecase we're talking about is hardly complex. Nor is it unreasonable to think that wicket:link should be able to handle it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Grimm Mobile: (858) 335-3426 Skype: philgrimm336
Re: Autolinking Relative Paths
On 3/16/08, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Igor Vaynberg [EMAIL PROTECTED] wrote: you guys do both realize that wicket:link is nothing more then convinience. it isnt really meant to support all these complex usecases. it is nice when you need to quickly include an image or link to a near by page, but nothing more then that. The usecase we're talking about is hardly complex. Nor is it unreasonable to think that wicket:link should be able to handle it. In fact, I believe I already have a patch that fixes it. I'll create a JIRA and attach the patch. You folks can discuss whether it is worthy or not to make it into core. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Autolinking Relative Paths
On 3/16/08, James Carman [EMAIL PROTECTED] wrote: In fact, I believe I already have a patch that fixes it. I'll create a JIRA and attach the patch. You folks can discuss whether it is worthy or not to make it into core. For future reference, I've created: https://issues.apache.org/jira/browse/WICKET-1428 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Autolinking Relative Paths
../ syntax is just as prone to refactoring errors as the absolute path, so i dont buy that argument -igor On Sun, Mar 16, 2008 at 11:51 AM, Phil Grimm [EMAIL PROTECTED] wrote: Yeah, as a new user to Wicket, I just see it as another feature of Wicket. There's no issues with it, if all your pages are in the same package. Is that what most Wicket developers do? I agree that searching the classpath could be problematic and more involved to implement. But, the ../ support seems reasonable and would really help when you'd otherwise have to resort to full absolute paths (which it seems to me is most the time). In general, if a framework allows things to break easily when refactoring occurs, this is not good. BTW, NetBeans (even with the Wicket plugin) does not fix the paths when I refactor the package name. It's nice that IDEA does. NetBeans kinda blows (buggy as hell), but I'm stuck with it for now :( Phil On Sun, Mar 16, 2008 at 1:21 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Igor Vaynberg [EMAIL PROTECTED] wrote: you guys do both realize that wicket:link is nothing more then convinience. it isnt really meant to support all these complex usecases. it is nice when you need to quickly include an image or link to a near by page, but nothing more then that. The usecase we're talking about is hardly complex. Nor is it unreasonable to think that wicket:link should be able to handle it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Grimm Mobile: (858) 335-3426 Skype: philgrimm336 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
TreeTable with ajax markupId problem
Hi,
I'm developing an application in which I'm using the TreeTable component.
My table contains the table (nodes) and 7 other columns which are
TextField's in
which users may enter data. OnBlur on the TextFields updates the model:
public EditablePanel(MarkupContainer parent, String id, final IModel
inputModel, final TreeTable treeTable, final TreeNode treeNode)
{
super(id);
setOutputMarkupId(true);
final TextField field = new TextField(textfield, inputModel);
field.setOutputMarkupId(true);
field.add(new AttributeAppender(size, new Model(2), ));
add(field);
field.add(new AjaxFormComponentUpdatingBehavior(onblur)
{
protected void onUpdate(AjaxRequestTarget target)
{
((DefaultTreeModel)treeTable.getModelObject()).nodeChanged(treeNode);
treeTable.updateTree(target);
target.focusComponent(field);
}
});
}
Since I update the components in the Ajax response, I thought I could set
the focus
on the component (input) I just updated, but it seems the Ajax response has
given
the components new markupId's and hence, the line:
target.focusComponent(field)
Is pretty much useless as the id's in the HTML has been altered (by Ajax
response),
and the input with the old id is no longer on the page.
I dont quite know how to get the new markupId's, anyone?
Cheers, Lars Borup Jensen
--
Lars Borup Jensen
http://www.it-arbejde.dk
Re: Planning Wicket Next Generation
+1 for Java 5 Generics On Sun, Mar 16, 2008 at 11:03 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: its binding now... -igor On Sun, Mar 16, 2008 at 8:12 AM, Maurice Marrink [EMAIL PROTECTED] wrote: +1 (non binding) for a quick x-m1 with only generics release Maurice On Sun, Mar 16, 2008 at 3:32 PM, Thijs [EMAIL PROTECTED] wrote: +1 to java 5 atul singh wrote: java 5 now definitely On Sun, Mar 16, 2008 at 7:48 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 for moving to java 5 +1 for moving to Java 5 *quickly* :) - 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] -- Scott Swank reformed mathematician - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
A model driven visibility. Howto?
Hi everyone, How to implement a model driven visibility? Are there any best practices? Should I use the AttributeModifier to set a style visibility attribute or there is a better way? Vitaly - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Ajax problem with RequiredTextField in IE6/7
Martijn, you're right. Probably not so thankful to fix bugs if people
then uses old versions and complain :). Ok, I tried in 1.3.2 and get
the same problem with IE. Problem seems to be Ajax. Before changing
language
in my app, everything works fine and inputting data to a field
generates the following in Wicket Ajax Debug Window:
INFO:
INFO: Initiating Ajax POST request on
?wicket:interface=:3:xyzQuestionnaireForm:customerInfo:contactInfo:streetaddress::IBehaviorListener:0:random=0.202408963724586
INFO: Invoking pre-call handler(s)...
INFO: Received ajax response (1897 characters)
INFO:
?xml version=1.0
encoding=UTF-8?ajax-responseheader-contribution
encoding=wicket1 ![CDATA[head
xmlns:wicket=http://wicket.apache.org;script type=text/javascript
src=resources/org.apache.wicket.markup.html.WicketEventReference/wicket-event.js/script
script type=text/javascript
src=resources/org.apache.wicket.ajax.WicketAjaxReference/wicket-ajax.js/script
script type=text/javascript
src=resources/org.apache.wicket.ajax.AbstractDefaultAjaxBehavior/wicket-ajax-debug.js/script
script type=text/javascript
id=wicket-ajax-debug-enable!--/*--![CDATA[/*!--*/
wicketAjaxDebugEnable=true;
/*--]^]^*//script
/head]]/header-contributioncomponent id=sendButton66
encoding=wicket1 ![CDATA[input value=Lähetä lomake
type=submit class=sendButton onclick=var
wcall=wicketSubmitFormById('xyzQuestionnaireForme',
'?wicket:interface=:3:xyzQuestionnaireForm:sendButton::IActivePageBehaviorListener:0:-1wicket:ignoreIfNotActive=true',
'sendButton' ,null,null, function() {return
Wicket.$$(this)Wicket.$$('xyzQuestionnaireForme')}.bind(this));;;
return false; name=sendButton id=sendButton66/script
type=text/javascript!--/*--![CDATA[/*!--*/
document.getElementById('sendButton66').disabled = true
/*--]^]^*//script
]]/componentcomponent id=validationMessagePanel63
encoding=wicket1 ![CDATA[div class=validationMessage
id=validationMessagePanel63Ole hyvä ja täytä lomakkeen vaaditut
kentät ennen lomakkeen lähettämistä. Vaaditut kentät on osoitettu
*-merkillä ja keltaisella taustavärillä.
/divscript type=text/javascript!--/*--![CDATA[/*!--*/
document.getElementById('validationMessagePanel63').style.display='block';
/*--]^]^*//script
]]/componentevaluate![CDATA[document.getElementById('streetaddress16').className='
';]]/evaluate/ajax-response
INFO: Response parsed. Now invoking steps...
INFO: Response processed successfully.
INFO: Invoking post-call handler(s)...
INFO: last focus id was not set
After changing language, the Ajax request does not launch. Obviously,
something is messing up it up. Problem is only with IE, Firefox works
fine. Any ideas?
Thanks!
-Marcus
On Sun, Mar 16, 2008 at 4:35 PM, Martijn Dashorst
[EMAIL PROTECTED] wrote:
Update first, ask questions later. There are roughly 300 issues solved
between your version and 1.3.2.
Martijn
On 3/16/08, Marcus Mattila [EMAIL PROTECTED] wrote:
Hi,
strange problem: when changing language in my app which is a Form done
with Wicket 1.3.0-RC1, the Models loose their values when the browser
is IE6/7. With Firefox everything is ok.
Component streetaddress =
get(customerInfo+:contactInfo+:streetaddress);
String modelAsString = streetaddress.getModelObjectAsString();
This String is empty () when using IE6/7 but in FF it contains the
correct value. Is there a bug, should I update Wicket to fix this
issue?
br,
Marcus
-
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.1 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.1
-
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: A model driven visibility. Howto?
@override boolean isVisible() {
return ((MyClass)getModelObject()).isSomeValueSet();
}
On 3/16/08, Vitaly Tsaplin [EMAIL PROTECTED] wrote:
Hi everyone,
How to implement a model driven visibility? Are there any best
practices? Should I use the AttributeModifier to set a style
visibility attribute or there is a better way?
Vitaly
-
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.2 is released
Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.2
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Autolinking Relative Paths
Well, ../ path it's slightly more tolerant to refactoring. You can change anything that comes before the ../ without needing to touch HTML files. So Igor, do you always use absolute paths? I'm thinking that's what I'll use, since the limited relative path support only works when the current page is above the destination (in the path), which for my package scheme is never. -Phil On Sun, Mar 16, 2008 at 2:31 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: ../ syntax is just as prone to refactoring errors as the absolute path, so i dont buy that argument -igor On Sun, Mar 16, 2008 at 11:51 AM, Phil Grimm [EMAIL PROTECTED] wrote: Yeah, as a new user to Wicket, I just see it as another feature of Wicket. There's no issues with it, if all your pages are in the same package. Is that what most Wicket developers do? I agree that searching the classpath could be problematic and more involved to implement. But, the ../ support seems reasonable and would really help when you'd otherwise have to resort to full absolute paths (which it seems to me is most the time). In general, if a framework allows things to break easily when refactoring occurs, this is not good. BTW, NetBeans (even with the Wicket plugin) does not fix the paths when I refactor the package name. It's nice that IDEA does. NetBeans kinda blows (buggy as hell), but I'm stuck with it for now :( Phil On Sun, Mar 16, 2008 at 1:21 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Igor Vaynberg [EMAIL PROTECTED] wrote: you guys do both realize that wicket:link is nothing more then convinience. it isnt really meant to support all these complex usecases. it is nice when you need to quickly include an image or link to a near by page, but nothing more then that. The usecase we're talking about is hardly complex. Nor is it unreasonable to think that wicket:link should be able to handle it. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Grimm Mobile: (858) 335-3426 Skype: philgrimm336 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Phil Grimm Mobile: (858) 335-3426 Skype: philgrimm336
Re: Autolinking Relative Paths
On Sun, Mar 16, 2008 at 2:48 PM, Phil Grimm [EMAIL PROTECTED] wrote: So Igor, do you always use absolute paths? i only use wicket:link for trivial cases. for example, if one of my components needs to display an image or include a js file that lives next to it -igor - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Planning Wicket Next Generation
+1 for Java 5 Generics - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Planning Wicket Next Generation
I have been surprised that we have not had a single person say that they still require 1.4. Although I was originally against dropping 1.3 if we did a quick 1.4 (because I assumed there'd be many who still needed Java 1.4), perhaps we should open this up on the users list and get a more accurate feel for it. Judging only by the response on this list, we could release a 1.4 that was 1.3 + generics and drop support for 1.3. But I imagine that there will still be some that need Java 1.4. Jeremy Thomerson -- sent from a wireless device -Original Message- From: Scott Swank [EMAIL PROTECTED] To: users@wicket.apache.org Sent: 3/16/08 4:45 PM Subject: Re: Planning Wicket Next Generation +1 for Java 5 Generics On Sun, Mar 16, 2008 at 11:03 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: its binding now... -igor On Sun, Mar 16, 2008 at 8:12 AM, Maurice Marrink [EMAIL PROTECTED] wrote: +1 (non binding) for a quick x-m1 with only generics release Maurice On Sun, Mar 16, 2008 at 3:32 PM, Thijs [EMAIL PROTECTED] wrote: +1 to java 5 atul singh wrote: java 5 now definitely On Sun, Mar 16, 2008 at 7:48 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 for moving to java 5 +1 for moving to Java 5 *quickly* :) - 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] -- Scott Swank reformed mathematician - 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: Planning Wicket Next Generation
Those people who do are still in struts 1.x mode. And thats what ... ? 85% of the commercial java world ? ... i hear lots of those are moving to JSF ... **sigh** =( On Sun, Mar 16, 2008 at 6:16 PM, Jeremy Thomerson [EMAIL PROTECTED] wrote: I have been surprised that we have not had a single person say that they still require 1.4. Although I was originally against dropping 1.3 if we did a quick 1.4 (because I assumed there'd be many who still needed Java 1.4), perhaps we should open this up on the users list and get a more accurate feel for it. Judging only by the response on this list, we could release a 1.4 that was 1.3 + generics and drop support for 1.3. But I imagine that there will still be some that need Java 1.4. Jeremy Thomerson -- sent from a wireless device -Original Message- From: Scott Swank [EMAIL PROTECTED] To: users@wicket.apache.org Sent: 3/16/08 4:45 PM Subject: Re: Planning Wicket Next Generation +1 for Java 5 Generics On Sun, Mar 16, 2008 at 11:03 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: its binding now... -igor On Sun, Mar 16, 2008 at 8:12 AM, Maurice Marrink [EMAIL PROTECTED] wrote: +1 (non binding) for a quick x-m1 with only generics release Maurice On Sun, Mar 16, 2008 at 3:32 PM, Thijs [EMAIL PROTECTED] wrote: +1 to java 5 atul singh wrote: java 5 now definitely On Sun, Mar 16, 2008 at 7:48 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 for moving to java 5 +1 for moving to Java 5 *quickly* :) - 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] -- Scott Swank reformed mathematician - 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] -- Regards Vyas, Anirudh || ॐ ||
Re: Planning Wicket Next Generation
it was already on the user list On Sun, Mar 16, 2008 at 11:16 PM, Jeremy Thomerson [EMAIL PROTECTED] wrote: I have been surprised that we have not had a single person say that they still require 1.4. Although I was originally against dropping 1.3 if we did a quick 1.4 (because I assumed there'd be many who still needed Java 1.4), perhaps we should open this up on the users list and get a more accurate feel for it. Judging only by the response on this list, we could release a 1.4 that was 1.3 + generics and drop support for 1.3. But I imagine that there will still be some that need Java 1.4. Jeremy Thomerson -- sent from a wireless device -Original Message- From: Scott Swank [EMAIL PROTECTED] To: users@wicket.apache.org Sent: 3/16/08 4:45 PM Subject: Re: Planning Wicket Next Generation +1 for Java 5 Generics On Sun, Mar 16, 2008 at 11:03 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: its binding now... -igor On Sun, Mar 16, 2008 at 8:12 AM, Maurice Marrink [EMAIL PROTECTED] wrote: +1 (non binding) for a quick x-m1 with only generics release Maurice On Sun, Mar 16, 2008 at 3:32 PM, Thijs [EMAIL PROTECTED] wrote: +1 to java 5 atul singh wrote: java 5 now definitely On Sun, Mar 16, 2008 at 7:48 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 for moving to java 5 +1 for moving to Java 5 *quickly* :) - 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] -- Scott Swank reformed mathematician - 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: Planning Wicket Next Generation
DOH! Pitfall of keeping up with the dev and users lists on my phone - sometimes I miss something - I was thinking this discussion was on the dev list (should've scrolled up and double-checked). Either way, that actually lends more probability to us being able to do a quick 1.4 and drop 1.3. What do the core developers think? Jeremy Thomerson -- sent from a wireless device -Original Message- From: Johan Compagner [EMAIL PROTECTED] To: users@wicket.apache.org Sent: 3/16/08 6:34 PM Subject: Re: Planning Wicket Next Generation it was already on the user list On Sun, Mar 16, 2008 at 11:16 PM, Jeremy Thomerson [EMAIL PROTECTED] wrote: I have been surprised that we have not had a single person say that they still require 1.4. Although I was originally against dropping 1.3 if we did a quick 1.4 (because I assumed there'd be many who still needed Java 1.4), perhaps we should open this up on the users list and get a more accurate feel for it. Judging only by the response on this list, we could release a 1.4 that was 1.3 + generics and drop support for 1.3. But I imagine that there will still be some that need Java 1.4. Jeremy Thomerson -- sent from a wireless device -Original Message- From: Scott Swank [EMAIL PROTECTED] To: users@wicket.apache.org Sent: 3/16/08 4:45 PM Subject: Re: Planning Wicket Next Generation +1 for Java 5 Generics On Sun, Mar 16, 2008 at 11:03 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: its binding now... -igor On Sun, Mar 16, 2008 at 8:12 AM, Maurice Marrink [EMAIL PROTECTED] wrote: +1 (non binding) for a quick x-m1 with only generics release Maurice On Sun, Mar 16, 2008 at 3:32 PM, Thijs [EMAIL PROTECTED] wrote: +1 to java 5 atul singh wrote: java 5 now definitely On Sun, Mar 16, 2008 at 7:48 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 for moving to java 5 +1 for moving to Java 5 *quickly* :) - 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] -- Scott Swank reformed mathematician - 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] --=_Part_13704_23495408.1205706851286-- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning Wicket Next Generation
Personally all my projects are on java 1.5 at least, so I would love to have a quick 1.4 release and drop 1.3. But that's just me. -igor On 3/16/08, Jeremy Thomerson [EMAIL PROTECTED] wrote: DOH! Pitfall of keeping up with the dev and users lists on my phone - sometimes I miss something - I was thinking this discussion was on the dev list (should've scrolled up and double-checked). Either way, that actually lends more probability to us being able to do a quick 1.4 and drop 1.3. What do the core developers think? Jeremy Thomerson -- sent from a wireless device -Original Message- From: Johan Compagner [EMAIL PROTECTED] To: users@wicket.apache.org Sent: 3/16/08 6:34 PM Subject: Re: Planning Wicket Next Generation it was already on the user list On Sun, Mar 16, 2008 at 11:16 PM, Jeremy Thomerson [EMAIL PROTECTED] wrote: I have been surprised that we have not had a single person say that they still require 1.4. Although I was originally against dropping 1.3 if we did a quick 1.4 (because I assumed there'd be many who still needed Java 1.4), perhaps we should open this up on the users list and get a more accurate feel for it. Judging only by the response on this list, we could release a 1.4 that was 1.3 + generics and drop support for 1.3. But I imagine that there will still be some that need Java 1.4. Jeremy Thomerson -- sent from a wireless device -Original Message- From: Scott Swank [EMAIL PROTECTED] To: users@wicket.apache.org Sent: 3/16/08 4:45 PM Subject: Re: Planning Wicket Next Generation +1 for Java 5 Generics On Sun, Mar 16, 2008 at 11:03 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: its binding now... -igor On Sun, Mar 16, 2008 at 8:12 AM, Maurice Marrink [EMAIL PROTECTED] wrote: +1 (non binding) for a quick x-m1 with only generics release Maurice On Sun, Mar 16, 2008 at 3:32 PM, Thijs [EMAIL PROTECTED] wrote: +1 to java 5 atul singh wrote: java 5 now definitely On Sun, Mar 16, 2008 at 7:48 PM, James Carman [EMAIL PROTECTED] wrote: On 3/16/08, Maarten Bosteels [EMAIL PROTECTED] wrote: +1 for moving to java 5 +1 for moving to Java 5 *quickly* :) - 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] -- Scott Swank reformed mathematician - 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] --=_Part_13704_23495408.1205706851286-- - 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: Planning Wicket Next Generation
FWIW +1 to java5 and 1.3. Generics == joy, especially with the model stuff wicket uses :) igor.vaynberg wrote: Personally all my projects are on java 1.5 at least, so I would love to have a quick 1.4 release and drop 1.3. But that's just me. -igor -- View this message in context: http://www.nabble.com/Re%3A-Planning-Wicket-Next-Generation-tp16069837p16087952.html Sent from the Wicket - User mailing list archive at Nabble.com. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Finding the cause of an Exception
Can anybody suggest how I can try to resolve my StreamCorruptedException? I have an autocomplete text field. When I hit the back button and modify the text, I get the said Exception. I've tried stepping through the code, but the error is not obvious at all. The error only happens with the autocomplete widget (i.e. when I modify the text in the related text box). Nothing else (different query or use of controls or links) triggers this Exception. Thanks! Dave java.lang.RuntimeException: Could not deserialize object using `org.apache.wicket.util.io.IObjectStreamFactory $DefaultObjectStreamFactory` object factory at org.apache.wicket.util.lang.Objects.byteArrayToObject(Objects.java:406) at org.apache.wicket.protocol.http.pagestore.AbstractPageStore.deserializePage(AbstractPageStore.java:228) at org.apache.wicket.protocol.http.pagestore.DiskPageStore.getPage(DiskPageStore.java:702) at org.apache.wicket.protocol.http.SecondLevelCacheSessionStore $SecondLevelCachePageMap.get(SecondLevelCacheSessionStore.java:311) at org.apache.wicket.Session.getPage(Session.java:745) at org.apache.wicket.request.AbstractRequestCycleProcessor.resolveRenderedPage(AbstractRequestCycleProcessor.java:443) at org.apache.wicket.protocol.http.WebRequestCycleProcessor.resolve(WebRequestCycleProcessor.java:139) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1224) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1316) at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354) at org.apache.wicket.protocol.http.WicketServlet.doGet(WicketServlet.java:121) at javax.servlet.http.HttpServlet.service(HttpServlet.java:707) at javax.servlet.http.HttpServlet.service(HttpServlet.java:820) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:487) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:367) at org.ops4j.pax.web.service.internal.HttpServiceHandler.handle(HttpServiceHandler.java:66) at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:181) at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:712) at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:139) at org.mortbay.jetty.Server.handle(Server.java:285) at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:502) at org.mortbay.jetty.HttpConnection $RequestHandler.headerComplete(HttpConnection.java:821) at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:513) at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:208) at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:378) at org.mortbay.jetty.bio.SocketConnector $Connection.run(SocketConnector.java:226) at org.mortbay.thread.BoundedThreadPool $PoolThread.run(BoundedThreadPool.java:442) Caused by: java.io.StreamCorruptedException at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1332) at java.io.ObjectInputStream.defaultReadFields(ObjectInputStream.java:1908) at java.io.ObjectInputStream.readSerialData(ObjectInputStream.java:1832) at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1719) at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1305) at java.io.ObjectInputStream.readObject(ObjectInputStream.java:348) at org.apache.wicket.util.lang.Objects.byteArrayToObject(Objects.java:392) ... 27 more - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning Wicket Next Generation
On Sun, Mar 16, 2008 at 9:32 PM, Ned Collyer [EMAIL PROTECTED] wrote: FWIW +1 to java5 and 1.3. Generics == joy, especially with the model stuff wicket uses :) Same here; would like to see generics. Enrique - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Planning Wicket Next Generation
So far, no one has said they need Java 1.4. So, how do we request that a vote is started for this? Option A - Generics go in 1.4-M1, we still support 1.3, and 1.4 will be the next big-feature release, many months from now Option B - Generics *are *1.4, we drop support for 1.3 (and Java 1.4), and 1.5 will be the next big-feature release, many months from now. Thank you, Jeremy Thomerson On Sun, Mar 16, 2008 at 11:44 PM, Enrique Rodriguez [EMAIL PROTECTED] wrote: On Sun, Mar 16, 2008 at 9:32 PM, Ned Collyer [EMAIL PROTECTED] wrote: FWIW +1 to java5 and 1.3. Generics == joy, especially with the model stuff wicket uses :) Same here; would like to see generics. Enrique - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
