Re: users, please give us your opinion: what is your take on generics with Wicket
On Tue, Jun 3, 2008 at 10:37 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: i think we should have qualified this rfi with a requirement that responders use 1.4 on a non-trivial project...these things only become apparent from real-world day-to-day usage. anything else is pretty much speculation. Well, like I stated I just wanted to get a hunch of what people think, not so much an informed discussion. I think it is very clear now that whatever choice we'll ultimately stick to, it will make part of our user base unhappy, and might have to do some evangelizing to get the changes accepted by everyone (or most) :-) As for speculation... I don't agree. I haven't converted yet, but it is easy enough to just look at any old piece of code I'm working on now and imagine what it will look like after changing to 1.4. Eelco - 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 Tue, Jun 3, 2008 at 11:30 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 10:37 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: i think we should have qualified this rfi with a requirement that responders use 1.4 on a non-trivial project...these things only become apparent from real-world day-to-day usage. anything else is pretty much speculation. As for speculation... I don't agree. I haven't converted yet, but it is easy enough to just look at any old piece of code I'm working on now and imagine what it will look like after changing to 1.4. and there are also a lot of pain points that you will not imagine that do exist :) i am wondering how many of the keep as is in trunk votes came from people who only imagined what their code would look like and havent actually hit the numerous pain points those of us who did code gainst it hit. i was of the generify component and model mind while i was generifying the framework, but after coding against it i began to see some of the ugliness and now my mind is almost changed. -igor Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Ajax-on-click-somewhere-else?
Doesnt the YUI and dojo contrib do this already?
gurgel2 wrote:
I want to do a popup menu (using a z-indexed layer) that should closed if i
click anywhere, EXCEPT on the menu itself.
Its the close behavior I need to know. Everything but that, is clear to
me. A similar behavior to a opened desktop app File,Edit, .. Help menu
or a context menu (not opened with right button ofcourse).
Maybe something like...
final MyMenu myMenu = ...
getPage().add(new AjaxEventBehavior(onclick)
{
void onEvent(AjaxRequestTarget target) {
myMenu.setVisibible(false);
target.addComponent(myMenu);
}
});
...but than then I have to deal with the exclusion of click events on my
menu popup layer. Any better ideas?
/Kalle
--
-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: users, please give us your opinion: what is your take on generics with Wicket
i was of the generify component and model mind while i was generifying the framework, but after coding against it i began to see some of the ugliness and now my mind is almost changed. yep, day to day usage is the main point. i came to that conclusion as well when i was trying to migrate somewhat non-trivial use of wicket to 1.4 base. the standard components like link et al aren't the real problem (though it doesn't look pretty), it gets complicated when you're using non-trivial components (like datatable and their dependents) where the type on the component gets in your way. - 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
Igor Vaynberg wrote
i am wondering how many of the keep as is in trunk votes came from
people who only imagined what their code would look like and havent
actually hit the numerous pain points those of us who did code gainst
it hit.
I'm one of the keep as is in trunk users and I use 1.4 trunk from the
beginning. I use it in a big real world application. But: I am one of
the former 2.0 users and accustomed to generic Components in Wicket.
Maybe I have made my workaround strategy for some generic problems more
than a year ago.
One experience I made was that I realized that I made no use of Models
when I startet using Wicket from 1.0. Instead of having
public class MyPanel extends PanelMyData
public MyPanel(String id, IModelMyData model) {
...
I used constructs like
public class MyPanel extends Panel
public MyPanel(String id, MyData myData) {
...
like I was used to do in other frameworks. The second one was the only
way to have a typesafe treatment of MyData when Model was non generic.
It took a while to realize that the Models in Wicket are very usefull
thing and the tight Component-Model coupling leads to better
Applications
Maybe the posts like I do not use Models or Only 20% or our
components have Models come from the same background as my early wicket
adoption.
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: setPageExpiredErrorPage(PageExpired.class) - Login page loaded instead of PageExpired page
I thought it better to reply here, so everyone can find it back later :) As said before by default any self especting authorization strategy will redirect to a login page if it detects that the user is not authorized for the page / component currently being created. So the trick is to make sure that error pages like PageExpiredErrorPage are always authorized, how to do that depends on the framework of your choice. In the case of wicket-auth-roles there are potentially 2 places this happens: AnnotationsRoleAuthorizationStrategy#isInstantiationAuthorized MetaDataRoleAuthorizationStrategy#isInstantiationAuthorized I suggest placing a breakpoint in both places and step through to see what is denying the pageexpiredpage to instantiate. Also if you are building custom errorpages it always is a good idea to override isErrorPage to return true. (could not tell if that is what you are doing, but just in case) As for documentation for wicket-auth-roles: i am only aware of http://cwiki.apache.org/WICKET/acegi-and-wicket-auth-roles.html which has a slightly different focus then what you need :) of course you could always check the examples. Maurice On Wed, Jun 4, 2008 at 1:50 AM, mfs [EMAIL PROTECTED] wrote: I am facing a similar issue, can someone direct me to right documentation, as to how to redirect to sessionExpiredPage instead of login page if session has expired.. jd17 wrote: 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-tp17596262p17636338.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]
Inmethod grid: Paging calls DataSource.query twice
Hi Please can someone let me know if it is bug or if there is a reason why when paging using the inmethod data grid, two calls are made to the datasource, one to get the current page's data and one to get the data for the page that you are navigating to. Setting a breakpoint on the datasource.query method and selecting next or previous on the data grid should highlight this, but I have not yet worked out why it should be called twice or how to avoid it being called twice. (I am testing with a fairly recent snapshot of the DefaultDataGrid (a svn diff on the subsequent revisions does not appear to show any fixes for this), but assume it would be the same for the other types of grid too) Thanks Mike -- View this message in context: http://www.nabble.com/Inmethod-grid%3A-Paging-calls-DataSource.query-twice-tp17640908p17640908.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-auth-roles - Redirect to LoginPage instead of SessionExpiry Page
See my reply in the other thread. Oh and next time could you keep it to one thread ;) thanks. Maurice On Wed, Jun 4, 2008 at 3:12 AM, mfs [EMAIL PROTECTED] wrote: Guys, I am using wicket-auth-roles which so far is working greaet serving all my purposes. Though I am stuck in this scenario where when the session-expiry has reached, instead of being redirected to the SessionExpiryPage, i get redirected to the loginPage, now in one of the threads it was commented that this is probably is the default behavior with auth-roles (where it doesnt let the pageexpired instance to be constructed), unless we configure the security settings accordingly. Now am not able to figure as to how exactly the security settings are to be configured, i also havent come across any example/documentation where this has been discussed... Any help would appreciated.. Thanks in advance.. -- View this message in context: http://www.nabble.com/wicket-auth-roles---Redirect-to-LoginPage-instead-of-SessionExpiry-Page-tp17637202p17637202.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: (Class? extends Page?) casting troubles
Hi, I'm getting inconvertible type errors when I compile from Maven on the command line with Java 6. Does anyone know if this issue was resolved ? I am building against 1.4-m2 - downloaded today (04-06-2008). The issue is the same as noted by Ryan Mckinley on 05/21/2008 : strangely, things work fine for me in eclipse, but from the command line, I still get: $ mvn clean install: /Users/ryan/Documents/workspace/dexter/website/src/java/dexter/website/ wicket/page/DownloadingPage.java:[18,97] inconvertible types found : java.lang.Classdexter.website.wicket.page.account.DexSignInPage required: java.lang.Class? extends org.apache.wicket.Page? I ran: mvn clean install in the wicket directory... Not sure if the java version is helpful: ryan$ mvn -version Maven version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp Thanks, Rod. NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Group Limited or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Group Limited does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Group Limited.
Re: (Class? extends Page?) casting troubles
Yeah it is very strange that you get different errors in eclipse and javac. I wonder which one is correcct.. But you have to generify the Page then it should work fine (like Void) I think we just need to drop the ? in that example What do you exactly call? johan On Wed, Jun 4, 2008 at 9:39 AM, Rod Good [EMAIL PROTECTED] wrote: Hi, I'm getting inconvertible type errors when I compile from Maven on the command line with Java 6. Does anyone know if this issue was resolved ? I am building against 1.4-m2 - downloaded today (04-06-2008). The issue is the same as noted by Ryan Mckinley on 05/21/2008 : strangely, things work fine for me in eclipse, but from the command line, I still get: $ mvn clean install: /Users/ryan/Documents/workspace/dexter/website/src/java/dexter/website/ wicket/page/DownloadingPage.java:[18,97] inconvertible types found : java.lang.Classdexter.website.wicket.page.account.DexSignInPage required: java.lang.Class? extends org.apache.wicket.Page? I ran: mvn clean install in the wicket directory... Not sure if the java version is helpful: ryan$ mvn -version Maven version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp Thanks, Rod. NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Group Limited or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Group Limited does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Group Limited.
Re: Example of wicketstuff-minis' Veil
I think I ran into that problem with veil too... Igor Vaynberg wrote: can you paste the stack trace please? are you using latest trunk? -igor On Tue, Jun 3, 2008 at 6:38 AM, nitinkc [EMAIL PROTECTED] wrote: I need an example of wicketstuff-minis' veil behavior. I added this to one of my components but keep getting the error that the behavior is already bound to another component and cannot be reused. All I am doing is: Button button = new Button(test); button.add(new Veil()); form.add(button); This is the only Veil I am using on my page. Thanks. -- View this message in context: http://www.nabble.com/Example-of-wicketstuff-minis%27-Veil-tp17623741p17623741.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] -- -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
sure will take a look...thanks Mr Mean wrote: I thought it better to reply here, so everyone can find it back later :) As said before by default any self especting authorization strategy will redirect to a login page if it detects that the user is not authorized for the page / component currently being created. So the trick is to make sure that error pages like PageExpiredErrorPage are always authorized, how to do that depends on the framework of your choice. In the case of wicket-auth-roles there are potentially 2 places this happens: AnnotationsRoleAuthorizationStrategy#isInstantiationAuthorized MetaDataRoleAuthorizationStrategy#isInstantiationAuthorized I suggest placing a breakpoint in both places and step through to see what is denying the pageexpiredpage to instantiate. Also if you are building custom errorpages it always is a good idea to override isErrorPage to return true. (could not tell if that is what you are doing, but just in case) As for documentation for wicket-auth-roles: i am only aware of http://cwiki.apache.org/WICKET/acegi-and-wicket-auth-roles.html which has a slightly different focus then what you need :) of course you could always check the examples. Maurice On Wed, Jun 4, 2008 at 1:50 AM, mfs [EMAIL PROTECTED] wrote: I am facing a similar issue, can someone direct me to right documentation, as to how to redirect to sessionExpiredPage instead of login page if session has expired.. jd17 wrote: 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-tp17596262p17636338.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/setPageExpiredErrorPage%28PageExpired.class%29--%3E-Login-page-loaded-instead-of-PageExpired-page-tp17596262p17641471.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
it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: (Class? extends Page?) casting troubles
I remember that having more than one wildcard in an type expression seems to be inherently broken. Usually you can rewrite something like void foo(Class? extends Page? pageClass) into something like X extends Page? void foo(ClassX pageClass) I would bet this solves your problem :-) However, nobody can explain why... :-( Probably some lack of the generics specification, broken compiler, or whatever... I would suggest to avoid more than one wildcard in one type expression in general and use above workaround. Cheers Peter Am 04.06.2008 um 10:10 schrieb Johan Compagner: Yeah it is very strange that you get different errors in eclipse and javac. I wonder which one is correcct.. But you have to generify the Page then it should work fine (like Void) I think we just need to drop the ? in that example What do you exactly call? johan On Wed, Jun 4, 2008 at 9:39 AM, Rod Good [EMAIL PROTECTED] wrote: Hi, I'm getting inconvertible type errors when I compile from Maven on the command line with Java 6. Does anyone know if this issue was resolved ? I am building against 1.4-m2 - downloaded today (04-06-2008). The issue is the same as noted by Ryan Mckinley on 05/21/2008 : strangely, things work fine for me in eclipse, but from the command line, I still get: $ mvn clean install: /Users/ryan/Documents/workspace/dexter/website/src/java/dexter/ website/ wicket/page/DownloadingPage.java:[18,97] inconvertible types found : java.lang.Classdexter.website.wicket.page.account.DexSignInPage required: java.lang.Class? extends org.apache.wicket.Page? I ran: mvn clean install in the wicket directory... Not sure if the java version is helpful: ryan$ mvn -version Maven version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp Thanks, Rod. NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Group Limited or third parties. If you are not the intended recipient of this email you should not read, print, re- transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Group Limited does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Group Limited. - 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 the only real other way is what is already possible Just dont keep references to the Component (just add them to there parents) and keep references to the models of those components. and work with models only johan On Wed, Jun 4, 2008 at 10:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket cheat sheet, solve your wicket problem fast?
It appears that we can't do so much at the moment. What you can do is to fax a CLA to Apache[0] and when that is registered then you should be part of the asf-cla group which now has the appropriate rights to add attachments. Frank [0]: http://www.apache.org/licenses/#clas On Tue, Jun 3, 2008 at 10:27 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: great. Frank is working on the diagram stuff, to be able to give clearance to me i think. Gwyn Evans wrote: On Tue, Jun 3, 2008 at 8:25 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: argh! It's very clean on the upload side of stuff. Anyway when we get confluence sorted out i'll put the diagram on this page : I've put the 2nd version up as an attatchment now. /Gwyn - 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: Inmethod grid: Paging calls DataSource.query twice
Hi, it shouldn't be called twice. I'll take a look into it. -Matej On Wed, Jun 4, 2008 at 9:36 AM, RUMikeP [EMAIL PROTECTED] wrote: Hi Please can someone let me know if it is bug or if there is a reason why when paging using the inmethod data grid, two calls are made to the datasource, one to get the current page's data and one to get the data for the page that you are navigating to. Setting a breakpoint on the datasource.query method and selecting next or previous on the data grid should highlight this, but I have not yet worked out why it should be called twice or how to avoid it being called twice. (I am testing with a fairly recent snapshot of the DefaultDataGrid (a svn diff on the subsequent revisions does not appear to show any fixes for this), but assume it would be the same for the other types of grid too) Thanks Mike -- View this message in context: http://www.nabble.com/Inmethod-grid%3A-Paging-calls-DataSource.query-twice-tp17640908p17640908.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]
Problem: Check within a ListView
Hi,
I have a ListView nested in a CheckGroup which works actually fine. In some
cases I have to disable (or make invisible) a certain Check within the
Checkgroup. e.g.
CheckGroup roleGroup = new CheckGroup(roles);
add(roleGroup);
roleGroup.add(new CheckGroupSelector(selector));
ListView roleList = new ListView(role-list, new DetachableRolesModel()) {
@Override
protected void populateItem(final ListItem item) {
Check check = new Check(check, item.getModel());
item.add(check);
item.add(new Label(role,
new PropertyModel(item.getModel(), value)));
if (condition) {
check.setEnabled(false);
}
}
};
roleList.setReuseItems(true);
roleGroup.add(roleList);
The problem is that the disabled item is removed from my model while
submitting the form although the disabled checkbox is checked. A disabled
and checked checkbox should not yield to the same result as a enabled and
unchecked checkbox. If I modify it to check.setEnabled(true); everything
works fine. Same with setVisibiliy().
What am I doing wrong?
Kai
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket cheat sheet, solve your wicket problem fast?
It looks like I can also email a scanned copy, but to where do I email? Frank Bille wrote: It appears that we can't do so much at the moment. What you can do is to fax a CLA to Apache[0] and when that is registered then you should be part of the asf-cla group which now has the appropriate rights to add attachments. Frank [0]: http://www.apache.org/licenses/#clas On Tue, Jun 3, 2008 at 10:27 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: great. Frank is working on the diagram stuff, to be able to give clearance to me i think. Gwyn Evans wrote: On Tue, Jun 3, 2008 at 8:25 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: argh! It's very clean on the upload side of stuff. Anyway when we get confluence sorted out i'll put the diagram on this page : I've put the 2nd version up as an attatchment now. /Gwyn - 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] -- -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: Wicket cheat sheet, solve your wicket problem fast?
secretary@ it says in that page. Frank On Wed, Jun 4, 2008 at 11:53 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: It looks like I can also email a scanned copy, but to where do I email? Frank Bille wrote: It appears that we can't do so much at the moment. What you can do is to fax a CLA to Apache[0] and when that is registered then you should be part of the asf-cla group which now has the appropriate rights to add attachments. Frank [0]: http://www.apache.org/licenses/#clas On Tue, Jun 3, 2008 at 10:27 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: great. Frank is working on the diagram stuff, to be able to give clearance to me i think. Gwyn Evans wrote: On Tue, Jun 3, 2008 at 8:25 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: argh! It's very clean on the upload side of stuff. Anyway when we get confluence sorted out i'll put the diagram on this page : I've put the 2nd version up as an attatchment now. /Gwyn - 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] -- -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]
How to use the NavOMatic?
Hi, we have developed a framework with a bunch of sites, each in a own package. What we need is a navigation bar, in the functionality of navomatic, which works. Our problems with navomatic are the following: 1)You have to define the wicket:links only in the html, and the pages have to be in the same directory. Is there a roundtrip to point to pages in other packages? 2)The examplepages are too simple, to get information from (no other wicket elements): In the html you have to put all your site contents hierarchical under your naviBorder element. But how do I preserve the same hierarchy in the java file where I add(new NaviBorder(naviBorder)); How do I get the hiererchy under this element? -- View this message in context: http://www.nabble.com/How-to-use-the-NavOMatic--tp17643614p17643614.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
On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. We discussed this on ##wicket yesterday. I asked why we have models on all components and someone pointed out that the main reason was about the detach stuff I believe. But, couldn't that be solved by having some components that implement something like IModelDriven (or IModelBacked or whatever) and the detach logic could apply to only those components? Also, someone has pointed out that when they create their own components, they sometimes (such as in Palette) have multiple models that they deal with. Allowing components to name their models what they want would be nice, too. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: What is cool on Wicket?
Thanks Gwyn and John, Anyway, here's what I wrote up till now: Clean / clear separation of presentation and logic Supports Ajax Security Enabling reuse Manages state Markup inheritance }POJO for logic No XML, no configuration files Stateful i18n Manipulate HTML tags and header via Java Any thought about this list? On Tue, Jun 3, 2008 at 11:10 PM, John Krasnay [EMAIL PROTECTED] wrote: One big selling point for me was the encapsulation of components. Because the code and all required resources (markup, CSS, JS, localization properties) are by default retrieved from the classpath, it's trivial to create reusable libraries of common components, page layouts, etc. jk On Tue, Jun 03, 2008 at 10:37:50PM +0300, Eyal Golan wrote: Hi, I'm going to give an intro presentation about Wicket at my home company (I work as an outsource). There are so many cool things in Wicket and I probably know some / most of them. Can you give your advice / thoughts? Things like Ajax support, markup inheritance, POJO usage, clear and clean separation of view and logic, learning curve etc. Thanks -- Eyal Golan [EMAIL PROTECTED] Visit: http://jvdrums.sourceforge.net/ LinkedIn: http://www.linkedin.com/in/egolan74 - 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 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket cheat sheet, solve your wicket problem fast?
doh, dont make me think again:) Thats the nice thing with wicket. I get the point though Frank Bille wrote: secretary@ it says in that page. Frank On Wed, Jun 4, 2008 at 11:53 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: It looks like I can also email a scanned copy, but to where do I email? Frank Bille wrote: It appears that we can't do so much at the moment. What you can do is to fax a CLA to Apache[0] and when that is registered then you should be part of the asf-cla group which now has the appropriate rights to add attachments. Frank [0]: http://www.apache.org/licenses/#clas On Tue, Jun 3, 2008 at 10:27 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: great. Frank is working on the diagram stuff, to be able to give clearance to me i think. Gwyn Evans wrote: On Tue, Jun 3, 2008 at 8:25 AM, Nino Saturnino Martinez Vazquez Wael [EMAIL PROTECTED] wrote: argh! It's very clean on the upload side of stuff. Anyway when we get confluence sorted out i'll put the diagram on this page : I've put the 2nd version up as an attatchment now. /Gwyn - 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] -- -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] -- -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: users, please give us your opinion: what is your take on generics with Wicket
There are also implementation issues that need to be considered. Currently the model is stored in a way that it doesn't take any place when not used. Having multiple models is rare, however, having one model that can (but doesn't have to) be used is more common imho. Wicket is kinda optimized for the later, so if you don't use the model there is no runtime cost associated. If we didn't have default model slot this would be more difficult to achieve. -Matej On Wed, Jun 4, 2008 at 12:37 PM, James Carman [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. We discussed this on ##wicket yesterday. I asked why we have models on all components and someone pointed out that the main reason was about the detach stuff I believe. But, couldn't that be solved by having some components that implement something like IModelDriven (or IModelBacked or whatever) and the detach logic could apply to only those components? Also, someone has pointed out that when they create their own components, they sometimes (such as in Palette) have multiple models that they deal with. Allowing components to name their models what they want would be nice, too. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
[FINALISED SCHEDULE] London Wicket Event at Google UK, tonight
Here's the schedule for tonight: 18:15 Pizza 18:30 Cemal - Welcome, Schedule 18:35 Richard - Wicket Overlay Panel For Google Maps 19:00 Cemal Al - Round the room (30 seconds each: introduction, what you are doing with Wicket) 19:15 Cemal - Announcements/Draw details and then More Control Using Select And SelectOption 19:30 Ian - Stateless vs Stateful 19:50 A short break a little bit of easy mingling 20:00 Wille - Using The 'Open Session In View' (OSIV) Pattern For Wicket Applications 20:30 Al - Wicket Photo Gallery followed by a bit of QA and a trip to a local recreational establishment. Regards - Cemal http://jWeekend.co.uk http://jWeekend.co.uk jWeekend wrote: ... not to mention our free draw for 3 pre-paid http://manning.com/dashorst/ Wicket In Action MEAP licences. I've looked through all the presentations now (all except Al's that is), including Ian's talk on Stateless vs Statefull that we may also squeeze in as a bonus (time permitting) but that could be one for next time as our agenda is already bursting at the seams with goodness; we have got some top material again. And, Al's talk is bound to impress us all, as usual. We'll need to get going at 18:30 sharp to fit it all in, so try to get there by 18:15 if you fancy a slice of pizza (and a bit earlier if you fancy two) too. There are still places available (and a couple of you have not confirmed yet), so you can still http://www.jweekend.com/dev/LWUGReg/ register . See you tomorrow. Regards - Cemal http://jWeekend.co.uk http://jWeekend.co.uk Al Maw wrote: Hi folks, Quick reminder that we're hosting another London Wicket event *this Wednesday* at Google's London office. It's looking like it might well be the best one to date, with a bunch of really interesting stuff and some cracking talks. Lots of cool stuff is lined up: - *Richard Wilkinson http://www.richard-wilkinson.co.uk/* on Wicket Google Maps controls and mash-ups. - *Wille Faler http://faler.wordpress.com/* talking how to get the OpenSessionInView enterprise pattern working in your Wicket app. - *Cemal Bayramoglu http://jweekend.co.uk* demonstrating how to tame your drop downs and make them behave just so. - *Al Maw http://herebebeasties.com* walking you through an entire crazy-cool AJAX-heavy app, using some of the components previously created for past London Wicket talks. As usual there will be: - Lots of pizza. - A visit to the pub afterwards. - People to help you out with any thorny Wicket issues you may be having (bring your code!). In short, it's shaping up to be rather ace. You should come. *You'll need to sign up, which you can do here: * http://jweekend.co.uk/dev/LWUGReg/ A reminder: talks and code from previous events available here: http://londonwicket.org Hope to see you there! Best regards, Al Cemal -- View this message in context: http://www.nabble.com/Reminder%3A-London-Wicket-event-at-Google-UK-on-Wednesday-tp17605619p17644831.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: [FINALISED SCHEDULE] London Wicket Event at Google UK, tonight
Is there a webcast? I'm interested in the Stateless vs. Stateful On Wed, Jun 4, 2008 at 7:48 AM, jWeekend [EMAIL PROTECTED] wrote: Here's the schedule for tonight: 18:15 Pizza 18:30 Cemal - Welcome, Schedule 18:35 Richard - Wicket Overlay Panel For Google Maps 19:00 Cemal Al - Round the room (30 seconds each: introduction, what you are doing with Wicket) 19:15 Cemal - Announcements/Draw details and then More Control Using Select And SelectOption 19:30 Ian - Stateless vs Stateful 19:50 A short break a little bit of easy mingling 20:00 Wille - Using The 'Open Session In View' (OSIV) Pattern For Wicket Applications 20:30 Al - Wicket Photo Gallery followed by a bit of QA and a trip to a local recreational establishment. Regards - Cemal http://jWeekend.co.uk http://jWeekend.co.uk jWeekend wrote: ... not to mention our free draw for 3 pre-paid http://manning.com/dashorst/ Wicket In Action MEAP licences. I've looked through all the presentations now (all except Al's that is), including Ian's talk on Stateless vs Statefull that we may also squeeze in as a bonus (time permitting) but that could be one for next time as our agenda is already bursting at the seams with goodness; we have got some top material again. And, Al's talk is bound to impress us all, as usual. We'll need to get going at 18:30 sharp to fit it all in, so try to get there by 18:15 if you fancy a slice of pizza (and a bit earlier if you fancy two) too. There are still places available (and a couple of you have not confirmed yet), so you can still http://www.jweekend.com/dev/LWUGReg/ register . See you tomorrow. Regards - Cemal http://jWeekend.co.uk http://jWeekend.co.uk Al Maw wrote: Hi folks, Quick reminder that we're hosting another London Wicket event *this Wednesday* at Google's London office. It's looking like it might well be the best one to date, with a bunch of really interesting stuff and some cracking talks. Lots of cool stuff is lined up: - *Richard Wilkinson http://www.richard-wilkinson.co.uk/* on Wicket Google Maps controls and mash-ups. - *Wille Faler http://faler.wordpress.com/* talking how to get the OpenSessionInView enterprise pattern working in your Wicket app. - *Cemal Bayramoglu http://jweekend.co.uk* demonstrating how to tame your drop downs and make them behave just so. - *Al Maw http://herebebeasties.com* walking you through an entire crazy-cool AJAX-heavy app, using some of the components previously created for past London Wicket talks. As usual there will be: - Lots of pizza. - A visit to the pub afterwards. - People to help you out with any thorny Wicket issues you may be having (bring your code!). In short, it's shaping up to be rather ace. You should come. *You'll need to sign up, which you can do here: * http://jweekend.co.uk/dev/LWUGReg/ A reminder: talks and code from previous events available here: http://londonwicket.org Hope to see you there! Best regards, Al Cemal -- View this message in context: http://www.nabble.com/Reminder%3A-London-Wicket-event-at-Google-UK-on-Wednesday-tp17605619p17644831.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
soo
interface IModelComponentT
{
public IModelT getModel()
}
and remove getModel/getModelObject methods from component itself?
But then everybody that does use models have to implement it..
On Wed, Jun 4, 2008 at 12:37 PM, James Carman [EMAIL PROTECTED]
wrote:
On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
it all depends, on how and what you're developing.
Yeah. I actually use less and less models in the regular way nowadays.
I use plenty of panels (the app I work on hardly uses separate pages)
that nest other panels in them (typically detail views or dialogs)
that reuse models of the parent. But indeed YMMV.
Personally, I think the whole generics business exposes that the
one-one relation between components and models is flawed. Without
generics this isn't much of a problem, just the odd unused member and
constructor, but as generics aren't as 'optional' it is all very in
your face suddenly.
I think on the longer term (post 1.4) we should re-think how models
work in Wicket. See if we can find an elegant way to make this more
flexible (I'm not in favor of the id based thing someone posted
earlier btw) without breaking the whole world.
We discussed this on ##wicket yesterday. I asked why we have models
on all components and someone pointed out that the main reason was
about the detach stuff I believe. But, couldn't that be solved by
having some components that implement something like IModelDriven (or
IModelBacked or whatever) and the detach logic could apply to only
those components? Also, someone has pointed out that when they create
their own components, they sometimes (such as in Palette) have
multiple models that they deal with. Allowing components to name
their models what they want would be nice, too.
FWIW, I'm still on the fence when it comes to whether we should go for
a full or partial (models only) implementation of generics, though I'm
leaning towards partial.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
I don't really think this is the right discussion we should be having now :)
Maybe 1.5 would be the right release for changes like that (if they
are justified, which i'm not really convinced it is. Anyway, as I said
before, storing (single) model in component has no overhead, so I
don't really see the point. Maybe we could make the methods protected
and components that actually use the default model would make them
public, dunno.
-Matej
On Wed, Jun 4, 2008 at 1:59 PM, Johan Compagner [EMAIL PROTECTED] wrote:
soo
interface IModelComponentT
{
public IModelT getModel()
}
and remove getModel/getModelObject methods from component itself?
But then everybody that does use models have to implement it..
On Wed, Jun 4, 2008 at 12:37 PM, James Carman [EMAIL PROTECTED]
wrote:
On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
it all depends, on how and what you're developing.
Yeah. I actually use less and less models in the regular way nowadays.
I use plenty of panels (the app I work on hardly uses separate pages)
that nest other panels in them (typically detail views or dialogs)
that reuse models of the parent. But indeed YMMV.
Personally, I think the whole generics business exposes that the
one-one relation between components and models is flawed. Without
generics this isn't much of a problem, just the odd unused member and
constructor, but as generics aren't as 'optional' it is all very in
your face suddenly.
I think on the longer term (post 1.4) we should re-think how models
work in Wicket. See if we can find an elegant way to make this more
flexible (I'm not in favor of the id based thing someone posted
earlier btw) without breaking the whole world.
We discussed this on ##wicket yesterday. I asked why we have models
on all components and someone pointed out that the main reason was
about the detach stuff I believe. But, couldn't that be solved by
having some components that implement something like IModelDriven (or
IModelBacked or whatever) and the detach logic could apply to only
those components? Also, someone has pointed out that when they create
their own components, they sometimes (such as in Palette) have
multiple models that they deal with. Allowing components to name
their models what they want would be nice, too.
FWIW, I'm still on the fence when it comes to whether we should go for
a full or partial (models only) implementation of generics, though I'm
leaning towards partial.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
recursive component
Hi guys! I need to make generate something like this dynamically: div wicket:id=level1 !-- node component -- div !-- caption -- span wicket:id=text / /div div style=margin-left: 24px; !-- children -- div wicket:id=level2-1 !-- node component -- div !-- caption -- a href=# wicket:id=linkselect/a /div div style=margin-left: 24px; !-- children -- div wicket:id=level3 !-- node component -- div !-- caption -- span wicket:id=name / /div div style=margin-left: 24px; !-- children -- /div /div /div /div div wicket:id=level2-2 !-- node component -- div !-- caption -- span wicket:id=text / /div div style=margin-left: 24px; !-- children -- /div /div /div /div This is a tree for which every node has a caption and children. Can I create a wicket component for the tree node that supports my example? I need a component that behaves like the Loop but in a recursive way :) Best regards, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: [FINALISED SCHEDULE] London Wicket Event at Google UK, tonight
We've had mixed success with our video technology - we will try again tonight. I suggested the topic to Ian, who kindly put some thoughts down for a brief presentation. Having seen the slides, it seems the key points are now covered, but I find this is an area where there is a lack of clear definitions/advice (in one place anyway) and is a constant source of questions from our students. If someone has any resources, or wants to make a list of the main points to consider (login page/hotspot, bookmarkability, scalability, page-params, stateless hints etc...) apart from the useful links to the wiki-page, please feel free to reply to this post of to start a new thread - I'm sure the information collected will help many. Regards - Cemal http://jWekend.co.uk http://jWekend.co.uk jwcarman wrote: Is there a webcast? I'm interested in the Stateless vs. Stateful On Wed, Jun 4, 2008 at 7:48 AM, jWeekend [EMAIL PROTECTED] wrote: Here's the schedule for tonight: 18:15 Pizza 18:30 Cemal - Welcome, Schedule 18:35 Richard - Wicket Overlay Panel For Google Maps 19:00 Cemal Al - Round the room (30 seconds each: introduction, what you are doing with Wicket) 19:15 Cemal - Announcements/Draw details and then More Control Using Select And SelectOption 19:30 Ian - Stateless vs Stateful 19:50 A short break a little bit of easy mingling 20:00 Wille - Using The 'Open Session In View' (OSIV) Pattern For Wicket Applications 20:30 Al - Wicket Photo Gallery followed by a bit of QA and a trip to a local recreational establishment. Regards - Cemal http://jWeekend.co.uk http://jWeekend.co.uk jWeekend wrote: ... not to mention our free draw for 3 pre-paid http://manning.com/dashorst/ Wicket In Action MEAP licences. I've looked through all the presentations now (all except Al's that is), including Ian's talk on Stateless vs Statefull that we may also squeeze in as a bonus (time permitting) but that could be one for next time as our agenda is already bursting at the seams with goodness; we have got some top material again. And, Al's talk is bound to impress us all, as usual. We'll need to get going at 18:30 sharp to fit it all in, so try to get there by 18:15 if you fancy a slice of pizza (and a bit earlier if you fancy two) too. There are still places available (and a couple of you have not confirmed yet), so you can still http://www.jweekend.com/dev/LWUGReg/ register . See you tomorrow. Regards - Cemal http://jWeekend.co.uk http://jWeekend.co.uk Al Maw wrote: Hi folks, Quick reminder that we're hosting another London Wicket event *this Wednesday* at Google's London office. It's looking like it might well be the best one to date, with a bunch of really interesting stuff and some cracking talks. Lots of cool stuff is lined up: - *Richard Wilkinson http://www.richard-wilkinson.co.uk/* on Wicket Google Maps controls and mash-ups. - *Wille Faler http://faler.wordpress.com/* talking how to get the OpenSessionInView enterprise pattern working in your Wicket app. - *Cemal Bayramoglu http://jweekend.co.uk* demonstrating how to tame your drop downs and make them behave just so. - *Al Maw http://herebebeasties.com* walking you through an entire crazy-cool AJAX-heavy app, using some of the components previously created for past London Wicket talks. As usual there will be: - Lots of pizza. - A visit to the pub afterwards. - People to help you out with any thorny Wicket issues you may be having (bring your code!). In short, it's shaping up to be rather ace. You should come. *You'll need to sign up, which you can do here: * http://jweekend.co.uk/dev/LWUGReg/ A reminder: talks and code from previous events available here: http://londonwicket.org Hope to see you there! Best regards, Al Cemal -- View this message in context: http://www.nabble.com/Reminder%3A-London-Wicket-event-at-Google-UK-on-Wednesday-tp17605619p17644831.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/Reminder%3A-London-Wicket-event-at-Google-UK-on-Wednesday-tp17605619p17645249.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: (Class? extends Page?) casting troubles
Hi Peter, 2008/6/4 Peter Ertl [EMAIL PROTECTED]: I remember that having more than one wildcard in an type expression seems to be inherently broken. I hope it is not, I hope it is just hard to understand. Usually you can rewrite something like void foo(Class? extends Page? pageClass) I think both signatures are not semanticall equal. Here there are two wildcards. On one hand wildcards are by definition independent from each other, but on the other hand there are coupled in this example, by the extends. Maybe in java it was decided that the independance is more important than the coupling. As I read the signature the type parameter might be of any type as long as it extends Page parametrized with any other type. Now when the method is used one parameter is given. foo(Bar.class) If Bar is a non-generic subtype of Page the compiler is happy. Either cause the type paramter of Page is well defined by the declaration of Bar or the compiler just forgets about them type parameters in an non-generic case (I don't know). If Bar is a generic subtype than Bar.class is its raw type which is a subtype of the raw type of Page, but nothing else. So the compiler is not happy. into something like X extends Page? void foo(ClassX pageClass) Having the wildcard in the generic type definition of the method it relaxes the Bounds. Here the compiler just has to make sure that X extends a parametrized Page which every subtype of Page does. @All Is there anyone out there having a better explanation? Currently I'm working my way through the generics FAQ by Angelika Langer http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html I see quite some statements there that apply here, but I still can't grab the whole picture. I would bet this solves your problem :-) However, nobody can explain why... :-( Probably some lack of the generics specification, broken compiler, or whatever... I would suggest to avoid more than one wildcard in one type expression in general and use above workaround. I'm not sure about the analysis but still a good guideline. mf Cheers Peter Am 04.06.2008 um 10:10 schrieb Johan Compagner: Yeah it is very strange that you get different errors in eclipse and javac. I wonder which one is correcct.. But you have to generify the Page then it should work fine (like Void) I think we just need to drop the ? in that example What do you exactly call? johan On Wed, Jun 4, 2008 at 9:39 AM, Rod Good [EMAIL PROTECTED] wrote: Hi, I'm getting inconvertible type errors when I compile from Maven on the command line with Java 6. Does anyone know if this issue was resolved ? I am building against 1.4-m2 - downloaded today (04-06-2008). The issue is the same as noted by Ryan Mckinley on 05/21/2008 : strangely, things work fine for me in eclipse, but from the command line, I still get: $ mvn clean install: /Users/ryan/Documents/workspace/dexter/website/src/java/dexter/website/ wicket/page/DownloadingPage.java:[18,97] inconvertible types found : java.lang.Classdexter.website.wicket.page.account.DexSignInPage required: java.lang.Class? extends org.apache.wicket.Page? I ran: mvn clean install in the wicket directory... Not sure if the java version is helpful: ryan$ mvn -version Maven version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp Thanks, Rod. NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Group Limited or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Group Limited does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Group Limited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Css and path issues
Hi, i fixed this issue yesterday thanks to the help on the irc channel. My issue was the way i was defining the css, i was using add(new StyleSheetReference(pageCSS, *getClass()*, styles/fenix.css)); and the getClass() part was the problem. I change that for nameOfTheClass.class and then the path for the css file is the same no matter the subclass. Thanks! Best regards. On Wed, Jun 4, 2008 at 12:05 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: you can use something like add(new HeaderContributor.forCss(pageA.class, filename)) on pageA and it should work from anywhere. -igor On Tue, Jun 3, 2008 at 8:26 AM, Manuel Corrales [EMAIL PROTECTED] wrote: Hi, i am starting new wicket application, my first one. I think this is an awesome framework!! I am having this issue, i have a css file and i am including it on a pageA, then i have another pageB (subclass of pageA) that is on another package. When i navigate to pageB, i have no stlyes because it is looking for it on the package of the pageB. How can i configure this, so wicket alway look for the css style on the same place? Thanks in advance! - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: recursive component
Some corrections :) I don't need to generate wicket markup. The example is the desirable wicket markup that will support the dynamical generation. Each node component is thought as a Loop. The think is the markup is required to be like this. The only thing I'd like to reduce is the written java code. In short I'd like to create a reusable node component that I can configure (with populateCaption() and populateChildren() callback methods perhaps) just like the Loop :) The node structure is fixed: div div -- caption components -- /div div style=margin-left: 24px; -- children components -- /div /div I hope I was clearer this time :D Stefan On Wed, 2008-06-04 at 15:04 +0300, Stefan Selariu wrote: Hi guys! I need to make generate something like this dynamically: div wicket:id=level1 !-- node component -- div !-- caption -- span wicket:id=text / /div div style=margin-left: 24px; !-- children -- div wicket:id=level2-1 !-- node component -- div !-- caption -- a href=# wicket:id=linkselect/a /div div style=margin-left: 24px; !-- children -- div wicket:id=level3 !-- node component -- div !-- caption -- span wicket:id=name / /div div style=margin-left: 24px; !-- children -- /div /div /div /div div wicket:id=level2-2 !-- node component -- div !-- caption -- span wicket:id=text / /div div style=margin-left: 24px; !-- children -- /div /div /div /div This is a tree for which every node has a caption and children. Can I create a wicket component for the tree node that supports my example? I need a component that behaves like the Loop but in a recursive way :) Best regards, Stefan - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: recursive component
hi stefan, The think is the markup is required to be like this. The only thing I'd like to reduce is the written java code. In short I'd like to create a reusable node component that I can configure (with populateCaption() and populateChildren() callback methods perhaps) just like the Loop :) martijns solution still applies - just make your own panels with the needed methods?! regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: recursive component
Thanks for the answers. The only annoying thing is that I have to create a different panel for each node since the captions differ on each level. Or am I wrong? Stefan On Wed, 2008-06-04 at 14:22 +0200, Jan Kriesten wrote: hi stefan, The think is the markup is required to be like this. The only thing I'd like to reduce is the written java code. In short I'd like to create a reusable node component that I can configure (with populateCaption() and populateChildren() callback methods perhaps) just like the Loop :) martijns solution still applies - just make your own panels with the needed methods?! regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Stateless vs Stateful
continuing on from jwcarman's http://www.nabble.com/Re%3A--FINALISED-SCHEDULE--London-Wicket-Event-at-Google-UK%2C-tonight-p17644874.html post ... We do get questions directly about, or that turn out to be about stateful vs stateless in Wicket. One of my colleagues at jWeekend posted http://cwiki.apache.org/confluence/display/WICKET/Pages this to the wiki a while back and we will post Ian's session from tonight's event too. In the meantime, the stateless vs stateful discussion should probably better continue on this thread. Regards - Cemal http://jWeekend.co.uk http://jWeekend.co.uk -- View this message in context: http://www.nabble.com/Stateless-vs-Stateful-tp17645575p17645575.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: recursive component
Yes. you are wrong. Read about Models: http://cwiki.apache.org/WICKET/working-with-wicket-models.html Martijn On Wed, Jun 4, 2008 at 2:29 PM, Stefan Selariu [EMAIL PROTECTED] wrote: Thanks for the answers. The only annoying thing is that I have to create a different panel for each node since the captions differ on each level. Or am I wrong? Stefan On Wed, 2008-06-04 at 14:22 +0200, Jan Kriesten wrote: hi stefan, The think is the markup is required to be like this. The only thing I'd like to reduce is the written java code. In short I'd like to create a reusable node component that I can configure (with populateCaption() and populateChildren() callback methods perhaps) just like the Loop :) martijns solution still applies - just make your own panels with the needed methods?! regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- 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]
how to pass parameters while setting page expired error page
I want to redirect to LoginPage if session expires and want to show message that your session expired, please login again. Is there any way that I can pass parameters to LoginPage ?? getApplicationSettings().setPageExpiredErrorPage(LoginPage.class); Thanks, Sanjay. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Example of wicketstuff-minis' Veil
Here is the stack trace: Root cause:java.lang.IllegalStateException: This behavior is already bound to component. An instance of this behavior cannot be reused between components. Bound component: [MarkupContainer [Component id = test, page = No Page, path = test.Button]] at org.wicketstuff.minis.veil.Veil.bind(Veil.java:64) at org.apache.wicket.Component.add(Component.java:922) at com.uprr.app.hrw.wicket.page.scheduling.EventDetailsPage.init(EventDetailsPage.java:235) at java.lang.reflect.Constructor.newInstance(Constructor.java:494) at java.lang.Class.newInstance0(Class.java:350) at java.lang.Class.newInstance(Class.java:303) at org.apache.wicket.session.DefaultPageFactory.newPage(DefaultPageFactory.java:58) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.newPage(BookmarkablePageRequestTarget.java:262) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.getPage(BookmarkablePageRequestTarget.java:283) at org.apache.wicket.request.target.component.BookmarkablePageRequestTarget.processEvents(BookmarkablePageRequestTarget.java:210) at org.apache.wicket.request.AbstractRequestCycleProcessor.processEvents(AbstractRequestCycleProcessor.java:90) at org.apache.wicket.RequestCycle.processEventsAndRespond(RequestCycle.java:1166) at org.apache.wicket.RequestCycle.step(RequestCycle.java:1241) at org.apache.wicket.RequestCycle.steps(RequestCycle.java:1316) at org.apache.wicket.RequestCycle.request(RequestCycle.java:493) at org.apache.wicket.protocol.http.WicketFilter.doGet(WicketFilter.java:354) at org.apache.wicket.protocol.http.WicketFilter.doFilter(WicketFilter.java:194) at weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:42) at weblogic.servlet.internal.WebAppServletContext$ServletInvocationAction.run(WebAppServletContext.java:3393) at weblogic.security.acl.internal.AuthenticatedSubject.doAs(AuthenticatedSubject.java:321) at weblogic.security.service.SecurityManager.runAs(Unknown Source) at weblogic.servlet.internal.WebAppServletContext.securedExecute(WebAppServletContext.java:2140) at weblogic.servlet.internal.WebAppServletContext.execute(WebAppServletContext.java:2046) at weblogic.servlet.internal.ServletRequestImpl.run(ServletRequestImpl.java:1366) at weblogic.work.ExecuteThread.execute(ExecuteThread.java:200) at weblogic.work.ExecuteThread.run(ExecuteThread.java:172) I am using: wicketstuff-minis-1.3.0-SNAPSHOT.jar igor.vaynberg wrote: can you paste the stack trace please? are you using latest trunk? -igor On Tue, Jun 3, 2008 at 6:38 AM, nitinkc [EMAIL PROTECTED] wrote: I need an example of wicketstuff-minis' veil behavior. I added this to one of my components but keep getting the error that the behavior is already bound to another component and cannot be reused. All I am doing is: Button button = new Button(test); button.add(new Veil()); form.add(button); This is the only Veil I am using on my page. Thanks. -- View this message in context: http://www.nabble.com/Example-of-wicketstuff-minis%27-Veil-tp17623741p17623741.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/Example-of-wicketstuff-minis%27-Veil-tp17623741p17646385.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: recursive component
Here's a basic treeview component i use (The backing models contain TreeNode
objects)
I made it abstract so the implementors just provide the fragment or panels
that represent nodes.
TreeView.java :
public abstract class TreeView extends Panel {
public TreeView(String markupId, final IModel rootNodeModel) {
super(markupId, rootNodeModel);
add(new TreeNodeView(node, rootNodeModel));
}
protected abstract Component newComponentForTreeNodeDescription(ListItem
markupContainer, String markupId, TreeNode treeNode);
protected abstract Component newComponentForTreeNodeChildren(ListItem
markupContainer, String markupId, TreeNode treeNode);
private class TreeNodeView extends ListView {
public TreeNodeView(String markupId, final IModel treeNodeModel) {
super(markupId, new LoadableDetachableModel() {
protected Object load() {
TreeNode node = (TreeNode)treeNodeModel.getObject();
List children = node.getChildren();
return children;
};
});
}
@Override
protected void populateItem(ListItem item) {
TreeNode currentChild = (TreeNode)item.getModelObject();
item.setOutputMarkupId(true);
item.add(newComponentForTreeNodeDescription(item, node_desc,
currentChild));
item.add(newComponentForTreeNodeChildren(item, children,
currentChild));
}
}
}
TreeView.html :
wicket:panel
li wicket:id=node
ul wicket:id=children
/ul
/li
wicket:child/
/wicket:panel
Stefan Selariu-2 wrote:
Hi guys!
I need to make generate something like this dynamically:
div wicket:id=level1 !-- node component --
div !-- caption --
/div
div style=margin-left: 24px; !-- children --
div wicket:id=level2-1 !-- node component --
div !-- caption --
# select
/div
div style=margin-left: 24px; !-- children --
div wicket:id=level3 !-- node component --
div !-- caption --
/div
div style=margin-left: 24px; !-- children --
/div
/div
/div
/div
div wicket:id=level2-2 !-- node component --
div !-- caption --
/div
div style=margin-left: 24px; !-- children --
/div
/div
/div
/div
This is a tree for which every node has a caption and children.
Can I create a wicket component for the tree node that supports my
example?
I need a component that behaves like the Loop but in a recursive way :)
Best regards,
Stefan
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--
View this message in context:
http://www.nabble.com/recursive-component-tp17645117p17646533.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: recursive component
I'm sorry but reading that didn't help. I was not able to find the answer for my problem. Maybe I'm to tired. If I do this: wicket:panel div wicket:id=sibling -- Loop is used here div div wicket:id=caption -- this comes from the page markup /div div div wicket:id=content / -- this comes from the page markup /div /div /wicket:panel Am I able to create pages like this? body div wicket:id=level1 -- my panel div -- caption for level1 span wicket:id=text / span wicket:id=text2 / /div div -- content for level1 div wicket:id=level2-1 -- my panel div -- caption for level2-1 span wicket:id=label / /div div -- empty content for level2-1 /div /div div wicket:id=level2-2 -- my panel div -- caption for level2-2 span wicket:id=text / /div div -- content for level2-2 table tr wicket:id=items ... /tr /table /div /div /div /div /body My problem is I don't know how to connect the panel instance with the right caption and content. Each node caption differs not in the data but also in the layout. And this is available also for the content. Thanks, Stefan On Wed, 2008-06-04 at 14:35 +0200, Martijn Dashorst wrote: Yes. you are wrong. Read about Models: http://cwiki.apache.org/WICKET/working-with-wicket-models.html Martijn On Wed, Jun 4, 2008 at 2:29 PM, Stefan Selariu [EMAIL PROTECTED] wrote: Thanks for the answers. The only annoying thing is that I have to create a different panel for each node since the captions differ on each level. Or am I wrong? Stefan On Wed, 2008-06-04 at 14:22 +0200, Jan Kriesten wrote: hi stefan, The think is the markup is required to be like this. The only thing I'd like to reduce is the written java code. In short I'd like to create a reusable node component that I can configure (with populateCaption() and populateChildren() callback methods perhaps) just like the Loop :) martijns solution still applies - just make your own panels with the needed methods?! regards, --- jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: recursive component
Thanks, I know now where I went wrong.
Best regards,
Stefan
On Wed, 2008-06-04 at 06:16 -0700, Alexis wrote:
Here's a basic treeview component i use (The backing models contain TreeNode
objects)
I made it abstract so the implementors just provide the fragment or panels
that represent nodes.
TreeView.java :
public abstract class TreeView extends Panel {
public TreeView(String markupId, final IModel rootNodeModel) {
super(markupId, rootNodeModel);
add(new TreeNodeView(node, rootNodeModel));
}
protected abstract Component newComponentForTreeNodeDescription(ListItem
markupContainer, String markupId, TreeNode treeNode);
protected abstract Component newComponentForTreeNodeChildren(ListItem
markupContainer, String markupId, TreeNode treeNode);
private class TreeNodeView extends ListView {
public TreeNodeView(String markupId, final IModel treeNodeModel) {
super(markupId, new LoadableDetachableModel() {
protected Object load() {
TreeNode node = (TreeNode)treeNodeModel.getObject();
List children = node.getChildren();
return children;
};
});
}
@Override
protected void populateItem(ListItem item) {
TreeNode currentChild = (TreeNode)item.getModelObject();
item.setOutputMarkupId(true);
item.add(newComponentForTreeNodeDescription(item, node_desc,
currentChild));
item.add(newComponentForTreeNodeChildren(item, children,
currentChild));
}
}
}
TreeView.html :
wicket:panel
li wicket:id=node
ul wicket:id=children
/ul
/li
wicket:child/
/wicket:panel
Stefan Selariu-2 wrote:
Hi guys!
I need to make generate something like this dynamically:
div wicket:id=level1 !-- node component --
div !-- caption --
/div
div style=margin-left: 24px; !-- children --
div wicket:id=level2-1 !-- node component --
div !-- caption --
# select
/div
div style=margin-left: 24px; !-- children --
div wicket:id=level3 !-- node component --
div !-- caption --
/div
div style=margin-left: 24px; !-- children --
/div
/div
/div
/div
div wicket:id=level2-2 !-- node component --
div !-- caption --
/div
div style=margin-left: 24px; !-- children --
/div
/div
/div
/div
This is a tree for which every node has a caption and children.
Can I create a wicket component for the tree node that supports my
example?
I need a component that behaves like the Loop but in a recursive way :)
Best regards,
Stefan
-
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]
New Window/Tab Scope
Hi, I need a scope for every new window/tab, where I can put some data. I read, that is in the wishlist for wicket 1.5, but are there any best practices or suggestions? Kind regards, Georg -- View this message in context: http://www.nabble.com/New-Window-Tab-Scope-tp17648112p17648112.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: New Window/Tab Scope
nothing right now because its not implemented yet. in the future you will have access to a Window class and be able to subclass it to store your own data, just like you do with Session now... -igor On Wed, Jun 4, 2008 at 7:29 AM, geke [EMAIL PROTECTED] wrote: Hi, I need a scope for every new window/tab, where I can put some data. I read, that is in the wishlist for wicket 1.5, but are there any best practices or suggestions? Kind regards, Georg -- View this message in context: http://www.nabble.com/New-Window-Tab-Scope-tp17648112p17648112.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-auth-roles - Redirect to LoginPage instead of SessionExpiry Page
but if you start two threads you are twice as likely to get an answer... -igor On Wed, Jun 4, 2008 at 12:38 AM, Maurice Marrink [EMAIL PROTECTED] wrote: See my reply in the other thread. Oh and next time could you keep it to one thread ;) thanks. Maurice On Wed, Jun 4, 2008 at 3:12 AM, mfs [EMAIL PROTECTED] wrote: Guys, I am using wicket-auth-roles which so far is working greaet serving all my purposes. Though I am stuck in this scenario where when the session-expiry has reached, instead of being redirected to the SessionExpiryPage, i get redirected to the loginPage, now in one of the threads it was commented that this is probably is the default behavior with auth-roles (where it doesnt let the pageexpired instance to be constructed), unless we configure the security settings accordingly. Now am not able to figure as to how exactly the security settings are to be configured, i also havent come across any example/documentation where this has been discussed... Any help would appreciated.. Thanks in advance.. -- View this message in context: http://www.nabble.com/wicket-auth-roles---Redirect-to-LoginPage-instead-of-SessionExpiry-Page-tp17637202p17637202.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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: wicket-auth-roles - Redirect to LoginPage instead of SessionExpiry Page
But how does that work when I have a lock on you? Will the universe deadlock? Martijn On Wed, Jun 4, 2008 at 4:34 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: but if you start two threads you are twice as likely to get an answer... -igor On Wed, Jun 4, 2008 at 12:38 AM, Maurice Marrink [EMAIL PROTECTED] wrote: See my reply in the other thread. Oh and next time could you keep it to one thread ;) thanks. Maurice On Wed, Jun 4, 2008 at 3:12 AM, mfs [EMAIL PROTECTED] wrote: Guys, I am using wicket-auth-roles which so far is working greaet serving all my purposes. Though I am stuck in this scenario where when the session-expiry has reached, instead of being redirected to the SessionExpiryPage, i get redirected to the loginPage, now in one of the threads it was commented that this is probably is the default behavior with auth-roles (where it doesnt let the pageexpired instance to be constructed), unless we configure the security settings accordingly. Now am not able to figure as to how exactly the security settings are to be configured, i also havent come across any example/documentation where this has been discussed... Any help would appreciated.. Thanks in advance.. -- View this message in context: http://www.nabble.com/wicket-auth-roles---Redirect-to-LoginPage-instead-of-SessionExpiry-Page-tp17637202p17637202.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] - 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: Use Spring with Wicket
Thanx Guys for ur quick response... Now i want to learn Integration of Wicket with Spring and Hibernate... Any help Thanks - Samit :confused: -- View this message in context: http://www.nabble.com/Use-Spring-with-Wicket-tp17600138p17648634.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-auth-roles - Redirect to LoginPage instead of SessionExpiry Page
i dont think the universe will deadlock, but you will block for a very very long time :) there are already three threads that acquired the lock :) -igor On Wed, Jun 4, 2008 at 7:48 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: But how does that work when I have a lock on you? Will the universe deadlock? Martijn On Wed, Jun 4, 2008 at 4:34 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: but if you start two threads you are twice as likely to get an answer... -igor On Wed, Jun 4, 2008 at 12:38 AM, Maurice Marrink [EMAIL PROTECTED] wrote: See my reply in the other thread. Oh and next time could you keep it to one thread ;) thanks. Maurice On Wed, Jun 4, 2008 at 3:12 AM, mfs [EMAIL PROTECTED] wrote: Guys, I am using wicket-auth-roles which so far is working greaet serving all my purposes. Though I am stuck in this scenario where when the session-expiry has reached, instead of being redirected to the SessionExpiryPage, i get redirected to the loginPage, now in one of the threads it was commented that this is probably is the default behavior with auth-roles (where it doesnt let the pageexpired instance to be constructed), unless we configure the security settings accordingly. Now am not able to figure as to how exactly the security settings are to be configured, i also havent come across any example/documentation where this has been discussed... Any help would appreciated.. Thanks in advance.. -- View this message in context: http://www.nabble.com/wicket-auth-roles---Redirect-to-LoginPage-instead-of-SessionExpiry-Page-tp17637202p17637202.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] - 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] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to pass parameters while setting page expired error page
I haven't had to deal with this issue yet, but perhaps you can put this information in a cookie and read it when necessary? On Wed, Jun 4, 2008 at 9:04 AM, Patel, Sanjay [EMAIL PROTECTED] wrote: I want to redirect to LoginPage if session expires and want to show message that your session expired, please login again. Is there any way that I can pass parameters to LoginPage ?? getApplicationSettings().setPageExpiredErrorPage(LoginPage.class); Thanks, Sanjay. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ryan Gravener http://twitter.com/ryangravener
Re: New Window/Tab Scope
it can be done i guess.. Turn on the multi window support/check in the settings. then extend: SecondLevelCacheSessionStore override createPageMap() now the bad thing is that you need to do super call to create it because that api is not really open But do a super call. And wrap it in your own IPageMap impl where you also store youre stuff and redirect all other calls to the pagemap i think this should work.. johan On Wed, Jun 4, 2008 at 4:33 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: nothing right now because its not implemented yet. in the future you will have access to a Window class and be able to subclass it to store your own data, just like you do with Session now... -igor On Wed, Jun 4, 2008 at 7:29 AM, geke [EMAIL PROTECTED] wrote: Hi, I need a scope for every new window/tab, where I can put some data. I read, that is in the wishlist for wicket 1.5, but are there any best practices or suggestions? Kind regards, Georg -- View this message in context: http://www.nabble.com/New-Window-Tab-Scope-tp17648112p17648112.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
why even have an interface? just detach all imodel fields via reflection! -igor On Wed, Jun 4, 2008 at 3:37 AM, James Carman [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. We discussed this on ##wicket yesterday. I asked why we have models on all components and someone pointed out that the main reason was about the detach stuff I believe. But, couldn't that be solved by having some components that implement something like IModelDriven (or IModelBacked or whatever) and the detach logic could apply to only those components? Also, someone has pointed out that when they create their own components, they sometimes (such as in Palette) have multiple models that they deal with. Allowing components to name their models what they want would be nice, too. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Problem: Check within a ListView
Igor Vaynberg mailto:[EMAIL PROTECTED] wrote: you are not doing anything wrong, that is how things are meant to work. So, isn't it possible to add a disabled checkbox to a listview without removing the item from the corresponding collection? Kai - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Use Spring with Wicket
Well, the example I showed before does have hibernate working also. On Wed, Jun 4, 2008 at 10:50 AM, Samit [EMAIL PROTECTED] wrote: Thanx Guys for ur quick response... Now i want to learn Integration of Wicket with Spring and Hibernate... Any help Thanks - Samit :confused: -- View this message in context: http://www.nabble.com/Use-Spring-with-Wicket-tp17600138p17648634.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
and if i store it in metadata ;) On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: why even have an interface? just detach all imodel fields via reflection! -igor On Wed, Jun 4, 2008 at 3:37 AM, James Carman [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. We discussed this on ##wicket yesterday. I asked why we have models on all components and someone pointed out that the main reason was about the detach stuff I believe. But, couldn't that be solved by having some components that implement something like IModelDriven (or IModelBacked or whatever) and the detach logic could apply to only those components? Also, someone has pointed out that when they create their own components, they sometimes (such as in Palette) have multiple models that they deal with. Allowing components to name their models what they want would be nice, too. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to pass parameters while setting page expired error page
Or in the session as sort of a flash memory. On Wed, Jun 4, 2008 at 10:53 AM, Ryan Gravener [EMAIL PROTECTED] wrote: I haven't had to deal with this issue yet, but perhaps you can put this information in a cookie and read it when necessary? On Wed, Jun 4, 2008 at 9:04 AM, Patel, Sanjay [EMAIL PROTECTED] wrote: I want to redirect to LoginPage if session expires and want to show message that your session expired, please login again. Is there any way that I can pass parameters to LoginPage ?? getApplicationSettings().setPageExpiredErrorPage(LoginPage.class); Thanks, Sanjay. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Ryan Gravener http://twitter.com/ryangravener - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: how to pass parameters while setting page expired error page
What param is that? What info do you want to pass in? On 6/4/08, Patel, Sanjay [EMAIL PROTECTED] wrote: I want to redirect to LoginPage if session expires and want to show message that your session expired, please login again. Is there any way that I can pass parameters to LoginPage ?? getApplicationSettings().setPageExpiredErrorPage(LoginPage.class); Thanks, Sanjay. - 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: (Class? extends Page?) casting troubles
This is my take on it: http://www.nabble.com/RE%3A-%28Class%3C--extends-Page%3C-%3E%3E%29-casti ng-troubles-p17370699.html I feel it covers the topic pretty thoroughly but I am by no means an expert on the matter. -Original Message- From: Martin Funk [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2008 8:14 AM To: users@wicket.apache.org Subject: Re: (Class? extends Page?) casting troubles Hi Peter, 2008/6/4 Peter Ertl [EMAIL PROTECTED]: I remember that having more than one wildcard in an type expression seems to be inherently broken. I hope it is not, I hope it is just hard to understand. Usually you can rewrite something like void foo(Class? extends Page? pageClass) I think both signatures are not semanticall equal. Here there are two wildcards. On one hand wildcards are by definition independent from each other, but on the other hand there are coupled in this example, by the extends. Maybe in java it was decided that the independance is more important than the coupling. As I read the signature the type parameter might be of any type as long as it extends Page parametrized with any other type. Now when the method is used one parameter is given. foo(Bar.class) If Bar is a non-generic subtype of Page the compiler is happy. Either cause the type paramter of Page is well defined by the declaration of Bar or the compiler just forgets about them type parameters in an non-generic case (I don't know). If Bar is a generic subtype than Bar.class is its raw type which is a subtype of the raw type of Page, but nothing else. So the compiler is not happy. into something like X extends Page? void foo(ClassX pageClass) Having the wildcard in the generic type definition of the method it relaxes the Bounds. Here the compiler just has to make sure that X extends a parametrized Page which every subtype of Page does. @All Is there anyone out there having a better explanation? Currently I'm working my way through the generics FAQ by Angelika Langer http://www.angelikalanger.com/GenericsFAQ/JavaGenericsFAQ.html I see quite some statements there that apply here, but I still can't grab the whole picture. I would bet this solves your problem :-) However, nobody can explain why... :-( Probably some lack of the generics specification, broken compiler, or whatever... I would suggest to avoid more than one wildcard in one type expression in general and use above workaround. I'm not sure about the analysis but still a good guideline. mf Cheers Peter Am 04.06.2008 um 10:10 schrieb Johan Compagner: Yeah it is very strange that you get different errors in eclipse and javac. I wonder which one is correcct.. But you have to generify the Page then it should work fine (like Void) I think we just need to drop the ? in that example What do you exactly call? johan On Wed, Jun 4, 2008 at 9:39 AM, Rod Good [EMAIL PROTECTED] wrote: Hi, I'm getting inconvertible type errors when I compile from Maven on the command line with Java 6. Does anyone know if this issue was resolved ? I am building against 1.4-m2 - downloaded today (04-06-2008). The issue is the same as noted by Ryan Mckinley on 05/21/2008 : strangely, things work fine for me in eclipse, but from the command line, I still get: $ mvn clean install: /Users/ryan/Documents/workspace/dexter/website/src/java/dexter/website/ wicket/page/DownloadingPage.java:[18,97] inconvertible types found : java.lang.Classdexter.website.wicket.page.account.DexSignInPage required: java.lang.Class? extends org.apache.wicket.Page? I ran: mvn clean install in the wicket directory... Not sure if the java version is helpful: ryan$ mvn -version Maven version: 2.0.6 ryan$ javac -version javac 1.6.0_04-dp Thanks, Rod. NOTICE This e-mail and any attachments are confidential and may contain copyright material of Macquarie Group Limited or third parties. If you are not the intended recipient of this email you should not read, print, re-transmit, store or act in reliance on this e-mail or any attachments, and should destroy all copies of them. Macquarie Group Limited does not guarantee the integrity of any emails or any attached files. The views or opinions expressed are the author's own and may not reflect the views or opinions of Macquarie Group Limited. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] __ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you.
RE: how to pass parameters while setting page expired error page
I want to pass some param so I can know in LoginPage that it is called because of session expired and I can show appropriate message (e.g your session is expired, please login again.) -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2008 12:11 PM To: users@wicket.apache.org Subject: Re: how to pass parameters while setting page expired error page What param is that? What info do you want to pass in? On 6/4/08, Patel, Sanjay [EMAIL PROTECTED] wrote: I want to redirect to LoginPage if session expires and want to show message that your session expired, please login again. Is there any way that I can pass parameters to LoginPage ?? getApplicationSettings().setPageExpiredErrorPage(LoginPage.class); Thanks, Sanjay. - 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]
Contructor model
Hi, let assume i have a class with no empty constructors (at least no publics). And i want to use a wicket page to instantiate this class. It is possible to create a model for this, so i dont have to use another object or add setters. I dont know if i made myself clear. Please feel free to ask. Thanks in advance! Regards.
Re: how to pass parameters while setting page expired error page
getSession().info() and add a FeedbackPanel to your login page? On Wed, Jun 4, 2008 at 12:25 PM, Patel, Sanjay [EMAIL PROTECTED] wrote: I want to pass some param so I can know in LoginPage that it is called because of session expired and I can show appropriate message (e.g your session is expired, please login again.) -Original Message- From: Johan Compagner [mailto:[EMAIL PROTECTED] Sent: Wednesday, June 04, 2008 12:11 PM To: users@wicket.apache.org Subject: Re: how to pass parameters while setting page expired error page What param is that? What info do you want to pass in? On 6/4/08, Patel, Sanjay [EMAIL PROTECTED] wrote: I want to redirect to LoginPage if session expires and want to show message that your session expired, please login again. Is there any way that I can pass parameters to LoginPage ?? getApplicationSettings().setPageExpiredErrorPage(LoginPage.class); Thanks, Sanjay. - 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
Eelco Hillenius wrote: et an idea of what you think. 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. But turned off where not appropriate. Eelco Hillenius wrote: 2) How strongly do you feel about your choice above? [ ] [x] It would make me sad to lose generic components : ( -- 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-tp17589984p17651064.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
you still have ondetach()...but for convinience we can automatically detach any imodel fields, i actually wanted to do this for a while... -igor On Wed, Jun 4, 2008 at 8:43 AM, Johan Compagner [EMAIL PROTECTED] wrote: and if i store it in metadata ;) On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: why even have an interface? just detach all imodel fields via reflection! -igor On Wed, Jun 4, 2008 at 3:37 AM, James Carman [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. We discussed this on ##wicket yesterday. I asked why we have models on all components and someone pointed out that the main reason was about the detach stuff I believe. But, couldn't that be solved by having some components that implement something like IModelDriven (or IModelBacked or whatever) and the detach logic could apply to only those components? Also, someone has pointed out that when they create their own components, they sometimes (such as in Palette) have multiple models that they deal with. Allowing components to name their models what they want would be nice, too. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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]
jsesionid written into url when using tomcat behind apache mod_jk
Hi, This is probably not a wicket related query as such (so apologies) but just in case here goes I have placed our tomcat server behind apache and we are using mod_jk. When I do this we see the jsessionid being written out in the url for the very first request response to the user (so we see something like www.dummydomain.com/list;jsessionid=899F7C88CDA2E8A0508651AA89484C6C) However, I have checked that cookies are being written correctly, and they are. Is this something anyone else has seen. Are there any other reasons that the cookie might be url encoded on the first request? Joel (I also found this post : http://www.nabble.com/Re%3A-how-to-resolve-jsessionid-for-the-first-time-in-the-url-ts16347213.html but there was no resolution)
Re: Problem: Check within a ListView
it is possible, just depends on how you set up your models. it is not possible by directly reading the collection of checkgroup, but you can come up with a different way. -igor On Wed, Jun 4, 2008 at 8:29 AM, Kai Mütz [EMAIL PROTECTED] wrote: Igor Vaynberg mailto:[EMAIL PROTECTED] wrote: you are not doing anything wrong, that is how things are meant to work. So, isn't it possible to add a disabled checkbox to a listview without removing the item from the corresponding collection? Kai - 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
Having multiple models is rare, however, having one model that can (but doesn't have to) be used is more common imho. Not that rare if I look at my code, especially if you take panels and fragments into account. I have plenty of places where I use two or three models. Wicket is kinda optimized for the later, so if you don't use the model there is no runtime cost associated. If we didn't have default model slot this would be more difficult to achieve. The problem with generics now is that the model isn't as optional anymore. So you'd have to use void or whatever. Eelco - 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 was talking about the model slot. If you don't have a model in component it doesn't cost you anything. -Matej On Wed, Jun 4, 2008 at 6:49 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: Having multiple models is rare, however, having one model that can (but doesn't have to) be used is more common imho. Not that rare if I look at my code, especially if you take panels and fragments into account. I have plenty of places where I use two or three models. Wicket is kinda optimized for the later, so if you don't use the model there is no runtime cost associated. If we didn't have default model slot this would be more difficult to achieve. The problem with generics now is that the model isn't as optional anymore. So you'd have to use void or whatever. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: jsesionid written into url when using tomcat behind apache mod_j
this has been asked a ton of times already...so do search the lists next time. just to reiterate, servlet container always does this on first request because it doesnt know if the cookies are enabled or not until the second request. if cookies are enabled jsessionid will go away on second request. -igor On Wed, Jun 4, 2008 at 9:45 AM, Joel Halbert [EMAIL PROTECTED] wrote: Hi, This is probably not a wicket related query as such (so apologies) but just in case here goes I have placed our tomcat server behind apache and we are using mod_jk. When I do this we see the jsessionid being written out in the url for the very first request response to the user (so we see something like www.dummydomain.com/list;jsessionid=899F7C88CDA2E8A0508651AA89484C6C) However, I have checked that cookies are being written correctly, and they are. Is this something anyone else has seen. Are there any other reasons that the cookie might be url encoded on the first request? Joel (I also found this post : http://www.nabble.com/Re%3A-how-to-resolve-jsessionid-for-the-first-time-in-the-url-ts16347213.html but there was no resolution) - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Wicket 1.3 - SNAPSHOT release dates
Hi, Is there an estimated release date for Wicket 1.3.4 or for 1.3-SNAPSHOT ? Regards, Vyas, Anirudh
RE: how to pass parameters while setting page expired error page
I want to redirect to LoginPage when session expires. If I can pass page
parameter while setting expired page, I can use that parameter in
LoginPage to know that LoginPage is called because of Session is
expired.
getApplicationSettings().setPageExpiredErrorPage(LoginPage.class, new
PageParameters(pageExpired=true));
and in LoginPage
...
public LoginPage(final PageParameters parameters) {
super(parameters);
parameters.getString(pageExpired)
if(pageExpired == true)
error(Your session is Expired. Pleae login
again., this);
...
}
...
-Original Message-
From: Patel, Sanjay [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2008 12:26 PM
To: users@wicket.apache.org
Subject: RE: how to pass parameters while setting page expired error
page
I want to pass some param so I can know in LoginPage that it is called
because of session expired and I can show appropriate message (e.g your
session is expired, please login again.)
-Original Message-
From: Johan Compagner [mailto:[EMAIL PROTECTED]
Sent: Wednesday, June 04, 2008 12:11 PM
To: users@wicket.apache.org
Subject: Re: how to pass parameters while setting page expired error
page
What param is that? What info do you want to pass in?
On 6/4/08, Patel, Sanjay [EMAIL PROTECTED] wrote:
I want to redirect to LoginPage if session expires and want to show
message that your session expired, please login again.
Is there any way that I can pass parameters to LoginPage ??
getApplicationSettings().setPageExpiredErrorPage(LoginPage.class);
Thanks,
Sanjay.
-
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
On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: you still have ondetach()...but for convinience we can automatically detach any imodel fields, i actually wanted to do this for a while... I tried to write this two days ago, but wasn't able to pull it off... I wrote an instantiation listener that introspected on the fields of components and replaced IModel members with a proxy. These proxies would register themselves with the request cycle for cleaning up whenever the getObject was called, and the request cycle then would go through the list of registered models and detach them at the end of the request. The problem I ran into however is that these members can be final, assigned at a later stage (typically are actually) and such. But if there is some way to automatically detach model members, we could get rid of the model member in component and instead just let components have models by default where it actually always makes sense, such as form components. Anyway, that's something for 1.5. If it is fixable, I think that would be the way out of the generics controversy :-) Eelco - 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 Wed, Jun 4, 2008 at 9:52 AM, Matej Knopp [EMAIL PROTECTED] wrote: I was talking about the model slot. If you don't have a model in component it doesn't cost you anything. The cost in this case is the fact that having the model slot, even when not used, results in the assumption that a component is typed. Eelco - 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
but IModel implementations can have Imodels inside too And the LDM doesn't play wel with detach unfortunately as it keeps an attached boolean that prevents the detach from entering the nested IModel Martijn On Wed, Jun 4, 2008 at 6:43 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: you still have ondetach()...but for convinience we can automatically detach any imodel fields, i actually wanted to do this for a while... -igor On Wed, Jun 4, 2008 at 8:43 AM, Johan Compagner [EMAIL PROTECTED] wrote: and if i store it in metadata ;) On Wed, Jun 4, 2008 at 5:16 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: why even have an interface? just detach all imodel fields via reflection! -igor On Wed, Jun 4, 2008 at 3:37 AM, James Carman [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: it all depends, on how and what you're developing. Yeah. I actually use less and less models in the regular way nowadays. I use plenty of panels (the app I work on hardly uses separate pages) that nest other panels in them (typically detail views or dialogs) that reuse models of the parent. But indeed YMMV. Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. I think on the longer term (post 1.4) we should re-think how models work in Wicket. See if we can find an elegant way to make this more flexible (I'm not in favor of the id based thing someone posted earlier btw) without breaking the whole world. We discussed this on ##wicket yesterday. I asked why we have models on all components and someone pointed out that the main reason was about the detach stuff I believe. But, couldn't that be solved by having some components that implement something like IModelDriven (or IModelBacked or whatever) and the detach logic could apply to only those components? Also, someone has pointed out that when they create their own components, they sometimes (such as in Palette) have multiple models that they deal with. Allowing components to name their models what they want would be nice, too. FWIW, I'm still on the fence when it comes to whether we should go for a full or partial (models only) implementation of generics, though I'm leaning towards partial. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - 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] -- 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: Wicket 1.3 - SNAPSHOT release dates
snapshots are available daily from wicketstuff repo. we have a teamcity instance that builds them quiet often. -igor On Wed, Jun 4, 2008 at 9:58 AM, Ricky [EMAIL PROTECTED] wrote: Hi, Is there an estimated release date for Wicket 1.3.4 or for 1.3-SNAPSHOT ? Regards, Vyas, Anirudh - 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 Wed, Jun 4, 2008 at 10:05 AM, Martijn Dashorst [EMAIL PROTECTED] wrote: but IModel implementations can have Imodels inside too Whether done automatically or by components as we do now, ultimately the calls to detach will be the same, right? Eelco - 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
sounds way too complicated to me dude...
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
with proper caching of the actual fields lookup this should be pretty performant
-igor
On Wed, Jun 4, 2008 at 10:03 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
you still have ondetach()...but for convinience we can automatically
detach any imodel fields, i actually wanted to do this for a while...
I tried to write this two days ago, but wasn't able to pull it off...
I wrote an instantiation listener that introspected on the fields of
components and replaced IModel members with a proxy. These proxies
would register themselves with the request cycle for cleaning up
whenever the getObject was called, and the request cycle then would go
through the list of registered models and detach them at the end of
the request. The problem I ran into however is that these members can
be final, assigned at a later stage (typically are actually) and such.
But if there is some way to automatically detach model members, we
could get rid of the model member in component and instead just let
components have models by default where it actually always makes
sense, such as form components.
Anyway, that's something for 1.5. If it is fixable, I think that would
be the way out of the generics controversy :-)
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
If besides formcomponent you get links/buttons and so on, then i still think the example i see of verbosity is still there, like dropdownchoice is then generified?? On 6/4/08, Eelco Hillenius [EMAIL PROTECTED] wrote: On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: you still have ondetach()...but for convinience we can automatically detach any imodel fields, i actually wanted to do this for a while... I tried to write this two days ago, but wasn't able to pull it off... I wrote an instantiation listener that introspected on the fields of components and replaced IModel members with a proxy. These proxies would register themselves with the request cycle for cleaning up whenever the getObject was called, and the request cycle then would go through the list of registered models and detach them at the end of the request. The problem I ran into however is that these members can be final, assigned at a later stage (typically are actually) and such. But if there is some way to automatically detach model members, we could get rid of the model member in component and instead just let components have models by default where it actually always makes sense, such as form components. Anyway, that's something for 1.5. If it is fixable, I think that would be the way out of the generics controversy :-) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
On Wed, Jun 4, 2008 at 10:10 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
sounds way too complicated to me dude...
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
with proper caching of the actual fields lookup this should be pretty
performant
Maybe. I was trying to avoid having to introspect on every single detachment.
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: [FINALISED SCHEDULE] London Wicket Event at Google UK, tonight
Is there a webcast? I'm interested in the Stateless vs. Stateful Me too. Eelco - 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 Wed, Jun 4, 2008 at 10:23 AM, Eelco Hillenius
[EMAIL PROTECTED] wrote:
On Wed, Jun 4, 2008 at 10:10 AM, Igor Vaynberg [EMAIL PROTECTED] wrote:
sounds way too complicated to me dude...
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
with proper caching of the actual fields lookup this should be pretty
performant
Maybe. I was trying to avoid having to introspect on every single detachment.
well, like i said, just cache it in a global map.
ConcurrentHashMapClassComponent,CollectionField. we do this all
over the place, eg propertyresolver. that way you can even only cache
IModel fields, so the loop becomes even tighter.
-igor
Eelco
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: users, please give us your opinion: what is your take on generics with Wicket
igor.vaynberg wrote:
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
+1
I'm also for moving getModel()/getModelObject() out of Component and only
putting them in things that really use models, like Label and
FormComponent...
I agree, though, that this should probably wait for 1.5...
--
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-tp17589984p17652189.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
We should definitely discuss this after 1.4.
-Matej
On Wed, Jun 4, 2008 at 7:30 PM, Patrick Angeles [EMAIL PROTECTED] wrote:
igor.vaynberg wrote:
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
+1
I'm also for moving getModel()/getModelObject() out of Component and only
putting them in things that really use models, like Label and
FormComponent...
I agree, though, that this should probably wait for 1.5...
--
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-tp17589984p17652189.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
So it would be no generics or it would be: MyComponentCompoundPropertyModel mycom = new MyComponentCompoundPropertyModel(); and I was saying that the suppress *should not* be in the API because people need the ability to control that sort of thing at their own code level, which should address your issue. - Brill Pappin On Tue, Jun 3, 2008 at 11:54 PM, Mike Comb [EMAIL PROTECTED] wrote: Well, in our case it would almost never be: MyComponentMyModel mycom = new MyComponentMyModel(); We don't have many of our own models, we use CompoundPropertyModel pretty much exclusively (wrapping DAOs or javabeans). So the verbosity doesn't benefit us much. Also, the vast majority of our components don't have a model. We generally have a page containing one or more forms with a CompoundPropModel on each form. Having generics (particularly if they are just something like Void) on every other object in the page is messy and confusing in my mind. Telling people to use suppress annotations is not a good solution either, we want those warnings for other things in our code (Collections, etc). -Mike On Jun 3, 2008, at 8:11 PM, Brill Pappin wrote: I guess I'm not understanding why people feel strongly against generics in the components. The model is going to use them for the data they contain, but the component would use them for the model it uses: MyModelString mymodel = new MyModelString(); MyComponentMyModel mycom = new MyComponentMyModel(); And that's all you would ever see of the generics unless you actually override one of the components methods (as in a button onclick). To top it off, I'm not even sure you would have to specify the generics for the component (not up on my generics coding)... But if the warning was bugging you, you could simply use a suppress annotation (suppress should absolutely not be in the API). More verbose? Yes... Not by much, but it is... However the advantages gained in terms of readability and type safety are enormous. - Brill Pappin -Original Message- From: Mike Comb [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 4:39 PM To: users@wicket.apache.org Subject: 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. I've spent a couple of afternoons trying to move our app to m1. My experience has been that generics on components are absolutely not worth it for our use cases. I love generics on objects that directly hold data (IModel), but they are too verbose and not very useful for objects that are a few levels removed from the actual data. [X ] Whatever choice ultimately made, I'll happily convert/ start using 1.4 and up. Happily probably isn't the word I'd chose, but we'll move to 1.4 eventually regardless of the decision made. -Mike -- Mike Comb Director of Engineering SoftCoin, Inc [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] -- Mike Comb Director of Engineering SoftCoin, Inc [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
Opinion, not statement :) But i get where your coming from. - Brill On Tue, Jun 3, 2008 at 11:29 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: no worries, i wasnt holding my breath. its just that when i make sweeping statements i tend to have something to back them up that other people can see... -igor On Tue, Jun 3, 2008 at 8:19 PM, Brill Pappin [EMAIL PROTECTED] wrote: You will wait a long time for an example generated from the API would be different in such and such a case, based on an opinion. If your really all that interested you could start from scratch using generics and see what came out. Let me know if you do, because I'd be interested to see if my opinion held any merit. However, if your interested in why I said that in the first place, then I can explain that. I don't know if you have every done true TDD (most people can't or think they can), but it actually changes your code and the way you write it. Starting with 2 users of your code makes a significant impact on what it looks like in the end. I applied the same thoughts to using generics from the start, and realized the API would likely be a bit different. Exactly how much, I wouldn't presume to guess. - Brill Pappin -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 11:03 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket sorry, still waiting for an example here... -igor On Tue, Jun 3, 2008 at 7:53 PM, Brill Pappin [EMAIL PROTECTED] wrote: Actually, i did not say ... say that wicket api needs a radical refactoring in order to support generics what I actually said was I think that if Wicket had been written with generics from the beginning, the API would be different. No radical refactoring required was mentioned :) Big difference... It would be WAY too much work to rewrite it now, and I think your right that it can be implemented fairly well without too much impact on the users. - Brill Pappin -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Tuesday, June 03, 2008 12:21 AM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket you made a radical statement, just wandering if there is anything concrete you can back it up with. in my head the generics have very little effect on the actual api design so i am wandering what prompted you to say that wicket api needs a radical refactoring in order to support generics - which essentially are little more then metadata. -igor On Mon, Jun 2, 2008 at 8:50 PM, Brill Pappin [EMAIL PROTECTED] wrote: So am I :) I think that just like TDD generates a whole new structure to your code (IMO a better one) that implementing generics at the start would have produced something a bit different. - Brill Pappin -Original Message- From: Igor Vaynberg [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 11:42 PM To: users@wicket.apache.org Subject: Re: users, please give us your opinion: what is your take on generics with Wicket im really curious to hear what these changes would be... -igor On Mon, Jun 2, 2008 at 8:25 PM, Brill Pappin [EMAIL PROTECTED] wrote: I think... We should be able to use the untyped variants, but the explanations for why that won't work directly was valid. So on to you're A/B question. I don't think it matters much... The people doing things inline are going to use that method anyway and generics won't hurt them, but the usefulness to people who write more extensive application is likely more important (if its that simple it doesn't matter much, if its complicated then it is and can be used). Allow me to digress. I think that if Wicket had been written with generics from the beginning, the API would be different... And that is the root of the problem. I think that maybe a concerted refactoring effort *must* allow the API to change (call it wicket 2.0 for all of us old struts users) in order for things to work out properly. I don't actually think that heavy a refactoring would be such a bad thing. I love what Wicket has done, but I think it could be less black-boxy as well. - Brill -Original Message- From: Stefan Lindner [mailto:[EMAIL PROTECTED] Sent: Monday, June 02, 2008 12:13 PM To: users@wicket.apache.org Subject: AW: users, please give us your opinion: what is your take on generics with Wicket Brill Pappin wrote 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
Re: users, please give us your opinion: what is your take on generics with Wicket
I *have* used the m1 release and although its not yet an RC and there are some issues to work out, it was a breath of fresh air. The biggest problem I had was understanding what kind of type to set things to, but once I sorted that out for a component, it made working with it later much easier. It not clean yet which made it a bit of a pain and I can understand why some would balk, but I can *definitely* see the joy on the horizon. that's my personal experience rather that my professional opinion. - Brill Pappin On Wed, Jun 4, 2008 at 2:40 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 11:30 PM, Eelco Hillenius [EMAIL PROTECTED] wrote: On Tue, Jun 3, 2008 at 10:37 PM, Igor Vaynberg [EMAIL PROTECTED] wrote: i think we should have qualified this rfi with a requirement that responders use 1.4 on a non-trivial project...these things only become apparent from real-world day-to-day usage. anything else is pretty much speculation. As for speculation... I don't agree. I haven't converted yet, but it is easy enough to just look at any old piece of code I'm working on now and imagine what it will look like after changing to 1.4. and there are also a lot of pain points that you will not imagine that do exist :) i am wondering how many of the keep as is in trunk votes came from people who only imagined what their code would look like and havent actually hit the numerous pain points those of us who did code gainst it hit. i was of the generify component and model mind while i was generifying the framework, but after coding against it i began to see some of the ugliness and now my mind is almost changed. -igor Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: AJAX slower than full page update
Yes, but we have many other things on the page. But why is it so slow? Is Wicket using some js functions that is extra slow in IE? If you google for IE javascript performance there are some recommendations, like here: http://blogs.msdn.com/ie/archive/2006/08/28/728654.aspx IE + JavaScript Performance Recommendations - Part 1 Have anyone looked at this issue before? BR Niels igor.vaynberg wrote: if the table is the only expensive component on your page then there is really no advantage to using ajax since you are adding all the overhead of javascript processing without saving anything. -igor On Tue, Jun 3, 2008 at 3:57 AM, Niels Bo [EMAIL PROTECTED] wrote: Hi I have observed that using AJAX to update of large content of a page is much slower than updating the full page withou AJAX. For example AJAX sorting a big DataTable (10x25) can be much slower that without AJAX, and I often see Client parsetime of more than a second in IE. FireFox seems to be faster, so I am hoping that is is possible to optimize the Wicket AJAX Javascript. Is this somthing that you Wicket developers will look into? Best Regards Niels -- View this message in context: http://www.nabble.com/AJAX-slower-than-full-page-update-tp17620961p17620961.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/AJAX-slower-than-full-page-update-tp17620961p17653337.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
If the type of component is getting in the way doesn't that mean the problem (non-trivial) component may need to be redesigned? - Brill Pappin On Wed, Jun 4, 2008 at 2:50 AM, Jan Kriesten [EMAIL PROTECTED] wrote: i was of the generify component and model mind while i was generifying the framework, but after coding against it i began to see some of the ugliness and now my mind is almost changed. yep, day to day usage is the main point. i came to that conclusion as well when i was trying to migrate somewhat non-trivial use of wicket to 1.4 base. the standard components like link et al aren't the real problem (though it doesn't look pretty), it gets complicated when you're using non-trivial components (like datatable and their dependents) where the type on the component gets in your way. - 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 agree with that and I think that is *the* key point. If implementing regular language features exposes a flaw, fix the flaw. I'm one of those that would rather have to refactor my code to upgrade to a new major version than try and work around some flaw just to maintain compatibility. - Brill Pappin On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: [...] Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. [...] - 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
Thats a pretty major api change (although it looks simple) maybe that
should be in the next major release?
- Brill
On Wed, Jun 4, 2008 at 1:30 PM, Patrick Angeles [EMAIL PROTECTED] wrote:
igor.vaynberg wrote:
component.detach() {
for (field:fields) {
if (imodel.class.isassignablefrom(field.gettype)) {
((imodel)field.get(this)).detach();
}
}
onDetach();
}
+1
I'm also for moving getModel()/getModelObject() out of Component and only
putting them in things that really use models, like Label and
FormComponent...
I agree, though, that this should probably wait for 1.5...
--
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-tp17589984p17652189.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: AJAX slower than full page update
honestly i havent noticed any slow performance on ie... -igor On Wed, Jun 4, 2008 at 11:25 AM, Niels Bo [EMAIL PROTECTED] wrote: Yes, but we have many other things on the page. But why is it so slow? Is Wicket using some js functions that is extra slow in IE? If you google for IE javascript performance there are some recommendations, like here: http://blogs.msdn.com/ie/archive/2006/08/28/728654.aspx IE + JavaScript Performance Recommendations - Part 1 Have anyone looked at this issue before? BR Niels igor.vaynberg wrote: if the table is the only expensive component on your page then there is really no advantage to using ajax since you are adding all the overhead of javascript processing without saving anything. -igor On Tue, Jun 3, 2008 at 3:57 AM, Niels Bo [EMAIL PROTECTED] wrote: Hi I have observed that using AJAX to update of large content of a page is much slower than updating the full page withou AJAX. For example AJAX sorting a big DataTable (10x25) can be much slower that without AJAX, and I often see Client parsetime of more than a second in IE. FireFox seems to be faster, so I am hoping that is is possible to optimize the Wicket AJAX Javascript. Is this somthing that you Wicket developers will look into? Best Regards Niels -- View this message in context: http://www.nabble.com/AJAX-slower-than-full-page-update-tp17620961p17620961.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/AJAX-slower-than-full-page-update-tp17620961p17653337.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 Session and non-Wicket Servlet
Guys, thanks for your help. I finally figured it out. I had my filters set up all wrong, as Larry pointed out. My previous web.xml, which worked in 2.0 was this: !-- Filters -- filter filter-nameWicketSessionFilter/filter-name filter-class wicket.protocol.http.servlet.WicketSessionFilter /filter-class init-param param-nameservletPath/param-name param-valueapp/param-value /init-param /filter filter filter-nameopenSessionInViewFilter/filter-name filter-class org.springframework.orm.hibernate3.support.OpenSessionInViewFilter /filter-class /filter !-- Filter Mappings -- filter-mapping filter-nameWicketSessionFilter/filter-name url-pattern/app/*/url-pattern /filter-mapping filter-mapping filter-nameWicketSessionFilter/filter-name url-pattern/report/url-pattern /filter-mapping filter-mapping filter-nameopenSessionInViewFilter/filter-name url-pattern/app/*/url-pattern /filter-mapping filter-mapping filter-nameopenSessionInViewFilter/filter-name url-pattern/report/url-pattern /filter-mapping !-- Listeners -- listener listener-class org.springframework.web.context.ContextLoaderListener /listener-class /listener !-- Servlet to serve up JasperReports. -- servlet servlet-nameJasperReportServlet/servlet-name servlet-class com.alliancemanaged.simis.web.jasperreport.JasperReportServlet /servlet-class load-on-startup1/load-on-startup /servlet !-- Servlet to serve images for JasperReport HTML output. -- servlet servlet-nameJasperImageServlet/servlet-name servlet-class com.alliancemanaged.simis.web.jasperreport.JasperImageServlet /servlet-class load-on-startup1/load-on-startup /servlet servlet servlet-nameWicketServlet/servlet-name servlet-classwicket.protocol.http.WicketServlet/servlet-class init-param param-nameapplicationClassName/param-name param-value com.alliancemanaged.simis.web.SIMISApplication /param-value /init-param init-param param-nameconfiguration/param-name param-valuedevelopment/param-value /init-param load-on-startup1/load-on-startup /servlet !-- URL Mappings -- servlet-mapping servlet-nameJasperReportServlet/servlet-name url-pattern/report/url-pattern /servlet-mapping servlet-mapping servlet-nameJasperImageServlet/servlet-name url-pattern/reportimage/url-pattern /servlet-mapping servlet-mapping servlet-nameWicketServlet/servlet-name url-pattern/app/*/url-pattern /servlet-mapping Notice I was previously using a servlet configuration, rather than a filter. When I migrated to 1.4, I converted to a filter. That's where my problem started, I guess. I didn't read the doc carefully enough, I suppose. I now have the following, which works great: filter filter-nameopenSessionInViewFilter/filter-name filter-class org.springframework.orm.hibernate3.support.OpenSessionInViewFilter /filter-class /filter filter filter-nameReportingApplication/filter-name filter-classorg.apache.wicket.protocol.http.WicketFilter/filter-class init-param param-nameapplicationClassName/param-name param-valuecom.alliancemanaged.simis.web.SIMISApplication/param-value /init-param /filter filter filter-nameWicketSessionFilter/filter-name filter-classorg.apache.wicket.protocol.http.servlet.WicketSessionFilter/filter-class init-param param-namefilterName/param-name param-valueReportingApplication/param-value /init-param /filter !-- Filter Mappings -- filter-mapping filter-nameopenSessionInViewFilter/filter-name url-pattern/app/*/url-pattern /filter-mapping filter-mapping filter-nameopenSessionInViewFilter/filter-name url-pattern/report/url-pattern /filter-mapping filter-mapping filter-nameReportingApplication/filter-name url-pattern/app/*/url-pattern dispatcherREQUEST/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping filter-mapping filter-nameWicketSessionFilter/filter-name url-pattern/report/*/url-pattern dispatcherREQUEST/dispatcher dispatcherINCLUDE/dispatcher /filter-mapping Thanks again for all the help. Regards, Matthew. On Tue, Jun 3, 2008 at 7:05 PM, Zappaterrini, Larry [EMAIL PROTECTED] wrote: The way the your web.xml is configured does not have the requests going to JasperReportServlet getting filtered by WicketSessionFilter. Change the filter mapping
Re: users, please give us your opinion: what is your take on generics with Wicket
i dont think it exposes anything, or that anything is flawed. the component provides a slot for a default model - it is there totally out of convinience. i think what is flawed here is that we tied the two types via generics. for example, sometimes i want to have a webmarkupcontainer with a model and sometimes without. -igor On Wed, Jun 4, 2008 at 11:30 AM, Brill Pappin [EMAIL PROTECTED] wrote: I agree with that and I think that is *the* key point. If implementing regular language features exposes a flaw, fix the flaw. I'm one of those that would rather have to refactor my code to upgrade to a new major version than try and work around some flaw just to maintain compatibility. - Brill Pappin On Wed, Jun 4, 2008 at 4:24 AM, Eelco Hillenius [EMAIL PROTECTED] wrote: [...] Personally, I think the whole generics business exposes that the one-one relation between components and models is flawed. Without generics this isn't much of a problem, just the odd unused member and constructor, but as generics aren't as 'optional' it is all very in your face suddenly. [...] - 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 1.3 - SNAPSHOT release dates
1.3.4 is sometime this week. Frank On Wed, Jun 4, 2008 at 6:58 PM, Ricky [EMAIL PROTECTED] wrote: Hi, Is there an estimated release date for Wicket 1.3.4 or for 1.3-SNAPSHOT ? Regards, Vyas, Anirudh
Does wicket favor composite session obj?
According to wicket API docs , I have a question. Does wicket favor composite session object ? That is , if my site has some independent apps , each has its custom setting object. It seems I have to associate these objects to one root session object : like this : App1Setting setting1 = ((RootSession)getSession()).getApp1Setting(); App2Setting setting2 = ((RootSession)getSession()).getApp2Setting(); Is it correct ?
Re: Does wicket favor composite session obj?
By default, Wicket will create separate session objects for each application. If you want to share info between multiple Wicket sessions, you'll have to access the underlying HttpSession object. Should be relatively easy to create an abstraction for that yourself. Eelco On Wed, Jun 4, 2008 at 11:57 AM, smallufo [EMAIL PROTECTED] wrote: According to wicket API docs , I have a question. Does wicket favor composite session object ? That is , if my site has some independent apps , each has its custom setting object. It seems I have to associate these objects to one root session object : like this : App1Setting setting1 = ((RootSession)getSession()).getApp1Setting(); App2Setting setting2 = ((RootSession)getSession()).getApp2Setting(); Is it correct ? - 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 Wed, Jun 4, 2008 at 11:35 AM, Brill Pappin [EMAIL PROTECTED] wrote: Thats a pretty major api change (although it looks simple) maybe that should be in the next major release? It's something we can consider yeah. We'll have to think it through and get back to the drawing board to see what that means for how components and models work together though. Consistency is very important in an API like Wicket's, and consistency is imho a big + in how models and components currently work together. Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket 1.3 - SNAPSHOT release dates
Thanks. I meant 1.3 - SNAPSHOT being finalized to a release version. appreciate your response. -- Regards Vyas, Anirudh || ॐ || On Wed, Jun 4, 2008 at 2:51 PM, Frank Bille [EMAIL PROTECTED] wrote: 1.3.4 is sometime this week. Frank On Wed, Jun 4, 2008 at 6:58 PM, Ricky [EMAIL PROTECTED] wrote: Hi, Is there an estimated release date for Wicket 1.3.4 or for 1.3-SNAPSHOT ? Regards, Vyas, Anirudh
Re: users, please give us your opinion: what is your take on generics with Wicket
I have to admit I haven't read thru all of this thread, so my answer might be to something else... But here we go: I think we actually do something very similar to this in our system, we automatically detach any instances of jpa-enitities (replacing them with a surrogate with only the class and id) and then get them again from the db-cache if the page is reconstructed again. So far it works like a charm and the programming model is very convinient. Just dump whatever entity you like as member of a component and it is automatically detached and then loaded back when needed. I implemented this by hooking in to serialization, just checking each object in ObjectOutputStream.replaceObject and ObjectInputStream.resolveObject. Also had to use my own PageMapEntries to get a suitable hook. Might work as an idea for your implementation perhaps? // Daniel jalbum.net On 2008-06-04, at 19:03, Eelco Hillenius wrote: On Wed, Jun 4, 2008 at 9:43 AM, Igor Vaynberg [EMAIL PROTECTED] wrote: you still have ondetach()...but for convinience we can automatically detach any imodel fields, i actually wanted to do this for a while... I tried to write this two days ago, but wasn't able to pull it off... I wrote an instantiation listener that introspected on the fields of components and replaced IModel members with a proxy. These proxies would register themselves with the request cycle for cleaning up whenever the getObject was called, and the request cycle then would go through the list of registered models and detach them at the end of the request. The problem I ran into however is that these members can be final, assigned at a later stage (typically are actually) and such. But if there is some way to automatically detach model members, we could get rid of the model member in component and instead just let components have models by default where it actually always makes sense, such as form components. Anyway, that's something for 1.5. If it is fixable, I think that would be the way out of the generics controversy :-) Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket 1.3 - SNAPSHOT release dates
1.3 has entered maintainance since all development effort is going into 1.4. It should therefore be safe to use snapshot releases since they will only be bug-fixes from a final 1.3.4 release. Frank On Wed, Jun 4, 2008 at 9:10 PM, Ricky [EMAIL PROTECTED] wrote: Thanks. I meant 1.3 - SNAPSHOT being finalized to a release version. appreciate your response. -- Regards Vyas, Anirudh || ॐ || On Wed, Jun 4, 2008 at 2:51 PM, Frank Bille [EMAIL PROTECTED] wrote: 1.3.4 is sometime this week. Frank On Wed, Jun 4, 2008 at 6:58 PM, Ricky [EMAIL PROTECTED] wrote: Hi, Is there an estimated release date for Wicket 1.3.4 or for 1.3-SNAPSHOT ? Regards, Vyas, Anirudh
Re: users, please give us your opinion: what is your take on generics with Wicket
I implemented this by hooking in to serialization, just checking each object in ObjectOutputStream.replaceObject and ObjectInputStream.resolveObject. Also had to use my own PageMapEntries to get a suitable hook. Might work as an idea for your implementation perhaps? That's a cool idea for individual projects. For Wicket in general however, the problem would be that it wouldn't work for every session store (it wouldn't for instance for HttpSessionStore which doesn't serialize on each request). Also, 1.3's default session store serializes on each request, but does not reuse that serialized instance until the back button is used (or if you're doing session replication and come in through another node I guess). Are you sure your detachment works like you think it does? Eelco - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
