Re: Weird exceptions. Has anyone seen any exceptions like these
In 1.3.4 this error shouldnt happen, it is just ignored On 6/1/08, atul singh [EMAIL PROTECTED] wrote: Hi, As a result of code integration from various teams we have introduced some change which is causing problems... but the sad part is that we do not know what is happening-- I will loove to know if someone else has seen similar exceptions and how they solved if they were able to:: Also what do these exceptions mean--i mean situation they might happen in?? 1. java.lang.IllegalStateException: No Page found for component [MarkupContainer [Component id = panel, page = No Page, path = at org.apache.wicket.Component.getPage(Component.java:1658) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:689) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:605) at org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:520) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172) - 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: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [X] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Didnt you encounter the big thread (at least 100 messages) where we discussed/voted going to 1.4? (and cool down dev on 1.3) On 6/1/08, Ayodeji Aladejebi [EMAIL PROTECTED] wrote: scan this user forum, you will realize that there is no high demand for generics in wicket from users. I am yet to see one user or thread here of wicket users screeming out for generics addition. I think users has been doing just fine without it at least speaking for myself. Anything more than IModel, I wont upgrade to 1.4 as well +1 for IModels only as for as I am concerned, annotations are better 1.5 additions than generics. generics is just awful On 6/1/08, atul singh [EMAIL PROTECTED] wrote: 1) [ X] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. *Reason::* I think generifying data-structure/models is what is sustainable. Components can become too complicated when gentrified..and who know how far wicket wants to go!! 2) [X] I definitively won't be using 1.4. if Wicket doesn't go for my preference. On Mon, Jun 2, 2008 at 2:14 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - 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]
Handling click events in your custom IRequestCodingStrategy
I am writing my own IRequestCodingStrategy that will be returned by getRequestCodingStrategy() in a subclass of DefaultWebRequestCycleProcessor. I use my IRequestCodingStrategy to translate a URL like index.jsp?content_id=17 into /press/articles/this_is_my_headline.html using decode() and encode() methods. It works pretty nice so far. However, I have a problem with Button or Link events that worked before. I mean these Buttons or Links, that have their onSubmit or onClick method overwritten. When I hover over these elements in the Browser, I see that the URL is still in the default Wicket style like Component::bla::[0]. When I trigger the action, nothing works really. Obviously my IRequestCodingStrategy and the way event methods are invoked, is not coupled together yet. How would I implement that? Is there a good tutorial maybe? -- View this message in context: http://www.nabble.com/Handling-click-events-in-your-custom-IRequestCodingStrategy-tp17595141p17595141.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: decode() in WebRequestCodingStrategy
why do you want to add extra params in the RequestParameters? The use case is this. The request comes in with a URL like /press/article/headline.html. I will take the URL and look up which Content node this path maps to in our CMS. Then I would like to add the id of this Content node into the RequestParameters for later processing. reikje wrote: I am trying to implement a custom WebRequestCodingStrategy. In the decode methode, I would like to add some custom parameters in the RequestParameters object that is returned. I can add whatever I want in addBookmarkablePageParameters(..) - perfect. However, all of my parameters are completly ignored as WebRequestCodingStrategy.decode will only return the parameters that were previously in the Request. Is that supposed to be like this? I was expecting that I could add individual parameters in a method called addBookmarkablePageParameters. I choosed to do that in WebRequestCodingStrategy because I don't want to mount anything. -- View this message in context: http://www.nabble.com/decode%28%29-in-WebRequestCodingStrategy-tp17460040p17595176.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: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. 2) How strongly do you feel about your choice above? [X] I might rethink upgrading if my choice doesn't win. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Weird exceptions. Has anyone seen any exceptions like these
*This is happening on use of ajax tabs...and that too all of them wherever they are in our application.. I remember this happening earlier when there were unclosed img tags:: look at this mail *http://www.mail-archive.com/users@wicket.apache.org/msg15126.html *Is any similar things there I am not aware of? *(Also if we want this exception ignored by shifting to 1.3.4--we probably are trying to ignore what might be going wrong ...I am not so sure about a change in wicket version we use at the moment, nor do we have bandwidth for this) On Mon, Jun 2, 2008 at 12:21 PM, Johan Compagner [EMAIL PROTECTED] wrote: In 1.3.4 this error shouldnt happen, it is just ignored On 6/1/08, atul singh [EMAIL PROTECTED] wrote: Hi, As a result of code integration from various teams we have introduced some change which is causing problems... but the sad part is that we do not know what is happening-- I will loove to know if someone else has seen similar exceptions and how they solved if they were able to:: Also what do these exceptions mean--i mean situation they might happen in?? 1. java.lang.IllegalStateException: No Page found for component [MarkupContainer [Component id = panel, page = No Page, path = at org.apache.wicket.Component.getPage(Component.java:1658) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponent(AjaxRequestTarget.java:689) at org.apache.wicket.ajax.AjaxRequestTarget.respondComponents(AjaxRequestTarget.java:605) at org.apache.wicket.ajax.AjaxRequestTarget.respond(AjaxRequestTarget.java:520) at org.apache.wicket.request.AbstractRequestCycleProcessor.respond(AbstractRequestCycleProcessor.java:104) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1172) - 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: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [X2] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. I would prefer to have models and components generified, however if this makes the API too verbose or cumbersome to use then I prefer to fall back to only generified models. At one point someone suggested a wiki page outlining the difficulties with generics, does such a page exist? 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Feedback message related problem--info,debug etc take string arguments which is not very flexible
I can do that within a day or 2..(Meaning with the patch..).does any core dev see an issue if info,debug etc start taking Serializable as parameter like error().?? Thanks On Mon, Jun 2, 2008 at 10:48 AM, Erik van Oosten [EMAIL PROTECTED] wrote: Hi, Atul, That sounds like a reasonable request to me (I am no core member). Its best to open a new issue in Wicket's jira, preferably with a patch attached. Regards, Erik. atul singh wrote: Hi, I see that only error() feedback takes a serializabel message. This allows me to pass any java object as message and implement custom filtering of messages by components. but info,debug etc take a string and so do not help me in that kind of filtering. Actually what we have is a TabbedWizard thing, a hybrid of TabbedPanel and Wizard. We have such a requirement to target feedback messages to very specific feedback components on any of the tabs. This is also not possible by implementing this logic based on the reporting component. I wanted the implementation to be generic , just based on info encapsulated in the message. Can anyone suggest an alternative? Can the info(),debug() etc method signatures be changed to have such flexibility??? Thanks - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [ X ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. 2) How strongly do you feel about your choice above? [ X ] Whatever choice ultimately made, I'll happily convert/ start Thijs - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: split tabpanel navigation and panel content
Thank you all for the response. I did it in a simple way .. Duplicate the TabbedPanel source code in a diff name (VerticalTabbedPanel) in my application and modified the html alone slightly so that the target panel comes in the RHS. Thanks, nazeem Mr Mean wrote: Well if you are talking about having other html elements between the tab bar and the content itself, then no you would have to write your own components. but using some css or overriding the default markup for the tabbedpanel you might be able to achieve the same visual effect. Maurice On Sun, Jun 1, 2008 at 11:22 AM, cresc [EMAIL PROTECTED] wrote: When using wickets tabbed panel can I split the navigation and the panel contents to diff blocks. The use cases I require is use a vertical tab (sidebar) as tab and display the contents in RHS side. Please suggest any workaround to achieve this. Thank u. -- View this message in context: http://www.nabble.com/split-tabpanel-navigation-and-panel-content-tp17583663p17583663.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/split-tabpanel-navigation-and-panel-content-tp17583663p17595750.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: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. 2) How strongly do you feel about your choice above? [ X] Whatever choice ultimately made, I'll happily convert/ start Dipu
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [x] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. I had a production quality project with the old 2.0 branch (downgraded it) and that worked just fine and very intuitive, I was very bummed at the time I had to add all these hideous type casts. I do not understand the fuss about generifying everything, I did not have ANY problems using the generics in my production project (which consists of about 30 wicket classes) and it was not a simple crud app, I did some funky wicket stuff with this project (loads of panels, fragment, own custom component, ajax) and it all just worked. 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. Wouter de Vaal - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
setPageExpiredErrorPage(PageExpired.class) - Login page loaded instead of PageExpired page
Hi, in my Wicket application (using Wicket 1.3.3) I have a Login page. In case of a session timeout, the user is supposed to be sent back to something looking like the login page with an additional text Your session has timed out. So I thought the best way to deal with this would be to create a PageExpired class derived from the Login class and use markup inheritance to add the Your session has timed out text, so there is no duplication and there are just a few lines to add. In the init() method of my WebApplication subclass I say getApplicationSettings().setPageExpiredErrorPage(PageExpired.class); But, unfortunately, on session expiry in most cases the Login Page is loaded instead of the PageExpired page. I could not find out conditions under which the Login page is being loaded instead of the PageExpired page. I tried to debug the Wicket code itself but got lost somewhere and did not find the point where the original target (before the timeout) gets replaced by the Login page. Also, I noticed that in no case the getPageExpiredErrorPage() Method of the Settings class was called. Do you have any ideas or maybe an alternative approach? José -- View this message in context: http://www.nabble.com/setPageExpiredErrorPage%28PageExpired.class%29--%3E-Login-page-loaded-instead-of-PageExpired-page-tp17596262p17596262.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: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. This is the only solution that makes sense, the other options are either a partial solution (which is a *very, very* bad thing, mixing generic with non-generic code INSIDE a framework!?!?) or no solution at all (which has my preference over a partial solution, since at least it is concise). 2) How strongly do you feel about your choice above? [X] I might rethink upgrading if my choice doesn't win. Seriously, no generics at all is better than a partial solution. Since upgrading involves more issues than generics alone, I may rethink only... If the decision to upgrade boils down to this issue, then I won't. Antoine - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
sortable column with overriden getCssClass
Hi,
We use sortable AbstractColumn derivatives in our DataTable.
I added this recently to the column to add a custom CSS class to the
TD elements in this column (see IStyledColumn):
@Override getCssClass {return colmn_class;}
Now my TH elements have an aggregate class list with the sortedness
class and mine as expected, and another class attribute with the
sortedness class only:
th class=wicket_orderNone fcflist_mTimea id=orderByLink95
onclick=var
wcall=wicketAjaxGet('../?wicket:interface=:2:anotherContentRow:anotherContent:tabs:panel:form:table:topToolbars:2:toolbar:headers:14:header:orderByLink::IBehaviorListener:1:1',null,null,
function() {return Wicket.$('orderByLink95') !=
null;}.bind(this));return !wcall; class=wicket_orderNone
href=../?wicket:interface=:2:anotherContentRow:anotherContent:tabs:panel:form:table:topToolbars:2:toolbar:headers:14:header:orderByLink::ILinkListener::
Now that can't be right, did I do something wrong or could this be a bug?
Gabor Szokoli
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Wicket cheat sheet, solve your wicket problem fast?
Hi I've created a small wicket cheat sheet for issues and features, please see here : http://www.flyupload.com/?fid=9436254 It's based on my experience so it's certainly not complete and you should consider it a draft. Any comment will be welcome:) -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven deployment..?
Yup.. James Carman wrote: Well, the test and prod profiles do have that property set to deployment. The default properties just sets it to development. On Fri, May 30, 2008 at 2:38 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Great:) Looks like we do a lot of stuff the same way:) So you just need to add this to your profile?: properties wicket.configurationdeployment/wicket.configuration /properties James Carman wrote: You don't need different web.xml files. You can use maven's filtering capability to filter your web.xml file (actually I filter my spring config files since I set up my application in a spring context). Take a look at my wicket-advanced example code for inspiration: http://svn.carmanconsulting.com/public/wicket-advanced/trunk On Fri, May 30, 2008 at 10:43 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi I use cargo, to deploy to tomcat and I would really like to automatically deploy wicket in deploy and not development. So what do you guys do..? Have different profiles that include different web.xml or? -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setPageExpiredErrorPage(PageExpired.class) - Login page loaded instead of PageExpired page
Looks like your security strategy is not allowing your pageexpired page to be instantiated. in that case it will try to render the login page. Note that this is default behavior both in wicket-auth-roles and swarm. Check the documentation for how to set your security strategy to allow wicket to create an instance of the page. Maurice On Mon, Jun 2, 2008 at 10:22 AM, jd17 [EMAIL PROTECTED] wrote: Hi, in my Wicket application (using Wicket 1.3.3) I have a Login page. In case of a session timeout, the user is supposed to be sent back to something looking like the login page with an additional text Your session has timed out. So I thought the best way to deal with this would be to create a PageExpired class derived from the Login class and use markup inheritance to add the Your session has timed out text, so there is no duplication and there are just a few lines to add. In the init() method of my WebApplication subclass I say getApplicationSettings().setPageExpiredErrorPage(PageExpired.class); But, unfortunately, on session expiry in most cases the Login Page is loaded instead of the PageExpired page. I could not find out conditions under which the Login page is being loaded instead of the PageExpired page. I tried to debug the Wicket code itself but got lost somewhere and did not find the point where the original target (before the timeout) gets replaced by the Login page. Also, I noticed that in no case the getPageExpiredErrorPage() Method of the Settings class was called. Do you have any ideas or maybe an alternative approach? José -- View this message in context: http://www.nabble.com/setPageExpiredErrorPage%28PageExpired.class%29--%3E-Login-page-loaded-instead-of-PageExpired-page-tp17596262p17596262.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket cheat sheet, solve your wicket problem fast?
Interesting idea - I'd encourage you to expand a bit on the the Are you using models? stage though, as that could be take the wrong way! :-) Incidently, for non-visibles, you might want to consider Component.setOutputMarkupPlaceholderTag() as an alternative such as when the parent contains a number of elements that may not need updating. /Gwyn On Mon, Jun 2, 2008 at 9:33 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi I've created a small wicket cheat sheet for issues and features, please see here : http://www.flyupload.com/?fid=9436254 It's based on my experience so it's certainly not complete and you should consider it a draft. Any comment will be welcome:) -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - 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: problem when reading properties file
On 6/2/08, wenm [EMAIL PROTECTED] wrote: But my label only show the message when the web service returns error, not constant showing. So it is not a good idea to use resourceModel. I know I'm not answering your original question, but until someone does, you could look at either the FeedbackPanel which you might be reimplementing, or at overriding the isVisible function of the label to make it show up conditionally. Gabor Szokoli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setPageExpiredErrorPage(PageExpired.class) - Login page loaded instead of PageExpired page
Hi Maurice, thanks for your quick response. I have tested quite a bit this morning and in most cases, the PageExpired page is being instantiated and redirected to on timeouts, but in other cases, it is not. I do not understand the exact circumstances, but I don't think the security strategy settings play a role because otherwise, I would not see the PageExpired page at all. José Mr Mean wrote: Looks like your security strategy is not allowing your pageexpired page to be instantiated. -- View this message in context: http://www.nabble.com/setPageExpiredErrorPage%28PageExpired.class%29--%3E-Login-page-loaded-instead-of-PageExpired-page-tp17596262p17597039.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]
problem when reading properties file
I want to read a properties file test.properties, and show the value which is
defined in properties file in a lable. But I can't read the properties file
I have tried
property.load(ClassLoader.getSystemResourceAsStream(test.properties));
property.load(this.getClass().getClassLoader().getResourceAsStream(test.properties));
property.load(PackageResource.get(test.class,
test.properties).getResourceStream().getInputStream());
property.load(((WebApplication)
Application.get()).getServletContext().getResourceAsStream(test.properties));
But it always generate null point error
java.lang.NullPointerException
at java.util.Properties$LineReader.readLine(Properties.java:365)
at java.util.Properties.load(Properties.java:293)
Then I tried to test reading in main method, and it works fine there.
public static void main(String[] args){
Properties property = new Properties();
try {
property.load(ClassLoader.getSystemResourceAsStream(test.properties));
} catch (IOException e) {
e.printStackTrace(); }
System.out.println(property.getProperty(a key));
}
Really can't understand why. Did I do something in wrong way? Thanks for any
help or sugestion.
--
View this message in context:
http://www.nabble.com/problem-when-reading-properties-file-tp17597421p17597421.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: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [x] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. 2) How strongly do you feel about your choice above? [x] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem when reading properties file
Thanks. But still the lable will show different messages according to different error situation. So even to make it show up conditionally can't solve the problem. Gabor Szokoli wrote: On 6/2/08, wenm [EMAIL PROTECTED] wrote: But my label only show the message when the web service returns error, not constant showing. So it is not a good idea to use resourceModel. I know I'm not answering your original question, but until someone does, you could look at either the FeedbackPanel which you might be reimplementing, or at overriding the isVisible function of the label to make it show up conditionally. Gabor Szokoli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/problem-when-reading-properties-file-tp17597421p17598771.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]
configure the expire header value
how to configure expire header value for wicket resources like indicator.gif wicket js etc ? and, if we can set the expire to long time away, can wicket name the resources with version according to wicket release version? -- View this message in context: http://www.nabble.com/configure-the-%22expire%22-header-value-tp17598027p17598027.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: Wicket cheat sheet, solve your wicket problem fast?
New version : http://www.flyupload.com/?fid=277854 Gwyn Evans wrote: Interesting idea - I'd encourage you to expand a bit on the the Are you using models? stage though, as that could be take the wrong way! :-) True, i've elaborated it a bit. Incidently, for non-visibles, you might want to consider Component.setOutputMarkupPlaceholderTag() as an alternative such as when the parent contains a number of elements that may not need updating. Somehow that eluded me thanks for pointing out. /Gwyn On Mon, Jun 2, 2008 at 9:33 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi I've created a small wicket cheat sheet for issues and features, please see here : http://www.flyupload.com/?fid=9436254 It's based on my experience so it's certainly not complete and you should consider it a draft. Any comment will be welcome:) -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Memory leak in DiskPageStore
Hi,
about not removing the entries, can you please create jira issue? I
will try to look into it ASAP.
-Matej
On Mon, Jun 2, 2008 at 11:38 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:
Recently, I had 2 memory related crashes of my Wicket app. Thanks to the
priceless -XX:+HeapDumpOnOutOfMemoryError option, I had a heap dump to look
at (one crash was due to a GC overhead exception, so no dump there). One
thing that immediately attracted my attention was that there were 116.917
instances of
org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry. As
objects of this class represent a session (javadoc), it seems that I had
116.917 sessions mapped in DiskPageStore.sessionIdToEntryMap.
In my app, i spotted two reasons for this;
1. search engine bots (e.g. googlebot) receive a new session for each page
they access, as we cut of the ;jsessionid= from the URL in our app in order
not to have those ugly IDs on the search engine result pages. As a result,
when google tried to index 100.000+ pages 100.000+ sessions had been
created. I am certainly going to work on this issue, however, it helped me
to spot reason number 2:
2. No entries are removed from DiskPageStore.sessionIdToEntryMap. I guess,
this should be added to the DiskPageStore.unbind(String sessionId) method:
public void unbind(String sessionId)
{
// FIX: replace get() with remove()
SessionEntry entry =
(SessionEntry)sessionIdToEntryMap.get(sessionId);
if (entry != null)
{
if (isSynchronous())
{
entry.unbind();
}
else
{
List pages = getPagesToSaveList(sessionId);
synchronized (pages)
{
flushPagesToSaveList(sessionId, pages);
entry.unbind();
}
pagesToSaveAll.remove(sessionId);
}
}
}
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Memory-leak-in-DiskPageStore-tp17597466p17597466.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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: decode() in WebRequestCodingStrategy
Eventually you might be interested in https://issues.apache.org/jira/browse/WICKET-1666 Am 02.06.2008 um 09:02 schrieb reikje: why do you want to add extra params in the RequestParameters? The use case is this. The request comes in with a URL like /press/article/headline.html. I will take the URL and look up which Content node this path maps to in our CMS. Then I would like to add the id of this Content node into the RequestParameters for later processing. reikje wrote: I am trying to implement a custom WebRequestCodingStrategy. In the decode methode, I would like to add some custom parameters in the RequestParameters object that is returned. I can add whatever I want in addBookmarkablePageParameters(..) - perfect. However, all of my parameters are completly ignored as WebRequestCodingStrategy.decode will only return the parameters that were previously in the Request. Is that supposed to be like this? I was expecting that I could add individual parameters in a method called addBookmarkablePageParameters. I choosed to do that in WebRequestCodingStrategy because I don't want to mount anything. -- View this message in context: http://www.nabble.com/decode%28%29-in-WebRequestCodingStrategy-tp17460040p17595176.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. Verbose VS Clarity, Clarity wins hands down. 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. -Original Message- From: Eelco Hillenius [mailto:[EMAIL PROTECTED] Sent: Sunday, June 01, 2008 4:45 PM To: wicket user list Subject: users, please give us your opinion: what is your take on generics with Wicket Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - 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]
Memory leak in DiskPageStore
Recently, I had 2 memory related crashes of my Wicket app. Thanks to the
priceless -XX:+HeapDumpOnOutOfMemoryError option, I had a heap dump to look
at (one crash was due to a GC overhead exception, so no dump there). One
thing that immediately attracted my attention was that there were 116.917
instances of
org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry. As
objects of this class represent a session (javadoc), it seems that I had
116.917 sessions mapped in DiskPageStore.sessionIdToEntryMap.
In my app, i spotted two reasons for this;
1. search engine bots (e.g. googlebot) receive a new session for each page
they access, as we cut of the ;jsessionid= from the URL in our app in order
not to have those ugly IDs on the search engine result pages. As a result,
when google tried to index 100.000+ pages 100.000+ sessions had been
created. I am certainly going to work on this issue, however, it helped me
to spot reason number 2:
2. No entries are removed from DiskPageStore.sessionIdToEntryMap. I guess,
this should be added to the DiskPageStore.unbind(String sessionId) method:
public void unbind(String sessionId)
{
// FIX: replace get() with remove()
SessionEntry entry =
(SessionEntry)sessionIdToEntryMap.get(sessionId);
if (entry != null)
{
if (isSynchronous())
{
entry.unbind();
}
else
{
List pages = getPagesToSaveList(sessionId);
synchronized (pages)
{
flushPagesToSaveList(sessionId, pages);
entry.unbind();
}
pagesToSaveAll.remove(sessionId);
}
}
}
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Memory-leak-in-DiskPageStore-tp17597466p17597466.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: Memory leak in DiskPageStore
https://issues.apache.org/jira/browse/WICKET-1679
Matej Knopp-2 wrote:
Hi,
about not removing the entries, can you please create jira issue? I
will try to look into it ASAP.
-Matej
On Mon, Jun 2, 2008 at 11:38 AM, Stefan Fußenegger
[EMAIL PROTECTED] wrote:
Recently, I had 2 memory related crashes of my Wicket app. Thanks to the
priceless -XX:+HeapDumpOnOutOfMemoryError option, I had a heap dump to
look
at (one crash was due to a GC overhead exception, so no dump there). One
thing that immediately attracted my attention was that there were 116.917
instances of
org.apache.wicket.protocol.http.pagestore.DiskPageStore$SessionEntry. As
objects of this class represent a session (javadoc), it seems that I
had
116.917 sessions mapped in DiskPageStore.sessionIdToEntryMap.
In my app, i spotted two reasons for this;
1. search engine bots (e.g. googlebot) receive a new session for each
page
they access, as we cut of the ;jsessionid= from the URL in our app in
order
not to have those ugly IDs on the search engine result pages. As a
result,
when google tried to index 100.000+ pages 100.000+ sessions had been
created. I am certainly going to work on this issue, however, it helped
me
to spot reason number 2:
2. No entries are removed from DiskPageStore.sessionIdToEntryMap. I
guess,
this should be added to the DiskPageStore.unbind(String sessionId)
method:
public void unbind(String sessionId)
{
// FIX: replace get() with remove()
SessionEntry entry =
(SessionEntry)sessionIdToEntryMap.get(sessionId);
if (entry != null)
{
if (isSynchronous())
{
entry.unbind();
}
else
{
List pages =
getPagesToSaveList(sessionId);
synchronized (pages)
{
flushPagesToSaveList(sessionId,
pages);
entry.unbind();
}
pagesToSaveAll.remove(sessionId);
}
}
}
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Memory-leak-in-DiskPageStore-tp17597466p17597466.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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
---
Stefan Fußenegger
http://talk-on-tech.blogspot.com // looking for a nicer domain ;)
--
View this message in context:
http://www.nabble.com/Memory-leak-in-DiskPageStore-tp17597466p17597859.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: problem when reading properties file
I'm not sure what's wrong, but why not use the i18n feature?
Create a .properties file with name of the page that your label is located,
put it in the same folder of the page (like were you put the html).
The label should be something like this:
add( new Label( page.label, new ResourceModel( page.label ) );
check:
http://cwiki.apache.org/WICKET/general-i18n-in-wicket.html
Hope that was helpful.
Eyal
On Mon, Jun 2, 2008 at 12:34 PM, wenm [EMAIL PROTECTED] wrote:
I want to read a properties file test.properties, and show the value which
is
defined in properties file in a lable. But I can't read the properties file
I have tried
property.load(ClassLoader.getSystemResourceAsStream(test.properties));
property.load(this.getClass().getClassLoader().getResourceAsStream(test.properties));
property.load(PackageResource.get(test.class,
test.properties).getResourceStream().getInputStream());
property.load(((WebApplication)
Application.get()).getServletContext().getResourceAsStream(test.properties));
But it always generate null point error
java.lang.NullPointerException
at java.util.Properties$LineReader.readLine(Properties.java:365)
at java.util.Properties.load(Properties.java:293)
Then I tried to test reading in main method, and it works fine there.
public static void main(String[] args){
Properties property = new Properties();
try {
property.load(ClassLoader.getSystemResourceAsStream(test.properties));
} catch (IOException e) {
e.printStackTrace(); }
System.out.println(property.getProperty(a key));
}
Really can't understand why. Did I do something in wrong way? Thanks for
any
help or sugestion.
--
View this message in context:
http://www.nabble.com/problem-when-reading-properties-file-tp17597421p17597421.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]
--
Eyal Golan
[EMAIL PROTECTED]
Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74
Re: users, please give us your opinion: what is your take on generics with Wicket
I agree with Antoine. Guðmundur Bjarni Antoine van Wel wrote: 1) Generifying* Wicket [X] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. This is the only solution that makes sense, the other options are either a partial solution (which is a *very, very* bad thing, mixing generic with non-generic code INSIDE a framework!?!?) or no solution at all (which has my preference over a partial solution, since at least it is concise). 2) How strongly do you feel about your choice above? [X] I might rethink upgrading if my choice doesn't win. Seriously, no generics at all is better than a partial solution. Since upgrading involves more issues than generics alone, I may rethink only... If the decision to upgrade boils down to this issue, then I won't. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17596960.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: Wicket cheat sheet, solve your wicket problem fast?
Why not just create a new wiki page? I like the idea too! On Mon, Jun 2, 2008 at 4:33 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi I've created a small wicket cheat sheet for issues and features, please see here : http://www.flyupload.com/?fid=9436254 It's based on my experience so it's certainly not complete and you should consider it a draft. Any comment will be welcome:) -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - 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: problem when reading properties file
so the problem is that you can get different messages? if so, why not use isVisible() as Gabor suggested. And for the String itself, why not use a utility that converts the message to your liking? On Mon, Jun 2, 2008 at 2:03 PM, wenm [EMAIL PROTECTED] wrote: Thanks. But still the lable will show different messages according to different error situation. So even to make it show up conditionally can't solve the problem. Gabor Szokoli wrote: On 6/2/08, wenm [EMAIL PROTECTED] wrote: But my label only show the message when the web service returns error, not constant showing. So it is not a good idea to use resourceModel. I know I'm not answering your original question, but until someone does, you could look at either the FeedbackPanel which you might be reimplementing, or at overriding the isVisible function of the label to make it show up conditionally. Gabor Szokoli - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/problem-when-reading-properties-file-tp17597421p17598771.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] -- Eyal Golan [EMAIL PROTECTED] Visit: http://jvdrums.sourceforge.net/ LinkedIn: http://www.linkedin.com/in/egolan74
Re: maven deployment..?
Brill Pappin wrote: Because deployment happens to a staging or production server, I simply set the jvm startup params with -Dwicket.configuration=deployment. It's also a possibility, i'll certainly ease of maven config a bit. I also have a small block in my Application instance that turns params on and off depending on the mode as well, so for instance I can have tags stripped etc. in production. I've done this too once, however I like to test it with same properties as in production. So, I simply deploy the war as needed and the correct env is set up. I like this way of doing it because I hate having a *different* deployable depending on how some filter modified my metadata. - Brill -Original Message- From: Nino Saturnino Martinez Vazquez Wael [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2008 10:43 AM To: users@wicket.apache.org Subject: maven deployment..? Hi I use cargo, to deploy to tomcat and I would really like to automatically deploy wicket in deploy and not development. So what do you guys do..? Have different profiles that include different web.xml or? -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem when reading properties file
Thanks Eyal. I have tried with resourceModel before, it works fine. But my label only show the message when the web service returns error, not constant showing. So it is not a good idea to use resourceModel. -- View this message in context: http://www.nabble.com/problem-when-reading-properties-file-tp17597421p17597687.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: problem when reading properties file
:) The problem is that I have to get different massages from properties file, and then comes to my original question. so the problem is that you can get different messages? if so, why not use isVisible() as Gabor suggested. And for the String itself, why not use a utility that converts the message to your liking? -- View this message in context: http://www.nabble.com/problem-when-reading-properties-file-tp17597421p17599504.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: Wicket cheat sheet, solve your wicket problem fast?
ahh, a simple solution.. I guess it's nice with some graphics. But we could do this as a combination I guess? James Carman wrote: Why not just create a new wiki page? I like the idea too! On Mon, Jun 2, 2008 at 4:33 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi I've created a small wicket cheat sheet for issues and features, please see here : http://www.flyupload.com/?fid=9436254 It's based on my experience so it's certainly not complete and you should consider it a draft. Any comment will be welcome:) -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem when reading properties file
Have we discussed *why* you're doing what you're doing? Perhaps you're approaching the problem the wrong way. Care to share the actual problem you're facing which caused you to choose this approach with us? On Mon, Jun 2, 2008 at 7:51 AM, wenm [EMAIL PROTECTED] wrote: :) The problem is that I have to get different massages from properties file, and then comes to my original question. so the problem is that you can get different messages? if so, why not use isVisible() as Gabor suggested. And for the String itself, why not use a utility that converts the message to your liking? -- View this message in context: http://www.nabble.com/problem-when-reading-properties-file-tp17597421p17599504.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven deployment..?
it seems it's just not enough adding the stuff to the profiles, do you use the maven properties plugin aswell? or? James Carman wrote: Well, the test and prod profiles do have that property set to deployment. The default properties just sets it to development. On Fri, May 30, 2008 at 2:38 PM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Great:) Looks like we do a lot of stuff the same way:) So you just need to add this to your profile?: properties wicket.configurationdeployment/wicket.configuration /properties James Carman wrote: You don't need different web.xml files. You can use maven's filtering capability to filter your web.xml file (actually I filter my spring config files since I set up my application in a spring context). Take a look at my wicket-advanced example code for inspiration: http://svn.carmanconsulting.com/public/wicket-advanced/trunk On Fri, May 30, 2008 at 10:43 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: Hi I use cargo, to deploy to tomcat and I would really like to automatically deploy wicket in deploy and not development. So what do you guys do..? Have different profiles that include different web.xml or? -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: setPageExpiredErrorPage(PageExpired.class) - Login page loaded instead of PageExpired page
Maurice,
you were on the right track, thanks a lot! Some time ago I had defined the
authorization strategy as follows:
getSecuritySettings().setAuthorizationStrategy(new IAuthorizationStrategy()
{
...
public boolean isInstantiationAuthorized(Class componentClass) {
if (SecureStyledPage.class.isAssignableFrom(componentClass)) {
if (!((MWSession) Session.get()).isUserLoggedIn()) {
// Force sign in
throw new RestartResponseAtInterceptPageException(Login.class);
}
else {
return true;
}
}
return true;
}
and forgotten about it. So this was the reason why it went wrong and this is
the place to correct things.
Cheers
José
--
View this message in context:
http://www.nabble.com/setPageExpiredErrorPage%28PageExpired.class%29--%3E-Login-page-loaded-instead-of-PageExpired-page-tp17596262p17597602.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: problem when reading properties file
:) The problem is that I have to get different massages from properties file, and then comes to my original question. hmm i tried Chinese, Thais and some others. But i never got a massage from a property file, how does that feel?? johan
Re: problem when reading properties file
Sure.
Maybe I need to explain more explicitly.
I will get the unique error code from web service if there is something
wrong. And then I would like to map the error codes to user-friendly
messages (which are in properties file), and show the messages conditionally
based on the error type in a label.
For example
if(error code == 1){
add(new Label(a, property.getProperty(key1)));
} else if (error code ==2){
.
}
So the first thing is that I have to read the properties file and let the
property to load it, so I can get the value(the message which I want to
show).
And problen is whatever I tried, it failed to read as what I wrote before
Have we discussed *why* you're doing what you're doing? Perhaps
you're approaching the problem the wrong way. Care to share the
actual problem you're facing which caused you to choose this approach
with us?
--
View this message in context:
http://www.nabble.com/problem-when-reading-properties-file-tp17597421p17599649.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: problem when reading properties file
lol :) I haven't get it so far, so I don't know how's the properties' massage. mis-typing, sorry. Johan Compagner wrote: :) The problem is that I have to get different massages from properties file, and then comes to my original question. hmm i tried Chinese, Thais and some others. But i never got a massage from a property file, how does that feel?? johan -- View this message in context: http://www.nabble.com/problem-when-reading-properties-file-tp17597421p17599687.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: problem when reading properties file
On Mon, Jun 2, 2008 at 8:01 AM, wenm [EMAIL PROTECTED] wrote:
Sure.
Maybe I need to explain more explicitly.
I will get the unique error code from web service if there is something
wrong. And then I would like to map the error codes to user-friendly
messages (which are in properties file), and show the messages conditionally
based on the error type in a label.
For example
if(error code == 1){
add(new Label(a, property.getProperty(key1)));
} else if (error code ==2){
.
}
So the first thing is that I have to read the properties file and let the
property to load it, so I can get the value(the message which I want to
show).
Have you looked at org.apache.wicket.model.ResourceModel? You could do:
new Label(a, new ResourceModel(key1))
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: problem when reading properties file
Exactly as James suggest and what I said earlier:
use something like this,
add( new Label( page.label, new ResourceModel( page.label ) );
Instead of 'page.label' do something like error.label.key#
where key# is what you get from the service.
On Mon, Jun 2, 2008 at 3:05 PM, James Carman [EMAIL PROTECTED]
wrote:
On Mon, Jun 2, 2008 at 8:01 AM, wenm [EMAIL PROTECTED] wrote:
Sure.
Maybe I need to explain more explicitly.
I will get the unique error code from web service if there is something
wrong. And then I would like to map the error codes to user-friendly
messages (which are in properties file), and show the messages
conditionally
based on the error type in a label.
For example
if(error code == 1){
add(new Label(a, property.getProperty(key1)));
} else if (error code ==2){
.
}
So the first thing is that I have to read the properties file and let the
property to load it, so I can get the value(the message which I want to
show).
Have you looked at org.apache.wicket.model.ResourceModel? You could do:
new Label(a, new ResourceModel(key1))
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
Eyal Golan
[EMAIL PROTECTED]
Visit: http://jvdrums.sourceforge.net/
LinkedIn: http://www.linkedin.com/in/egolan74
Re: problem when reading properties file
yup, it works. But I would like to know the way to read the file, for studying and also maybe future use. jwcarman wrote: Have you looked at org.apache.wicket.model.ResourceModel? You could do: new Label(a, new ResourceModel(key1)) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- View this message in context: http://www.nabble.com/problem-when-reading-properties-file-tp17597421p17599820.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: problem when reading properties file
On Mon, Jun 2, 2008 at 8:10 AM, wenm [EMAIL PROTECTED] wrote: yup, it works. But I would like to know the way to read the file, for studying and also maybe future use. For future use, I'd suggest you look at the java.util.ResourceBundle class. That will probably do what you are looking for. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven deployment..?
On Mon, Jun 2, 2008 at 7:55 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: it seems it's just not enough adding the stuff to the profiles, do you use the maven properties plugin aswell? or? Just adding the properties/profiles won't quite get it done. You need to turn on resource filtering in maven: resources resource directorysrc/main/resources/directory includes include**/*.xml/include include**/*.properties/include /includes filteringtrue/filtering /resource /resources - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
getString, Label - Warn
Hi everybody, If I use this code : BookmarkablePageLink lien_accueil = new BookmarkablePageLink(accueil, HomePage.class); Label labelLinkAccueil = new Label (name,getString(LabelLinkAccueil)); labelLinkAccueil.setEscapeModelStrings(false); lien_accueil.add(labelLinkAccueil); lien_accueil.setVisible(true); add(lien_accueil); In my log file, I have this warning : (Localizer.java:188) - Tried to retrieve a localized string for a component that has not yet been added to the page. This can sometimes lead to an invalid or no localized resource returned. Make sure you are not calling Component#getString() inside your Component's constructor. Offending component: [MarkupContainer [Component id = panelmenu, page = No Page, path = panelmenu.PanelMenu]] Wicket doesn't like to use the constructor of a label and getString() How cant I resolve this warning and use getString with new Label Thank you in advance -- View this message in context: http://www.nabble.com/getString%2C-Label--%3E-Warn-tp17599949p17599949.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: getString, Label - Warn
Make a model that does the getString in the getObject and give that model to your label. Maurice On Mon, Jun 2, 2008 at 2:15 PM, Fabien D. [EMAIL PROTECTED] wrote: Hi everybody, If I use this code : BookmarkablePageLink lien_accueil = new BookmarkablePageLink(accueil, HomePage.class); Label labelLinkAccueil = new Label (name,getString(LabelLinkAccueil)); labelLinkAccueil.setEscapeModelStrings(false); lien_accueil.add(labelLinkAccueil); lien_accueil.setVisible(true); add(lien_accueil); In my log file, I have this warning : (Localizer.java:188) - Tried to retrieve a localized string for a component that has not yet been added to the page. This can sometimes lead to an invalid or no localized resource returned. Make sure you are not calling Component#getString() inside your Component's constructor. Offending component: [MarkupContainer [Component id = panelmenu, page = No Page, path = panelmenu.PanelMenu]] Wicket doesn't like to use the constructor of a label and getString() How cant I resolve this warning and use getString with new Label Thank you in advance -- View this message in context: http://www.nabble.com/getString%2C-Label--%3E-Warn-tp17599949p17599949.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getString, Label - Warn
It's not telling you that you can't use it as a constructor param. It's telling you that you're trying to use it during the constructor code of your PanelMenu class. So, either move that code to onBeforeRender or use a ResourceModel for your label. On Mon, Jun 2, 2008 at 8:15 AM, Fabien D. [EMAIL PROTECTED] wrote: Hi everybody, If I use this code : BookmarkablePageLink lien_accueil = new BookmarkablePageLink(accueil, HomePage.class); Label labelLinkAccueil = new Label (name,getString(LabelLinkAccueil)); labelLinkAccueil.setEscapeModelStrings(false); lien_accueil.add(labelLinkAccueil); lien_accueil.setVisible(true); add(lien_accueil); In my log file, I have this warning : (Localizer.java:188) - Tried to retrieve a localized string for a component that has not yet been added to the page. This can sometimes lead to an invalid or no localized resource returned. Make sure you are not calling Component#getString() inside your Component's constructor. Offending component: [MarkupContainer [Component id = panelmenu, page = No Page, path = panelmenu.PanelMenu]] Wicket doesn't like to use the constructor of a label and getString() How cant I resolve this warning and use getString with new Label Thank you in advance -- View this message in context: http://www.nabble.com/getString%2C-Label--%3E-Warn-tp17599949p17599949.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Use Spring with Wicket
Hi, Can any1 plz help me to understand how to use Spring with Wicket?... i.e. 1. DAO? Thanks Samit - Samit :confused: -- View this message in context: http://www.nabble.com/Use-Spring-with-Wicket-tp17600138p17600138.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: Use Spring with Wicket
You can download (via SVN) and play with my example application: http://svn.carmanconsulting.com/public/wicket-advanced/trunk It includes the spring integration with DAOs, etc. On Mon, Jun 2, 2008 at 8:27 AM, Samit [EMAIL PROTECTED] wrote: Hi, Can any1 plz help me to understand how to use Spring with Wicket?... i.e. 1. DAO? Thanks Samit - Samit :confused: -- View this message in context: http://www.nabble.com/Use-Spring-with-Wicket-tp17600138p17600138.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use Spring with Wicket
http://www.google.com/search?q=wicket+spring On Mon, Jun 2, 2008 at 2:27 PM, Samit [EMAIL PROTECTED] wrote: Hi, Can any1 plz help me to understand how to use Spring with Wicket?... i.e. 1. DAO? Thanks Samit - Samit :confused: -- View this message in context: http://www.nabble.com/Use-Spring-with-Wicket-tp17600138p17600138.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] -- Become a Wicket expert, learn from the best: http://wicketinaction.com Apache Wicket 1.3.3 is released Get it now: http://www.apache.org/dyn/closer.cgi/wicket/1.3.3 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getString, Label - Warn
I have tried, but I have the same warning -- View this message in context: http://www.nabble.com/getString%2C-Label--%3E-Warn-tp17599949p17600229.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: getString, Label - Warn
You tried what? Moving the code to onBeforeRender() or using ResourceModel? On Mon, Jun 2, 2008 at 8:33 AM, Fabien D. [EMAIL PROTECTED] wrote: I have tried, but I have the same warning -- View this message in context: http://www.nabble.com/getString%2C-Label--%3E-Warn-tp17599949p17600229.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. 2) How strongly do you feel about your choice above? [X ] I might rethink upgrading if my choice doesn't win. We do almost all our frontend stuff with Wicket. Our developers think that the full generification will have a significant impact on ease of use and speed of development, whereas they don't see the advantages of fully typed components. 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]
RE: maven deployment..?
Not a problem, you can turn that switch on at any time on the maven command line, or in a profile (which also would likely require a command line switch). If you're a true test user, you can likely turn that on for only your unit tests and/or set up an execution for surefire so the test are run in another phase (disclaimer: I've never tried to set up executions for surefire, I assume it can be done). Example: # mvn -P WICKETTEST test # mvn -Dwicket.configuration=deployment test - Brill -Original Message- From: Nino Saturnino Martinez Vazquez Wael [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 4:36 AM To: users@wicket.apache.org Subject: Re: maven deployment..? Brill Pappin wrote: Because deployment happens to a staging or production server, I simply set the jvm startup params with -Dwicket.configuration=deployment. It's also a possibility, i'll certainly ease of maven config a bit. I also have a small block in my Application instance that turns params on and off depending on the mode as well, so for instance I can have tags stripped etc. in production. I've done this too once, however I like to test it with same properties as in production. So, I simply deploy the war as needed and the correct env is set up. I like this way of doing it because I hate having a *different* deployable depending on how some filter modified my metadata. - Brill -Original Message- From: Nino Saturnino Martinez Vazquez Wael [mailto:[EMAIL PROTECTED] Sent: Friday, May 30, 2008 10:43 AM To: users@wicket.apache.org Subject: maven deployment..? Hi I use cargo, to deploy to tomcat and I would really like to automatically deploy wicket in deploy and not development. So what do you guys do..? Have different profiles that include different web.xml or? -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - 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] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - 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: maven deployment..?
Why do you need the filtering? - Brill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 8:14 AM To: users@wicket.apache.org Subject: Re: maven deployment..? On Mon, Jun 2, 2008 at 7:55 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: it seems it's just not enough adding the stuff to the profiles, do you use the maven properties plugin aswell? or? Just adding the properties/profiles won't quite get it done. You need to turn on resource filtering in maven: resources resource directorysrc/main/resources/directory includes include**/*.xml/include include**/*.properties/include /includes filteringtrue/filtering /resource /resources - 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 cheat sheet, solve your wicket problem fast?
Sorry, I don't understand how to access the pdf from this link -Original Message- From: Nino Saturnino Martinez Vazquez Wael [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 4:34 AM To: users@wicket.apache.org Subject: Wicket cheat sheet, solve your wicket problem fast? Hi I've created a small wicket cheat sheet for issues and features, please see here : http://www.flyupload.com/?fid=9436254 It's based on my experience so it's certainly not complete and you should consider it a draft. Any comment will be welcome:) -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ EMAIL CONFIDENTIALITY NOTICE This Email message, and any attachments, may contain confidential patient health information that is legally protected. This information is intended only for the use of the individual or entity named above. The authorized recipient of this information is prohibited from disclosing this information to any other party unless required to do so by law or regulation and is required to destroy the information after its stated need has been fulfilled. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or action taken in reliance on the contents of this message is strictly prohibited. If you have received this information in error, please notify the sender immediately by replying to this message and delete the message from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: maven deployment..?
The filtering replaces the maven properties in your templates. Take a look at: http://svn.carmanconsulting.com/public/wicket-advanced/trunk/src/main/resources/META-INF/beans.xml That's my spring configuration file. All of the database settings, the Wicket configurationType, etc. are all replaced by maven properties when they are copied. On Mon, Jun 2, 2008 at 8:56 AM, Brill Pappin [EMAIL PROTECTED] wrote: Why do you need the filtering? - Brill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 8:14 AM To: users@wicket.apache.org Subject: Re: maven deployment..? On Mon, Jun 2, 2008 at 7:55 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: it seems it's just not enough adding the stuff to the profiles, do you use the maven properties plugin aswell? or? Just adding the properties/profiles won't quite get it done. You need to turn on resource filtering in maven: resources resource directorysrc/main/resources/directory includes include**/*.xml/include include**/*.properties/include /includes filteringtrue/filtering /resource /resources - 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 cheat sheet, solve your wicket problem fast?
On Mon, Jun 2, 2008 at 1:59 PM, Ames, Tim [EMAIL PROTECTED] wrote: Sorry, I don't understand how to access the pdf from this link You probably need to scoll down - here, at least, the page seems to have some info about the file, then a number of blank lines only then the Download Now link you need. /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
[ x ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ x ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. To be honest I don't see the advantage of generic components, all I want is to not have to do casting when I'm using models, .getModelObject() should return the type that I put in, in a list view, if I give it a list of strings I dont want to cast the listItem model object to a string. It would also be nice if the .add() and others methods on components could return the type of component it is rather than just a Component object. eg you cant do 'new TextArea(...).add(some behavior).setRequired(true) because the add behaviour method returns a Component not a TextArea and setRequired is not available on Components. Thanks -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17601296.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: getString, Label - Warn
Do this instead: BookmarkablePageLink lien_accueil = new BookmarkablePageLink(accueil, HomePage.class); Label labelLinkAccueil = new Label (name,new ResourceModel(LabelLinkAccueil)); Regards, Erik. Fabien D. wrote: Hi everybody, If I use this code : BookmarkablePageLink lien_accueil = new BookmarkablePageLink(accueil, HomePage.class); Label labelLinkAccueil = new Label (name,getString(LabelLinkAccueil)); labelLinkAccueil.setEscapeModelStrings(false); lien_accueil.add(labelLinkAccueil); lien_accueil.setVisible(true); add(lien_accueil); In my log file, I have this warning : (Localizer.java:188) - Tried to retrieve a localized string for a component that has not yet been added to the page. This can sometimes lead to an invalid or no localized resource returned. Make sure you are not calling Component#getString() inside your Component's constructor. Offending component: [MarkupContainer [Component id = panelmenu, page = No Page, path = panelmenu.PanelMenu]] Wicket doesn't like to use the constructor of a label and getString() How cant I resolve this warning and use getString with new Label Thank you in advance -- Erik van Oosten http://day-to-day-stuff.blogspot.com/ - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[ANNOUNCE] Apache Wicket 1.4 Milestone 2 is released
Help the Apache Wicket team to determine the future of your Wicket based web application development. We have released our second milestone release of our Java 5 based web framework and are anxious to receive feedback on our use of generics. Download Wicket 1.4-m2 now and help us decide whether to tone down, remove or increase the application of Java 5 generics to our API. We have started the discussion on the user mailing list: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-td17589984.html Eager people click here to download the distribution, others can read further: http://www.apache.org/dyn/closer.cgi/wicket/1.4-m2 We thank you for your patience and support. The Wicket Team === Apache Wicket === Apache Wicket is a component oriented Java web application framework. With proper mark-up/logic separation, a POJO data model, and a refreshing lack of XML, Apache Wicket makes developing web-apps simple and enjoyable again. Swap the boilerplate, complex debugging and brittle code for powerful, reusable components written with plain Java and HTML. You can find out more about Apache Wicket on our website: http://wicket.apache.org === This release === The Apache Wicket team is proud to announce the availability of the first milestone release of our first java 1.5 Wicket version: Apache Wicket 1.4-m2. This is the first release with java 1.5 as a minimum. Not everything has been converted to java 1.5 yet but we are getting there. === Migrating from 1.3 === If you are coming from Wicket 1.3, you really want to read our migration guide, found on the wiki: http://cwiki.apache.org/WICKET/migrate-14.html === Downloading the release === You can download the release from the official Apache mirror system, and you can find it through the following link: http://www.apache.org/dyn/closer.cgi/wicket/1.4-m2/ For the Maven and Ivy fans out there: update your pom's to the following, and everything will be downloaded automatically: dependency groupIdorg.apache.wicket/groupId artifactIdwicket/artifactId version1.4-m2/version /dependency Substitute the artifact ID with the projects of your liking to get the other projects. Please note that we don't prescribe a Logging implementation for SLF4J. You need to specify yourself which one you prefer. Read more about SLF4J here: http://slf4j.org === Validating the release === The release has been signed by Frank Bille, your release manager for today. The public key can be found in the KEYS file in the download area. Download the KEYS file only from the Apache website. http://www.apache.org/dist/wicket/1.4-m2/KEYS Instructions on how to validate the release can be found here: http://www.apache.org/dev/release-signing.html#check-integrity === Reporting bugs === In case you do encounter a bug, we would appreciate a report in our JIRA: http://issues.apache.org/jira/browse/WICKET === The distribution === In the distribution you will find a README. The README contains instructions on how to build from source yourself. You also find a CHANEGELOG-1.4 which contains a list of all things that have been fixed, added and/or removed since the first release in the 1.4 branch.
RE: Wicket cheat sheet, solve your wicket problem fast?
Duh, sorry to have bothered y'all :) -Original Message- From: Gwyn Evans [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 9:25 AM To: users@wicket.apache.org Subject: Re: Wicket cheat sheet, solve your wicket problem fast? On Mon, Jun 2, 2008 at 1:59 PM, Ames, Tim [EMAIL PROTECTED] wrote: Sorry, I don't understand how to access the pdf from this link You probably need to scoll down - here, at least, the page seems to have some info about the file, then a number of blank lines only then the Download Now link you need. /Gwyn - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ EMAIL CONFIDENTIALITY NOTICE This Email message, and any attachments, may contain confidential patient health information that is legally protected. This information is intended only for the use of the individual or entity named above. The authorized recipient of this information is prohibited from disclosing this information to any other party unless required to do so by law or regulation and is required to destroy the information after its stated need has been fulfilled. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or action taken in reliance on the contents of this message is strictly prohibited. If you have received this information in error, please notify the sender immediately by replying to this message and delete the message from your system. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: maven deployment..?
Ahh, I see... I don't use spring so I don't have to replace anything :) -Brill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 9:01 AM To: users@wicket.apache.org Subject: Re: maven deployment..? The filtering replaces the maven properties in your templates. Take a look at: http://svn.carmanconsulting.com/public/wicket-advanced/trunk/src/main/resour ces/META-INF/beans.xml That's my spring configuration file. All of the database settings, the Wicket configurationType, etc. are all replaced by maven properties when they are copied. On Mon, Jun 2, 2008 at 8:56 AM, Brill Pappin [EMAIL PROTECTED] wrote: Why do you need the filtering? - Brill -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 8:14 AM To: users@wicket.apache.org Subject: Re: maven deployment..? On Mon, Jun 2, 2008 at 7:55 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: it seems it's just not enough adding the stuff to the profiles, do you use the maven properties plugin aswell? or? Just adding the properties/profiles won't quite get it done. You need to turn on resource filtering in maven: resources resource directorysrc/main/resources/directory includes include**/*.xml/include include**/*.properties/include /includes filteringtrue/filtering /resource /resources - 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]
continueToOriginalDestination goes to tomcat's index.jsp
Hi,
I have a X web page and a login web page.
I did add below code in my application class, so when I access X page
without login, I will redirect to login page:
protected void init() {
super.init();
getSecuritySettings().setAuthorizationStrategy(new
SimplePageAuthorizationStrategy(AuthenticationPage.class, Login.class) {
@Override
protected boolean isAuthorized() {
return ((MySession)Session.get()).getUser() != null;
}
});
I also added AjaxFormValidatingBehavior.addToAllFormComponents(form,
onkeyup, Duration.ONE_SECOND); in my login class.
Here are two questions:
1. When I enter data into input field and key up, AjaxFormValidatingBehavior
doesn't work. It won't validate input field.
2. After input correct info in login page and manual because question 1, I
have to manual press submit button. Then I was redirected to tomcat's
index.jsp! What's wrong with it? I access X page without login, this is
right. But after correct login, I should return to X page, not tomcat's
index.jsp.
Please tell me what's going on and how to solve it, thanks!
http://www.nabble.com/file/p17601972/Login.java Login.java
--
View this message in context:
http://www.nabble.com/continueToOriginalDestination-goes-to-tomcat%27s-index.jsp-tp17601972p17601972.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: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. Component generification seems a little over the top with little value. It seems that generics in the models and collections only should be sufficient. 2) How strongly do you feel about your choice above? [X] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. Any use of generics is better than versions 1.4 using no generics -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602015.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: users, please give us your opinion: what is your take on generics with Wicket
why are you contradicting yourself? To be honest I don't see the advantage of generic components, all I want is to not have to do casting when I'm using models, .getModelObject() should return the type that I put in, in a list view, if I give it a list of strings I dont want to cast the listItem model object to a string. if you have just IModel then you will have to cast.. getModelObject will always return just Object then. about: new TextArea(...).add(some behavior).setRequired(true) this can be done but then we have to override some methods of component and then return another type The problem is that this could result in us lifting a final where we dont want to.. But this is outside the scope of generics johan On Mon, Jun 2, 2008 at 3:26 PM, richardwilko [EMAIL PROTECTED] wrote: [ x ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ x ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. To be honest I don't see the advantage of generic components, all I want is to not have to do casting when I'm using models, .getModelObject() should return the type that I put in, in a list view, if I give it a list of strings I dont want to cast the listItem model object to a string. It would also be nice if the .add() and others methods on components could return the type of component it is rather than just a Component object. eg you cant do 'new TextArea(...).add(some behavior).setRequired(true) because the add behaviour method returns a Component not a TextArea and setRequired is not available on Components. Thanks -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17601296.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: autocomplete show div while textfield is empty
no one??? taygolf wrote: Hey guys. I have been playing with autocompletetextfield and I really like it now that the ie bug is fixed with the 1.4 milestone. The only question I have about it is how do I make the list visible all the time. Basically I want the div to be visible all the time no matter what has been entered in the textfield. that way the user can start typing the name and the choices will be narrowed down but if they simply want to select from all choices they can. I have tried several things but none of them have worked so far. There has to be a set div to visible some where that I am missing Thanks T -- View this message in context: http://www.nabble.com/autocomplete-show-div-while-textfield-is-empty-tp17497376p17602208.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: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Should be avoided, definitly. All this generics stuff is ruining my wicket experience. 2) How strongly do you feel about your choice above? [X] I might rethink upgrading if my choice doesn't win. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602297.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: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [X] Should be avoided, definitly. All this generics stuff is ruining my wicket experience. 2) How strongly do you feel about your choice above? [X] I might rethink upgrading if my choice doesn't win. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602298.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: getString, Label - Warn
To use model and label ... I will try RessourceModel now Thank you for your help -- View this message in context: http://www.nabble.com/getString%2C-Label--%3E-Warn-tp17599949p17602329.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: getString, Label - Warn
No problem. Erik gave you exactly what you need. On Mon, Jun 2, 2008 at 10:14 AM, Fabien D. [EMAIL PROTECTED] wrote: To use model and label ... I will try RessourceModel now Thank you for your help -- View this message in context: http://www.nabble.com/getString%2C-Label--%3E-Warn-tp17599949p17602329.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: getString, Label - Warn
With the ModelRessource, it's working, thank you :) :) -- View this message in context: http://www.nabble.com/getString%2C-Label--%3E-Warn-tp17599949p17602394.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: users, please give us your opinion: what is your take on generics with Wicket
ok maybe i misread this :
'Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.'
but those 2 sentences seem to contradict each other, the first says only
generify IModel which I assumed ti mean that when you put a String into a
model you would get a String out of it, the second seems to says
generifiying components to make them only accept some model types.
So just to clarify my position
generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form)
{
EmailFormModel emailFormModel = (EmailFormModel) form.getModelObject();
is what I would like to see.
generic components im not bothered about.
if using generics wont do away with the casting then I dont see any point to
using them at all.
Johan Compagner wrote:
why are you contradicting yourself?
To be honest I don't see the advantage of generic components, all I want
is
to not have to do casting when I'm using models, .getModelObject() should
return the type that I put in, in a list view, if I give it a list of
strings I dont want to cast the listItem model object to a string.
if you have just IModel then you will have to cast.. getModelObject will
always return just Object then.
ok maybe i misread
about:
new TextArea(...).add(some behavior).setRequired(true)
this can be done but then we have to override some methods of component
and
then return another type
The problem is that this could result in us lifting a final where we dont
want to..
But this is outside the scope of generics
johan
On Mon, Jun 2, 2008 at 3:26 PM, richardwilko
[EMAIL PROTECTED]
wrote:
[ x ] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
[ x ] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
To be honest I don't see the advantage of generic components, all I want
is
to not have to do casting when I'm using models, .getModelObject() should
return the type that I put in, in a list view, if I give it a list of
strings I dont want to cast the listItem model object to a string. It
would
also be nice if the .add() and others methods on components could return
the
type of component it is rather than just a Component object. eg you cant
do
'new TextArea(...).add(some behavior).setRequired(true) because the add
behaviour method returns a Component not a TextArea and setRequired is
not
available on Components.
Thanks
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17601296.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]
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602507.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: users, please give us your opinion: what is your take on generics with Wicket
1) Generifying* Wicket [x] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. 2) How strongly do you feel about your choice above? [x] I definitively won't be using 1.4. if Wicket doesn't go for my preference. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Goes to show you that people have a tendency to reject things that they
do not understand rather than put in the effort :o)
-Original Message-
From: richardwilko [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 10:21 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
ok maybe i misread this :
'Can best be done in a limited fashion, where we only generify IModel
but not components. I care more about what generifying can do for API
clarity (declaring a component to only accept certain models for
instance) than static type checking.'
but those 2 sentences seem to contradict each other, the first says only
generify IModel which I assumed ti mean that when you put a String into
a model you would get a String out of it, the second seems to says
generifiying components to make them only accept some model types.
So just to clarify my position
generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form) {
EmailFormModel emailFormModel = (EmailFormModel)
form.getModelObject();
is what I would like to see.
generic components im not bothered about.
if using generics wont do away with the casting then I dont see any
point to using them at all.
Johan Compagner wrote:
why are you contradicting yourself?
To be honest I don't see the advantage of generic components, all I
want is to not have to do casting when I'm using models,
.getModelObject() should return the type that I put in, in a list
view, if I give it a list of strings I dont want to cast the listItem
model object to a string.
if you have just IModel then you will have to cast.. getModelObject
will always return just Object then.
ok maybe i misread
about:
new TextArea(...).add(some behavior).setRequired(true)
this can be done but then we have to override some methods of
component and then return another type The problem is that this could
result in us lifting a final where we dont want to..
But this is outside the scope of generics
johan
On Mon, Jun 2, 2008 at 3:26 PM, richardwilko
[EMAIL PROTECTED]
wrote:
[ x ] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
[ x ] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
To be honest I don't see the advantage of generic components, all I
want is to not have to do casting when I'm using models,
.getModelObject() should return the type that I put in, in a list
view, if I give it a list of strings I dont want to cast the listItem
model object to a string. It would also be nice if the .add() and
others methods on components could return the type of component it is
rather than just a Component object. eg you cant do 'new
TextArea(...).add(some behavior).setRequired(true) because the add
behaviour method returns a Component not a TextArea and setRequired
is not available on Components.
Thanks
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is
-your-take-on-generics-with-Wicket-tp17589984p17601296.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]
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo
ur-take-on-generics-with-Wicket-tp17589984p17602507.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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Mon, Jun 2, 2008 at 10:21 AM, richardwilko
[EMAIL PROTECTED] wrote:
ok maybe i misread this :
'Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.'
but those 2 sentences seem to contradict each other, the first says only
generify IModel which I assumed ti mean that when you put a String into a
model you would get a String out of it, the second seems to says
generifiying components to make them only accept some model types.
So just to clarify my position
generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form)
{
EmailFormModel emailFormModel = (EmailFormModel) form.getModelObject();
is what I would like to see.
generic components im not bothered about.
Using generics will do away with the casting, but only if you
genericize Component. Merely genericizing IModel won't get rid of the
casting by itself.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
Ok you example doesnt work..
You will need to cast there
Then IModel only only helps describing the constructor. After that you loose
the generics or you have to ofcourse keep the models and dont work anymore
directly with the components
So if we only do IModel and not component
then this will need casting or supresswarnings:
TextField tf = new TextField(id, new ModelStirng(myString));
tf.getModelObject() will return Object you need to cast to String.
tf.getModel() will return IModel? so you need to cast it and supress
warnings and that kind of stuff.
So to keep the type safety you have to do this:
ModelString model = new ModelStirng(myString);
TextField tf = new TextField(id,model );
model.getObject() this will return a String..
johan
On Mon, Jun 2, 2008 at 4:21 PM, richardwilko [EMAIL PROTECTED]
wrote:
ok maybe i misread this :
'Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.'
but those 2 sentences seem to contradict each other, the first says only
generify IModel which I assumed ti mean that when you put a String into a
model you would get a String out of it, the second seems to says
generifiying components to make them only accept some model types.
So just to clarify my position
generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form)
{
EmailFormModel emailFormModel = (EmailFormModel)
form.getModelObject();
is what I would like to see.
generic components im not bothered about.
if using generics wont do away with the casting then I dont see any point
to
using them at all.
Johan Compagner wrote:
why are you contradicting yourself?
To be honest I don't see the advantage of generic components, all I want
is
to not have to do casting when I'm using models, .getModelObject() should
return the type that I put in, in a list view, if I give it a list of
strings I dont want to cast the listItem model object to a string.
if you have just IModel then you will have to cast.. getModelObject will
always return just Object then.
ok maybe i misread
about:
new TextArea(...).add(some behavior).setRequired(true)
this can be done but then we have to override some methods of component
and
then return another type
The problem is that this could result in us lifting a final where we dont
want to..
But this is outside the scope of generics
johan
On Mon, Jun 2, 2008 at 3:26 PM, richardwilko
[EMAIL PROTECTED]
wrote:
[ x ] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
[ x ] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
To be honest I don't see the advantage of generic components, all I want
is
to not have to do casting when I'm using models, .getModelObject()
should
return the type that I put in, in a list view, if I give it a list of
strings I dont want to cast the listItem model object to a string. It
would
also be nice if the .add() and others methods on components could return
the
type of component it is rather than just a Component object. eg you
cant
do
'new TextArea(...).add(some behavior).setRequired(true) because the add
behaviour method returns a Component not a TextArea and setRequired is
not
available on Components.
Thanks
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17601296.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]
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602507.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: Feedback message related problem--info,debug etc take string arguments which is not very flexible
we havent done it yet because it is an API break. so we have been waiting for wicket1.5/2.0 whatever to do this. -igor On Mon, Jun 2, 2008 at 12:17 AM, atul singh [EMAIL PROTECTED] wrote: I can do that within a day or 2..(Meaning with the patch..).does any core dev see an issue if info,debug etc start taking Serializable as parameter like error().?? Thanks On Mon, Jun 2, 2008 at 10:48 AM, Erik van Oosten [EMAIL PROTECTED] wrote: Hi, Atul, That sounds like a reasonable request to me (I am no core member). Its best to open a new issue in Wicket's jira, preferably with a patch attached. Regards, Erik. atul singh wrote: Hi, I see that only error() feedback takes a serializabel message. This allows me to pass any java object as message and implement custom filtering of messages by components. but info,debug etc take a string and so do not help me in that kind of filtering. Actually what we have is a TabbedWizard thing, a hybrid of TabbedPanel and Wizard. We have such a requirement to target feedback messages to very specific feedback components on any of the tabs. This is also not possible by implementing this logic based on the reporting component. I wanted the implementation to be generic , just based on info encapsulated in the message. Can anyone suggest an alternative? Can the info(),debug() etc method signatures be changed to have such flexibility??? Thanks - 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: users, please give us your opinion: what is your take on generics with Wicket
yes thats why i am against Referendums (politically) :)
On Mon, Jun 2, 2008 at 4:27 PM, Hoover, William [EMAIL PROTECTED] wrote:
Goes to show you that people have a tendency to reject things that they
do not understand rather than put in the effort :o)
-Original Message-
From: richardwilko [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 10:21 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
ok maybe i misread this :
'Can best be done in a limited fashion, where we only generify IModel
but not components. I care more about what generifying can do for API
clarity (declaring a component to only accept certain models for
instance) than static type checking.'
but those 2 sentences seem to contradict each other, the first says only
generify IModel which I assumed ti mean that when you put a String into
a model you would get a String out of it, the second seems to says
generifiying components to make them only accept some model types.
So just to clarify my position
generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form) {
EmailFormModel emailFormModel = (EmailFormModel)
form.getModelObject();
is what I would like to see.
generic components im not bothered about.
if using generics wont do away with the casting then I dont see any
point to using them at all.
Johan Compagner wrote:
why are you contradicting yourself?
To be honest I don't see the advantage of generic components, all I
want is to not have to do casting when I'm using models,
.getModelObject() should return the type that I put in, in a list
view, if I give it a list of strings I dont want to cast the listItem
model object to a string.
if you have just IModel then you will have to cast.. getModelObject
will always return just Object then.
ok maybe i misread
about:
new TextArea(...).add(some behavior).setRequired(true)
this can be done but then we have to override some methods of
component and then return another type The problem is that this could
result in us lifting a final where we dont want to..
But this is outside the scope of generics
johan
On Mon, Jun 2, 2008 at 3:26 PM, richardwilko
[EMAIL PROTECTED]
wrote:
[ x ] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
[ x ] Whatever choice ultimately made, I'll happily convert/ start
using 1.4 and up.
To be honest I don't see the advantage of generic components, all I
want is to not have to do casting when I'm using models,
.getModelObject() should return the type that I put in, in a list
view, if I give it a list of strings I dont want to cast the listItem
model object to a string. It would also be nice if the .add() and
others methods on components could return the type of component it is
rather than just a Component object. eg you cant do 'new
TextArea(...).add(some behavior).setRequired(true) because the add
behaviour method returns a Component not a TextArea and setRequired
is not available on Components.
Thanks
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is
-your-take-on-generics-with-Wicket-tp17589984p17601296.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]
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-yo
ur-take-on-generics-with-Wicket-tp17589984p17602507.htmlhttp://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602507.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]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
I think its not quite that simple. Certainly both sets of components should use generics (silly to have a partial solution) but how its done is vital so that it doesn't become a huge mess. I'm one of the adopters of the M1 release and I've found it quite difficult to keep things straight sometimes. - Model objects should allow any generic needed (due tot he nature of a model). - Components should be specific about the generics they accept i.e. instance of model etc. makeing the generics clean will help us keep our code clean. - Brill Pappin Eelco Hillenius wrote: We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-generics-with-Wicket-tp17589984p17602906.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: Wicket cheat sheet, solve your wicket problem fast?
Nino makes a profit on every ad you accidently click on, trying to find the correct download link ;-) BTW, isn't the apache wiki having a Add diagram button now? Frank On Mon, Jun 2, 2008 at 3:46 PM, Brill Pappin [EMAIL PROTECTED] wrote: It's there, but tiny and hidden in among the ads (centred, middle/bottom). - Brill Pappin -Original Message- From: Ames, Tim [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 8:59 AM To: users@wicket.apache.org Subject: RE: Wicket cheat sheet, solve your wicket problem fast? Sorry, I don't understand how to access the pdf from this link -Original Message- From: Nino Saturnino Martinez Vazquez Wael [mailto:[EMAIL PROTECTED] ] Sent: Monday, June 02, 2008 4:34 AM To: users@wicket.apache.org Subject: Wicket cheat sheet, solve your wicket problem fast? Hi I've created a small wicket cheat sheet for issues and features, please see here : http://www.flyupload.com/?fid=9436254 It's based on my experience so it's certainly not complete and you should consider it a draft. Any comment will be welcome:) -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ EMAIL CONFIDENTIALITY NOTICE This Email message, and any attachments, may contain confidential patient health information that is legally protected. This information is intended only for the use of the individual or entity named above. The authorized recipient of this information is prohibited from disclosing this information to any other party unless required to do so by law or regulation and is required to destroy the information after its stated need has been fulfilled. If you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution, or action taken in reliance on the contents of this message is strictly prohibited. If you have received this information in error, please notify the sender immediately by replying to this message and delete the message from your system. - 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: users, please give us your opinion: what is your take on generics with Wicket
I'd really like to know how it's ruining my wicket experience? Can you please elaborate? I agree that the M1 release of 1.4 was less than optimum, but not having generics is annoying to people who have gotten used to using them. - Brill Pappin -Original Message- From: mozvip [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:13 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket 1) Generifying* Wicket [X] Should be avoided, definitly. All this generics stuff is ruining my wicket experience. 2) How strongly do you feel about your choice above? [X] I might rethink upgrading if my choice doesn't win. -- View this message in context: http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-t ake-on-generics-with-Wicket-tp17589984p17602298.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
Clearly :) However I think the wicket developers have to be careful here as doing wrong will make a big mess :) - Brill -Original Message- From: Hoover, William [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:27 AM To: users@wicket.apache.org Subject: RE: users, please give us your opinion: what is your take on generics with Wicket Goes to show you that people have a tendency to reject things that they do not understand rather than put in the effort :o) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
+1 -Original Message- From: Brill Pappin [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:49 AM To: users@wicket.apache.org Subject: RE: users, please give us your opinion: what is your take on generics with Wicket I don't know, I think the discussion is going *toward* generics. Frankly I can't even see why its an issue at all, the language has evolved and uses them... Why would Wicket not also use them its inline with the current state of the language? There is no reason that people who can't get their heads around Generics can't use the older releases that don't include it, but IMO any java developer who doesn't get generics yet better make some time to learn, because like it or not, they *will* be dealing with them. - Brill Pappin -Original Message- From: Matej Knopp [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:46 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. Also If i had to decide between new WebMarkupContainerVoid and new WebMarkupContainer where the later wouldn't be generified I'd certainly go for the Void alternative. -Matej On Sun, Jun 1, 2008 at 10:44 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - 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: users, please give us your opinion: what is your take on generics with Wicket
+1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 10:56 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - 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: users, please give us your opinion: what is your take on generics with Wicket
Why don't we use the Wiki page to list our *specific* gotchas we encounter and try to come up with a solution for them. My guess is that we can do so. On Mon, Jun 2, 2008 at 11:03 AM, Hoover, William [EMAIL PROTECTED] wrote: +1 I would like to see what the major issues are as to why people are rejecting model/component generics. None that I have seen so far are that convincing- especially the complaints of verbosity. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of James Carman Sent: Monday, June 02, 2008 10:56 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket On Mon, Jun 2, 2008 at 10:45 AM, Matej Knopp [EMAIL PROTECTED] wrote: I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. +1, I agree. I think this discussion might be counter-productive if folks who aren't using the generified versions are voting. - 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: users, please give us your opinion: what is your take on generics with Wicket
Hi Elco, hi Users,
first of all thanks a lot for trying generics in wicket in the first case.
I haven't really cared about em so far, too much. So thanks a lot for
the learning experience I'm going through right now.
[x] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
What currently bus me is that Components are tightly knitted together
with their class representation.
There are quite some methods that don't return the component,
but its class. Maybe most prominently 'getHomePage()' in Application.
This used to have the signature:
public abstract Class getHomePage();
And a popular implementation would be:
public Class getHomePage() {
return HomePage.class
}
So maybe in favor of that popular implementation its current signature is:
Application: public abstract Class? extends Page? getHomePage();
which is not a generic method but a method with a generified return
parameter.
But at least this works with the existing user code basis very well.
But it also implies a circle I can't break up in my mind yet.
This signature forces you to implement HomePage as a raw type, a class
without type parameters, esp. not generic.
Though on the other hand HomePage is a descendant of Component which is
generic, of course.
Which is a strong sign for HomePage to be generic too.
I think both ends don't go together well.
How is this going to be solved? Or, explained?
My tries on the signature of getHomePage() didn't really lead nowhere.
The best Try on this is:
public abstract C extends Page ClassC getHomePage();
Leaving Page and possibly Component raw.
Maybe it is enough to just generify some of Components methods?
2) How strongly do you feel about your choice above?
[x] I might rethink upgrading if my choice doesn't win.
mf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. Also If i had to decide between new WebMarkupContainerVoid and new WebMarkupContainer where the later wouldn't be generified I'd certainly go for the Void alternative. -Matej On Sun, Jun 1, 2008 at 10:44 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - 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: users, please give us your opinion: what is your take on generics with Wicket
I don't know, I think the discussion is going *toward* generics. Frankly I can't even see why its an issue at all, the language has evolved and uses them... Why would Wicket not also use them its inline with the current state of the language? There is no reason that people who can't get their heads around Generics can't use the older releases that don't include it, but IMO any java developer who doesn't get generics yet better make some time to learn, because like it or not, they *will* be dealing with them. - Brill Pappin -Original Message- From: Matej Knopp [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 10:46 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket I'm not sure I like where this discussion is going. I don't see anyone having any particular objections against current state. I think before we even think of (partially) reverting generics we have to discuss what's wrong (except the verbosity of course, but that's not something we can really do about) with current state. I use wicket with generics daily and I don't see any particular show stopper so far. Also If i had to decide between new WebMarkupContainerVoid and new WebMarkupContainer where the later wouldn't be generified I'd certainly go for the Void alternative. -Matej On Sun, Jun 1, 2008 at 10:44 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Hi all, We have had several threads in this and the dev list, and some discussions in the public on how to incorporate generics in Wicket. I'd like to use this thread to gather the opinions of as many regular Wicket users as we can. Please help us get an impression of what our users think about the issue by completing this simple survey. Note that it is not a vote; we only want to get an idea of what you think. 1) Generifying* Wicket [ ] Can best be done like currently in the 1.4 branch, where models and components are both generified. I care most about the improved static type checking generified models and components give Wicket. [ ] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. [ ] Should be avoided, I prefer the way 1.3 works. Because... (fill in your opinion here). [ ] (anything other than these choices?) 2) How strongly do you feel about your choice above? [ ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. [ ] I might rethink upgrading if my choice doesn't win. [ ] I definitively won't be using 1.4. if Wicket doesn't go for my preference. Thanks in advance for everyone participating, and pls feel free to explain yourself further beyond just answering these questions! Eelco p.s. I suggest that the core devs and most active participants and previous discussions wait a few days before giving their opinions so that we don't flood the thread right from the start. * Parameterizing would probably be the better word to use, but generifying seems to be the word that many people use. - 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: users, please give us your opinion: what is your take on generics with Wicket
On Sun, Jun 01, 2008 at 01:44:59PM -0700, Eelco Hillenius wrote: 1) Generifying* Wicket [x] Can best be done in a limited fashion, where we only generify IModel but not components. I care more about what generifying can do for API clarity (declaring a component to only accept certain models for instance) than static type checking. 2) How strongly do you feel about your choice above? [x] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. IMHO storing a model in a Component is more a convenience than a fundamental part of component-ness. This may be part of the reason that genericizing Component is so contentious. I have many components with no model and many others, such as a TextField that uses a parent's CompoundPropertyModel, the component has a model but I really don't care about the type, since I never call getModelObject(). In all these cases (which are easily the majority in my experience), genericized Components would force me to deal with the syntactic overhead of generics with absolutely zero value. I'm all for genericizing certain components for which the model is central (e.g. ListView and Item) but I think genericizing Component is overkill, since it's relatively rare that I care about the type of a component's model. jk - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: users, please give us your opinion: what is your take on generics with Wicket
I see your point... a referendum will only be as good as the current
state of the product that is being evaluated, and the expertise of those
doing the evaluation. It seems as though in this case that some of those
doing the evaluation have limited knowledge of what benefits generics
has to offer (and obviously the state of the product is incomplete- so a
released version is not what's being evaluated).
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 10:32 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
yes thats why i am against Referendums (politically) :)
On Mon, Jun 2, 2008 at 4:27 PM, Hoover, William [EMAIL PROTECTED]
wrote:
Goes to show you that people have a tendency to reject things that
they do not understand rather than put in the effort :o)
-Original Message-
From: richardwilko [mailto:[EMAIL PROTECTED]
Sent: Monday, June 02, 2008 10:21 AM
To: users@wicket.apache.org
Subject: Re: users, please give us your opinion: what is your take on
generics with Wicket
ok maybe i misread this :
'Can best be done in a limited fashion, where we only generify IModel
but not components. I care more about what generifying can do for API
clarity (declaring a component to only accept certain models for
instance) than static type checking.'
but those 2 sentences seem to contradict each other, the first says
only generify IModel which I assumed ti mean that when you put a
String into a model you would get a String out of it, the second seems
to says generifiying components to make them only accept some model
types.
So just to clarify my position
generic models which would do away with this type of casting:
protected void onSubmit(AjaxRequestTarget target, Form form) {
EmailFormModel emailFormModel = (EmailFormModel)
form.getModelObject();
is what I would like to see.
generic components im not bothered about.
if using generics wont do away with the casting then I dont see any
point to using them at all.
Johan Compagner wrote:
why are you contradicting yourself?
To be honest I don't see the advantage of generic components, all I
want is to not have to do casting when I'm using models,
.getModelObject() should return the type that I put in, in a list
view, if I give it a list of strings I dont want to cast the
listItem model object to a string.
if you have just IModel then you will have to cast.. getModelObject
will always return just Object then.
ok maybe i misread
about:
new TextArea(...).add(some behavior).setRequired(true)
this can be done but then we have to override some methods of
component and then return another type The problem is that this
could result in us lifting a final where we dont want to..
But this is outside the scope of generics
johan
On Mon, Jun 2, 2008 at 3:26 PM, richardwilko
[EMAIL PROTECTED]
wrote:
[ x ] Can best be done in a limited fashion, where we only
generify
IModel but not components. I care more about what generifying can
do for API clarity (declaring a component to only accept certain
models for instance) than static type checking.
[ x ] Whatever choice ultimately made, I'll happily convert/
start
using 1.4 and up.
To be honest I don't see the advantage of generic components, all I
want is to not have to do casting when I'm using models,
.getModelObject() should return the type that I put in, in a list
view, if I give it a list of strings I dont want to cast the
listItem
model object to a string. It would also be nice if the .add() and
others methods on components could return the type of component it
is
rather than just a Component object. eg you cant do 'new
TextArea(...).add(some behavior).setRequired(true) because the add
behaviour method returns a Component not a TextArea and setRequired
is not available on Components.
Thanks
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-
is -your-take-on-generics-with-Wicket-tp17589984p17601296.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]
--
View this message in context:
http://www.nabble.com/users%2C-please-give-us-your-opinion%3A-what-is-
yo
ur-take-on-generics-with-Wicket-tp17589984p17602507.htmlhttp://www.na
bble.com/users%2C-please-give-us-your-opinion%3A-what-is-your-take-on-
generics-with-Wicket-tp17589984p17602507.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional
Re: users, please give us your opinion: what is your take on generics with Wicket
Hi Elco, hi Users,
first of all thanks a lot for trying generics in wicket in the first case.
I haven't really cared about em so far, too much. So thanks a lot for
the learning experience I'm going through right now.
[x] Can best be done in a limited fashion, where we only generify
IModel but not components. I care more about what generifying can do
for API clarity (declaring a component to only accept certain models
for instance) than static type checking.
As I see it generifying component far of being elegant yet.
Components are tightly knitted together with their class representation.
There are quite some methods that don't return the component,
but its class. Maybe most prominently 'getHomePage()' in Application.
This used to have the signature:
public abstract Class getHomePage();
And a popular implementation would be:
public Class getHomePage() {
return HomePage.class
}
So maybe in favor of that popular implementation its current signature is:
Application: public abstract Class? extends Page? getHomePage();
which is not a generic method but a method with a generified return
parameter.
But at least this works with the existing user code basis very well.
But it also implies a circle I can't break up in my mind yet.
This signature forces you to implement HomePage as a raw type, a class
without type parameters, esp. not generic.
Though on the other hand HomePage is a descendant of Component which is
generic, of course.
Which is a strong sign for HomePage to be generic too.
I think both ends don't go together well.
How is this going to be solved? Or, explained?
My tries on the signature of getHomePage() didn't really lead nowhere.
The best Try on this is:
public abstract C extends Page ClassC getHomePage();
Leaving Page and possibly Component raw.
Maybe it is enough to just generify some of Components methods?
2) How strongly do you feel about your choice above?
[x] I might rethink upgrading if my choice doesn't win.
mf
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
