This question is answered.


Permlink Replies: 250 - Pages: 17 [ Previous | 1 2 3 4 5 6 | Next ] - Last Post: 20 Jul 21, 17:45 Last Post By: davidekholm Threads: [ Previous | Next ]
ctwist

Posts: 651
Registered: 27-Sep-2003
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 17:01   in response to: xexyl in response to: xexyl
Correct
  Click to reply to this thread Reply
xexyl wrote:
Now this is interesting: init.bsh is compiled. How did you do this exactly?
When I said init.bsh is compiled, I meant that the contents of init.bsh are compiled. Just move the code into a Java class and init.bsh just becomes a skeleton script.

Similarly, I moved all the Java code from the htt files into Java classes.

One of my objectives was to limit the use of BeanShell as much as possible; I trust compiled Java more than interpreted BeanShell, and bugs in compiled Java are revealed at compile time instead of when executed.
One thing that has changed is tighter scripting rules for variables. Details are in http://jalbum.net/forum/thread.jspa?threadID=55131.

Okay now at first I was thinking this might be key but now I don't know: the thing is that the same template lines fail in the new build but do not in the old build. I already included an example place but here's it again - maybe you have an idea?

font-size: <%= fontsize + 3 %>px;
The tighter scripting rules were introduced in jAlbum 17.1. Try compiling your skin in jAlbum 17 and 17.1 If it works in jAlbum 17 but not 17.1, there is almost certainly a problem with one of your variable references. If your skin also fails in jAlbum 17, maybe your problems are not related to how you refer to variables.
Your Java source code is not published. The sample code that you provided looks good, but we would have to see how this fits into the rest of your Java code.

Edited by: ctwist on 16-Jun-2020 11:02
Change "declarations" to "references"
ctwist

Posts: 651
Registered: 27-Sep-2003
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 16 Jun 20, 17:54   in response to: xexyl in response to: xexyl
Helpful
  Click to reply to this thread Reply
Reflections contains headless-settings.jap. This should be deleted. SkinModel.java is preferred for setting default values.
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 17 Jun 20, 20:07   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
Going backwards on posts:

ctwist wrote:
Reflections contains headless-settings.jap. This should be deleted. SkinModel.java is preferred for setting default values.

I believe that this was created automatically? I do have both SkinModel and SlideModel too though. However I will delete headless-settings.jap in my working (or is that working not-working) copy.

The other post is more interesting to me though which I'll get to next. Thanks.
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 17 Jun 20, 20:18   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
ctwist wrote:
xexyl wrote:
Now this is interesting: init.bsh is compiled. How did you do this exactly?
When I said init.bsh is compiled, I meant that the contents of init.bsh are compiled. Just move the code into a Java class and init.bsh just becomes a skeleton script.

Similarly, I moved all the Java code from the htt files into Java classes.

One of my objectives was to limit the use of BeanShell as much as possible; I trust compiled Java more than interpreted BeanShell, and bugs in compiled Java are revealed at compile time instead of when executed.


Totally understandable. I just took a look at Mirage and I see what you mean. Also I saw something else that I had noticed in Reflections that I had forgotten about:

<%!


Instead of just:

<%


I'm going to look into that but also moving the BeanShell code to Java classes. Thanks for the hints here.

One thing that has changed is tighter scripting rules for variables. Details are in http://jalbum.net/forum/thread.jspa?threadID=55131.

Okay now at first I was thinking this might be key but now I don't know: the thing is that the same template lines fail in the new build but do not in the old build. I already included an example place but here's it again - maybe you have an idea?

font-size: <%= fontsize + 3 %>px;
The tighter scripting rules were introduced in jAlbum 17.1. Try compiling your skin in jAlbum 17 and 17.1 If it works in jAlbum 17 but not 17.1, there is almost certainly a problem with one of your variable references. If your skin also fails in jAlbum 17, maybe your problems are not related to how you refer to variables.

Right. That's the curious thing: the old build works in the most recent version of jAlbum. However the same scriptlets do not if I repackage the skin. Again this is all in BeanShell which is why I was intrigued at having it compiled instead. Your skin Mirage might have enough information but I'll have to look at it more to get some ideas.

Your Java source code is not published. The sample code that you provided looks good, but we would have to see how this fits into the rest of your Java code.

Understandable. It's a mess right now but I can easily checkout the code as it was. I will in fact be doing this after tarring up the current changes (even though it's on nightly backup) and look into getting past BeanShell.

Thank you for the helpful ideas! I'll let you know. I am mostly perplexed on why the same thing works in the old skin that does not in the new (version). I've also wondered about takin the Minimal skin and adding my filters and options to it as really it isn't even necessarily for publication; I don't know if the JavaScript Exposure is still being developed and it's the filters I wrote that I'm mostly interested in getting working again (saves me the effort from doing it elsewhere - or so I thought. I will find out if that's the case in due course).
RobM

Posts: 3,889
Registered: 4-Aug-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 17 Jun 20, 20:52   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
{quote:title=xexyl wrote:}{quote
I believe that this was created automatically? I do have both SkinModel and SlideModel too though. However I will delete headless-settings.jap in my working (or is that working not-working) copy.
headless-settings.jap is created with Menu>Tools>Skin Developer>Prepare for online and console use...
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 17 Jun 20, 23:31   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
RobM wrote:
{quote:title=xexyl wrote:}{quote
I believe that this was created automatically? I do have both SkinModel and SlideModel too though. However I will delete headless-settings.jap in my working (or is that working not-working) copy.
headless-settings.jap is created with Menu>Tools>Skin Developer>Prepare for online and console use...

Right. I saw that but I never used that tool to my memory. Nor do I recall using console use. Then again it might very well be that I had.

It doesn't matter now since I have solved the problem (see next comment).
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 17 Jun 20, 23:40   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
Resolved.

The problem is simple. I don't know if it's something that changed with BeanShell or jAlbum or maybe even it was in my WIP that I never published that I changed it. I don't know but my attempt at modularity either never worked or no longer works: I used packages. I was about to shower and it just popped into my head that it might be related. A quick:

sed -i '/package xexyl/d' *.java


And recompiling did the trick. That's quicker than even opening an application and loading the files just as command line for regexps is quicker than opening an application as are so many other tasks. That's what I was getting at. Whereas some people are faster with the mouse I am faster with the keyboard and the utilities are already there, faster etc. But never mind that. What works for one person doesn't work for everyone. That's all I was getting at earlier.

Anyway no need to make the BeanShell scripts into Java classes now which is better for me.

Maybe I will update it here but if I do I'll probably make some additional enhancements. Not for today though. Far too knackered for that.

Thank you to everyone for trying to help. Rob you and Chris were particularly helpful so thank you. I'll mark it answered here even though I sorted it out myself.

Cheers.

Edited by: xexyl on 17-Jun-2020 14:40

RobM

Posts: 3,889
Registered: 4-Aug-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 18 Jun 20, 00:43   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
Sometimes you just need someone to talk to, to suddenly get the answer to a puzzling problem. :)
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 18 Jun 20, 15:39   in response to: RobM in response to: RobM
 
  Click to reply to this thread Reply
True.

I think a few things made me think of it. One of those things is that I saw that in Mirage there was no package. I had wondered about it beforehand but I wasn't sure. Then it just occurred to me - why is it that the variables are found in the Java classes but not BeanShell? I did use import but maybe something changed that made it not work. So then what about the old compiled class files? Well that's one of the things that made me think on it - they were already compiled and even though I'm pretty sure I had them in packages something might have changed that made a recompilation break.

I still have a couple problems though but I have some ideas on where to go to sort it out: (1) the variables seem to maintain their default values even after updating them in the UI - in init.bsh etc. at least; and (2) when selecting the styles in the jAlbum UI the colours aren't being updated in the Reflections settings (the style variable however IS updated according to a println statement in init.bsh).

I'm going to do a test that has a variable in the main class itself and see if that is updated; if it is then I'll move those other variables over. I did in fact change the main class in this rework though that was just the name (Engine -> Reflections).

I've done some renaming of other things too like changing American spelling of colour to proper British spelling. The trouble is Java and also CSS (if it specifies colour etc. - I think there are keywords that include it) expects American spelling so why bother mixing it is the old thinking. But why bother is it annoys me. So I've done that too.

Thank you again for the dialogue. Much appreciated! When I resolve that I might make the filter settings more customisable. If I do do that I might update the skin itself though I don't think I'll work with the jQuery plugin as I really despise JavaScript (and to be fair just as much I hate CSS)!

Does jAlbum have a way to submit only image filters and/or plugins instead? That might be something to consider too if the skin seems to be problematic for some reason or another.

Anyway thanks, stay safe and cheers.

Edited by: xexyl on 18-Jun-2020 06:41
ctwist

Posts: 651
Registered: 27-Sep-2003
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 18 Jun 20, 16:13   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
xexyl wrote:
why is it that the variables are found in the Java classes but not BeanShell?
Mirage's MgAlbum class gets the skin variables. If they are needed by script files, these are public, so they can be referenced as MgAlbum.varname. BeanShell files don't automatically have access to skin variables; you need to get them. You can get them in the BeanShell file; I just think it is cleaner to get them in the Java classes.
the variables seem to maintain their default values even after updating them in the UI
Mirage gets album object variables in Index.java, which refreshes the variables for each album object. If they are needed by script files, these are public, so they can be referenced as index.varname.
in init.bsh etc. at least; and (2) when selecting the styles in the jAlbum UI the colours aren't being updated in the Reflections settings (the style variable however IS updated according to a println statement in init.bsh).
Style is a jAlbum variable. This is updated automatically.
I've done some renaming of other things too like changing American spelling of colour to proper British spelling.
The Americans have hijacked the spelling of programming keywords. There is nothing that can be done about this; the battle has been lost.

Edited by: ctwist on 18-Jun-2020 10:15
updateVars causes the variables to be refreshed for the current album object. You can run this in BeanShell.

Edited by: ctwist on 18-Jun-2020 10:24
Strike out erroneous text.
JeffTucker

Posts: 8,109
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 18 Jun 20, 16:19   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
ctwist wrote:
BeanShell files don't automatically have access to skin variables; you need to get them.

I don't believe this is a correct statement. I've never had to "get" skin variables in, for example, init.bsh. You can just refer to them.

ETA: This, BTW, is one of big arguments against trying to compile things like init.bsh and index.htt. Instead of being able to just use things like skin variables, you suddenly have to wade into all manner of variable declarations and "get" statements. It ends up being ten times as much code, to arrive at the same result.

The other reason for not compiling the templates is because that makes it virtually impossible for an ordinary user to alter things. Yeah, we discourage users from editing template files, but there are times when a user wants to do something unusual, and it can be done easily with 60 seconds of work in a text editor.

Compiling the UI is a different animal. It's about the same coding effort as creating an interpreted onload.bsh, but you end up with something that loads much faster, and the built-in error checking of NetBeans or Eclipse saves you from the dreaded "onload.bsh fails and I don't know why" hell.
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 18 Jun 20, 16:20   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
ctwist wrote:
xexyl wrote:
why is it that the variables are found in the Java classes but not BeanShell?
Mirage's MgAlbum class gets the skin variables. If they are needed by script files, these are public, so they can be referenced as MgAlbum.varname. BeanShell files don't automatically have access to skin variables; you need to get them. You can get them in the BeanShell file; I just think it is cleaner to get them in the Java classes.

Ah, interesting. But actually you misunderstood in this case, maybe. I was thinking why is it that my old compiled files init.bsh could find the variables but the new ones, compiled (the same variables) were not found in init.bsh. However this might be of use if I'm unable to get easily the variables modified by the user to be updated in the init.bsh script so thanks!

the variables seem to maintain their default values even after updating them in the UI
Mirage gets album object variables in Index.java, which refreshes the variables for each album object. If they are needed by script files, these are public, so they can be referenced as index.varname.

Makes sense. That also gives me a thought on my issue though maybe it's not relevant; I'll have to check.

in init.bsh etc. at least; and (2) when selecting the styles in the jAlbum UI the colours aren't being updated in the Reflections settings (the style variable however IS updated according to a println statement in init.bsh).
Style is a jAlbum variable. This is updated automatically.

Yup. It's just that in the skin UI itself the colour variables are e.g. for background, text etc. aren't updated after style has been updated - even though I have the .jap files. This was also something that worked before but does not seem to now and I am not sure why. I guess something to do with where variables are but I'm not sure yet.

Any idea behind that?

I've done some renaming of other things too like changing American spelling of colour to proper British spelling.
The Americans have hijacked the spelling of programming keywords. There is nothing that can be done about this; the battle has been lost.

Hahaha yes well that's what they think :) No, seriously. You're right in that way. As they have a lot of other things. :( It's unfortunate but it is what it is and I still can at least spell the other way where I can. Know what I mean?
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 18 Jun 20, 16:21   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
jGromit wrote:
ctwist wrote:
BeanShell files don't automatically have access to skin variables; you need to get them.

I don't believe this is a correct statement. I've never had to "get" skin variables in, for example, init.bsh. You can just refer to them.


That was my experience too. And in fact even now it seems to be the case as long as there's no package (but having a package used to work). I'm not sure why the variables however are not being updated after the user has modified them though. Might be something I will consider though first as it'd be easier that way than to move everything over.
JeffTucker

Posts: 8,109
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 18 Jun 20, 16:25   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
xexyl wrote:
I'm not sure why the variables however are not being updated after the user has modified them though.

We can't see what you're doing.

This is sort of jAlbum 101. The user makes a selection in the skin's UI, like checking a JCheckBox or choosing a value from a JComboBox. The variable, when referenced in the template files, coughs up the value selected by the user. There's nothing "special" that has to be done - it just works.
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 18 Jun 20, 16:29   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
jGromit wrote:

We can't see what you're doing.

This is sort of jAlbum 101. The user makes a selection in the skin's UI, like checking a JCheckBox or choosing a value from a JComboBox. The variable, when referenced in the template files, coughs up the value selected by the user. There's nothing "special" that has to be done - it just works.


Right. And it did work. But in the recompiled build (even the things that didn't change) it doesn't, for some reason or another. So what I have now is:

The variables can be referenced in the templates and BeanShell files. However the changes the user makes is not updated. So for example if the user disables an option if I were to do:

System.out.println(setting);


The variable remains the default. Also after updating the style the hints from the .jap file under styles/ subdirectory are not made use of.

Does that make more sense then? I'm sometimes not sure if I explain things right. I have an odd way of thinking and I'm also dead tired half the time.
Legend
Forum admins
Helpful Answer
Correct Answer

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