This question is not answered. Helpful answers available: 2. Correct answers available: 1.


Permlink Replies: 5 - Pages: 1 - Last Post: 7 Jun 22, 14:43 Last Post By: JeffTucker Threads: [ Previous | Next ]
JeffTucker

Posts: 8,288
Registered: 31-Jan-2006
Needed: a more reliable variable correction mechanism
Posted: 6 Jun 22, 14:26
 
  Click to reply to this thread Reply
This issue came up last year in the midst of a somewhat confused discussion of a related problem, but it never went anywhere. Rather than bump that old thread....

Let's say that version 12 of SomeSkin includes a JCheckBox for showThing, and it defaults to false. In version 13, that's been replaced by a JComboBox for whatThing (a new variable), with four choices: neither, thing, thing2, and both, and that it defaults to neither.

Now imagine that a user has, in version 12, set showThing to true. If he just installs version 13 and makes the album, he's not going to see thing in his albums - the new default setting of neither doesn't know anything about his prior choice.

So what do I do in my skins? When a project is loaded, and the skin detects that it was made with a version of SomeSkin older than version 13, it says, "if showThing was true, set whatThing to thing instead of neither." No breakage. The result is what the user expects, and thing is displayed in his album.

But this happens only when the project is opened in the application, and the skin's GUI is loaded. When running from the command line or multi-maker, the GUI is never loaded, and the "fix" code is never executed.

I'm open to suggestions. Putting the variable corrections in a .jar file other than the regular skin GUI, something that's executed no matter how the project file is opened, would be one approach. Or, the command line and multi-maker could actually load the GUI, but in a "dummy" mode, in which the GUI would never actually be displayed.
RobM

Posts: 4,247
Registered: 4-Aug-2006
Re: Needed: a more reliable variable correction mechanism
Posted: 6 Jun 22, 16:20   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Instead of fixing the settings in init.bsh why not set them in predir.bsh? That should get processed either way jAlbum is run.
JeffTucker

Posts: 8,288
Registered: 31-Jan-2006
Re: Needed: a more reliable variable correction mechanism
Posted: 6 Jun 22, 16:36   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
RobM wrote:
Instead of fixing the settings in init.bsh why not set them in predir.bsh? That should get processed either way jAlbum is run.

Both of those options - init.bsh and predir.bsh - are nonstarters.

The user opens a saved project, but with a new skin version. He looks at the settings. None of the fixes has been applied. But then he makes the album, and suddenly, things are happening that weren't revealed in the project settings. Ugh.

Even worse, he looks at the settings and makes some changes. But then the templates are executed, and make fixes that the user has already chosen to do differently.

But beyond that, in my example above, the showThing variable is no longer present in version 13 of the skin. By the time any of the skin templates is executed, the templates can't check to find out what showThing was set to in the project that was saved in version 12. The evidence is already gone. And I certainly don't want to retain SkinModel.java entries for every obsolete variable in the skin.

Finally, by the time the skin templates are executed, the fact that the album was last created with version 12 may also be invisible, so the templates have no way of determining that any fixes need to be done.

There really is a reason why I do these things upon skin loading in SomeSkin.jar. Remember, this isn't something new - I've been using this kind of routine for almost a decade. It was always problematic with the command line, but few users were using that. But the multi-maker is a different story.
davidekholm

Posts: 4,094
Registered: 18-Oct-2002
Re: Needed: a more reliable variable correction mechanism
Posted: 7 Jun 22, 14:00   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
The introduction of the MultiMaker (which has no skin UI) surely makes this problem more urgent to address. jAlbum HAS a mechanism to allow the skin to adjust (import) old variables, but it's only working when the skin is loaded. If the skin UI implements the "ManagesImport" interface, then its "importVariables" method will be called on skin loading, but before the project's variables are fed into the skin's UI. Here's how the interface looks:
public interface ManagesImport {
    void importVariables(Map<String, Object> skinVariables);
}
The skin simply declares this method and does whatever needs to be done, for instance:
class MyUI extends ControlPanel implements ManagesImport {
   void importVariables(Map<String, Object> skinVariables) {
      if ("true".equals(skinVariables.get("showThing"))) {
         skinVariables.put("someThing", "thing");
      }
   }
}
I guess we simply need a way for a skin to get a similar callback called whenever a skin is loaded. A skin property could for instance point out a class that implements ManagesImport and then instantiate an object of it and call the callback.
JeffTucker

Posts: 8,288
Registered: 31-Jan-2006
Re: Needed: a more reliable variable correction mechanism
Posted: 7 Jun 22, 14:26   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
My skins are all using the same basic scheme, within the UI (in this case, for a simple variable name change):
public void importVariables(Map<String, Object> vars) {
	try {
 
		(... some stuff to get savedVersion)
 
		if (savedVersion < 14) {
			System.out.println("Project file prior to Atom 14");
			vars.put("txtIndexPage", vars.get("txtThumbnailPage"));
		}
	} catch (Exception e) {
	}
}
Works like a champ.

I don't have any sense of how big a problem this is. If a user doesn't use the command line or multi-maker, of course, he'll just never run into it. I'm acutely aware of it because I have command-line scripts to rebuild my demo albums, and I know that there are times when I can't use them, because of the variable fixes that are needed. Not a big deal, of course - open, CTRL-S, F9, go to the next one. Takes less than a minute.

Even if he does use the multi-maker, some "fixes" are very limited, and might not affect his projects at all. For example, in the next releases of my skin, I've done some wholesale changes to the CSS id's and classes. In that case, the skin will attempt to correct any custom CSS the user has included (find all occurrences of "ne-" and replace them with "ja-", for instance). But if the user isn't doing any custom CSS, this won't matter.

Finally, things can always be fixed after the fact, since the command line and multi-maker aren't saving the project. So, if the project gets built incorrectly, the user can just open it in the GUI, and make it again. Since the saved skin version number didn't get saved, the fixes will be done correctly.

It's only a problem if a user uses the command line or multi-maker, and doesn't take a look at the results!
JeffTucker

Posts: 8,288
Registered: 31-Jan-2006
Re: Needed: a more reliable variable correction mechanism
Posted: 7 Jun 22, 14:43   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Other skin developers, less obsessive than I am, don't run into this. They just do things like changing variables, and let the chips fall where they may. Wait for the bug report, and then say, "Oh, the new version uses a different variable for that, so now you're getting the default value. You'll have to make the change in each of your projects."

AFAIK, no skin developer has ever been violently assaulted for doing this, though that might be why some of them have disappeared.
Legend
Forum admins
Helpful Answer
Correct Answer

Point your RSS reader here for a feed of the latest messages in all forums