AW: InputCalendar does not work as popup
Hi Martin,
nice to hear. The onchange attribute already exists, like all the other
javascript related ones. But the submit is not executed right now if one select
a new date. Although I do not know whether any kind of javascript is executed.
I did not test that yet.
Bye, Daniel
-Ursprüngliche Nachricht-
Von: Martin Marinschek [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 6. Oktober 2005 17:48
An: MyFaces Discussion
Betreff: Re: InputCalendar does not work as popup
Bug # 1 and 2 are already fixed in the current head version
#3 & 4 are about to be fixed.
onchange should exist as an attribute in inputCalendar, right?
regards,
Martin
On 10/6/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
>
>
> Hi,
>
> I am having trouble using the input calendar component as popup. The effects
> described below can be reproduced with version 1.1.0 in our production
> environment (OC4J, Java 1.5) and in several Tomcat versions (4.1, 5.0, 5.1,
> deploying myfaces examples) using IE, Firefox and Opera.
>
>
>
> When the Button is clicked and the popup opens, the icons / symbols for
> switching the month back and forward ("the arrows") are rendered only when
> the mouse has been moved over them.
> Selecting a month from the dropdown list works fine, selecting a year from
> the dropdown list simply closes the complete popup, no new year is selected.
> The "Today is" pattern cannot be localized / customized. Same to the week
> number ("Wk" in English).
> The "Click to select" pattern in the status bar of the browser cannot be
> localized / customized
> Maybe I am blind, but I am not able to make a submit after selecting a new
> value e.g. by executing "submit();" onchange.
>
>
>
> As I expect the calendar component to have been tested and for others it
> works properly, I have no idea why it does not here. Any ideas?
>
>
>
> Thanks, Daniel
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
InputCalendar does not work as popup
Hi, I am having trouble using the input calendar component as popup. The effects described below can be reproduced with version 1.1.0 in our production environment (OC4J, Java 1.5) and in several Tomcat versions (4.1, 5.0, 5.1, deploying myfaces examples) using IE, Firefox and Opera. When the Button is clicked and the popup opens, the icons / symbols for switching the month back and forward (“the arrows”) are rendered only when the mouse has been moved over them. Selecting a month from the dropdown list works fine, selecting a year from the dropdown list simply closes the complete popup, no new year is selected. The “Today is” pattern cannot be localized / customized. Same to the week number (“Wk” in English). The “Click to select” pattern in the status bar of the browser cannot be localized / customized Maybe I am blind, but I am not able to make a submit after selecting a new value e.g. by executing “submit();” onchange. As I expect the calendar component to have been tested and for others it works properly, I have no idea why it does not here. Any ideas? Thanks, Daniel
AW: Migration to 1.1.0 causes ValueChangeListener problems
Hi,
your explanations sound reasonable, but do not really help us. For most of the
input fields, we do not use a value binding to a java beans field, but bind the
components themselves (e.g. HTMLInputText). And those are initialized by their
default constructors (new HTMLInputText()) without setting any value.
Therefore for me it seems, that the MyFaces implementation sets the default
value value of these components to null instead of an empty String. Setting the
value to "" after the submit without any user input is not consistent then.
Bye, Daniel
-Ursprüngliche Nachricht-
Von: Martin Marinschek [mailto:[EMAIL PROTECTED]
Gesendet: Montag, 26. September 2005 09:19
An: MyFaces Discussion
Betreff: Re: Migration to 1.1.0 causes ValueChangeListener problems
Sorry for ignoring your post,
here the answer:
MyFaces 1.0.9 had a TCK compatibility bug with respect to setting nulls back to
the backend, instead of an empty string.
I still haven't checked though if a value change listener ought to be fired in
this case. I would suppose that not, but will need to check the RI what it does
in this case.
Fancy checking it out and open a jira issue if we don't do as the RI does?
regards,
Martin
On 9/26/05, Boris Klug <[EMAIL PROTECTED]> wrote:
> Hi!
>
> I had the same problem. I figured out that we set most values to null,
> not to an empty String (""). After submitting the form, the value was
> an empty String, so the value changed and the events get fired.
>
> We changed the initial value to an empty String and now I no longer
> get the valueChangedEvents.
>
> See my posting here:
> http://www.mail-archive.com/users%40myfaces.apache.org/msg09062.html
>
> I asked there if this is the normal behaviour but got no answer.
>
>
>
> [EMAIL PROTECTED] wrote:
> > Hi,
> >
> > I upgraded our app simply by replacing the jars of the 1.0.9 version
> > against the new ones (configuration changes have not been necessary).
> > Almost everything of the application works fine but:
> >
> > When a form is submitted, all methods which are registered as
> > valueChangeListener are called, even if the concerning UIInput has
> > no value or the value has not been changed.
> >
> > Since we have many valueChangeListeners on some pages and perform
> > some complex stuff in them, the business logic does not work any longer.
> >
> > Thanks fpr help,
> >
> > Daniel
>
--
http://www.irian.at
Your JSF powerhouse -
JSF Trainings in English and German
Migration to 1.1.0 causes ValueChangeListener problems
Hi, I upgraded our app simply by replacing the jars of the 1.0.9 version against the new ones (configuration changes have not been necessary). Almost everything of the application works fine but: When a form is submitted, all methods which are registered as valueChangeListener are called, even if the concerning UIInput has no value or the value has not been changed. Since we have many valueChangeListeners on some pages and perform some complex stuff in them, the business logic does not work any longer. Thanks fpr help, Daniel
