[jira] Commented: (MYFACES-1861) Duplicated ids exception for 2 controls with same id and one of them is not rendered

[ https://issues.apache.org/jira/browse/MYFACES-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588920#action_12588920 ] Simon Kitching commented on MYFACES-1861: - I don't believe this is a bug.

[jira] Commented: (MYFACES-1863) HTML generated with duplicate Ids when using forceId=true

[ https://issues.apache.org/jira/browse/MYFACES-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12588921#action_12588921 ] Simon Kitching commented on MYFACES-1863: - This bug should be assigned to

Re: [Trinidad] Required/message icon positions

Jeanne Waldman wrote: What's the JIRA number? What exactly are your requirements? I wouldn't over-design it by putting in too many hooks. - Jeanne Here's the Jira issue: https://issues.apache.org/jira/browse/TRINIDAD-755 Any yes, it is more complicated than it feels it should be. We

Re: [Trinidad] private / protected final methods in renderers

Blake Sullivan wrote: Stephen Friedrich said the following On 4/13/2008 11:26 PM PT: Blake, in general you point of view is a very theoretical one from a high ebony tower. Do you say so in english? ;-) In English, it is usually ivory tower, but, if you think that I'm evil, ebony tower might

Re: [Trinidad] private / protected final methods in renderers

Hi An extreme example is JBoss Seam, where almost all of the internals are implemented using their own component framework. I can always replace default behaviour by replacing components. Of course when upgrading from version 1.1 to 2.0 I had to modify my changed components, too, but

[jira] Commented: (MYFACES-1861) Duplicated ids exception for 2 controls with same id and one of them is not rendered

[ https://issues.apache.org/jira/browse/MYFACES-1861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589007#action_12589007 ] Guy Bashan commented on MYFACES-1861: - Sorry, I am not familiar with the JSF spec (I

Re: tobago island logo :)

Hi Udo, Sorry for this late response ... Now I'm little busy now, but the Tobago logo issue remain opened. ... in any case, more time is more time to thinking ... :) Best regards, Adonis On Tue, Apr 8, 2008 at 4:08 PM, Udo Schnurpfeil [EMAIL PROTECTED] wrote: Hi Adonis, I agree that a logo

Issue with myfaces 1.2.2/1.2.0 and acegi

Hi guys, I'm using form login with acegi and the following setup works on my myfaces 1.1.5 project: security.xml bean id=authenticationProcessingFilter class=org.acegisecurity.ui.webapp.AuthenticationProcessingFilter property name=authenticationManager ref=authenticationManager/

[jira] Commented: (MYFACES-1863) HTML generated with duplicate Ids when using forceId=true

[ https://issues.apache.org/jira/browse/MYFACES-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589014#action_12589014 ] Guy Bashan commented on MYFACES-1863: - Why does forceId sucks (beside the fact it

[jira] Commented: (MYFACES-1863) HTML generated with duplicate Ids when using forceId=true

[ https://issues.apache.org/jira/browse/MYFACES-1863?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589039#action_12589039 ] Simon Kitching commented on MYFACES-1863: - You might find this page useful:

[jira] Commented: (TOBAGO-325) Popups background not disabled

[ https://issues.apache.org/jira/browse/TOBAGO-325?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589044#action_12589044 ] Tobias Glensk commented on TOBAGO-325: -- We just tested it with version 1.0.16. You can

[jira] Created: (TOMAHAWK-1232) EqualValidator: 'for' attribute doesn't work correctly in conjunction with RichFaces

EqualValidator: 'for' attribute doesn't work correctly in conjunction with RichFaces Key: TOMAHAWK-1232 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1232

Re: [Trinidad] private / protected final methods in renderers

Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default access modifier methods in components renderer and components class. In UIXTable, createCollectionModel is final method, due to this we can not associate our own model

[jira] Reopened: (TOBAGO-325) Popups background not disabled

[ https://issues.apache.org/jira/browse/TOBAGO-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helmut Swaczinna reopened TOBAGO-325: - New patch supplied Popups background not disabled --

[jira] Updated: (TOBAGO-325) Popups background not disabled

[ https://issues.apache.org/jira/browse/TOBAGO-325?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Helmut Swaczinna updated TOBAGO-325: Status: Patch Available (was: Reopened) Popups background not disabled

An apology

I wish to withdraw and clarify the scope of my apology earlier on the [EMAIL PROTECTED] mailing list regarding my overreaction and emotional response to the replies made by Blake Sullivan on the private / protected final methods in renderers thread. I am just as guilty or more guilty in regards to

dojo quo vadis

hello everyone I just wanted to drop a short note, start a discussion here. I was busy the last few weeks regarding dojo after getting weblets 1.0 out of the door. Well here is a plan. As you all know we currently have dojo in Tomahawk, well the main issue is, this is a huge dependency. I

Re: [Trinidad] private / protected final methods in renderers

On Tue, Apr 15, 2008 at 8:11 PM, Andy Schwartz [EMAIL PROTECTED] wrote: Ravi, All - On Tue, Apr 15, 2008 at 11:01 AM, Ravindra Adireddy [EMAIL PROTECTED] wrote: Hi all, Extending complex trinidad components like table, treeTable is complex job due to final, private and default

Re: [Trinidad] private / protected final methods in renderers

I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the renderkit using renderer types is a desired improvement to the core renderers. If it is, there is an open discussion that Simon has addressed on

Re: [Trinidad] private / protected final methods in renderers

Perhaps you should file a JIRA ticket and give us a prototype so that we can discuss a more concrete example. Scott Andrew Robinson wrote: I agree partially with ending this thread, but not 100%. The thread still lives on as a discussion to see if having sub-renderers instantiated via the

Re: [Trinidad] private / protected final methods in renderers

There is already code in: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting As for JIRA, I don't feel that that is a place for discussions. If a decision is made, then I will create an issue. -Andrew On Tue, Apr 15, 2008 at 12:30 PM, Scott O'Bryan [EMAIL

Re: [Trinidad] private / protected final methods in renderers

I'll start a new thread though to clean up the email mess On Tue, Apr 15, 2008 at 12:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: There is already code in: http://svn.apache.org/viewvc/myfaces/trinidad/branches/ar_subRendererPerfTesting As for JIRA, I don't feel that that is a place for

Re: An apology

Andrew, I'm sorry that I let this get so out of control. One of my worst faults (at least according to Gabrielle Crawford, who doesn't know the least of it), is that I don't +1 the parts that I agree with enough and instead comment on the parts that I want changed. As Gabrielle said once

Re: An apology

Thank you On Tue, Apr 15, 2008 at 12:56 PM, Blake Sullivan [EMAIL PROTECTED] wrote: Andrew, I'm sorry that I let this get so out of control. One of my worst faults (at least according to Gabrielle Crawford, who doesn't know the least of it), is that I don't +1 the parts that I agree with

[Trinidad] Idea to register sub-renderers in the faces configuration.

In order to improve the ability to customize the rendering of Trinidad components, an idea was proposed in the private / protected final methods in renderers thread. This idea is to replace existing code that has hard references to sub renderers (directly instantiating Trinidad renderers from

Re: [Trinidad] private / protected final methods in renderers

The new thread has the subject: [Trinidad] Idea to register sub-renderers in the faces configuration. On Tue, Apr 15, 2008 at 12:39 PM, Andrew Robinson [EMAIL PROTECTED] wrote: I'll start a new thread though to clean up the email mess On Tue, Apr 15, 2008 at 12:37 PM, Andrew Robinson [EMAIL

Re: [Trinidad] private / protected final methods in renderers

Thanks. I think that would be best. :) Andrew Robinson wrote: I'll start a new thread though to clean up the email mess On Tue, Apr 15, 2008 at 12:37 PM, Andrew Robinson [EMAIL PROTECTED] wrote: There is already code in:

Re: dojo quo vadis

On Tue, Apr 15, 2008 at 12:08 PM, Werner Punz [EMAIL PROTECTED] wrote: hello everyone I just wanted to drop a short note, start a discussion here. I was busy the last few weeks regarding dojo after getting weblets 1.0 out of the door. Well here is a plan. As you all know we currently have

Re: [Trinidad] private / protected final methods in renderers

Hi guys, Dividing this thread is the best thing. But I think we either reached a conclusion or we should start a vote about final/private methods * We can change current final/private renderer methods to not final / protected ones, only when needed, on specific use cases !!!* If somebody still

Re: [Trinidad] private / protected final methods in renderers

I am agreement with the others that would like to see case by case JIRA issues to choose to open up renderers since it is considered taboo (spelling it right this time). On Tue, Apr 15, 2008 at 2:40 PM, Cristi Toth [EMAIL PROTECTED] wrote: Hi guys, Dividing this thread is the best thing. But

Re: [Trinidad] private / protected final methods in renderers

What I meant with on specific use cases was case by case So I agree with this approach. But I don't want to get the same negative feedback with the same arguments on cases where it's really useful to have protected methods. Oh! One more thing: we also agree that renderers are not 100% guaranteed

Re: [Trinidad] private / protected final methods in renderers

I like your suggestion on a WIKI to state Trinidad's official stance on sub-classing renderers. In there something about it not at all supported / use at your own risk and if ppl. have a good desire to make something non-final or protected on what the process is to get that discussed and maybe

Re: Hazem Saleh - Invitation to be a MyFaces Committer

Dear Cagatay, - I already signed and sent the ICLA. - Here are my first three choices : 1. hazems 2. hazem.saleh 3. hazem_saleh Thank you! On Mon, Apr 7, 2008 at 3:29 PM, Cagatay Civici [EMAIL PROTECTED] wrote: Dear Hazem, On behalf of the Apache MyFaces PMC, I would like to extend an

Re: [Trinidad] private / protected final methods in renderers

Andrew Robinson said the following On 4/15/2008 1:42 PM PT: I am agreement with the others that would like to see case by case JIRA issues to choose to open up renderers since it is considered taboo (spelling it right this time). Or, more specifically, that subclassing the current Renderers

[jira] Commented: (TRINIDAD-1043) Convert legacy XSS files to CSS

[ https://issues.apache.org/jira/browse/TRINIDAD-1043?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589256#action_12589256 ] Jeanne Waldman commented on TRINIDAD-1043: -- we should also support @import, or

LinkRenderer calls writeURIAttribute... but why?

Hi there, I'm wondering if anyone knows why the links id needs to call writeURIAttribute instead of writeAttribute. The code is in GoLinkRenderer. The comment says that they are URI attributes, but it doesn't say why. I have some of my own code that does the same thing for links , but it

[jira] Commented: (TRINIDAD-1) Add @agent support for skin properties

[ https://issues.apache.org/jira/browse/TRINIDAD-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589259#action_12589259 ] Matt Cooper commented on TRINIDAD-1: I would like to see this supported on all @-rules,

[jira] Issue Comment Edited: (TRINIDAD-1) Add @agent support for skin properties

[ https://issues.apache.org/jira/browse/TRINIDAD-1?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=12589259#action_12589259 ] mattcooper edited comment on TRINIDAD-1 at 4/15/08 3:17 PM: - I

[jira] Reopened: (MYFACES-1859) Optimize javascript following good practices

[ https://issues.apache.org/jira/browse/MYFACES-1859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Leonardo Uribe reopened MYFACES-1859: - Apply suggestions of Stefan Schuster about this Optimize javascript following good

Re: [Trinidad] Required/message icon positions

Hi, Stephen Friedrich wrote, On 4/15/2008 12:59 AM PT: Jeanne Waldman wrote: What's the JIRA number? What exactly are your requirements? I wouldn't over-design it by putting in too many hooks. - Jeanne Here's the Jira issue: https://issues.apache.org/jira/browse/TRINIDAD-755 I couldn't

[TRINIDAD] LinkRenderer calls writeURIAttribute... but why? (was: LinkRenderer calls writeURIAttribute... but why?)

Hey Jeanne, we ran across these quite a while ago when we did the initial portal compatibility enhancements. I really didn't look at it too much at the time, but Adam seemed to think that these were necessary for bookmarks.. I managed to find this thread:

[VOTE] release for myfaces build tools plugins 1.0.0

Hi, I was running the needed tasks to get the 1.0.0 release of Apache MyFaces Build Tools out. This release is necessary to release myfaces 1.2.3 Please note that this vote concerns all of the following parts: 1. Maven artifact group org.apache.myfaces.buildtools v1.0.0 (only plugins) [1] The

Re: [VOTE] release for myfaces build tools plugins 1.0.0

+1 On Tue, Apr 15, 2008 at 8:19 PM, Leonardo Uribe [EMAIL PROTECTED] wrote: Hi, I was running the needed tasks to get the 1.0.0 release of Apache MyFaces Build Tools out. This release is necessary to release myfaces 1.2.3 Please note that this vote concerns all of the following parts:

Re: dojo quo vadis

Leonardo Uribe schrieb: I would like to see how tomahawk directory looks like after the modification, only to take this into account. One question is if dojo components should be 1.1 or 1.2 compatible (the difference is on the generation of component and tag classes), or both. Well for