Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Generic MaskFormatter that handles AllowNull #119

Merged
merged 7 commits into from
Mar 19, 2022
Merged

Generic MaskFormatter that handles AllowNull #119

merged 7 commits into from
Mar 19, 2022

Conversation

errael
Copy link
Contributor

@errael errael commented Feb 21, 2022

This has the basics. This mask formatter used in SSDateField and it's Factory.

Added Format enum, rather than DateFormat enum, probably controversial. Not sure how I feel about it, but in terms of allowing an app to specify it's own default formats this might be handy starting place. Can discuss in #18 or this PR.

Wanted to set initial state of SSDateField, after Nav's AddRecord button is pushed, to either null or current date depending on AllowNull. I put the logic in SSDateField.cleanField() but it never gets called (from anywhere). Any idea how this can be done?

At the very top there's SSFormatteTextField.VISIBLE_ERROR_STATE. When true, the field goes redish when it hold an invalid value. When false, it has the previous behavior and the field goes red when you try to leave the field and it's invalid. I had difficulty getting the new behavior to match the old behavior, any idea?

@errael errael requested a review from bpangburn February 21, 2022 21:52
Copy link
Owner

@bpangburn bpangburn left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Minor comments here and there. Still need to hammer on it a bit. Previous edition worked pretty well.

@@ -50,12 +50,16 @@

/**
* constant representing the dd/mm/yyyy date format
* @deprecated
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Where we deprecate things and there is a replacement method/constructor, I'm a fan of * @deprecated use {@link #replacementMethod() } JavaDoc. Several examples in SSDBComboBox.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Left the unadorned @deprecated as a reminder which I forgot.

Strangely @deprecated use {@link Format.DATE_DDMMYYYY} fails javadoc build. Javadoc enum handling problem? Maybe you can come up with something.

Doing it like @deprecated use {@link Format}'s DATE_DDMMYYYY

*/
public static final int YYYYMMDD = 2;
// Don't like the way default is buried in get(Format) case label.
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does the need for a default format for each general type swing the enum approach one way or the other? I guess you're handing this with Format.DATE.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Right, left over comment before adding Format.DATE to signify default.

The single enum approach would allow something like SSFormattedTextField.get(Format.DATE) to return a text field with default formatter for the given type. Another reason is to make it easier to specify the default per app, rather than spreading it around in the different places FormatterFactory.

I think you mentioned somewhere that there could be an enum that just has the types like DATE/MONEY/... and then separate enums for each sub-type. That would work as well, the default sub-type would be specified as part of the type enum; that does feel cleaner and gives more compile time checking. It also gives a single spot for specifying the default sub-type for a given type.

After all the other issues are addressed, I'll put together a change just for the enums. Please speak up with any naming and/or other conventions in this area.

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In com.nqadmin.swingset.enums we use mixed case class enum name and all caps items, which is what you were doing with FORMAT enum. I guess we could consider a .formatting.enus package, but that might be overkill. Should we try to use the delimiter in the item names? YYYYMMDD_DELIM_HYPEN? Probably not. Other formatters might have multiple delimiters/separators (e.g., currency might have "." for cents and "," for thousands). Just trying to list some things that might cause enum ambiguity or confusion if we're going to handle order and delimiters, etc. in a single enum item.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One possibility (blue sky) would be to only have FieldType enum. Then something like

  • SSFormattedTextField DateField.get() returns something with reasonable defaults
  • SSFormattedTextField DateField.builder().mask("xxx").delimiter("").validator(doVal).build() if you don't want the defaults

Then you don't need any enums. But this might be to open ended especially considering that it has to work with the verifier; I guess the stuff like DATE_YYYYDDMM sets up a variety of things so it all works together, and is a convenience. But in general, each subType may have it's own set of options and that complicates things again.

It might be a good idea to consider/try a few more Type implementations. I'm getting confused as to what's needed.

// TODO Consider setting to null vs system date.
if (!getAllowNull()) {
setValue(new java.util.Date());
}
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want/need to call setValue(null) if getAllowNull()==true? Same for cleanField(). Maybe the constructor should just call cleanField() if we keep that method?

Copy link
Contributor Author

@errael errael Feb 24, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Does it matter what we do in the constructor? Nothing's bound yet, no idea what AllowNull is.

How about just don't do anything in the constructor and count on the rest of the system and/or app to take care of it?

Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Makes sense on the constructor since we don't know what getAllowNull() will give. What about cleanField() presuming we figure out how to call it when appropriate? Seems safest to set to null if allowed or you could get some unexpected dates propagating to the database. Would rather force the end user to fill explicitly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Even if !Allowed, could set to null. Then it shows up red.

I've got a PR ready with the background color stuff working, empty constructor, cleanField called for new record. I'll push that and you can take a look, see how it feels.

@@ -0,0 +1,418 @@
/* *****************************************************************************
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

New method so will probably try to digest in Eclipse rather than in GitHub site.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

FYI, SSMaskFormatterFactory had no changes from the first preview you saw.

SSDateField.cleanField uses AllowNull. Avoid potential NPE in updateSSComponent.
@errael
Copy link
Contributor Author

errael commented Feb 24, 2022

This latest commit should take care of the basics. Then the background colors. By the time that's done, we should be able to decide on the format enums.

@bpangburn bpangburn changed the base branch from 4.0.9-SNAPSHOTV2 to 4.1.0-SNAPSHOT March 17, 2022 14:19
@bpangburn
Copy link
Owner

bpangburn commented Mar 19, 2022 via email

@errael
Copy link
Contributor Author

errael commented Mar 19, 2022

We can pull this.

"pull"? Did you mean merge?

Hopefully if we redo the Enums it won’t create merge issues, but seems like it should be fine.

If we discuss/coordinate on the enums, I agree that we should be able to avoid merge hell.

@bpangburn
Copy link
Owner

@errael Yes. I guess that "Merge pull request" means you Request that I Pull your branch/changes into 4.1.0-SNAPSHOT, which Merges them into 4.1.0-SNAPSHOT? Merge sounds better :) and is a bit more intuitive.

I'll go ahead and merge this and then I may create a new branch based on the latest 4.1.0-SNAPSHOT to play with the colors/borders and then maybe start to look at another formatter (maybe SSN or Currency).

@bpangburn bpangburn merged commit 1e47bca into bpangburn:4.1.0-SNAPSHOT Mar 19, 2022
@errael errael deleted the MaskFormatterNull branch March 19, 2022 20:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants