Messages posted by chrishantha
[Logo]
ICEsoft.org Forums: ICEfaces, ICEmobile, ICEpdf
[Search] Search   [Recent Topics] Recent Topics   [Groups] Home Page | www.icesoft.org  [Login] Login 
Messages posted by: chrishantha  XML
Profile for chrishantha -> Messages posted by chrishantha [148] Go to Page: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Next 
Author Message
I wonder why ICEfaces tutorial page requires the user to login to view pages.

After logged in, I noticed that all tutorials are in the Wiki pages.

However, ICEfaces Wiki doesn't require a login to view pages.

http://wiki.icefaces.org/display/ICE

I believe that tutorials for ICEfaces should be given free access to any user. There is no need to ask user to login. You have even given a link in home page to the Tutorials.

New users should have fast access to ICEfaces resources. This login requirement makes new users to have doubts using ICEfaces.

Even ICEfaces releases should be able to download without logging in as it is open source.

ICEfaces is a great framework, but now it has many great competitors like PrimeFaces.

I believe only ICEfaces EE users need to login to access more resources.

I think ICEfaces needs to rethink how they deliver content to users.
The panelTooltip component with a display listener is not working correctly when using following in web.xml.

Code:
<context-param>
   <param-name>com.icesoft.faces.blockUIOnSubmit</param-name>
   <param-value>true</param-value>
 </context-param>


I'm using ICEfaces EE 1.8.2.GA_P02 with revision 23249.

The issue can be reproduced from Component Showcase. Just add the above configuration in web.xml

View the Tooltip Panel example, which uses one tooltip for all the provinces.

Tooltip panel disappears just after displaying. Then it won't display again.

Please check this issue.

Thanks.


Hi mircea,

Thanks for replying and fixing the issue.

I checked and now it works properly.

By the way, I got some new issues with ICEfaces EE 1.8.2.GA_P02. I will put those in the forum. I hope will be able to look into it.

Thanks.
There is an issue with ICEfaces EE 1.8.2.GA_P02 when the title is changed after navigating to a new page.

This issue can be reproduced in the Component Showcase also.

When "Component Showcase" is loaded, the title is "ICEfaces Component Suite"

<title id="dynamicTitle">ICEfaces Component Suite</title> 


Now click on another component demonstration link. For example, open "Connection Status"

Now the title won't change. Firebug shows following error.

failed to insert element: <title id="dynamicTitle">...</title> couldn't find container for property: bridge


Then I check why that issue is coming. The error is logged from the code in "application.js".

Following are the revision details, which included the code

Revision: 21421
Author: mark.collette
Date: 11:05:14 PM, Friday, May 14, 2010
Message:
ICE-5704 : Javascript tree update optimisations 


The error is coming when trying to find bridge from the title element.

Following is code from line 207 to 213
Code:
 var update = new Ice.ElementModel.Update(updateElement);
 var extElem = address.asExtendedElement();
 if (!got_bridge_optimizedJSListenerCleanup) {
 	bridge_optimizedJSListenerCleanup =
 	extElem.findBridge().optimizedJSListenerCleanup;
 	got_bridge_optimizedJSListenerCleanup = true;
 }



When the title is changed, the first update to the page is the title tag.

<updates><update address="dynamicTitle" tag="title"><attribute name="id"><![CDATA[dynamicTitle]]></attribute><content><![CDATA[Connection Status]]></content></update><update address="navigationMenuForm:navPnlSrs:1:tree:n-0-3:navNodeLink" tag="a"><attribute........ 


As I can see, the bridge cannot be found from the title tag as it is inside the HTML Head.

Please check this issue.

Thanks.


Hi Mark,

I also have this issue of disappearing inputFile component during upload. I'm using ICEfaces EE 1.8.2.GA_P01.

I was trying to find what's wrong with the component as I noted that the HTTP response for the file upload request is empty. Therefore the iframe content disappears from the page.

I debugged the ICEfaces code and found out that the file upload logic is very complicated. :)

Following is the scenario I understood. Please correct me if something is wrong.

  • The response for file upload is the value returned from getResultingIframeContent(BridgeFacesContext, UploadStateHolder) method defined in com.icesoft.faces.webapp.http.core.UploadServer class.

  • The method getResultingIframeContent goes to a five seconds (5000ms) loop. The loop will exit when com.icesoft.faces.component.inputfile.UploadStateHolder returns the iframe contents before five seconds, otherwise the method will return empty content for the iframe.

  • The iframe contents to the UploadStateHolder is set from com.icesoft.faces.component.inputfile.InputFile.storeContentAndConfig(BridgeFacesContext, String, String) method. The storeContentAndConfig method gets the UploadStateHolder object from request parameter map.

  • The UploadStateHolder object is placed in the request parameter map inside the com.icesoft.faces.component.inputfile.FileUploadPhaseListener class, which queues the action events for the inputFile component.

    In summary, if the file upload process takes more than five seconds, the component disappears from the page. Please let me know whether this is correct.

    I think this is the main reason you have asked to use a separate thread to process the uploaded file.

    mark.collette wrote:
    If you process the uploaded file in a long running thread. Instead, spawn off a worker thread, and let your actionListener return. When your thread is done processing the uploaded file, do a server push. 


    Is this the only solution for this issue? Why there is this kind of logic limited to 5 seconds?

    Please let me know.

    Thanks.
  • I found a workaround for the issue.

    I modified the "Ice.Menu.contextMenuPopup" function, in "\bridge\component\menu.js"

    I used the modified function in a local JS file as follows.

    Code:
         Ice.Menu.getAbsolutePositionedParent = function(element) {
             while ((element = element.parentNode) && element != document.body)
                 if (Element.getStyle(element, 'position') == 'absolute')
                     return $(element);
             return null;
         }
         Ice.Menu.contextMenuPopup = function(event, popupMenu, targComp) {
             var dynamic = $(popupMenu + "_dynamic");
     		var targetComponent = $(targComp);
             if(!event) {
             	event = window.event;
             }
             if(event) {
             	event.returnValue = false;
             	event.cancelBubble  = true;
     
                 if(event.stopPropagation) {
                 	event.stopPropagation();
                 }
                 
                 var posx = 0; // Mouse position relative to
                 var posy = 0; //  the document
                 if (event.pageX || event.pageY) 	{
                     posx = event.pageX;
                     posy = event.pageY;
                 }
                 else if (event.clientX || event.clientY) 	{
                     posx = event.clientX + document.body.scrollLeft
                         + document.documentElement.scrollLeft;
                     posy = event.clientY + document.body.scrollTop
                         + document.documentElement.scrollTop;
                 }
     			var abolutePositionedParent = Ice.Menu.getAbsolutePositionedParent(targetComponent);
                 if (abolutePositionedParent) {
                     posx -= abolutePositionedParent.offsetLeft;
                     posy -= abolutePositionedParent.offsetTop;
                 }
                 if (dynamic) {
                         dynamic.value = posx +", "+ posy + ", "+ popupMenu + ", "+ targComp;
                     try {
                         var form = Ice.util.findForm(dynamic);
                         iceSubmitPartial(form,dynamic,event);
                     } catch (e) {logger.info("Form not found" + e);}
                     return;
                 }
                 
                Ice.Menu.showIt(posx, posy, popupMenu, targComp);
             }
         }
     

    Hi,

    The menu popup is not positioned correctly when it is used inside a panel popup.

    I'm using ICEfaces 1.8.2.GA_P01.

    The calculated position is not correct and I think the reason for that is the panel popup is using absolute position.

    I have attached a video of showing what happens.

    I used component showcase to reproduce the issue.

    I tried to find a workaround for this issue, but I still couldn't find.

    Please check this issue.

    Thanks.
    Hi,

    Opening a page in a new browser tab is okay as long as the managed bean is in "Request" scope. There will be two request scoped managed beans for different views on different tabs.

    However if the page uses a session scoped managed bean, then there will be unexpected errors if the same page is opened in two browser tabs. Two views will be using a single session managed bean.

    I'm also trying to restrict opening the same view in another tab to avoid any critical errors.

    If there is any simple way of doing that, let us know.

    Thanks!
    Hi,

    There is an issue with ICEfaces Menu Bar component in ICEfaces 1.8.2.GA_P01.

    It displays in the wrong position in Internet Explorer 6 and 7 when the page is scrolled.

    This issue is caused by the fix for ICE-5251 Revision 20500.

    Diff in Revision 20500

    Issue can be reproduced using ICEfaces Component Showcase. Please see the image attached.

    Please check this issue.

    Thanks.
    Hi,

    The auto-complete list for ice:selectInputText is not positioned correctly in Internet Explorer 8 when it is inside a ice:panelPopup.

    I'm using ICEfaces EE 1.8.2.GA_P01.

    This issue was fixed in ICE-4974 (Description: ice:selectInputText popup list displays out of place when inside ice:panelPopup on IE8).

    Following is the change done in ICE-4974.

    Code:
                                            update.clonePosition(element.parentNode, {setTop:false, setWidth:false, setHeight:false,
                                                offsetLeft: element.offsetLeft - element.parentNode.offsetLeft});
     +                                      if (Prototype.Browser.IE && navigator.userAgent.indexOf("MSIE 8") > -1) {
     +                                          var savedPos = element.style.position;
     +                                          element.style.position = "relative";
     +                                          update.style.left = element.offsetLeft + "px";
     +                                          update.style.top = (element.offsetTop + element.offsetHeight) + "px";
     +                                          element.style.position = savedPos;
     +                                      }
                                        }
     


    The change done in ICE-5465 caused the regression of ICE-4974.

    Following is the change in ICE-5465 (Description: scrollable div causesselectInputText dropdown to render out of place in IE7).

    Code:
                                            update.clonePosition(element.parentNode, {setTop:false, setWidth:false, setHeight:false,
                                                offsetLeft: element.offsetLeft - element.parentNode.offsetLeft});
     -                                      if (Prototype.Browser.IE && navigator.userAgent.indexOf("MSIE 8") > -1) {
     +                                      if (ieEngine == 7 || ieEngine == 8) {
                                                var savedPos = element.style.position;
                                                element.style.position = "relative";
                                                update.style.left = element.offsetLeft + "px";
     -                                          update.style.top = (element.offsetTop + element.offsetHeight) + "px";
     +                                          if (ieEngine == 7) {
     +                                              update.style.top = (element.offsetTop + element.offsetHeight) + "px";
     +                                          } else if (ieEngine == 8) {
     +                                              update.style.top = (element.offsetTop - element.cumulativeScrollOffset().top + element.offsetHeight) + "px";
     +                                          }
                                                element.style.position = savedPos;
                                            }
     


    As you can see, the style for IE8 is changed by the fix for ICE-5465.

    Changing the "top" style for IE8 to following fixes the issue.

    Code:
     update.style.top = (element.offsetTop + element.offsetHeight) + "px";
     


    Please check this issue.

    Thanks.
    I will explain what's happening as I understood.

    Initially the modal layer is created when the "Test Popup #1" is opened using "Open Popup #1" button in page.

    Clicking "Open Popup #2" in "Test Popup #1" opens the "Test Popup #2" and at the same time "Test Popup #1" is closed.

    Code:
    public void openPopup2(ActionEvent event){
     	this.setPopup1Rendered(false);
     	this.setPopup2Rendered(true);
     }


    Then "Ice.modal.stop()" is called for "Test Popup #1".

    Note: "Ice.modal.stop()" is called for all "not rendering" popups after each response from the server.

    Following is the "Ice.modal.stop()" function.

    Code:
    stop:function(target) {
     if (Ice.modal.getRunning() == target) {
     	...
     }
     }


    Since the running popup is "Test Popup #2", "Ice.modal.getRunning()" returns the ID of the "Test Popup #2".

    Therefore the stop function for "Test Popup #1" will be skipped.

    When the "Test Popup #2" is closed by clicking "Close Popup #2", the "Ice.modal.stop()" is called for both popups.

    "Test Popup #2" closes successfully as it was the last running popup.

    Now "Ice.modal.getRunning()" function in the stop method for "Test Popup #1" will return the ID of the "Test Popup #1" from the stack.

    The stop function calls "Ice.modal.stopRunning()" function and that function will try to restore tab indexes.

    Even though, the ID of the "Test Popup #1" was in the stack, the element of the popup is not in the page as it was set to rendered false.

    Therefore the target element is null in "enableDisableTabindex" function.

    This JavaScript error should be fixed as it causes many issues.

    For example in my application, a modal popup is displayed after closing another modal popup.

    Then if I click on a link with a "Panel Confirmation", the panel confirmation is displayed. Clicking "Yes" on "Panel Confirmation" will not queue an action event as there is a JavaScript error.

    Following is the "Ice.PanelConfirmation.accept()" function.
    Code:
     accept: function() {
     	this.close();
     	setFocus(this.srcComp.id);
     	this.srcHandler.call(this.srcComp,this.event);
     }


    "this.close()" calls the "Ice.modal.stop()" function and it will cause the error and the "srcHandler" is not executed.

    I hope this explains the issue in detail.

    Please check this and let us know.

    Thanks.
    Hi,

    There seems to be an issue with the changes done in ICE-5439.

    There is a javascript error and it causes many issues.

    I'm using ICEfaces 1.8.2.GA_P01 (Revision: 21157)

    Issue can be reproduced using the example attached in ICE-5439 Case8996Example2.war

    After deploying, replace icefaces jars with the jars in "ICEfaces 1.8.2.GA_P01" release.

    I'm using Firefox and Firebug to check the errors.

    Do following steps with the example.

    1. Click "Open Popup #1"
    2. Click "Open Popup #2" in "Test Popup #1"
    3. Now click "Close Popup #2" in "Test Popup #2"

    There is a Javascript error.

    Error is coming from enableDisableTabindex function in style.js.

    Following is the code.

    Code:
    var targetElement = null;
     if (target) {
     	  targetElement = $(target);
     } else {
     	  targetElement = document;
     }        
     var focusables = {};
     focusables.a = targetElement.getElementsByTagName('a');
     focusables.area = targetElement.getElementsByTagName('area');
     focusables.button = targetElement.getElementsByTagName('button');


    Here the "targetElement" is null.

    "target" value is the ID of the first popup. Since the first popup is not rendered, the element is not there.

    Please check this issue.

    Thanks.
    Hi Ken,

    Thank you very much for the information.

    I'm using Spring Framework 3.0.1 and Spring Security 3.0.2.

    So far, I don't have any issues using latest Spring with ICEfaces.

    I'm using the previously mentioned patch to avoid run-time error only.

    I also want to thank you for releasing ICEfaces EE 1.8.2.GA Patch 1 on time and I'm happy with the release. :)

    Best Regards,

    Isuru.
    Hi,

    I downloaded ICEfaces 1.8.2 GA_P01 release and it's not working with Spring Security 3.0.

    It seems to be an issue with ICE-5245

    Even though ICEfaces detects Spring Security 3.0, it returns the Authentication Wrapper for Spring Security 2.0. This causes NoClassDefFoundError to be thrown at runtime.

    I am not using "isUserInRole" in my application for now, but I did some changes to ICEfaces code.

    I created a new Authentication Wrapper for Spring Security 3.0 and the BridgeExternalContext will return the correct wrapper. After the patch, my application is working well.

    The patch file is attached.

    Please check on this issue.

    Thank you.
    BeanImpPropertiesTest class uses a class from sun.reflect.misc package.

    Using classes from sun.* packages are not recommended.

    http://java.sun.com/products/jdk/faq/faq-sun-packages.html

    I have a patch for BeanImpPropertiesTest.
     
    Profile for chrishantha -> Messages posted by chrishantha [148] Go to Page: 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 Next 
    Go to:   
    Powered by JForum 2.1.7ice © JForum Team