Re: multi-window support, pagestores and wicket 1.5
Thank you for your replies Igor. I have another question regarding to clustered environment. Suppose we have versioned pages opened in two windows. If one node goes down, only the last page user made request from is stored in http session and replicated to other nodes. So i suppose that only one page would work and the state from the second page is lost. So multi-window support for stateful pages (even versioned) wouldn't work in clustered environment. Is this true? I think that even weird javascript solution for multiple windows would be good (it could be turned off by default), because we are unable to migrate our existing wicket projects, or create stateful application in multiple windows/tabs running in the cluster. This was supported out-of-box by wicket previous versions. I know that there is a possibility to provide implementation IPageManager, but there is missing support for browser window detection so its a bit more complicated to implement IPageManager supporting multiple windows in clustered environment. BR, Michal 2010/12/13 Igor Vaynberg igor.vaynb...@gmail.com: On Sat, Dec 11, 2010 at 12:04 PM, Michal Kurtak michal.kur...@gmail.com wrote: Hi folks, I know that there has been a lot of written about pagestores and multi-window support in wicket 1.5, but i have several other questions: 1. Is multi-window supported for non-versioned pages? If page is versioned everything works ok, but i always get StalePageExceptions when i use multiple windows/tabs with non-versioned pages. I think that StalePageException is useful in some cases when you wanna be sure that user has same page in all windows, but in older versions of wicket it was possible to have non versioned pages and multi-window support together (e.g. we have an application written in wicket 1.2.6 that uses non-versioned pages in multiple windows) no, it is not supported. supporting it has been problematic even in 1.4.x series where it required javascript and introduced a strange redirect that happened as soon as the page was loaded. unversioned pages also cause weird issues with the back button. if you want something that is unversioned then i think building it as stateless makes more sense. 2. How page stores work in clustered environment? In older versions of wicket we used pagemaps stored in HttpSession. When one node in cluster refuses to handle request, it was successfully handled by another nod, because HttpSession was replicated to another node. We have used non-versioned pages (no back button support needed) and in one pagemap there was max 5 pages. Wicket provided this functionality out-of-box. in both 1.4.x and 1.5.x by default we store the current page in session and the rest are spooled to disk. the current page is replicated to all nodes since it is stored in session, so any node can pick up a request. 3. How to achieve this in wicket 1.5? I have found PersistentPageManager which uses IPageStore to store pages. Pages are stored on disk by default, but there is also thread safe SerializedPagesCache with SoftReferences. Theres no out-of-box solution to store pages in HttpSession. I have also found file page-management.txt in org.apache.wicket.page package. It contains proposal of other pagamanagers and multi-window support for non-versioned pages. The proposal contains classes PersistentPageManager with DiskPageStore and SecondLevelCacheSessionStore for versioned pages SessionManager for holding non versioned pages in HttpSession. 4. Can we expect that this proposal will be implemented in wicket 1.5 final version? no. the current version is feature complete and we are concentrating on bugfixing. a more sophisticated page management may be introduced in the future. we have concentrated on the 99% usecase and simplified the code for that. you can implement your own page storage strategies as you see fit. -igor Thanks for your replies. BR, Michal Kurtak - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: multi-window support, pagestores and wicket 1.5
Hmm... This solutions seems really good. sorry for bothering michal 2010/12/13 Igor Vaynberg igor.vaynb...@gmail.com: when the page that is stored in http session is deserialized on another node it is also spooled to disk. so in a cluster all nodes have identical spooled pages - so everything should work. -igor On Mon, Dec 13, 2010 at 8:00 PM, Michal Kurtak michal.kur...@gmail.com wrote: Thank you for your replies Igor. I have another question regarding to clustered environment. Suppose we have versioned pages opened in two windows. If one node goes down, only the last page user made request from is stored in http session and replicated to other nodes. So i suppose that only one page would work and the state from the second page is lost. So multi-window support for stateful pages (even versioned) wouldn't work in clustered environment. Is this true? I think that even weird javascript solution for multiple windows would be good (it could be turned off by default), because we are unable to migrate our existing wicket projects, or create stateful application in multiple windows/tabs running in the cluster. This was supported out-of-box by wicket previous versions. I know that there is a possibility to provide implementation IPageManager, but there is missing support for browser window detection so its a bit more complicated to implement IPageManager supporting multiple windows in clustered environment. BR, Michal 2010/12/13 Igor Vaynberg igor.vaynb...@gmail.com: On Sat, Dec 11, 2010 at 12:04 PM, Michal Kurtak michal.kur...@gmail.com wrote: Hi folks, I know that there has been a lot of written about pagestores and multi-window support in wicket 1.5, but i have several other questions: 1. Is multi-window supported for non-versioned pages? If page is versioned everything works ok, but i always get StalePageExceptions when i use multiple windows/tabs with non-versioned pages. I think that StalePageException is useful in some cases when you wanna be sure that user has same page in all windows, but in older versions of wicket it was possible to have non versioned pages and multi-window support together (e.g. we have an application written in wicket 1.2.6 that uses non-versioned pages in multiple windows) no, it is not supported. supporting it has been problematic even in 1.4.x series where it required javascript and introduced a strange redirect that happened as soon as the page was loaded. unversioned pages also cause weird issues with the back button. if you want something that is unversioned then i think building it as stateless makes more sense. 2. How page stores work in clustered environment? In older versions of wicket we used pagemaps stored in HttpSession. When one node in cluster refuses to handle request, it was successfully handled by another nod, because HttpSession was replicated to another node. We have used non-versioned pages (no back button support needed) and in one pagemap there was max 5 pages. Wicket provided this functionality out-of-box. in both 1.4.x and 1.5.x by default we store the current page in session and the rest are spooled to disk. the current page is replicated to all nodes since it is stored in session, so any node can pick up a request. 3. How to achieve this in wicket 1.5? I have found PersistentPageManager which uses IPageStore to store pages. Pages are stored on disk by default, but there is also thread safe SerializedPagesCache with SoftReferences. Theres no out-of-box solution to store pages in HttpSession. I have also found file page-management.txt in org.apache.wicket.page package. It contains proposal of other pagamanagers and multi-window support for non-versioned pages. The proposal contains classes PersistentPageManager with DiskPageStore and SecondLevelCacheSessionStore for versioned pages SessionManager for holding non versioned pages in HttpSession. 4. Can we expect that this proposal will be implemented in wicket 1.5 final version? no. the current version is feature complete and we are concentrating on bugfixing. a more sophisticated page management may be introduced in the future. we have concentrated on the 99% usecase and simplified the code for that. you can implement your own page storage strategies as you see fit. -igor Thanks for your replies. BR, Michal Kurtak - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: multi-window support, pagestores and wicket 1.5
And one more thing. do you have some benchmarks comparing DiskDataStore, AsynchronousDataStore to Pagemaps stored in http sessions (as in earlier wicket versions)? I mean writing pages to disks comparing to writing them to http session (and replicating big sessions)? 2010/12/13 Michal Kurtak michal.kur...@gmail.com: Hmm... This solutions seems really good. sorry for bothering michal 2010/12/13 Igor Vaynberg igor.vaynb...@gmail.com: when the page that is stored in http session is deserialized on another node it is also spooled to disk. so in a cluster all nodes have identical spooled pages - so everything should work. -igor On Mon, Dec 13, 2010 at 8:00 PM, Michal Kurtak michal.kur...@gmail.com wrote: Thank you for your replies Igor. I have another question regarding to clustered environment. Suppose we have versioned pages opened in two windows. If one node goes down, only the last page user made request from is stored in http session and replicated to other nodes. So i suppose that only one page would work and the state from the second page is lost. So multi-window support for stateful pages (even versioned) wouldn't work in clustered environment. Is this true? I think that even weird javascript solution for multiple windows would be good (it could be turned off by default), because we are unable to migrate our existing wicket projects, or create stateful application in multiple windows/tabs running in the cluster. This was supported out-of-box by wicket previous versions. I know that there is a possibility to provide implementation IPageManager, but there is missing support for browser window detection so its a bit more complicated to implement IPageManager supporting multiple windows in clustered environment. BR, Michal 2010/12/13 Igor Vaynberg igor.vaynb...@gmail.com: On Sat, Dec 11, 2010 at 12:04 PM, Michal Kurtak michal.kur...@gmail.com wrote: Hi folks, I know that there has been a lot of written about pagestores and multi-window support in wicket 1.5, but i have several other questions: 1. Is multi-window supported for non-versioned pages? If page is versioned everything works ok, but i always get StalePageExceptions when i use multiple windows/tabs with non-versioned pages. I think that StalePageException is useful in some cases when you wanna be sure that user has same page in all windows, but in older versions of wicket it was possible to have non versioned pages and multi-window support together (e.g. we have an application written in wicket 1.2.6 that uses non-versioned pages in multiple windows) no, it is not supported. supporting it has been problematic even in 1.4.x series where it required javascript and introduced a strange redirect that happened as soon as the page was loaded. unversioned pages also cause weird issues with the back button. if you want something that is unversioned then i think building it as stateless makes more sense. 2. How page stores work in clustered environment? In older versions of wicket we used pagemaps stored in HttpSession. When one node in cluster refuses to handle request, it was successfully handled by another nod, because HttpSession was replicated to another node. We have used non-versioned pages (no back button support needed) and in one pagemap there was max 5 pages. Wicket provided this functionality out-of-box. in both 1.4.x and 1.5.x by default we store the current page in session and the rest are spooled to disk. the current page is replicated to all nodes since it is stored in session, so any node can pick up a request. 3. How to achieve this in wicket 1.5? I have found PersistentPageManager which uses IPageStore to store pages. Pages are stored on disk by default, but there is also thread safe SerializedPagesCache with SoftReferences. Theres no out-of-box solution to store pages in HttpSession. I have also found file page-management.txt in org.apache.wicket.page package. It contains proposal of other pagamanagers and multi-window support for non-versioned pages. The proposal contains classes PersistentPageManager with DiskPageStore and SecondLevelCacheSessionStore for versioned pages SessionManager for holding non versioned pages in HttpSession. 4. Can we expect that this proposal will be implemented in wicket 1.5 final version? no. the current version is feature complete and we are concentrating on bugfixing. a more sophisticated page management may be introduced in the future. we have concentrated on the 99% usecase and simplified the code for that. you can implement your own page storage strategies as you see fit. -igor Thanks for your replies. BR, Michal Kurtak - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: multi-window support, pagestores and wicket 1.5
We are developing (at my employer) UI library based on wicket 1.5 (former version was based on wicket 1.2.6.) and we will make performance measurements so I can provide you some results:) But the tests will be made in January, if it doesn't matter 2010/12/13 Igor Vaynberg igor.vaynb...@gmail.com: no, but you are welcome to test and ping us back with the results :) -igor On Mon, Dec 13, 2010 at 8:14 PM, Michal Kurtak michal.kur...@gmail.com wrote: And one more thing. do you have some benchmarks comparing DiskDataStore, AsynchronousDataStore to Pagemaps stored in http sessions (as in earlier wicket versions)? I mean writing pages to disks comparing to writing them to http session (and replicating big sessions)? 2010/12/13 Michal Kurtak michal.kur...@gmail.com: Hmm... This solutions seems really good. sorry for bothering michal 2010/12/13 Igor Vaynberg igor.vaynb...@gmail.com: when the page that is stored in http session is deserialized on another node it is also spooled to disk. so in a cluster all nodes have identical spooled pages - so everything should work. -igor On Mon, Dec 13, 2010 at 8:00 PM, Michal Kurtak michal.kur...@gmail.com wrote: Thank you for your replies Igor. I have another question regarding to clustered environment. Suppose we have versioned pages opened in two windows. If one node goes down, only the last page user made request from is stored in http session and replicated to other nodes. So i suppose that only one page would work and the state from the second page is lost. So multi-window support for stateful pages (even versioned) wouldn't work in clustered environment. Is this true? I think that even weird javascript solution for multiple windows would be good (it could be turned off by default), because we are unable to migrate our existing wicket projects, or create stateful application in multiple windows/tabs running in the cluster. This was supported out-of-box by wicket previous versions. I know that there is a possibility to provide implementation IPageManager, but there is missing support for browser window detection so its a bit more complicated to implement IPageManager supporting multiple windows in clustered environment. BR, Michal 2010/12/13 Igor Vaynberg igor.vaynb...@gmail.com: On Sat, Dec 11, 2010 at 12:04 PM, Michal Kurtak michal.kur...@gmail.com wrote: Hi folks, I know that there has been a lot of written about pagestores and multi-window support in wicket 1.5, but i have several other questions: 1. Is multi-window supported for non-versioned pages? If page is versioned everything works ok, but i always get StalePageExceptions when i use multiple windows/tabs with non-versioned pages. I think that StalePageException is useful in some cases when you wanna be sure that user has same page in all windows, but in older versions of wicket it was possible to have non versioned pages and multi-window support together (e.g. we have an application written in wicket 1.2.6 that uses non-versioned pages in multiple windows) no, it is not supported. supporting it has been problematic even in 1.4.x series where it required javascript and introduced a strange redirect that happened as soon as the page was loaded. unversioned pages also cause weird issues with the back button. if you want something that is unversioned then i think building it as stateless makes more sense. 2. How page stores work in clustered environment? In older versions of wicket we used pagemaps stored in HttpSession. When one node in cluster refuses to handle request, it was successfully handled by another nod, because HttpSession was replicated to another node. We have used non-versioned pages (no back button support needed) and in one pagemap there was max 5 pages. Wicket provided this functionality out-of-box. in both 1.4.x and 1.5.x by default we store the current page in session and the rest are spooled to disk. the current page is replicated to all nodes since it is stored in session, so any node can pick up a request. 3. How to achieve this in wicket 1.5? I have found PersistentPageManager which uses IPageStore to store pages. Pages are stored on disk by default, but there is also thread safe SerializedPagesCache with SoftReferences. Theres no out-of-box solution to store pages in HttpSession. I have also found file page-management.txt in org.apache.wicket.page package. It contains proposal of other pagamanagers and multi-window support for non-versioned pages. The proposal contains classes PersistentPageManager with DiskPageStore and SecondLevelCacheSessionStore for versioned pages SessionManager for holding non versioned pages in HttpSession. 4. Can we expect that this proposal will be implemented in wicket 1.5 final version? no. the current version is feature complete and we are concentrating on bugfixing. a more sophisticated page management may be introduced in the future. we have
Re: StalePageException and AJAX possible bug
JIRA issue created https://issues.apache.org/jira/browse/WICKET-3252 2010/12/11 Martin Grigorov mgrigo...@apache.org: Yes, please. Create a ticket with a quickstart. Even better - with a patch ;-) On Sat, Dec 11, 2010 at 10:26 AM, Michal Kurtak michal.kur...@gmail.comwrote: Hi, I have encountered a problem when using not versioned page with AJAX in multiple tabs/windows . Suppose I have ajax link which changes its model in non versioned page. I open the same page in new tab/window and click on the link. When i click the link in the first tab/window i get javascript error Wicket.Ajax: Wicket.Ajax.Call.failure: Error while parsing response: Could not find root ajax-response element This occurs because theres a hole page rendered in response (ajax-response element is missing) Should i create JIRA issue or is this a known bug? BR, Michal - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
StalePageException and AJAX possible bug
Hi, I have encountered a problem when using not versioned page with AJAX in multiple tabs/windows . Suppose I have ajax link which changes its model in non versioned page. I open the same page in new tab/window and click on the link. When i click the link in the first tab/window i get javascript error Wicket.Ajax: Wicket.Ajax.Call.failure: Error while parsing response: Could not find root ajax-response element This occurs because theres a hole page rendered in response (ajax-response element is missing) Should i create JIRA issue or is this a known bug? BR, Michal - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
multi-window support, pagestores and wicket 1.5
Hi folks, I know that there has been a lot of written about pagestores and multi-window support in wicket 1.5, but i have several other questions: 1. Is multi-window supported for non-versioned pages? If page is versioned everything works ok, but i always get StalePageExceptions when i use multiple windows/tabs with non-versioned pages. I think that StalePageException is useful in some cases when you wanna be sure that user has same page in all windows, but in older versions of wicket it was possible to have non versioned pages and multi-window support together (e.g. we have an application written in wicket 1.2.6 that uses non-versioned pages in multiple windows) 2. How page stores work in clustered environment? In older versions of wicket we used pagemaps stored in HttpSession. When one node in cluster refuses to handle request, it was successfully handled by another nod, because HttpSession was replicated to another node. We have used non-versioned pages (no back button support needed) and in one pagemap there was max 5 pages. Wicket provided this functionality out-of-box. 3. How to achieve this in wicket 1.5? I have found PersistentPageManager which uses IPageStore to store pages. Pages are stored on disk by default, but there is also thread safe SerializedPagesCache with SoftReferences. Theres no out-of-box solution to store pages in HttpSession. I have also found file page-management.txt in org.apache.wicket.page package. It contains proposal of other pagamanagers and multi-window support for non-versioned pages. The proposal contains classes PersistentPageManager with DiskPageStore and SecondLevelCacheSessionStore for versioned pages SessionManager for holding non versioned pages in HttpSession. 4. Can we expect that this proposal will be implemented in wicket 1.5 final version? Thanks for your replies. BR, Michal Kurtak - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
why are Component.hasErrorMessage and hasFeedbackMessage final?
Hi folks,
I try to implement persistent feedback messages (feedback messages
that persist until next validate call). I would like to achieve this
by having special attribute with persistent messages in a component
and overriding hasErrorMessage method like this:
public boolean hasErrorMessage()
{
return super.hasErrorMessage hasPersistentErrorMessage();
}
But there's a problem. Methods hasErrorMessage and hasFeedbackMessage
in Component are final.
I've found wicket bug related to persistent feedback messages:
https://issues.apache.org/jira/browse/WICKET-2705. Igor Vaynberg
wrote:
feedback messages are stored in component's metadata with the components
add new support for persistent feedback messages - these are not
cleaned up after render
form components report their errors as persistent
form components clean their reported errors once validated
so form component workflow looks like this:
before validate - clear all reported errors
validate - reports persistent messages
onvalid - clear all reported errors
onerror - do nothing, messages stay until next validation or onvalid
Until this desired behavior will be implemented (as Igor wrote in 1.6)
it would be useful to have hasErrorMessage() and hasFeedbackMessage()
non-final, so users could implement persistent feedback messages.
Is it possible? Thanks.
BR,
Michal
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: isTemporary behavior + ajax behavior
Hi, Jira issue created with quickstart: https://issues.apache.org/jira/browse/WICKET-3097 br, michal 2010/10/5 Igor Vaynberg igor.vaynb...@gmail.com: hrm. this was fixed in 1.4.x a good while back. maybe it never got ported to trunk. please create a jira issue and attach a quickstart. -igor On Mon, Oct 4, 2010 at 4:49 AM, Michal Kurtak michal.kur...@gmail.com wrote: Hi, I think its a bug but i am not sure. My scenario: 1. Component has 2 behaviors: first is temporary and second is ajax behavior. 2. Url for Ajax behavior contains behavior's index (e.g. ../page?1-1.IBehaviorListener.1-form-text) 2. Temporary behavior is removed in detachBehaviors method. 3. Ajax request is invoking ListenerInterfaceRequestHandler and it's looking for behavior on non-existing index This scenario causes error on wicket 1.5-M2.1 br, Michal - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
isTemporary behavior + ajax behavior
Hi, I think its a bug but i am not sure. My scenario: 1. Component has 2 behaviors: first is temporary and second is ajax behavior. 2. Url for Ajax behavior contains behavior's index (e.g. ../page?1-1.IBehaviorListener.1-form-text) 2. Temporary behavior is removed in detachBehaviors method. 3. Ajax request is invoking ListenerInterfaceRequestHandler and it's looking for behavior on non-existing index This scenario causes error on wicket 1.5-M2.1 br, Michal - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Wicket 1.5 PageMap, accessStack, pageMapEvictionStrategy
Hi, I'm playing with wicket 1.5-M2.1 and i couldn't find PageMap. Problem is not in PageMap itself, but I have used operations on PageMap which I couldn't find in wicket 1.5. For example we used accessStack to find page of certain class and response with that page: Session.get().getDefaultPageMap().getAccessStack(); We have also created special eviction strategy (OneInstancePerClassEvictionStrategy implements IPageMapEvictionStrategy) that stores only one page instance from certain class. Is it possible to get list of pages for a certain window (former pagemap) in wicket 1.5? Is it possible to define eviction strategy in wicket 1.5? Maybe i was looking at wrong places. Am i missing something? Thanks. BR, Michal Kurtak - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: could IAjaxCallDecorator implement IHeaderContributor
https://issues.apache.org/jira/browse/WICKET-3059
2010/9/17 Igor Vaynberg igor.vaynb...@gmail.com:
add an rfe to jira.
-igor
On Fri, Sep 17, 2010 at 7:43 AM, Michal Kurtak michal.kur...@gmail.com
wrote:
Thanks for your quick reply.
Thats the way i do it right now. But the problem is that all ajax
components have behavior bundled inside so i must override not only
getAjaxCallDecorator but renderHead in all components. Its not
possible to achieve single point of functionality in one class (one
AjaxCallDecorator). Its just a proposal to IAjaxCallDecorator extend
IHeaderContributor.
br,
Michal Kurtak
2010/9/17 Martin Grigorov mgrigo...@apache.org:
Extend org.apache.wicket.ajax.AbstractDefaultAjaxBehavior
then override renderHead(IHeaderResponse) and getAjaxCallDecorator()
On Fri, Sep 17, 2010 at 3:50 PM, Michal Kurtak
michal.kur...@gmail.comwrote:
Hi,
Is it possible to IAjaxCallDecorator implement IHeaderContributor?
For example ovverriden method form IAjaxCallDecorator looks like this:
public CharSequence preDecorateScript(CharSequence script)
{
MyLibrary.call(); + script;
}
Where MyLibrary.call(); is javascript function defined in MyLibrary
namespace in external js file (mylibrary.js). I need to contribute
this file to head. What is the best place for this contribution?
I suppose if IAjaxCallDecorator would implement IHeaderContributor, it
would be perfect place.
Best regards,
Michal Kurtak
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
could IAjaxCallDecorator implement IHeaderContributor
Hi,
Is it possible to IAjaxCallDecorator implement IHeaderContributor?
For example ovverriden method form IAjaxCallDecorator looks like this:
public CharSequence preDecorateScript(CharSequence script)
{
MyLibrary.call(); + script;
}
Where MyLibrary.call(); is javascript function defined in MyLibrary
namespace in external js file (mylibrary.js). I need to contribute
this file to head. What is the best place for this contribution?
I suppose if IAjaxCallDecorator would implement IHeaderContributor, it
would be perfect place.
Best regards,
Michal Kurtak
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: could IAjaxCallDecorator implement IHeaderContributor
Thanks for your quick reply.
Thats the way i do it right now. But the problem is that all ajax
components have behavior bundled inside so i must override not only
getAjaxCallDecorator but renderHead in all components. Its not
possible to achieve single point of functionality in one class (one
AjaxCallDecorator). Its just a proposal to IAjaxCallDecorator extend
IHeaderContributor.
br,
Michal Kurtak
2010/9/17 Martin Grigorov mgrigo...@apache.org:
Extend org.apache.wicket.ajax.AbstractDefaultAjaxBehavior
then override renderHead(IHeaderResponse) and getAjaxCallDecorator()
On Fri, Sep 17, 2010 at 3:50 PM, Michal Kurtak michal.kur...@gmail.comwrote:
Hi,
Is it possible to IAjaxCallDecorator implement IHeaderContributor?
For example ovverriden method form IAjaxCallDecorator looks like this:
public CharSequence preDecorateScript(CharSequence script)
{
MyLibrary.call(); + script;
}
Where MyLibrary.call(); is javascript function defined in MyLibrary
namespace in external js file (mylibrary.js). I need to contribute
this file to head. What is the best place for this contribution?
I suppose if IAjaxCallDecorator would implement IHeaderContributor, it
would be perfect place.
Best regards,
Michal Kurtak
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Glue for composing panels
Hi Frank,
We use the same approach as you. We have found one disadvantage, which
relates to references to components created by subclasses.
I'll demostrate it (problem and solution) in the following example:
class BasePage extends Page
{
/** Component created by subclass */
private Component component;
private boolean componentsAssembled = false;
/** Let the assemple method to set componentsAssembled flag */
private void assembleComponents()
{
component = createComponent();
...
componentsAssembled = true;
}
protected abstract Component createComponent();
@Override
void onBeforeRender() {
if ( !componentsAssembled ) {
assembleComponents();
}
super.onBeforeRender(); // Or whatever else is needed
}
/** Method uses assambelComponents() to ensure, that component is created */
public Component getComponent()
{
if(component == null)
{
assembleComponents();
}
return component;
}
/** public method delegete to referenced component. Uses safe
getComponent() method */
public void setComponentModel(IModel? model)
{
getComponent().setModel(model);
}
michal
2009/10/29 Frank Silbermann frank.silberm...@fedex.com:
I was discussing glue for composing reusable panels into web pages on
the blog of Erik van Oosten
(http://blog.jteam.nl/2009/09/16/wicket-dos-and-donts/).
I told him that my approach had been to create an abstract base page
that constructs the common elements while leaving place-holders for
page-specific panels by defining methods such as:
abstract Panel createUpperLeftPanel (String wicketID);
abstract Panel createLowerRightPanel(String wicketID);
and having the base page's constructor say things like:
Panel p1 = createUpperLeftPanel(a_wicket_id);
add(p1);
...
Add( createUpperRightPanel(another_wicket_id) );
The child page's contribution would be the implementation of the
abstract methods.
I explained that I preferred this to mark-up inheritance because I could
add to the base page in any number places (not just one place), the
compiler would tell the child-page writer exactly what panels were
needed, and most importantly, no additional mark-up whatsoever would
need to be associated with any of the child pages. (Panel classes used
by the child page would of course have their associated mark-up.)
Eric and others explained what a bad idea it is for constructors to call
overridable methods -- they execute before the child-page's properties
have been set. I usually got away with this, but I admit I was burnt a
few times. Recently, I wondered whether there might be a simple fix for
the constructor-calls-overridable-method problem, such as:
(a) Move the base page's component tree construction out of the
constructor, and put it into the method:
private void assembleComponents() {
...
}
(b) Add the property:
private boolean componentsAssembled = false;
(c) Override as follows to construct the component tree after the class
constructors finish:
�...@override
void onBeforeRender() {
if ( !componentsAssembled ) {
assembleComponents();
componentsAssembled = true;
}
super.onBeforeRender(); // Or whatever else is needed
}
Then component construction would wait until the properties in both the
parent and the subclass had been set. I'd no longer have the problem
associated with calling abstract methods from the constructor.
Do you see any disadvantages to this approach? Is there a more
appropriate hook upon which to hang my base page's component-tree
assembly?
If it _is_ a good approach, is there any reason the Wicket designers
chose not to create an overrideable method in the Component class that
is called just once after constructors terminate, and tell developers
that this is where the component tree should be created?
/Frank
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: Glue for composing panels
Yes Frank, model-setting method was just an example how to access a
component before onBeforeRender() executes.
I've only tried to point out that we set componentsAssembled = true in
assembleComponents() method. We call assembleComponents() from
get-method (for referenced component) to ensure that referenced
component has been created.
michal
2009/11/2 Frank Silbermann frank.silberm...@fedex.com:
If I understand you correctly, Michal, you don't want to set the component's
model once and for all as it is being created, and you're worried that the
model-setting method might be called before the first onBeforeRender().
That's just an example, I guess, so perhaps the general concern is that you
might need to access a component for whatever reason before the first call to
onBeforeRender().
Therefore, _any_ attempt to access a component after constructors have
terminated should trigger construction of the component tree if necessary.
Is that the idea?
It sure would be nice to have an honest to goodness post-constructors event
on which I could hang the component tree creation -- then we wouldn't have to
worry about this.
In my use of Wicket, I've always set a component's model at the time that
component was created -- I've never had to swap out a model in a separate
operation. If the data to be displayed changes dynamically, I've always
simply used a model which took that into account.
Is that just a different style of programming? Or are there circumstances
beyond my limited experience which would require one to access a component
before the first call to onBeforeRender()?
/Frank
-Original Message-
From: Michal Kurtak [mailto:michal.kur...@gmail.com]
Sent: Monday, November 02, 2009 3:39 AM
To: users@wicket.apache.org
Subject: Re: Glue for composing panels
Hi Frank,
We use the same approach as you. We have found one disadvantage, which
relates to references to components created by subclasses.
I'll demostrate it (problem and solution) in the following example:
class BasePage extends Page
{
/** Component created by subclass */
private Component component;
private boolean componentsAssembled = false;
/** Let the assemple method to set componentsAssembled flag */
private void assembleComponents()
{
component = createComponent();
...
componentsAssembled = true;
}
protected abstract Component createComponent();
@Override
void onBeforeRender() {
if ( !componentsAssembled ) {
assembleComponents();
}
super.onBeforeRender(); // Or whatever else is needed
}
/** Method uses assambelComponents() to ensure, that component is created */
public Component getComponent()
{
if(component == null)
{
assembleComponents();
}
return component;
}
/** public method delegete to referenced component. Uses safe
getComponent() method */
public void setComponentModel(IModel? model)
{
getComponent().setModel(model);
}
michal
2009/10/29 Frank Silbermann frank.silberm...@fedex.com:
I was discussing glue for composing reusable panels into web pages on
the blog of Erik van Oosten
(http://blog.jteam.nl/2009/09/16/wicket-dos-and-donts/).
I told him that my approach had been to create an abstract base page
that constructs the common elements while leaving place-holders for
page-specific panels by defining methods such as:
abstract Panel createUpperLeftPanel (String wicketID);
abstract Panel createLowerRightPanel(String wicketID);
and having the base page's constructor say things like:
Panel p1 = createUpperLeftPanel(a_wicket_id);
add(p1);
...
Add( createUpperRightPanel(another_wicket_id) );
The child page's contribution would be the implementation of the
abstract methods.
I explained that I preferred this to mark-up inheritance because I could
add to the base page in any number places (not just one place), the
compiler would tell the child-page writer exactly what panels were
needed, and most importantly, no additional mark-up whatsoever would
need to be associated with any of the child pages. (Panel classes used
by the child page would of course have their associated mark-up.)
Eric and others explained what a bad idea it is for constructors to call
overridable methods -- they execute before the child-page's properties
have been set. I usually got away with this, but I admit I was burnt a
few times. Recently, I wondered whether there might be a simple fix for
the constructor-calls-overridable-method problem, such as:
(a) Move the base page's component tree construction out of the
constructor, and put it into the method:
private void assembleComponents() {
...
}
(b) Add the property:
private boolean componentsAssembled = false;
(c
Re: How to redirect from a ModalWindow
Hi Matthias,
Try to navigate to another page from WindowClosedCallback
window.close(target);
window.setWindowClosedCallback(new WindowClosedCallback()
{
public void onClose(AjaxRequestTarget target)
{
setResponsePage(OtherPage.class);
}
}
But remember to remove WindowClosedCallback before you open your
window next time
Michal
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Creating components in onBeforeRender() method
Hello,
I am working on a library based on wicket framework and I couldnt find
some suitable solution when creating component hierarchies.
For example I have a base class AbstractLink for links (DownloadLink,
LabelLink, IconLink, SubmitLink, ...):
public abstract class AbstractLink extends Panel
{
private ILinkComponent linkComponent;
private boolean attached= false;
protected void onBeforeRender()
{
if(!attached)
{
removeAll();
linkComponent = createLinkComponent();
linkComponent.setWidht(150, Unit.PX);
add(linkComponent);
attached = true;
}
}
protected abstract ILinkComponent createLinkComponent(String id);
// PROBLEM METHOD - NOT SURE that linkComponent exists
public void setTooltip(IModel tooltip)
{
linkComponent.setTooltip(tootlip);
}
}
public abstract class LabelLink extends AbstractLink
{
private IModel labelModel;
public LabelLink(IModel labelModel)
{
this.labelModel= labelModel;
}
protected ILinkComponent createLinkComponent(String id)
{
Link linkComponent = new Link(id);
linkComponent.add(new Label(labelModel));
return linkComponent;
}
}
Subclassing panels are responsible for creating linkComponent.
Overriden method createLinkComponent() usually uses attribute from
subclass (labelModel in LabelLink). For this reason I couldnt call
createLinkComponent in AbstractLink's constructor (LabelLink attribute
labelModel is null). So I use the trick with onBeforeRender method.
The problem is that I couldnt write methods (setTooltip) delegating to
linkComponent in AbstractLink, because i cannot be sure that
linkComponent exists.
Is there someone who solved this sort of problem? Or how do you handle
similar situations?
Thanks,
michal
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
