Re: [ice-dev] Try out Entry Refactor

["Smith, Robert W." <smithrw@xxxxxxxx>]

Alex,

The MOOSE SWTBot test failed because of a couple of things that might be errors, or might be intentional changes.

MOOSE Items no longer give a "Ready to process" message after saving.

Entries for continuous ranges no longer give the range of valid values. (ie "The value mus be between 1 and 10000" vs the current "The value must be a valid number."

If the way these are currently working is fine, let me know and I'll update the tests to reflect that.

Robert
________________________________________
From: ice-dev-bounces@xxxxxxxxxxx <ice-dev-bounces@xxxxxxxxxxx> on behalf of McCaskey, Alex <mccaskeyaj@xxxxxxxx>
Sent: Thursday, January 21, 2016 3:18 PM
To: ice developer discussions
Subject: [ice-dev] Try out Entry Refactor

Hey Everyone,

I’ve spent a lot of time reworking the Entry infrastructure over the last week. What worked well in the beginning for the Entry was starting to become a little to complicated (think about how we’ve had to keep adding AllowedValueTypes) as the project as grown over the last couple years.

So now, the Entry/IEntryContentProvider is no more. In its place is an IEntry interface, which exposes basically the same functionality as the Entry did - set/get value, default value, allowed values, etc. Right below that is the AbstractEntry, which realizes the IEntry interface for as much common basic stuff as it can, and keeps more specialized operations abstract for further subclasses.

Below the AbstractEntry is where it gets interesting, and where the power of this new refactor lies. Subclasses of AbstractEntry decide how they want to implement things like setting values, handling discrete values, files, executables, and whatever else we can think of. I have implemented AbstractEntry subclasses for all of our previous AllowedValueTypes - StringEntry for Undefined, DiscreteEntry for Discrete, FileEntry for File, ContinuousEntry for Continuous, and ExecutableEntry for Executable. FileEntry, ContinuousEntry, and ExecutableEntry are all specializations of DiscreteEntry, and it’s really easy to instantiate them now in your Items:

IEntry continuousEntry = new ContinuousEntry(“0”, “100”);
IEntry booleanEntry = new DiscreteEntry(“true”, “false”);
IEntry fileEntry = new FileEntry(“mug.e”, “out.e”, “hello.e”);

On the UI side, we now have multiple EntryComposites, instead of the one with a large switch. To keep in sync with the new UI refactor, I’ve made IEntryComposite and IEntryCompositeProvider interfaces, with AbstractEntryComposite and DefaultEntryCompositeProvider realizations. For each IEntry realization, we have a different subclass of AbstractEntryComposite that renders itself according to the type of IEntry it has. For example, FileEntryComposite knows it’s rendering a FileEntry, so it throws up a drop down and a browse button. It is also now really easy to swap out these Composites, due to the ability to expose IEntryCompositeProviders through the Extension Registry.

Ok, so with all that said, I would like to ask everyone to pull down this branch and test out your specific Items - Andrew make sure the Vibe stuff still works, Robert check that your UI SWTBot tests still work (specifically the widgets.test bundle, which I seem to be having trouble with). I have tested the Moose and Reflectivity Items and they look good, but feel free to double check me.

Respond to this if you find any bugs or have any questions about how the new IEntries work.

Alex McCaskey
_______________________________________________
ice-dev mailing list
ice-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ice-dev