I came across a user case where I had to programatically scroll the contents of a div to the right. This was
to be performed on a click of an ajax link. This is how I achieved the same:
onSubmit(AjaxTarget....)
{
.... body of onsubmit , additional operations.
target.appendJavascript("var obj = document.getElementById('divid');obj.scrollLeft = 500;");
}
some additional methods which could be used on the window itself rather than a div are
scrollBy
scrollTo
moveBy
Thursday 24 June, 2010
Wicket - Nested Modal Windows - Parent window not getting refreshed
Recently while trying to use nested modal windows I came across this wierd issue where the value being returned from the child modal window was not being refreshed and shown on the parent modal window.
My heirarchy was like this:
-><html>
--><form>
----><div wicket:id="parentModalWindow">
------><wicket:panel>
--------><form> -- Parent Modal Window Form
----------><div wicket:id="childModalWindow">
------------><wicket:panel>
--------------><form> --Child Modal window form
--------------></form>
------------></wicket:panel>
----------></div>
--------><form>
------><wicket:panel>
----></div>
--></form
-><html>
When using such a design of components the child modal window was always submitting a null value for the form components. And hence the form processing was not happening correctly.
I thereafter was suggested to use a web page instead of a panel for the child modal window as panel -> form - > panel - > form hierarchy didnt work well. Form within form was supported.
Hence I update my child modal window content to be created from a web page. And used a page creator to set content.
Now I went a step ahead as I could see the value being returned to the parent i submitted the child form and but the parent modal window components were not refreshed .
I then realised that I had to overide
childModalWindow.setCloseButtonCallback(new ModalWindow.CloseButtonCallback()
{
public boolean onCloseButtonClicked(AjaxRequestTarget target) {
target.addComponent(parentWindowComponent);
return true;
}
});
childModalWindow.setWindowClosedCallback(new ModalWindow.WindowClosedCallback()
{
public void onClose(AjaxRequestTarget target) {
target.addComponent(parentWindowComponent);
}
});
This fixed the final problem as well the container in the parent window also updated to show the new value submitted by the child modal window.
My heirarchy was like this:
-><html>
--><form>
----><div wicket:id="parentModalWindow">
------><wicket:panel>
--------><form> -- Parent Modal Window Form
----------><div wicket:id="childModalWindow">
------------><wicket:panel>
--------------><form> --Child Modal window form
--------------></form>
------------></wicket:panel>
----------></div>
--------><form>
------><wicket:panel>
----></div>
--></form
-><html>
When using such a design of components the child modal window was always submitting a null value for the form components. And hence the form processing was not happening correctly.
I thereafter was suggested to use a web page instead of a panel for the child modal window as panel -> form - > panel - > form hierarchy didnt work well. Form within form was supported.
Hence I update my child modal window content to be created from a web page. And used a page creator to set content.
Now I went a step ahead as I could see the value being returned to the parent i submitted the child form and but the parent modal window components were not refreshed .
I then realised that I had to overide
childModalWindow.setCloseButtonCallback(new ModalWindow.CloseButtonCallback()
{
public boolean onCloseButtonClicked(AjaxRequestTarget target) {
target.addComponent(parentWindowComponent);
return true;
}
});
childModalWindow.setWindowClosedCallback(new ModalWindow.WindowClosedCallback()
{
public void onClose(AjaxRequestTarget target) {
target.addComponent(parentWindowComponent);
}
});
This fixed the final problem as well the container in the parent window also updated to show the new value submitted by the child modal window.
Wicket - Auto Complete inside a ModalWindow
While trying to include an autocomplete field inside a modalwindow I came across this issue where the ajax response being sent was rendered behind the modal window on IE. Windows XP, Wicket 1.3.7
In other words the lookup values were not visible as they were placed behind the modal window container. This however worked fine on firefox.
The same auto complete text field worked fine on a normal web page. Both on IE and Firefox.
Searching through forums I realised that the z-index of the autocomplete text field was much lower than the container hence it was always behind other containers and components.
The Wicket AutoComplete .js can be browsed through to see what exactly was happening.
function getOffsetParentZIndex(obj) {
obj=typeof obj=="string"?Wicket.$(obj):obj;
obj=obj.offsetParent;
var index="auto";
do {
var pos=getStyle(obj,"position");
if(pos=="relative"||pos=="absolute"||pos=="fixed") {
index=getStyle(obj,"z-index");
}
obj=obj.offsetParent;
} while (obj && index == "auto");
return index;
}
This method above always returned zero for the modal window container and hence the auto complete z index was set to 0 + 1 = 1 which was much lower than the other containers.
Also something noticeable was on IE all container pos came out as static is not being processed in the method and hence the method goes right upto the last parent to get the z-index.
As a workaround we came up with a solution where we added style="position:relative;z-index=99999;" to the element containing the text field , this could be the div, form , td etc in your case.
What this will do is to allow the above method process the container and send back 99999 as the z-index and your auto complete's z-index would then be 99999 +1 and hence it will render above the container.
Problem Solved.
Another work around would be change the modal window content to be a web page instead of the Panel.
In other words the lookup values were not visible as they were placed behind the modal window container. This however worked fine on firefox.
The same auto complete text field worked fine on a normal web page. Both on IE and Firefox.
Searching through forums I realised that the z-index of the autocomplete text field was much lower than the container hence it was always behind other containers and components.
The Wicket AutoComplete .js can be browsed through to see what exactly was happening.
function getOffsetParentZIndex(obj) {
obj=typeof obj=="string"?Wicket.$(obj):obj;
obj=obj.offsetParent;
var index="auto";
do {
var pos=getStyle(obj,"position");
if(pos=="relative"||pos=="absolute"||pos=="fixed") {
index=getStyle(obj,"z-index");
}
obj=obj.offsetParent;
} while (obj && index == "auto");
return index;
}
This method above always returned zero for the modal window container and hence the auto complete z index was set to 0 + 1 = 1 which was much lower than the other containers.
Also something noticeable was on IE all container pos came out as static is not being processed in the method and hence the method goes right upto the last parent to get the z-index.
As a workaround we came up with a solution where we added style="position:relative;z-index=99999;" to the element containing the text field , this could be the div, form , td etc in your case.
What this will do is to allow the above method process the container and send back 99999 as the z-index and your auto complete's z-index would then be 99999 +1 and hence it will render above the container.
Problem Solved.
Another work around would be change the modal window content to be a web page instead of the Panel.
Monday 21 June, 2010
Apache Commons Collections - Chaining Comparators
I came across this useful Util class provided by Apache Commons Collections.
ComparatorUtils
one of the useful methods here is chainedComparator which allows us to chain comparators to achieve sorting on multiple attributes of an object.
if the results from the first comparator result in 0 then the next comparator is invoked.
I remember writing a Util for myself for the same. But This class is much more robust and accessible.
ComparatorUtils
one of the useful methods here is chainedComparator which allows us to chain comparators to achieve sorting on multiple attributes of an object.
if the results from the first comparator result in 0 then the next comparator is invoked.
I remember writing a Util for myself for the same. But This class is much more robust and accessible.
Tuesday 15 June, 2010
Migrating From Junit 4 to TestNG
Testing next generation sounds good , for which recently I had migrated some of my unit tests written in JUnit 4 to Test NG.
Some useful features I have used and liked:
Some useful features I have used and liked:
- Annotations
- Dependent Method
- Groups
- Printable and User Friendly Reports
- CSS Configuration for reports
- Tests runnable for various granularities like suites , groups, class , package etc
- Eclipse plugin available
- Data Provider
- Spring compatibily
- XML configuration
- Many more which can be read from the Test NG documentation
Subscribe to:
Posts (Atom)