Very simple scenario , I wanted to display a PDF or an Excel on click of a link/ on submit of a button.
Since wicket offers flavors of ajaxbutton and ajax link one can easily make a mistake of the using them to render the pdf or excel.
I did the same. everything seemed to work unit the point where the response needed to be rendered and i would see a pdf or excel.
The problem was that using an ajax button or link we can only render a ajax response, but in this case i wanted to render a pdf or excel response (bytes).
It only clicked to me after a while of debugging that the browser had no way to identify how to render the ajax response which contained pdf bytes.
Lesson learnt , always use a Normal Button or a link to render the pdf as the web response.
an example would be like this:
Link excelLink = new Link("linForExcel"){
@Override
public void onClick() {
final OutputStream excelOutputStream = methodToReturnTheExcelOutputStream();
final ByteArrayResource byteArrayResource = new ByteArrayResource("application/vnd.ms-excel", ((ByteArrayOutputStream) excelOutputStream).toByteArray());
IResourceStream resourceStream = byteArrayResource.getResourceStream();
getRequestCycle().setRequestTarget(new ResourceStreamRequestTarget(resourceStream) {
public String getFileName() {
return "NameOfExcel.csv";
}
});
}
I guess this is a page to share all issues I have troubleshooted and found interesting enough to share. Also a place to give back something , in return of all the help I have received or taken from forums.
Showing posts with label wicket. Show all posts
Showing posts with label wicket. Show all posts
Friday, 9 July 2010
Wicket - Displaying a PDF onclick of a link or onSubmit of a Button
Thursday, 24 June 2010
Wicket - Programattically Scroll a Div Horizontally
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
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
Labels:
ajax,
container,
div,
horizontal result set,
programatically,
scroll,
wicket
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.
Labels:
1.3.7,
auto,
complete,
firefox,
ie,
modal window,
not visible,
wicket,
z-index
Subscribe to:
Posts (Atom)