Re: disabled f:ajax / not working (?)

2012-07-03 Thread Dennis Hörsch

Hi

So, what to do next? Should I make a ticket at MyFaces?

Greetings,
dennis

Am 29.06.2012 15:12, schrieb Leonardo Uribe:

Hi

Probably that's something not explicitly specified, but I think at
first view it has sense what you say. If the client behavior is
disabled, it should not generate any scripts, and the submit should
work as usual.

regards,

Leonardo Uribe

2012/6/29 Dennis Hörschhoer...@his.de:

Hi,

I tested to disable allf:ajax /  temporally on my page (programatically,
for testing reasons).
The behavior that I would expect is that the button then submits as without
the f:ajax tag.

But instead of this, the whole button is kind of disabled. This is also the
case if I disable the f:ajax directly:
h:commandButton value=Show
f:ajax execute=@this render=@form disabled=true /
f:setPropertyActionListener target=#{flash.show} value=true /
/h:commandButton

In the HTML the button has an onclick with 'return false'. Is this the
desired  behavior?
As I discovered so far this 'return false' is in the end depend on
AjaxBehavior.getHints().

getHints(): This method returns an unmodifiable Set containing the
ClientBehaviorHint SUBMITTING.
(http://javaserverfaces.java.net/nonav/docs/2.1/javadocs/javax/faces/component/behavior/AjaxBehavior.html)

But why does the AjaxBehavior pretend to be 'SUBMITTING' while generating no
script?

If I change it to return an empty set if it is disabled it works as
expected.

Greetings
dennis

--
HIS Hochschul-Informations-System GmbH
Goseriede 9 | 30159 Hannover |www.his.de

Dennis Hörsch
Unternehmensbereich Hochschul-IT
Arbeitsbereich Personalmanagement
Telefon +49 (0)511 1220-403
e-mailhoer...@his.de

Registergericht: Amtsgericht Hannover, HRB 6489
Geschäftsführer: Prof. Dr. Martin Leitner
Vorsitzender des Aufsichtsrats: Prof. Dr. Andreas Geiger







[jira] [Updated] (TRINIDAD-2282) In validateLength, a default hintRange message is displayed instead of hintMaximum even when minimum value is not set

2012-07-03 Thread Anshu Jain (JIRA)

 [ 
https://issues.apache.org/jira/browse/TRINIDAD-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Anshu Jain updated TRINIDAD-2282:
-

Status: Patch Available  (was: Open)

 In validateLength, a default hintRange message is displayed instead of 
 hintMaximum even when minimum value is not set
 -

 Key: TRINIDAD-2282
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2282
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-beta-2
 Environment: JDeveloper 11.1.2.0.0
Reporter: Anshu Jain
 Attachments: TrinidadBug2282.patch


 af:validateLength is used for a input text box. The maximum value is set and 
 minimum value is not set. Which means by default minimum is 0.
 The hintMaximum is set to {0} is maximum allowed and hintRange is set to 
 {0} is minimum, {1} is maximum
 When the user clicks on the the given text box, hintMaximum should be 
 displayed.
 Instead a default message: Enter between 0 and 3 characters. is displayed. 
 hintMaximum should be displayed in this scenario.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Comment Edited] (TRINIDAD-2282) In validateLength, a default hintRange message is displayed instead of hintMaximum even when minimum value is not set

2012-07-03 Thread Anshu Jain (JIRA)

[ 
https://issues.apache.org/jira/browse/TRINIDAD-2282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13405686#comment-13405686
 ] 

Anshu Jain edited comment on TRINIDAD-2282 at 7/3/12 8:30 AM:
--

Code fix for this bug
when minimum value is not set for a validateLength, the default value is taken 
as 0 by the server side code. As a result min=0 is sent to the client side as 
well. In this condition, server side does not set the user defined 
hintNotInRange, but sets hintMaximum.
But, in the js, a check is done for min != null and a default hintNotInRange 
message is displayed.
This fix checks if the value of min is 0 in js, in which case, hintMaximum is 
displayed.

  was (Author: anshujain):
Code fix for this bug
  
 In validateLength, a default hintRange message is displayed instead of 
 hintMaximum even when minimum value is not set
 -

 Key: TRINIDAD-2282
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2282
 Project: MyFaces Trinidad
  Issue Type: Bug
  Components: Components
Affects Versions: 2.0.0-beta-2
 Environment: JDeveloper 11.1.2.0.0
Reporter: Anshu Jain
 Attachments: TrinidadBug2282.patch


 af:validateLength is used for a input text box. The maximum value is set and 
 minimum value is not set. Which means by default minimum is 0.
 The hintMaximum is set to {0} is maximum allowed and hintRange is set to 
 {0} is minimum, {1} is maximum
 When the user clicks on the the given text box, hintMaximum should be 
 displayed.
 Instead a default message: Enter between 0 and 3 characters. is displayed. 
 hintMaximum should be displayed in this scenario.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Resolved] (TOBAGO-1168) '' and '\' are not escaped inside inputSuggest

2012-07-03 Thread Udo Schnurpfeil (JIRA)

 [ 
https://issues.apache.org/jira/browse/TOBAGO-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Udo Schnurpfeil resolved TOBAGO-1168.
-

Resolution: Fixed

 '' and '\' are not escaped inside inputSuggest
 ---

 Key: TOBAGO-1168
 URL: https://issues.apache.org/jira/browse/TOBAGO-1168
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Themes
Affects Versions: 1.5.6, 1.6.0-beta-2
Reporter: Bernd Bohmann
Assignee: Bernd Bohmann
Priority: Minor
 Fix For: 1.5.7, 1.6.0-beta-3




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (TRINIDAD-2120) Use jQuery ThemeRoller skins with Trinidad

2012-07-03 Thread Leonardo Uribe (JIRA)

[ 
https://issues.apache.org/jira/browse/TRINIDAD-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13405727#comment-13405727
 ] 

Leonardo Uribe commented on TRINIDAD-2120:
--

Thanks for take your time to review it. The feedback is most welcome. 

I agree with the suggestions done, just some comments:

ui-icon : the issue with ui-icon is themeroller uses a selector class called 
.ui-icon, but in trinidad, selectors ending with -icon has an special meaning. 
See this comment in StyleUtils:

// =-=jmw There is no good way to tell if this is an icon.
// for now, I look at the selector name.
// we do have some styles that have -icon- in the name, but it's
// not at the end which is how icons are determined.
// our icon names look like .AFWarningIcon:alias
// AFErrorIconStyle is a style.
// This supports pseudo-classes on icon definitions (e.g.,
// foo-icon:hover- or FooIcon:alias:hover)
// -icon: is a condition because it could be -icon:hover.

It could be good to have something like this:

.ui-icon {
-tr-icon: false;
}

Or something like that, to indicate the selector should not be deal as an icon. 
It has sense, and it shouldn't be hard to implement. In that way, you can add 
the required entries in the base skin to prevent these selectors to be read as 
icons. 

CSSUtils.isColor() : the problem with use parseColor is if the parsing cannot 
be done, an exception is thrown, so you need to catch it again and return 
false. In the extraction process, the detection of the color property is based 
into a mutually exclusive condition, which means the first value that could 
be parsed into a color wins. In CSS spec that's ok, because it defines the 
possible values to be found. I know the code is almost the same, but one is 
doing a check, the other one is used to get the color, so both are different 
methods, even if they look the same.



 Use jQuery ThemeRoller skins with Trinidad
 --

 Key: TRINIDAD-2120
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2120
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 2.0.0-core
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Attachments: TRINIDAD-2120-1.patch, TRINIDAD-2120-2.patch, 
 TRINIDAD-2120-4-changes-trinidad-impl-only.patch, cupertino+casablanca.png, 
 redmond+casablanca-2.png, redmond+casablanca.png, 
 screenshot-trinidad-cupertino.PNG, screenshot-trinidad-smoothness.PNG, 
 screenshot-trinidad-sunny.PNG, south-street+casablanca-2.png


 Here is the original mail from Trasca Virgil: 
 http://markmail.org/search/?q=themeroller%20trinidad#query:themeroller%20trinidad+page:1+mid:byczdawpyj33zqoy+state:results
 Mon, 25 Oct 2010 07:01:25 -0700
 Hi
  
  I am interested to get better skinning support in Apache MyFaces. I want 
 to 
 get MyFaces closely integrated with http://jqueryui.com/themeroller/ - I am 
 targeting MyFaces JSF1.2 branch.
  
 The end result should be the same with what PrimeFaces already did 
 - http://www.primefaces.org/themes.html 
  
 My initial idea is to implemented a JQueryCssToMyFacesCss kind of compiler 
 which 
 will get as input the jquery CSS syntax and will dump MyFaces CSS syntax.
  
 I have few questions related with this:
 * Did anybody tried something similar in the past - in the MyFaces 
 community?
 * Do you think the approach is achievable? Do you have a better 
 suggestion? Is 
 the UI MyFaces CSS syntax a generic enough UI css framework or is making 
 MyFaces 
 specific assumptions?
 * Is this doable only by implementing the previous compiler or the
 MyFaces/Trinidad components should be touched also?
  
 Here is the documentation for jQuery UI CSS framework
  
 http://docs.jquery.com/UI/Theming/API
  
 Thank you,
 Virgil
 Investigating more about this possible improvement, I notice that jquery 
 themeroller themes does not require jquery to work. So what can we do?
 We can take themeroller themes and generate a skin from trinidad. Trinidad 
 already has all the pieces of the pluzze (css parser/merger and a cool 
 skinning api) so we should just use it.
 I tried to create a skin in this way:
 skin
 idsunny.desktop/id
 familysunny/family
 render-kit-idorg.apache.myfaces.trinidad.desktop/render-kit-id
 
 style-sheet-nameskins/themeroller/sunny/jquery-ui-1.8.14.custom.css/style-sheet-name
 /skin
 skin-addition
 skin-idsunny.desktop/skin-id
 
 style-sheet-nameskins/themeroller/trinidad-theme.css/style-sheet-name
 /skin-addition
 The first stylesheet is the reference to a generated jquery theme and the 
 addition is the file that does the integration with trinidad. So, ThemeRoller 
 generates the .css + image files and 

Re: [TRINIDAD] JQuery Themeroller compatibility

2012-07-03 Thread Leonardo Uribe
Hi

Ok, I let some comments in TRINIDAD-2120. Unfortunately my time is
running out these days, but I hope to contribute a little bit more
after my vacations.

regards,

Leonardo Uribe

2012/7/3 Pavitra Subramaniam pavitra.subraman...@oracle.com:


 On 7/2/2012 3:48 PM, Pavitra Subramaniam wrote:



 On 6/29/2012 5:48 AM, Leonardo Uribe wrote:

 Hi

 I have been playing for some time with this idea. I tried to create a
 base skin:

 skin
 idthemeroller.desktop/id
 familythemeroller/family
 extendssimple.desktop/extends
 render-kit-idorg.apache.myfaces.trinidad.desktop/render-kit-id

 style-sheet-nameskins/themeroller/casablanca-themeroller-base.css/style-sheet-name
 /skin

 And then just extend that skin like this:

 skin
 idblack-tie.desktop/id
 familyblack-tie/family
 extendsthemeroller.desktop/extends
 render-kit-idorg.apache.myfaces.trinidad.desktop/render-kit-id

 style-sheet-nameskins/themeroller/black-tie/jquery-ui-1.8.21.custom.css/style-sheet-name
 /skin

 It works, so maybe it is better to set the base template on top.

 +1. thanks for tru


 er, thanks for trying :).

 - Pavitra

 I think it is also possible to use a skin addition to fix what is
 specific to the theme:

 skin-addition
 skin-idcupertino.desktop/skin-id

 style-sheet-nameskins/themeroller/cupertino/additional-skin-params.css/style-sheet-name
 /skin-addition

 +1 as well.

 Thanks
 Pavitra

 I have also found some issues but nothing that cannot be done. For
 example, themeroller change the colors according if the text is inside
 a widget container or header and so on, but trinidad has some
 hard-coded font colors and other concepts, that at the end it is
 better just ignore them and use a simplified way similar to
 themeroller way. Also, it could be good to generate some icons based
 on the ones provided by casablanca skin.

 I was thinking on commit the skins inside trinidad-components-showcase
 for now, and when the code is good enough move it to the
 implementation. That could make easier for anybody to help, because
 the code is in the repo and with the web application, maven and maven
 jetty pluggiin, it is very simple to edit some changes then just
 refresh the browser and have the result.



 Obviously before that we need to add just a couple of lines in
 trinidad, but it is reasonable.

 regards,

 Leonardo Uribe

 2012/6/22 Leonardo Uribelu4...@gmail.com:

 Hi

 I did some changes to the css, and now this is the result.


 https://issues.apache.org/jira/secure/attachment/12533046/redmond%2Bcasablanca-2.png

 https://issues.apache.org/jira/secure/attachment/12533047/south-street%2Bcasablanca-2.png

 There is still room for improvement, I think we can just take some
 themes, adjust them the best we can and bundle them inside trinidad
 without jQuery. Maybe it is a good idea to write a blog explaining how
 to create your custom trinidad skin using ThemeRoller.

 In my opinion, casablanca skin is a lot more complex and better skin
 that the ones provided in ThemeRoller. It is worth to just take our
 time and create the additional resources to make the skins more
 elegant and well polished. For example, there is no default colors for
 links in ThemeRoller, we can provide them manually, things like that.

 I removed jQuery tr:document hack and the skins do not change.

 Suggestions are welcome!.

 regards,

 Leonardo Uribe

 2012/6/22 Leonardo Uribelu4...@gmail.com:

 Hi

 2012/6/22 Pavitra Subramaniampavitra.subraman...@oracle.com:

 Hello Leonardo, Scott,

 Thanks for working on this. The LAF is very neat. I looked at the
 patch
 uploaded to the issue 2120 but didn't find the changes made to
 DocumentRenderer. Can you upload it as well? I see 2 issues being
 discussed

 The first patch was the proof of concept I did long time ago. I have
 attached a second patch with the work so far and another screenshot
 using other different theme:


 https://issues.apache.org/jira/secure/attachment/12533025/TRINIDAD-2120-2.patch

 https://issues.apache.org/jira/secure/attachment/12533026/redmond%2Bcasablanca.png

 Note the patch does not include the images of each theme.

 1.  Integrate themes provided by jQuery ThemeRoller into Trinidad
 Skinning
 Framework to get jQuery LAF on Trinidad applications
 2. Provide an ability to integrate jQuery widgets in a Trinidad app /
 enhance Trinidad component to use jQuery (?)

 For 1.  Integrate existing themes provided by jQuery ThemeRoller into
 Trinidad Skinning Framework to get jQuery LAF on Trinidad applications
 -

 a.  for the 'sunny' theme you have defined something like this

 +skin
 +idsunny.desktop/id
 +familysunny/family
 +render-kit-idorg.apache.myfaces.trinidad.desktop/render-kit-id
 +

 style-sheet-nameskins/themeroller/sunny/jquery-ui-1.8.14.custom.css/style-sheet-name
 +/skin
 +skin-addition
 +skin-idsunny.desktop/skin-id
 +

 style-sheet-nameskins/themeroller/trinidad-theme.css/style-sheet-name
 +/skin-addition
 +skin-addition
 +skin-idsunny.desktop/skin-id
 

[jira] [Commented] (TOBAGO-1167) tx:menuCheckbox and tx:menuRadio should have the attributes id and fieldId

2012-07-03 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/TOBAGO-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13405824#comment-13405824
 ] 

Hudson commented on TOBAGO-1167:


Integrated in tobago-1.5.x #66 (See 
[https://builds.apache.org/job/tobago-1.5.x/66/])
TOBAGO-1167: tx:menuCheckbox and tx:menuRadio should have the 
attributes id and fieldId (Revision 1356585)

 Result = SUCCESS
lofwyr : http://svn.apache.org/viewvc/?view=revrev=1356585
Files : 
* 
/myfaces/tobago/branches/tobago-1.5.x/tobago-example/tobago-example-test/src/main/webapp/tc/menuBar/menuBar-fieldId.xhtml
* 
/myfaces/tobago/branches/tobago-1.5.x/tobago-example/tobago-example-test/src/main/webapp/tc/menuBar/menuBar.xhtml


 tx:menuCheckbox and tx:menuRadio should have the attributes id and 
 fieldId
 --

 Key: TOBAGO-1167
 URL: https://issues.apache.org/jira/browse/TOBAGO-1167
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core
Affects Versions: 1.5.6, 1.6.0-beta-2
Reporter: Udo Schnurpfeil
Assignee: Udo Schnurpfeil
Priority: Minor
 Fix For: 1.5.7, 1.6.0-beta-3




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (TOBAGO-1168) '' and '\' are not escaped inside inputSuggest

2012-07-03 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/TOBAGO-1168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13405823#comment-13405823
 ] 

Hudson commented on TOBAGO-1168:


Integrated in tobago-1.5.x #66 (See 
[https://builds.apache.org/job/tobago-1.5.x/66/])
TOBAGO-1168: '' and '\' are not escaped inside inputSuggest
Merged from trunk [from revision 1356512] (Revision 1356581)

 Result = SUCCESS
lofwyr : http://svn.apache.org/viewvc/?view=revrev=1356581
Files : 
* 
/myfaces/tobago/branches/tobago-1.5.x/tobago-theme/tobago-theme-scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/InRenderer.java


 '' and '\' are not escaped inside inputSuggest
 ---

 Key: TOBAGO-1168
 URL: https://issues.apache.org/jira/browse/TOBAGO-1168
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Themes
Affects Versions: 1.5.6, 1.6.0-beta-2
Reporter: Bernd Bohmann
Assignee: Bernd Bohmann
Priority: Minor
 Fix For: 1.5.7, 1.6.0-beta-3




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (TOBAGO-1167) tx:menuCheckbox and tx:menuRadio should have the attributes id and fieldId

2012-07-03 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/TOBAGO-1167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13405881#comment-13405881
 ] 

Hudson commented on TOBAGO-1167:


Integrated in tobago-trunk #821 (See 
[https://builds.apache.org/job/tobago-trunk/821/])
TOBAGO-1167: tx:menuCheckbox and tx:menuRadio should have the 
attributes id and fieldId
Merged from tobago-1.5.x [from revision 1356585] (Revision 1356588)

 Result = SUCCESS
lofwyr : http://svn.apache.org/viewvc/?view=revrev=1356588
Files : 
* /myfaces/tobago/trunk
* 
/myfaces/tobago/trunk/tobago-example/tobago-example-test/src/main/webapp/tc/menuBar/menuBar-fieldId.xhtml
* 
/myfaces/tobago/trunk/tobago-example/tobago-example-test/src/main/webapp/tc/menuBar/menuBar.xhtml


 tx:menuCheckbox and tx:menuRadio should have the attributes id and 
 fieldId
 --

 Key: TOBAGO-1167
 URL: https://issues.apache.org/jira/browse/TOBAGO-1167
 Project: MyFaces Tobago
  Issue Type: Bug
  Components: Core
Affects Versions: 1.5.6, 1.6.0-beta-2
Reporter: Udo Schnurpfeil
Assignee: Udo Schnurpfeil
Priority: Minor
 Fix For: 1.5.7, 1.6.0-beta-3




--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Reopened] (TOBAGO-1153) Better look and feel for the tc:file upload

2012-07-03 Thread Bernd Bohmann (JIRA)

 [ 
https://issues.apache.org/jira/browse/TOBAGO-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bernd Bohmann reopened TOBAGO-1153:
---

  Assignee: Bernd Bohmann  (was: Udo Schnurpfeil)

Input should have an id. Otherwise they would be disabled inside a popup.

 Better look and feel for the tc:file upload
 ---

 Key: TOBAGO-1153
 URL: https://issues.apache.org/jira/browse/TOBAGO-1153
 Project: MyFaces Tobago
  Issue Type: New Feature
Reporter: Udo Schnurpfeil
Assignee: Bernd Bohmann
Priority: Minor
 Fix For: 1.6.0-beta-2, 1.6.0


 Currently the look and feel doesn't fit really to the themes.
 It's not easy, but possible to style the control. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (TOBAGO-1153) Better look and feel for the tc:file upload

2012-07-03 Thread Hudson (JIRA)

[ 
https://issues.apache.org/jira/browse/TOBAGO-1153?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13405992#comment-13405992
 ] 

Hudson commented on TOBAGO-1153:


Integrated in tobago-trunk #822 (See 
[https://builds.apache.org/job/tobago-trunk/822/])
TOBAGO-1153: Better look and feel for the tc:file upload
Input elements must have an id. Otherwise they would be disabled inside a 
popup. (Revision 1356692)

 Result = SUCCESS
bommel : http://svn.apache.org/viewvc/?view=revrev=1356692
Files : 
* 
/myfaces/tobago/trunk/tobago-theme/tobago-theme-scarborough/src/main/java/org/apache/myfaces/tobago/renderkit/html/scarborough/standard/tag/FileRenderer.java


 Better look and feel for the tc:file upload
 ---

 Key: TOBAGO-1153
 URL: https://issues.apache.org/jira/browse/TOBAGO-1153
 Project: MyFaces Tobago
  Issue Type: New Feature
Reporter: Udo Schnurpfeil
Assignee: Bernd Bohmann
Priority: Minor
 Fix For: 1.6.0-beta-2, 1.6.0


 Currently the look and feel doesn't fit really to the themes.
 It's not easy, but possible to style the control. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira




[jira] [Commented] (TRINIDAD-2120) Use jQuery ThemeRoller skins with Trinidad

2012-07-03 Thread Prakash Udupa (JIRA)

[ 
https://issues.apache.org/jira/browse/TRINIDAD-2120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13406213#comment-13406213
 ] 

Prakash Udupa commented on TRINIDAD-2120:
-

Reg. -ui-icon issue: In order to accomodate that thermoroller has selectors 
ending in 'ui-icon' that aren't to be treated like icon, we'd not want to break 
other apps that ended their selectors with 'ui-icon' because they wanted to be 
treated like icon. I'm assuming that you are not making this change now...

- return (selectorName.endsWith(-icon) || 
+ return ( (selectorName.endsWith(-icon)  !selectorName.equals(ui-icon) 
 !selectorName.contains(.ui-icon)) || 

b.t.w. -tr-icon is a good idea, I'm not sure if it is a common requirement to 
invest time to do that, maybe you can file a bug on JQuery to see if they can 
change the selector names to not end in 'icon'.

Reg. isColor(), I understand one is supposed to parse and return a color and 
you need a method that just says whether it is a color. But then your method is 
doing all the parsing that the other method is doing. Duplicate code is a pain 
on maintenance. I'm suggesting that you just call parseColor() inside of your 
isColor(), and return true for a successful parse, and false for a failure 
(inlcudes exception case that you would catch and return false).

 Use jQuery ThemeRoller skins with Trinidad
 --

 Key: TRINIDAD-2120
 URL: https://issues.apache.org/jira/browse/TRINIDAD-2120
 Project: MyFaces Trinidad
  Issue Type: Improvement
  Components: Skinning
Affects Versions: 2.0.0-core
Reporter: Leonardo Uribe
Assignee: Leonardo Uribe
 Attachments: TRINIDAD-2120-1.patch, TRINIDAD-2120-2.patch, 
 TRINIDAD-2120-4-changes-trinidad-impl-only.patch, cupertino+casablanca.png, 
 redmond+casablanca-2.png, redmond+casablanca.png, 
 screenshot-trinidad-cupertino.PNG, screenshot-trinidad-smoothness.PNG, 
 screenshot-trinidad-sunny.PNG, south-street+casablanca-2.png


 Here is the original mail from Trasca Virgil: 
 http://markmail.org/search/?q=themeroller%20trinidad#query:themeroller%20trinidad+page:1+mid:byczdawpyj33zqoy+state:results
 Mon, 25 Oct 2010 07:01:25 -0700
 Hi
  
  I am interested to get better skinning support in Apache MyFaces. I want 
 to 
 get MyFaces closely integrated with http://jqueryui.com/themeroller/ - I am 
 targeting MyFaces JSF1.2 branch.
  
 The end result should be the same with what PrimeFaces already did 
 - http://www.primefaces.org/themes.html 
  
 My initial idea is to implemented a JQueryCssToMyFacesCss kind of compiler 
 which 
 will get as input the jquery CSS syntax and will dump MyFaces CSS syntax.
  
 I have few questions related with this:
 * Did anybody tried something similar in the past - in the MyFaces 
 community?
 * Do you think the approach is achievable? Do you have a better 
 suggestion? Is 
 the UI MyFaces CSS syntax a generic enough UI css framework or is making 
 MyFaces 
 specific assumptions?
 * Is this doable only by implementing the previous compiler or the
 MyFaces/Trinidad components should be touched also?
  
 Here is the documentation for jQuery UI CSS framework
  
 http://docs.jquery.com/UI/Theming/API
  
 Thank you,
 Virgil
 Investigating more about this possible improvement, I notice that jquery 
 themeroller themes does not require jquery to work. So what can we do?
 We can take themeroller themes and generate a skin from trinidad. Trinidad 
 already has all the pieces of the pluzze (css parser/merger and a cool 
 skinning api) so we should just use it.
 I tried to create a skin in this way:
 skin
 idsunny.desktop/id
 familysunny/family
 render-kit-idorg.apache.myfaces.trinidad.desktop/render-kit-id
 
 style-sheet-nameskins/themeroller/sunny/jquery-ui-1.8.14.custom.css/style-sheet-name
 /skin
 skin-addition
 skin-idsunny.desktop/skin-id
 
 style-sheet-nameskins/themeroller/trinidad-theme.css/style-sheet-name
 /skin-addition
 The first stylesheet is the reference to a generated jquery theme and the 
 addition is the file that does the integration with trinidad. So, ThemeRoller 
 generates the .css + image files and we just need to provide a reusable .css 
 file to reuse the css classes. In practice with just one file we can create 
 20 or 30 trinidad themes in one move!
 Obviously these skins are no match for casablanca theme, and will possibly 
 have some flaws (the same for any themeroller skin, right?), but I think it 
 is worth to try it. I'll attach some files here to show how it looks like.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 

Re: Facelets: Back button, then nav-link click produces NPE

2012-07-03 Thread jnthodge

OK, we've upgraded to 2.1.7 as you suggested, and it has only changed the
line number that throws this error in ApplicationImpl.java.  Any thoughts?

Thanks much!!

java.lang.NullPointerException
at
org.apache.myfaces.application.ApplicationImpl._traverseListenerList(ApplicationImpl.java:2355)
at
org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:574)
at
org.apache.myfaces.application.ApplicationImpl.publishEvent(ApplicationImpl.java:604)
at
org.apache.myfaces.application.NavigationHandlerImpl$PreDisposeViewCallback.visit(NavigationHandlerImpl.java:237)
at
org.apache.myfaces.component.visit.FullVisitContext.invokeVisitCallback(FullVisitContext.java:141)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitTree(UIXComponent.java:539)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitTree(UIXComponent.java:362)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitAllChildren(UIXComponent.java:445)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitChildren(UIXComponent.java:423)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitChildren(UIXComponent.java:703)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitTree(UIXComponent.java:566)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitTree(UIXComponent.java:362)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitAllChildren(UIXComponent.java:445)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitChildren(UIXComponent.java:423)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitChildren(UIXComponent.java:703)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitTree(UIXComponent.java:566)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitTree(UIXComponent.java:362)
at
org.apache.myfaces.trinidad.component.UIXShowOne.visitTree(UIXShowOne.java:135)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:960)
at
javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1159)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitAllChildren(UIXComponent.java:445)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitChildren(UIXComponent.java:423)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitChildren(UIXComponent.java:703)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitTree(UIXComponent.java:566)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitTree(UIXComponent.java:362)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitAllChildren(UIXComponent.java:445)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitChildren(UIXComponent.java:423)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitChildren(UIXComponent.java:703)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitTree(UIXComponent.java:566)
at
org.apache.myfaces.trinidad.component.UIXComponent.visitTree(UIXComponent.java:362)
at javax.faces.component.UIComponent.visitTree(UIComponent.java:960)
at
javax.faces.component.UIComponentBase.visitTree(UIComponentBase.java:1159)
at
org.apache.myfaces.application.NavigationHandlerImpl.handleNavigation(NavigationHandlerImpl.java:182)
at
org.apache.myfaces.trinidadinternal.application.NavigationHandlerImpl.handleNavigation(NavigationHandlerImpl.java:117)
at
org.apache.myfaces.application.ActionListenerImpl.processAction(ActionListenerImpl.java:161)
at
org.apache.myfaces.trinidad.component.UIXCommand.broadcast(UIXCommand.java:190)
at javax.faces.component.UIViewRoot._broadcastAll(UIViewRoot.java:1023)
at javax.faces.component.UIViewRoot.broadcastEvents(UIViewRoot.java:286)
at javax.faces.component.UIViewRoot._process(UIViewRoot.java:1360)
at 
javax.faces.component.UIViewRoot.processApplication(UIViewRoot.java:752)
at
org.apache.myfaces.lifecycle.InvokeApplicationExecutor.execute(InvokeApplicationExecutor.java:38)
at
org.apache.myfaces.lifecycle.LifecycleImpl.executePhase(LifecycleImpl.java:170)
at
org.apache.myfaces.lifecycle.LifecycleImpl.execute(LifecycleImpl.java:117)
at javax.faces.webapp.FacesServlet.service(FacesServlet.java:197)
at
weblogic.servlet.internal.StubSecurityHelper$ServletServiceAction.run(StubSecurityHelper.java:227)
at
weblogic.servlet.internal.StubSecurityHelper.invokeServlet(StubSecurityHelper.java:125)
at
weblogic.servlet.internal.ServletStubImpl.execute(ServletStubImpl.java:300)
at weblogic.servlet.internal.TailFilter.doFilter(TailFilter.java:26)
at
weblogic.servlet.internal.FilterChainImpl.doFilter(FilterChainImpl.java:56)
at
org.apache.myfaces.trinidadinternal.webapp.TrinidadFilterImpl._doFilterImpl(TrinidadFilterImpl.java:293)