[jira] Created: (TOBAGO-597) TLD file for tx facelets extensions to include in eclipse to get coding assistence and code completition
TLD file for tx facelets extensions to include in eclipse to get coding assistence and code completition Key: TOBAGO-597 URL: https://issues.apache.org/jira/browse/TOBAGO-597 Project: MyFaces Tobago Issue Type: Improvement Components: Facelets Affects Versions: 1.0.13 Reporter: Guido Dubois -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-572) Duplicate component id with
[
https://issues.apache.org/jira/browse/TOBAGO-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559371#action_12559371
]
Guido Dubois commented on TOBAGO-572:
-
I tested it with:
Tobago 1.0.12 Tobago 1.0.13 Tobago
1.0.14 snap
Facelets 1.1.12x x
x
Facelets 1.1.13x x
x
Facelets 1.1.14x x
x
(x) I get this error in all cases
> Duplicate component id with
> ---
>
> Key: TOBAGO-572
> URL: https://issues.apache.org/jira/browse/TOBAGO-572
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Facelets
>Affects Versions: 1.0.13
> Environment: Facelets 1.1.12, MyFaces 1.1.6 snap (11.09.2007), Tobago
> 1.0.13 snap (10.12.2007)
>Reporter: Guido Dubois
> Attachments: tobago_faceletsexample.war
>
>
> The first time the page is rendered correctly, but if you go back you will
> get an exception
> java.lang.IllegalStateException: Client-id : _id54 is duplicated in the faces
> tree. Component : page:_id54, path: {Component-Path : [Class:
> org.apache.myfaces.tobago.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: org.apache.myfaces.tobago.component.UIPage,Id:
> page][Class: org.apache.myfaces.tobago.component.UICell,Id: _id27][Class:
> org.apache.myfaces.tobago.component.UIBox,Id: _id29][Class:
> org.apache.myfaces.tobago.component.UICell,Id: _id54]}
> I will add a sample...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (TOMAHAWK-1176) XmlTemplate fails when filename contains spaces on WindowsXP
XmlTemplate fails when filename contains spaces on WindowsXP Key: TOMAHAWK-1176 URL: https://issues.apache.org/jira/browse/TOMAHAWK-1176 Project: MyFaces Tomahawk Issue Type: Bug Components: XmlTemplate Affects Versions: 1.1.7-SNAPSHOT Environment: Windows XP SP2 Reporter: Jayson Raymond Fix For: 1.1.7-SNAPSHOT XmlTemplate uses URLs. From this it extracts the filename and uses this to load a file. WindowsXP at least doesn't understand the %20 encoding for spaces in a filename. Attached patch replaces instances of %20 in URL filepath with " " in filepath use to open file. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1794) MF Core causes resources not found(404) errors (recently also corrected in Sun RI for JSF 1.2)
[ https://issues.apache.org/jira/browse/MYFACES-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559273#action_12559273 ] Wolf Benz commented on MYFACES-1794: After check-out of MyFacesCore-trunk_1.2.x, as M2 project, trying mvn install, I get this Maven error: "[INFO] Error scanning for extensions: Error building model lineage in order to pre-scan for extensions: Cannot find artifact for parent POM: org.apache.myfaces:myfaces::5-SNAPSHOT for project org.apac he.myfaces.core:myfaces-core-project:pom:1.2.1-SNAPSHOT " I changed the local pom by adding this repo Apache Repo http://svn.apache.org/repos/asf/myfaces , but to no avail. I don't see the myfaces-core-project either. What am I doing wrong? > MF Core causes resources not found(404) errors (recently also corrected in > Sun RI for JSF 1.2) > -- > > Key: MYFACES-1794 > URL: https://issues.apache.org/jira/browse/MYFACES-1794 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 1.2.0 > Environment: JSF 1.2 (failures mostly happen with extensions like > with Trinidad e.g.) >Reporter: Wolf Benz > Fix For: 1.2.1 > > > Cf. the MF mailing list: topics like "Dialog issue during ADF->Trinidad > migration" > I came across it using tr:inputDate but in the list topic I mentioned above, > so I first thought it was a Trinidad issue, but people more knowledgeable > with the JSF spec(Adam Winer) pointed out it was a MF 1.2 core issue, and > that the Sun RI had also sufferend from it, yet in the RI, this bug has > recently been corrected. > The error I got was when clicking the calendar icon and expecting a cal > popup. Instead I got: > "description The requested resource (.../__ADFv__.jsp) is not available." > As it potentially affects a lot of other components beyond this trinidad one, > I marked it major as these components just don't work anymore. > E.g. MF mailing list with topic "RE: [Trinidad] HTTP 404 (file not found) > while using DialogFramework" points that out. > --Wolf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-464) Create a real tx extension taglib for facelets
[ https://issues.apache.org/jira/browse/TOBAGO-464?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559253#action_12559253 ] Bernd Bohmann commented on TOBAGO-464: -- Can you add the tld file to a new issue, please > Create a real tx extension taglib for facelets > -- > > Key: TOBAGO-464 > URL: https://issues.apache.org/jira/browse/TOBAGO-464 > Project: MyFaces Tobago > Issue Type: Improvement > Components: Facelets >Reporter: Bernd Bohmann >Assignee: Bernd Bohmann > Fix For: 1.0.12 > > Attachments: tobago-facelet-extension.tld > > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (TOBAGO-596) Duplicate component Id exception with tc:date and tx:date with facelets
Duplicate component Id exception with tc:date and tx:date with facelets --- Key: TOBAGO-596 URL: https://issues.apache.org/jira/browse/TOBAGO-596 Project: MyFaces Tobago Issue Type: Bug Components: Facelets Affects Versions: 1.0.13 Reporter: Bernd Bohmann Assignee: Bernd Bohmann Fix For: 1.0.14, 1.1.0 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-572) Duplicate component id with
[
https://issues.apache.org/jira/browse/TOBAGO-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559252#action_12559252
]
Bernd Bohmann commented on TOBAGO-572:
--
Can you test it with facelets 1.1.13 and facelets 1.1.14, please.
> Duplicate component id with
> ---
>
> Key: TOBAGO-572
> URL: https://issues.apache.org/jira/browse/TOBAGO-572
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Facelets
>Affects Versions: 1.0.13
> Environment: Facelets 1.1.12, MyFaces 1.1.6 snap (11.09.2007), Tobago
> 1.0.13 snap (10.12.2007)
>Reporter: Guido Dubois
> Attachments: tobago_faceletsexample.war
>
>
> The first time the page is rendered correctly, but if you go back you will
> get an exception
> java.lang.IllegalStateException: Client-id : _id54 is duplicated in the faces
> tree. Component : page:_id54, path: {Component-Path : [Class:
> org.apache.myfaces.tobago.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: org.apache.myfaces.tobago.component.UIPage,Id:
> page][Class: org.apache.myfaces.tobago.component.UICell,Id: _id27][Class:
> org.apache.myfaces.tobago.component.UIBox,Id: _id29][Class:
> org.apache.myfaces.tobago.component.UICell,Id: _id54]}
> I will add a sample...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: UIInput.resetValue()
And I sure hope it will. On Jan 15, 2008 1:03 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > but, a move to JSF 2 is MUCH bigger than to 1.2 (from 1.1) > > -M > > On Jan 15, 2008 9:57 AM, Simon Lessard <[EMAIL PROTECTED]> wrote: > > Yes, which mean that I might make such propositions or support them, but > I'm > > not the only member and I'm pretty such that some members see apparent > > backward compatibility to be a precept above anything else. > > > > > > ~ Simon > > > > > > > > On Jan 15, 2008 11:35 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > aren't you part of the EG ? > > > :-) > > > -M > > > > > > > > > > > > > > > On Jan 15, 2008 7:46 AM, Simon Lessard <[EMAIL PROTECTED] > > wrote: > > > > Personally, considering there's always backward compatibility issues > > anyway, > > > > I wouldn't mind seeing some new ones if it was to allow JSF to be > much > > > > faster, easier to use and more extensible. Like standardizing > FacesBean > > for > > > > instance. If done correctly, it would give a decent speed boost, > allow > > > > easier and more intelligent state saving as well as many other > goodies. > > I'd > > > > really like to see a way to extends the Lifecycle more easily as > well, > > maybe > > > > implying standardization of the Phase classes. Maybe adding new > phases > > as > > > > well like register resources occurring before render to push all > > > > dependencies in a rendering context and thus allowing all script > > references > > > > to be rendered in the head element thus respecting w3c. A coherence > > > > validation phase as well as a mean to execute a Callback on the > whole > > tree > > > > (to implement custom phases for example) wouldn't be unwelcome > either. > > > > Anyway, we'll see that in due time. > > > > > > > > > > > > Regards, > > > > > > > > ~ Simon > > > > > > > > > > > > > > > > On Jan 15, 2008 10:33 AM, Matthias Wessendorf < [EMAIL PROTECTED]> > > wrote: > > > > > nice... > > > > > > > > > > > > > > > > > > > > > > > > > On Jan 15, 2008 7:23 AM, Manfred Geiler <[EMAIL PROTECTED]> > > wrote: > > > > > > On Jan 15, 2008 4:16 PM, Matthias Wessendorf < [EMAIL PROTECTED] > > > > wrote: > > > > > > > We here can only talk... The spec itself is made behind closed > > doors > > > > ;-) > > > > > > > > > > > > Not really "closed" > > > > > > "ajar" would be a better word: at least everyone is allowed to > > comment > > > > > > on early drafts > > > > > > ;-) > > > > > > > > > > > > --Manfred > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > > > > > Matthias Wessendorf > > > > > > > > > > further stuff: > > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > > > sessions: http://www.slideshare.net/mwessendorf > > > > > mail: matzew-at-apache-dot-org > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Matthias Wessendorf > > > > > > further stuff: > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > mail: matzew-at-apache-dot-org > > > > > > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org >
Re: UIInput.resetValue()
but, a move to JSF 2 is MUCH bigger than to 1.2 (from 1.1) -M On Jan 15, 2008 9:57 AM, Simon Lessard <[EMAIL PROTECTED]> wrote: > Yes, which mean that I might make such propositions or support them, but I'm > not the only member and I'm pretty such that some members see apparent > backward compatibility to be a precept above anything else. > > > ~ Simon > > > > On Jan 15, 2008 11:35 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > aren't you part of the EG ? > > :-) > > -M > > > > > > > > > > On Jan 15, 2008 7:46 AM, Simon Lessard <[EMAIL PROTECTED] > wrote: > > > Personally, considering there's always backward compatibility issues > anyway, > > > I wouldn't mind seeing some new ones if it was to allow JSF to be much > > > faster, easier to use and more extensible. Like standardizing FacesBean > for > > > instance. If done correctly, it would give a decent speed boost, allow > > > easier and more intelligent state saving as well as many other goodies. > I'd > > > really like to see a way to extends the Lifecycle more easily as well, > maybe > > > implying standardization of the Phase classes. Maybe adding new phases > as > > > well like register resources occurring before render to push all > > > dependencies in a rendering context and thus allowing all script > references > > > to be rendered in the head element thus respecting w3c. A coherence > > > validation phase as well as a mean to execute a Callback on the whole > tree > > > (to implement custom phases for example) wouldn't be unwelcome either. > > > Anyway, we'll see that in due time. > > > > > > > > > Regards, > > > > > > ~ Simon > > > > > > > > > > > > On Jan 15, 2008 10:33 AM, Matthias Wessendorf < [EMAIL PROTECTED]> > wrote: > > > > nice... > > > > > > > > > > > > > > > > > > > > On Jan 15, 2008 7:23 AM, Manfred Geiler <[EMAIL PROTECTED] > > wrote: > > > > > On Jan 15, 2008 4:16 PM, Matthias Wessendorf < [EMAIL PROTECTED]> > wrote: > > > > > > We here can only talk... The spec itself is made behind closed > doors > > > ;-) > > > > > > > > > > Not really "closed" > > > > > "ajar" would be a better word: at least everyone is allowed to > comment > > > > > on early drafts > > > > > ;-) > > > > > > > > > > --Manfred > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > > > Matthias Wessendorf > > > > > > > > further stuff: > > > > blog: http://matthiaswessendorf.wordpress.com/ > > > > sessions: http://www.slideshare.net/mwessendorf > > > > mail: matzew-at-apache-dot-org > > > > > > > > > > > > > > > > > > -- > > > > > > > > Matthias Wessendorf > > > > further stuff: > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > mail: matzew-at-apache-dot-org > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
Yes, which mean that I might make such propositions or support them, but I'm not the only member and I'm pretty such that some members see apparent backward compatibility to be a precept above anything else. ~ Simon On Jan 15, 2008 11:35 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > aren't you part of the EG ? > :-) > -M > > On Jan 15, 2008 7:46 AM, Simon Lessard <[EMAIL PROTECTED]> wrote: > > Personally, considering there's always backward compatibility issues > anyway, > > I wouldn't mind seeing some new ones if it was to allow JSF to be much > > faster, easier to use and more extensible. Like standardizing FacesBean > for > > instance. If done correctly, it would give a decent speed boost, allow > > easier and more intelligent state saving as well as many other goodies. > I'd > > really like to see a way to extends the Lifecycle more easily as well, > maybe > > implying standardization of the Phase classes. Maybe adding new phases > as > > well like register resources occurring before render to push all > > dependencies in a rendering context and thus allowing all script > references > > to be rendered in the head element thus respecting w3c. A coherence > > validation phase as well as a mean to execute a Callback on the whole > tree > > (to implement custom phases for example) wouldn't be unwelcome either. > > Anyway, we'll see that in due time. > > > > > > Regards, > > > > ~ Simon > > > > > > > > On Jan 15, 2008 10:33 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > nice... > > > > > > > > > > > > > > > On Jan 15, 2008 7:23 AM, Manfred Geiler <[EMAIL PROTECTED]> > wrote: > > > > On Jan 15, 2008 4:16 PM, Matthias Wessendorf < [EMAIL PROTECTED]> > wrote: > > > > > We here can only talk... The spec itself is made behind closed > doors > > ;-) > > > > > > > > Not really "closed" > > > > "ajar" would be a better word: at least everyone is allowed to > comment > > > > on early drafts > > > > ;-) > > > > > > > > --Manfred > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Matthias Wessendorf > > > > > > further stuff: > > > blog: http://matthiaswessendorf.wordpress.com/ > > > sessions: http://www.slideshare.net/mwessendorf > > > mail: matzew-at-apache-dot-org > > > > > > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org >
[jira] Resolved: (TRINIDAD-895) faces-config does not include converter and validator attributes
[ https://issues.apache.org/jira/browse/TRINIDAD-895?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf resolved TRINIDAD-895. - Resolution: Fixed Fix Version/s: 1.2.6-plugins > faces-config does not include converter and validator attributes > > > Key: TRINIDAD-895 > URL: https://issues.apache.org/jira/browse/TRINIDAD-895 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Plugins >Reporter: Gabrielle Crawford >Assignee: Matthias Weßendorf >Priority: Minor > Fix For: 1.2.6-plugins > > > When the faces-config is generated, converter and validator attributes are > not included. The xsd for faces-config allows these to be included for use by > a DT. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: UIInput.resetValue()
aren't you part of the EG ? :-) -M On Jan 15, 2008 7:46 AM, Simon Lessard <[EMAIL PROTECTED]> wrote: > Personally, considering there's always backward compatibility issues anyway, > I wouldn't mind seeing some new ones if it was to allow JSF to be much > faster, easier to use and more extensible. Like standardizing FacesBean for > instance. If done correctly, it would give a decent speed boost, allow > easier and more intelligent state saving as well as many other goodies. I'd > really like to see a way to extends the Lifecycle more easily as well, maybe > implying standardization of the Phase classes. Maybe adding new phases as > well like register resources occurring before render to push all > dependencies in a rendering context and thus allowing all script references > to be rendered in the head element thus respecting w3c. A coherence > validation phase as well as a mean to execute a Callback on the whole tree > (to implement custom phases for example) wouldn't be unwelcome either. > Anyway, we'll see that in due time. > > > Regards, > > ~ Simon > > > > On Jan 15, 2008 10:33 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > nice... > > > > > > > > > > On Jan 15, 2008 7:23 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote: > > > On Jan 15, 2008 4:16 PM, Matthias Wessendorf < [EMAIL PROTECTED]> wrote: > > > > We here can only talk... The spec itself is made behind closed doors > ;-) > > > > > > Not really "closed" > > > "ajar" would be a better word: at least everyone is allowed to comment > > > on early drafts > > > ;-) > > > > > > --Manfred > > > > > > > > > > > -- > > > > > > > > Matthias Wessendorf > > > > further stuff: > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > mail: matzew-at-apache-dot-org > > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
Personally, considering there's always backward compatibility issues anyway, I wouldn't mind seeing some new ones if it was to allow JSF to be much faster, easier to use and more extensible. Like standardizing FacesBean for instance. If done correctly, it would give a decent speed boost, allow easier and more intelligent state saving as well as many other goodies. I'd really like to see a way to extends the Lifecycle more easily as well, maybe implying standardization of the Phase classes. Maybe adding new phases as well like register resources occurring before render to push all dependencies in a rendering context and thus allowing all script references to be rendered in the head element thus respecting w3c. A coherence validation phase as well as a mean to execute a Callback on the whole tree (to implement custom phases for example) wouldn't be unwelcome either. Anyway, we'll see that in due time. Regards, ~ Simon On Jan 15, 2008 10:33 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > nice... > > On Jan 15, 2008 7:23 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote: > > On Jan 15, 2008 4:16 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > > We here can only talk... The spec itself is made behind closed doors > ;-) > > > > Not really "closed" > > "ajar" would be a better word: at least everyone is allowed to comment > > on early drafts > > ;-) > > > > --Manfred > > > > > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org >
Re: UIInput.resetValue()
nice... On Jan 15, 2008 7:23 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote: > On Jan 15, 2008 4:16 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > We here can only talk... The spec itself is made behind closed doors ;-) > > Not really "closed" > "ajar" would be a better word: at least everyone is allowed to comment > on early drafts > ;-) > > --Manfred > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
On Jan 15, 2008 4:16 PM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > We here can only talk... The spec itself is made behind closed doors ;-) Not really "closed" "ajar" would be a better word: at least everyone is allowed to comment on early drafts ;-) --Manfred
Re: UIInput.resetValue()
> Matze, do you have any concrete use case that could confirm your POV? a "hack" like the mentioned utility does it. But using clean interfaces would be more appreciated. Originally this email should go the the RI list, b/c I am hoping that the interface changes in JSF2 (for some reasons). We here can only talk... The spec itself is made behind closed doors ;-) -M > > --Manfred > > > > On Jan 15, 2008 7:22 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > > Hi, > > > > the resetValue() method was added directly to UIinput, instead to a > > proper interface (EditableValueHolder). > > I guess this was done, to not break impls of that interface. > > IMO this is wrong and should (at least in JSF2) be part of the > > EditableValueHolder interface. > > > > Since JSF2 will bring much more new bits, such an "enhancement" on the > > interface might be valueable. > > > > What is your take on that ? > > > > -Matthias > > > > -- > > Matthias Wessendorf > > > > further stuff: > > blog: http://matthiaswessendorf.wordpress.com/ > > sessions: http://www.slideshare.net/mwessendorf > > mail: matzew-at-apache-dot-org > > > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
As I said, I see from the backwards compatibility why it was done.
On Jan 15, 2008 7:02 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> Why not use the last "if" alone?
because this all is already done in JSF ...
>
> if (component instanceof EditableValueHolder)
> {
>EditableValueHolder holder = (EditableValueHolder)component;
>holder.setValue(null);
>holder.setSubmittedValue(null);
>holder.setLocalValueSet(false);
>holder.setValid(true);
> }
>
> Every UIInput is an EditableValueHolder and the UIXEditable as well, right?
>
> This code fragement could also be candidate for a
> "EditableValueHolderUtils" class in the MyFaces Commons.
jup, good idea. That would be more leverage able;
>
> --Manfred
>
>
>
>
> On Jan 15, 2008 3:47 PM, Simon Lessard <[EMAIL PROTECTED]> wrote:
> > Although I'm -1 also because of backward compatibility, I also felt that it
> > should have been added to the interface to start with as it simplifies many
> > loops used for reseting EditableValueHolder of the whole tree. You cannot
> > use instanceof UIInput for those as Trinidad input components, for example,
> > does not extends UIInput, but do implement EditableValueHolder so the loop's
> > body has to look like:
> >
> > if (component instanceof UIXEditable)
> > {
> > ((UIXEditable)component).resetValue();
> > }
> > else if (component instanceof UIInput)
> > {
> > ((UIInput)component).resetValue();
> > }
> > else if (component instanceof EditableValueHolder)
> > {
> > EditableValueHolder holder = (EditableValueHolder)component;
> > holder.setValue(null);
> > holder.setSubmittedValue(null);
> >holder.setLocalValueSet(false);
> > holder.setValid(true);
> > }
> >
> >
> > Maybe a good compromise would be to alter UIViewRoot to add a
> > resetAllEditableValueHolderValues method.
> >
> >
> > Regards,
> >
> > ~ Simon
> >
> >
> >
> > On Jan 15, 2008 3:19 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> > > -1
> > > Sorry, I cannot agree.
> > >
> > > The API doc of resetValue() tells you why:
> > > "Convenience method to reset [..]"
> > >
> > > A "utility like" method for convenience like this one does not belong
> > > to an interface. It does not add any behavioural function.
> > > UIInput is not an interface but a (base) class, so it is ok to have
> > > such a method there.
> > >
> > > Matze, do you have any concrete use case that could confirm your POV?
> > >
> > > --Manfred
> > >
> > >
> > >
> > >
> > >
> > > On Jan 15, 2008 7:22 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > > > Hi,
> > > >
> > > > the resetValue() method was added directly to UIinput, instead to a
> > > > proper interface (EditableValueHolder).
> > > > I guess this was done, to not break impls of that interface.
> > > > IMO this is wrong and should (at least in JSF2) be part of the
> > > > EditableValueHolder interface.
> > > >
> > > > Since JSF2 will bring much more new bits, such an "enhancement" on the
> > > > interface might be valueable.
> > > >
> > > > What is your take on that ?
> > > >
> > > > -Matthias
> > > >
> > > > --
> > > > Matthias Wessendorf
> > > >
> > > > further stuff:
> > > > blog: http://matthiaswessendorf.wordpress.com/
> > > > sessions: http://www.slideshare.net/mwessendorf
> > > > mail: matzew-at-apache-dot-org
> > > >
> > >
>
--
Matthias Wessendorf
further stuff:
blog: http://matthiaswessendorf.wordpress.com/
sessions: http://www.slideshare.net/mwessendorf
mail: matzew-at-apache-dot-org
Re: UIInput.resetValue()
Why not use the last "if" alone?
if (component instanceof EditableValueHolder)
{
EditableValueHolder holder = (EditableValueHolder)component;
holder.setValue(null);
holder.setSubmittedValue(null);
holder.setLocalValueSet(false);
holder.setValid(true);
}
Every UIInput is an EditableValueHolder and the UIXEditable as well, right?
This code fragement could also be candidate for a
"EditableValueHolderUtils" class in the MyFaces Commons.
--Manfred
On Jan 15, 2008 3:47 PM, Simon Lessard <[EMAIL PROTECTED]> wrote:
> Although I'm -1 also because of backward compatibility, I also felt that it
> should have been added to the interface to start with as it simplifies many
> loops used for reseting EditableValueHolder of the whole tree. You cannot
> use instanceof UIInput for those as Trinidad input components, for example,
> does not extends UIInput, but do implement EditableValueHolder so the loop's
> body has to look like:
>
> if (component instanceof UIXEditable)
> {
> ((UIXEditable)component).resetValue();
> }
> else if (component instanceof UIInput)
> {
> ((UIInput)component).resetValue();
> }
> else if (component instanceof EditableValueHolder)
> {
> EditableValueHolder holder = (EditableValueHolder)component;
> holder.setValue(null);
> holder.setSubmittedValue(null);
>holder.setLocalValueSet(false);
> holder.setValid(true);
> }
>
>
> Maybe a good compromise would be to alter UIViewRoot to add a
> resetAllEditableValueHolderValues method.
>
>
> Regards,
>
> ~ Simon
>
>
>
> On Jan 15, 2008 3:19 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> > -1
> > Sorry, I cannot agree.
> >
> > The API doc of resetValue() tells you why:
> > "Convenience method to reset [..]"
> >
> > A "utility like" method for convenience like this one does not belong
> > to an interface. It does not add any behavioural function.
> > UIInput is not an interface but a (base) class, so it is ok to have
> > such a method there.
> >
> > Matze, do you have any concrete use case that could confirm your POV?
> >
> > --Manfred
> >
> >
> >
> >
> >
> > On Jan 15, 2008 7:22 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > > Hi,
> > >
> > > the resetValue() method was added directly to UIinput, instead to a
> > > proper interface (EditableValueHolder).
> > > I guess this was done, to not break impls of that interface.
> > > IMO this is wrong and should (at least in JSF2) be part of the
> > > EditableValueHolder interface.
> > >
> > > Since JSF2 will bring much more new bits, such an "enhancement" on the
> > > interface might be valueable.
> > >
> > > What is your take on that ?
> > >
> > > -Matthias
> > >
> > > --
> > > Matthias Wessendorf
> > >
> > > further stuff:
> > > blog: http://matthiaswessendorf.wordpress.com/
> > > sessions: http://www.slideshare.net/mwessendorf
> > > mail: matzew-at-apache-dot-org
> > >
> >
Re: UIInput.resetValue()
Although I'm -1 also because of backward compatibility, I also felt that it
should have been added to the interface to start with as it simplifies many
loops used for reseting EditableValueHolder of the whole tree. You cannot
use instanceof UIInput for those as Trinidad input components, for example,
does not extends UIInput, but do implement EditableValueHolder so the loop's
body has to look like:
if (component instanceof UIXEditable)
{
((UIXEditable)component).resetValue();
}
else if (component instanceof UIInput)
{
((UIInput)component).resetValue();
}
else if (component instanceof EditableValueHolder)
{
EditableValueHolder holder = (EditableValueHolder)component;
holder.setValue(null);
holder.setSubmittedValue(null);
holder.setLocalValueSet(false);
holder.setValid(true);
}
Maybe a good compromise would be to alter UIViewRoot to add a
resetAllEditableValueHolderValues method.
Regards,
~ Simon
On Jan 15, 2008 3:19 AM, Manfred Geiler <[EMAIL PROTECTED]> wrote:
> -1
> Sorry, I cannot agree.
>
> The API doc of resetValue() tells you why:
> "Convenience method to reset [..]"
>
> A "utility like" method for convenience like this one does not belong
> to an interface. It does not add any behavioural function.
> UIInput is not an interface but a (base) class, so it is ok to have
> such a method there.
>
> Matze, do you have any concrete use case that could confirm your POV?
>
> --Manfred
>
>
> On Jan 15, 2008 7:22 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > the resetValue() method was added directly to UIinput, instead to a
> > proper interface (EditableValueHolder).
> > I guess this was done, to not break impls of that interface.
> > IMO this is wrong and should (at least in JSF2) be part of the
> > EditableValueHolder interface.
> >
> > Since JSF2 will bring much more new bits, such an "enhancement" on the
> > interface might be valueable.
> >
> > What is your take on that ?
> >
> > -Matthias
> >
> > --
> > Matthias Wessendorf
> >
> > further stuff:
> > blog: http://matthiaswessendorf.wordpress.com/
> > sessions: http://www.slideshare.net/mwessendorf
> > mail: matzew-at-apache-dot-org
> >
>
[jira] Commented: (TOBAGO-572) Duplicate component id with
[
https://issues.apache.org/jira/browse/TOBAGO-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559038#action_12559038
]
Bernd Bohmann commented on TOBAGO-572:
--
I will look at this issue tonight.
> Duplicate component id with
> ---
>
> Key: TOBAGO-572
> URL: https://issues.apache.org/jira/browse/TOBAGO-572
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Facelets
>Affects Versions: 1.0.13
> Environment: Facelets 1.1.12, MyFaces 1.1.6 snap (11.09.2007), Tobago
> 1.0.13 snap (10.12.2007)
>Reporter: Guido Dubois
> Attachments: tobago_faceletsexample.war
>
>
> The first time the page is rendered correctly, but if you go back you will
> get an exception
> java.lang.IllegalStateException: Client-id : _id54 is duplicated in the faces
> tree. Component : page:_id54, path: {Component-Path : [Class:
> org.apache.myfaces.tobago.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: org.apache.myfaces.tobago.component.UIPage,Id:
> page][Class: org.apache.myfaces.tobago.component.UICell,Id: _id27][Class:
> org.apache.myfaces.tobago.component.UIBox,Id: _id29][Class:
> org.apache.myfaces.tobago.component.UICell,Id: _id54]}
> I will add a sample...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (TOBAGO-572) Duplicate component id with
[
https://issues.apache.org/jira/browse/TOBAGO-572?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559033#action_12559033
]
Guido Dubois commented on TOBAGO-572:
-
This behaviour is still present in Tobago 1.0.14 snap (12.01.2008). Is it
possible that you fix this as soon as possible? Thanks for a short note...
> Duplicate component id with
> ---
>
> Key: TOBAGO-572
> URL: https://issues.apache.org/jira/browse/TOBAGO-572
> Project: MyFaces Tobago
> Issue Type: Bug
> Components: Facelets
>Affects Versions: 1.0.13
> Environment: Facelets 1.1.12, MyFaces 1.1.6 snap (11.09.2007), Tobago
> 1.0.13 snap (10.12.2007)
>Reporter: Guido Dubois
> Attachments: tobago_faceletsexample.war
>
>
> The first time the page is rendered correctly, but if you go back you will
> get an exception
> java.lang.IllegalStateException: Client-id : _id54 is duplicated in the faces
> tree. Component : page:_id54, path: {Component-Path : [Class:
> org.apache.myfaces.tobago.component.UIViewRoot,ViewId:
> /helloWorld.xhtml][Class: org.apache.myfaces.tobago.component.UIPage,Id:
> page][Class: org.apache.myfaces.tobago.component.UICell,Id: _id27][Class:
> org.apache.myfaces.tobago.component.UIBox,Id: _id29][Class:
> org.apache.myfaces.tobago.component.UICell,Id: _id54]}
> I will add a sample...
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[Trinidad] Rendering of trinidad components in Visual page editor
Varun Shingal wrote: Hi Im working on a project on JSF and use the eclipse visual page editor (WTP) for editing the pages. I started using trinidad components and found that there is no support for them in the visual page editor for design-time rendering. Is it something wrong I am doing or is it not supported? What can I do for adding this support? Is there anything being done to add this support? In what way can I add support for the trinidad components for design time rendering? Thanks and Cheers Varun
Rendering of trinidad components in Visual page editor
Hi Im working on a project on JSF and use the eclipse visual page editor (WTP) for editing the pages. I started using trinidad components and found that there is no support for them in the visual page editor for design-time rendering. Is it something wrong I am doing or is it not supported? What can I do for adding this support? Is there anything being done to add this support? In what way can I add support for the trinidad components for design time rendering? Thanks and Cheers Varun
[jira] Commented: (MYFACES-1803) elements should be rendered for better WAI support
[ https://issues.apache.org/jira/browse/MYFACES-1803?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12559003#action_12559003 ] Simon Kitching commented on MYFACES-1803: - I think we need central utility methods to start and end a script section. One thing that central method could do is ensure CDATA is used to wrap the script. And another is this noscript stuff. However I'm not sure that should be output by default. That's a lot of extra text that many apps will not want, particularly as it doesn't actually make the app usable for users without javascript. And outputting a noscript section that does not actually make the app run might shut some tools up, but it really "lies" about WAI support; I would not like that to be the default. Maybe a webapp config option called NOSCRIPT_TEXT could be used to enable output inside script tags; when present the is generated using the provided string as the message? > elements should be rendered for better WAI support > - > > Key: MYFACES-1803 > URL: https://issues.apache.org/jira/browse/MYFACES-1803 > Project: MyFaces Core > Issue Type: Improvement > Components: General >Affects Versions: 1.1.5, 1.2.0 >Reporter: Manfred Geiler >Assignee: Manfred Geiler >Priority: Minor > > According to the "Web Accessibility Initiative (WAI)" guidelines > (http://www.w3.org/WAI/) for every
[jira] Created: (MYFACES-1803) elements should be rendered for better WAI support
elements should be rendered for better WAI support - Key: MYFACES-1803 URL: https://issues.apache.org/jira/browse/MYFACES-1803 Project: MyFaces Core Issue Type: Improvement Components: General Affects Versions: 1.2.0, 1.1.5 Reporter: Manfred Geiler Assignee: Manfred Geiler Priority: Minor According to the "Web Accessibility Initiative (WAI)" guidelines (http://www.w3.org/WAI/) for every
[jira] Commented: (MYFACES-1794) MF Core causes resources not found(404) errors (recently also corrected in Sun RI for JSF 1.2)
[ https://issues.apache.org/jira/browse/MYFACES-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558998#action_12558998 ] Wolf Benz commented on MYFACES-1794: You're right Simon. Will do. Thx, -Wolf > MF Core causes resources not found(404) errors (recently also corrected in > Sun RI for JSF 1.2) > -- > > Key: MYFACES-1794 > URL: https://issues.apache.org/jira/browse/MYFACES-1794 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 1.2.0 > Environment: JSF 1.2 (failures mostly happen with extensions like > with Trinidad e.g.) >Reporter: Wolf Benz > Fix For: 1.2.1 > > > Cf. the MF mailing list: topics like "Dialog issue during ADF->Trinidad > migration" > I came across it using tr:inputDate but in the list topic I mentioned above, > so I first thought it was a Trinidad issue, but people more knowledgeable > with the JSF spec(Adam Winer) pointed out it was a MF 1.2 core issue, and > that the Sun RI had also sufferend from it, yet in the RI, this bug has > recently been corrected. > The error I got was when clicking the calendar icon and expecting a cal > popup. Instead I got: > "description The requested resource (.../__ADFv__.jsp) is not available." > As it potentially affects a lot of other components beyond this trinidad one, > I marked it major as these components just don't work anymore. > E.g. MF mailing list with topic "RE: [Trinidad] HTTP 404 (file not found) > while using DialogFramework" points that out. > --Wolf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1794) MF Core causes resources not found(404) errors (recently also corrected in Sun RI for JSF 1.2)
[ https://issues.apache.org/jira/browse/MYFACES-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558987#action_12558987 ] Simon Kitching commented on MYFACES-1794: - The whole point of this issue, and the whole point of the Adam Winer email that you referenced is that this is a problem with myfaces-core. In fact, this is even in the title of this issue. So you need to retest with the latest version of myfaces-core. Which version of Trinidad you test with is irrelevant. Choose whatever is easiest for you. > MF Core causes resources not found(404) errors (recently also corrected in > Sun RI for JSF 1.2) > -- > > Key: MYFACES-1794 > URL: https://issues.apache.org/jira/browse/MYFACES-1794 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 1.2.0 > Environment: JSF 1.2 (failures mostly happen with extensions like > with Trinidad e.g.) >Reporter: Wolf Benz > Fix For: 1.2.1 > > > Cf. the MF mailing list: topics like "Dialog issue during ADF->Trinidad > migration" > I came across it using tr:inputDate but in the list topic I mentioned above, > so I first thought it was a Trinidad issue, but people more knowledgeable > with the JSF spec(Adam Winer) pointed out it was a MF 1.2 core issue, and > that the Sun RI had also sufferend from it, yet in the RI, this bug has > recently been corrected. > The error I got was when clicking the calendar icon and expecting a cal > popup. Instead I got: > "description The requested resource (.../__ADFv__.jsp) is not available." > As it potentially affects a lot of other components beyond this trinidad one, > I marked it major as these components just don't work anymore. > E.g. MF mailing list with topic "RE: [Trinidad] HTTP 404 (file not found) > while using DialogFramework" points that out. > --Wolf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (MYFACES-1794) MF Core causes resources not found(404) errors (recently also corrected in Sun RI for JSF 1.2)
[ https://issues.apache.org/jira/browse/MYFACES-1794?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12558983#action_12558983 ] Wolf Benz commented on MYFACES-1794: Hello Simon, What version of Trinidad would you like me to test it with? In the apache svn repo I am looking at a 1.2.6 version as the last one(for tr-impl). Is this the one you'd prefer, or should I try with the latest 1.2.4 version? -Wolf > MF Core causes resources not found(404) errors (recently also corrected in > Sun RI for JSF 1.2) > -- > > Key: MYFACES-1794 > URL: https://issues.apache.org/jira/browse/MYFACES-1794 > Project: MyFaces Core > Issue Type: Bug >Affects Versions: 1.2.0 > Environment: JSF 1.2 (failures mostly happen with extensions like > with Trinidad e.g.) >Reporter: Wolf Benz > Fix For: 1.2.1 > > > Cf. the MF mailing list: topics like "Dialog issue during ADF->Trinidad > migration" > I came across it using tr:inputDate but in the list topic I mentioned above, > so I first thought it was a Trinidad issue, but people more knowledgeable > with the JSF spec(Adam Winer) pointed out it was a MF 1.2 core issue, and > that the Sun RI had also sufferend from it, yet in the RI, this bug has > recently been corrected. > The error I got was when clicking the calendar icon and expecting a cal > popup. Instead I got: > "description The requested resource (.../__ADFv__.jsp) is not available." > As it potentially affects a lot of other components beyond this trinidad one, > I marked it major as these components just don't work anymore. > E.g. MF mailing list with topic "RE: [Trinidad] HTTP 404 (file not found) > while using DialogFramework" points that out. > --Wolf -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: UIInput.resetValue()
-1 Sorry, I cannot agree. The API doc of resetValue() tells you why: "Convenience method to reset [..]" A "utility like" method for convenience like this one does not belong to an interface. It does not add any behavioural function. UIInput is not an interface but a (base) class, so it is ok to have such a method there. Matze, do you have any concrete use case that could confirm your POV? --Manfred On Jan 15, 2008 7:22 AM, Matthias Wessendorf <[EMAIL PROTECTED]> wrote: > Hi, > > the resetValue() method was added directly to UIinput, instead to a > proper interface (EditableValueHolder). > I guess this was done, to not break impls of that interface. > IMO this is wrong and should (at least in JSF2) be part of the > EditableValueHolder interface. > > Since JSF2 will bring much more new bits, such an "enhancement" on the > interface might be valueable. > > What is your take on that ? > > -Matthias > > -- > Matthias Wessendorf > > further stuff: > blog: http://matthiaswessendorf.wordpress.com/ > sessions: http://www.slideshare.net/mwessendorf > mail: matzew-at-apache-dot-org >
