Posts:
3,945
Registered:
4-Aug-2006
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
14 Aug 17, 23:45
in response to: davidekholm
|
|
|
Most developers will probably appreciate the straight forward syntax.
Does any of this need a health warning should a hack try to write to objects (is it all threadsafe/sychronised - will it work)?
I have added a section to the Sample scripts page which includes a link back here, probably easier than trawling through the forum in a few months time. |
|
|
Posts:
3,573
Registered:
18-Oct-2002
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
15 Aug 17, 11:53
in response to: RobM
|
|
|
Most developers will probably appreciate the straight forward syntax.
Does any of this need a health warning should a hack try to write to objects (is it all threadsafe/sychronised - will it work)?
There is no thread safety but as long as each thread manipulate the data of its "own" AlbumObject, then there is no interference. If you interact with shared data, ensure you synchronize some how (by using the synchronized keyword or use atomic objects (see AtomicInteger and such)
I have added a section to the Sample scripts page which includes a link back here, probably easier than trawling through the forum in a few months time.
Thanks |
|
|
Posts:
3,573
Registered:
18-Oct-2002
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
26 Sep 19, 12:19
in response to: davidekholm
|
|
|
I almost forgot about this "new" getDescendants() API, but it turned out very valuable when implementing jAlbum's new search functionality. Now with Groovy as one of the available scripting languages, we can use the same syntax for stream processing in both Groovy and Java. Here's a Groovy example that prints the original dates of all images in a multi threaded way:
rootFolder.getDescendants().parallelStream()
.filter(ao -> ao.getCategory() == Category.image )
.forEach(ao -> println(ao.getVars().get("originalDate")));
This example is also valid Java if you simply swap println to System.out.println
Now, what's cool with the getDescendants() API and with the Java Stream API is that it's lazy, meaning that it doesn't process the whole tree unless told to do so. Here's an example that examines an album project for the presence of any videos. It stops as soon as it has found one video:
hasVideo = rootFolder.getDescendants().parallelStream()
.anyMatch(ao -> ao.getCategory() == Category.video );
Just open jAlbum's system console and copy and paste these code snippets to see them in live action. The upcoming jAlbum version will also print the time it took to execute an expression for your convenience. |
|
|
Posts:
8,381
Registered:
31-Jan-2006
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
26 Sep 19, 12:53
in response to: davidekholm
|
|
|
Now, what's cool with the getDescendants() API and with the Java Stream API is that it's lazy, meaning that it doesn't process the whole tree unless told to do so.
I'll have to do a little code-hunting. I'm often doing something like that in an init.bsh, and typically I'm using either a recursive getChildren() or a countCategories().
In the case of getChildren(), I'm also bailing out of the loop once I hit one occurrence of the thing I'm looking for, so I'm not sure getDescendants() is any more efficient.
In the case of countCategories(), assuming that I don't need the resulting counts for some other purpose, I guess getDescendants() would be more efficient. But in a project with fewer than 10,000 objects, would the difference even be measurable? |
|
|
Posts:
3,573
Registered:
18-Oct-2002
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
26 Sep 19, 14:49
in response to: JeffTucker
|
|
|
|
It matters most if you're grabbing metadata like comments, camera dates, titles and keywords as getDescendants().parallelStream() will iterate the tree using multiple threads. If you have a pretty slow IO device (like a network drive), the difference also becomes more noticeable
|
|
|
Posts:
8,381
Registered:
31-Jan-2006
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
26 Sep 19, 15:13
in response to: davidekholm
|
|
|
It matters most if you're grabbing metadata like comments, camera dates, titles and keywords....
That's something I'm doing in only one place, in one skin. I'll have to mull it over, as in that one context, I don't think I can get away with any multi-threading. That's also a place where I should probably be using the JSON files, instead. But that's all a bit of a mystery to me. And are the JSON files generated before template processing happens? I need the data during album creation, not during album viewing.
I might change some other, simpler cases, just to make the code a little tighter and more readable. |
|
|
Posts:
8,381
Registered:
31-Jan-2006
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
26 Sep 19, 15:29
in response to: davidekholm
|
|
|
Here's an example that examines an album project for the presence of any videos. It stops as soon as it has found one video:
hasVideo = rootFolder.getDescendants().parallelStream()
.anyMatch(ao -> ao.getCategory() == Category.video );
Um, that blows up if used in init.bsh. The error message indicates that BeanShell doesn't understand the > character - it's a parse error.
ETA: Couldn't remember what they're called - lambda expressions. Not supported in BeanShell yet, though it appears that BeanShell isn't really abandonware yet. |
|
|
Posts:
3,573
Registered:
18-Oct-2002
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
26 Sep 19, 19:42
in response to: JeffTucker
|
|
|
Here's an example that examines an album project for the presence of any videos. It stops as soon as it has found one video:
hasVideo = rootFolder.getDescendants().parallelStream()
.anyMatch(ao -> ao.getCategory() == Category.video );
Um, that blows up if used in init.bsh. The error message indicates that BeanShell doesn't understand the > character - it's a parse error.
ETA: Couldn't remember what they're called - lambda expressions. Not supported in BeanShell yet, though it appears that BeanShell isn't really abandonware yet.
Yes, BeanShell doesn't support that but Groovy does. Rename init.bsh to init.grooy |
|
|
Posts:
3,573
Registered:
18-Oct-2002
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
26 Sep 19, 19:43
in response to: JeffTucker
|
|
|
It matters most if you're grabbing metadata like comments, camera dates, titles and keywords....
That's something I'm doing in only one place, in one skin. I'll have to mull it over, as in that one context, I don't think I can get away with any multi-threading. That's also a place where I should probably be using the JSON files, instead. But that's all a bit of a mystery to me. And are the JSON files generated before template processing happens? I need the data during album creation, not during album viewing.
I might change some other, simpler cases, just to make the code a little tighter and more readable.
The JSON files can be generated in init by the use of the JSONMaker API. |
|
|
Posts:
8,381
Registered:
31-Jan-2006
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
26 Sep 19, 20:02
in response to: davidekholm
|
|
|
Yes, BeanShell doesn't support that but Groovy does. Rename init.bsh to init.grooy
That just triggers a whole cascade of other problems. My init.bsh is doing a lot of things, including defining methods that are used elsewhere.
Not worth the tsuris, I'm afraid. |
|
|
Posts:
3,573
Registered:
18-Oct-2002
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
26 Sep 19, 21:14
in response to: JeffTucker
|
|
|
Yes, BeanShell doesn't support that but Groovy does. Rename init.bsh to init.grooy
That just triggers a whole cascade of other problems. My init.bsh is doing a lot of things, including defining methods that are used elsewhere.
Not worth the tsuris, I'm afraid.
Ah, so far, the only thing materially that differs is that one cannot add a data type in front of variable declarations. If one does so, those variables become temporary variables. |
|
|
Posts:
8,381
Registered:
31-Jan-2006
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
26 Sep 19, 21:20
in response to: davidekholm
|
|
|
|
|
In my first attempt, Groovy choked on a replaceAll(). I am not making this up. Error dump attached.
Here are the lines: private String cleanString(String s) {
if(s == null || s.trim().equals("")) return null;
s = engine.processTemplate(s).replaceAll(" +", " ").replaceAll("\r\n|\r|\n","<br>").replaceAll("<br>$", "").trim();
if(s.equals("")) return null;
return s;
}
|
|
|
Posts:
3,573
Registered:
18-Oct-2002
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
26 Sep 19, 21:39
in response to: JeffTucker
|
|
|
I see. It turns out that Groovy has some "clever" means of interpreting special characters within strings. $ being one such character. The idea is to allow for easy mixing of variables and text. I guess you can replace $ by \$ to have it working or use Groovy's special ''' (triple single quotes) around that string. Then it behaves exactly like an ordinary Java string.
https://groovy-lang.org/syntax.html |
|
|
Posts:
8,381
Registered:
31-Jan-2006
|
|
|
|
Re: Keyword Labels Maxing at 30
Posted:
26 Sep 19, 21:46
in response to: davidekholm
|
|
|
Pretty nasty, since that's standard regex. Any language that requires that kind of goofy syntax gets an immediate thumbs-down.
I think I'll put all of this off until I get back from the beach - leaving Saturday for a month.
Of course, what I'd really like to do is ditch all of the interpreted stuff, and just compile things like what's in init.bsh. The catch is that I don't have a clue about how to do that. In short, I don't know how to tell NetBeans and the compiler where these "skin" variables are coming from, nor do I know how to pass newly-computed stuff to subsequent template processing.
Remember, I'm still "procedural."  |
|
|
|
Legend
|
|
Forum admins
|
|
Helpful Answer
|
|
Correct Answer
|
|
