I removed the
> > > > if ( stringValue.length() == 0 )
> > > > {
> > > > set_flag = false;
> > > > }
> >
code that you mentioned from Field and moved it to some of the number
fields where i think it is still needed. This is checked into the head
of the fulcrum repo. Sorry, I forgot to give notice. Please let me
know if this helps your situation.
john mcnally
Rodney Schneider wrote:
>
> Hi John (and any other Intake users),
>
> Sorry to spam the list again, but if someone could just let me know what the
> issues are, I could spend the time coming up with a proposal to fix this bug.
>
> All I really need to know is if anyone's existing Turbine applications rely
> on this bug in Intake for their correct operation.
>
> At the moment in our application, we are forced to work around the bug in our
> Action classes, by doing explicit checking on the value of the affected
> fields before validation. I'll cut and paste some code from one of our
> actions into this email as it has been particularly well commented by one of
> my fellow developers....
>
> -----------------------------------------------------------------
>
> // This runs through all the fields in the group, and sets
> // them in the project, _if_ they have been set in the input.
> // Note however that a parameter present in the input but
> // with an empty value is currently treated by Intake as
> // unset (that is, Field foo.isSet() returns false), so
> // we need the following workaround to allow the user to
> // empty out optional fields.
> projectGroup.setProperties(project);
>
> // Allow the user to null out optional fields.
> // Note that this workaround is itself problematic, because
> // it cannot distinguish between empty and missing parameters
> // (getTestValue() returns null in either case), which means
> // that if we remove these fields from the front-end form,
> // we have to remember to remove the workaround here (or
> // else these properties will always get nulled out).
> if (projectGroup.get("Description").getTestValue() == null)
> project.setDescription(null);
> if (projectGroup.get("Theme").getTestValue() == null)
> project.setTheme(null);
>
> -----------------------------------------------------------------
>
> Has anyone who uses Intake encountered this bug before? Any feedback would
> be greatly appreciated.
>
> Thanks,
>
> -- Rodney
>
> > On Tue, 26 Mar 2002 04:23, you wrote:
> > > I think removing the conditional that you suggest will have other
> > > repercussions. I will look further at this, but it will probably be a
> > > few days.
> > >
> > > john mcnally
> > >
> > > Rodney Schneider wrote:
> > > > Hi Edmund and John!
> > > >
> > > > I have sent two emails to this list regarding this bug in Intake and
> > > > no-one has replied yet :( It exists in both the most recent Turbine
> > > > 2.2 code and the most recent CVS version of Fulcrum.
> > > >
> > > > I'll try to explain myself a bit better this time as maybe the bug
> > > > report I sent wasn't clear. See this message...
> > > >
> > > > http://www.mail-archive.com/[email protected]/msg06959.ht
> > > >ml
> > > >
> > > > > > > I have got a problem with the rules for checking field values in
> > > > > > > intake. Somehow I cannot check for empty fields. I define the
> > > > > > > rule as explained in the docs like this:
> > > > > > >
> > > > > > > ..
> > > > > > > <field name="PersonName" key="personname" type="String">
> > > > > > > <rule name="minLength" value="1">Bitte geben Sie den
> > > > > > > Nachnamen an.</rule> </field>
> > > > > > > ..
> > > > > > >
> > > > > > > When I leave the field empty, intake does not report an error.
> > > > > > > (isAllValid() still returns true)
> > > > > >
> > > > > > not sure why this does not work.
> > > >
> > > > If a browser submits a form with an empty text field (with, say, the
> > > > parameter name="foo"), then the request parameters will come in in the
> > > > form "?foo=&bar=..." etc., and both javax.servlet.HttpServletRequest
> > > > and org.apache.turbine.util.ParameterParser will report that the
> > > > parameter "foo" is present with the value "" (the empty string).
> > > > However, org.apache.turbine.services.intake.model.Field will treat this
> > > > field as if it is not present at all: specifically, in the method
> > > > validate() is the following code:
> > > >
> > > > stringValue = pp.getString(getKey());
> > > > if ( stringValue.length() == 0 )
> > > > {
> > > > set_flag = false;
> > > > }
> > > >
> > > > Thus, there is no way to distinguish between an empty field and a field
> > > > that is not present in the HTML form at all.
> > > >
> > > > I am happy to generate a patch that removes the above check, but I am
> > > > not sure if this will affect the rest of the Intake code...
> > > >
> > > > > > > I have experimented a bit with intake, and other rules actually
> > > > > > > do work as expected, if the field value is not empty. It seems
> > > > > > > the rules simply bypassed for empty fields and no checks are
> > > > > > > applied. So I also tried setting the required messsage:
> > > > > > >
> > > > > > > ..
> > > > > > > <field name="PersonName" key="personname" type="String">
> > > > > > > <required-message>Bitte geben Sie den Nachnamen
> > > > > > > an.</required-message> </field>
> > > > > > > ..
> > > > > > >
> > > > > > > Again, no error when I leave the field empty. Is this a bug in
> > > > > > > the intake service (included in TDK 2.1 release) or am I doing
> > > > > > > something wrong?
> > > >
> > > > See above.
> > > >
> > > > > > <required-message> is to provide a message that is to be displayed
> > > > > > if the field is declared as required and the field is empty. It
> > > > > > does not make the field required.
> > > > > >
> > > > > > <rule name="required" value="true">Bitte geben Sie den Nachnamen
> > > > > > an.</rule>
> > > > > >
> > > > > > should work, though i have not looked at what's in 2.1 for a while.
> > > > >
> > > > > Thanks for the quick reply. That rule actually does seem to work
> > > > > (though I cannot find anything about a rule with name "required" in
> > > > > the intake docs at
> > > > > http://jakarta.apache.org/turbine/turbine-2/services/intake-service.h
> > > > >tm l).
> > > >
> > > > The "required" rule does work, but this doesn't help in all situations.
> > > > One simple example is an "Edit User Profile" form which contains an
> > > > "Email Address" field that is not required and a "Work Phone Number"
> > > > field that is required. When a user first registers, they type in a
> > > > valid email address in the "Email Address" field and their current work
> > > > phone number in the "Work Phone Number" field. Then they change jobs,
> > > > so they go to the Edit User Profile page, empty the email address
> > > > field, edit the work phone number field (but accidentally type a 'abc'
> > > > instead of a valid number) and submit the form. Intake finds the the
> > > > Work Phone Number field is invalid so it redisplays the page containing
> > > > the form with the appropriate error message. HERE IS THE PROBLEM....
> > > > the email address field is pre-populated with the old email address
> > > > even though the user had previously emptied it!!
> > > >
> > > > This happens because Intake doesn't disinguish empty fields from fields
> > > > that are not present in the form at all. See my other email for more
> > > > information.
> > > >
> > > > > A bit odd is, that the isAllValid() method still returns true, but
> > > > > lateron when I try to assign the fields to the proper data object
> > > > > (using the group.setProperties() method) an exception is thrown
> > > > > (message: "Attempted to assign an invalid input").
> > > > >
> > > > > Maybe I can figure out another way to check the field validity
> > > > > (either that, or I will have to watch for that exception).
> > > >
> > > > I think the abovementioned code should be removed from
> > > > org.apache.turbine.services.intake.model.Field and
> > > > org.apache.fulcrum.intake.model.Field but, again, I am not sure whether
> > > > other code in Intake relies on the above check or whether existing
> > > > applications that use Intake will be affected.
> > > >
> > > > If you want me to submit a patch, please let me know.
> > > >
> > > > Thanks,
> > > >
> > > > -- Rodney
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
