Custom Web Galleries in Lightroom: Getting Started

This is the first section of my notes on building a custom web gallery for Lightroom. It was last modified January 2013 and relates to Lightroom 4.3.
Go to the Table of Contents to see all available sections.

Notes on modifying Lightroom Web Templates


One - download the dev kit. Put the two example files in the lightroom dir as appropriate (mine is located at:

C:\Users\odoketa\AppData\Roaming\Adobe\Lightroom\Web Galleries\davidsample2.lrwebengine


The sample from Adobe comes with two example web templates, which I will call 'Sample 1' and 'Sample 2'.
You can tell them apart because Sample 1 has a bunch of random quotes at the bottom (to show how to use certain variables, etc.)
Sample two does a split screen display with the thumbnails at left and the big picture in the center.

I prefer the sample 1 layout, so that's the one I'm going to build off of.
That is located in
C:\Users\odoketa\AppData\Roaming\Adobe\Lightroom\Web Galleries\davidsample1.lrwebengine

For a start, we're going to need to change the 'MySample' heading on what is clearly the title to read
'site title' or something. So I open galleryinfo.lrweb and head down to views, which is where the
menu item get set (in the header of the file the comment notes "
The views table creates the panel entries available within the Lightroom UI.  For this sample the
user can dynamically edit the site title of the website before it is published." which is how I knew
that was where to go.

It looks like the default value for this variable is set above, in model.

I'm fairly certain f:subdivided_sections creates a new section of user vars, and then
f:labeled_text_input creates the actual entry. First and foremost, I'm going to change
title to equal "site title" and see if that works.

I tried various methods of reloading the module to see the changes I had made, but it loooks like
closing and opening the program is the only way to do this. So I do this, and now the site title
entry area is labeled "Site Title". Success! 

For giggles now, I'm going to copy the whole 'f:labeled_text_input' block (from the f: to the closing '},'
and see if that allows me to create another variable. I'll call this 'Site Description' and it will be
(I hope) a smaller text description of the photos on the page.

f:labeled_text_input  {
	title = "Site Description",
	value = bind "metadata.siteDescription.value",
},

Now I know from before that I can define the defaults up above in the model, so I'll create a new line
up there with the description default.

["metadata.siteDescription.value"] = "Describe the site", -- default for siteDescription variable

I'm going to save this. I'm pretty sure it won't work, because I think I need to define the variable
in another file first, but I'm going to try it and see what happens. Close and open the program and
Lo! it worked with no additional changes!

I see just underneath there's a CSS ID for site title - I'm not sure how that works, but I'm sure we'll
want something similar for our description (especially if it controls the actual appearance on the page
of our text.

Since I've added a Site Description, I might as well try to display it. Let's go see how that's done.

I imagine the header is where we would display this stuff, and I'll bet that if this paginates, the header
displays on each page. So that's also a good place to put the description.

The last line of the example header is

<h1 onclick="clickTarget(this, 'metadata.siteTitle.value');" id="metadata.siteTitle.value" class="siteTitle">$model.metadata.siteTitle.value</h1>

I feel pretty confident we can rework this to be the description. Let's start by removing the onclick. I think we should leave the id and class
and change them to what is appropriate. Going to change the h1 tag to maybe h3 or even a simple p tag.
Hm. Looks like there's a metadata.x.value in id, that's probably going to break things. I'll pull it for now,
but I'm sure later we'll want it to style things.

<h3 class="siteDescription">$model.metadata.siteDescription.value</h3>

Looks like simply shifting from one module to another reloads the page, at least for html changes. I imagine the
key pages get cached, but the html templates do not. Handy!