voyent
Messages posted by: bfuller18  XML
Profile for bfuller18 -> Messages posted by bfuller18 [40] Go to Page: 1, 2, 3 Next 
Author Message

arran.mccullough wrote:
Does the browsers dev console give any more information on these errors?

What browser are you using? Does it happen for other browsers as well?

Thanks,
Arran 

Here is the full text of the message: "Error in evaluated javascript:Invalid argument."

There is nothing in the javascript console. I think this is because MyFaces is catching the error and displaying the dialog in lieu of the console error.
https://issues.apache.org/jira/browse/MYFACES-3902
https://issues.apache.org/jira/browse/MYFACES-3906

Testing with PROJECT_STAGE = Production,UnitTest, or SystemTest results in no javascript alert or logged console error.

After reading MYFACES-3906, I put the following javascript into the my h:head:
Code:
		
 	<script type="text/javascript" language="JavaScript">
 		window.myfaces = window.myfaces || {};
 		myfaces.config = myfaces.config || {};
 		myfaces.config.defaultErrorOutput = console.error;
 	</script>
 


This allowed me to catch the error in the debugger. The error occurs in icepush.uncompressed.js, function XMLDynamicConfiguration(lookupElement) line 1524:

"unknown attribute: serverErrorRetryTimeouts"


Affected Browser: IE 11
Unaffected Browsers: Chrome 48 and Firefox 44.
We recently switched JSF Implementation from Mojarra 2.1.28 to MyFaces 2.1.17.

We were still running IceFaces EE 3.3.0_P02 because of this bug: http://www.icesoft.org/JForum/posts/list/22948.page

Since we switched to MyFaces, we again tried IceFaces EE 3.3.0_P03 to see if the behavior was any different. The good news is it looks like we no longer have the issue noted above. Unfortunately, now we have a different issue. When javax.faces.PROJECT_STAGE is set to "Development" , we get annoying JavaScript alerts saying "Error in evaluated javascript" . This does not happen with IceFaces EE 3.3.0_P02
Turns out it was just easier to re-write the functionality using ace:dataTable and remove the dependency on ice-cc:editableTable.

It would really be nice if there was better documentation for components like ice-cc:editableTable.
We have an ice-cc:editableTable implemented as per examples.

We are using IceFaces 3.3.0_p02 and it's been working fine under Mojarra 2.1.28. However we are trying to move toward using MyFaces. With MyFaces, the rows never become editable. The events get processed and called in our backing beans, and we see the Row Update/Row Cancel edit buttons, but the input components stay read only.

Is there any extra configuration needed to use this component with MyFaces?
Looks like its not so simple to extend it after all. The report is corrupted. Needs more investigation, but this should really work out of the box without all these hacks..
I just looked at the IceFaces source and think I may see the reason why.

org.icefaces.ace.component.dataexporter.Exporter.java line 84 in the "setUp" function executes:
Code:
pageOnly = component.isPageOnly() || table.isLazy();


So it seems the base exporter class is purposely disabling multi-page if the table is lazy loaded. Why is it doing this? Is there a technical reason or issue, or are you just trying to stop people from exhausting resources on large data sets?

It certainly would have been nice to have seen this information somewhere in the documentation (even something as small as a debug log message would have been useful for this case).

I suppose I'll have to extend Exporter, and then copy the 3 exporter implementations (pdf, csv, excel), but change them to extend my my new class which doesn't override the requested settings.



We are having issues using icefaces 3.3.0_P02 EE and lazy data sources.

When using and ace:dataTable and a simple ListSorter data source, we find that ace:dataExporter single page and multi-page exports work fine.

However when we use a lazy data source styled like the showcase example, we only can get get a single page exported.

When attempting to export the full table, we can see a call to get the full table size returns the correct count, but then the 'load' function is only called only once and pageSize set to the pagination size, and not the full table size.

Are we missing something here?
It appears the issue has been marked as Closed/Fixed in Jira. When do you expect to release 3.3.0_P04? Or will there be a interim release to fix the regression?
Thanks Judy. We have download access only, not a full support contract. Support suggested we use the forums instead.

I looked at the Jira entry you mentioned and it does sound similar. However we don't use any '@WindowsDisposed' annotations.

I also tried setting org.icefaces.lazyWindowScope set to false, but that didn't help either.

As a side note, I think you may have update the 'ICEsoft Forum Reference' reference link to the wrong forum post?
We have several xhtml pages that reference ViewScoped beans. Navigate away from the one of these pages using an action, then use the browsers back button to return to back that page. When we try to interact with components on the page again, we get:

Code:
WARNING: /common/taskPMGSelectionPopup.xhtml @12,42 rendered="#{taskPMGChooserBean.popupVisible}": Property 'popupVisible' not found on type org.icefaces.impl.application.WindowScopeManager$NOOPBean
 javax.el.PropertyNotFoundException: /common/taskPMGSelectionPopup.xhtml @12,42 rendered="#{taskPMGChooserBean.popupVisible}": Property 'popupVisible' not found on type org.icefaces.impl.application.WindowScopeManager$NOOPBean


These pages worked fine from icefaces 2.x up to the last 3.3.0_p02 release. Converting taskPMGChooserBean in the above example to WindowScoped seems to solve the problem, but we are hesitant to update all ViewScoped beans in our system to WindowScoped.

Any ideas?
I was told our support agreement did not qualify for a patch. We were told that 3.3.0_p03 would be released in Q1 2015. Any updates?
Have you tried assigning an ID to the ice:headerRow that you have bound?

ombinte wrote:
How can I use the ui:repeat varStatus attribute for implement a forEach ? 


In your previous reply you have a typo 'varStatut' should be 'varStatus'. Your fragment will never be rendered because the variable named "status" does not exist.
Not mentioning compat components deprecation is a fairly large omission in the release notes.

Thanks for the migration guide, you may want to update the release notes ( http://www.icesoft.org/wiki/display/ICE/ICEfaces+4.0.0+Release+Notes ) to point to them instead of just the red block placeholder.

We have tried some ace components and they dont seem to work as reliably or even the same way as many of the ice components. We'll likely stick with 3.3 until support ends.
I dont see any mention in the official release notes. But in your Roadmap Update http://www.icesoft.org/blog/icefaces-4-0-roadmap-update-2/, you mention:

"The legacy ICE (Compat) components will not be brought forward into the 4.0 release. Most of these components rely on an earlier ICEfaces Direct-to-DOM rendering technique that isn’t compatible with many newer JSF features, such as partial-page rendering (f:ajax). Rather than invest the engineering resources to bring these up to spec for JSF 2.2, we’ve decided to focus our energies on further evolving the newer ACE and MOBI components."

Is there a full list of exactly what components are compat components?

Also, when can we expect icefaces 3 to 4 migration guide in the release notes to be updated?

 
Profile for bfuller18 -> Messages posted by bfuller18 [40] Go to Page: 1, 2, 3 Next 
Go to:   
Powered by JForum 2.1.7ice © JForum Team