← 返回首页
DefaultModuleService: change persisting of items by stelfrich · Pull Request #236 · scijava/scijava-common · GitHub
Skip to content

Navigation Menu

Toggle navigation
Sign in
Appearance settings
Search or jump to...

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Include my email address so I can be contacted

Saved searches

Use saved searches to filter your results more quickly

Appearance settings
Resetting focus

DefaultModuleService: change persisting of items#236

Open
stelfrich wants to merge 5 commits into
scijava:masterfrom
stelfrich:disable-persist-if-initialize
Open

DefaultModuleService: change persisting of items#236
stelfrich wants to merge 5 commits into
scijava:masterfrom
stelfrich:disable-persist-if-initialize

Conversation

Copy link
Copy Markdown
Member

Disable the persisting of a ModuleItems if an initialize() method is set and is not empty. This way, initialize() can overwrite the value of a ModuleItem even if persist=true is assumed implicitly.

See:

Copy link
Copy Markdown
Member

Did this work well in your tests?

Copy link
Copy Markdown
Member Author

It works as I expect it to work after resetting the Prefs. That leaves us with two issues:

  1. If a ModuleItem has been persisted previously, this value will still overwrite initialize()
  2. With this change, explicitly setting persist=true for a ModuleItem that also has initializer set, will disable persisting (that's what we have expected)

I couldn't find any other odd behavior. But as you have already mentioned, we might be breaking someone else's code with this change.

Copy link
Copy Markdown
Member Author

With this change, explicitly setting persist=true for a ModuleItem that also has initializer set, will disable persisting (that's what we have expected)

I have added clarifying documentation in Parameter.

import static org.junit.Assert.assertNull;
import static org.junit.Assert.assertSame;

import java.security.GeneralSecurityException;
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Choose a reason Spam Abuse Off Topic Outdated Duplicate Resolved Low Quality Hide comment

???

Copy link
Copy Markdown
Member Author

Thanks for the comments (and being so patient), @ctrueden! They have been addressed.

Copy link
Copy Markdown
Member

ctrueden commented Aug 5, 2016

I gave this a little more thought, and here is what I would like to do:

  • Change persist to a ternary enum: YES, NO and DEFAULT or some such. We can have DEFAULT behave as you have coded here—and in fact, tweak the persistence heuristic as needed for what we deem is most reasonable going forward. If someone says YES, they know better, and want it saved. And similarly, NO means NO. 😉

I would like to include this update as part of the SJC3 release, due within the next few months. There is an sjc3 integration branch containing all such changes, where the above changes should go.

If you have time to tackle it, great. Or if not, I will take care of it before SJC3 is released.

ctrueden added this to the 3.0.0 milestone Aug 5, 2016
stelfrich force-pushed the disable-persist-if-initialize branch from b0fe402 to c9992de Compare August 8, 2016 07:22
stelfrich and others added 5 commits August 8, 2016 09:30
Disable the persisting of a ModuleItems if an initialize() method is set and is not empty. This way, initialize() can overwrite the value of a ModuleItem even if persist=true is assumed implicitly. See: * imagej/imagej-legacy#137 (comment)
Introduces the ItemPersistence enum (YES, NO, DEFAULT). YES and NO overwrite additional checks (i.e. precedence of an initializer, value is default value). In case of DEFAULT, the value is persisted only if it is not the default value and no initializer is set.
stelfrich force-pushed the disable-persist-if-initialize branch 2 times, most recently from 0c50673 to b4e8a32 Compare August 8, 2016 10:53
Copy link
Copy Markdown
Member Author

If you have time to tackle it, great.

I did, @ctrueden. But that invalidates all Commands with bytecode of the previous Parameter implementation, right? How would I test this implementation in an ImageJ2 installation - I am a bit lost here 😕

Copy link
Copy Markdown
Member

ctrueden commented Jan 1, 2017

FYI, my plan is to merge this into the sjc3 branch. Will do soon.

Copy link
Copy Markdown
Member

ctrueden commented Feb 1, 2017
edited
Loading

Just a quick update: I looked into doing this earlier in January, but the sjc3 branch of scijava-common is quite out of date. It needs a rebase over the latest scijava-common. In particular, all the logging updates are now incompatible with the changes on master as well as the log-revamp branch.

So it will be a while longer before I have time to get all this unified. Probably April. I am anxious to get SJC3 finished and merged, but it's going to be a substantial endeavor.

The good news is that I won't forget about this PR, thanks to its inclusion in the 3.0.0 milestone.

ctrueden added the to do label Oct 3, 2018
ctrueden force-pushed the master branch 3 times, most recently from 53b6733 to 3dc99c9 Compare November 7, 2023 18:37
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants

Footer

© 2026 GitHub, Inc.