[jira] [Commented] (MYFACES-3779) Mixed mode(Server+client) for state saving
[ https://issues.apache.org/jira/browse/MYFACES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774331#comment-13774331 ] Thomas Andraschko commented on MYFACES-3779: Don't know if this is really usefull - The state is so small if you don't blow it up with your ViewScopd beans. IMO The only usecass when a mixed mode is really usefull i described here: http://tandraschko.blogspot.de/2012/12/dynamical-switching-of-jsf-state-saving.html Mixed mode(Server+client) for state saving -- Key: MYFACES-3779 URL: https://issues.apache.org/jira/browse/MYFACES-3779 Project: MyFaces Core Issue Type: New Feature Reporter: Ertio Lew How about having a mixed mode for state saving whereby state is initially kept on server for a configurable amount of time (so that fast frequent requests are served without transferring the state from client to server several times, the drawback with client side saving) after that period of time if the page is still alive in browser but it is idle, a javascript request is triggered which asks the server for that state data now it will be kept on client side, now the client the server both know that state for this session is there on client. If the page has died no request has been sent to server asking for state data till that period of time, then state data would be removed from server. A further enhancement could be that you could set a fixed amount out of all memory on server that you want to allocate for state saving of all sessions. Till the time that quota remains, state is kept on server using that quota. But when that quota is over all the state information for further sessions is kept using client side state saving. Also a mixed mode. Such mixed modes would be very helpful in improving performance, better utilization of the server resources. -- 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
[jira] [Resolved] (TOBAGO-1314) Version detection works not correctly for JSF 2.1
[ https://issues.apache.org/jira/browse/TOBAGO-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1314. - Resolution: Fixed Version detection works not correctly for JSF 2.1 - Key: TOBAGO-1314 URL: https://issues.apache.org/jira/browse/TOBAGO-1314 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.5.10, 2.0.0-alpha-1 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Minor Fix For: 1.5.11, 2.0.0-alpha-2 Should be also extended to check against JSF 2.2 -- 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
[jira] [Created] (MYFACES-3780) _ComponentAttributesMap return null when no property descriptor is available and null value is passed to map
Leonardo Uribe created MYFACES-3780: --- Summary: _ComponentAttributesMap return null when no property descriptor is available and null value is passed to map Key: MYFACES-3780 URL: https://issues.apache.org/jira/browse/MYFACES-3780 Project: MyFaces Core Issue Type: Bug Components: JSR-314, JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Checking some stuff I have found that there is an old check for null in ComponentAttributesMap.put(...) This check doesn't have sense, because null values are valid for hashmap, and in that sense the check is useless. The fix is very simple, just remove the unnecessary check. I just comment the related code, to prevent other people to try to add it in the future. The fix will be done on 2.0.x, 2.1.x and 2.2.x branches -- 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
[jira] [Resolved] (MYFACES-3780) _ComponentAttributesMap return null when no property descriptor is available and null value is passed to map
[ https://issues.apache.org/jira/browse/MYFACES-3780?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3780. - Resolution: Fixed Fix Version/s: 2.1.13 2.2.0 2.0.19 _ComponentAttributesMap return null when no property descriptor is available and null value is passed to map Key: MYFACES-3780 URL: https://issues.apache.org/jira/browse/MYFACES-3780 Project: MyFaces Core Issue Type: Bug Components: JSR-314, JSR-344 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Fix For: 2.0.19, 2.2.0, 2.1.13 Checking some stuff I have found that there is an old check for null in ComponentAttributesMap.put(...) This check doesn't have sense, because null values are valid for hashmap, and in that sense the check is useless. The fix is very simple, just remove the unnecessary check. I just comment the related code, to prevent other people to try to add it in the future. The fix will be done on 2.0.x, 2.1.x and 2.2.x branches -- 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
[jira] [Created] (TOBAGO-1315) JSON Response is broken for AJAX Requests using Mojarra = 2.1: unallowed XML header
Udo Schnurpfeil created TOBAGO-1315: --- Summary: JSON Response is broken for AJAX Requests using Mojarra = 2.1: unallowed XML header Key: TOBAGO-1315 URL: https://issues.apache.org/jira/browse/TOBAGO-1315 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 2.0.0-alpha-1 Environment: Facelets only (JSP works) Mojarra 2.1.25 Reporter: Udo Schnurpfeil Mojarra always send an XML, but this is not allowed in JSON Responses -- 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
[jira] [Commented] (TOBAGO-1314) Version detection works not correctly for JSF 2.1
[ https://issues.apache.org/jira/browse/TOBAGO-1314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774394#comment-13774394 ] Hudson commented on TOBAGO-1314: SUCCESS: Integrated in tobago-1.5.x #178 (See [https://builds.apache.org/job/tobago-1.5.x/178/]) TOBAGO-1314: Version detection works not correctly for JSF 2.1 (lofwyr: http://svn.apache.org/viewvc/?view=revrev=1525532) * /myfaces/tobago/branches/tobago-1.5.x * /myfaces/tobago/branches/tobago-1.5.x/tobago-example/tobago-example-test/src/main/java/org * /myfaces/tobago/branches/tobago-1.5.x/tobago-example/tobago-example-test/src/main/java/org/apache/myfaces/tobago/example/test/Version.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-example/tobago-example-test/src/main/webapp/WEB-INF/faces-config.xml * /myfaces/tobago/branches/tobago-1.5.x/tobago-example/tobago-example-test/src/main/webapp/script/tobago-assert.js * /myfaces/tobago/branches/tobago-1.5.x/tobago-example/tobago-example-test/src/main/webapp/test/version * /myfaces/tobago/branches/tobago-1.5.x/tobago-example/tobago-example-test/src/main/webapp/test/version/version.js * /myfaces/tobago/branches/tobago-1.5.x/tobago-example/tobago-example-test/src/main/webapp/test/version/version.xhtml * /myfaces/tobago/branches/tobago-1.5.x/tobago-jsf-compat/src/main/java/org/apache/myfaces/tobago/util/FacesVersion.java Version detection works not correctly for JSF 2.1 - Key: TOBAGO-1314 URL: https://issues.apache.org/jira/browse/TOBAGO-1314 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 1.5.10, 2.0.0-alpha-1 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Minor Fix For: 1.5.11, 2.0.0-alpha-2 Should be also extended to check against JSF 2.2 -- 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
[jira] [Commented] (MYFACES-3779) Mixed mode(Server+client) for state saving
[ https://issues.apache.org/jira/browse/MYFACES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774397#comment-13774397 ] Leonardo Uribe commented on MYFACES-3779: - In JSF 2.2, ViewScoped beans are stored in session, no matter if client side or server side state saving is used. The code we have right now in MyFaces Core is good enough to be extended. The problem is there is no clarity about the usefulness of the strategy proposed, because with the new JSF 2.0 partial state saving algorithm, the ammount of memory required to store views into session has been reduced to its minimal expression. In this article: http://content.jsfcentral.com/c/journal/view_article_content?cmd=viewgroupId=35702articleId=73398version=1.8#.UkAArj9Kvb0 At the end there is a graph showing how the state evolves for a client in a simple application. Other frameworks like Grails and Tapestry that are supposed to be stateless uses almost the same or more session space that MyFaces Core. The focus used to solve the problem until now has been to reduce the size required to store views into the state. In this context, it is questionable if the technique can be useful from performance perspective. In other words, it is required more information about the usefulness of the change proposed from performance perspective. I think it is better to try to solve this at spec level and live for now with a hack outside MyFaces Core code. It is clear that the hack proposed aims to solve some situations where a ViewExpiredException should not be thrown. Mixed mode(Server+client) for state saving -- Key: MYFACES-3779 URL: https://issues.apache.org/jira/browse/MYFACES-3779 Project: MyFaces Core Issue Type: New Feature Reporter: Ertio Lew How about having a mixed mode for state saving whereby state is initially kept on server for a configurable amount of time (so that fast frequent requests are served without transferring the state from client to server several times, the drawback with client side saving) after that period of time if the page is still alive in browser but it is idle, a javascript request is triggered which asks the server for that state data now it will be kept on client side, now the client the server both know that state for this session is there on client. If the page has died no request has been sent to server asking for state data till that period of time, then state data would be removed from server. A further enhancement could be that you could set a fixed amount out of all memory on server that you want to allocate for state saving of all sessions. Till the time that quota remains, state is kept on server using that quota. But when that quota is over all the state information for further sessions is kept using client side state saving. Also a mixed mode. Such mixed modes would be very helpful in improving performance, better utilization of the server resources. -- 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
[jira] [Resolved] (TOBAGO-1315) JSON Response is broken for AJAX Requests using Mojarra = 2.1: unallowed XML header
[ https://issues.apache.org/jira/browse/TOBAGO-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1315. - Resolution: Fixed Fix Version/s: 2.0.0-alpha-2 Assignee: Udo Schnurpfeil JSON Response is broken for AJAX Requests using Mojarra = 2.1: unallowed XML header Key: TOBAGO-1315 URL: https://issues.apache.org/jira/browse/TOBAGO-1315 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 2.0.0-alpha-1 Environment: Facelets only (JSP works) Mojarra 2.1.25 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 2.0.0-alpha-2 Mojarra always send an XML, but this is not allowed in JSON Responses -- 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
[jira] [Resolved] (TOBAGO-1307) tx:date not recognized as partial request
[
https://issues.apache.org/jira/browse/TOBAGO-1307?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Schnurpfeil resolved TOBAGO-1307.
-
Resolution: Fixed
Fix Version/s: 2.0.0-alpha-2
Assignee: Udo Schnurpfeil
tx:date not recognized as partial request
-
Key: TOBAGO-1307
URL: https://issues.apache.org/jira/browse/TOBAGO-1307
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0-alpha-2
Environment: Facelets (JSP works)
Mojarra (MyFaces works)
Version = 2.1
Reporter: Michael Bädorf
Assignee: Udo Schnurpfeil
Fix For: 2.0.0-alpha-2
Using tx:date with JSF 2.x returns a wrong answer:
?xml version=\1.0\ encoding=\UTF-8\?\n{
tobagoAjaxResponse: true,
responseCode: 200,
ajaxPart_0: {
ajaxId: j_idt1:j_idt13:j_id42:j_id43popup,
html: ... snipped ...,
responseCode: 200
},
jsfState: input type=\hidden\ name=\javax.faces.ViewState\
id=\j_id1:javax.faces.ViewState:0\
value=\-1186034638223701276:-8097948037232765006\ autocomplete=\off\
}
As seen in example app it should return something like
{
tobagoAjaxResponse: true,
responseCode: 200,
ajaxPart_0: {
ajaxId: j_idt1:j_idt13:j_id42:j_id43popup,
html: ... snipped ...,
responseCode: 200
},
jsfState: input type=\hidden\ name=\javax.faces.ViewState\
id=\j_id1:javax.faces.ViewState:0\
value=\-1186034638223701276:-8097948037232765006\ autocomplete=\off\
}
The error seems to be
?xml version=\1.0\ encoding=\UTF-8\?\n
so the answer could not recognized as json answer
--
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
[jira] [Resolved] (TOBAGO-1298) Re-implement TobagoConfigParser
[ https://issues.apache.org/jira/browse/TOBAGO-1298?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1298. - Resolution: Fixed Fix Version/s: 2.0.0-alpha-2 Re-implement TobagoConfigParser --- Key: TOBAGO-1298 URL: https://issues.apache.org/jira/browse/TOBAGO-1298 Project: MyFaces Tobago Issue Type: Task Components: Core Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Minor Fix For: 2.0.0-alpha-2 The new parser uses plain Java (SAX) for reading the configuration. So, we no longer need the digester. Removing the old TobagoThemeParser. The tobago-theme.xml is part of tobago-config.xml since Tobago 1.5.x -- 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
[jira] [Resolved] (TOBAGO-1310) Support for the CSP header field: Content-Security-Policy-Report-Only
[ https://issues.apache.org/jira/browse/TOBAGO-1310?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1310. - Resolution: Fixed Fix Version/s: 2.0.0 2.0.0-alpha-2 Support for the CSP header field: Content-Security-Policy-Report-Only - Key: TOBAGO-1310 URL: https://issues.apache.org/jira/browse/TOBAGO-1310 Project: MyFaces Tobago Issue Type: New Feature Components: Core Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Minor Fix For: 2.0.0-alpha-2, 2.0.0 -- 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
[jira] [Commented] (MYFACES-3779) Mixed mode(Server+client) for state saving
[ https://issues.apache.org/jira/browse/MYFACES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774403#comment-13774403 ] Thomas Andraschko commented on MYFACES-3779: It is clear that the hack proposed aims to solve some situations where a ViewExpiredException should not be thrown. I didn't know that ViewScoped beans will be always serialized to the session now. What happens in the future if i would use client side state and the ViewScoped beans are not available anymore? Also a ViewExpiredException? Mixed mode(Server+client) for state saving -- Key: MYFACES-3779 URL: https://issues.apache.org/jira/browse/MYFACES-3779 Project: MyFaces Core Issue Type: New Feature Reporter: Ertio Lew How about having a mixed mode for state saving whereby state is initially kept on server for a configurable amount of time (so that fast frequent requests are served without transferring the state from client to server several times, the drawback with client side saving) after that period of time if the page is still alive in browser but it is idle, a javascript request is triggered which asks the server for that state data now it will be kept on client side, now the client the server both know that state for this session is there on client. If the page has died no request has been sent to server asking for state data till that period of time, then state data would be removed from server. A further enhancement could be that you could set a fixed amount out of all memory on server that you want to allocate for state saving of all sessions. Till the time that quota remains, state is kept on server using that quota. But when that quota is over all the state information for further sessions is kept using client side state saving. Also a mixed mode. Such mixed modes would be very helpful in improving performance, better utilization of the server resources. -- 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
[jira] [Resolved] (TOBAGO-1302) Add support for a theme resources index file per theme
[ https://issues.apache.org/jira/browse/TOBAGO-1302?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1302. - Resolution: Fixed Fix Version/s: 2.0.0 2.0.0-alpha-2 Add support for a theme resources index file per theme -- Key: TOBAGO-1302 URL: https://issues.apache.org/jira/browse/TOBAGO-1302 Project: MyFaces Tobago Issue Type: Improvement Components: Themes Affects Versions: 2.0.0-alpha-1 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Priority: Minor Fix For: 2.0.0-alpha-2, 2.0.0 Add a index goal to the tobago-theme-plugin and add a support for reading this index file instead of scanning the theme jar. -- 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
[jira] [Resolved] (TOBAGO-1297) Remove deprecated-name from theme definition
[ https://issues.apache.org/jira/browse/TOBAGO-1297?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-1297. - Resolution: Fixed Fix Version/s: 2.0.0 2.0.0-alpha-2 Remove deprecated-name from theme definition -- Key: TOBAGO-1297 URL: https://issues.apache.org/jira/browse/TOBAGO-1297 Project: MyFaces Tobago Issue Type: Task Components: Themes Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Priority: Trivial Fix For: 2.0.0-alpha-2, 2.0.0 This cleans up only a renaming step many years ago... -- 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
[jira] [Resolved] (TOBAGO-1295) Loading themes on JBoss 7.x.x with vfs protocol
[
https://issues.apache.org/jira/browse/TOBAGO-1295?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Udo Schnurpfeil resolved TOBAGO-1295.
-
Resolution: Fixed
Fix Version/s: 2.0.0
2.0.0-alpha-2
Loading themes on JBoss 7.x.x with vfs protocol
---
Key: TOBAGO-1295
URL: https://issues.apache.org/jira/browse/TOBAGO-1295
Project: MyFaces Tobago
Issue Type: Bug
Components: Core
Affects Versions: 2.0.0-alpha-2
Environment: Jboss 7.1.1, Jboss 7.2.0
Reporter: Thomas Schmitz
Assignee: Udo Schnurpfeil
Fix For: 2.0.0-alpha-2, 2.0.0
JBoss seemingly has changed its VFS scheme name from vfszip to vfs in version
7.x.x. Therefore it is not possible to deploy a tobago application on it as
tobago does not know how to handle it.
I tried to fix it in ResourceLocator by simply changing the part where the
old vfszip protocol is handled from 'protocol.equals(vfszip)' to
'protocol.startsWith(vfs).
But it seems that vfszip and vfs must be handled in different ways as the
part where the jar or zip file is loaded with the ZipInputStream does not
work:
zipStream = new ZipInputStream(stream);
while (zipStream.available() 0) {
ZipEntry nextEntry = zipStream.getNextEntry();
if (nextEntry == null || nextEntry.isDirectory()) {
continue;
}
String name = / + nextEntry.getName();
if (name.startsWith(prefix)) {
addResource(resources, name, skipPrefix);
}
}
In fact it produces an infinite loop because zipStream.available always
returns 0 but zipStream.getNextEntry is always null.
I found out that if I disclaim on the theme-jars and unzip them next to my
WEB-INF directory they will be loaded correct. So my workaround is to comment
out the part with the infinite loop.
I am sad that I can't propose a good patch for this. The only way I found out
is to use jboss-vfs API to handle the vfs scheme correct.
--
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
[jira] [Commented] (TOBAGO-1315) JSON Response is broken for AJAX Requests using Mojarra = 2.1: unallowed XML header
[ https://issues.apache.org/jira/browse/TOBAGO-1315?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774424#comment-13774424 ] Hudson commented on TOBAGO-1315: SUCCESS: Integrated in tobago-trunk # (See [https://builds.apache.org/job/tobago-trunk//]) TOBAGO-1315: JSON Response is broken for AJAX Requests using Mojarra = 2.1: unallowed XML header (lofwyr: http://svn.apache.org/viewvc/?view=revrev=1525539) * /myfaces/tobago/trunk/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/webapp/JsonResponseWriter.java JSON Response is broken for AJAX Requests using Mojarra = 2.1: unallowed XML header Key: TOBAGO-1315 URL: https://issues.apache.org/jira/browse/TOBAGO-1315 Project: MyFaces Tobago Issue Type: Bug Components: Core Affects Versions: 2.0.0-alpha-1 Environment: Facelets only (JSP works) Mojarra 2.1.25 Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 2.0.0-alpha-2, 2.0.0 Mojarra always send an XML, but this is not allowed in JSON Responses -- 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
[jira] [Commented] (MYFACES-3779) Mixed mode(Server+client) for state saving
[ https://issues.apache.org/jira/browse/MYFACES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774429#comment-13774429 ] Leonardo Uribe commented on MYFACES-3779: - TA I didn't know that ViewScoped beans will be always serialized to the session now. Yes, that how things are working now according to the new JSF 2.2 spec. Flow scope beans needs to be serialized in session too, even if both @ViewScoped and @FlowScoped are not marked as persistent capable. It is the only way to make these scopes work. TA What happens in the future if i would use client side state and the ViewScoped beans are not available anymore? Also a ViewExpiredException? The beans will silently be created again, and the context will be lost. The code is already in place, so you can try the latest snapshot. Mixed mode(Server+client) for state saving -- Key: MYFACES-3779 URL: https://issues.apache.org/jira/browse/MYFACES-3779 Project: MyFaces Core Issue Type: New Feature Reporter: Ertio Lew How about having a mixed mode for state saving whereby state is initially kept on server for a configurable amount of time (so that fast frequent requests are served without transferring the state from client to server several times, the drawback with client side saving) after that period of time if the page is still alive in browser but it is idle, a javascript request is triggered which asks the server for that state data now it will be kept on client side, now the client the server both know that state for this session is there on client. If the page has died no request has been sent to server asking for state data till that period of time, then state data would be removed from server. A further enhancement could be that you could set a fixed amount out of all memory on server that you want to allocate for state saving of all sessions. Till the time that quota remains, state is kept on server using that quota. But when that quota is over all the state information for further sessions is kept using client side state saving. Also a mixed mode. Such mixed modes would be very helpful in improving performance, better utilization of the server resources. -- 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
[jira] [Created] (MYFACES-3781) f:view tag must be processed when view metadata is created
Leonardo Uribe created MYFACES-3781:
---
Summary: f:view tag must be processed when view metadata is created
Key: MYFACES-3781
URL: https://issues.apache.org/jira/browse/MYFACES-3781
Project: MyFaces Core
Issue Type: Bug
Components: JSR-314, JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
From stackoverflow.com:
http://stackoverflow.com/questions/18495673/validation-conversion-errors-of-fviewparam-do-not-localize-to-fview-locale
In few words, if a:
f:view locale=#{... ...}
is used and there is a converter attached to a f:viewParam, the locale is not
set before the converter is used. In theory, f:view must be taken into account
when the facelet view metadata is created, but the content of f:view tag should
not be added by performance considerations.
I think the issue is valid, and it has relevance under JSF 2.2 spec, so it
should be fixed for 2.0.x, 2.1.x and 2.2.x
--
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
[jira] [Commented] (MYFACES-3779) Mixed mode(Server+client) for state saving
[ https://issues.apache.org/jira/browse/MYFACES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774448#comment-13774448 ] Ertio Lew commented on MYFACES-3779: To deal with ViewExpiredExceptions most of us are forced to use client side saving even when cost of state saving on server is minimal but when using the client side saving, there are associated CPU costs to encrypt/decrypt the state when transferring between client server. Also I see lot of hidden fields containing large amount of text for viewstate data which increase the page size considerably when pages are relatively small. Thus I just feel when we use client side saving we a loosing a bit of performance, so why not just opt for client side saving when it becomes real necessarily otherwise use server saving. I think dealing with ViewExpiredException is a necessity for almost all public facing applications above strategy looks somewhat addressing that concern. Mixed mode(Server+client) for state saving -- Key: MYFACES-3779 URL: https://issues.apache.org/jira/browse/MYFACES-3779 Project: MyFaces Core Issue Type: New Feature Reporter: Ertio Lew How about having a mixed mode for state saving whereby state is initially kept on server for a configurable amount of time (so that fast frequent requests are served without transferring the state from client to server several times, the drawback with client side saving) after that period of time if the page is still alive in browser but it is idle, a javascript request is triggered which asks the server for that state data now it will be kept on client side, now the client the server both know that state for this session is there on client. If the page has died no request has been sent to server asking for state data till that period of time, then state data would be removed from server. A further enhancement could be that you could set a fixed amount out of all memory on server that you want to allocate for state saving of all sessions. Till the time that quota remains, state is kept on server using that quota. But when that quota is over all the state information for further sessions is kept using client side state saving. Also a mixed mode. Such mixed modes would be very helpful in improving performance, better utilization of the server resources. -- 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
[jira] [Commented] (MYFACES-3733) Implement vdl.createComponent(...)
[
https://issues.apache.org/jira/browse/MYFACES-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774454#comment-13774454
]
Xavier Cho commented on MYFACES-3733:
-
@[~lu4242], I tried to change ordering of components to make a child added
before the parent as suggested, though the problem seems to persist.
I'd very much like to contribute a test case, though I had to abandon the
current approach of dynamically creating composite components altogether as I'm
already far behind the schedule.
I'm sorry I couldn't submit any concrete example which reproduces the problem.
And thanks for the help!
Implement vdl.createComponent(...)
--
Key: MYFACES-3733
URL: https://issues.apache.org/jira/browse/MYFACES-3733
Project: MyFaces Core
Issue Type: Task
Components: JSR-344
Reporter: Leonardo Uribe
This is a difficult issue to do in JSF 2.2 . I have spent a long time to
solve this one, and given the complexity involved and since there is no
documentation anywhere about how this should work, I'll let the required
explanation here.
The idea is allow to include generated vdl fragments into pages
programatically. This includes normal components, composite components or
just fragments of markup. The method signature is this:
public UIComponent createComponent(FacesContext context, String taglibURI,
String tagName, MapString,Object attributes)
Some valid examples of this are:
// Normal component
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/html;,
outputText, attributes);
// Composite component
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/composite/testComposite;,
dynComp_1, attributes);
// Dynamic include
MapString, Object attributes = new HashMapString, Object();
attributes.put(src, /addSimpleIncludeVDL_1_1.xhtml);
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/facelets;,
include, attributes);
The javadoc does not suggest the dynamic include is valid, but I think users
expect these kind of stuff work.
Theoretically it sounds like something easy to do, but unfortunately it is
not. The reasons why this is so are:
- Facelets algorithm wraps html markup into UILeaf instances, which is a
special transient component. UILeaf instances are never saved or restored
from the component tree, but in some points of the algorithm (restore view
and before render response when vdl.buildView() is called) the component tree
is updated, adding or removing UILeaf instances.
- Facelets has an algorithm that require id generation to be stable,
otherwise a duplicate id exception may arise. A lot of effort has been done
to organize this part, and the current solution works very well. But in this
case, we need to generate unique ids that can be refreshed somehow.
- Facelets algorithm has an special logic to deal with dynamic sections like
the ones generated by c:if or
ui:include src=#{...} . Add facelets sections programatically could make
this algorithm fail, removing sections that should be.
- Facelets PSS algorithm needs to be taken into account too. The listener
that is used to register programmatic changes on the tree in
DefaultFaceletsStateManagementStrategy uses ComponentSupport.MARK_CREATED to
identify which component belongs to the component tree and which one was
added by outside. Add facelets sections programatically could make this
algorithm fail, because it could assume some sections of the tree does not
need to be saved fully, even if that's not true.
The issue in the spec is this:
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-611
At start the idea was to export FaceletFactory directly, but I told to the EG
that it was a bad idea by multiple reasons (That's a Pandora's Box). See:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/91
This previous message is useful too:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-06/message/18
After thinking and trying different strategies to overcome this issue, I
finally found the following solution:
- Use the compiler for generate a custom Facelet inline or on the fly. It
is not necessary to create an
xml document and then parse it, just generate the Tag class and pass it to
the compiler to generate an
Abstract Syntax Tree (AST), with the hierarchy of facelet TagHandler
instances.
- To solve the issue with UILeaf instances, the best is create a stateful
ComponentSystemEventListener that on restore view phase it compiles the
custom Facelet and apply it over the fragment. The ideal and only event to
attach the listener is PostRestoreStateEvent,
[jira] [Comment Edited] (MYFACES-3779) Mixed mode(Server+client) for state saving
[ https://issues.apache.org/jira/browse/MYFACES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774448#comment-13774448 ] Ertio Lew edited comment on MYFACES-3779 at 9/23/13 10:54 AM: -- To deal with ViewExpiredExceptions most of us are forced to use client side saving even when cost of state saving on server is minimal but when using the client side saving, there are associated CPU costs to encrypt/decrypt the state when transferring between client server. With client side saving, there are a lot of hidden input fields for viewstate data containing large amount of texts which increase the page size considerably when pages are relatively small. Thus I just feel when we use client side saving we a loosing a bit of performance, so why not just opt for client side saving when it becomes real necessity otherwise use server saving, as per above mixed mode strategy. I think dealing with ViewExpiredException is a necessity for almost all public facing applications right now using client side saving is the only way to deal with this but it has its own issues(as described above), thus this mixed mode looks somewhat addressing these concerns. was (Author: ertiop93): To deal with ViewExpiredExceptions most of us are forced to use client side saving even when cost of state saving on server is minimal but when using the client side saving, there are associated CPU costs to encrypt/decrypt the state when transferring between client server. Also I see lot of hidden fields containing large amount of text for viewstate data which increase the page size considerably when pages are relatively small. Thus I just feel when we use client side saving we a loosing a bit of performance, so why not just opt for client side saving when it becomes real necessarily otherwise use server saving. I think dealing with ViewExpiredException is a necessity for almost all public facing applications above strategy looks somewhat addressing that concern. Mixed mode(Server+client) for state saving -- Key: MYFACES-3779 URL: https://issues.apache.org/jira/browse/MYFACES-3779 Project: MyFaces Core Issue Type: New Feature Reporter: Ertio Lew How about having a mixed mode for state saving whereby state is initially kept on server for a configurable amount of time (so that fast frequent requests are served without transferring the state from client to server several times, the drawback with client side saving) after that period of time if the page is still alive in browser but it is idle, a javascript request is triggered which asks the server for that state data now it will be kept on client side, now the client the server both know that state for this session is there on client. If the page has died no request has been sent to server asking for state data till that period of time, then state data would be removed from server. A further enhancement could be that you could set a fixed amount out of all memory on server that you want to allocate for state saving of all sessions. Till the time that quota remains, state is kept on server using that quota. But when that quota is over all the state information for further sessions is kept using client side state saving. Also a mixed mode. Such mixed modes would be very helpful in improving performance, better utilization of the server resources. -- 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
[jira] [Commented] (MYFACES-3779) Mixed mode(Server+client) for state saving
[ https://issues.apache.org/jira/browse/MYFACES-3779?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774464#comment-13774464 ] Leonardo Uribe commented on MYFACES-3779: - I have already studied the effect of the encryption over performance and I can say it is proportional to the size of the state. Small state, small performance overhead. Server side increase server memory usage, but client side increase network overhead and CPU usage. I can see the logic behind this. The problem is we have not agreed how should be done this customization, and first of all which problem we are trying to solve: better performance or avoid ViewExpiredException. If the feature is for performance, decide which views should use client side or server side looks like something that should be decided at deployment time. Should we use some kind of extra xml file for it? maybe, and it has sense if we add in the future the view pool technique. But if the feature is to avoid ViewExpiredException, it means there is something we need to fix at the spec level, because the application developer should be able to decide that when he/she is writing the application code. Mixed mode(Server+client) for state saving -- Key: MYFACES-3779 URL: https://issues.apache.org/jira/browse/MYFACES-3779 Project: MyFaces Core Issue Type: New Feature Reporter: Ertio Lew How about having a mixed mode for state saving whereby state is initially kept on server for a configurable amount of time (so that fast frequent requests are served without transferring the state from client to server several times, the drawback with client side saving) after that period of time if the page is still alive in browser but it is idle, a javascript request is triggered which asks the server for that state data now it will be kept on client side, now the client the server both know that state for this session is there on client. If the page has died no request has been sent to server asking for state data till that period of time, then state data would be removed from server. A further enhancement could be that you could set a fixed amount out of all memory on server that you want to allocate for state saving of all sessions. Till the time that quota remains, state is kept on server using that quota. But when that quota is over all the state information for further sessions is kept using client side state saving. Also a mixed mode. Such mixed modes would be very helpful in improving performance, better utilization of the server resources. -- 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
[jira] [Commented] (MYFACES-3733) Implement vdl.createComponent(...)
[
https://issues.apache.org/jira/browse/MYFACES-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774606#comment-13774606
]
Leonardo Uribe commented on MYFACES-3733:
-
Please note I have already committed a solution for the problem found
Implement vdl.createComponent(...)
--
Key: MYFACES-3733
URL: https://issues.apache.org/jira/browse/MYFACES-3733
Project: MyFaces Core
Issue Type: Task
Components: JSR-344
Reporter: Leonardo Uribe
This is a difficult issue to do in JSF 2.2 . I have spent a long time to
solve this one, and given the complexity involved and since there is no
documentation anywhere about how this should work, I'll let the required
explanation here.
The idea is allow to include generated vdl fragments into pages
programatically. This includes normal components, composite components or
just fragments of markup. The method signature is this:
public UIComponent createComponent(FacesContext context, String taglibURI,
String tagName, MapString,Object attributes)
Some valid examples of this are:
// Normal component
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/html;,
outputText, attributes);
// Composite component
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/composite/testComposite;,
dynComp_1, attributes);
// Dynamic include
MapString, Object attributes = new HashMapString, Object();
attributes.put(src, /addSimpleIncludeVDL_1_1.xhtml);
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/facelets;,
include, attributes);
The javadoc does not suggest the dynamic include is valid, but I think users
expect these kind of stuff work.
Theoretically it sounds like something easy to do, but unfortunately it is
not. The reasons why this is so are:
- Facelets algorithm wraps html markup into UILeaf instances, which is a
special transient component. UILeaf instances are never saved or restored
from the component tree, but in some points of the algorithm (restore view
and before render response when vdl.buildView() is called) the component tree
is updated, adding or removing UILeaf instances.
- Facelets has an algorithm that require id generation to be stable,
otherwise a duplicate id exception may arise. A lot of effort has been done
to organize this part, and the current solution works very well. But in this
case, we need to generate unique ids that can be refreshed somehow.
- Facelets algorithm has an special logic to deal with dynamic sections like
the ones generated by c:if or
ui:include src=#{...} . Add facelets sections programatically could make
this algorithm fail, removing sections that should be.
- Facelets PSS algorithm needs to be taken into account too. The listener
that is used to register programmatic changes on the tree in
DefaultFaceletsStateManagementStrategy uses ComponentSupport.MARK_CREATED to
identify which component belongs to the component tree and which one was
added by outside. Add facelets sections programatically could make this
algorithm fail, because it could assume some sections of the tree does not
need to be saved fully, even if that's not true.
The issue in the spec is this:
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-611
At start the idea was to export FaceletFactory directly, but I told to the EG
that it was a bad idea by multiple reasons (That's a Pandora's Box). See:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/91
This previous message is useful too:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-06/message/18
After thinking and trying different strategies to overcome this issue, I
finally found the following solution:
- Use the compiler for generate a custom Facelet inline or on the fly. It
is not necessary to create an
xml document and then parse it, just generate the Tag class and pass it to
the compiler to generate an
Abstract Syntax Tree (AST), with the hierarchy of facelet TagHandler
instances.
- To solve the issue with UILeaf instances, the best is create a stateful
ComponentSystemEventListener that on restore view phase it compiles the
custom Facelet and apply it over the fragment. The ideal and only event to
attach the listener is PostRestoreStateEvent, but we need to add the code in
UIComponent.processEvent().
- In the case of a ui:include, if multiple components are returned, all of
them are grouped into a single
UIPanel. If the code returns one component, it returns that component.
- If the code generates a branch, or in other words, multiple nested
components, it should attach the
listener to
[jira] [Commented] (TOBAGO-866) Add capabilities and update browsers in UserAgent class
[ https://issues.apache.org/jira/browse/TOBAGO-866?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774616#comment-13774616 ] Udo Schnurpfeil commented on TOBAGO-866: placeholder was added as capability, but it seems to be a better strategy to write user-agent independent code, and make the differences on the client. Add capabilities and update browsers in UserAgent class --- Key: TOBAGO-866 URL: https://issues.apache.org/jira/browse/TOBAGO-866 Project: MyFaces Tobago Issue Type: Improvement Components: Core, Themes Reporter: Udo Schnurpfeil Assignee: Bernd Bohmann The UserAgent should say, e. g. it supports placeholder. Also updating the browser list. -- 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
[jira] [Resolved] (TOBAGO-866) Add capabilities and update browsers in UserAgent class
[ https://issues.apache.org/jira/browse/TOBAGO-866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Udo Schnurpfeil resolved TOBAGO-866. Resolution: Fixed Add capabilities and update browsers in UserAgent class --- Key: TOBAGO-866 URL: https://issues.apache.org/jira/browse/TOBAGO-866 Project: MyFaces Tobago Issue Type: Improvement Components: Core, Themes Reporter: Udo Schnurpfeil Assignee: Bernd Bohmann Fix For: 1.5.11, 2.0.0-alpha-2, 2.0.0 The UserAgent should say, e. g. it supports placeholder. Also updating the browser list. -- 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
[jira] [Commented] (MYFACES-3733) Implement vdl.createComponent(...)
[
https://issues.apache.org/jira/browse/MYFACES-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774601#comment-13774601
]
Leonardo Uribe commented on MYFACES-3733:
-
I have made some junit test for this one and there was a problem with the
optimization done in MYFACES-3774. The problem was caused because the facetName
is not properly set, causing a duplicate id exception.
But I tried the hack using binding attribute and nested composite components
(org.apache.myfaces.view.facelets.pss.acid.AcidMyFacesRequestTestCase.testComponentBindingVDL_2())
and it works well. Note that test is designed to run with multiple state
saving configurations (pss enabled, no pss, always refresh, ...).
Take a look at
http://svn.apache.org/repos/asf/myfaces/core/trunk/impl/src/test/java/org/apache/myfaces/view/facelets/pss/acid/managed/ComponentBindingVDLBean2.java
To see how it works.
facelets.REFRESH_PERIOD attribute is meant to be used on development time, not
in production time. So, it is expected in some cases to cause problems, that
after set it to -1 or set the environment in production mode just dissapear. I
still have to investigate if there are chances to fix the problem somehow,
because in this case, the facelet is compiled inline, so maybe the problem is
there, the refresh algorithm assume the same facelet refresh the tree each time.
I consider the solution we have implemented is good enough to use it (just set
facelets.REFRESH_PERIOD to -1), but there is still work to do in this part, and
solve all possible scenarios will take some time anyway.
Implement vdl.createComponent(...)
--
Key: MYFACES-3733
URL: https://issues.apache.org/jira/browse/MYFACES-3733
Project: MyFaces Core
Issue Type: Task
Components: JSR-344
Reporter: Leonardo Uribe
This is a difficult issue to do in JSF 2.2 . I have spent a long time to
solve this one, and given the complexity involved and since there is no
documentation anywhere about how this should work, I'll let the required
explanation here.
The idea is allow to include generated vdl fragments into pages
programatically. This includes normal components, composite components or
just fragments of markup. The method signature is this:
public UIComponent createComponent(FacesContext context, String taglibURI,
String tagName, MapString,Object attributes)
Some valid examples of this are:
// Normal component
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/html;,
outputText, attributes);
// Composite component
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/composite/testComposite;,
dynComp_1, attributes);
// Dynamic include
MapString, Object attributes = new HashMapString, Object();
attributes.put(src, /addSimpleIncludeVDL_1_1.xhtml);
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/facelets;,
include, attributes);
The javadoc does not suggest the dynamic include is valid, but I think users
expect these kind of stuff work.
Theoretically it sounds like something easy to do, but unfortunately it is
not. The reasons why this is so are:
- Facelets algorithm wraps html markup into UILeaf instances, which is a
special transient component. UILeaf instances are never saved or restored
from the component tree, but in some points of the algorithm (restore view
and before render response when vdl.buildView() is called) the component tree
is updated, adding or removing UILeaf instances.
- Facelets has an algorithm that require id generation to be stable,
otherwise a duplicate id exception may arise. A lot of effort has been done
to organize this part, and the current solution works very well. But in this
case, we need to generate unique ids that can be refreshed somehow.
- Facelets algorithm has an special logic to deal with dynamic sections like
the ones generated by c:if or
ui:include src=#{...} . Add facelets sections programatically could make
this algorithm fail, removing sections that should be.
- Facelets PSS algorithm needs to be taken into account too. The listener
that is used to register programmatic changes on the tree in
DefaultFaceletsStateManagementStrategy uses ComponentSupport.MARK_CREATED to
identify which component belongs to the component tree and which one was
added by outside. Add facelets sections programatically could make this
algorithm fail, because it could assume some sections of the tree does not
need to be saved fully, even if that's not true.
The issue in the spec is this:
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-611
At start the idea was to export FaceletFactory directly, but I told to the EG
that it was a bad
[jira] [Commented] (TOBAGO-1283) New attribute placeholder for input fields
[ https://issues.apache.org/jira/browse/TOBAGO-1283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774714#comment-13774714 ] Hudson commented on TOBAGO-1283: FAILURE: Integrated in tobago-1.5.x #180 (See [https://builds.apache.org/job/tobago-1.5.x/180/]) TOBAGO-1283: New attribute placeholder for input fields (lofwyr: http://svn.apache.org/viewvc/?view=revrev=1525631) * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUIInput.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUITextarea.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/component/AbstractUITime.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/DateTagDeclaration.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/InTagDeclaration.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/component/TextareaTagDeclaration.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/main/java/org/apache/myfaces/tobago/internal/taglib/declaration/HasPlaceholder.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-core/src/main/java/org/apache/myfaces/tobago/renderkit/html/HtmlAttributes.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-example/tobago-example-demo/src/main/java/org/apache/myfaces/tobago/example/demo/overview/OverviewController.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-example/tobago-example-demo/src/main/webapp/content/01-basic/basic.xhtml * /myfaces/tobago/branches/tobago-1.5.x/tobago-extension/tobago-taglib-extension/src/main/java-jsf-1.2/org/apache/myfaces/tobago/internal/taglib/extension/DateExtensionTag.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-extension/tobago-taglib-extension/src/main/java-jsf-1.2/org/apache/myfaces/tobago/internal/taglib/extension/InExtensionTag.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-theme/tobago-theme-scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/InRenderer.java * /myfaces/tobago/branches/tobago-1.5.x/tobago-theme/tobago-theme-scarborough/src/main/resources/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/style/style.css * /myfaces/tobago/branches/tobago-1.5.x/tobago-theme/tobago-theme-standard/src/main/resources/org/apache/myfaces/tobago/renderkit/html/standard/standard/script/tobago-in.js New attribute placeholder for input fields Key: TOBAGO-1283 URL: https://issues.apache.org/jira/browse/TOBAGO-1283 Project: MyFaces Tobago Issue Type: New Feature Components: Core, Themes Reporter: Udo Schnurpfeil Assignee: Udo Schnurpfeil Fix For: 1.5.11, 2.0.0-alpha-2, 2.0.0 The new attribute placeholder should display a short text in the input field, that describes the meaning of this field. This attribute is new in HTML 5, but should also work in the other supported browsers in Tobago. -- 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
[jira] [Commented] (MYFACES-3733) Implement vdl.createComponent(...)
[
https://issues.apache.org/jira/browse/MYFACES-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13774703#comment-13774703
]
Leonardo Uribe commented on MYFACES-3733:
-
Checking the code I have found that the way how the refreshing algorithm works
affects the order of the components. The refresh algorithm removes and adds the
components in each refresh to include in the right spot added components by the
effect of c:if, ui:include src=#{...} and so on. In the case of a
programatically added component, the component should be let in the same spot,
not removed or added, but things get more complicated when you start to make
variants (nested composite components, programatically added normal components
and composite components). The most complex case is when there is a chain or
PostAddToViewEvent and dynamic creation listeners, because in that case the
composite component content is deferred on the listener.
Implement vdl.createComponent(...)
--
Key: MYFACES-3733
URL: https://issues.apache.org/jira/browse/MYFACES-3733
Project: MyFaces Core
Issue Type: Task
Components: JSR-344
Reporter: Leonardo Uribe
This is a difficult issue to do in JSF 2.2 . I have spent a long time to
solve this one, and given the complexity involved and since there is no
documentation anywhere about how this should work, I'll let the required
explanation here.
The idea is allow to include generated vdl fragments into pages
programatically. This includes normal components, composite components or
just fragments of markup. The method signature is this:
public UIComponent createComponent(FacesContext context, String taglibURI,
String tagName, MapString,Object attributes)
Some valid examples of this are:
// Normal component
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/html;,
outputText, attributes);
// Composite component
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/composite/testComposite;,
dynComp_1, attributes);
// Dynamic include
MapString, Object attributes = new HashMapString, Object();
attributes.put(src, /addSimpleIncludeVDL_1_1.xhtml);
UIComponent component = vdl.createComponent(facesContext,
http://java.sun.com/jsf/facelets;,
include, attributes);
The javadoc does not suggest the dynamic include is valid, but I think users
expect these kind of stuff work.
Theoretically it sounds like something easy to do, but unfortunately it is
not. The reasons why this is so are:
- Facelets algorithm wraps html markup into UILeaf instances, which is a
special transient component. UILeaf instances are never saved or restored
from the component tree, but in some points of the algorithm (restore view
and before render response when vdl.buildView() is called) the component tree
is updated, adding or removing UILeaf instances.
- Facelets has an algorithm that require id generation to be stable,
otherwise a duplicate id exception may arise. A lot of effort has been done
to organize this part, and the current solution works very well. But in this
case, we need to generate unique ids that can be refreshed somehow.
- Facelets algorithm has an special logic to deal with dynamic sections like
the ones generated by c:if or
ui:include src=#{...} . Add facelets sections programatically could make
this algorithm fail, removing sections that should be.
- Facelets PSS algorithm needs to be taken into account too. The listener
that is used to register programmatic changes on the tree in
DefaultFaceletsStateManagementStrategy uses ComponentSupport.MARK_CREATED to
identify which component belongs to the component tree and which one was
added by outside. Add facelets sections programatically could make this
algorithm fail, because it could assume some sections of the tree does not
need to be saved fully, even if that's not true.
The issue in the spec is this:
https://java.net/jira/browse/JAVASERVERFACES_SPEC_PUBLIC-611
At start the idea was to export FaceletFactory directly, but I told to the EG
that it was a bad idea by multiple reasons (That's a Pandora's Box). See:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-11/message/91
This previous message is useful too:
https://java.net/projects/javaserverfaces-spec-public/lists/jsr344-experts/archive/2012-06/message/18
After thinking and trying different strategies to overcome this issue, I
finally found the following solution:
- Use the compiler for generate a custom Facelet inline or on the fly. It
is not necessary to create an
xml document and then parse it, just generate the Tag class and pass it to
the compiler to generate an
Abstract Syntax Tree (AST),
