[jira] [Comment Edited] (MYFACES-3879) Passthrough attributes for f:selectItem and f:selectItems should be rendered by associated components
[
https://issues.apache.org/jira/browse/MYFACES-3879?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13995038#comment-13995038
]
Sebastian Mellmann edited comment on MYFACES-3879 at 5/12/14 12:42 PM:
---
My code looks like this:
http://pastebin.com/Ym4wLbbW
I've already added the pt:title attribute as you can see, but it threw an
exception:
javax.faces.view.facelets.FaceletException: Error Parsing: Error Traced[line:
152] Präfix pt für Attribut pt:title, das mit Elementtyp f:selectItems
verknüpft ist, ist nicht gebunden.
Am I missing something here?
was (Author: mellmann):
My code looks like this:
h:selectOneMenu id=selApplicationSelectedItemName
value=#{searchController.currentUniqueApplicationName}
title=#{app.description}
valueChangeListener=#{searchController.applicationChangeListener}
f:selectItems value=#{searchRoleController.applicationDtos} var=app
itemLabel=#{app.displayName} itemDescription=#{app.description}
itemValue=#{app.uniqueName} pt:title=#{app.description} /
/h:selectOneMenu
I've already added the pt:title attribute as you can see, but it threw an
exception:
javax.faces.view.facelets.FaceletException: Error Parsing: Error Traced[line:
152] Präfix pt für Attribut pt:title, das mit Elementtyp f:selectItems
verknüpft ist, ist nicht gebunden.
Am I missing something here?
Passthrough attributes for f:selectItem and f:selectItems should be rendered
by associated components
-
Key: MYFACES-3879
URL: https://issues.apache.org/jira/browse/MYFACES-3879
Project: MyFaces Core
Issue Type: Bug
Components: JSR-344
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
Fix For: 2.2.3
Reported by Sebastian Mellmann:
Hello everyone,
I have just run into a problem where the 'title' attribut is not being
rendered using the h:selectOneMenu tag.
Used version is MyFaces Core 2.2.2
I had a look into the source code and the following changes seem to fix the
problem:
Class: org.apache.myfaces.shared.renderkit.html.HtmlRendererUtils
Method: renderSelectOptions (Line 521)
Code changes listed on pastebin: http://pastebin.com/SHLKxi5H
Can someone confirm this, because I wanted to ask the ML first before opening
an issue via Apache JIRA for MyFaces?!
Thanks and regards,
Sebastian
The problem is not the title fix, is that passthrough attributes must work
for components created by effect of f:selectItem and f:selectItems. There is
a line in the renderkit javadoc of javax.faces.SelectMany/javax.faces.Listbox
that says:
... In both the case of the option element or the optgroup
element, the implementation must pass the UISelectItem or
UISelectItems corresponding to the SelectItem bean to the call to
ResponseWriter.startElement(). ...
I tested against Mojarra 2.2.6 and it is correct. But Mojarra has a bug in
this part, because components like h:selectManyCheckbox or h:selectOneRadio
should work just the same, but in this case a set of input html tags are
rendered instead. It is clear the renderkit javadoc reference how the
option is rendered, so we should follow the spirit of the spec in this
part, which is allow to define passthrough attributes for f:selectItem and
f:selectItems.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (MYFACES-3889) Handling PostConstruct annotations - wrong order : under wildfly-8.0.0.Final
hamid AGHAZZAF created MYFACES-3889: --- Summary: Handling PostConstruct annotations - wrong order : under wildfly-8.0.0.Final Key: MYFACES-3889 URL: https://issues.apache.org/jira/browse/MYFACES-3889 Project: MyFaces Core Issue Type: Bug Environment: wildfly-8.0.0.Final, Spring 3.1.0, myfaces 2.1.12 Reporter: hamid AGHAZZAF Priority: Blocker The specification states that managed bean methods annotated with @PostConstruct have to be called after the object is initialized and after dependency injection is performed. However, MyFaces calls those methods after the bean instance is created but before dependency injection is performed. This issue was resolved for tomcat7 server (https://issues.apache.org/jira/browse/MYFACES-1761). But remain with WildFly 8.0.Final . Bellow the list of third party artifacts used with their versions : activation-1.1.jar joda-time-2.3.jar velocity-1.6.2.jar aopalliance-1.0.jarjrobin-1.5.9.jar xml-apis-1.0.b2.jar aspectjrt-1.6.12.jar jsr305-1.3.9.jar xmlbeans-2.3.0.jar aspectjtools-1.6.2.jar jstl-1.2.jar aspectjweaver-1.6.11.jar junit-3.8.1.jar atmosphere-runtime-2.0.1.jar log4j-1.2.12.jar avalon-framework-4.1.3.jar logback-classic-0.9.30.jar bcmail-jdk14-1.38.jar logback-core-0.9.30.jar bcmail-jdk14-138.jar logkit-1.0.1.jar bcprov-jdk14-1.38.jar mail-1.4.jar bcprov-jdk14-138.jar myfaces-api-2.1.12.jar bctsp-jdk14-1.38.jar myfaces-impl-2.1.12.jar bsh-2.0b4.jar oro-2.0.8.jar castor-1.2.jar poi-3.7.jar cglib-3.0.jar poi-ooxml-3.7.jar commons-beanutils-1.8.2.jar poi-ooxml-schemas-3.7.jar commons-codec-1.3.jar primefaces-4.0.jar commons-collections-3.2.jar primefaces-extensions-0.7.1.jar commons-dbcp-1.2.2.jar servlet-api-2.3.jar commons-digester-1.8.jar slf4j-api-1.6.2.jar commons-fileupload-1.3.1.jar slf4j-log4j12-1.6.1.jar commons-io-2.4.jar smoothness-1.0.10.jar commons-lang-2.2.jar snakeyaml-1.6.jar commons-lang3-3.1.jar spring-aop-3.1.0.RELEASE.jar commons-logging-1.1.jar spring-asm-3.1.0.RELEASE.jar commons-pool-1.3.jar spring-aspects-3.1.0.RELEASE.jar dom4j-1.6.1.jar spring-beans-3.1.0.RELEASE.jar geronimo-stax-api_1.0_spec-1.0.jar spring-binding-2.3.2.RELEASE.jar groovy-all-2.0.1.jar spring-context-3.1.0.RELEASE.jar gsfar-base-0.0.8-SNAPSHOT.jar spring-context-support-3.1.0.RELEASE.jar gsfar-core-0.0.8-SNAPSHOT.jar spring-core-3.1.0.RELEASE.jar gsfar-domain-0.0.8-SNAPSHOT.jar spring-data-commons-1.5.2.RELEASE.jar gson-2.2.2.jar spring-data-commons-core-1.4.0.RELEASE.jar guava-12.0.jar spring-data-envers-0.1.0.RELEASE.jar hibernate-commons-annotations-4.0.1.Final.jar spring-data-jpa-1.3.4.RELEASE.jar hibernate-core-4.1.7.Final.jar spring-expression-3.2.1.RELEASE.jar hibernate-entitymanager-4.1.7.Final.jar spring-faces-2.3.2.RELEASE.jar hibernate-envers-4.1.7.Final.jar spring-integration-core-2.2.2.RELEASE.jar hibernate-jpa-2.0-api-1.0.1.Final.jar spring-integration-jdbc-2.2.2.RELEASE.jar hsqldb-1.8.0.7.jar spring-jdbc-3.1.0.RELEASE.jar itext-2.1.7.jar spring-js-2.3.2.RELEASE.jar jackson-annotations-2.1.4.jar spring-js-resources-2.3.2.RELEASE.jar jackson-core-2.1.4.jar
[jira] [Resolved] (MYFACES-3841) h:inputTextArea removes leading newline
[ https://issues.apache.org/jira/browse/MYFACES-3841?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3841. - Resolution: Fixed Fix Version/s: 2.2.4 2.1.16 Assignee: Leonardo Uribe The custom param name for myfaces was added as org.apache.myfaces.addNewLineAtStart h:inputTextArea removes leading newline - Key: MYFACES-3841 URL: https://issues.apache.org/jira/browse/MYFACES-3841 Project: MyFaces Core Issue Type: Bug Components: JSR-127 Affects Versions: 2.0.19, 2.1.13 Reporter: Michael Kaufmann Assignee: Leonardo Uribe Fix For: 2.1.16, 2.2.4 h:inputTextArea removes one leading newline. This bug has recently been fixed in Mojarra, but the same bug is also present in Apache MyFaces. Please consider adding a similar bugfix to Apache MyFaces. Reference: https://java.net/jira/browse/JAVASERVERFACES-2858 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Comment Edited] (MYFACES-3005) Only send Flash cookie if needed
[ https://issues.apache.org/jira/browse/MYFACES-3005?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13992779#comment-13992779 ] Dennis Kieselhorst edited comment on MYFACES-3005 at 5/8/14 2:22 PM: - Just to let others know, the name of the config param is: org.apache.myfaces.FLASH_SCOPE_DISABLED was (Author: deki): Can somebody tell me, what happened to that context param? I tried with 2.2.3 and it has no effect. It's not in the docs either. Only send Flash cookie if needed Key: MYFACES-3005 URL: https://issues.apache.org/jira/browse/MYFACES-3005 Project: MyFaces Core Issue Type: Improvement Components: JSR-314 Affects Versions: 2.0.3 Reporter: Jakob Korherr Assignee: Ganesh Jung Fix For: 2.0.5 As pointed out by Ganesh on the mailing list [1], we do not always have to send the Flash cookie oam.Flash.RENDERMAP.TOKEN (e.g. when there is no data in the Flash scope). [1] http://old.nabble.com/oam.Flash.RENDERMAP.TOKEN-ts30491897.html -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (MYFACES-3890) Component added using vdl.createComponent(...) is removed when javax.faces.FACELETS_REFRESH_PERIOD is not -1
Leonardo Uribe created MYFACES-3890: --- Summary: Component added using vdl.createComponent(...) is removed when javax.faces.FACELETS_REFRESH_PERIOD is not -1 Key: MYFACES-3890 URL: https://issues.apache.org/jira/browse/MYFACES-3890 Project: MyFaces Core Issue Type: Bug Components: JSR-344 Affects Versions: 2.2.3 Reporter: Leonardo Uribe Assignee: Leonardo Uribe Priority: Minor On the way of implement MYFACES-3733 Implement vdl.createComponent(...), it was noticed that when javax.faces.FACELETS_REFRESH_PERIOD config param is different from -1, the programmatically added component dissapear after a postback. The problem happens because the code in vdl.createComponent(...) does an inline compilation of a facelet instance of the component, but the original algorithm does not consider that case. Instead, all facelets are stored in a structure and the refresh period is used to decide when a facelet instance needs to be reloaded. The inline compilation makes a new facelet instance to be created every time the component needs to be created or refreshed. The algorithm done in this part is ok, the only thing that needs to be done is disable the refresh on the sections that are compiled inline. Unfortunately things are not so simple, because for example in a composite component there are two facelets involved: one that makes the inline compilation and the other that renders the component and is reused over and over again. So, we need to review the algorithm to be sure everything is ok. -- This message was sent by Atlassian JIRA (v6.2#6252)
Re: [proposal] A new module for improved JSF-MVC inside MyFaces Project
How will a href=#{ma:getLink('mypage?action=exportExcel')}Export excel/a
work when ViewAction is not defined as
@ViewAction(value=/sayhello.xhtml,
params= {
@ViewParam(name=action,
expectedValue=exportExcel)
})
public void method3(@ViewParam String param1,
@ViewParam(someOther) Integer param2)
{
but as @ViewAction(/section1/*, action=exportExcel)
Is the latter not supported now?
facelet function getLink for action processing is not a bad idea.
On Sunday, May 11, 2014 11:52 PM, Leonardo Uribe lu4...@gmail.com wrote:
Hi
Ok, I think the idea about @ViewAction and @ViewParam is clear, I have
implemented a fast prototype and it works well, there is a lot of things we
can do for improvement, however we should focus the attention in other
areas so we can give the module a better structure.
The next thing we need is how to combine javascript with JSF, specifically
in cases like this:
input id=search/
script type=text/javascript
$('#search').autocomplete({
source: #{some EL that return a link to an action goes here}
});
/script
The idea is provide an input box and then write some javascript lines to
make the component an autocomplete box, but the problem is we need to provide
a URL that can be used to retrieve the values to fill the box. In my opinion,
mix EL and javascript is the best in these cases, but things get complex
quickly when you need to provide parameters and so on. So I would like to
propose these facelet functions (better with examples):
a href=#{ma:getLink('mypage?action=exportExcel')}Export excel/a
and
ma:defineLink id=mylink
f:param name=action value=renderMessage/
/ma:defineLink
a href=#{ma:getLinkFrom('mylink')}Render url from EL expression/a
#{ma:getLink(...)} work just like h:link but receives the outcome as parameter.
The function append the request path and the client window id, so the final
generated link will be something like this:
http://localhost:8080/myfaces-mvc-examples/sayhello.jsf?id=5jfwid=1di8uhetf9action=exportExcel
#{ma:getLinkFrom(...)} just inject the link from a component that works just
like h:link but it is just a wrapper, so the user can customize the parameters,
when the EL function is called, the link is rendered taking the parameters
in the definition. The outcome by default is the page itself.
Please note this proposal is something different from the one that suggest to
create the link just pointing to the method in the bean like
#{ma:getLink('mybean', 'mymethod', params)}. After thinking about it, the
problem with that approach is the difficulty to do the match between the link
to generate and the method. EL does not consider annotated methods, so it is
not possible to scan the annotations from the EL unless you do a bypass over
CDI.
I think the approach proposed is something simple to understand, and it has
the advantage that you can isolate the declaration of the link from the
rendering, so the final javascript code will be easier to read.
Finally we need something for the POST case, so the idea is append something
like this:
form action=#{ma:encodeActionURL()}
method=post
enctype=application/x-www-form-urlencoded
/form
#{ma:encodeActionURL()} do what h:form does for encode the action url. Then,
it is responsibility of the user to provide the view state and client window
token in the request as data, so the postback can be processed properly.
In this case, the idea is the view scope will be available, but the component
tree state will not be updated when POST goes back to the client, so any
changes on the component tree in the action will be ignored.
JSF does not make any difference between GET and POST, so viewParam will
work just the same. What defines a postback in JSF is if the view state
field is in the request or not. Theoretically, use #{ma:getLink(...)} should
work too, but I think there are different cases.
There is a contradiction in this case. Send a POST, provide the view state
token, do not restore the view but restore the view scope bean. The problem is
after you make changes on the view scope beans you need to save those changes,
and that could mean update the view state token, even if the beans are stored
in the server (remember the beans can be serialized, for example in a cluster).
If we take a look at the proposed goals:
1) possibility to use a normal JSF lifecycle for the first GET request
2) allow action handling and custom response for POST actions
3) normal action handling like in asp.net MVC + a EL util function to
generate the action URL
we cannot really make number 2 exactly as POST actions. It doesn't fit because
... JSF’s core architecture is designed to be independent of specific
protocols and markup.
Really the problem proposed in number 2 is not simple and we should analyze it
carefully. In which cases do we really need that
[jira] [Resolved] (MYFACES-3880) Allow view state to be rendered in the beginning of the form
[ https://issues.apache.org/jira/browse/MYFACES-3880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe resolved MYFACES-3880. - Resolution: Fixed Fix Version/s: 2.2.4 Assignee: Leonardo Uribe Allow view state to be rendered in the beginning of the form Key: MYFACES-3880 URL: https://issues.apache.org/jira/browse/MYFACES-3880 Project: MyFaces Core Issue Type: New Feature Affects Versions: 2.2.2 Reporter: Felipe Jaekel Assignee: Leonardo Uribe Priority: Minor Fix For: 2.2.4 As discussed on the user list, Leonardo Uribe asked me to create a ticket for this feature. The idea is to allow the view state to be rendered in the beginning of the form to avoid a ViewExpiredException in case of a postback on a page that isn't completely loaded yet. Details: http://markmail.org/search/?q=view%20list%3Aorg.apache.myfaces.users#query:view%20list%3Aorg.apache.myfaces.users%20order%3Adate-backward+page:1+mid:uqp2l6y2iwlmwbso+state:results As a workaround I'm using PrimeFaces deferred loading. It hides the form components while the page isn't fully loaded. http://www.primefaces.org/showcase/ui/outputPanel.jsf Thanks -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (MYFACES-3886) SerializedViewCollection does not update it's _keys list when _serializedViews contains key
[ https://issues.apache.org/jira/browse/MYFACES-3886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated MYFACES-3886: Resolution: Fixed Status: Resolved (was: Patch Available) I have checked the solution and it is ok, I just committed a small modification in the removal, but the result is the same. The test cases does not show any other problem, the precedence remains without changes and the algorithm itself does not require anything else. Thanks to Adam Balazs for provide this patch. SerializedViewCollection does not update it's _keys list when _serializedViews contains key --- Key: MYFACES-3886 URL: https://issues.apache.org/jira/browse/MYFACES-3886 Project: MyFaces Core Issue Type: Bug Components: General Affects Versions: 2.2.2 Environment: PrimeFaces 4.0.12. Reporter: Adam Balazs Assignee: Leonardo Uribe Fix For: 2.2.4 Attachments: SerializedViewCollection.java.patch When I use DialogFramework (of PrimeFaces), it's adds a new view to the session every time. The problem is that when I post an AJAX request to the original view, the _keys list is not updated, only the view get updated in the _serializedViews map. After I reach the limit defined with the org.apache.myfaces.NUMBER_OF_VIEWS_IN_SESSION context-param, MyFaces gets the first element in the _keys list (which is the container view) - assuming that this is the oldest view in the session - and remove the corresponding view from the _serializedViews map by the key. But clearly it is not, as I already posted some AJAX requests to it. I think the optimal behavior would be the following: when a view gets an ajax request the code should remove the the key from the _keys list and than add it as a last element. The related class is org.apache.myfaces.application.viewstate.SerializedViewCollection at the if condition started at line 87. My question is if it is an intended behavior or if it's a bug. -- This message was sent by Atlassian JIRA (v6.2#6252)
