Re: Page Expired page with PatternDateConverter
quickstart
11 Ekim 2010 16:00 tarihinde Hemant Shah prot...@gmail.com yazdı:
Yes, it works fine if we do not override the getConverter method. In which
case it behaves like a normal AjaxEditableLabel, as would be expected, and
we are using AjaxEditableLabel instances in many places in our application.
- Hemant
On 10/11/2010 6:24 AM, Altuğ Bilgin Altıntaş wrote:
if you don't override IConverter then everything works fine ?
2010/10/11 Hemant Shahprot...@gmail.com
Altuğ, thanks for responding.
There are no errors reported in the log. All the classes in the project
are
serializable.
Could this be a bug?
Regards,
Hemant
On 10/10/2010 5:03 PM, Altuğ Bilgin Altıntaş wrote:
Did you look at Wicket's logs ?
Be sure serialization is done correctly.
2010/10/10 Hemant Shahprot...@gmail.com
I am new to the Wicket framework and I hope I can get some help with a
problem I am facing.
I am using version 1.4.12.
I am overriding the AjaxEditableLabel class and its overridden
getConverter
method is at follows:
@Override
public IConverter. getConverter(Class type) {
return new PatternDateConverter(MM/dd/, true);
}
However, the first time in a session the component is updated, I get
the
Page Expired message. The error results only when the getConverter
method
is called.
Note that this happens only the first time I access it in a session. If
I
go to the home page and from there back to the page which contains the
component, it works without any problems.
I am not sure how to overcome this problem. I hope you guys can help.
Thanks.
- Hemant
Re: Page Expired page with PatternDateConverter
if you don't override IConverter then everything works fine ?
2010/10/11 Hemant Shah prot...@gmail.com
Altuğ, thanks for responding.
There are no errors reported in the log. All the classes in the project are
serializable.
Could this be a bug?
Regards,
Hemant
On 10/10/2010 5:03 PM, Altuğ Bilgin Altıntaş wrote:
Did you look at Wicket's logs ?
Be sure serialization is done correctly.
2010/10/10 Hemant Shahprot...@gmail.com
I am new to the Wicket framework and I hope I can get some help with a
problem I am facing.
I am using version 1.4.12.
I am overriding the AjaxEditableLabel class and its overridden
getConverter
method is at follows:
@Override
public IConverter. getConverter(Class type) {
return new PatternDateConverter(MM/dd/, true);
}
However, the first time in a session the component is updated, I get the
Page Expired message. The error results only when the getConverter
method
is called.
Note that this happens only the first time I access it in a session. If I
go to the home page and from there back to the page which contains the
component, it works without any problems.
I am not sure how to overcome this problem. I hope you guys can help.
Thanks.
- Hemant
Re: Page Expired page with PatternDateConverter
Yes, it works fine if we do not override the getConverter method. In
which case it behaves like a normal AjaxEditableLabel, as would be
expected, and we are using AjaxEditableLabel instances in many places in
our application.
- Hemant
On 10/11/2010 6:24 AM, Altuğ Bilgin Altıntaş wrote:
if you don't override IConverter then everything works fine ?
2010/10/11 Hemant Shahprot...@gmail.com
Altuğ, thanks for responding.
There are no errors reported in the log. All the classes in the project are
serializable.
Could this be a bug?
Regards,
Hemant
On 10/10/2010 5:03 PM, Altuğ Bilgin Altıntaş wrote:
Did you look at Wicket's logs ?
Be sure serialization is done correctly.
2010/10/10 Hemant Shahprot...@gmail.com
I am new to the Wicket framework and I hope I can get some help with a
problem I am facing.
I am using version 1.4.12.
I am overriding the AjaxEditableLabel class and its overridden
getConverter
method is at follows:
@Override
public IConverter. getConverter(Class type) {
return new PatternDateConverter(MM/dd/, true);
}
However, the first time in a session the component is updated, I get the
Page Expired message. The error results only when the getConverter
method
is called.
Note that this happens only the first time I access it in a session. If I
go to the home page and from there back to the page which contains the
component, it works without any problems.
I am not sure how to overcome this problem. I hope you guys can help.
Thanks.
- Hemant
Re: Page Expired page with PatternDateConverter
Did you look at Wicket's logs ?
Be sure serialization is done correctly.
2010/10/10 Hemant Shah prot...@gmail.com
I am new to the Wicket framework and I hope I can get some help with a
problem I am facing.
I am using version 1.4.12.
I am overriding the AjaxEditableLabel class and its overridden getConverter
method is at follows:
@Override
public IConverter. getConverter(Class type) {
return new PatternDateConverter(MM/dd/, true);
}
However, the first time in a session the component is updated, I get the
Page Expired message. The error results only when the getConverter method
is called.
Note that this happens only the first time I access it in a session. If I
go to the home page and from there back to the page which contains the
component, it works without any problems.
I am not sure how to overcome this problem. I hope you guys can help.
Thanks.
- Hemant
Re: Page Expired page with PatternDateConverter
Altuğ, thanks for responding.
There are no errors reported in the log. All the classes in the project
are serializable.
Could this be a bug?
Regards,
Hemant
On 10/10/2010 5:03 PM, Altuğ Bilgin Altıntaş wrote:
Did you look at Wicket's logs ?
Be sure serialization is done correctly.
2010/10/10 Hemant Shahprot...@gmail.com
I am new to the Wicket framework and I hope I can get some help with a
problem I am facing.
I am using version 1.4.12.
I am overriding the AjaxEditableLabel class and its overridden getConverter
method is at follows:
@Override
public IConverter. getConverter(Class type) {
return new PatternDateConverter(MM/dd/, true);
}
However, the first time in a session the component is updated, I get the
Page Expired message. The error results only when the getConverter method
is called.
Note that this happens only the first time I access it in a session. If I
go to the home page and from there back to the page which contains the
component, it works without any problems.
I am not sure how to overcome this problem. I hope you guys can help.
Thanks.
- Hemant
Re: Page in Page
Thank all for the help. Am 28.05.2010 07:21, schrieb Jeremy Thomerson: On Fri, May 28, 2010 at 12:08 AM, Chris Colmanchr...@stepaheadsoftware.com wrote: I think the concepts are very different. The opinion that they are effectively the same was raised in the earlier discussion (probably more than a year ago). Your suggestion involved using child/extend for one of the overridable sections and then doing the other section with div wicket:id=body[body]/div If it's just as good or just as easy to implement using the later option then why not do both with the later suggestion? The reason they are different is that the later is not true markup inheritance. A child/extend section is indeed true markup inheritance, albeit, we're currently constrained to a single inheritable/overridable section per page but as was agreed a year ago limiting wicket to a single overidable section was an 'arbitrary constraint' and has nothing to do with maintaining a single inheritance model. A single inheritance model only imposes the constraint that each page directly extends only one other page and that constraint is clearly not violated by having multiple overridable sections. -Original Message- From: Jeremy Thomerson [mailto:jer...@wickettraining.com] Sent: Friday, 28 May 2010 8:40 AM To: users@wicket.apache.org Subject: Re: Page in Page On Thu, May 27, 2010 at 5:33 PM, Chris Colman chr...@stepaheadsoftware.comwrote: Wicket (just like Java) does not support multiple inheritance. If you're creating a base page that has two blocks that need to be filled in, you can: I agree that wicket shouldn't support multiple inheritance but I'm not sure that what is required here is multiple inheritance. In the wicket parallel universe multiple inheritance would be represented by one page extending from multiple base pages but that's not what is required here and that would indeed be a bad path to trod. What I have had the need for many times is for a base page to have multiple overridable 'sections' - one base page but multiple sections within that page that could be overridden (or not) by pages that extend that page. This does not represent multiple inheritance. It is the equivalent of Java allowing multiple overridable methods in a single base class. In Java classes that extend the base class can override one or more of the virtual (non final) methods in the base class but the same rule applies - any class/page can only extend a single base class/page. The constraint that wicket has now is that only one section of a page can be overridden by the 'limit of one' child/extend wicket tags. As only one overridable section is currently allowed in wicket there is no need to identify it. If wicket were to allow multiple sections in a base page to be overridden in derived pages then a simple identification scheme would be required - much like Java uses method signatures to identify the methods that are being overridden. Eg., BasePage.html: body div id=container wicket:section id=header !-- markup will be used if no derived page overrides it --. h1my website/h1. /wicket:section hr / wicket:section id=body !-- a derived page should override this -- /wicket;section hr / !-- footer same for every page - no overriding -- div class=footer pcopyright 2010 acme corp/p /div /div /body WelcomePage.html: body !-- happy to use base page's header so no header section override -- wicket:section id=body h1Welcome to my website!/h1 My website is the best because it uses wicket! /wicket:section /body Note how I've used the same tag 'section' in both base and extended pages to avoid the obvious issue that occurs should someone extend the WelcomePage.html above. Ie. When inheritance is chained over more than two levels. In that case it becomes very wrong to specify whether a section is 'overriding' (extend) or can be overridden (child). Much like in Java inheritance you don't specify each method as being a 'child' or 'extension'. Instead, the mere presence of a method with identical signature as in a base class indicates that that method is overriding the base class method. That would seem an obvious model for overridable markup sections in wicket also. This idea/issue has been raised a few times before in this list and once a remarkably small patch was even developed that would enable this to work. - To unsubscribe, e-mail: users
Re: Page in Page
On Thu, May 27, 2010 at 2:30 PM, Christian Märzinger christian.maerzin...@gmail.com wrote: Hi! How can I embedd a page in another page? i have following Homepage wicket div id=header class=borderedBlock table width=100% header text br / header text 2 /table /div table width=100% tr td id=left class=borderedBlock ul div id=treeTablewicket:child //div /ul /td td id=content class=borderedBlock div id=map2wicket:child //div /td /tr /table div id=footer class=borderedBlock@ footer footer/div /wicket now i try to put a map in the content and a tree table at the left side Thanks - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org Wicket (just like Java) does not support multiple inheritance. If you're creating a base page that has two blocks that need to be filled in, you can: 1 - make one of them use the wicket:child tag - like you have done. pages that are subclasses will then wrap wicket:extend tags around their content, and this will appear in the place of the wicket:child tag 2 - then, for the other location, use something like div wicket:id=tree[tree]/div and in your base page java, do: add(createTreeForThisPage(tree)), where createTreeForThisPage is defined as protected abstract Component createTreeForThisPage(String id). Pages that extend this base page will be required to return the component for that location. Or, you can skip the inheritance and use #2 above for both locations on the page. -- Jeremy Thomerson http://www.wickettraining.com
RE: Page in Page
Wicket (just like Java) does not support multiple inheritance. If you're creating a base page that has two blocks that need to be filled in, you can: I agree that wicket shouldn't support multiple inheritance but I'm not sure that what is required here is multiple inheritance. In the wicket parallel universe multiple inheritance would be represented by one page extending from multiple base pages but that's not what is required here and that would indeed be a bad path to trod. What I have had the need for many times is for a base page to have multiple overridable 'sections' - one base page but multiple sections within that page that could be overridden (or not) by pages that extend that page. This does not represent multiple inheritance. It is the equivalent of Java allowing multiple overridable methods in a single base class. In Java classes that extend the base class can override one or more of the virtual (non final) methods in the base class but the same rule applies - any class/page can only extend a single base class/page. The constraint that wicket has now is that only one section of a page can be overridden by the 'limit of one' child/extend wicket tags. As only one overridable section is currently allowed in wicket there is no need to identify it. If wicket were to allow multiple sections in a base page to be overridden in derived pages then a simple identification scheme would be required - much like Java uses method signatures to identify the methods that are being overridden. Eg., BasePage.html: body div id=container wicket:section id=header !-- markup will be used if no derived page overrides it --. h1my website/h1. /wicket:section hr / wicket:section id=body !-- a derived page should override this -- /wicket;section hr / !-- footer same for every page - no overriding -- div class=footer pcopyright 2010 acme corp/p /div /div /body WelcomePage.html: body !-- happy to use base page's header so no header section override -- wicket:section id=body h1Welcome to my website!/h1 My website is the best because it uses wicket! /wicket:section /body Note how I've used the same tag 'section' in both base and extended pages to avoid the obvious issue that occurs should someone extend the WelcomePage.html above. Ie. When inheritance is chained over more than two levels. In that case it becomes very wrong to specify whether a section is 'overriding' (extend) or can be overridden (child). Much like in Java inheritance you don't specify each method as being a 'child' or 'extension'. Instead, the mere presence of a method with identical signature as in a base class indicates that that method is overriding the base class method. That would seem an obvious model for overridable markup sections in wicket also. This idea/issue has been raised a few times before in this list and once a remarkably small patch was even developed that would enable this to work. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Page in Page
On Thu, May 27, 2010 at 5:33 PM, Chris Colman chr...@stepaheadsoftware.comwrote: Wicket (just like Java) does not support multiple inheritance. If you're creating a base page that has two blocks that need to be filled in, you can: I agree that wicket shouldn't support multiple inheritance but I'm not sure that what is required here is multiple inheritance. In the wicket parallel universe multiple inheritance would be represented by one page extending from multiple base pages but that's not what is required here and that would indeed be a bad path to trod. What I have had the need for many times is for a base page to have multiple overridable 'sections' - one base page but multiple sections within that page that could be overridden (or not) by pages that extend that page. This does not represent multiple inheritance. It is the equivalent of Java allowing multiple overridable methods in a single base class. In Java classes that extend the base class can override one or more of the virtual (non final) methods in the base class but the same rule applies - any class/page can only extend a single base class/page. The constraint that wicket has now is that only one section of a page can be overridden by the 'limit of one' child/extend wicket tags. As only one overridable section is currently allowed in wicket there is no need to identify it. If wicket were to allow multiple sections in a base page to be overridden in derived pages then a simple identification scheme would be required - much like Java uses method signatures to identify the methods that are being overridden. Eg., BasePage.html: body div id=container wicket:section id=header !-- markup will be used if no derived page overrides it --. h1my website/h1. /wicket:section hr / wicket:section id=body !-- a derived page should override this -- /wicket;section hr / !-- footer same for every page - no overriding -- div class=footer pcopyright 2010 acme corp/p /div /div /body WelcomePage.html: body !-- happy to use base page's header so no header section override -- wicket:section id=body h1Welcome to my website!/h1 My website is the best because it uses wicket! /wicket:section /body Note how I've used the same tag 'section' in both base and extended pages to avoid the obvious issue that occurs should someone extend the WelcomePage.html above. Ie. When inheritance is chained over more than two levels. In that case it becomes very wrong to specify whether a section is 'overriding' (extend) or can be overridden (child). Much like in Java inheritance you don't specify each method as being a 'child' or 'extension'. Instead, the mere presence of a method with identical signature as in a base class indicates that that method is overriding the base class method. That would seem an obvious model for overridable markup sections in wicket also. This idea/issue has been raised a few times before in this list and once a remarkably small patch was even developed that would enable this to work. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org And how is your proposed solution any different than the solution that I gave you (putting div wicket:id=body[body]/div in your markup and creating an abstract method that child classes must implement)? It's exactly the same except that now people would have to learn a new wicket:section tag. This doesn't make sense and it strays from Wicket's just java / just html motto. The two solutions are functionally the same and only cosmetically different. -- Jeremy Thomerson http://www.wickettraining.com
RE: Page in Page
I think the concepts are very different. The opinion that they are effectively the same was raised in the earlier discussion (probably more than a year ago). Your suggestion involved using child/extend for one of the overridable sections and then doing the other section with div wicket:id=body[body]/div If it's just as good or just as easy to implement using the later option then why not do both with the later suggestion? The reason they are different is that the later is not true markup inheritance. A child/extend section is indeed true markup inheritance, albeit, we're currently constrained to a single inheritable/overridable section per page but as was agreed a year ago limiting wicket to a single overidable section was an 'arbitrary constraint' and has nothing to do with maintaining a single inheritance model. A single inheritance model only imposes the constraint that each page directly extends only one other page and that constraint is clearly not violated by having multiple overridable sections. -Original Message- From: Jeremy Thomerson [mailto:jer...@wickettraining.com] Sent: Friday, 28 May 2010 8:40 AM To: users@wicket.apache.org Subject: Re: Page in Page On Thu, May 27, 2010 at 5:33 PM, Chris Colman chr...@stepaheadsoftware.comwrote: Wicket (just like Java) does not support multiple inheritance. If you're creating a base page that has two blocks that need to be filled in, you can: I agree that wicket shouldn't support multiple inheritance but I'm not sure that what is required here is multiple inheritance. In the wicket parallel universe multiple inheritance would be represented by one page extending from multiple base pages but that's not what is required here and that would indeed be a bad path to trod. What I have had the need for many times is for a base page to have multiple overridable 'sections' - one base page but multiple sections within that page that could be overridden (or not) by pages that extend that page. This does not represent multiple inheritance. It is the equivalent of Java allowing multiple overridable methods in a single base class. In Java classes that extend the base class can override one or more of the virtual (non final) methods in the base class but the same rule applies - any class/page can only extend a single base class/page. The constraint that wicket has now is that only one section of a page can be overridden by the 'limit of one' child/extend wicket tags. As only one overridable section is currently allowed in wicket there is no need to identify it. If wicket were to allow multiple sections in a base page to be overridden in derived pages then a simple identification scheme would be required - much like Java uses method signatures to identify the methods that are being overridden. Eg., BasePage.html: body div id=container wicket:section id=header !-- markup will be used if no derived page overrides it --. h1my website/h1. /wicket:section hr / wicket:section id=body !-- a derived page should override this -- /wicket;section hr / !-- footer same for every page - no overriding -- div class=footer pcopyright 2010 acme corp/p /div /div /body WelcomePage.html: body !-- happy to use base page's header so no header section override -- wicket:section id=body h1Welcome to my website!/h1 My website is the best because it uses wicket! /wicket:section /body Note how I've used the same tag 'section' in both base and extended pages to avoid the obvious issue that occurs should someone extend the WelcomePage.html above. Ie. When inheritance is chained over more than two levels. In that case it becomes very wrong to specify whether a section is 'overriding' (extend) or can be overridden (child). Much like in Java inheritance you don't specify each method as being a 'child' or 'extension'. Instead, the mere presence of a method with identical signature as in a base class indicates that that method is overriding the base class method. That would seem an obvious model for overridable markup sections in wicket also. This idea/issue has been raised a few times before in this list and once a remarkably small patch was even developed that would enable this to work. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org And how is your proposed solution any different than the solution that I gave you (putting div wicket:id=body[body]/div in your markup and creating an abstract method that child classes must implement)? It's exactly the same except that now people would have to learn a new wicket:section tag. This doesn't make sense and it strays from Wicket's just
Re: Page in Page
On Fri, May 28, 2010 at 12:08 AM, Chris Colman chr...@stepaheadsoftware.com wrote: I think the concepts are very different. The opinion that they are effectively the same was raised in the earlier discussion (probably more than a year ago). Your suggestion involved using child/extend for one of the overridable sections and then doing the other section with div wicket:id=body[body]/div If it's just as good or just as easy to implement using the later option then why not do both with the later suggestion? The reason they are different is that the later is not true markup inheritance. A child/extend section is indeed true markup inheritance, albeit, we're currently constrained to a single inheritable/overridable section per page but as was agreed a year ago limiting wicket to a single overidable section was an 'arbitrary constraint' and has nothing to do with maintaining a single inheritance model. A single inheritance model only imposes the constraint that each page directly extends only one other page and that constraint is clearly not violated by having multiple overridable sections. -Original Message- From: Jeremy Thomerson [mailto:jer...@wickettraining.com] Sent: Friday, 28 May 2010 8:40 AM To: users@wicket.apache.org Subject: Re: Page in Page On Thu, May 27, 2010 at 5:33 PM, Chris Colman chr...@stepaheadsoftware.comwrote: Wicket (just like Java) does not support multiple inheritance. If you're creating a base page that has two blocks that need to be filled in, you can: I agree that wicket shouldn't support multiple inheritance but I'm not sure that what is required here is multiple inheritance. In the wicket parallel universe multiple inheritance would be represented by one page extending from multiple base pages but that's not what is required here and that would indeed be a bad path to trod. What I have had the need for many times is for a base page to have multiple overridable 'sections' - one base page but multiple sections within that page that could be overridden (or not) by pages that extend that page. This does not represent multiple inheritance. It is the equivalent of Java allowing multiple overridable methods in a single base class. In Java classes that extend the base class can override one or more of the virtual (non final) methods in the base class but the same rule applies - any class/page can only extend a single base class/page. The constraint that wicket has now is that only one section of a page can be overridden by the 'limit of one' child/extend wicket tags. As only one overridable section is currently allowed in wicket there is no need to identify it. If wicket were to allow multiple sections in a base page to be overridden in derived pages then a simple identification scheme would be required - much like Java uses method signatures to identify the methods that are being overridden. Eg., BasePage.html: body div id=container wicket:section id=header !-- markup will be used if no derived page overrides it --. h1my website/h1. /wicket:section hr / wicket:section id=body !-- a derived page should override this -- /wicket;section hr / !-- footer same for every page - no overriding -- div class=footer pcopyright 2010 acme corp/p /div /div /body WelcomePage.html: body !-- happy to use base page's header so no header section override -- wicket:section id=body h1Welcome to my website!/h1 My website is the best because it uses wicket! /wicket:section /body Note how I've used the same tag 'section' in both base and extended pages to avoid the obvious issue that occurs should someone extend the WelcomePage.html above. Ie. When inheritance is chained over more than two levels. In that case it becomes very wrong to specify whether a section is 'overriding' (extend) or can be overridden (child). Much like in Java inheritance you don't specify each method as being a 'child' or 'extension'. Instead, the mere presence of a method with identical signature as in a base class indicates that that method is overriding the base class method. That would seem an obvious model for overridable markup sections in wicket also. This idea/issue has been raised a few times before in this list and once a remarkably small patch was even developed that would enable this to work. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org And how is your proposed solution any different than the solution that I gave you (putting div wicket:id=body[body]/div in your markup
