This question is answered.


Permlink Replies: 250 - Pages: 17 [ Previous | 1 ... 5 6 7 8 9 10 11 | Next ] - Last Post: 20 Jul 21, 17:45 Last Post By: davidekholm Threads: [ Previous | Next ]
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 26 Jun 20, 19:19   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
jGromit wrote:
xexyl wrote:
Thanks to you all (but more than the others jGromit)!

You're welcome! Post back if you get stumped. And you will :)


Well yesterday I fixed the problem in the filter. But you're right. I am not sure about something. In this case about the SimpleDateFormat and in particular wrt printing file last modification date.

This is what I have of old in index.htt (whether there's a better way or not is another matter entirely I suppose):

  long checkLastMod(File named) {
      File infile = new File(named + "/albumfiles.txt");
                     
      if (!infile.exists()) {
         return new Date().getTime(); 
      } else {       
         return infile.lastModified();
      }              
   }


Then it's used like:

long fileDate = checkLastMod(ao.getFile());
Calendar cal = Calendar.getInstance();
cal.setTime(new Date(fileDate));
out.println((cal.get(Calendar.DAY_OF_MONTH)+1)+"/"+cal.get(Calendar.MONTH)+"/"+(cal.get(Calendar.YEAR)));


So far okay. But I see that the Date class has been deprecated. At the same time though I see that SimpleDateFormat relies on Date and not LocalDate so I thought okay maybe I'll just keep it that way. But it's the format also that I wonder about.

Whereas I tend to use one of the following formats:

YYYY-DD-MM
DD/MM/YYYY

(Amongst some others.)

Some prefer others and often it's a regional thing. But I see in jAlbum advanced settings (for the project) there's a date format the user can specify.

Question what variables are involved? Or is there a preferred way to deal with this? I looked at the variables help page but I didn't see anything that might be relevant to locale/date format.

Any help would be appreciated.

Thank you.
JeffTucker

Posts: 8,149
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 26 Jun 20, 20:18   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
First, you should never be directly examining either the contents or the timestamp of a file like albumfiles.txt. For I/O efficiency, the core often doesn't write out such files while the user is actively modifying things - that file, for example, may not get written out until after the user has generated the album, and is closing the project. So, the timestamp on the file is useless.

Second, this is one of those cases in which modifying 10-year-old code is probably the wrong approach. Instead, take a look at a current skin and see how that skin is doing the same thing.

I believe what you're trying to do here is figure out if there are any new objects in this project, or in a particular folder. If so, there are now quicker ways of doing this. So, depending on what level you're at, and the current scope (i.e., are you within an iterator or not), just do:
newest = JAlbumUtilities.getDeepLastAdded(rootFolder); // for the whole project
 
or
 
newest = JAlbumUtilities.getDeepLastAdded(currentFolder); // if you're processing a folder
 
or
 
newest = JAlbumUtilities.getDeepLastAdded(currentObject); // if you're checking a folder while processing its parent folder
 
or
 
dateofthisobject = currentObject.getWhenAdded();
That will give you the date on which something was most recently added to the project or folder, or, in the last case, when this particular object was added to the project.

Then, a number of older skins tried to do their own date formatting because, if memory serves, the jAlbum core had no setting for it. Later, that resulted in a massive amount of confusion. A user would set a date format in the jAlbum settings, but because the skin had its own settings, dates in the album would be an unholy mix of the two formats. Simplest is to let the jAlbum core setting control what you're displaying:
displayedNewestDate = new FormattedDate(newest, engine.getDateFormatAsObject()).toString();
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 26 Jun 20, 22:07   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
First of all when I made it more 'my way' (date wise - the original design of the outputted album was mostly Carl's and I remember emailing back and forth with him including about the dates) I forgot to move the + 1 for the month and so the day has + 1 in the code above but this has been fixed. Just to make that clear.

Anyway I was trying to work out my reply here but I think it's better to go (as you correctly point out - which is why I was asking) to the not trying to rework the old code. For this reply I'll just say what functionality I need so that you can then point me to the right functions/methods. After that I can then ask if there's something specific I'm missing.

The old file has several hacks and I rather suspect that a lot of what I did is no longer necessary as the engine probably has it now. I also see some potential problems in at least one of those hacks.

Anyway this is what I need:

  • Count the images in each directory.
  • Count the number of subdirectories.
  • Get the date of the last added image (it was technically modified but thinking on it last added works just as well and maybe even better). Now this you included but the way I did it before was checking for the slides directory itself. But this was also a hack - and probably much of the file was - and I guess there's a better way to do this now more than ever. What might that be?

I'm a bit foggy in the head atm so I might not have got everything across but those are some of the things I need anyway - maybe I've missed some but I'm not sure for now if so. These are in the core now, I gather?

I have another query too:

Is it possible to in jAlbum exclude images from filters? I can imagine how this would be good for some of the images some of the times but is there anything that needs to be done on my end for this?

Thank you very much!
JeffTucker

Posts: 8,149
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 26 Jun 20, 22:33   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
xexyl wrote:
Anyway this is what I need:

  • Count the images in each directory.
  • Count the number of subdirectories.

See https://jalbum.net/api/se/datadosen/jalbum/JAlbumUtilities.html#countCategories(se.datadosen.jalbum.AlbumObject)

- Get the date of the last added image (it was technically modified but thinking on it last added works just as well and maybe even better). Now this you included but the way I did it before was checking for the slides directory itself. But this was also a hack - and probably much of the file was - and I guess there's a better way to do this now more than ever. What might that be?

I just posted the entire code that you need to do this, above. It really is just a couple of lines, and it's blazing fast.

Do not try to count things in the output. Because of multi-threading, that's a recipe for disaster - you might be building an index page while the core is in the middle of processing the images, meaning that the count of output slides would change each time you made the album, even with the same images.

Is it possible to in jAlbum exclude images from filters? I can imagine how this would be good for some of the images some of the times but is there anything that needs to be done on my end for this?

I've been down that road, and it's a lot of thrashing about. A filter that's applied to the engine applies to every object you feed to it. To alter that, you'd have to create an object-specific variable that a user could attach to a given object (like with a check box in a custom UI panel in edit mode), then write your filter to look for that variable and either apply or not apply the filter. Be very sure you want to do that before heading down that road.
RobM

Posts: 4,174
Registered: 4-Aug-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 26 Jun 20, 22:51   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
Also in the wiki for actual code examples.
davidekholm

Posts: 4,059
Registered: 18-Oct-2002
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 27 Jun 20, 00:34   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
xexyl wrote:

Is it possible to in jAlbum exclude images from filters? I can imagine how this would be good for some of the images some of the times but is there anything that needs to be done on my end for this?

I had to check the code for this, but there IS a way for users to exclude individual images from certain filters. A user can add an image specific user variable under the Edit view called "excludedFilters" and set the name of the filter (or filters, comma separated) as the value. Geeky, yes! :-)

For jAlbum's "Effects" (See settings->Effects, the user can right click any image and deselect that effect individually from the Effects menu. (Effects are technically very similar to filters. They basically also have a decent UI)
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 27 Jun 20, 00:56   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
jGromit wrote:
xexyl wrote:
Anyway this is what I need:

  • Count the images in each directory.
  • Count the number of subdirectories.

See https://jalbum.net/api/se/datadosen/jalbum/JAlbumUtilities.html#countCategories(se.datadosen.jalbum.AlbumObject)


Yep I saw that but I must have missed some of those features. Thanks.

- Get the date of the last added image (it was technically modified but thinking on it last added works just as well and maybe even better). Now this you included but the way I did it before was checking for the slides directory itself. But this was also a hack - and probably much of the file was - and I guess there's a better way to do this now more than ever. What might that be?

I just posted the entire code that you need to do this, above. It really is just a couple of lines, and it's blazing fast.


Yes - it's just I couldn't remember exactly how the list went (as in what is included). I'll play with it though when I get a chance.

Do not try to count things in the output. Because of multi-threading, that's a recipe for disaster - you might be building an index page while the core is in the middle of processing the images, meaning that the count of output slides would change each time you made the album, even with the same images.

Right - you already hinted at that with the other issue. As I did say they were hacks and hacks tend to be ugly.

Is it possible to in jAlbum exclude images from filters? I can imagine how this would be good for some of the images some of the times but is there anything that needs to be done on my end for this?

I've been down that road, and it's a lot of thrashing about. A filter that's applied to the engine applies to every object you feed to it. To alter that, you'd have to create an object-specific variable that a user could attach to a given object (like with a check box in a custom UI panel in edit mode), then write your filter to look for that variable and either apply or not apply the filter. Be very sure you want to do that before heading down that road.


I figured it would be something like this. Thanks. And whether or not I want to do it I don't know; it's just that I can imagine that it might be nice at times. What those times are I cannot say though. I was thinking in terms of how you can exclude specific images from the album so maybe it was possible to do that with filters instead.
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 27 Jun 20, 00:59   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:
xexyl wrote:

Is it possible to in jAlbum exclude images from filters? I can imagine how this would be good for some of the images some of the times but is there anything that needs to be done on my end for this?

I had to check the code for this, but there IS a way for users to exclude individual images from certain filters. A user can add an image specific user variable under the Edit view called "excludedFilters" and set the name of the filter (or filters, comma separated) as the value. Geeky, yes! :-)


Ha, I'm familiar with that - checking large code bases to find out if something is possible. That's why I never comment (or is it that's why I should be commenting more often? :)) Excellent, thanks! I imagined that it might work like this if it was possible.


For jAlbum's "Effects" (See settings->Effects, the user can right click any image and deselect that effect individually from the Effects menu. (Effects are technically very similar to filters. They basically also have a decent UI)

Will do, thanks.
JeffTucker

Posts: 8,149
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 27 Jun 20, 02:13   in response to: davidekholm in response to: davidekholm
 
  Click to reply to this thread Reply
davidekholm wrote:
I had to check the code for this, but there IS a way for users to exclude individual images from certain filters. A user can add an image specific user variable under the Edit view called "excludedFilters" and set the name of the filter (or filters, comma separated) as the value. Geeky, yes! :-)

Oh, now you tell me. Where were you ten years ago, when I needed you?
davidekholm

Posts: 4,059
Registered: 18-Oct-2002
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 27 Jun 20, 10:16   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
;-)
xexyl

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

Oh, now you tell me. Where were you ten years ago, when I needed you?


I wasn't here to ask for it. Or I was and didn't think to ask it for you anyway. Who would have thought that me returning would be good? I would say you can bow to me but since you helped me heaps and stacks maybe I ought to be bowing to you. Perhaps we should all be bowing to each other - we can look like a bunch of merry fools leaning over together!

Jest aside this probably really ought to be documented at the very least. And maybe it's an idea to have it specifically in the UI - you know, where when you click on an image you can say I want to exclude this image from this or that filter or filters.
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 27 Jun 20, 23:17   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
As for the index/slide.htt I just cleaned those up. The index.htt is the one that really needed a clean-up and it's done. I say 'done' but I mean the clean-up I did is done. There probably could be additional things done. I made it HTML5 (I think) and responsive (I think!) and I did the same for slide.htt.

I was able to get rid of a lot of old functions, some loops and probably some other things too.

Thanks again so much. This goes in particular to jGromit but the rest of you too.

Looking at the code examples Rob linked to (thanks - I had seen it but it seems more useful now) there are additional things I can do but those will have to be another time.

Chris you pointed out the widget css. Good point. I probably ought to do that but for now I need a break and probably for a few days at the least. I could realistically submit the update here but I want to test things more (directories and subdirectories seems good though and that was one thing I wasn't sure about) before then. I also have something I want to do with one of the filters but this is all for another day.

I'll let you know if I have any other questions (I can see that being the case).

Cheers and thanks again.
ctwist

Posts: 710
Registered: 27-Sep-2003
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 28 Jun 20, 01:14   in response to: xexyl in response to: xexyl
 
  Click to reply to this thread Reply
xexyl wrote:
I made it HTML5 (I think)
Feed some album pages into Nu Html Checker. It will identify HTML5 violations.
JeffTucker

Posts: 8,149
Registered: 31-Jan-2006
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 28 Jun 20, 02:22   in response to: ctwist in response to: ctwist
 
  Click to reply to this thread Reply
I'm surprised at some of the things the validators (the W3 one you've linked to, and Total Validator, which I use) tolerate, but probably shouldn't.

Neither one complains about things like a self-closing break tag:
<br/>
This really should be banished.

And neither complains about the archaic charset (also self-closing):
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
 
Instead of:
 
<meta charset='UTF-8'>
It's a mixed bag when it comes to things that aren't wrong, but should be scrubbed, like the type attributes:
<style type="text/css">body {color: black;}</style>
<script type="text/javascript">var a="asdf";</script>
 
Instead of:
 
<style>body {color: black;}</style>
<script>var a="asdf";</script>
xexyl

Posts: 181
Registered: 1-Sep-2009
Re: What has changed the past 9 years that might break a skin rebuild?
Posted: 28 Jun 20, 17:04   in response to: JeffTucker in response to: JeffTucker
 
  Click to reply to this thread Reply
jGromit wrote:
I'm surprised at some of the things the validators (the W3 one you've linked to, and Total Validator, which I use) tolerate, but probably shouldn't.

Already gone. When I made the changes yesterday.


Neither one complains about things like a self-closing break tag:
<br/>
This really should be banished.

Same here.


And neither complains about the archaic charset (also self-closing):
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"/>
 
Instead of:
 
<meta charset='UTF-8'>

This was also changed.

It's a mixed bag when it comes to things that aren't wrong, but should be scrubbed, like the type attributes:
<style type="text/css">body {color: black;}</style>
<script type="text/javascript">var a="asdf";</script>
 
Instead of:
 
<style>body {color: black;}</style>
<script>var a="asdf";</script>

Now this is one I didn't know. Mixed bag in what way? Should the type attribute be removed then? Mind that I don't think I have the first but the second one I know I do.
Legend
Forum admins
Helpful Answer
Correct Answer

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