[JBoss JIRA] (RF-12427) AJAX loading of resources in dynamically / programatically generated subtree
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12427?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč resolved RF-12427.
-----------------------------
Assignee: Lukáš Fryč
Fix Version/s: (was: 5-Tracking)
Resolution: Duplicate Issue
This is duplicate of RF-12270
> AJAX loading of resources in dynamically / programatically generated subtree
> ----------------------------------------------------------------------------
>
> Key: RF-12427
> URL: https://issues.jboss.org/browse/RF-12427
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.1.0.CR2
> Reporter: Lukáš Fryč
> Assignee: Lukáš Fryč
>
> There are several scenarios where components are dynamically added to the tree so resources for these components doesn't have to be loaded by AJAX:
> * components added programatically
> * components included by {{ui:include}} with dynamic {{src}} attribute
> * components under dynamic rows/panels/etc., e.g. {{rich:tab}} generated by {{c:forEach}} (RF-11694)
> Create mock components with mock resources and test that when component rendered "dynamically", the resources (JS and CSS) are provided to the page properly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (RF-12270) Allow RichFaces to bring new CSS/JS resources into the page after AJAX request
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12270?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-12270:
---------------------------------
There is duplicate issue RF-12427
> Allow RichFaces to bring new CSS/JS resources into the page after AJAX request
> ------------------------------------------------------------------------------
>
> Key: RF-12270
> URL: https://issues.jboss.org/browse/RF-12270
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: core, resource handling
> Affects Versions: 4.2.2.Final
> Reporter: Tomasz Kurpios
> Fix For: 5.0.0.Alpha2
>
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> Quoting the extract from official documentation (3.5 Restrictions):
> ??JSF 2 does not allow resources such as JavaScript or Cascading Style Sheets (CSS) to be added if the element requiring the resource is not initially present in the JSF tree. As such, components added to the tree via Ajax must have any required resources already loaded. In RichFaces, any components added to the JSF tree should have components with corresponding resources included on the main page initially. To facilitate this, components can use the rendered="false" setting to not be rendered on the page.??
>
> Setting rendered="false" is OK when components are in the tree. However, if there are lots of components on a single view, for performance reasons some parts might be excluded by means of <c:if> or <c:choose> tags.
> That's at least what could be done in 3.3.3. It worked fine back then. However, the JSF2 AJAX mechanism does not support this feature. This makes usage of aforementioned tags impossible in some cases.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (RF-12427) AJAX loading of resources in dynamically / programatically generated subtree
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-12427?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-12427:
------------------------------------
[~lfryc] is this not a duplicate of RF-12270?
> AJAX loading of resources in dynamically / programatically generated subtree
> ----------------------------------------------------------------------------
>
> Key: RF-12427
> URL: https://issues.jboss.org/browse/RF-12427
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: core
> Affects Versions: 4.1.0.CR2
> Reporter: Lukáš Fryč
> Fix For: 5-Tracking
>
>
> There are several scenarios where components are dynamically added to the tree so resources for these components doesn't have to be loaded by AJAX:
> * components added programatically
> * components included by {{ui:include}} with dynamic {{src}} attribute
> * components under dynamic rows/panels/etc., e.g. {{rich:tab}} generated by {{c:forEach}} (RF-11694)
> Create mock components with mock resources and test that when component rendered "dynamically", the resources (JS and CSS) are provided to the page properly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (RF-11417) Tab: investigate why @action does not work
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-11417?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-11417:
-------------------------------
Workaround Description:
Create one of these for each tab. For example:
{code}
<a4j:jsFunction name="tabOneSwitch" action="#{myAction.switch('ZZZ')}" execute="@this" render="myForm"/>
<a4j:jsFunction name="tabTwoSwitch" action="#{myAction.switch('RRR')}" execute="@this" render="myForm"/>
<a4j:jsFunction name="tabThreeSwitch" action="#{myAction.switch('MMM')}" execute="@this" render="myForm"/>
{code}
For each tab do this for example:
{code}
<rich:tab onheaderclick="tabOneSwitch();" ... />
<rich:tab onheaderclick="tabTwoSwitch();" ... />
....
{code}
> Tab: investigate why @action does not work
> ------------------------------------------
>
> Key: RF-11417
> URL: https://issues.jboss.org/browse/RF-11417
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-panels-layout-themes
> Affects Versions: 4.1.0.CR1
> Reporter: Lukáš Fryč
> Fix For: 5.0.0.Alpha3
>
>
> Determine why rich:tab @action has not been implemented.
> Verify that its implementation can't affect current applications (and try to find possible workaround).
> Implement @action and @actionListener.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (RF-13165) The rowclick event of the rich:dataTable is not recognized as a valid server-side event during an ajax postback
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13165?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-13165:
-------------------------------
Workaround Description:
{code}
<h:form id="form">
<a4j:jsFunction name="selectRow" actionListener="#{userBean.actionListener}" render="out">
<a4j:param name="currentRow" assignTo="#{userBean.name}"/>
</a4j:jsFunction>
<h:outputText value="#{userBean.name}" id="out" />
<rich:dataTable value="#{carsBean.allInventoryItems}" var="car" footerClass="footerCklass" onrowclick="selectRow('#{car.vendor}');"
{code}
(workaround taken from RF-10824)
> The rowclick event of the rich:dataTable is not recognized as a valid server-side event during an ajax postback
> ---------------------------------------------------------------------------------------------------------------
>
> Key: RF-13165
> URL: https://issues.jboss.org/browse/RF-13165
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-tables
> Reporter: Fab Mars
> Fix For: 5-Tracking
>
>
> An embedded _<a4j:ajax>_ tag in an extendedDataTable with the event rowclick_ does not work. The relevant code snippet:
> {code}
> <a4j:ajax event="rowclick" render="shippingEditForm" listener="#{shippingEdit.setId(shipping.id)}"/>
> {code}
> This *should* work. A google search quickly shows one how many people expect it to work. I dug in to find out why it doesn't work:
> When a HTML element triggers an ajax event, a check is performed on the server-side to see if the HTML element that triggered the event is the JSF component that is being decoded. This is done in this line of code:
> https://github.com/richfaces/richfaces/blob/master/framework/src/main/jav...
> {code}
> if (behaviorSource != null && behaviorSource.equals(clientId)) {
> ...
> {code}
> Before the request is sent to the server, we check if the originating element of an event is from a component, and "re-target" it if not (see:RF-12616, RF-12715). This is done in these lines of code:
> https://github.com/richfaces/richfaces/blob/master/framework/src/main/res...
> {code}
> if (this.id && sourceElement.id.indexOf(this.id) == 0) { // otherwise parent element is definitely not JSF component
> var suffix = sourceElement.id.substring(this.id.length); // extract suffix
> if (suffix.match(/^[a-zA-Z]*$/) && isRichFacesComponent(this)) {
> parentElement = this;
> return false;
> }
> }
> {code}
> This re-targeting works well, as for the most part elements DOM ids within components use the _#\{clientId}Qualifier_ syntax. However this breaks down with table rows, where the ":" separator is used. This is the same separator used to separate JSF component id's in the _clientId_. For example, a table with the _clilentId_ "_form:edt_" will have rows with DOM id "_myForm:edt:5:n_".
> So we need to fix the client-side re-targeting to work for table rows.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (RF-13250) Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
by SBS JIRA Integration (JIRA)
[ https://issues.jboss.org/browse/RF-13250?page=com.atlassian.jira.plugin.s... ]
SBS JIRA Integration updated RF-13250:
--------------------------------------
Forum Reference: https://community.jboss.org/message/840357#840357
> Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
> --------------------------------------------------------------
>
> Key: RF-13250
> URL: https://issues.jboss.org/browse/RF-13250
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.4
> Environment: Gentoo Linux, Tomcat 7.0.39, MyFaces 2.1.12, Tomahawk 1.1.14, RichFaces 4.3.4, APR 1.4.5
> Reporter: Milo van der Zee
> Assignee: Pavol Pitonak
> Labels: memoryleak
>
> Hello,
> I did an upgrade from RF 4.3.3.Final to 4.3.4.Final and the application started to crash with 'Out Off Memory' errors. I changed the POM back to 4.3.3.Final and the problem is gone.
> I also started seeing this message lot's of times:
> {{WARN org.atmosphere.cpr.AtmosphereResponse - Committed error code 400}}
> I don't know if that has anything to do with the error. I set {{org.atmosphere.cpr.sessionSupport}} to {{true}} and I did not see the message again. But still the application went out-of-memory.
> In the crashed system heap dump I see a lot of:
> - AtomicBoolean (751.000, 15.0MB)
> - ConcurrentLinkedQueue
> - AtmospereRequest$Builder (60.042, 13.8MB)
> To me it looks like it has something to do with Atmosphere. Any ideas?
> Thanks,
> Milo van der Zee
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (RF-13250) Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
by Milo van der Zee (JIRA)
[ https://issues.jboss.org/browse/RF-13250?page=com.atlassian.jira.plugin.s... ]
Milo van der Zee commented on RF-13250:
---------------------------------------
Hello Brian, I can't try this in the 'production' environment but I'll start my dev station and see if the problem also shows without many users. If so, I cab check if Mojarra changes the behaviour.
Thanks for the interest in this issue. I'll try to help and fix it.
> Extreme memory usage in RF4.3.4.Final and not in RF4.3.3.Final
> --------------------------------------------------------------
>
> Key: RF-13250
> URL: https://issues.jboss.org/browse/RF-13250
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 4.3.4
> Environment: Gentoo Linux, Tomcat 7.0.39, MyFaces 2.1.12, Tomahawk 1.1.14, RichFaces 4.3.4, APR 1.4.5
> Reporter: Milo van der Zee
> Assignee: Pavol Pitonak
> Labels: memoryleak
>
> Hello,
> I did an upgrade from RF 4.3.3.Final to 4.3.4.Final and the application started to crash with 'Out Off Memory' errors. I changed the POM back to 4.3.3.Final and the problem is gone.
> I also started seeing this message lot's of times:
> {{WARN org.atmosphere.cpr.AtmosphereResponse - Committed error code 400}}
> I don't know if that has anything to do with the error. I set {{org.atmosphere.cpr.sessionSupport}} to {{true}} and I did not see the message again. But still the application went out-of-memory.
> In the crashed system heap dump I see a lot of:
> - AtomicBoolean (751.000, 15.0MB)
> - ConcurrentLinkedQueue
> - AtmospereRequest$Builder (60.042, 13.8MB)
> To me it looks like it has something to do with Atmosphere. Any ideas?
> Thanks,
> Milo van der Zee
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (RF-13251) FocusManager to support complex components like rich:autocomplete
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-13251?page=com.atlassian.jira.plugin.s... ]
Brian Leathem commented on RF-13251:
------------------------------------
Sounds like this use case would be better served by adding auto-complete capabilities to the select component (RF-11453).
> FocusManager to support complex components like rich:autocomplete
> -----------------------------------------------------------------
>
> Key: RF-13251
> URL: https://issues.jboss.org/browse/RF-13251
> Project: RichFaces
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: component-misc
> Affects Versions: 4.3.4
> Reporter: Immo Benjes
> Priority: Minor
>
> Currently the FocusManager in Richfaces only works on 'simple' UI components like h:inputText or h:selectOneMenu but not on more complex components like rich:autocomplete.
> It would be good if FocusManager could support complex components or 'real' Ids as generated for that page.
> The use case for the support on autocomplete is like this:
> User has to enter multiple 'entities'. A rich:autocomplete is used to select the entity and add it to a list. After each ajax submit the focus gets lost and the user has to manually set the focus back to the autocomplete input field.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months
[JBoss JIRA] (RF-10618) autocomplete: unnesessary request on item selection
by Brian Leathem (JIRA)
[ https://issues.jboss.org/browse/RF-10618?page=com.atlassian.jira.plugin.s... ]
Brian Leathem updated RF-10618:
-------------------------------
Assignee: (was: Nick Belaevski)
> autocomplete: unnesessary request on item selection
> ---------------------------------------------------
>
> Key: RF-10618
> URL: https://issues.jboss.org/browse/RF-10618
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-input
> Affects Versions: 4.0.0.Milestone6
> Reporter: Ilya Shaikovsky
> Priority: Minor
> Fix For: 5-Future
>
>
> {code}
> <h:form>
> <rich:autocomplete mode="cachedAjax" tokens=", " minChars="0"
> autoFill="false" selectFirst="false" id="ac2"
> value="#{autocompleteBean.svalue}" var="a"
> autocompleteList="#{autocompleteBean.autocompleteList}">
> </rich:autocomplete>
> <h:outputText value="#{autocompleteBean.svalue}" id="out2" />
> </h:form>
> {code}
> # focus input
> # type a - Ajax request sent and list populated - OK
> # select first item. - item selected and one more Ajax request sent. - FAIL. no need in one more request.
> This one is minor and I believe future. minor because in that case list returned not according to "a" letter but all the states starting on different letters.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
12 years, 5 months