[JBoss JIRA] (RF-12523) a4j:commandButton generates duplicated context path using a resource value expression within image attribute
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12523?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-12523:
---------------------------------
[~checkoff], what's the purpose of specifying @value attribute?
Documentation states that only @image attribute is necessary to specify URL:
http://docs.jboss.org/richfaces/latest_4_X/vdldoc/a4j/commandButton.html
> a4j:commandButton generates duplicated context path using a resource value expression within image attribute
> ------------------------------------------------------------------------------------------------------------
>
> Key: RF-12523
> URL: https://issues.jboss.org/browse/RF-12523
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: resource handling
> Affects Versions: 4.2.2.Final, 4.3.0.M1
> Environment: Windows 7 Professional, JBoss AS 6.1.0.Final, Mojarra 2.1.7
> Reporter: Andreas Owczarek
> Assignee: Pavol Pitonak
> Labels: ajax4jsf
>
> a4j:commandButton produces an extra context path prefix for the image resource path, when it is used with the value expression {code}#{resource['library:file']}{code} for the image attribute.
> {code:xml|title=Example code}
> <a4j:commandButton image="#{resource['icons:icon.gif']}" value="#{resource['icons:icon.gif']}"/>
> {code}
> {code:xml|title=Generated Result code}
> <input type="image" alt="/com.example.my.context.path/faces/javax.faces.resource/icon.gif?ln=icons" src="/com.example.my.context.path/com.example.my.context.path/faces/javax.faces.resource/icon.gif?ln=icons" value="/com.example.my.context.path/faces/javax.faces.resource/icon.gif?ln=icons" onclick="RichFaces.ajax("j_idt76",event,{"incId":"1"} );return false;" name="j_idt76" id="j_idt76">
> {code}
> The generated code show the correct value for the expression within the generated button label, but the image could not be located correctly because of the wrong generated image resource path.
--
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
11 years, 11 months
[JBoss JIRA] (RF-12523) a4j:commandButton generates duplicated context path using a resource value expression within image attribute
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12523?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-12523:
---------------------------------
This issue is not very likely caused by resource optimization, let's write fundamental test to reproduce it.
> a4j:commandButton generates duplicated context path using a resource value expression within image attribute
> ------------------------------------------------------------------------------------------------------------
>
> Key: RF-12523
> URL: https://issues.jboss.org/browse/RF-12523
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: resource handling
> Affects Versions: 4.2.2.Final, 4.3.0.M1
> Environment: Windows 7 Professional, JBoss AS 6.1.0.Final, Mojarra 2.1.7
> Reporter: Andreas Owczarek
> Assignee: Pavol Pitonak
> Labels: ajax4jsf
>
> a4j:commandButton produces an extra context path prefix for the image resource path, when it is used with the value expression {code}#{resource['library:file']}{code} for the image attribute.
> {code:xml|title=Example code}
> <a4j:commandButton image="#{resource['icons:icon.gif']}" value="#{resource['icons:icon.gif']}"/>
> {code}
> {code:xml|title=Generated Result code}
> <input type="image" alt="/com.example.my.context.path/faces/javax.faces.resource/icon.gif?ln=icons" src="/com.example.my.context.path/com.example.my.context.path/faces/javax.faces.resource/icon.gif?ln=icons" value="/com.example.my.context.path/faces/javax.faces.resource/icon.gif?ln=icons" onclick="RichFaces.ajax("j_idt76",event,{"incId":"1"} );return false;" name="j_idt76" id="j_idt76">
> {code}
> The generated code show the correct value for the expression within the generated button label, but the image could not be located correctly because of the wrong generated image resource path.
--
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
11 years, 11 months
[JBoss JIRA] (RF-12655) Selected components doesn't provide tabindex: commandButton/Link, select
by Lukáš Fryč (JIRA)
Lukáš Fryč created RF-12655:
-------------------------------
Summary: Selected components doesn't provide tabindex: commandButton/Link, select
Key: RF-12655
URL: https://issues.jboss.org/browse/RF-12655
Project: RichFaces
Issue Type: Feature Request
Security Level: Public (Everyone can see)
Components: component-input
Affects Versions: 4.3.0.M3
Reporter: Lukáš Fryč
Following components should definitely have tabindex attribute:
* a4j:commandButton
* a4j:commandLink
* rich:select
There is complete list of components and status which provides tabindex and which doesn't: RFPL-2502
--
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
11 years, 11 months
[JBoss JIRA] (RF-12619) @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12619?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč resolved RF-12619.
-----------------------------
Labels: a4j:commandbutton cdi facelets seamfaces viewscoped (was: a4j:commandbutton cdi facelets seamfaces viewscoped waiting_on_user)
Resolution: Duplicate Issue
> @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
> -----------------------------------------------------------------------
>
> Key: RF-12619
> URL: https://issues.jboss.org/browse/RF-12619
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.0.M2
> Environment: Windows, JDK 1.7.0_09, Glassfish 3.1.2.2 with Mojarra 2.1.14 (at least >= 2.1.8), RF 4.3.0 M2 (also on RF 4.2.x), Weld 1.1.8 and SeamFaces 3.1.0.
> Reporter: Fab Mars
> Assignee: Lukáš Fryč
> Labels: a4j:commandbutton, cdi, facelets, seamfaces, viewscoped
> Attachments: TestViewScope.zip
>
>
> Here is a weird case I found after updating a project of mine from JSF 1.2 & RF 3.x to JSF 2.1 and RF 4.2.3/4.3.0M2. See attached project.
> On a part of the page which is into a Facelets insert, I can click on a <a4j:commandButton/> to trigger the creation of some entity instance and dynamically display another form associated to that entity in another part of the page. So, there are 2 forms on the screen, one for the creation button, another one to edit the entity, both are always displayed but the content of the latter isn't rendered until the entity exists. The page actions are held by some backing bean which also contains the form.
> From the second form, I can submit the entity once updated. The buttons are <h:commandButton/> this time and the action returns null so I can stay on the same view and keep on working.
> Back with RF 3.x, I used the keepAlive tag to maintain the page's backing bean along the page life. All worked fine. After JSF 2.1 and RF 4 and CDI were released, I intended on using @ViewScoped instead. Naturally I had to add SeamFaces so my @ViewScoped beans were actually CDI-managed, and I updated my whole codebase.
> Well, now, when the a4j creation button is used, the form dynamically displays all right BUT when I try to submit the second form, my @ViewScoped bean vanishes (pbly the viewMap vanishes entirely).
> However, if I use <h:commandButton><f:ajax/></h:commandButton> for the creation instead, everything works fine. Which leads me to believe there is a bug/regression from RF3.3 on a4j:command* components (maybe a4j:ajax/a4j:poll, didn't check) when used in a full CDI environment.
--
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
11 years, 11 months
[JBoss JIRA] (RF-12619) @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
by Lukáš Fryč (JIRA)
[ https://issues.jboss.org/browse/RF-12619?page=com.atlassian.jira.plugin.s... ]
Lukáš Fryč commented on RF-12619:
---------------------------------
Awesome, thanks for checking, Fab.
Closing as duplicate of RF-12442.
The fix will be released with {{4.3.0.M3}}.
> @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
> -----------------------------------------------------------------------
>
> Key: RF-12619
> URL: https://issues.jboss.org/browse/RF-12619
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.0.M2
> Environment: Windows, JDK 1.7.0_09, Glassfish 3.1.2.2 with Mojarra 2.1.14 (at least >= 2.1.8), RF 4.3.0 M2 (also on RF 4.2.x), Weld 1.1.8 and SeamFaces 3.1.0.
> Reporter: Fab Mars
> Assignee: Lukáš Fryč
> Labels: a4j:commandbutton, cdi, facelets, seamfaces, viewscoped, waiting_on_user
> Attachments: TestViewScope.zip
>
>
> Here is a weird case I found after updating a project of mine from JSF 1.2 & RF 3.x to JSF 2.1 and RF 4.2.3/4.3.0M2. See attached project.
> On a part of the page which is into a Facelets insert, I can click on a <a4j:commandButton/> to trigger the creation of some entity instance and dynamically display another form associated to that entity in another part of the page. So, there are 2 forms on the screen, one for the creation button, another one to edit the entity, both are always displayed but the content of the latter isn't rendered until the entity exists. The page actions are held by some backing bean which also contains the form.
> From the second form, I can submit the entity once updated. The buttons are <h:commandButton/> this time and the action returns null so I can stay on the same view and keep on working.
> Back with RF 3.x, I used the keepAlive tag to maintain the page's backing bean along the page life. All worked fine. After JSF 2.1 and RF 4 and CDI were released, I intended on using @ViewScoped instead. Naturally I had to add SeamFaces so my @ViewScoped beans were actually CDI-managed, and I updated my whole codebase.
> Well, now, when the a4j creation button is used, the form dynamically displays all right BUT when I try to submit the second form, my @ViewScoped bean vanishes (pbly the viewMap vanishes entirely).
> However, if I use <h:commandButton><f:ajax/></h:commandButton> for the creation instead, everything works fine. Which leads me to believe there is a bug/regression from RF3.3 on a4j:command* components (maybe a4j:ajax/a4j:poll, didn't check) when used in a full CDI environment.
--
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
11 years, 11 months
[JBoss JIRA] (RF-12619) @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
by Fab Mars (JIRA)
[ https://issues.jboss.org/browse/RF-12619?page=com.atlassian.jira.plugin.s... ]
Fab Mars edited comment on RF-12619 at 12/11/12 8:00 PM:
---------------------------------------------------------
I confirm. It's working in my bigger project in both cases (h:action+f:ajax and a4j:action) now.
Thank you.
was (Author: fabmars):
I confirm. It's working in both cases (h:action+f:ajax and a4j:action) now.
Thank you.
> @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
> -----------------------------------------------------------------------
>
> Key: RF-12619
> URL: https://issues.jboss.org/browse/RF-12619
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.0.M2
> Environment: Windows, JDK 1.7.0_09, Glassfish 3.1.2.2 with Mojarra 2.1.14 (at least >= 2.1.8), RF 4.3.0 M2 (also on RF 4.2.x), Weld 1.1.8 and SeamFaces 3.1.0.
> Reporter: Fab Mars
> Assignee: Lukáš Fryč
> Labels: a4j:commandbutton, cdi, facelets, seamfaces, viewscoped, waiting_on_user
> Attachments: TestViewScope.zip
>
>
> Here is a weird case I found after updating a project of mine from JSF 1.2 & RF 3.x to JSF 2.1 and RF 4.2.3/4.3.0M2. See attached project.
> On a part of the page which is into a Facelets insert, I can click on a <a4j:commandButton/> to trigger the creation of some entity instance and dynamically display another form associated to that entity in another part of the page. So, there are 2 forms on the screen, one for the creation button, another one to edit the entity, both are always displayed but the content of the latter isn't rendered until the entity exists. The page actions are held by some backing bean which also contains the form.
> From the second form, I can submit the entity once updated. The buttons are <h:commandButton/> this time and the action returns null so I can stay on the same view and keep on working.
> Back with RF 3.x, I used the keepAlive tag to maintain the page's backing bean along the page life. All worked fine. After JSF 2.1 and RF 4 and CDI were released, I intended on using @ViewScoped instead. Naturally I had to add SeamFaces so my @ViewScoped beans were actually CDI-managed, and I updated my whole codebase.
> Well, now, when the a4j creation button is used, the form dynamically displays all right BUT when I try to submit the second form, my @ViewScoped bean vanishes (pbly the viewMap vanishes entirely).
> However, if I use <h:commandButton><f:ajax/></h:commandButton> for the creation instead, everything works fine. Which leads me to believe there is a bug/regression from RF3.3 on a4j:command* components (maybe a4j:ajax/a4j:poll, didn't check) when used in a full CDI environment.
--
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
11 years, 11 months
[JBoss JIRA] (RF-12619) @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
by Fab Mars (JIRA)
[ https://issues.jboss.org/browse/RF-12619?page=com.atlassian.jira.plugin.s... ]
Fab Mars commented on RF-12619:
-------------------------------
I confirm. It's working in both cases (h:action+f:ajax and a4j:action) now.
Thank you.
> @ViewScoped (CDI-managed) beans lost with a4j:command* and dynamic form
> -----------------------------------------------------------------------
>
> Key: RF-12619
> URL: https://issues.jboss.org/browse/RF-12619
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: component-a4j-core
> Affects Versions: 4.3.0.M2
> Environment: Windows, JDK 1.7.0_09, Glassfish 3.1.2.2 with Mojarra 2.1.14 (at least >= 2.1.8), RF 4.3.0 M2 (also on RF 4.2.x), Weld 1.1.8 and SeamFaces 3.1.0.
> Reporter: Fab Mars
> Assignee: Lukáš Fryč
> Labels: a4j:commandbutton, cdi, facelets, seamfaces, viewscoped, waiting_on_user
> Attachments: TestViewScope.zip
>
>
> Here is a weird case I found after updating a project of mine from JSF 1.2 & RF 3.x to JSF 2.1 and RF 4.2.3/4.3.0M2. See attached project.
> On a part of the page which is into a Facelets insert, I can click on a <a4j:commandButton/> to trigger the creation of some entity instance and dynamically display another form associated to that entity in another part of the page. So, there are 2 forms on the screen, one for the creation button, another one to edit the entity, both are always displayed but the content of the latter isn't rendered until the entity exists. The page actions are held by some backing bean which also contains the form.
> From the second form, I can submit the entity once updated. The buttons are <h:commandButton/> this time and the action returns null so I can stay on the same view and keep on working.
> Back with RF 3.x, I used the keepAlive tag to maintain the page's backing bean along the page life. All worked fine. After JSF 2.1 and RF 4 and CDI were released, I intended on using @ViewScoped instead. Naturally I had to add SeamFaces so my @ViewScoped beans were actually CDI-managed, and I updated my whole codebase.
> Well, now, when the a4j creation button is used, the form dynamically displays all right BUT when I try to submit the second form, my @ViewScoped bean vanishes (pbly the viewMap vanishes entirely).
> However, if I use <h:commandButton><f:ajax/></h:commandButton> for the creation instead, everything works fine. Which leads me to believe there is a bug/regression from RF3.3 on a4j:command* components (maybe a4j:ajax/a4j:poll, didn't check) when used in a full CDI environment.
--
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
11 years, 11 months
[JBoss JIRA] (RF-5460) Strange a4j resource prefix with url-based servlet mappings
by Fab Mars (JIRA)
[ https://issues.jboss.org/browse/RF-5460?page=com.atlassian.jira.plugin.sy... ]
Fab Mars resolved RF-5460.
--------------------------
Fix Version/s: 4.3.0.Final
(was: 3.Future)
Resolution: Out of Date
Problem no present in RF4. I see resources are relivered by /javax.faces.resource/ in any case.
> Strange a4j resource prefix with url-based servlet mappings
> -----------------------------------------------------------
>
> Key: RF-5460
> URL: https://issues.jboss.org/browse/RF-5460
> Project: RichFaces
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Affects Versions: 3.2.2
> Environment: JSF RI 1.2.11, RF 3.2.2SR1, Facelets 1.1.15b1, Glassfish v2.
> Reporter: Fab Mars
> Priority: Minor
> Labels: a4j, mapping, prefix, servlet
> Fix For: 4.3.0.Final
>
>
> My web.xml has several servlet mappings.
> <servlet-mapping>
> <servlet-name>Faces Servlet</servlet-name>
> <url-pattern>*.jsf</url-pattern>
> </servlet-mapping>
> <servlet-mapping>
> <servlet-name>Faces Servlet</servlet-name>
> <url-pattern>/somepath1/*</url-pattern>
> </servlet-mapping>
> <servlet-mapping>
> <servlet-name>Faces Servlet</servlet-name>
> <url-pattern>/somepath999/*</url-pattern>
> </servlet-mapping>
> I'm doing this because I'm using some phaselistener that preproceses some things and also enables short-urls.
> Now, any page has a4j resources written like this:
> <script type="text/javascript" src="/MyContext/somepath999/a4j/g/3_2_2.SR1org/richfaces/renderkit/html/scripts/skinning.js">
> That is all a4j resources are now comprising the LAST servlet-mapping, just between the context name and the /a4j/ path part.
> I tried to workaround it, by putting the *.jsf mapping as the last in the web.xml but to no avail: the last servlet mapping path was always used.
> To reproduce, just download the demo application: http://download.jboss.com/jboss-richfaces/richfaces-demo-3.2.2.SR1-jee5.war
> Edit web.xml and add to the existing *.jsf mapping the following:
> <servlet-mapping>
> <servlet-name>Faces Servlet</servlet-name>
> <url-pattern>/yeswecan/*</url-pattern>
> </servlet-mapping>
> Then deploy and look at the source of any page:
> <img class="rich-spacer " height="1" id="j_id258" src="/richfaces/yeswecan/a4j/g/3_2_2.SR1images/spacer.gif" width="1" style="height:10px;" />
> I'm not sure this is a bug or a feature of some sort. The code obviously takes ANY valid servlet mapping, which is fair enough. But maybe it should just check whether there is an extension-based mapping amongst them, and if yes, use it.
> Worse, this issue is also probably (conceptually) linked to https://jira.jboss.org/jira/browse/RF-3586
> Anyway, you're free to requalify this issue if you want. I'm reporting what I found and I'll find a workaround in the meantime.
> Thanks.
--
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
11 years, 11 months