[jsword-devel] Feature found

[Joe Walker]

I was going to say - option 2, but on reflection a file can be modified 
before it's arrival on your computer, so you're right and option 3 is 
better.
Either solution would make me happy though.

I have a check-in to fix missing resources for the passage selection 
pane, and an experiment to make getAction() assert or default in the 
absence of said resources. Crosswire appears to be down, so I can't 
check-in or even CVS diff, but my recollection is that in 
common/swing/ActionFactory I changed createJLabel to:

/**
  * Construct a JLabel from the Action.
  * Only Action.NAME and Action.MNEMONIC_KEY are used.
  * @param acronymn the internal name of the CWAction
  * @return A label, asserting if missing resources or with default vals
  */
public JLabel createJLabel(String acronymn)
{
     Action action = getAction(acronymn);

     assert action != null : "Missing resource: "+acronymn;
     JLabel label = new JLabel();
     if (action != null)
     {
         label.setText(action.getValue(Action.NAME).toString());
         Integer mnemonic=(Integer)action.getValue(Action.MNEMONIC_KEY);
         if (mnemonic != null)
         {
             label.setDisplayedMnemonic(mnemonic.intValue());
         }
     }
     else
     {
         label.setText(acronymn);
     }

     return label;
}

(slightly edited to stop wordwrap)

Does that make sense?


Joe.


DM Smith wrote:
> I found a "feature" which I am working on fixing.
> 
> When the xsl is compiled for reuse, it works very well to check each 
> time it is used to see if there is a change and recompile it when it 
> does. The compilation is expensive so it is best for the user to compile 
> it. And recompiling it when it changes allows a developer to bring up 
> the application and test iterative changes to the xsl. It serves no 
> advantage to a non-developer.
> 
> The problem is when the xsl is in a jar the NetUtil.getLastModified 
> returns the current time and the net result is that the xsl is compiled 
> every time it is used.
> 
> I see three possible solutions:
> 1) return 0 when the resource is in a jar. This is the simplest 
> solution. The problem with this is that if there is any persistence of a 
> n artifact based upon that timestamp, then it will not see any changes.
> 2) return the timestamp of the jar. So if there is persistence and the 
> jar changes then it would force a recompile even if the xsl did not 
> change. The basic thought is that the changes to the jar are going to be 
> relatively infrequent and even recompiling the xsl once for each run of 
> the application is not that big a deal.
> 3) return the timestamp on the file in the jar. This is a complete 
> solution and matches the expectation of the method's contract.
> 
> The form of the url that I am trying to work with is:
> jar:file:/a/b/c/jarname.jar!/x/y/filename.ext
> 
> In this case I can pick off the file:.../jarname.jar and the 
> .../filename.ext and use JarFile to get the JarEntry to interrogate.
> 
> The problem is that the solution is still not completely generalized. 
> What if the jar's file is served up via ftp or http. I don't know what 
> that url would look like. Would it be something like:
> http:jar:file:.../jarname.jar!.../filename.ext.
> 
> I am inclined to do nothing for this situation.
> 
> On another note, I think Eclipse M9 is coming out later today. I have 
> been using an integration build for the last week and it is better than M8.
> _______________________________________________
> jsword-devel mailing list
> jsword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/jsword-devel