[MAGNOLIA-1119] Required field in dialog Created: 10/Oct/06  Updated: 01/Mar/07  Resolved: 01/Mar/07

Status: Closed
Project: Magnolia
Component/s: gui
Affects Version/s: 3.0 RC2
Fix Version/s: None

Type: Bug Priority: Major
Reporter: Capitaine Harold Assignee: Magnolia International
Resolution: Duplicate Votes: 2
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

OS: windows XP Pro, Tomcat 5.0, java j2sdk1.4.2_12


Attachments: Text File DialogControlImpl.patch     Text File DialogControlImpl.patch     Text File patch.txt    
Issue Links:
relation
is related to MAGNOLIA-1310 required option on dialog field is no... Closed
supersession
is superseded by MAGNOLIA-1361 validation check for missing required... Closed
Template:
Acceptance criteria:
Empty
Task DoD:
[ ]* Doc/release notes changes? Comment present?
[ ]* Downstream builds green?
[ ]* Solution information and context easily available?
[ ]* Tests
[ ]* FixVersion filled and not yet released
[ ]  Architecture Decision Record (ADR)
Bug DoR:
[ ]* Steps to reproduce, expected, and actual results filled
[ ]* Affected version filled
Date of First Response:

 Description   

When putting a field in a dialog to required, the field still can be empty.
Problem should come from DialogControlImpl.java in the validate function.
More precisely in the second part of the test.



 Comments   
Comment by Capitaine Harold [ 18/Oct/06 ]

This bug also concerns the release RC3.
It affects the core component. Because each dialog are concerned by this bug.

Comment by Ali Hammadi [ 29/Nov/06 ]

This is my solution to correct the bug of required fields.
It have to be validated.

Comment by Ali Hammadi [ 29/Nov/06 ]

Please use this file for the patch.
Don't care with the previous

Comment by Chris Miner [ 22/Jan/07 ]

Is the concept expressed in this patch essentially not correct or is there another reason it isn't applied and is not part of the code base already?

Comment by Magnolia International [ 22/Jan/07 ]

It's mostly that nobody had the time to look yet
(and yes, by looking at it quickly, the patch could be improved - there is no reason to collect the list of empty values to know if there's an empty one)

Comment by Chris Miner [ 22/Jan/07 ]

well yes from the logic of it all one could stop once any non empty value was found. I think the intention is to find out if all the values of getValues() are empty. Stopping with just one empty value wouldn't be the same thing. But then I wondered if there was some logic to putting the empty values in the list returned from getValues() in the first place. Maybe the right fix it to not add them to the list returned by getValues() in the first place? Unless an empty value in that context has a semantic meaning such as 'delete this property'. In which case you would want to differenciate between an empty value and no value.

Comment by Chris Miner [ 08/Feb/07 ]

Here's my version of the patch.

Comment by Chris Miner [ 08/Feb/07 ]

After working with my patched version for a while, I notice that the alert panel telling me that a property is missing is incorrectly localized. That is to say although my dialog is localized, the alert panel is not despite the fact that it looks like the code is attempting to do this.

I tracked this down to the fact that at the time the validation is being done, the DialogControlImpl instance doesn't have a parent. The parent for such controls seems to be setup at render time. So... no access to the i18nbasename set in the dialog. Furthermore this failed attempt during validation leads to a misconfigured result from getMessages, when the dialog is later rendered and has a parent. This means the dialog label suddenly becomes unlocalized for fields that are required but fail the check.

There is a workaround though. You can add i18nbasename properties to everyone of your dialog controls which are required. That way the right localized label is used in the alert panel that comes back, and same correctly localized label is shown in the dialog.

But then there is the problem that only the first invalid field is reported. Via an alert panel. Better would be to indicate at least all required fields at once. With a color or something. see http://jira.magnolia.info/browse/MAGNOLIA-1361. Interestingly enough this is exactly where the if (StringUtils.isEmpty(this.getValue()) && this.getValues().size() == 0) bit actually works correctly for non multivalued fields and my patch doesn't.

To make a long story short have a look at http://jira.magnolia.info/browse/MAGNOLIA-1361.

Comment by Sameer Charles [ 22/Feb/07 ]

Chris, Does MAGNOLIA-1361 with your patches also solves this issue? so we can simply ignore the patches attached to this issue

Comment by Magnolia International [ 27/Feb/07 ]

will apply patches from MAGNOLIA-1361

Comment by Magnolia International [ 01/Mar/07 ]

Superseded by MAGNOLIA-1361

Generated at Mon Feb 12 03:23:50 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.