Re: myfaces groovy support
Cool thing, Werner. Congrats! --Manfred On Tue, May 13, 2008 at 7:45 AM, Werner Punz [EMAIL PROTECTED] wrote: Hello everyone I just wanted to give notification that I took a small break from my components project which is still on track and that I am working on myfaces groovy support. I got the first artefacts already reloading, and a first code will be made available by the end of the week, early next week. (For the Sun guys reading, thanks a lot you gave me the final push to do it, although I did many things differently than you did) Ok what will be done: First of all I replaced all the factories with my own ones to enable the entire system, I also had to write my own context listener to handle the classloader issues. (We really need a change in the spec here to enable scripting properly - Ed?) Secondly once the factories were in place I added proxy generation code wherever needed to enable reloading proxies. Third, a classloader which forks into the groovy system to load the groovy code. The groovy code also has its own reloading weaving code added to enable reloading of groovy files on the groovy side of things (the woven aop reloading code is lost on the java side however if you just deliver classes instead of objects, my first approach was a try to enable everything on the java side) So what do we get Reloading for most artefacts (probably on method level if things work out the way I intend them to be (For certain artefacts there are contracts you have to program in on the groovy side to enable this - aka expose the private properties some artefacts have otherwise a on method reloading will not be possible). Maybe and this is a big maybe, if I can get it up and running (I want to replace code on the fly) reloading of methods on groovy classes loaded by groovy over the new classloader. Again this is a big if, I have not prototyped this fully yet, but it should be possible. The idea is, once you load an in groovy object over the classloader it should be possible to change its methods on the fly via the meta programming capabilities of groovy. Ok first code around friday or early next week. After that I will start further discussions. And again, thanks to Ryan and Ed for finally pushing me towards it (indirectly by doing it). I also have to admit I have had a look at some parts of the code to check how you guys solved some problems I have been facing - especially the dreaded classloader issues and weaving issues. (I did most of the stuff differently though due to the different approach I am doing, of a mixed groovy/java infrastructure to enable some things not reachable from the java side that easily, also I did not want to change the core code, I wanted to have it more as an extension). If you want to have a look at the code upfront before next week, send me a private mail, I just do not want to post it yet because it still is not done enough for a public post. Especially the init code I am still very unhappy with. Werner -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
[jira] Commented: (TRINIDAD-1070) lightwight dialog autoresize does not work correctly
[
https://issues.apache.org/jira/browse/TRINIDAD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596307#action_12596307
]
Mathias Walter commented on TRINIDAD-1070:
--
I've also tried to use 'html jsfc=trh:html', but it doesn't help either.
lightwight dialog autoresize does not work correctly
Key: TRINIDAD-1070
URL: https://issues.apache.org/jira/browse/TRINIDAD-1070
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.7-core
Environment: Tomcat 6.0.14, Sun JSF RI 1.2, Windows XP SP2, FireFox
2.0.14, FireFox 3.0b5, IE6, Facelets 1.1.14
Reporter: Mathias Walter
Attachments: lwdlg_correctwidth_IE.jpg, lwdlg_wrongwidth_FF_1.jpg,
lwdlg_wrongwidth_FF_2.jpg
Original Estimate: 3h
Remaining Estimate: 3h
A simple lightweight dialog does not get shown correctly in FireFox (see
screenshots). The width is not set correctly to the content width and
therefore a horizontal scroll bar is shown. The reason is maybe a large
combobox.
Code:
?xml version='1.0' encoding='utf-8'?
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
xmlns:h=http://java.sun.com/jsf/html;
version=1.2
trh:head
titleArzt auswählen/title
/trh:head
trh:body
tr:form
tr:panelFormLayout
tr:selectOneChoice label=Arzt:
value=#{physicians.choosed} required=true
f:selectItems
value=#{physicians.items} /
/tr:selectOneChoice
/tr:panelFormLayout
tr:separator /
tr:panelButtonBar halign=center
tr:commandButton id=save
action=#{physicians.select} text=Übernehmen /
tr:commandButton id=cancel
action=#{physicians.cancelSelect} text=Abbrechen immediate=true /
/tr:panelButtonBar
/tr:form
/trh:body
/html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: myfaces groovy support
Unfortunately I did an accidental post of this in the RI devs mailinglist speaking of being chaotic and early morning. :-( Werner Manfred Geiler schrieb: Cool thing, Werner. Congrats! --Manfred On Tue, May 13, 2008 at 7:45 AM, Werner Punz [EMAIL PROTECTED] wrote: Hello everyone I just wanted to give notification that I took a small break from my components project which is still on track and that I am working on myfaces groovy support. I got the first artefacts already reloading, and a first code will be made available by the end of the week, early next week. (For the Sun guys reading, thanks a lot you gave me the final push to do it, although I did many things differently than you did) Ok what will be done: First of all I replaced all the factories with my own ones to enable the entire system, I also had to write my own context listener to handle the classloader issues. (We really need a change in the spec here to enable scripting properly - Ed?) Secondly once the factories were in place I added proxy generation code wherever needed to enable reloading proxies. Third, a classloader which forks into the groovy system to load the groovy code. The groovy code also has its own reloading weaving code added to enable reloading of groovy files on the groovy side of things (the woven aop reloading code is lost on the java side however if you just deliver classes instead of objects, my first approach was a try to enable everything on the java side) So what do we get Reloading for most artefacts (probably on method level if things work out the way I intend them to be (For certain artefacts there are contracts you have to program in on the groovy side to enable this - aka expose the private properties some artefacts have otherwise a on method reloading will not be possible). Maybe and this is a big maybe, if I can get it up and running (I want to replace code on the fly) reloading of methods on groovy classes loaded by groovy over the new classloader. Again this is a big if, I have not prototyped this fully yet, but it should be possible. The idea is, once you load an in groovy object over the classloader it should be possible to change its methods on the fly via the meta programming capabilities of groovy. Ok first code around friday or early next week. After that I will start further discussions. And again, thanks to Ryan and Ed for finally pushing me towards it (indirectly by doing it). I also have to admit I have had a look at some parts of the code to check how you guys solved some problems I have been facing - especially the dreaded classloader issues and weaving issues. (I did most of the stuff differently though due to the different approach I am doing, of a mixed groovy/java infrastructure to enable some things not reachable from the java side that easily, also I did not want to change the core code, I wanted to have it more as an extension). If you want to have a look at the code upfront before next week, send me a private mail, I just do not want to post it yet because it still is not done enough for a public post. Especially the init code I am still very unhappy with. Werner
[jira] Updated: (TRINIDAD-1070) lightwight dialog autoresize does not work correctly
[
https://issues.apache.org/jira/browse/TRINIDAD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathias Walter updated TRINIDAD-1070:
-
Status: Open (was: Patch Available)
lightwight dialog autoresize does not work correctly
Key: TRINIDAD-1070
URL: https://issues.apache.org/jira/browse/TRINIDAD-1070
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.7-core
Environment: Tomcat 6.0.14, Sun JSF RI 1.2, Windows XP SP2, FireFox
2.0.14, FireFox 3.0b5, IE6, Facelets 1.1.14
Reporter: Mathias Walter
Attachments: lwdlg_correctwidth_IE.jpg, lwdlg_wrongwidth_FF_1.jpg,
lwdlg_wrongwidth_FF_2.jpg
Original Estimate: 3h
Remaining Estimate: 3h
A simple lightweight dialog does not get shown correctly in FireFox (see
screenshots). The width is not set correctly to the content width and
therefore a horizontal scroll bar is shown. The reason is maybe a large
combobox.
Code:
?xml version='1.0' encoding='utf-8'?
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
xmlns:h=http://java.sun.com/jsf/html;
version=1.2
trh:head
titleArzt auswählen/title
/trh:head
trh:body
tr:form
tr:panelFormLayout
tr:selectOneChoice label=Arzt:
value=#{physicians.choosed} required=true
f:selectItems
value=#{physicians.items} /
/tr:selectOneChoice
/tr:panelFormLayout
tr:separator /
tr:panelButtonBar halign=center
tr:commandButton id=save
action=#{physicians.select} text=Übernehmen /
tr:commandButton id=cancel
action=#{physicians.cancelSelect} text=Abbrechen immediate=true /
/tr:panelButtonBar
/tr:form
/trh:body
/html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1070) lightwight dialog autoresize does not work correctly
[
https://issues.apache.org/jira/browse/TRINIDAD-1070?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mathias Walter updated TRINIDAD-1070:
-
Status: Patch Available (was: Open)
lightwight dialog autoresize does not work correctly
Key: TRINIDAD-1070
URL: https://issues.apache.org/jira/browse/TRINIDAD-1070
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.2.7-core
Environment: Tomcat 6.0.14, Sun JSF RI 1.2, Windows XP SP2, FireFox
2.0.14, FireFox 3.0b5, IE6, Facelets 1.1.14
Reporter: Mathias Walter
Attachments: lwdlg_correctwidth_IE.jpg, lwdlg_wrongwidth_FF_1.jpg,
lwdlg_wrongwidth_FF_2.jpg
Original Estimate: 3h
Remaining Estimate: 3h
A simple lightweight dialog does not get shown correctly in FireFox (see
screenshots). The width is not set correctly to the content width and
therefore a horizontal scroll bar is shown. The reason is maybe a large
combobox.
Code:
?xml version='1.0' encoding='utf-8'?
html xmlns=http://www.w3.org/1999/xhtml;
xmlns:f=http://java.sun.com/jsf/core;
xmlns:tr=http://myfaces.apache.org/trinidad;
xmlns:trh=http://myfaces.apache.org/trinidad/html;
xmlns:h=http://java.sun.com/jsf/html;
version=1.2
trh:head
titleArzt auswählen/title
/trh:head
trh:body
tr:form
tr:panelFormLayout
tr:selectOneChoice label=Arzt:
value=#{physicians.choosed} required=true
f:selectItems
value=#{physicians.items} /
/tr:selectOneChoice
/tr:panelFormLayout
tr:separator /
tr:panelButtonBar halign=center
tr:commandButton id=save
action=#{physicians.select} text=Übernehmen /
tr:commandButton id=cancel
action=#{physicians.cancelSelect} text=Abbrechen immediate=true /
/tr:panelButtonBar
/tr:form
/trh:body
/html
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (TRINIDAD-1068) ID not unique in generated html of tableheader (duplicate id detailStamp)
[ https://issues.apache.org/jira/browse/TRINIDAD-1068?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mathias Walter updated TRINIDAD-1068: - Status: Patch Available (was: Open) ID not unique in generated html of tableheader (duplicate id detailStamp) - Key: TRINIDAD-1068 URL: https://issues.apache.org/jira/browse/TRINIDAD-1068 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.6-core, 1.2.7-core Reporter: martin piekorz If I place two tables in one page, the id of the generated table header for the selection row is in both tables unique. All other table head ids are unique. table_one th id=j_id8... ... table_two ... th id=j_id8 ... 08.05.2008 16:37:41 org.apache.myfaces.trinidadinternal.io.DebugResponseWriter _logDuplicateId WARNUNG: The id j_id8 is used more than once. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (TOMAHAWK-1084) amISpannedOver doesn't ignore non-rendered columns
[ https://issues.apache.org/jira/browse/TOMAHAWK-1084?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daniel Zwink updated TOMAHAWK-1084: --- Status: Patch Available (was: Open) amISpannedOver doesn't ignore non-rendered columns -- Key: TOMAHAWK-1084 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1084 Project: MyFaces Tomahawk Issue Type: Bug Components: Extended Datatable Affects Versions: 1.1.5 Reporter: Paul Pogonyshev Priority: Minor In data table renderer there is amISpannedOver() method. It seems to work fine except that it doesn't ignore non-rendered columns. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: myfaces groovy support
Out of curiosity, will this be able to be extensible to support Jython as well? (some ppl like me prefer the jython syntax over groovy's) On Mon, May 12, 2008 at 11:45 PM, Werner Punz [EMAIL PROTECTED] wrote: Hello everyone I just wanted to give notification that I took a small break from my components project which is still on track and that I am working on myfaces groovy support. I got the first artefacts already reloading, and a first code will be made available by the end of the week, early next week. (For the Sun guys reading, thanks a lot you gave me the final push to do it, although I did many things differently than you did) Ok what will be done: First of all I replaced all the factories with my own ones to enable the entire system, I also had to write my own context listener to handle the classloader issues. (We really need a change in the spec here to enable scripting properly - Ed?) Secondly once the factories were in place I added proxy generation code wherever needed to enable reloading proxies. Third, a classloader which forks into the groovy system to load the groovy code. The groovy code also has its own reloading weaving code added to enable reloading of groovy files on the groovy side of things (the woven aop reloading code is lost on the java side however if you just deliver classes instead of objects, my first approach was a try to enable everything on the java side) So what do we get Reloading for most artefacts (probably on method level if things work out the way I intend them to be (For certain artefacts there are contracts you have to program in on the groovy side to enable this - aka expose the private properties some artefacts have otherwise a on method reloading will not be possible). Maybe and this is a big maybe, if I can get it up and running (I want to replace code on the fly) reloading of methods on groovy classes loaded by groovy over the new classloader. Again this is a big if, I have not prototyped this fully yet, but it should be possible. The idea is, once you load an in groovy object over the classloader it should be possible to change its methods on the fly via the meta programming capabilities of groovy. Ok first code around friday or early next week. After that I will start further discussions. And again, thanks to Ryan and Ed for finally pushing me towards it (indirectly by doing it). I also have to admit I have had a look at some parts of the code to check how you guys solved some problems I have been facing - especially the dreaded classloader issues and weaving issues. (I did most of the stuff differently though due to the different approach I am doing, of a mixed groovy/java infrastructure to enable some things not reachable from the java side that easily, also I did not want to change the core code, I wanted to have it more as an extension). If you want to have a look at the code upfront before next week, send me a private mail, I just do not want to post it yet because it still is not done enough for a public post. Especially the init code I am still very unhappy with. Werner
Re: myfaces groovy support
Andrew Robinson schrieb: Out of curiosity, will this be able to be extensible to support Jython as well? (some ppl like me prefer the jython syntax over groovy's) Well it depends, if jython can generate java Classes through its Eval functionality in the scripting adapter, then in the long run if someone does it, yes. Otherwise it might be hard. The thing is I intercept a classloader which has to return a class implementing the bean or jsf artefact the rest is infrastructure which can be adapted easily to other scripting languages. The classloader is necessary due to the fact that the scripts themselves have to be loaded from somewhere, I am not sure if I can remove the classloader at all, I don´t think so without any significant changes to the core codebase. Werner Btw. Status: following artefacts are already kickstarting: Beans, PhaseListener, ViewHandler
[jira] Reopened: (TRINIDAD-799) Add agent version support in skinning
[
https://issues.apache.org/jira/browse/TRINIDAD-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson reopened TRINIDAD-799:
--
AFAIK the current implementation is not the one discussed as the desired
implementation in the mailing list
Add agent version support in skinning
-
Key: TRINIDAD-799
URL: https://issues.apache.org/jira/browse/TRINIDAD-799
Project: MyFaces Trinidad
Issue Type: Wish
Components: Components
Affects Versions: 1.0.4-core
Reporter: Andrew Robinson
Assignee: Cristi Toth
Fix For: 1.0.8-core, 1.2.8-core
The current skinning functionality does not allow a skinning developer to
differentiate between different browser versions. For example, it is possible
to tell the difference between IE and firefox, but not between IE 6 and 7
Possible implementations:
1) @agent ie6 { ... }
2) @agent ie { @agentVersion 6 { ... } }
A more general and more powerful approach would be to allow developers to use
a regex on the browser version:
@agent match /MSIE [67]/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-799) Add agent version support in skinning
[
https://issues.apache.org/jira/browse/TRINIDAD-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596440#action_12596440
]
Andrew Robinson commented on TRINIDAD-799:
--
Taking this over as it is holding up a release and we have had no response on
the mailing list.
Add agent version support in skinning
-
Key: TRINIDAD-799
URL: https://issues.apache.org/jira/browse/TRINIDAD-799
Project: MyFaces Trinidad
Issue Type: Wish
Components: Components
Affects Versions: 1.0.4-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Fix For: 1.0.8-core, 1.2.8-core
The current skinning functionality does not allow a skinning developer to
differentiate between different browser versions. For example, it is possible
to tell the difference between IE and firefox, but not between IE 6 and 7
Possible implementations:
1) @agent ie6 { ... }
2) @agent ie { @agentVersion 6 { ... } }
A more general and more powerful approach would be to allow developers to use
a regex on the browser version:
@agent match /MSIE [67]/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-799) Add agent version support in skinning
[
https://issues.apache.org/jira/browse/TRINIDAD-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596442#action_12596442
]
Scott O'Bryan commented on TRINIDAD-799:
As per this discussion:
http://www.mail-archive.com/dev@myfaces.apache.org/msg32203.html, this bug is
holding up the next Release of Trinidad.
Add agent version support in skinning
-
Key: TRINIDAD-799
URL: https://issues.apache.org/jira/browse/TRINIDAD-799
Project: MyFaces Trinidad
Issue Type: Wish
Components: Components
Affects Versions: 1.0.4-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Fix For: 1.0.8-core, 1.2.8-core
The current skinning functionality does not allow a skinning developer to
differentiate between different browser versions. For example, it is possible
to tell the difference between IE and firefox, but not between IE 6 and 7
Possible implementations:
1) @agent ie6 { ... }
2) @agent ie { @agentVersion 6 { ... } }
A more general and more powerful approach would be to allow developers to use
a regex on the browser version:
@agent match /MSIE [67]/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-799) Add agent version support in skinning
[
https://issues.apache.org/jira/browse/TRINIDAD-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596444#action_12596444
]
Scott O'Bryan commented on TRINIDAD-799:
Thanks Andrew.
Add agent version support in skinning
-
Key: TRINIDAD-799
URL: https://issues.apache.org/jira/browse/TRINIDAD-799
Project: MyFaces Trinidad
Issue Type: Wish
Components: Components
Affects Versions: 1.0.4-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Fix For: 1.0.8-core, 1.2.8-core
The current skinning functionality does not allow a skinning developer to
differentiate between different browser versions. For example, it is possible
to tell the difference between IE and firefox, but not between IE 6 and 7
Possible implementations:
1) @agent ie6 { ... }
2) @agent ie { @agentVersion 6 { ... } }
A more general and more powerful approach would be to allow developers to use
a regex on the browser version:
@agent match /MSIE [67]/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-799) Add agent version support in skinning
[
https://issues.apache.org/jira/browse/TRINIDAD-799?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596463#action_12596463
]
Blake Sullivan commented on TRINIDAD-799:
-
If the current implementation doesn't match what was discussed, I believe that
we should back it out and release. We can but the agreed upon api in the next
release.
Add agent version support in skinning
-
Key: TRINIDAD-799
URL: https://issues.apache.org/jira/browse/TRINIDAD-799
Project: MyFaces Trinidad
Issue Type: Wish
Components: Components
Affects Versions: 1.0.4-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Fix For: 1.0.8-core, 1.2.8-core
The current skinning functionality does not allow a skinning developer to
differentiate between different browser versions. For example, it is possible
to tell the difference between IE and firefox, but not between IE 6 and 7
Possible implementations:
1) @agent ie6 { ... }
2) @agent ie { @agentVersion 6 { ... } }
A more general and more powerful approach would be to allow developers to use
a regex on the browser version:
@agent match /MSIE [67]/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-666) Selection of pageable sheet doesn't work
Selection of pageable sheet doesn't work Key: TOBAGO-666 URL: https://issues.apache.org/jira/browse/TOBAGO-666 Project: MyFaces Tobago Issue Type: Bug Components: Themes Affects Versions: 1.0.16 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Fix For: 1.0.17 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1074) Use shared string builder in org.apache.myfaces.trinidad.bean.FacesBeanFactory::_buildTypeKey
Use shared string builder in org.apache.myfaces.trinidad.bean.FacesBeanFactory::_buildTypeKey - Key: TRINIDAD-1074 URL: https://issues.apache.org/jira/browse/TRINIDAD-1074 Project: MyFaces Trinidad Issue Type: Bug Reporter: Stevan Malesevic org.apache.myfaces.trinidad.bean.FacesBeanFactory::_buildTypeKey should use shared StringBuilder to reduce memory (similar to org.apache.myfaces.trinidad.component.UIXComponentBase::getClientId) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1075) default attribute on subform tagdoc needs clarification
default attribute on subform tagdoc needs clarification --- Key: TRINIDAD-1075 URL: https://issues.apache.org/jira/browse/TRINIDAD-1075 Project: MyFaces Trinidad Issue Type: Bug Components: Documentation Affects Versions: 1.2.7-core Reporter: Sandy Schaffner Priority: Minor 1. Update tag doc on default from: whether the subform should assume it has been submitted. When set to default, submitted will be considered true if no other subform has been submitted. to: whether the subform should assume it has been submitted. When set to true, submitted will be considered true if no other subform has been submitted. 2. Update top level description from: The contents of a subform will only be validated (or otherwise processed) if a component inside of the subform is responsible for submitting the page. to: The contents of a subform will only be validated (or otherwise processed) if a component inside of the subform is responsible for submitting the page or if the default attribute is set to true. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Adobe Flex components as MyFaces JSF components
hello, i had just a very quick look at it. do you plan to support existing jsf artifacts (e.g. converters, validators,...)? @subproject and name: for each topic you have to start at least a vote. what's about the following idea: let's start a subproject for component libs like alchemy. in the future it might be nice to have also a component lib for e.g. javafx,... [new subproject] |_ [alchemy] |_[...] regards, gerhard 2008/5/13 Jihoon Kim [EMAIL PROTECTED]: I would suggest that the best place would be as a new subproject, like orchestra or portlet bridge are. It would definitely belong in the MyFaces family (rather than anywhere else in Apache) but I don't think it fits as part of Tomahawk. As I noted earlier, people who use tomahawk won't always want Flex, and people who want Flex won't always want the other tomahawk components. It could also be a new myfaces commons module, but we haven't really figured out how to structure those anyway. And it isn't really a common module, but a component library just like tomahawk is. So is there any documentation in regards to how a code becomes a subproject of MyFaces? I would like to possibly look into that area, since if that is the path that might be taken; I would like to know of the process ahead of time. I did previously read through the process within the incubator, but wasn't sure if that was solely for a standalone project or applies to subproject as well. In the case that the contribution does get accepted and does become a subproject, I even have a name that I would like to propose, which is alchemy. Thanks!!! -- Sincerely, Ji Hoon Kim -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: Adobe Flex components as MyFaces JSF components
If alchemy is already written, then we'll need to complete IP clearance. Scott Gerhard Petracek wrote: hello, i had just a very quick look at it. do you plan to support existing jsf artifacts (e.g. converters, validators,...)? @subproject and name: for each topic you have to start at least a vote. what's about the following idea: let's start a subproject for component libs like alchemy. in the future it might be nice to have also a component lib for e.g. javafx,... [new subproject] |_ [alchemy] |_[...] regards, gerhard 2008/5/13 Jihoon Kim [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: I would suggest that the best place would be as a new subproject, like orchestra or portlet bridge are. It would definitely belong in the MyFaces family (rather than anywhere else in Apache) but I don't think it fits as part of Tomahawk. As I noted earlier, people who use tomahawk won't always want Flex, and people who want Flex won't always want the other tomahawk components. It could also be a new myfaces commons module, but we haven't really figured out how to structure those anyway. And it isn't really a common module, but a component library just like tomahawk is. So is there any documentation in regards to how a code becomes a subproject of MyFaces? I would like to possibly look into that area, since if that is the path that might be taken; I would like to know of the process ahead of time. I did previously read through the process within the incubator, but wasn't sure if that was solely for a standalone project or applies to subproject as well. In the case that the contribution does get accepted and does become a subproject, I even have a name that I would like to propose, which is alchemy. Thanks!!! -- Sincerely, Ji Hoon Kim -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces
Re: new name for sev-en
hello matthias, as mentioned: maybe it's a good starting point for further suggestions. it isn't easy to find a name which is perfect to everyone (in every language, dialect, slang,...). regards, gerhard 2008/5/11 Matthias Wessendorf [EMAIL PROTECTED]: I'd prefer a Spanish word... To me checker sounds stupid. (krasser checker...) -M Sent from my iPod. Am 11.05.2008 um 01:55 schrieb Gerhard Petracek [EMAIL PROTECTED]: @andrew: it depends on the mother tongue. ;) for some of you 'seven' sounds boring - especially if english is your mother tongue. words of foreign languages sound much more interesting. if i translate 'seven' into my mother tongue, it also sounds a bit boring (just because it isn't exotic for me). in my country it's a kind of trend to use english words. so maybe we should just use an invented name or an acronym. e.g.: jac (*j*ava *a*nnotation *c*hecker) jack (*j*ava *a*nnotation *c*hec*k*er) if you translate e.g. 'jack' into my mother tongue, there are a lot of different meanings. so there is no real meaning - it just sounds interesting (it's a matter of taste). regards, gerhard 2008/5/10 Leonardo Uribe [EMAIL PROTECTED][EMAIL PROTECTED]: Some spanish words: myfaces-commons-validacion myfaces-commons-validar myfaces-commons-validador myfaces-commons-valide myfaces-commons-evaluador On Sat, May 10, 2008 at 3:12 PM, Hazem Saleh [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: +1 for myfaces-commons-checker. On Sat, May 10, 2008 at 1:53 PM, Gerhard Petracek [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: do you have a further suggestion? maybe a bit more fancy? e.g. one of the suggestions i heard is: myfaces-commons-checker maybe it's a new starting point for further suggestions. regards, gerhard 2008/4/29 Scott O'Bryan [EMAIL PROTECTED][EMAIL PROTECTED]: How about convalidi. It's validate in Italian (I think). Gerhard Petracek wrote: hello scott, do you have a suggestion for a short and fancy name? regards, gerhard 2008/4/27 Scott O'Bryan [EMAIL PROTECTED] [EMAIL PROTECTED] mailto: [EMAIL PROTECTED] [EMAIL PROTECTED]: +1 to not naming it validations. There is already a commons validator. -0 to including core in the name Strong -1 to including JSR in the project name. A jar is nearly an enhancement number for java. You wouln't name your project something like MyFaces-1234 after a Jira ticket number. On Apr 26, 2008, at 10:25 AM, Gerhard Petracek [EMAIL PROTECTED][EMAIL PROTECTED]mailto:[EMAIL PROTECTED] [EMAIL PROTECTED] wrote: hello alexander, i got your idea. however, i hope we will find a short and fancy name. if we don't have 'core' within the name, i think we have to find something else than just 'validation'. otherwise it will be a bit confusing for users due to the fact that the core itself doesn't validate. concrete validation logic is located within the independent/optional modules. the target is to have a core which provides the infrastructure and which encapsulates the specifics of the jsf version. furthermore, the core is independent of specific annotations. the optional modules provide the concrete annotations and/or validation logic (independent of the jsf version). (reason for and/or: we don't provide the annotations of jpa nor of jsr 303 - we just provide the validation strategies for these external annotations.) @myfaces-commons-validation-annotations: it isn't a pure annotation module - it also provides the validation strategies and much more. (in the case of the jpa validation support it just provides the validation strategy.) moreover, i would suggest that we rename seven-validation to seven-ext-validation or a bit shorter: seven-extval (for extended validation) or something similar which indicates that these are our annotations (and so on). @myfaces-commons-validation-jsr303: i'm fine with both jsr303 (my original suggestion) or bean-validation the names of our compromise so far: myfaces-commons-[new name] (= the core) myfaces-commons-[new name]-validation (= our annotations + validation strategies incl. cross-component validation infrastructure and also the jpa validation strategy,...) myfaces-commons-[new
Re: Adobe Flex components as MyFaces JSF components
Hi thanks for the feedback! Yes, I was intending to support the other jsf artifacts such as converters and validators in the future. In the contribution, I did create the components for Flex's validators and converters. But since they belong in a swf file, they technically are actual jsf components [in order to keep to the design]. Yet since all components that take input and updates the model extend from UIInput, I do not think there will be too many issues in supporting the regular jsf converters and validators. Of course when the contribution does get accepted, I do plan on investing my free time in creating support for standard converters and validators as well as other areas that I wish to improve upon. I think that's a good idea, since in the future I was hoping to check out javafx and other technology as well. Thanks!!! On Tue, May 13, 2008 at 2:27 PM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello, i had just a very quick look at it. do you plan to support existing jsf artifacts (e.g. converters, validators,...)? @subproject and name: for each topic you have to start at least a vote. what's about the following idea: let's start a subproject for component libs like alchemy. in the future it might be nice to have also a component lib for e.g. javafx,... [new subproject] |_ [alchemy] |_[...] regards, gerhard 2008/5/13 Jihoon Kim [EMAIL PROTECTED]: I would suggest that the best place would be as a new subproject, like orchestra or portlet bridge are. It would definitely belong in the MyFaces family (rather than anywhere else in Apache) but I don't think it fits as part of Tomahawk. As I noted earlier, people who use tomahawk won't always want Flex, and people who want Flex won't always want the other tomahawk components. It could also be a new myfaces commons module, but we haven't really figured out how to structure those anyway. And it isn't really a common module, but a component library just like tomahawk is. So is there any documentation in regards to how a code becomes a subproject of MyFaces? I would like to possibly look into that area, since if that is the path that might be taken; I would like to know of the process ahead of time. I did previously read through the process within the incubator, but wasn't sure if that was solely for a standalone project or applies to subproject as well. In the case that the contribution does get accepted and does become a subproject, I even have a name that I would like to propose, which is alchemy. Thanks!!! -- Sincerely, Ji Hoon Kim -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Sincerely, Ji Hoon Kim
[jira] Resolved: (TRINIDAD-799) Add agent version support in skinning
[
https://issues.apache.org/jira/browse/TRINIDAD-799?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Andrew Robinson resolved TRINIDAD-799.
--
Resolution: Fixed
Added support for the following syntax:
@agent ie and (version: 6) and (version: 7), gecko and (version: 1.9)
These are the same:
@agent ie and (version: 6.*)
@agent ie and (version: 6)
So to match only 6.0.x use:
@agent ie and (version: 6.0)
There is no range functionality for this release. A new JIRA ticket should be
created to support version ranges. The current functionality should be adequate
for the current release.
Add agent version support in skinning
-
Key: TRINIDAD-799
URL: https://issues.apache.org/jira/browse/TRINIDAD-799
Project: MyFaces Trinidad
Issue Type: Wish
Components: Components
Affects Versions: 1.0.4-core
Reporter: Andrew Robinson
Assignee: Andrew Robinson
Fix For: 1.0.8-core, 1.2.8-core
The current skinning functionality does not allow a skinning developer to
differentiate between different browser versions. For example, it is possible
to tell the difference between IE and firefox, but not between IE 6 and 7
Possible implementations:
1) @agent ie6 { ... }
2) @agent ie { @agentVersion 6 { ... } }
A more general and more powerful approach would be to allow developers to use
a regex on the browser version:
@agent match /MSIE [67]/
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [trinidad] release? I need help...
TRINIDAD-799 is in with version (not min/max ranges) support. I think we can start the release process soon. Perhaps people can hammer my changes with the release bits to ensure they are stable and okay? -Andrew On Mon, May 12, 2008 at 5:40 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey Cristi, What is the status of Trinidad-799? Is it checked in and ready to go. If so I'm going to start the release process. Scott Cristi Toth wrote: On Mon, May 5, 2008 at 11:00 PM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Easy enough for me since I'm in the middle of something else right now.. Cristi, can you ping me on this thread when TRINIDAD-799 is done and committed? I'll try to monitor it, but just in case I miss it... :) I'll try not to forget ;) Andrew Robinson wrote: +1 for the release to wait on TRINIDAD-799 On Mon, May 5, 2008 at 2:32 PM, Cristi Toth [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hey guys... There is an issue still opened reagarding TRINIDAD-799 I resolved it, but the guys here didn't agree with the api and also changed the requirements. There was a long discussion about this and it seemed it reached an agreement about the api, but I need some code for determining the agent minor version. Blake said there is something like this in Rich Client already and that you could donate the regex used for that. But since then he didn't give any sign of the code and I had no time to bug him with that. When do you plan to freeze and prepare the release? It would be a nice feature to have in this new release. cheers On Mon, May 5, 2008 at 9:44 PM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hey Matthias, I think I can jump in later today or early tomorrow if you havn't got anyone yet. Scott Matthias Wessendorf wrote: Http://myfaces.apache.org/trinidad Sent from my iPod. Am 05.05.2008 um 21:10 schrieb Nutulapati, Krishna [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Can you give me the link from where I can download new version of trinidad? Thanks Krishna -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: Monday, May 05, 2008 2:01 PM To: MyFaces Development Subject: [trinidad] release? I need help... Hello, I think it is time for a new trinidad release. However i am currently not able to manage that, because I broke my right arm. Would be cool if someone could jump in. Thanks, Matthias Sent from my iPod. -- Cristi Toth - Codebeat www.codebeat.ro http://www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro http://www.codebeat.ro
Re: Adobe Flex components as MyFaces JSF components
If the idea is accepted, I can give a part of my time to implement the standard converters, validators and other stuff. IMO, alchemy is a very nice name ( I really like :) ). +1 for Gerhard idea. On Wed, May 14, 2008 at 1:20 AM, Jihoon Kim [EMAIL PROTECTED] wrote: Hi thanks for the feedback! Yes, I was intending to support the other jsf artifacts such as converters and validators in the future. In the contribution, I did create the components for Flex's validators and converters. But since they belong in a swf file, they technically are actual jsf components [in order to keep to the design]. Yet since all components that take input and updates the model extend from UIInput, I do not think there will be too many issues in supporting the regular jsf converters and validators. Of course when the contribution does get accepted, I do plan on investing my free time in creating support for standard converters and validators as well as other areas that I wish to improve upon. I think that's a good idea, since in the future I was hoping to check out javafx and other technology as well. Thanks!!! On Tue, May 13, 2008 at 2:27 PM, Gerhard Petracek [EMAIL PROTECTED] wrote: hello, i had just a very quick look at it. do you plan to support existing jsf artifacts (e.g. converters, validators,...)? @subproject and name: for each topic you have to start at least a vote. what's about the following idea: let's start a subproject for component libs like alchemy. in the future it might be nice to have also a component lib for e.g. javafx,... [new subproject] |_ [alchemy] |_[...] regards, gerhard 2008/5/13 Jihoon Kim [EMAIL PROTECTED]: I would suggest that the best place would be as a new subproject, like orchestra or portlet bridge are. It would definitely belong in the MyFaces family (rather than anywhere else in Apache) but I don't think it fits as part of Tomahawk. As I noted earlier, people who use tomahawk won't always want Flex, and people who want Flex won't always want the other tomahawk components. It could also be a new myfaces commons module, but we haven't really figured out how to structure those anyway. And it isn't really a common module, but a component library just like tomahawk is. So is there any documentation in regards to how a code becomes a subproject of MyFaces? I would like to possibly look into that area, since if that is the path that might be taken; I would like to know of the process ahead of time. I did previously read through the process within the incubator, but wasn't sure if that was solely for a standalone project or applies to subproject as well. In the case that the contribution does get accepted and does become a subproject, I even have a name that I would like to propose, which is alchemy. Thanks!!! -- Sincerely, Ji Hoon Kim -- http://www.irian.at Your JSF powerhouse - JSF Consulting, Development and Courses in English and German Professional Support for Apache MyFaces -- Sincerely, Ji Hoon Kim -- Hazem Ahmed Saleh Ahmed http://www.jroller.com/page/HazemBlog
Re: [trinidad] release? I need help...
Maybe offtopic: Could trinidad-sandbox be included in the release? or there is a procedure for this? On 5/13/08, Andrew Robinson [EMAIL PROTECTED] wrote: TRINIDAD-799 is in with version (not min/max ranges) support. I think we can start the release process soon. Perhaps people can hammer my changes with the release bits to ensure they are stable and okay? -Andrew On Mon, May 12, 2008 at 5:40 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey Cristi, What is the status of Trinidad-799? Is it checked in and ready to go. If so I'm going to start the release process. Scott Cristi Toth wrote: On Mon, May 5, 2008 at 11:00 PM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Easy enough for me since I'm in the middle of something else right now.. Cristi, can you ping me on this thread when TRINIDAD-799 is done and committed? I'll try to monitor it, but just in case I miss it... :) I'll try not to forget ;) Andrew Robinson wrote: +1 for the release to wait on TRINIDAD-799 On Mon, May 5, 2008 at 2:32 PM, Cristi Toth [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hey guys... There is an issue still opened reagarding TRINIDAD-799 I resolved it, but the guys here didn't agree with the api and also changed the requirements. There was a long discussion about this and it seemed it reached an agreement about the api, but I need some code for determining the agent minor version. Blake said there is something like this in Rich Client already and that you could donate the regex used for that. But since then he didn't give any sign of the code and I had no time to bug him with that. When do you plan to freeze and prepare the release? It would be a nice feature to have in this new release. cheers On Mon, May 5, 2008 at 9:44 PM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hey Matthias, I think I can jump in later today or early tomorrow if you havn't got anyone yet. Scott Matthias Wessendorf wrote: Http://myfaces.apache.org/trinidad Sent from my iPod. Am 05.05.2008 um 21:10 schrieb Nutulapati, Krishna [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Can you give me the link from where I can download new version of trinidad? Thanks Krishna -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: Monday, May 05, 2008 2:01 PM To: MyFaces Development Subject: [trinidad] release? I need help... Hello, I think it is time for a new trinidad release. However i am currently not able to manage that, because I broke my right arm. Would be cool if someone could jump in. Thanks, Matthias Sent from my iPod. -- Cristi Toth - Codebeat www.codebeat.ro http://www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro http://www.codebeat.ro
Re: [trinidad] release? I need help...
I'll build the release tomorrow. Scott Andrew Robinson wrote: TRINIDAD-799 is in with version (not min/max ranges) support. I think we can start the release process soon. Perhaps people can hammer my changes with the release bits to ensure they are stable and okay? -Andrew On Mon, May 12, 2008 at 5:40 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey Cristi, What is the status of Trinidad-799? Is it checked in and ready to go. If so I'm going to start the release process. Scott Cristi Toth wrote: On Mon, May 5, 2008 at 11:00 PM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Easy enough for me since I'm in the middle of something else right now.. Cristi, can you ping me on this thread when TRINIDAD-799 is done and committed? I'll try to monitor it, but just in case I miss it... :) I'll try not to forget ;) Andrew Robinson wrote: +1 for the release to wait on TRINIDAD-799 On Mon, May 5, 2008 at 2:32 PM, Cristi Toth [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hey guys... There is an issue still opened reagarding TRINIDAD-799 I resolved it, but the guys here didn't agree with the api and also changed the requirements. There was a long discussion about this and it seemed it reached an agreement about the api, but I need some code for determining the agent minor version. Blake said there is something like this in Rich Client already and that you could donate the regex used for that. But since then he didn't give any sign of the code and I had no time to bug him with that. When do you plan to freeze and prepare the release? It would be a nice feature to have in this new release. cheers On Mon, May 5, 2008 at 9:44 PM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hey Matthias, I think I can jump in later today or early tomorrow if you havn't got anyone yet. Scott Matthias Wessendorf wrote: Http://myfaces.apache.org/trinidad Sent from my iPod. Am 05.05.2008 um 21:10 schrieb Nutulapati, Krishna [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Can you give me the link from where I can download new version of trinidad? Thanks Krishna -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: Monday, May 05, 2008 2:01 PM To: MyFaces Development Subject: [trinidad] release? I need help... Hello, I think it is time for a new trinidad release. However i am currently not able to manage that, because I broke my right arm. Would be cool if someone could jump in. Thanks, Matthias Sent from my iPod. -- Cristi Toth - Codebeat www.codebeat.ro http://www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro http://www.codebeat.ro
Re: [trinidad] release? I need help...
I don't think it should really be released, for the same reasons that the tomahawk one is not. I am willing to change my opinion though with a good argument. What I do think we should do is have a nightly sandbox snapshot. Also offtopic: the artifact IDs for the sandbox have no trinidad- prefix, as a result, the jar names are really vague. -Andrew On Tue, May 13, 2008 at 6:07 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Maybe offtopic: Could trinidad-sandbox be included in the release? or there is a procedure for this? On 5/13/08, Andrew Robinson [EMAIL PROTECTED] wrote: TRINIDAD-799 is in with version (not min/max ranges) support. I think we can start the release process soon. Perhaps people can hammer my changes with the release bits to ensure they are stable and okay? -Andrew On Mon, May 12, 2008 at 5:40 PM, Scott O'Bryan [EMAIL PROTECTED] wrote: Hey Cristi, What is the status of Trinidad-799? Is it checked in and ready to go. If so I'm going to start the release process. Scott Cristi Toth wrote: On Mon, May 5, 2008 at 11:00 PM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Easy enough for me since I'm in the middle of something else right now.. Cristi, can you ping me on this thread when TRINIDAD-799 is done and committed? I'll try to monitor it, but just in case I miss it... :) I'll try not to forget ;) Andrew Robinson wrote: +1 for the release to wait on TRINIDAD-799 On Mon, May 5, 2008 at 2:32 PM, Cristi Toth [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hey guys... There is an issue still opened reagarding TRINIDAD-799 I resolved it, but the guys here didn't agree with the api and also changed the requirements. There was a long discussion about this and it seemed it reached an agreement about the api, but I need some code for determining the agent minor version. Blake said there is something like this in Rich Client already and that you could donate the regex used for that. But since then he didn't give any sign of the code and I had no time to bug him with that. When do you plan to freeze and prepare the release? It would be a nice feature to have in this new release. cheers On Mon, May 5, 2008 at 9:44 PM, Scott O'Bryan [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hey Matthias, I think I can jump in later today or early tomorrow if you havn't got anyone yet. Scott Matthias Wessendorf wrote: Http://myfaces.apache.org/trinidad Sent from my iPod. Am 05.05.2008 um 21:10 schrieb Nutulapati, Krishna [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]: Can you give me the link from where I can download new version of trinidad? Thanks Krishna -Original Message- From: Matthias Wessendorf [mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] Sent: Monday, May 05, 2008 2:01 PM To: MyFaces Development Subject: [trinidad] release? I need help... Hello, I think it is time for a new trinidad release. However i am currently not able to manage that, because I broke my right arm. Would be cool if someone could jump in. Thanks, Matthias Sent from my iPod. -- Cristi Toth - Codebeat www.codebeat.ro http://www.codebeat.ro -- Cristi Toth - Codebeat www.codebeat.ro http://www.codebeat.ro
[jira] Updated: (PORTLETBRIDGE-34) Bridge does not work with Myfaces with state saving = client
[ https://issues.apache.org/jira/browse/PORTLETBRIDGE-34?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe updated PORTLETBRIDGE-34: Status: Patch Available (was: Open) Bridge does not work with Myfaces with state saving = client Key: PORTLETBRIDGE-34 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-34 Project: MyFaces Portlet Bridge Issue Type: Bug Affects Versions: 1.0.0-alpha-2 Environment: windows xp, tomcat 6.0.16 and jetty, pluto Reporter: Leonardo Uribe Attachments: patchPortletBridgeMyfaces.patch The javax.faces.ViewState hidden field is not rendered! The problem is on PortletViewHandlerImpl.java. The field: private static final String SAVESTATE_FIELD_MARKER = ~com.sun.faces.saveStateFieldMarker~; Is the problem. If ri is present this is the value, if not myfaces state field marker should be used I will attach a patch (the easiest solution that I could find), and if no objections, I'll commit it. Reproduce the error is simple. Just use archetype for portlets and change the param javax.faces.STATE_SAVING_METHOD to client -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (PORTLETBRIDGE-34) Bridge does not work with Myfaces with state saving = client
Bridge does not work with Myfaces with state saving = client Key: PORTLETBRIDGE-34 URL: https://issues.apache.org/jira/browse/PORTLETBRIDGE-34 Project: MyFaces Portlet Bridge Issue Type: Bug Affects Versions: 1.0.0-alpha-2 Environment: windows xp, tomcat 6.0.16 and jetty, pluto Reporter: Leonardo Uribe Attachments: patchPortletBridgeMyfaces.patch The javax.faces.ViewState hidden field is not rendered! The problem is on PortletViewHandlerImpl.java. The field: private static final String SAVESTATE_FIELD_MARKER = ~com.sun.faces.saveStateFieldMarker~; Is the problem. If ri is present this is the value, if not myfaces state field marker should be used I will attach a patch (the easiest solution that I could find), and if no objections, I'll commit it. Reproduce the error is simple. Just use archetype for portlets and change the param javax.faces.STATE_SAVING_METHOD to client -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-434) MyFaces's Portlet enhancement
[ https://issues.apache.org/jira/browse/MYFACES-434?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12596613#action_12596613 ] Leonardo Uribe commented on MYFACES-434: One last tip. For use this, use NonBufferingAddResource. MyFaces's Portlet enhancement - Key: MYFACES-434 URL: https://issues.apache.org/jira/browse/MYFACES-434 Project: MyFaces Core Issue Type: Improvement Components: Portlet_Support Affects Versions: 1.1.0 Environment: LInux, J2SE 1.4.2 Reporter: Shinsuke SUGAYA Assignee: Martin Marinschek Fix For: 1.1.6-SNAPSHOT Attachments: PortletEnableTomahawk.patch, tomahawk-patch-portlet.zip, Tomahawk_FileUpload_IBMPortal.zip MyFacesGenericPortlet does not fully support the feature of tomahawk component, such as inputHtml and fileUpload. So, I request the following feature to run it on portlet: - support tags in head (ex. inputHtml component) - support upload (fileUpload component) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[ORCHESTRA] incorrect download links
Hey guys, Sorry if someone's already dealing with this, but the Download links on the Core and Core15 projects are incorrect - they point to the main MyFaces download page. This can be quite frustrating - it took me a long time to figure out where the correct link was (on the main Orchestra page). ~~~ Kito D. Mann - Author, JavaServer Faces in Action http://www.virtua.com/ http://www.virtua.com - JSF/Java EE consulting, training, and mentoring http://www.jsfcentral.com/ http://www.JSFCentral.com - JavaServer Faces FAQ, news, and info phone: +1 203-653-2989 fax: +1 203-653-2988
