RE: JSF 2.0 component set
You're absolutely right that it can happen if enough people are interested in doing it. That's what OSS is all about. And if it happens, that would be great. This is the main target for my initial post: check whether enough interested developers could be found. My comment is just about what is *likely* to happen without any sudden new inflow of volunteers. The original poster suggested it would be a good idea, but didn't volunteer to spend the next six months coding it :-). Having a created a rather extensive company internal comp-set we searched for ways to let some of the stuff flow back to the community. And the first post is inspired by this. We could use our experience and some of the ideas and code-inspirations (our code is too heavily dependant on not opensourceable internal code) to participate in such a product. regards Alexander
Re: MarkMail link adjustment
Jason, Thanks for the info. @dev, I adjusted all markmail links in the myfaces-master-pom accordingly. --Manfred On Tue, Apr 1, 2008 at 8:45 AM, Jason Hunter [EMAIL PROTECTED] wrote: Hi Manfred, I wanted to let you know that on MarkMail we've setup list home pages at URLs like /list/listid. I'm hoping you can adjust the MyFaces per-list archive links on http://myfaces.apache.org/mail-lists.html to point at these pages instead of using the multi-subdomains. Before: http://users.myfaces.markmail.org/ After: http://markmail.org/list/org.apache.myfaces.users The list home page URLs are more elegant and (we think) will help us some with Google that doesn't like sites having thousands of subdomains that seem to point at the same content. The list pages are pretty basic right now. We're going to make these pages sexy in the future with list metadata and everything, but for now we want to get people pointing at the right pages and phase out the multiple subdomain hack. Hopefully this is an easy fix for you. We see lots of referrals from the MyFaces links! (Please let me know if you're not the right person to contact about this.) -jh-
[jira] Commented: (MYFACES-1692) CommandLink does not execute action if no javascript is allowed
[
https://issues.apache.org/jira/browse/MYFACES-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584051#action_12584051
]
Simon Kitching commented on MYFACES-1692:
-
(1)
Hmm..what exactly is the required behaviour of an h:commandLink? I had always
assumed (and myfaces has always implemented) it works just like
h:commandButton. Should check this.
But assuming that commandLink and commandButton should have the same behaviour
(just with different visual representation) then commandLink really *must*
submit the enclosing form. As Leonardo points out, without that any data that
the user enters into a form will be lost.
And I'm pretty sure there *is* no way to submit a form from a link without
script. Http was designed with the idea that a link and a form are two quite
different things; links do not vary depending on the state of other input
fields on the page.
However I had thought that a solution to this no-javascript issue had already
been implemented: for h:commandLink to render a button with a css style that
makes it look like a link. This certainly was being discussed - was it not
committed? I'm not 100% sure how this works for disabled users (eg
screen-readers for the blind) but initially it seems ok; a submit button should
be understandable. Probably better than a link that triggers javascript to
submit some not-obviously-related form.
(2)
To repeat an earlier comment: the view state can be of any size but a link has
a fixed limit on the size of its query parameters. So any kind of solution
implemented with links should just refuse to work with client-side state (throw
an exception). Otherwise, a page will work with N components, then suddenly
fail with N+1 components. That's really ugly.
Supporting server-side state is ok; the link just needs query params that
contain the key of the server-side state data.
(3)
I can imagine a new component, called t:goLink or some similar name. It could
do a postback and run action listeners. However it could never implement the
full expected behaviour of h:commandLink (see comment 1 above). Because of the
loss of user input, it is really useful only for cases where the action always
navigates to some other page (so should probably be hard-wired with
immediate=true).
And it would only work reliably with server-side state (see comment 2 above).
(4)
Yes, if h:commandLink is used but the browser is known to not support
javascript then some kind of warning or error would probably be a good idea.
However I'm not sure that this can be reliably detected on the server. Can
JavascriptUtils.isJavascriptAllowed really work? Maybe instead h:form could
check whether any component has output javascript into the page, and if so then
render a noscript tag containing a warning message? Certainly IE and Firefox
will render a noscript block iff javascript is disabled for that page..
CommandLink does not execute action if no javascript is allowed
---
Key: MYFACES-1692
URL: https://issues.apache.org/jira/browse/MYFACES-1692
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.0
Environment: Tomcat 6.0, javax.faces.STATE_SAVING_METHOD=server,
org.apache.myfaces.ALLOW_JAVASCRIPT=false
Reporter: Thomas Fischer
Situation:
The tag h:commandLink action=#{someBean.someAction}
value=submit/h:commandLink is used in a jsp page, which is visited by
the user. The user clicks on the link.
Expected behaviour:
The method someBean.someAction() should be called, and the navigation rule
which matches the outcome should determine the page to be displayed.
Wrong behaviour:
The method defined in action is not called and the same jsp page is rendered
again.
I did some debugging to find the reason of this problem. It seems to me that
the server does not recognize that the click on the link is a postback. In
line 172 in org.apache.myfaces.renderkit.html.HtmlResponseStateManager, the
HTTP Parameter ResponseStateManager.VIEW_STATE_PARAM is checked for
existence. If it is there, the request is a callback, and if it is not there,
the request is not treated as postback. This parameter is not encoded in the
link rendered by h:commandLink, thus the request is not treated as a
postback, and the page is just rendered again.
If javaScript rendering is allowed, this works fine because the HTTP
parameter ResponseStateManager.VIEW_STATE_PARAM is rendered as a hidden input
field, and the javascript code does a form submit.
It seems to me that the problem could be solved by adding the parameter
ResponseStateManager.VIEW_STATE_PARAM to the generated link (but I did not
check it).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a
[jira] Commented: (MYFACES-1692) CommandLink does not execute action if no javascript is allowed
[
https://issues.apache.org/jira/browse/MYFACES-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584061#action_12584061
]
Thomas Fischer commented on MYFACES-1692:
-
As written in my comment from 11/Oct/07 03:16 AM, the patch is not desirable in
its original form. In fact, the JSF specs say that a commandLink MUST submit
the form which is not possible without Javascript as far as I know.
So any solution in the original direction would involve a custom component,
probably with reduced functionality even with javascript disabled (no form
submit). However, as I wrote above, the problem with this approach is if the
custom component is inside a form for layout reasons, then the decode method
would not be called in the current implementation.
The idea of rendering a button so that it looks like a link would be a good
solution to this problem. I'm not sure it is entirely feasible, though. I have
just talked to a colleague who tried to do this, and he says that e.g.
underlining a text in a button in firefox is a problem even in the current
firefox versions. I do not know whether this addition is submitted in myfaces
or not.
CommandLink does not execute action if no javascript is allowed
---
Key: MYFACES-1692
URL: https://issues.apache.org/jira/browse/MYFACES-1692
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.0
Environment: Tomcat 6.0, javax.faces.STATE_SAVING_METHOD=server,
org.apache.myfaces.ALLOW_JAVASCRIPT=false
Reporter: Thomas Fischer
Situation:
The tag h:commandLink action=#{someBean.someAction}
value=submit/h:commandLink is used in a jsp page, which is visited by
the user. The user clicks on the link.
Expected behaviour:
The method someBean.someAction() should be called, and the navigation rule
which matches the outcome should determine the page to be displayed.
Wrong behaviour:
The method defined in action is not called and the same jsp page is rendered
again.
I did some debugging to find the reason of this problem. It seems to me that
the server does not recognize that the click on the link is a postback. In
line 172 in org.apache.myfaces.renderkit.html.HtmlResponseStateManager, the
HTTP Parameter ResponseStateManager.VIEW_STATE_PARAM is checked for
existence. If it is there, the request is a callback, and if it is not there,
the request is not treated as postback. This parameter is not encoded in the
link rendered by h:commandLink, thus the request is not treated as a
postback, and the page is just rendered again.
If javaScript rendering is allowed, this works fine because the HTTP
parameter ResponseStateManager.VIEW_STATE_PARAM is rendered as a hidden input
field, and the javascript code does a form submit.
It seems to me that the problem could be solved by adding the parameter
ResponseStateManager.VIEW_STATE_PARAM to the generated link (but I did not
check it).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1692) CommandLink does not execute action if no javascript is allowed
[
https://issues.apache.org/jira/browse/MYFACES-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584107#action_12584107
]
Simon Kitching commented on MYFACES-1692:
-
I think this issue should remain open, but changed from bug to enhancement.
Using real links where javascript is supported seems nicer. However when it
is disabled (ie ALLOW_JAVASCRIPT=false) it would be nice for h:commandLink to
automatically switch to rendering a button rather than just be broken.
However the implementation does require a little more thought; defining the
style directly on the button is most convenient but makes it hard for users to
override the style (I think direct styles have higher priority than almost any
other css rule?). Adding a style-class is better, but myfaces would then need
to ensure that the rule was defined; as css rules in HTML need to be defined in
the head section that becomes a little tricky. Ecch.
Maybe support a config param org.apache.myfaces.COMMAND_LINK_CLASS? When set,
output that as the class for the button written by the commandLink renderer
(and the user is responsible for ensuring that a style exists for that class).
When the option is not set, hard-wire the style property with the default
styling.
CommandLink does not execute action if no javascript is allowed
---
Key: MYFACES-1692
URL: https://issues.apache.org/jira/browse/MYFACES-1692
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.0
Environment: Tomcat 6.0, javax.faces.STATE_SAVING_METHOD=server,
org.apache.myfaces.ALLOW_JAVASCRIPT=false
Reporter: Thomas Fischer
Situation:
The tag h:commandLink action=#{someBean.someAction}
value=submit/h:commandLink is used in a jsp page, which is visited by
the user. The user clicks on the link.
Expected behaviour:
The method someBean.someAction() should be called, and the navigation rule
which matches the outcome should determine the page to be displayed.
Wrong behaviour:
The method defined in action is not called and the same jsp page is rendered
again.
I did some debugging to find the reason of this problem. It seems to me that
the server does not recognize that the click on the link is a postback. In
line 172 in org.apache.myfaces.renderkit.html.HtmlResponseStateManager, the
HTTP Parameter ResponseStateManager.VIEW_STATE_PARAM is checked for
existence. If it is there, the request is a callback, and if it is not there,
the request is not treated as postback. This parameter is not encoded in the
link rendered by h:commandLink, thus the request is not treated as a
postback, and the page is just rendered again.
If javaScript rendering is allowed, this works fine because the HTTP
parameter ResponseStateManager.VIEW_STATE_PARAM is rendered as a hidden input
field, and the javascript code does a form submit.
It seems to me that the problem could be solved by adding the parameter
ResponseStateManager.VIEW_STATE_PARAM to the generated link (but I did not
check it).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1692) CommandLink does not execute action if no javascript is allowed
[
https://issues.apache.org/jira/browse/MYFACES-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584090#action_12584090
]
Leonardo Uribe commented on MYFACES-1692:
-
I have done this simple html test
html
head
style type=text/css
.boton {
background-color: transparent;
border-width: 0px;
text-decoration: underline;
color:blue;
}
/style
/head
body
input type=submit class=boton value=Press Me!/input
/body
/html
Maybe we can do something like this (this also works):
input type=submit
style=background-color: transparent;border-width: 0px;text-decoration:
underline;color:blue
value=Press Me!/input
I have tested on IE 6 and firefox 2.0.0.13.
The problems with this is that in fact is not an link tag, so css should be set
manually. But the better solution at this time.
CommandLink does not execute action if no javascript is allowed
---
Key: MYFACES-1692
URL: https://issues.apache.org/jira/browse/MYFACES-1692
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.0
Environment: Tomcat 6.0, javax.faces.STATE_SAVING_METHOD=server,
org.apache.myfaces.ALLOW_JAVASCRIPT=false
Reporter: Thomas Fischer
Situation:
The tag h:commandLink action=#{someBean.someAction}
value=submit/h:commandLink is used in a jsp page, which is visited by
the user. The user clicks on the link.
Expected behaviour:
The method someBean.someAction() should be called, and the navigation rule
which matches the outcome should determine the page to be displayed.
Wrong behaviour:
The method defined in action is not called and the same jsp page is rendered
again.
I did some debugging to find the reason of this problem. It seems to me that
the server does not recognize that the click on the link is a postback. In
line 172 in org.apache.myfaces.renderkit.html.HtmlResponseStateManager, the
HTTP Parameter ResponseStateManager.VIEW_STATE_PARAM is checked for
existence. If it is there, the request is a callback, and if it is not there,
the request is not treated as postback. This parameter is not encoded in the
link rendered by h:commandLink, thus the request is not treated as a
postback, and the page is just rendered again.
If javaScript rendering is allowed, this works fine because the HTTP
parameter ResponseStateManager.VIEW_STATE_PARAM is rendered as a hidden input
field, and the javascript code does a form submit.
It seems to me that the problem could be solved by adding the parameter
ResponseStateManager.VIEW_STATE_PARAM to the generated link (but I did not
check it).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1692) CommandLink does not execute action if no javascript is allowed
[
https://issues.apache.org/jira/browse/MYFACES-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584104#action_12584104
]
Thomas Fischer commented on MYFACES-1692:
-
Leonardo, you are right, underlining works also with Firefox. Sorry for the
wrong information.
The strange thing is that I checked my colleague's application and there
underlines do not show, although I used exactly the same css class. Must be due
to some surrounding element supressing the underline, but I was not able to
find out what it is.
So this issue should be resolved with resolution wont' fix IMHO. I'd offer to
do it if you agree.
CommandLink does not execute action if no javascript is allowed
---
Key: MYFACES-1692
URL: https://issues.apache.org/jira/browse/MYFACES-1692
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.0
Environment: Tomcat 6.0, javax.faces.STATE_SAVING_METHOD=server,
org.apache.myfaces.ALLOW_JAVASCRIPT=false
Reporter: Thomas Fischer
Situation:
The tag h:commandLink action=#{someBean.someAction}
value=submit/h:commandLink is used in a jsp page, which is visited by
the user. The user clicks on the link.
Expected behaviour:
The method someBean.someAction() should be called, and the navigation rule
which matches the outcome should determine the page to be displayed.
Wrong behaviour:
The method defined in action is not called and the same jsp page is rendered
again.
I did some debugging to find the reason of this problem. It seems to me that
the server does not recognize that the click on the link is a postback. In
line 172 in org.apache.myfaces.renderkit.html.HtmlResponseStateManager, the
HTTP Parameter ResponseStateManager.VIEW_STATE_PARAM is checked for
existence. If it is there, the request is a callback, and if it is not there,
the request is not treated as postback. This parameter is not encoded in the
link rendered by h:commandLink, thus the request is not treated as a
postback, and the page is just rendered again.
If javaScript rendering is allowed, this works fine because the HTTP
parameter ResponseStateManager.VIEW_STATE_PARAM is rendered as a hidden input
field, and the javascript code does a form submit.
It seems to me that the problem could be solved by adding the parameter
ResponseStateManager.VIEW_STATE_PARAM to the generated link (but I did not
check it).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1692) CommandLink does not execute action if no javascript is allowed
[
https://issues.apache.org/jira/browse/MYFACES-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584097#action_12584097
]
Bruno Aranda commented on MYFACES-1692:
---
Yes, styling the commandButton as a link is the classic solution to this...
CommandLink does not execute action if no javascript is allowed
---
Key: MYFACES-1692
URL: https://issues.apache.org/jira/browse/MYFACES-1692
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.0
Environment: Tomcat 6.0, javax.faces.STATE_SAVING_METHOD=server,
org.apache.myfaces.ALLOW_JAVASCRIPT=false
Reporter: Thomas Fischer
Situation:
The tag h:commandLink action=#{someBean.someAction}
value=submit/h:commandLink is used in a jsp page, which is visited by
the user. The user clicks on the link.
Expected behaviour:
The method someBean.someAction() should be called, and the navigation rule
which matches the outcome should determine the page to be displayed.
Wrong behaviour:
The method defined in action is not called and the same jsp page is rendered
again.
I did some debugging to find the reason of this problem. It seems to me that
the server does not recognize that the click on the link is a postback. In
line 172 in org.apache.myfaces.renderkit.html.HtmlResponseStateManager, the
HTTP Parameter ResponseStateManager.VIEW_STATE_PARAM is checked for
existence. If it is there, the request is a callback, and if it is not there,
the request is not treated as postback. This parameter is not encoded in the
link rendered by h:commandLink, thus the request is not treated as a
postback, and the page is just rendered again.
If javaScript rendering is allowed, this works fine because the HTTP
parameter ResponseStateManager.VIEW_STATE_PARAM is rendered as a hidden input
field, and the javascript code does a form submit.
It seems to me that the problem could be solved by adding the parameter
ResponseStateManager.VIEW_STATE_PARAM to the generated link (but I did not
check it).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1035) PPR doesn't complete in IE 7 when command component originates action, becomes disabled, and is a partial target
PPR doesn't complete in IE 7 when command component originates action, becomes
disabled, and is a partial target
Key: TRINIDAD-1035
URL: https://issues.apache.org/jira/browse/TRINIDAD-1035
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Affects Versions: 1.0.7-core
Environment: IE 7
Reporter: Shawn Bertrand
Fix For: 1.0.8-core
This problem only occurs in IE 7 - Firefox 2.x is fine.
With partialSubmit=true on a command link or button, and when that link or
button is added as a partial target and becomes disabled during that
component's actionListener method, the link or button does become disabled
but PPR doesn't complete on any components listening to PPR events from the
link or button. The PPR fragments received by the client contain the correctly
updated and pertinent components, but the client doesn't process them.
This is reproducible in the PPR Demos page (pprDemos.jspx) with a few
modifications. With the changes below, the Do a partial submit link and
partial Submit buttons will become disabled as expected, but the time won't
be updated on the client - even though the PPR response contains the updated
fragment.
pprDemos.jspx:
=
1. Change the pSubLink and pSubButton to:
tr:commandLink id=pSub_link
disabled=#{partialDemoUtil.btnDisabled}
partialSubmit=true
text=Do a partial Submit.
actionListener=#{partialDemoUtil.action}/
tr:spacer height=6/
tr:commandButton id=pSub_button
disabled=#{partialDemoUtil.btnDisabled}
partialSubmit=true
text=partialSubmit Button
actionListener=#{partialDemoUtil.action}/
PartialDemoUtilBean.java:
=
1. BtnDisabled binding methods:
private boolean _disabled = false;
public boolean getBtnDisabled()
{
return _disabled;
}
public void setBtnDisabled(boolean state)
{
_disabled = state;
}
2. Change the action(...) method to:
public void action(ActionEvent action)
{
// Just update the string which says when the last update was.
_status.setLinkUpdate();
setBtnDisabled(!_disabled);
RequestContext.getCurrentInstance().addPartialTarget(action.getComponent());
}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: New logos for Tobago and Orchestra
Hi, In the final I designed the Tomahawk logo :) What do you think about this logo ... ? Have a nice day ! Adonis On Tue, Apr 1, 2008 at 11:35 AM, Adonis Raduca [EMAIL PROTECTED] wrote: Hi, I seems that majority have pronounced in the favor of the first Trinidad logo, also the majority likes Orchestra logo. So we have Orchestra and Trinidad final logos. What about Tobago, I propose a tournament between the second logo of Trinidad and the already existing Tobago logo for title of The final Tobago logo :) What is your opinion ... ? Thanks, Adonis P.S. Simon I will provide to you an Orchestra logo for the site today ;) On 3/31/08, simon [EMAIL PROTECTED] wrote: On Thu, 2008-03-27 at 17:59 +0200, Adonis Raduca wrote: Hi, We have new logos for Tobago and Orchestra :) The general opinion seemed to be that the Orchestra one was good. So if you can send it to me I'll add it to the website (the original post had the orchestra and trinidad icons in one image...). Thanks Adonis. Regards, Simon attachment: tomahawk_logo.png
[jira] Commented: (MYFACES-1692) CommandLink does not execute action if no javascript is allowed
[
https://issues.apache.org/jira/browse/MYFACES-1692?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584177#action_12584177
]
Leonardo Uribe commented on MYFACES-1692:
-
I like Simon approach, looks better that simple do not allow this, so I will
solve this issue with this idea
CommandLink does not execute action if no javascript is allowed
---
Key: MYFACES-1692
URL: https://issues.apache.org/jira/browse/MYFACES-1692
Project: MyFaces Core
Issue Type: Bug
Components: General
Affects Versions: 1.2.0
Environment: Tomcat 6.0, javax.faces.STATE_SAVING_METHOD=server,
org.apache.myfaces.ALLOW_JAVASCRIPT=false
Reporter: Thomas Fischer
Situation:
The tag h:commandLink action=#{someBean.someAction}
value=submit/h:commandLink is used in a jsp page, which is visited by
the user. The user clicks on the link.
Expected behaviour:
The method someBean.someAction() should be called, and the navigation rule
which matches the outcome should determine the page to be displayed.
Wrong behaviour:
The method defined in action is not called and the same jsp page is rendered
again.
I did some debugging to find the reason of this problem. It seems to me that
the server does not recognize that the click on the link is a postback. In
line 172 in org.apache.myfaces.renderkit.html.HtmlResponseStateManager, the
HTTP Parameter ResponseStateManager.VIEW_STATE_PARAM is checked for
existence. If it is there, the request is a callback, and if it is not there,
the request is not treated as postback. This parameter is not encoded in the
link rendered by h:commandLink, thus the request is not treated as a
postback, and the page is just rendered again.
If javaScript rendering is allowed, this works fine because the HTTP
parameter ResponseStateManager.VIEW_STATE_PARAM is rendered as a hidden input
field, and the javascript code does a form submit.
It seems to me that the problem could be solved by adding the parameter
ResponseStateManager.VIEW_STATE_PARAM to the generated link (but I did not
check it).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-822) Add additional accessibility features to skinning
[ https://issues.apache.org/jira/browse/TRINIDAD-822?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584192#action_12584192 ] Andy Schwartz commented on TRINIDAD-822: The patch adds several new APIs: - The AccessibilityProfile API provides access to accessibility preferences at runtime. - getAccessibilityProfile() methods have been added to RenderingContext, RequestContext. - trinidad-config.xml now supports an accessibility-profile configuration element. This is a whitespace-separated list of accessibility profile options. Currently the two available options are high-contrast and large-fonts. Typically this will just be an EL binding (like accessibility-mode). - Skins now support @accessibility-profile rule, which allows high-contrast and large-fonts as values. Note that the AccessibilityProfile API currently exposes two properties: 1. Color contrast: This property indicates whether the user prefers high contrast vs. default contrast content. 2. Font size: This property indicates whether the user prefers large fonts vs. the default fonts. Each of these properties are defined as enumerations, allowing for future expansion. Also added an accdemo skin, and an accessibilityPofileDemo.jspx page for testing/demonstrating this new functionality. Add additional accessibility features to skinning - Key: TRINIDAD-822 URL: https://issues.apache.org/jira/browse/TRINIDAD-822 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 1.0.5-core, 1.2.4-core Reporter: Matt Cooper Assignee: Matt Cooper Attachments: TRINIDAD-822-1.2.x.patch It is important to be able to define skin settings based on accessibility policies such as: @accessibility-policy [low-vision, any-vision, high-contrast, any-contrast, keyboard, mouse, touch] If this is added then a corresponding accessibility-policy property/object for trinidad-config.xml would be needed. There is an existing accessibility-mode property/object available today so we may want to incorporate that or otherwise deprecate it if it is not possible to use it to enumerate all of the possible combinations of the above noted policies. Basically people should be able to define skin properties specific to accessibility needs. In the past the answer was to create a separate skin for each need but it is becoming apparent that this is not ideal. Take this scenario for example: The Apache MyFaces Trinidad community has spent a lot of effort working on a skin that meets all of the accessibility requirements of their customers. You're a random customer of Trinidad, working on making an app for your own organization and don't have the resources or expertise to make a skin that meets the same needs on your own. You are happy with most of what the default skin provides but you really just want to make some minor color, image, and font changes to match your organization's branding. You really just want to extend the provided skin and don't want to risk breaking accessibility needs. If you change the base styles, you'll be responsible for coming up with low-vision, high-contrast styles too. If you could somehow just change the styles that won't impact the special needs users then you can make your skin extension with much less effort--the any-contrast and any-vision @accessibility-policy would enable you to do this. Or the inverse if some third party created a skin but you needed to make some tweaks for high-contrast, low-vision, or touch-based entry users, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] Adding additional accessibility features to skinning
Gang - Just a heads up that I finally managed to get around to submitting a patch for TRINIDAD-822. The solution is pretty much along the lines that we discussed in this email thread. I did decide to go with enum properties on the AccessibilityProfile API rather than booleans, though I cheated a bit by adding boolean-based convenience methods. If you are curious about the details of the implementation, feel free to have a peek at the patch! Andy
[jira] Updated: (TRINIDAD-822) Add additional accessibility features to skinning
[ https://issues.apache.org/jira/browse/TRINIDAD-822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Andy Schwartz updated TRINIDAD-822: --- Status: Patch Available (was: Open) Add additional accessibility features to skinning - Key: TRINIDAD-822 URL: https://issues.apache.org/jira/browse/TRINIDAD-822 Project: MyFaces Trinidad Issue Type: Improvement Components: Skinning Affects Versions: 1.0.5-core, 1.2.4-core Reporter: Matt Cooper Assignee: Matt Cooper Attachments: TRINIDAD-822-1.2.x.patch It is important to be able to define skin settings based on accessibility policies such as: @accessibility-policy [low-vision, any-vision, high-contrast, any-contrast, keyboard, mouse, touch] If this is added then a corresponding accessibility-policy property/object for trinidad-config.xml would be needed. There is an existing accessibility-mode property/object available today so we may want to incorporate that or otherwise deprecate it if it is not possible to use it to enumerate all of the possible combinations of the above noted policies. Basically people should be able to define skin properties specific to accessibility needs. In the past the answer was to create a separate skin for each need but it is becoming apparent that this is not ideal. Take this scenario for example: The Apache MyFaces Trinidad community has spent a lot of effort working on a skin that meets all of the accessibility requirements of their customers. You're a random customer of Trinidad, working on making an app for your own organization and don't have the resources or expertise to make a skin that meets the same needs on your own. You are happy with most of what the default skin provides but you really just want to make some minor color, image, and font changes to match your organization's branding. You really just want to extend the provided skin and don't want to risk breaking accessibility needs. If you change the base styles, you'll be responsible for coming up with low-vision, high-contrast styles too. If you could somehow just change the styles that won't impact the special needs users then you can make your skin extension with much less effort--the any-contrast and any-vision @accessibility-policy would enable you to do this. Or the inverse if some third party created a skin but you needed to make some tweaks for high-contrast, low-vision, or touch-based entry users, etc. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: [Trinidad] Adding additional accessibility features to skinning
Thank you Andy On Tue, Apr 1, 2008 at 9:59 AM, Andy Schwartz [EMAIL PROTECTED] wrote: Gang - Just a heads up that I finally managed to get around to submitting a patch for TRINIDAD-822. The solution is pretty much along the lines that we discussed in this email thread. I did decide to go with enum properties on the AccessibilityProfile API rather than booleans, though I cheated a bit by adding boolean-based convenience methods. If you are curious about the details of the implementation, feel free to have a peek at the patch! Andy
Re: [Tobago] Merging maven-apt-plugin with Codehaus'
Hi Bernd, I've finished with the major changes in tidying up the Codehaus apt-maven-plugin if you fancy taking a look: http://svn.codehaus.org/mojo/trunk/sandbox/apt-maven-plugin/ Major changes: - Manually merged in any exclusive features I could see in the Tobago version - Big refactor to simplify code - Added integration test intrastructure with a few tests to start with - Supported plugin dependencies (TOBAGO-130/MOJO-1072) I've also just removed any Java compliation support from the plugin since I couldn't see any advantage of duplicating this with the maven-compiler-plugin. Can you see any problems with that? A few further points I'd like to ask you about: 1) Do you use extra source roots? I'm tempted to remove this parameter since it tends to go against the standard of using the project's current source roots. 2) Do you use the resource target path parameter? I'd have thought that the apt factory should control this. 3) Do you use the target files parameter? I wouldn't have thought you'd need such fine-grained control of source files to process when using Maven. 4) Do you use staleness checking? I'm not too convinced by this implementation since it checks source files against class files to determine staleness. This is a problem when using -nocompile as the class file timestamp has no correlation with the staleness of generated resources. Auto-compiling IDEs then also pose a further problem since they never let a class file become stale, hence resources are never generated with apt. I'd be interested in any feedback on using this plugin with Tobago. Feel free to move any existing JIRA issues across to the apt component in MOJO: http://jira.codehaus.org/browse/MOJO/component/13192 Cheers, Mark On 27/03/2008, Bernd Bohmann [EMAIL PROTECTED] wrote: Ok, I'm waiting for your reply. Regards Bernd Mark Hobson schrieb: Hi Bernd, Thanks for the reply. I glad that you agree that merging the plugins is the way forward. I've started manually adding the features unique to the Tobago plugin to the Codehaus version and am currently tidying up the code. It's probably best to wait until I've finished doing that before submitting any patches; I'll let you know when it's ready for trialling with Tobago. Cheers, Mark On 27/03/2008, Bernd Bohmann [EMAIL PROTECTED] wrote: Hello Mark, I think merging the plugin is a good idea. I hope I get enough time to prepare patches for the missing features in the codehaus apt plugin. The fist step would be using the apt-maven-plugin in the tobago build instead of the own plugin. Regards Bernd Mark Hobson schrieb: Hi there, I was looking for a Maven APT plugin and came across Tobago's and also one over at Codehaus [1]. I'm not aware of the history of these two plugins, but they both appear to be forked from the same codebase and been worked on over time. I'd like to see these plugins merged together to avoid duplicating efforts by both parties; if this of interest? I think the natural home for this plugin would be at Codehaus, which Tobago could easily use. I'm happy to help out merging the two codebases together since I have commit rights over at Codehaus. I've already fixed TOBAGO-130 as MOJO-1072 [2], so hopefully this merge will be beneficial to both parties. Let me know if you're interested and how you'd see the process moving forward. Cheers, Mark [1] http://mojo.codehaus.org/apt-maven-plugin/ [2] http://jira.codehaus.org/browse/MOJO-1072
[Orchestra] Core15 release ?
Hi, are there any plans to release the core15 module ? Thanks, Matthias -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: [Orchestra] Core15 release ?
Hi! are there any plans to release the core15 module ? soon :-) I would like open-source the @ConversationName annotation in core15 and then we should be ready. Volunteering doing the release then? Ciao, Mario
JspStateManagerImpl into shared?
Hi! Just to reiterate: I hate shared! ;-) Seriously, it seems that Orchestra has to implement a StateManager which holds the view state in the conversationContext instead of the session. At the moment it seems that large portions of JspStateManagerImpl can be reused, but requires to copy it over into Orchestra. With slight refactoring of JspStateManagerImpl it should be possible to just replace the actual storing/loading stuff. Does this qualify to move JspStateManagerImpl into shared? Or should I better copy the source over? Ciao, Mario
Re: svn commit: r643513 - in /myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin
Hi Leonardo,
As I'm no longer the only person committing to the builder-plugin
project, feel free to rename the branch if you want.
Regards, Simon
On Tue, 2008-04-01 at 18:50 +, [EMAIL PROTECTED] wrote:
Author: lu4242
Date: Tue Apr 1 11:49:55 2008
New Revision: 643513
URL: http://svn.apache.org/viewvc?rev=643513view=rev
Log:
Generate Tag classes with velocity, step 1
Added:
myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin/src/main/resources/META-INF/tagClass11.vm
myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin/src/main/resources/META-INF/tagClassMacros11.vm
Modified:
myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin/pom.xml
myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin/src/main/java/org/apache/myfaces/buildtools/maven2/plugin/builder/MakeTagsMojo.java
myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin/src/main/java/org/apache/myfaces/buildtools/maven2/plugin/builder/model/ComponentMeta.java
Modified:
myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin/pom.xml
URL:
http://svn.apache.org/viewvc/myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin/pom.xml?rev=643513r1=643512r2=643513view=diff
==
---
myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin/pom.xml
(original)
+++
myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin/pom.xml
Tue Apr 1 11:49:55 2008
@@ -134,12 +134,19 @@
artifactIdvelocity/artifactId
version1.5/version
/dependency
-
+
+dependency
+ groupIdcommons-collections/groupId
+ artifactIdcommons-collections/artifactId
+ version3.1/version
+/dependency
+!--
dependency
groupIdorg.codehaus.plexus/groupId
artifactIdplexus-velocity/artifactId
version1.1.7/version
/dependency
+ --
dependency
groupIdlog4j/groupId
Modified:
myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin/src/main/java/org/apache/myfaces/buildtools/maven2/plugin/builder/MakeTagsMojo.java
URL:
http://svn.apache.org/viewvc/myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin/src/main/java/org/apache/myfaces/buildtools/maven2/plugin/builder/MakeTagsMojo.java?rev=643513r1=643512r2=643513view=diff
==
---
myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin/src/main/java/org/apache/myfaces/buildtools/maven2/plugin/builder/MakeTagsMojo.java
(original)
+++
myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin/src/main/java/org/apache/myfaces/buildtools/maven2/plugin/builder/MakeTagsMojo.java
Tue Apr 1 11:49:55 2008
@@ -24,19 +24,21 @@
import java.io.OutputStreamWriter;
import java.io.Writer;
import java.util.Iterator;
+import java.util.Properties;
import java.util.logging.Logger;
-import org.apache.maven.archetype.exception.ArchetypeGenerationFailure;
import org.apache.maven.plugin.AbstractMojo;
import org.apache.maven.plugin.MojoExecutionException;
import org.apache.maven.project.MavenProject;
import
org.apache.myfaces.buildtools.maven2.plugin.builder.model.ComponentMeta;
import org.apache.myfaces.buildtools.maven2.plugin.builder.model.Model;
import
org.apache.myfaces.buildtools.maven2.plugin.builder.utils.BuildException;
+import org.apache.velocity.Template;
import org.apache.velocity.VelocityContext;
+import org.apache.velocity.app.VelocityEngine;
import org.apache.velocity.context.Context;
import org.codehaus.plexus.util.IOUtil;
-import org.codehaus.plexus.velocity.VelocityComponent;
+import org.codehaus.plexus.util.StringUtils;
/**
* Maven goal to generate java source code for Component tag classes.
@@ -72,10 +74,14 @@
private String metadataFile = classes/META-INF/myfaces-metadata.xml;
/**
- * @parameter expression=src/main/java-templates
- * @required
+ * @parameter expression=src/main/resources/META-INF
*/
private File templateSourceDirectory;
+
+/**
+ * @parameter
+ */
+private String templateTagName;
/**
* @parameter
expression=${project.build.directory}/maven-faces-plugin/main/java
@@ -109,11 +115,6 @@
* @parameter
*/
private String jsfVersion;
-
-/**
- * @component
- */
-private VelocityComponent velocity;
/**
* Execute the Mojo.
@@ -139,18 +140,64 @@
}
}
+private VelocityEngine initVelocity() throws MojoExecutionException
+{
+
+Properties p = new Properties();
+
+p.setProperty( resource.loader, file, class );
+p.setProperty( velocimacro.library,
ExternalContextUtils in commons
Hey guys, Do to popular demand, I uploaded the ExternalContextUtils to the commons project. It's a bit different from Trinidad's and includes some extra request types to be able to handle JSR-286 as well as JSR-301. Like everything else in commons right now, there are no test cases or anything, but it's there. Let me know if people don't like what I've done to the API, I can still go back and change things if need be, but having used Trinidad's externalContextUtils for some time, I've basically taken everything in my wishlist and added it to the commons class. Thanks, Scott
Re: [Orchestra] Core15 release ?
On Tue, Apr 1, 2008 at 9:15 PM, Mario Ivankovits [EMAIL PROTECTED] wrote: Hi! are there any plans to release the core15 module ? soon :-) I would like open-source the @ConversationName annotation in core15 and then we should be ready. Volunteering doing the release then? yes. do you mind next week ? During ApacheCon EU I can do it. -M Ciao, Mario -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
[jira] Created: (TRINIDAD-1036) Client Color Converter's getFormatHint() returns empty string for the hints.
Client Color Converter's getFormatHint() returns empty string for the hints.
-
Key: TRINIDAD-1036
URL: https://issues.apache.org/jira/browse/TRINIDAD-1036
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Yee-Wah Lee
Priority: Minor
1. Sample code to create a button which, when clicked, gets the format hint for
a color field and displays it in an output text.
f:verbatim
script language=javascript
function getHint ()
{
var colorField = document.getElementById (sic1);
var format = _getColorFieldFormat (colorField);
var colorHint = document.getElementById (help_sic1);
colorHint.textContent = format.getFormatHint ();
}
/script
/f:verbatim
tr:inputColor id=sic1 chooseId=cp1
label=Enter or select color from palette below
f:facet name=help
tr:outputText id=help_sic1 value=Format hint goes here if
button is clicked/
/f:facet
/tr:inputColor
tr:commandButton onclick=getHint(this); return false; text=Click
for color hint/
2. Run the page and click the button - the output text is updated with the
string Example Format: . It should instead reflect the patterns for the
inputColor which are defaulted in the example above, i.e. Example Format:
RRGGBB, #RRGGBB, r,g,b
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1036) Client Color Converter's getFormatHint() returns empty string for the hints.
[
https://issues.apache.org/jira/browse/TRINIDAD-1036?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584295#action_12584295
]
Yee-Wah Lee commented on TRINIDAD-1036:
---
I think this used to be work before the changes in TRINIDAD-829 and
TRINIDAD-873.
Between these two changes, the method TrFastMessageFormatUtils.format() now
works with strings whereas the color converter uses an Array of strings , e.g.
[RRGGBB, #RRGGBB, r,g,b].
Client Color Converter's getFormatHint() returns empty string for the hints.
-
Key: TRINIDAD-1036
URL: https://issues.apache.org/jira/browse/TRINIDAD-1036
Project: MyFaces Trinidad
Issue Type: Bug
Components: Components
Reporter: Yee-Wah Lee
Priority: Minor
1. Sample code to create a button which, when clicked, gets the format hint
for a color field and displays it in an output text.
f:verbatim
script language=javascript
function getHint ()
{
var colorField = document.getElementById (sic1);
var format = _getColorFieldFormat (colorField);
var colorHint = document.getElementById (help_sic1);
colorHint.textContent = format.getFormatHint ();
}
/script
/f:verbatim
tr:inputColor id=sic1 chooseId=cp1
label=Enter or select color from palette below
f:facet name=help
tr:outputText id=help_sic1 value=Format hint goes here if
button is clicked/
/f:facet
/tr:inputColor
tr:commandButton onclick=getHint(this); return false;
text=Click for color hint/
2. Run the page and click the button - the output text is updated with the
string Example Format: . It should instead reflect the patterns for the
inputColor which are defaulted in the example above, i.e. Example Format:
RRGGBB, #RRGGBB, r,g,b
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-1032) New component: tr:panelStretchLayout
[ https://issues.apache.org/jira/browse/TRINIDAD-1032?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12584301#action_12584301 ] Andrew Robinson commented on TRINIDAD-1032: --- New proposal, use the panelBorderLayout instead. Add these attributes: layout (table/positioned): if positioned, use absolute positioned DIVs to render the panel. Only if layout is positioned are the following new attributes used: topHeight: the CSS height of the top facet to use if present topInnerHeight: the CSS height of the inner top facet to use if present bottomHeight: the CSS height of the bottom facet to use if present bottomInnerHeight: the CSS height of the inner bottom facet to use if present To save being verbose, other attributes: leftWidth, innerLeftWidth, startWidth, innerStartWidth, rightWidth, innerRightWidth, endWidth, innerEndWidth. Since this would be an enhancement, not a new component, it would not be a sandbox, but a core change. New component: tr:panelStretchLayout Key: TRINIDAD-1032 URL: https://issues.apache.org/jira/browse/TRINIDAD-1032 Project: MyFaces Trinidad Issue Type: New Feature Components: Components Affects Versions: 1.0.7-core, 1.2.7-core Reporter: Andrew Robinson Assignee: Andrew Robinson Add a new component, to the trinidad-sandbox first, that is similar to the panelBorderLayout. Unlike this component the panelStretchLayout would be rendered using DIV instead of TABLE and would be able to stretch horizontally and vertically. The main reason I am proposing this is to be able to produce a component for the new demo that can frame the browser viewport and have the demo page content in a center-scrolling DIV. This way there can be a header, footer on the page that fits on one page. For those that are familiar with the Oracle panelStretchLayout, this one would not be as robust. I do not think it would be in the scope to automatically stretch the children and I do not think that it would be needed to have an auto-height for the original version. The component would have a top, bottom, left, and right facets and use the children for the center. The facet sizes (height and width) would be specified using attributes. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: svn commit: r643513 - in /myfaces/myfaces-build-tools/branches/skitching/myfaces-builder-plugin
Hi Simon Ok, I have renamed as builder_plugin. The idea is finish this plugin as fast as we can. I have some questions but I will do this on another mail. regards Leonardo Uribe
[ANNOUNCE] Release of Apache MyFaces Buildtools Archetypes 1.0.1.
The Apache MyFaces team is pleased to announce the release of Apache MyFaces Buildtools Archetypes 1.0.1. Apache MyFaces Buildtools Archetypes are several archetypes using myfaces projects to start coding web apps with this line: mvn archetype:generate -DarchetypeCatalog=http://myfaces.apache.org Type groupId, artifactId, package, version and that's all! to run with jetty mvn clean jetty:run portlet archetype mvn clean -PjettyConfig jetty:run Apache MyFaces Trinidad is available in the central Maven repository under Group ID org.apache.myfaces.buildtools. Enjoy! Leonardo Uribe
Re: MyfacesBuilderPlugin
Hi The problem with xml files to make faces-plugin test work is now fixed. I have a question about how myfaces-metadata works. The idea is have one file per jar, and when the model is readed, it should scan every artifact and merge it with the generated myfaces-metadata.xml. I'm right or wrong (This is what I'm doing right now, and in my opinion is the preferred way)? regards Leonardo Uribe
[jira] Updated: (TRINIDAD-1037) Trinidad tree/treeTable expand all handling
[ https://issues.apache.org/jira/browse/TRINIDAD-1037?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Kamran Kashanian updated TRINIDAD-1037: --- Status: Patch Available (was: Open) Trinidad tree/treeTable expand all handling --- Key: TRINIDAD-1037 URL: https://issues.apache.org/jira/browse/TRINIDAD-1037 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.7-core Environment: All Reporter: Kamran Kashanian Fix For: 1.2.7-core Attachments: trunk_1.2.x.patch Original Estimate: 1h Remaining Estimate: 1h The Trinidad tree/treeTable components include logic to protect against an unbounded expand all action. The expand all action can be expensive for large trees. The method org.apache.myfaces.trinidad.component.HierarchyUtils.__handleBroadcast() checks for a RowDisclosure event, and tries to determine the # of expanded nodes by looping over the newly expanded row keys. However, looping over the RowKeySet, which is bound to the tree model, can be expensive. Instead, the method should call getSize() on the expanded row key set, and loop only if an unknown size (size = -1) is returned. Providing a patch for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TRINIDAD-1037) Trinidad tree/treeTable expand all handling
Trinidad tree/treeTable expand all handling --- Key: TRINIDAD-1037 URL: https://issues.apache.org/jira/browse/TRINIDAD-1037 Project: MyFaces Trinidad Issue Type: Improvement Affects Versions: 1.2.7-core Environment: All Reporter: Kamran Kashanian Fix For: 1.2.7-core Attachments: trunk_1.2.x.patch The Trinidad tree/treeTable components include logic to protect against an unbounded expand all action. The expand all action can be expensive for large trees. The method org.apache.myfaces.trinidad.component.HierarchyUtils.__handleBroadcast() checks for a RowDisclosure event, and tries to determine the # of expanded nodes by looping over the newly expanded row keys. However, looping over the RowKeySet, which is bound to the tree model, can be expensive. Instead, the method should call getSize() on the expanded row key set, and loop only if an unknown size (size = -1) is returned. Providing a patch for this. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
