Re: [core] performance: performance hints
Hi
2011/4/19 Martin Koci martin.kocicak.k...@gmail.com
Hi,
is it possible to introduce performance hints in myfaces-core? Hints
similar to javax.faces.component.visit.VisitHint but related to
performance improvements. Example:
For dataTable like:
a:dataTable
a:column
#{aExpression}
it's completely unnecessary to save per-row state. Currently there is no
elegant way how to do read-only table (state per-row is always
maintained). If user wants (fast) readOnly table, he/she must extend
UIData and re-implemenent setRowIndex method. But hint say
org.apache.myfaces.core.UIData.saveRowState=false can solve it
elegantly - if present (in component.getAttributes()) UIData skips
row-state-saving and restoring methods entirely.
Unfortunately, we can't do anything like that on default UIData
implementation
(it could breaks backwards behavior). I think we could include a property
on tomahawk t:dataTable called readOnly, that just skip all that code
related to save/restore for rows. That could be better, and it has sense to
put in tomahawk, because after all that is the right location for extend
default jsf components.
Anyway, I think it is possible to do some work on UIData to make it perform
faster and better.
Lifespan of those hints can be request (faceContext.attributes) or view
(component.attributes)
I don't think in this case it applies, but any configuration param for a
view
should be on a tag like f:view or something similar.
regards,
Leonardo
WDYT?
Regards,
Kočičák
See https://issues.apache.org/jira/browse/MYFACES-3111 too.
[jira] [Created] (MYFACES-3114) jsf.js jsf.ajax.response relies on internal parals
jsf.js jsf.ajax.response relies on internal parals -- Key: MYFACES-3114 URL: https://issues.apache.org/jira/browse/MYFACES-3114 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.5 Reporter: Werner Punz We use internal _mfInteral params for jsf.jax.response in our context var. The culprit is jsf.ajax.response is a public api and the response call definitely has to perform as well without those params if called separately. This needs to be fixed. Te _mfInternal params per se are not needed but they help us to deal with certain corner conditions regarding detached elements and forms. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (MYFACES-3115) jsf.js event handler source id might be missing
jsf.js event handler source id might be missing --- Key: MYFACES-3115 URL: https://issues.apache.org/jira/browse/MYFACES-3115 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.5 Reporter: Werner Punz Priority: Minor Martin Koci reported about a missing context.source.id in the event handling. I rather suspect this not being a bug since we had some name fallback in 2.0.4 which was removed to due to being not entirely correct this needs to be investigated. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3114) jsf.js jsf.ajax.response relies on internal parameters
[ https://issues.apache.org/jira/browse/MYFACES-3114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Werner Punz resolved MYFACES-3114. -- Resolution: Fixed Fix Version/s: 2.0.6-SNAPSHOT jsf.js jsf.ajax.response relies on internal parameters -- Key: MYFACES-3114 URL: https://issues.apache.org/jira/browse/MYFACES-3114 Project: MyFaces Core Issue Type: Bug Affects Versions: 2.0.5 Reporter: Werner Punz Fix For: 2.0.6-SNAPSHOT We use internal _mfInteral params for jsf.jax.response in our context var. The culprit is jsf.ajax.response is a public api and the response call definitely has to perform as well without those params if called separately. This needs to be fixed. Te _mfInternal params per se are not needed but they help us to deal with certain corner conditions regarding detached elements and forms. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (MYFACES-3043) Ajax: response(...) function breaks if request(...) has not been called previously
[
https://issues.apache.org/jira/browse/MYFACES-3043?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Werner Punz resolved MYFACES-3043.
--
Resolution: Fixed
The issue has been shifted over to
https://issues.apache.org/jira/browse/MYFACES-3114 and resolved, the
jsf.ajax.response now works properly with default input parameters and hence
resolves itself with a direct call to response an a custom request.
Ajax: response(...) function breaks if request(...) has not been called
previously
--
Key: MYFACES-3043
URL: https://issues.apache.org/jira/browse/MYFACES-3043
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314
Affects Versions: 2.0.4
Reporter: Nick Belaevski
Assignee: Werner Punz
Fix For: 2.0.5
In RichFaces for file upload component we call jsf.ajax.response(...) method
to process contents of IFRAME element. The problem is that this call is not
preceded by call to jsf.ajax.request(...), making MyFaces fail:
response : function(request, context) {
this._q._curReq._response.processResponse(request, context);
}
this._q._curReq - is undefined.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
Re: [core] performance: performance hints
I totally support this improvement +1.
On Mon, Apr 25, 2011 at 12:45 PM, Leonardo Uribe lu4...@gmail.com wrote:
Hi
2011/4/19 Martin Koci martin.kocicak.k...@gmail.com
Hi,
is it possible to introduce performance hints in myfaces-core? Hints
similar to javax.faces.component.visit.VisitHint but related to
performance improvements. Example:
For dataTable like:
a:dataTable
a:column
#{aExpression}
it's completely unnecessary to save per-row state. Currently there is no
elegant way how to do read-only table (state per-row is always
maintained). If user wants (fast) readOnly table, he/she must extend
UIData and re-implemenent setRowIndex method. But hint say
org.apache.myfaces.core.UIData.saveRowState=false can solve it
elegantly - if present (in component.getAttributes()) UIData skips
row-state-saving and restoring methods entirely.
Unfortunately, we can't do anything like that on default UIData
implementation
(it could breaks backwards behavior). I think we could include a property
on tomahawk t:dataTable called readOnly, that just skip all that code
related to save/restore for rows. That could be better, and it has sense to
put in tomahawk, because after all that is the right location for extend
default jsf components.
Anyway, I think it is possible to do some work on UIData to make it perform
faster and better.
Lifespan of those hints can be request (faceContext.attributes) or view
(component.attributes)
I don't think in this case it applies, but any configuration param for a
view
should be on a tag like f:view or something similar.
regards,
Leonardo
WDYT?
Regards,
Kočičák
See https://issues.apache.org/jira/browse/MYFACES-3111 too.
--
Hazem Ahmed Saleh Ahmed
Author of (The Definitive Guide to Apache MyFaces and Facelets):
http://www.amazon.com/Definitive-Guide-Apache-MyFaces-Facelets/dp/1590597370
http://www.amazon.com/-/e/B002M052KY
Visualize and share your social networks 2D and 3D:
http://www.mapmysocial.com
