Re: cleaning up whitespace in source files
Ok, rather than running "detab.sh" before svn update, I suggest this instead. svn -q status | cut -c 8- | xargs -n 1 sed -i -e 's/\t//g' It replaces tabs *only* in local files that you already have modified versions of. The svn update therefore works normally on other files (no conflicts). Regards, Simon Andrew Robinson schrieb: SVN merge takes "-x -w" arguments to ignore whitespace. I am not sure about updating. -Andrew On Thu, Jul 3, 2008 at 4:39 PM, simon <[EMAIL PROTECTED]> wrote: Sorry, but I think conflicts are now being reported when updating a checkout dir for files where *all* of these were true: * contains tabs * did not have eol-style set to native * was not first checked in from your native platform. I'll try to think of a nice way to automatically clean up those conflicts.. Regards, Simon On Fri, 2008-07-04 at 00:04 +0200, simon wrote: By the way: * the detab.sh script is here: http://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/other/scripts/detab.sh * I haven't touched tobago, trinidad or portlet-bridge. It's up to the developers of those projects to choose when/if they want to do this. I also fixed quite a few .java files that did not have eol-style set to native. People, could you please check that you have your ~/.subversion/config file set up correctly? Regards, Simon On Thu, 2008-07-03 at 23:11 +0200, simon wrote: Ok, as people seem happy to see tabs cleaned up done I'm doing it now. But I'm leaving trailing whitespace alone for now; there is less benefit and it does touch a whole lot of files. To anyone who currently has checked-out directories with uncommitted changes in them, I recommend running "detab.sh" *before* running svn update. This will avoid having conflict markers inserted into all your locally modified files. If you forget, do svn update, and end up with lots of conflicts then I recommend: * install svn 1.5.0 (if you don't have it already), then * "svn resolve --recursive --accept mine-full ." then * run detab.sh Regards, Simon On Wed, 2008-07-02 at 22:14 +0200, simon wrote: Interesting question, Manfred. Here are the answers: Count of java files is done via: find . -name ".svn" -prune -o -name "target" -prune \ -o -name "*.java" -print | wc -l Count of java files with tabs is done by running "detab1.sh" (which just fixes tabs) then: svn status | grep "^M" | wc -l Count of java files with tabs or trailing whitespace is done by running "detab.sh" then svn status as above. shared/trunk: # of java files: 396 # of files with tabs: 25 # of files with tabs/trailing spaces: 51 shared/trunk12: # of java files: 390 # of files with tabs: 31 # of files with tabs/trailing spaces: 133 core/trunk: # of java files: 351 # of files with tabs: 78 # of files with tabs/trailing spaces: 216 core/trunk12: # of java files: 503 # of files with tabs: 120 # of files with tabs/trailing spaces: 385 It's interesting how many more classes there are in jsf1.2 than in jsf1.1. Some of this is due to more unit tests, but much appears to be real new classes needed to implement the extended spec. On Wed, 2008-07-02 at 20:12 +0200, Manfred Geiler wrote: Simon, Do you have a number? How many files do have tab characters? I think (b - fix them) would be the better solution. But only if that does not change every second file. --Manfred On Wed, Jul 2, 2008 at 7:28 PM, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: Hi All, In the new checkstyle rules file I enabled checks for tab characters, as the myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the checkstyle report points out a lot of files containing tabs. It's no big deal, but do we want to: (a) disable the checkstyle rule and ignore tabs or (b) fix them? Tabs are a minor nuisance when viewing the source as some tools render 4 spaces, some 8. I've written a simple shellscript that can clean this up very easily, and am happy to do so. The script also removes trailing whitespace from lines, of which we also appear to have quite a lot. But doing this will create some large commit messages and make comparing files with past versions noisier. It can also cause svn conflicts if people have modified files they have not yet committed, unless they run the cleanup script against their own working dir before doing svn update. So, option (a) or (b)? Regards, Simon
[jira] Created: (TRINIDAD-1140) "select" renderers shoud support "escape" and "disabled" properties for SelectItemGroup
"select" renderers shoud support "escape" and "disabled" properties for SelectItemGroup --- Key: TRINIDAD-1140 URL: https://issues.apache.org/jira/browse/TRINIDAD-1140 Project: MyFaces Trinidad Issue Type: Bug Components: Components Affects Versions: 1.2.8-core Reporter: Stephen Friedrich The only attribute that is ever rendered for optgroup is the label. However optgroup has a disabled attribute (which is also honored by browsers). Also the "escape" proeprty should be taken into account when rendering the label. Tested with selectOneListbox, but very probably the other "select" renderers have the same problem. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: cleaning up whitespace in source files
SVN merge takes "-x -w" arguments to ignore whitespace. I am not sure about updating. -Andrew On Thu, Jul 3, 2008 at 4:39 PM, simon <[EMAIL PROTECTED]> wrote: > Sorry, but I think conflicts are now being reported when updating a > checkout dir for files where *all* of these were true: > * contains tabs > * did not have eol-style set to native > * was not first checked in from your native platform. > > I'll try to think of a nice way to automatically clean up those > conflicts.. > > Regards, Simon > > On Fri, 2008-07-04 at 00:04 +0200, simon wrote: >> By the way: >> >> * the detab.sh script is here: >> http://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/other/scripts/detab.sh >> >> * I haven't touched tobago, trinidad or portlet-bridge. It's up to the >> developers of those projects to choose when/if they want to do this. >> >> I also fixed quite a few .java files that did not have eol-style set to >> native. People, could you please check that you have your >> ~/.subversion/config >> file set up correctly? >> >> Regards, >> Simon >> >> On Thu, 2008-07-03 at 23:11 +0200, simon wrote: >> > Ok, as people seem happy to see tabs cleaned up done I'm doing it now. >> > But I'm leaving trailing whitespace alone for now; there is less benefit >> > and it does touch a whole lot of files. >> > >> > To anyone who currently has checked-out directories with uncommitted >> > changes in them, I recommend running "detab.sh" *before* running svn >> > update. This will avoid having conflict markers inserted into all your >> > locally modified files. >> > >> > If you forget, do svn update, and end up with lots of conflicts then I >> > recommend: >> > * install svn 1.5.0 (if you don't have it already), then >> > * "svn resolve --recursive --accept mine-full ." then >> > * run detab.sh >> > >> > Regards, >> > Simon >> > >> > On Wed, 2008-07-02 at 22:14 +0200, simon wrote: >> > > Interesting question, Manfred. Here are the answers: >> > > >> > > Count of java files is done via: >> > > find . -name ".svn" -prune -o -name "target" -prune \ >> > > -o -name "*.java" -print | wc -l >> > > >> > > Count of java files with tabs is done by running "detab1.sh" (which just >> > > fixes tabs) then: >> > > svn status | grep "^M" | wc -l >> > > >> > > Count of java files with tabs or trailing whitespace is done by running >> > > "detab.sh" then svn status as above. >> > > >> > > shared/trunk: >> > > # of java files: 396 >> > > # of files with tabs: 25 >> > > # of files with tabs/trailing spaces: 51 >> > > >> > > shared/trunk12: >> > > # of java files: 390 >> > > # of files with tabs: 31 >> > > # of files with tabs/trailing spaces: 133 >> > > >> > > core/trunk: >> > > # of java files: 351 >> > > # of files with tabs: 78 >> > > # of files with tabs/trailing spaces: 216 >> > > >> > > core/trunk12: >> > > # of java files: 503 >> > > # of files with tabs: 120 >> > > # of files with tabs/trailing spaces: 385 >> > > >> > > >> > > It's interesting how many more classes there are in jsf1.2 than in >> > > jsf1.1. Some of this is due to more unit tests, but much appears to be >> > > real new classes needed to implement the extended spec. >> > > >> > > >> > > >> > > >> > > On Wed, 2008-07-02 at 20:12 +0200, Manfred Geiler wrote: >> > > > Simon, >> > > > Do you have a number? How many files do have tab characters? >> > > > I think (b - fix them) would be the better solution. But only if that >> > > > does not change every second file. >> > > > --Manfred >> > > > >> > > > >> > > > On Wed, Jul 2, 2008 at 7:28 PM, [EMAIL PROTECTED] >> > > > <[EMAIL PROTECTED]> wrote: >> > > > > Hi All, >> > > > > >> > > > > In the new checkstyle rules file I enabled checks for tab >> > > > > characters, as the >> > > > > myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the >> > > > > checkstyle report points out a lot of files containing tabs. >> > > > > >> > > > > It's no big deal, but do we want to: >> > > > > (a) disable the checkstyle rule and ignore tabs or >> > > > > (b) fix them? >> > > > > >> > > > > Tabs are a minor nuisance when viewing the source as some tools >> > > > > render 4 >> > > > > spaces, some 8. >> > > > > >> > > > > I've written a simple shellscript that can clean this up very >> > > > > easily, and am >> > > > > happy to do so. The script also removes trailing whitespace from >> > > > > lines, of >> > > > > which we also appear to have quite a lot. >> > > > > >> > > > > But doing this will create some large commit messages and make >> > > > > comparing >> > > > > files with past versions noisier. It can also cause svn conflicts if >> > > > > people >> > > > > have modified files they have not yet committed, unless they run the >> > > > > cleanup >> > > > > script against their own working dir before doing svn update. >> > > > > >> > > > > So, option (a) or (b)? >> > > > > >> > > > > Regards, Simon >> > > > > >> > > > > >> > > > >> > > > >> > > > >> > > >> > >> > >
Re: cleaning up whitespace in source files
Sorry, but I think conflicts are now being reported when updating a checkout dir for files where *all* of these were true: * contains tabs * did not have eol-style set to native * was not first checked in from your native platform. I'll try to think of a nice way to automatically clean up those conflicts.. Regards, Simon On Fri, 2008-07-04 at 00:04 +0200, simon wrote: > By the way: > > * the detab.sh script is here: > http://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/other/scripts/detab.sh > > * I haven't touched tobago, trinidad or portlet-bridge. It's up to the > developers of those projects to choose when/if they want to do this. > > I also fixed quite a few .java files that did not have eol-style set to > native. People, could you please check that you have your > ~/.subversion/config > file set up correctly? > > Regards, > Simon > > On Thu, 2008-07-03 at 23:11 +0200, simon wrote: > > Ok, as people seem happy to see tabs cleaned up done I'm doing it now. > > But I'm leaving trailing whitespace alone for now; there is less benefit > > and it does touch a whole lot of files. > > > > To anyone who currently has checked-out directories with uncommitted > > changes in them, I recommend running "detab.sh" *before* running svn > > update. This will avoid having conflict markers inserted into all your > > locally modified files. > > > > If you forget, do svn update, and end up with lots of conflicts then I > > recommend: > > * install svn 1.5.0 (if you don't have it already), then > > * "svn resolve --recursive --accept mine-full ." then > > * run detab.sh > > > > Regards, > > Simon > > > > On Wed, 2008-07-02 at 22:14 +0200, simon wrote: > > > Interesting question, Manfred. Here are the answers: > > > > > > Count of java files is done via: > > > find . -name ".svn" -prune -o -name "target" -prune \ > > > -o -name "*.java" -print | wc -l > > > > > > Count of java files with tabs is done by running "detab1.sh" (which just > > > fixes tabs) then: > > > svn status | grep "^M" | wc -l > > > > > > Count of java files with tabs or trailing whitespace is done by running > > > "detab.sh" then svn status as above. > > > > > > shared/trunk: > > > # of java files: 396 > > > # of files with tabs: 25 > > > # of files with tabs/trailing spaces: 51 > > > > > > shared/trunk12: > > > # of java files: 390 > > > # of files with tabs: 31 > > > # of files with tabs/trailing spaces: 133 > > > > > > core/trunk: > > > # of java files: 351 > > > # of files with tabs: 78 > > > # of files with tabs/trailing spaces: 216 > > > > > > core/trunk12: > > > # of java files: 503 > > > # of files with tabs: 120 > > > # of files with tabs/trailing spaces: 385 > > > > > > > > > It's interesting how many more classes there are in jsf1.2 than in > > > jsf1.1. Some of this is due to more unit tests, but much appears to be > > > real new classes needed to implement the extended spec. > > > > > > > > > > > > > > > On Wed, 2008-07-02 at 20:12 +0200, Manfred Geiler wrote: > > > > Simon, > > > > Do you have a number? How many files do have tab characters? > > > > I think (b - fix them) would be the better solution. But only if that > > > > does not change every second file. > > > > --Manfred > > > > > > > > > > > > On Wed, Jul 2, 2008 at 7:28 PM, [EMAIL PROTECTED] > > > > <[EMAIL PROTECTED]> wrote: > > > > > Hi All, > > > > > > > > > > In the new checkstyle rules file I enabled checks for tab characters, > > > > > as the > > > > > myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the > > > > > checkstyle report points out a lot of files containing tabs. > > > > > > > > > > It's no big deal, but do we want to: > > > > > (a) disable the checkstyle rule and ignore tabs or > > > > > (b) fix them? > > > > > > > > > > Tabs are a minor nuisance when viewing the source as some tools > > > > > render 4 > > > > > spaces, some 8. > > > > > > > > > > I've written a simple shellscript that can clean this up very easily, > > > > > and am > > > > > happy to do so. The script also removes trailing whitespace from > > > > > lines, of > > > > > which we also appear to have quite a lot. > > > > > > > > > > But doing this will create some large commit messages and make > > > > > comparing > > > > > files with past versions noisier. It can also cause svn conflicts if > > > > > people > > > > > have modified files they have not yet committed, unless they run the > > > > > cleanup > > > > > script against their own working dir before doing svn update. > > > > > > > > > > So, option (a) or (b)? > > > > > > > > > > Regards, Simon > > > > > > > > > > > > > > > > > > > > > > > > > > > >
Re: cleaning up whitespace in source files
By the way: * the detab.sh script is here: http://svn.apache.org/repos/asf/myfaces/myfaces-build-tools/trunk/other/scripts/detab.sh * I haven't touched tobago, trinidad or portlet-bridge. It's up to the developers of those projects to choose when/if they want to do this. I also fixed quite a few .java files that did not have eol-style set to native. People, could you please check that you have your ~/.subversion/config file set up correctly? Regards, Simon On Thu, 2008-07-03 at 23:11 +0200, simon wrote: > Ok, as people seem happy to see tabs cleaned up done I'm doing it now. > But I'm leaving trailing whitespace alone for now; there is less benefit > and it does touch a whole lot of files. > > To anyone who currently has checked-out directories with uncommitted > changes in them, I recommend running "detab.sh" *before* running svn > update. This will avoid having conflict markers inserted into all your > locally modified files. > > If you forget, do svn update, and end up with lots of conflicts then I > recommend: > * install svn 1.5.0 (if you don't have it already), then > * "svn resolve --recursive --accept mine-full ." then > * run detab.sh > > Regards, > Simon > > On Wed, 2008-07-02 at 22:14 +0200, simon wrote: > > Interesting question, Manfred. Here are the answers: > > > > Count of java files is done via: > > find . -name ".svn" -prune -o -name "target" -prune \ > > -o -name "*.java" -print | wc -l > > > > Count of java files with tabs is done by running "detab1.sh" (which just > > fixes tabs) then: > > svn status | grep "^M" | wc -l > > > > Count of java files with tabs or trailing whitespace is done by running > > "detab.sh" then svn status as above. > > > > shared/trunk: > > # of java files: 396 > > # of files with tabs: 25 > > # of files with tabs/trailing spaces: 51 > > > > shared/trunk12: > > # of java files: 390 > > # of files with tabs: 31 > > # of files with tabs/trailing spaces: 133 > > > > core/trunk: > > # of java files: 351 > > # of files with tabs: 78 > > # of files with tabs/trailing spaces: 216 > > > > core/trunk12: > > # of java files: 503 > > # of files with tabs: 120 > > # of files with tabs/trailing spaces: 385 > > > > > > It's interesting how many more classes there are in jsf1.2 than in > > jsf1.1. Some of this is due to more unit tests, but much appears to be > > real new classes needed to implement the extended spec. > > > > > > > > > > On Wed, 2008-07-02 at 20:12 +0200, Manfred Geiler wrote: > > > Simon, > > > Do you have a number? How many files do have tab characters? > > > I think (b - fix them) would be the better solution. But only if that > > > does not change every second file. > > > --Manfred > > > > > > > > > On Wed, Jul 2, 2008 at 7:28 PM, [EMAIL PROTECTED] > > > <[EMAIL PROTECTED]> wrote: > > > > Hi All, > > > > > > > > In the new checkstyle rules file I enabled checks for tab characters, > > > > as the > > > > myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the > > > > checkstyle report points out a lot of files containing tabs. > > > > > > > > It's no big deal, but do we want to: > > > > (a) disable the checkstyle rule and ignore tabs or > > > > (b) fix them? > > > > > > > > Tabs are a minor nuisance when viewing the source as some tools render 4 > > > > spaces, some 8. > > > > > > > > I've written a simple shellscript that can clean this up very easily, > > > > and am > > > > happy to do so. The script also removes trailing whitespace from lines, > > > > of > > > > which we also appear to have quite a lot. > > > > > > > > But doing this will create some large commit messages and make comparing > > > > files with past versions noisier. It can also cause svn conflicts if > > > > people > > > > have modified files they have not yet committed, unless they run the > > > > cleanup > > > > script against their own working dir before doing svn update. > > > > > > > > So, option (a) or (b)? > > > > > > > > Regards, Simon > > > > > > > > > > > > > > > > > > > >
Re: [VOTE] Upgrade s:limitRendered to tomahawk
On Thu, Jul 3, 2008 at 4:31 PM, simon <[EMAIL PROTECTED]> wrote:
> The name t:renderOne sounds good to me.
>
Sounds good to me too. My intention of the next days is propose several
components to be
upgraded, in order to check what we need to do (more than upgrade components
is the discussion
involved and the final todos list). Only non dojo components will be
proposed.
>
> On Thu, 2008-07-03 at 10:07 -0600, Andrew Robinson wrote:
> > If that were done, I would recommend the name "renderOne". choose in
> > JSF sounds closer to the select* prefix, reserved for UIInput
> > components. renderOne is clear in that it shows that it affects
> > rendering, where choose does not define what it does (one could argue
> > that it was a bad naming decision for JSTL and XSLT). Choose to me
> > sounds more like a SELECT component than a choice to only render one.
> > But that is my opinion.
> >
> > -Andrew
> >
> > On Wed, Jul 2, 2008 at 3:58 PM, Mike Kienenberger <[EMAIL PROTECTED]>
> wrote:
> > > What Simon proposed makes a lot of sense to me.
> > >
> > >
> > > On Wed, Jul 2, 2008 at 1:18 PM, [EMAIL PROTECTED]
> > > <[EMAIL PROTECTED]> wrote:
> > >> Andrew Robinson schrieb:
> >
> > You must have had a real use case that pushed you to write this
> > component.
> > Can you please describe it?
> >
> > >>>
> > >>> The same as all usages of . The index based or more than
> > >>> one are just added benefits I threw in. I can provide examples, but I
> > >>> shouldn't have to.
> > >>
> > >> I certainly think all new components should have to provide proper
> > >> use-cases. Having very rarely used components in Tomahawk:
> > >> * makes it hard for users to find what they want (steeper learning
> curve)
> > >> * increases the maintenance burden
> > >> * increases the jarfile size
> > >>
> > >> So components should only go in if they are useful to a reasonable
> number of
> > >> people.
> > >>
> > >>> Just because someone can't think of when it would
> > >>> be needed, doesn't mean it never would be useful, but I can appease
> > >>> you curiosity.
> > >>
> > >> It's not curiosity. There is a vast amount of crap in Tomahawk right
> now, to
> > >> the point where Tomahawk is close to dying. There hasn't been a
> release for
> > >> a year. The number of open bugs is vast. So everyone *should* be
> watching
> > >> carefully to see that we don't increase the problems.
> > >>
> > >> That doesn't mean that good components cannot be added. But new stuff
> does
> > >> need to be evaluated for usefulness.
> > >>
> > >> And the author of a component is often too close to the code to see
> whether
> > >> it can be improved (that applies equally to me). Having other people
> look
> > >> critically at the purpose and API is very useful. You are free to
> point out
> > >> any issues with components I write (eg Orchestra stuff).
> > >>
> > >>> I created the component so that people would stop using
> > >>> c:choose and c:if in JSF pages and complain that they don't work in
> > >>> tables and such.
> > >>>
> > >>> 1) default c:choose functionality (render the first match):
> > >>>
> > >>>
> > >>> > >>> rendered="#{prefs.firstThenLast}" />
> > >>> > >>> rendered="#{prefs.firstThenLast}" />
> > >>>
> > >>>
> > >>
> > >> Yep, this is a good use case. As you demonstrate later in your email,
> > >> writing mutually-exclusive rendered expressions for a set of
> components can
> > >> get nasty.
> > >>
> > >> I'm not a JSTL user, so your reference to c:choose wasn't perhaps as
> clear
> > >> to me as it might be to others. I think this way:
> > >>
> > >> if (cond1) render component 1
> > >> else if (cond2) render component 2
> > >> else if (cond3) render component 3
> > >> else render component 4
> > >>
> > >> Expanding the javadoc for the component a bit would be good,
> mentioning that
> > >> it simplifies rendered expressions for mutually-exclusive components.
> The
> > >> current docs don't mention that the implicit condition associated with
> the
> > >> "choose clauses" is the rendered expression; it makes sense once I
> know what
> > >> the component is doing but wasn't obvious at first.
> > >>
> > >>> 2) render index based. This behaves much like the tr:switcher
> > >>> component. But instead of using facets and facet names, it uses
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>>
> > >>
> > >> I'm not so sure about this. The tr:switcher makes sense to me; it
> chooses a
> > >> component to render by name which will not be easily broken by page
> changes,
> > >> and where the link between what the backing bean EL expression returns
> and
> > >> what facet is selected is clear (the name matches).
> > >>
> > >> Selecting by index has a far smaller set of use-cases I think. And it
> can
> > >> promote code fragility; coupling an index returned by the backing bean
> with
> > >> an array defined in the page has potential for trouble. Bu
Re: [VOTE] Upgrade s:limitRendered to tomahawk
The name t:renderOne sounds good to me.
On Thu, 2008-07-03 at 10:07 -0600, Andrew Robinson wrote:
> If that were done, I would recommend the name "renderOne". choose in
> JSF sounds closer to the select* prefix, reserved for UIInput
> components. renderOne is clear in that it shows that it affects
> rendering, where choose does not define what it does (one could argue
> that it was a bad naming decision for JSTL and XSLT). Choose to me
> sounds more like a SELECT component than a choice to only render one.
> But that is my opinion.
>
> -Andrew
>
> On Wed, Jul 2, 2008 at 3:58 PM, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> > What Simon proposed makes a lot of sense to me.
> >
> >
> > On Wed, Jul 2, 2008 at 1:18 PM, [EMAIL PROTECTED]
> > <[EMAIL PROTECTED]> wrote:
> >> Andrew Robinson schrieb:
>
> You must have had a real use case that pushed you to write this
> component.
> Can you please describe it?
>
> >>>
> >>> The same as all usages of . The index based or more than
> >>> one are just added benefits I threw in. I can provide examples, but I
> >>> shouldn't have to.
> >>
> >> I certainly think all new components should have to provide proper
> >> use-cases. Having very rarely used components in Tomahawk:
> >> * makes it hard for users to find what they want (steeper learning curve)
> >> * increases the maintenance burden
> >> * increases the jarfile size
> >>
> >> So components should only go in if they are useful to a reasonable number
> >> of
> >> people.
> >>
> >>> Just because someone can't think of when it would
> >>> be needed, doesn't mean it never would be useful, but I can appease
> >>> you curiosity.
> >>
> >> It's not curiosity. There is a vast amount of crap in Tomahawk right now,
> >> to
> >> the point where Tomahawk is close to dying. There hasn't been a release for
> >> a year. The number of open bugs is vast. So everyone *should* be watching
> >> carefully to see that we don't increase the problems.
> >>
> >> That doesn't mean that good components cannot be added. But new stuff does
> >> need to be evaluated for usefulness.
> >>
> >> And the author of a component is often too close to the code to see whether
> >> it can be improved (that applies equally to me). Having other people look
> >> critically at the purpose and API is very useful. You are free to point out
> >> any issues with components I write (eg Orchestra stuff).
> >>
> >>> I created the component so that people would stop using
> >>> c:choose and c:if in JSF pages and complain that they don't work in
> >>> tables and such.
> >>>
> >>> 1) default c:choose functionality (render the first match):
> >>>
> >>>
> >>> >>> rendered="#{prefs.firstThenLast}" />
> >>> >>> rendered="#{prefs.firstThenLast}" />
> >>>
> >>>
> >>
> >> Yep, this is a good use case. As you demonstrate later in your email,
> >> writing mutually-exclusive rendered expressions for a set of components can
> >> get nasty.
> >>
> >> I'm not a JSTL user, so your reference to c:choose wasn't perhaps as clear
> >> to me as it might be to others. I think this way:
> >>
> >> if (cond1) render component 1
> >> else if (cond2) render component 2
> >> else if (cond3) render component 3
> >> else render component 4
> >>
> >> Expanding the javadoc for the component a bit would be good, mentioning
> >> that
> >> it simplifies rendered expressions for mutually-exclusive components. The
> >> current docs don't mention that the implicit condition associated with the
> >> "choose clauses" is the rendered expression; it makes sense once I know
> >> what
> >> the component is doing but wasn't obvious at first.
> >>
> >>> 2) render index based. This behaves much like the tr:switcher
> >>> component. But instead of using facets and facet names, it uses
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> I'm not so sure about this. The tr:switcher makes sense to me; it chooses a
> >> component to render by name which will not be easily broken by page
> >> changes,
> >> and where the link between what the backing bean EL expression returns and
> >> what facet is selected is clear (the name matches).
> >>
> >> Selecting by index has a far smaller set of use-cases I think. And it can
> >> promote code fragility; coupling an index returned by the backing bean with
> >> an array defined in the page has potential for trouble. But the wizard
> >> use-case is an example of a valid use of this functionality.
> >>
> >>> 3) render multiple children. Can be used much like "-v" vs "-" can
> >>> be used for command line verbosity
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >> Equivalent to this:
> >>
> >>
> >>
> >>
> >> Yes, the limitRendered approach is a little more efficient; only one EL
> >> expression evaluated rather than 3. But any JSF developer understands the
> >> latter, while no-one can understand the limitRendered approach without
> >> looking up the docs fi
Re: cleaning up whitespace in source files
Ok, as people seem happy to see tabs cleaned up done I'm doing it now. But I'm leaving trailing whitespace alone for now; there is less benefit and it does touch a whole lot of files. To anyone who currently has checked-out directories with uncommitted changes in them, I recommend running "detab.sh" *before* running svn update. This will avoid having conflict markers inserted into all your locally modified files. If you forget, do svn update, and end up with lots of conflicts then I recommend: * install svn 1.5.0 (if you don't have it already), then * "svn resolve --recursive --accept mine-full ." then * run detab.sh Regards, Simon On Wed, 2008-07-02 at 22:14 +0200, simon wrote: > Interesting question, Manfred. Here are the answers: > > Count of java files is done via: > find . -name ".svn" -prune -o -name "target" -prune \ > -o -name "*.java" -print | wc -l > > Count of java files with tabs is done by running "detab1.sh" (which just > fixes tabs) then: > svn status | grep "^M" | wc -l > > Count of java files with tabs or trailing whitespace is done by running > "detab.sh" then svn status as above. > > shared/trunk: > # of java files: 396 > # of files with tabs: 25 > # of files with tabs/trailing spaces: 51 > > shared/trunk12: > # of java files: 390 > # of files with tabs: 31 > # of files with tabs/trailing spaces: 133 > > core/trunk: > # of java files: 351 > # of files with tabs: 78 > # of files with tabs/trailing spaces: 216 > > core/trunk12: > # of java files: 503 > # of files with tabs: 120 > # of files with tabs/trailing spaces: 385 > > > It's interesting how many more classes there are in jsf1.2 than in > jsf1.1. Some of this is due to more unit tests, but much appears to be > real new classes needed to implement the extended spec. > > > > > On Wed, 2008-07-02 at 20:12 +0200, Manfred Geiler wrote: > > Simon, > > Do you have a number? How many files do have tab characters? > > I think (b - fix them) would be the better solution. But only if that > > does not change every second file. > > --Manfred > > > > > > On Wed, Jul 2, 2008 at 7:28 PM, [EMAIL PROTECTED] > > <[EMAIL PROTECTED]> wrote: > > > Hi All, > > > > > > In the new checkstyle rules file I enabled checks for tab characters, as > > > the > > > myfaces convention is (AFAIK) to use 4 spaces, not tabs. However the > > > checkstyle report points out a lot of files containing tabs. > > > > > > It's no big deal, but do we want to: > > > (a) disable the checkstyle rule and ignore tabs or > > > (b) fix them? > > > > > > Tabs are a minor nuisance when viewing the source as some tools render 4 > > > spaces, some 8. > > > > > > I've written a simple shellscript that can clean this up very easily, and > > > am > > > happy to do so. The script also removes trailing whitespace from lines, of > > > which we also appear to have quite a lot. > > > > > > But doing this will create some large commit messages and make comparing > > > files with past versions noisier. It can also cause svn conflicts if > > > people > > > have modified files they have not yet committed, unless they run the > > > cleanup > > > script against their own working dir before doing svn update. > > > > > > So, option (a) or (b)? > > > > > > Regards, Simon > > > > > > > > > > > > >
[jira] Commented: (MYFACES-1888) catch Throwable errors when using ErrorPageWriter (myfaces error handling)
[
https://issues.apache.org/jira/browse/MYFACES-1888?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610346#action_12610346
]
Leonardo Uribe commented on MYFACES-1888:
-
After reproducing many error situations several conclusions where found:
1. All Throwable error events are encapsulated in a Exception when occur in
code called by EL expressions. So the actual code works fine for this cases.
2. Throwable error events inside custom validators, renderers, converters,
phaseListeners (without EL calls) are not catched by the actual code (the
behavior we want to correct).
3. Simulating StackOverflowError and OutOfMemoryError, catching works well but
on OutOfMemoryError sometimes the stack trace could not be rendered (because no
mem available!).
I'll commit a solution for both branches (1.1 and 1.2) soon
> catch Throwable errors when using ErrorPageWriter (myfaces error handling)
> --
>
> Key: MYFACES-1888
> URL: https://issues.apache.org/jira/browse/MYFACES-1888
> Project: MyFaces Core
> Issue Type: Improvement
>Affects Versions: 1.1.6-SNAPSHOT, 1.2.3
>Reporter: Leonardo Uribe
>Assignee: Leonardo Uribe
>
> One possible enhancement to the myfaces error handling capability is catch
> Throwable errors when using myfaces error handling.
> This should be done taking into account what the spec says about it:
> - Call the execute() method of the saved Lifecycle instance, passing the
> FacesContext instance for this request as a parameter. If the execute()
> method throws a FacesException, re-throw it as a ServletException with
> the FacesException as the root cause.
> Call the render() method of the saved Lifecycle instance, passing the
> FacesContext instance for this request as a parameter. If the render() method
> throws a FacesException, re-throw
> The idea is catch and rethrow non Exception classes like errors (extends from
> Throwable or Error classes directly). If Myfaces error handling is used use
> it to show the error page with the info, taking into account that not all
> info could be available.
> The idea is do this on FacesServlet:
> try {
> _lifecycle.execute(facesContext);
> if (!handleQueuedExceptions(facesContext))
> {
> _lifecycle.render(facesContext);
> }
> }
> catch (Exception e)
> {
> handleLifecycleException(facesContext, e);
> }
> catch (Throwable e)
> {
> //Handle Error and Throwable error cases (out-of-memory-errors,
> ).
> handleLifecycleThrowable(facesContext, e);
> }
> finally
> {
> facesContext.release();
> }
> Please note that any change should not break old functionality.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: [VOTE] Upgrade s:limitRendered to tomahawk
If that were done, I would recommend the name "renderOne". choose in
JSF sounds closer to the select* prefix, reserved for UIInput
components. renderOne is clear in that it shows that it affects
rendering, where choose does not define what it does (one could argue
that it was a bad naming decision for JSTL and XSLT). Choose to me
sounds more like a SELECT component than a choice to only render one.
But that is my opinion.
-Andrew
On Wed, Jul 2, 2008 at 3:58 PM, Mike Kienenberger <[EMAIL PROTECTED]> wrote:
> What Simon proposed makes a lot of sense to me.
>
>
> On Wed, Jul 2, 2008 at 1:18 PM, [EMAIL PROTECTED]
> <[EMAIL PROTECTED]> wrote:
>> Andrew Robinson schrieb:
You must have had a real use case that pushed you to write this
component.
Can you please describe it?
>>>
>>> The same as all usages of . The index based or more than
>>> one are just added benefits I threw in. I can provide examples, but I
>>> shouldn't have to.
>>
>> I certainly think all new components should have to provide proper
>> use-cases. Having very rarely used components in Tomahawk:
>> * makes it hard for users to find what they want (steeper learning curve)
>> * increases the maintenance burden
>> * increases the jarfile size
>>
>> So components should only go in if they are useful to a reasonable number of
>> people.
>>
>>> Just because someone can't think of when it would
>>> be needed, doesn't mean it never would be useful, but I can appease
>>> you curiosity.
>>
>> It's not curiosity. There is a vast amount of crap in Tomahawk right now, to
>> the point where Tomahawk is close to dying. There hasn't been a release for
>> a year. The number of open bugs is vast. So everyone *should* be watching
>> carefully to see that we don't increase the problems.
>>
>> That doesn't mean that good components cannot be added. But new stuff does
>> need to be evaluated for usefulness.
>>
>> And the author of a component is often too close to the code to see whether
>> it can be improved (that applies equally to me). Having other people look
>> critically at the purpose and API is very useful. You are free to point out
>> any issues with components I write (eg Orchestra stuff).
>>
>>> I created the component so that people would stop using
>>> c:choose and c:if in JSF pages and complain that they don't work in
>>> tables and such.
>>>
>>> 1) default c:choose functionality (render the first match):
>>>
>>>
>>> >> rendered="#{prefs.firstThenLast}" />
>>> >> rendered="#{prefs.firstThenLast}" />
>>>
>>>
>>
>> Yep, this is a good use case. As you demonstrate later in your email,
>> writing mutually-exclusive rendered expressions for a set of components can
>> get nasty.
>>
>> I'm not a JSTL user, so your reference to c:choose wasn't perhaps as clear
>> to me as it might be to others. I think this way:
>>
>> if (cond1) render component 1
>> else if (cond2) render component 2
>> else if (cond3) render component 3
>> else render component 4
>>
>> Expanding the javadoc for the component a bit would be good, mentioning that
>> it simplifies rendered expressions for mutually-exclusive components. The
>> current docs don't mention that the implicit condition associated with the
>> "choose clauses" is the rendered expression; it makes sense once I know what
>> the component is doing but wasn't obvious at first.
>>
>>> 2) render index based. This behaves much like the tr:switcher
>>> component. But instead of using facets and facet names, it uses
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> I'm not so sure about this. The tr:switcher makes sense to me; it chooses a
>> component to render by name which will not be easily broken by page changes,
>> and where the link between what the backing bean EL expression returns and
>> what facet is selected is clear (the name matches).
>>
>> Selecting by index has a far smaller set of use-cases I think. And it can
>> promote code fragility; coupling an index returned by the backing bean with
>> an array defined in the page has potential for trouble. But the wizard
>> use-case is an example of a valid use of this functionality.
>>
>>> 3) render multiple children. Can be used much like "-v" vs "-" can
>>> be used for command line verbosity
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>> Equivalent to this:
>>
>>
>>
>>
>> Yes, the limitRendered approach is a little more efficient; only one EL
>> expression evaluated rather than 3. But any JSF developer understands the
>> latter, while no-one can understand the limitRendered approach without
>> looking up the docs first. And a pretty rare use case I would think. Worth
>> including perhaps if it didn't have any other negatives, but I think it
>> does: it forces the name of the component to be generic and the
>> documentation to be complex.
>>
>>> Now I cannot tell you all the reasons they may be useful, but I can
>>> say that many time in Trinidad authors chose to only provide
>>> functionality that
[jira] Commented: (TRINIDAD-745) Support autocomplete attribute for input fields
[ https://issues.apache.org/jira/browse/TRINIDAD-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610253#action_12610253 ] Matthias Weßendorf commented on TRINIDAD-745: - and even worse, if the users actually select the value, offered from the bowser. The browsers (FF, IE, no idea on safari) don't trigger the callback to your onchange property... > Support autocomplete attribute for input fields > --- > > Key: TRINIDAD-745 > URL: https://issues.apache.org/jira/browse/TRINIDAD-745 > Project: MyFaces Trinidad > Issue Type: New Feature >Affects Versions: 1.0.3-core >Reporter: Stephen Friedrich >Assignee: Matthias Weßendorf > Attachments: autoComplete.patch > > > My app has some fields where it isn't useful to have the browser remember > and try to auto complete values. > In HTML you can switch that off with the non-standard "autocomplete" > attribute. > JSF 1.2 also added the same attribute, but Trinidad is still missing it. > Please see the attached patch for a possible implementation. I added the > attribute to all subclasses of InputText, with the exception of InputFile, > because the browser (well at least firefox) seems to never auto complete > those fields, anyway. To keep in line with the rest of Trinidad's attribute > names I used "autoComplete" with an upper case "C". > I have not added/modified any tests, because frankly I did not understand > what is currently tested and how it is tested. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-745) Support autocomplete attribute for input fields
[ https://issues.apache.org/jira/browse/TRINIDAD-745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610252#action_12610252 ] Matthias Weßendorf commented on TRINIDAD-745: - I think it is worth to add this to Trinidad. > Support autocomplete attribute for input fields > --- > > Key: TRINIDAD-745 > URL: https://issues.apache.org/jira/browse/TRINIDAD-745 > Project: MyFaces Trinidad > Issue Type: New Feature >Affects Versions: 1.0.3-core >Reporter: Stephen Friedrich >Assignee: Matthias Weßendorf > Attachments: autoComplete.patch > > > My app has some fields where it isn't useful to have the browser remember > and try to auto complete values. > In HTML you can switch that off with the non-standard "autocomplete" > attribute. > JSF 1.2 also added the same attribute, but Trinidad is still missing it. > Please see the attached patch for a possible implementation. I added the > attribute to all subclasses of InputText, with the exception of InputFile, > because the browser (well at least firefox) seems to never auto complete > those fields, anyway. To keep in line with the rest of Trinidad's attribute > names I used "autoComplete" with an upper case "C". > I have not added/modified any tests, because frankly I did not understand > what is currently tested and how it is tested. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-775) panelButtonBar is missing skinning
[
https://issues.apache.org/jira/browse/TRINIDAD-775?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610223#action_12610223
]
Carsten Pieper commented on TRINIDAD-775:
-
Yes, indeed, the given workaround is ugly. I came up with the same dirty
workaround
(OK , 5px in my case ;-) ), but this had unwanted side effects:
Assume you have a panelButtonBar which doesn't only contain buttons but also
commandLinks with icons in it. The rendered icon's img would be effected by
this setting, too, getting a width of 15px (well, 5px with me)...
The situation described above might not really be what the panelButtonBar's
creators
had in mind but it might be something (a clickable icon doesn't "feel" so far
off from
a normal button, does it?) that others might run into, too...
> panelButtonBar is missing skinning
> --
>
> Key: TRINIDAD-775
> URL: https://issues.apache.org/jira/browse/TRINIDAD-775
> Project: MyFaces Trinidad
> Issue Type: Bug
>Affects Versions: 1.0.3-core
>Reporter: Stephen Friedrich
>
> My client's styleguide mandates 15px gap between buttons.
> When I did not find anything in the skin selectors doc at first I thought the
> doc was just missing.
> When I inspected my page with Firebug I saw that a spacer image was hardcoded
> with 10px width and thought that the renderer was probably using a skinning
> property.
> So I looked at the source and found this in PanelButtonBarRenderer:
> protected void encodeSeparator( ...
> {
> // FIXME Use proper skinning techniques
> renderSpacer(context, rc, "10", "1");
>
> Well, yeah, a fix would be nice.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[TRINIDAD] Unable to use Converter with tr:inputDate
Hi,
I have JSF page which contains a tr:inputDate component as given below:-
As well as there is a commandButton
In the Backing bean the action method is as follows:-
public String action(){
DateTimeConverter converter = new DateTimeConverter();//the Trinidad DateTime
Converter
converter.setPattern("dd/MM/");
inputDate1.setConverter(converter);
return null;
}
While running the JSF page, on clicking the button the converter does get
applied, But after the Page gets rendered if the user again clicks on the
calendar button to select a new date then a javascript error appears
(/**incomprehensible**/). How else can I set the above mentioned converter on
the inputDate cpmponent from the backing bean.
pl. consider that I strictly need to set the converter from the backing bean.
Thanks,
Dushyant
Explore your hobbies and interests. Go to
http://in.promos.yahoo.com/groups/
Re: InputDate - [TRINIDAD-790]
Ok :-) I saw that you have included it also in 1.2.X trunk! Thank you!! Matthias Wessendorf wrote: Hi, thanks for the patch. I am already applying it. thanks! On Thu, Jul 3, 2008 at 10:42 AM, Gregor Sfiligoj <[EMAIL PROTECTED]> wrote: Hi all! As suggested by Matthias I provide a new patch for the InputDate problem (see TRINIDAD-790). This one is against the 1.0.X trunk. I'm interested in resolving this annoying bug because I have these components in production. I quote my previous post about the patch: [...] there were two problems: 1) DateField.js, function _dfsv(): daylight saving correction is no more needed. Also there are 2 duplicated functions (same name) _getLocaleTimeZoneDifference() in DateField.js and DateFormat.js. Results are different, because one needs difference in minutes and GMT (in DateFormat.js), the other one in millis with locale timezone correction. I renamed the function located in DateField.js. Without renaming there are conflicts because during creation of Common1_0_X.js one of them is overwritten. 2) SimpleInputDateRenderer.java: the _uixLocaleTZ variable should be setted also if no icon is rendered for the InputDate component. This happens when we use the ChooseDate component in combination with InputDate. I tested patches trying different settings in trinidad-config.xml, with and without DateTimeConverter and with different Locale settings in client browser (this affects javascript code). Tried also with the trinidad-demo application and works. [...] Best regards, Gregor Sfiligoj
[jira] Created: (TOBAGO-682) Facelets, page is not rendered correct, it toggles from ok - wrong - ok - wrong... by executing an actionListener
check the system time. Is it diffrent than current date time??
[jira] Updated: (TRINIDAD-790) datepicker selects wrong day
[ https://issues.apache.org/jira/browse/TRINIDAD-790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-790: Resolution: Fixed Fix Version/s: 1.2.9-core 1.0.9-core Status: Resolved (was: Patch Available) Thanks for the patch > datepicker selects wrong day > > > Key: TRINIDAD-790 > URL: https://issues.apache.org/jira/browse/TRINIDAD-790 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 1.0.3-core > Environment: Firefox 2.0.0.8 > Internet Explorer 6.0.2800.1106 > Trinidad 1.0.3 >Reporter: Daniel Niklas >Assignee: Matthias Weßendorf > Fix For: 1.0.9-core, 1.2.9-core > > Attachments: DateField.patch, InputDate_1.0.X_rev_1.patch, > SimpleInputDateRenderer.patch > > > The date-picker-popup of the inputDate-component > sets the wrong day into the -element. > E.g.: Select October and click "26". Then > "25.10.2007" is set into the -element. > This error occurs with the following months: > - April > - May > - June > - July > - August > - September > - October > You can reproduce this error here: > http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx > Best regards > Daniel Niklas -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (TRINIDAD-790) datepicker selects wrong day
[ https://issues.apache.org/jira/browse/TRINIDAD-790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610169#action_12610169 ] Matthias Weßendorf commented on TRINIDAD-790: - thnaks for the patch. > datepicker selects wrong day > > > Key: TRINIDAD-790 > URL: https://issues.apache.org/jira/browse/TRINIDAD-790 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 1.0.3-core > Environment: Firefox 2.0.0.8 > Internet Explorer 6.0.2800.1106 > Trinidad 1.0.3 >Reporter: Daniel Niklas >Assignee: Matthias Weßendorf > Attachments: DateField.patch, InputDate_1.0.X_rev_1.patch, > SimpleInputDateRenderer.patch > > > The date-picker-popup of the inputDate-component > sets the wrong day into the -element. > E.g.: Select October and click "26". Then > "25.10.2007" is set into the -element. > This error occurs with the following months: > - April > - May > - June > - July > - August > - September > - October > You can reproduce this error here: > http://www.irian.at/trinidad-demo/faces/components/inputDate.jspx > Best regards > Daniel Niklas -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: InputDate - [TRINIDAD-790]
Hi, thanks for the patch. I am already applying it. thanks! On Thu, Jul 3, 2008 at 10:42 AM, Gregor Sfiligoj <[EMAIL PROTECTED]> wrote: > Hi all! > > As suggested by Matthias I provide a new patch for the InputDate problem > (see TRINIDAD-790). This one is against the 1.0.X trunk. I'm interested in > resolving this annoying bug because I have these components in production. > I quote my previous post about the patch: > > [...] > there were two problems: > 1) DateField.js, function _dfsv(): daylight saving correction is no more > needed. Also there are 2 duplicated functions (same name) > _getLocaleTimeZoneDifference() in DateField.js and DateFormat.js. Results > are different, because one needs difference in minutes and GMT (in > DateFormat.js), the other one in millis with locale timezone correction. I > renamed the function located in DateField.js. Without renaming there are > conflicts because during creation of Common1_0_X.js one of them is > overwritten. > 2) SimpleInputDateRenderer.java: the _uixLocaleTZ variable should be setted > also if no icon is rendered for the InputDate component. This happens when > we use the ChooseDate component in combination with InputDate. > > I tested patches trying different settings in > trinidad-config.xml, with and without DateTimeConverter and with different > Locale settings in client browser (this affects javascript code). > > Tried also with the trinidad-demo application and works. > [...] > > > Best regards, > Gregor Sfiligoj > -- Matthias Wessendorf further stuff: blog: http://matthiaswessendorf.wordpress.com/ sessions: http://www.slideshare.net/mwessendorf mail: matzew-at-apache-dot-org
InputDate - [TRINIDAD-790]
Hi all! As suggested by Matthias I provide a new patch for the InputDate problem (see TRINIDAD-790). This one is against the 1.0.X trunk. I'm interested in resolving this annoying bug because I have these components in production. I quote my previous post about the patch: [...] there were two problems: 1) DateField.js, function _dfsv(): daylight saving correction is no more needed. Also there are 2 duplicated functions (same name) _getLocaleTimeZoneDifference() in DateField.js and DateFormat.js. Results are different, because one needs difference in minutes and GMT (in DateFormat.js), the other one in millis with locale timezone correction. I renamed the function located in DateField.js. Without renaming there are conflicts because during creation of Common1_0_X.js one of them is overwritten. 2) SimpleInputDateRenderer.java: the _uixLocaleTZ variable should be setted also if no icon is rendered for the InputDate component. This happens when we use the ChooseDate component in combination with InputDate. I tested patches trying different settings in trinidad-config.xml, with and without DateTimeConverter and with different Locale settings in client browser (this affects javascript code). Tried also with the trinidad-demo application and works. [...] Best regards, Gregor Sfiligoj
Re: [jira] Updated: (TRINIDAD-1135) Flush Cached Model for UIXCollection during broadcast
Hi Matthias, Can you please put the fix for 1.2.8.1 branch as well? I have a Oracle internal bug that is dependent on this fix. Thanks, Venkata Matthias Weßendorf (JIRA) wrote: [ https://issues.apache.org/jira/browse/TRINIDAD-1135?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Matthias Weßendorf updated TRINIDAD-1135: - Resolution: Fixed Fix Version/s: 1.0.9-core Status: Resolved (was: Patch Available) Fixed it on the JSF 1.1 trunk as well Thanks for the patch Flush Cached Model for UIXCollection during broadcast - Key: TRINIDAD-1135 URL: https://issues.apache.org/jira/browse/TRINIDAD-1135 Project: MyFaces Trinidad Issue Type: Bug Affects Versions: 1.2.8-core, 1.2.9-core Environment: All Reporter: Venkata Guddanti Assignee: Matthias Weßendorf Fix For: 1.0.9-core, 1.2.9-core, 1.2.8-core Attachments: trunk.patch If a UIXCollection component is used as a stamp inside another UIXCollection. The model for the collection can go stale during the broadcast of messages. This is because the model in the stamped UIXCollection could be pointing to the wrong one because of the stamp state processing during the decode/validate/update phase. The fix is to make sure that the stamped collection is using the right model based on the stamp state of the parent collection. This is done by simply calling _flushCachedModel(); at the beginning of the broadcast.
[jira] Commented: (TRINIDAD-1139) partial submit (for ppr) does not work for content type xhtml (_submitPartialChange() does not submitForm() for xhtml)
[ https://issues.apache.org/jira/browse/TRINIDAD-1139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12610163#action_12610163 ] Matthias Weßendorf commented on TRINIDAD-1139: -- OK, now I got it. the html snippet was more confusion than helpful :-) The real testcase helped. Looks like a problem with text/xml as contentType. This (instead of jsp:text) fails as well: > partial submit (for ppr) does not work for content type xhtml > (_submitPartialChange() does not submitForm() for xhtml) > --- > > Key: TRINIDAD-1139 > URL: https://issues.apache.org/jira/browse/TRINIDAD-1139 > Project: MyFaces Trinidad > Issue Type: Bug > Components: Components >Affects Versions: 1.2.8-core > Environment: Mac OS X 10.5.4, Glassfish, JSF1.2, Firefox 3.0, Safari, > 3.1.2 >Reporter: burghard.w.v.britzke > Attachments: test.jspx > > Original Estimate: 168h > Remaining Estimate: 168h > > xhtml rendered pages does not submit forms via _submitPartialChange() > I found the following code snippet in DebugCommon1_2_8.js in function > _submitPartialChange() > 9176 // Get the actual form object > 9177 if ((typeof form) == "string") > 9178 form = document[form]; > 9179 > 9180 if (!form) > 9181 return false; > 9182 > the expression document[form] returns --> undefined for xhtml documents > so this function exits always without submitting. > my sample document > > "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd";> > http://www.w3.org/1999/xhtml";> > > test > > > > > > alerts the following message: "undefined [object HTMLFormElement]" > there are other places where document[form] is used in DebugScript1_2_8.js -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
