* Query re design of Improve Website or CD DVD HTML Plugin

[ColeValleyGirl]

Mike,

I just started looking at doing a modified version of your plug-in to support two other Lytebox equivalents, thinking it would be relatively simple. (I want consistency between the lightbox in FH and on the rest of my website, which I'm redeveloping, and Lytebox and your other alternatives aren't easy to integrate in my CMS).

One of the alternatives I intended to include is the most widely used free lightbox in the CMS environment I use (CMS is Drupal, lightbox is http://www.jacklmoore.com/colorbox/ -- it's also widely used in other CMS environments such as Wordpress.

The other is a commercial alternative which offers a free licence for non-commercial sites and includes a zoom feature as well as a pop-up feature: https://www.magictoolbox.com/magiczoomplus/ -- probably of less interest to most users, although the extra functionality is very nice.

However, I've hit a snag: the licence terms for MagicZoomPlus does not allow the code to be distributed, which precludes including the js in the body of the plugin (plus the js differs between the licensed and free versions).

It also occurs to me that adding further alternatives into the plugin and including the js/css for all of them will make it very rapidly unwieldy.

So I wondered why you'd taken the design decision to include the js and css inline in the plug-in (and the resultant html files) rather than (say) prompting for a directory that contains those js and css and copying the files into the website directory, and then just editing the references to the js and css in the html files? There is probably a very good reason which is escaping me (maybe wanting to keep the user interface simple and not introduce the complexity of js/css to people who don't need to understand them?)

Helen

[tatewise]

You have hit the nail on the head. I tried to keep the interface straightforward. It is busy enough already!

In fact for the native FH Lytebox the Plugin does copy the js/css files from C:\Program Files (x86)\Family Historian\Web\Lytebox\.

If the Plugin took your suggested approach for the others, from where does the user download the js/css files?
They could perhaps be stored in the FHUG KB and downloaded as required.
But if the user accidentally deleted or moved them, they would need downloading again.
So I decided to embed them in the Plugin, as happens in several other Plugins.
Yes it makes the Plugin about 1Mbyte, but many image files are far bigger so what the heck.

If the js/css files are available online, then perhaps they could be downloaded as needed.

[ColeValleyGirl]

The approach I've taken in the past (in js scripts in my scripting editor) is to prompt for a local directory which holds the relevant js and css files (which the user has previously downloaded) and check that the expected files are present before proceeding.

The FHUG KB could perhaps hold guidance on where to download from, including links to the 'official' download sources (or home pages of the relevant products) -- and an indication of which versions of each lightbox product has been tested with the plugin. Or a more sophisticated version of the plugin could (as you suggest) download at need.

This approach might also help reduce the overall size of the website files) as each html file will only need a reference to the js and css rather than include it in its entirety, and make changing the styling of the lightbox by modifying the css file on a production site much easier. (Noted that, if the standard fh Lytebox is being used, the files are copied).

However, as you say, the interface is pretty busy already and the demand for this may not justify the extra complexity/work. I have a js prototype working in my editor that will meet my needs for a while; longer term there may be other improvements I (and rt) want to make (like incorporating 3-generation navigation trees at the top of each individual page, such as is done by GEDmill (http://www.logicmill.com/).

[tatewise]

An option that should work could be based on Lua library modules, similar to luasql, md5, socket, etc.
BUT it needs some enhancements to the Plugin Store &/or FH itself to support a LoadRequire() capability.
I have an extensive set of library modules for string, table, general, encoder, iterate, progbar, and iup_gui functions.
Currently these are replicated in all my Plugins, and I have been asking for an FH Lua library module capability for years.
I believe I have proved the concept works, and has mechanisms to prevent updates to modules from affecting established Plugins by using version controls.
If I remember correctly, essentially all that is required is a LoadRequire() Plugin API or a preinstalled LoadRequire Plugin script, plus the ability to post library modules in the Plugin Store. Such modules may only be posted once, so any updates must be posted under a new name (using a version number in the name). Also such modules cannot be downloaded by users directly and should therefore only be visible to their authors.

[ColeValleyGirl]

I agree -- fh-specific Lua library modules would be a significant step forward in reducing effort (by promoting re-use) and improving code readability/comprehension).

[tatewise]

Could you perhaps put in your request for FH library modules to Calico Pie?
Otherwise, we need to start a Wish List item, but I suspect it won't get many votes.

[rt]

Mike,

I would add my vote to a method of having a common group of routines / functions for use in FH plugins. You & others can debate what method of implementation would be best but good documentation of the routines / functions would be needed and each would need an owner as you describe (especially if enhancements were requested).

Like ColeValleyGirl, I have looked at the source of the "Improve Website.." plugin and wondered on the same aspects of the design, especially when quite a few FH users have between several hundred and many thousands of individuals in their gedcom file. However, you make good practical points as to why you adopted your approach.

A further practical point is that with any lengthy plugin file, scrolling back & forth to find various bits of code can become quite tedious. Using the editor I have to hand, its LUA formatting handles the highlighting of reserved words etc, but doesn't support the (extremely useful) expansion & contraction of routines / functions. Do you know of an editor which supports this for LUA scripts?

Dave

[tatewise]

Dave, thank you for your support.
I would certainly document my library modules along the same lines as the KB Plugin Help & Advice and Code Snippets.

I did not understand you point about: "especially when quite a few FH users have between several hundred and many thousands of individuals in their gedcom file". I don't see how the Plugin design is impacted by the size of the Gedcom file.

I am not aware of any better Lua editors.

[rt]

Mike,

Maybe not a strong point these days, and was intended to be about the accumulated size of the resulting web page files. Perhaps a hangover on my part from the days of being forced to put common code in (sub)routines. (Grief, that was over 45 years ago...)

Thanks for the editor feedback.

Dave.

[tatewise]

You've missed the point Dave. HTML web pages produced by the Plugin do NOT have replicated copies of the js/css files. They use the usual method for including external files, and only one copy of the js/css files gets uploaded to the website:
<script type="text/javascript" src="lytebox.js"></script>
<link rel="stylesheet" href="lytebox.css" type="text/css" media="screen" />

It is the Plugin scripts we are talking about having embedded copies of js/css files and replicated library module functions.

[rt]

Mike,

Ok, it was some months ago when I looked at code in detail and may be confusing it with another product.

Dave.