In the overview of the changes coming to Simple Lightbox 2.0, I mentioned that the lightbox code had been entirely rewritten to be modular in nature.  This was not a trivial task, but there are a few reasons that make a modular approach an ideal option:

• Organized – Code is grouped by purpose/use which makes it easier to find the necessary code when adding new features and maintaining current code
• Flexible – Multiple instances of modules can be created, allowing multiple lightbox viewers with different configurations (options, themes, etc.) to be added to a page.
• Extensible – New modules can be easily added to provide new features and functionality (even by 3rd-party plugins)
• Consistent – All modules have a consistent API to safely access a component’s properties and functionality.  This means less issues due to small changes like internal name changes, etc.
• Sane – I got tired of prefixing all methods with a namespace denoting their purpose (e.g. viewerResize(), itemShow(), etc.). Now methods can have simple names and can be easily called (e.g. viewer.resize(), item.show(), etc.)

Let’s have a look at the various modules

Controller

Everything starts at the Controller.  This is the command center that coordinates all of the other modules.  That being said, the Controller mostly initializes the other modules and gets out of the way for them to do their thing.

Modules that are managed by the Controller are called Components, and are actually what do most of the work in SLB 2.0.  All components share the same base and are then further customized to handle their specific functions.

The components are:

• Viewer
• Content_Item
• Content_Type
• Group
• Theme
• Template
• Template_Tag
• Template_Tag_Handler

Viewer

A Viewer handles all display-oriented functionality for a lightbox, from navigation to animations to user-customizable options like UI text and overlay opacity.

Multiple Viewers can be added to the page, each with a different configuration, allowing different links (and groups of links) to be displayed differently from each other.

Viewers reference other components for its functionality:

• The current Content_Item being displayed in the viewer can be accessed to determine the next or previous item to display (e.g. if it is part of a Group)
• The viewer’s Theme controls what the lightbox looks like

Content_Item

A Content_Item represents an item to be displayed in a Viewer.  A Content_Item instance will be created for any link that is activated for SLB, and is used to access the item’s various properties that will be displayed in the Viewer (e.g. image, title/caption, description, etc.).

Items may be part of a Group that can be navigated through by the item’s Viewer, or isolated from all other items.

All items also have a Content_Type that defines properties and functionality for various types of content (image, video, etc.)

Content_Type

A Content_Type defines how properties are retrieved for a Content_Item as different approaches are required for different types of content (e.g. displaying an image compared to displaying a video).

Any number of Content_Types can be defined, allowing any type of content to be displayed by SLB.  Using a priority-based structure, custom Content_Types can even override default Content_Types to add new features for a specific type of content.

Group

A Group is primarily a collection of Content_Items, allowing a Viewer to navigate through multiple items (e.g. a slideshow of related images).

There can be multiple Groups of items on the page.

A Content_Item can belong to a single Group (or none at all).

Theme

Plain and simple, a Theme controls how a Viewer looks when it is displayed.  Different Viewers can have different Themes to allow a different UI for each Viewer.

All Themes have a Template that defines the layout of the content to be displayed in the Viewer.

Template

At its core, a Template is a bit of HTML with Template_Tags sprinkled to define how a Content_Item is displayed in the lightbox.  When requested, a Template will generate the final output using the properties of the Content_Item being displayed.

A basic template may look like:

<div class="container">
	{item.content}
	<div class="details">
		<strong>{item.caption}</strong>
		<p>{item.description}</p>
		<div class="nav">
			{ui.nav_prev}
			{ui.nav_next}
			{ui.nav_slide_control}
		</div>
	</div>
	<div class="close">
		{ui.close}
	</div>
</div>

Template_Tag

A Template_Tag is a placeholder used in Templates that will be replaced with dynamic content for each item.  This allows full customization of what properties will be displayed for an item and how the properties will be displayed in the lightbox.

There are 2 default template tags (though custom tags can also be added):

• item – Access the current Content_Item's properties
• Examples
• item.content: Item’s content (image, video, etc.)
• item.caption: Item’s caption/title
• item.group: The name of the group the item is in
• ui – Insert UI elements into the template
• Examples
• ui.nav_prev: Button to navigate to the previous Content_Item
• ui.close: Button to close the lightbox

Template_Tag_Handler

A Template_Tag_Handler do the heavy lifting to control how Template_Tag in a Template is processed.  This allows any type of tag to be created for ultimate customizability.

There is one Template_Tag_Handler for each type of Template_Tag.

Simple, Right?

As you can see, breaking up the lightbox’s functionality into modules greatly simplifies working with the various components as the structure and relationships are quite clear.  The improved consistency and extensibility make the work well worth it.

Simple Lightbox – The Road to 2.0: Modularity was originally published on Archetyped on April 26, 2012 11:23am

I previously wrote that Simple Lightbox is meant to be purpose-built for WordPress, and that’s what the next version is all about.

Many improvements are on the way in the next version, especially in terms of customization, performance, and usability.  Future posts will provide a more in-depth look at the various features, but here is a brief overview of the changes we’ll see in Simple Lightbox 2.0:

Customization

The current version of SLB already has a wealth of options (activation by post-type, slideshow controls, UI customization, etc.), and even allows third-party additions to a limited degree.  However, the next version of SLB will take this to the next level.  Advanced third-party support will allow custom features to be added to SLB just like a WordPress plugin.  The administration interface has been overhauled to provide site owners with a simple way to control both built-in and third-party features.

Simply put, there are going to be some very interesting features that will let you display media in new ways in the next version.

Flexibility

The lightbox code has been rewritten from the ground up to be completely modular and extremely extensible.  This results in smoother operation of the default lightbox components, but also allows others to add additional features to make the humble lightbox an even more powerful tool for displaying media.

Robust Theme Support

Love it or hate it, most lightboxes (SLB included) generally have a very similar look, but the next version of SLB will make it simple for the lightbox to fit the look of the rest of your site perfectly.  This will also allow theme developers add support for SLB to their themes.  Imagine downloading a theme with a lightbox that matches the rest of the theme perfectly.

Adding additional features to a lightbox theme will also be possible.  Social/sharing buttons, download links, and more will be simple to add.

Display Everything

Thanks to the modular nature of SLB 2.0, the lightbox will be capable of displaying any type of content.  SLB 2.0 will ship with some default content types built-in (images, WordPress attachments, etc.), and additional content types will also be available (either directly or via third-parties).

The best part is that anyone will be able to simply add the ability to display new content types in SLB.

Auto-resize? Yes

I’ve heard the cries for automatic resizing of content that is too large for the browser window.  I’d love this feature too, but it needs to be done right, as standard implementations leave a lot to be desired in terms of image quality.  I’m happy to report that some interesting solutions are currently in development to allow Simple Lightbox to resize content to fit the browser window while maintaining as much image quality as possible.

Advanced, but still Simple

You may have noticed the word “simple” sprinkled generously throughout this overview, but this is no trivial matter.  Simple Lightbox was made to be a simple and automatic way to display images in a lightbox with as little fuss as possible.  SLB 2.0 will have more features, but it will still remain as simple as ever to customize to your heart’s content.  Not to worry, SLB’s zero-click functionality will still be there– just activate and it works.

As always, the suggestion box is open

Rapid progress is being made on Simple Lightbox 2.0, but your requests and suggestions are as welcome as always.  Leave a comment below for what you want to see in the next version of SLB (but don’t bother asking for free slurpies– that’s already planned as a premium option).

Be Prepared

As I mentioned, future posts will cover various aspects of SLB 2.0 in greater detail, so keep your eyes peeled or follow me to find out about them the instant they’re published.

Get a Sneak Peek

Private beta testing will begin soon.  If you’d like to join the ranks of our brave beta testers and get an early peek at Simple Lightbox 2.0, keep an eye out for the signup for the private beta phase.  Yes, I’ll be sure to tweet about it.

Simple Lightbox – The Road to 2.0: Overview was originally published on Archetyped on April 5, 2012 05:00pm

A new experiment: 2 for 1

This week, I have begun experimenting with a schedule that allots two days per week to a project instead of just one.

I will still be grouping multiple projects together on the same days as I have found that it helps to keep my eyes from glazing over as can happen when working on one thing for too long.  The projects are grouped together strategically (related workflows, thought processes, etc.) to maintain as much momentum as possible throughout the day.  I have also injected a day (Wednesday) where I do something completely different to optimize the transition between the first half of the week and the second half.

The Schedule

• Monday-Tuesday
• Simple Lightbox
• Cornerstone
• Wednesday
• Photography
• Video
• Thursday-Friday
• Top-Secret Project
• Site Maintenance

Benefits

Some of the main benefits one may expect from such a schedule are:

• Better use of momentum — Momentum is a powerful tool, and by allocating two consecutive days per week to a project, I will be able to harness the momentum from the first day to make even more progress the next day.
  
• Increased focus — With fewer projects to juggle, I can focus more attention on specific projects.
  
• Faster project completion — With more time to work on a given project, I will be able to complete the projects faster
• Increased availability for new projects — There are always projects on the backburner.  By completing current projects faster, I will be able to start working on the awaiting projects sooner.

Pitfalls

Though one additional day may seem trivial, such a change to the schedule is not without its pitfalls:

• Less variation — Variation was one of the best things about working on a different project every day.  The daily change was refreshing and kept boredom at bay.  By focusing on fewer projects during the week, I may become bored with the repetition.
• No progress on other projects  — In order to spend more time on certain projects, work will need to be stopped on other projects.  It pains me to put a halt on some projects, even though it provides more time to another project.
• Less pressure — This is a big one.  By allocating more time to a project during the week, I am essentially extending the deadline for the tasks I have scheduled.  I will need to remain vigilant to avoid the Wimpy-esque thought that I can “take care of it tomorrow.”

The middle road

I admit that one of the primary motivations for changing my weekly schedule is a lack of patience– I want to finish certain projects, and I don’t want to wait.  However, by taking the middle road and allocating only one additional day to each project, I’m hoping that I will benefit both from the variation of a daily schedule and the increased time of a more selective schedule.

Schedule Changes was originally published on Archetyped on April 5, 2012 02:26pm

• Create “paper trail” of changes made to user
• Role, grade, position, etc.
• Date-based
• Track any type of change for any type of user
• Students, teachers, administration, etc.
• Allow retrieval of full user history
• Allow retrieval of history of based on relationships/connections between content types
• Example: Retrieve history of a class by finding all teachers associated with class in their histories
• Allow queries for users based on properties in history
• Example: Find all students who have had a class with a specific teacher

Data Storage (Options)

1. User metadata (separate records)
• Store history in built-in wp_usermeta database table
• Methodology: Changing a property for a user
1. Save old property value in special meta key: hist_{property-name}
• {property-name} is property being changed
2. Set new property value in default meta key: {property-name}
• - Changes not dated
• Option: Could store date with old value as serialized data
• - Would need to parse/sort full query before results based on specific properties/values could be returned
• + Simple to query based on meta key
• Find all users with specified property/value combination
• ? Can user metadata store multiple items with same key for user? (ala post meta)
• A: Yes
2. User metadata (serialized data)
• Entire user history stored in single row for user in built-in wp_usermeta database table
• Data stored as serialized array
• Key: Timestamp of user property change
• Value: Object/array of properties/values
• - Must query all users’ histories before any connections can be made
• + Keeps wp_usermeta table cleaner
3. Separate database table
• User history stored in bespoke database table(s): user_history
• Structure (schema)
• id: Unique row ID
• user_id: User ID
• date: Timestamp of property/value change
• property: Property being set/changed
• value: New value of property
• Example: Student grade-level change
• id: Automatically set
• user_id: {user-id} (ID from wp_users table)
• date: Current date time
• property: “grade-level”
• value: 2
• ? Current user properties: How to manage/query? (Options)
1. Mirror current properties/values in user metadata
• History table used primarily for past history
• All current user data should be accessed from user metadata
• History updated when property changed/set
• + Can perform queries for current data using metadata (all students in class “x”, etc.)
• - Duplication of data: wp_usermeta/user_history
• Not too much of an issue because history only used for archival purposes (e.g. not validating current user properties)
2. Add current column to user history table
• Flag indicates row contains latest data for user property
• - Must unset previous row flagged as current when setting new data
• +Simple to query current data using where clause

  ...WHERE current = true

3. Use date column
• Query only latest matching rows
• Unique rows sorted by date column
• Will return most recent row of each property for user
• ? How to retrieve multiple properties with same key for user?
• Example: Student may currently be in multiple classes (and assigned to each class at different times)
• - Only most recently-set class would be returned for student

Properties with multiple values (Options)

Examples

• Student in multiple classes in current semester
• Teacher teaching multiple classes in current semester

1. Serialized property value
• Store data as array
• - Does not track granular changes
• Example: Single class changed while others remain
2. Multiple rows with same property
• Example: Separate row for each class that student is enrolled in
• + Current classes managed as user metadata
• History just for chronological record
• Dates of property changes “tells the story” of user’s changes

EDU: Notes – Core: User: History was originally published on Archetyped on March 21, 2012 06:09pm

It’s been awhile, but a new beta version of Simple Lightbox is ready to be unleashed upon our awesome group of brave testers. Your testing helps to make SLB better with each update.

The beta is quite stable, but one person (me) can only do so much testing. Now it’s time to let it loose for all of you to install and test.

Version 1.6.2 is primarily a maintenance release.  Not a lot has changed (except for a 95% rebuild of the JS code), so with your help it hopefully it won’t be long before 1.6.2 is ready for an official release.

What you get

For being a brave lad and installing the beta version on your site, you get the latest version with all the new features before anyone else. You also get a chance to provide feedback before the final version is released. Awesome, I know.

Oh yeah, and if you find a bug, the fix is named after you. Fame and fortune will surely soon follow.

Note: As always, all previous stable versions of Simple Lightbox are available via WordPress’ official plugin page if you need to downgrade to a previous version for any reason.

Release Notes:

Beta 2

• Optimize: Improved PHP 5 compatibility

Beta 1

• Update: Rebuild JS code
• Fix: Some elements can overlap lightbox
• Optimize: Improved utility code

SLB 1.6.2 Beta was originally published on Archetyped on March 16, 2012 01:08pm

• Unified way to get/set component references from within other components
• Used as base of other get/set methods (get_viewer(), etc.)
• Smart – not too dependent on configuration
• Safe – manages component data without risk of corruption

Get component reference (Process)

Arguments

• Property name (string): Name of property to retrieve (group, viewer, etc.)
• Data type (Component Class [function]): Component type (View.Viewer, View.Group, etc.)
• Validates data type before returning data
• Enables creation of new component instance if necessary
• Get default (optional) (boolean): Whether to get default component reference from controller
• Default: Yes
• Useful when searching through container components for reference (as returning default reference will stop iteration through containers)

Prioritized search for component

1. Check if instance property already set
• Can be set by various operations
• Previous property retrieval (caches property for future access)
• Direct property setting (e.g. set_viewer(), etc.)
• Return value immediately if property is set
2. Check instance attributes for component
• Instance attributes stored as: instance.attributes (object)
• Attribute key matches property name: instance.attributes.viewer will contain viewer reference
• Possible return values – Dependent on how attribute was set
• String: ID of component reference
• Components stored by ID in controller (View)
• Object reference: Direct reference to another component
• Set attribute value to main instance property if found (for faster future retrievals)
• set_component(property_name, value)
• Sanitizes value
• Retrieves actual component reference from controller based on ID (string) and component type
3. Check containers
• Containers: Component instances that current component instance can inherit/access properties from
• Such components contain current component (e.g. Group contains Item, etc.)
• Containers defined in component class definitions (object)
• Key: property name (group, viewer, etc.)
• Value: Component data type (View.Group, View.Viewer, etc.)
• Iterate through containers
• Retrieve container component reference

  //Example (Group)
  var container = get_component('group', View.Group);

• - Recursion issue in get_component() if using get_component()to retrieve containers
  • Example: Property being searched for = Container being searched
  • Property: group
  • Current container: group
  • A: Skip containers that match current property being searched for
  • e.g. Don’t look in ‘group’ container if attempting to retrieve ‘group’ reference
• Look for component reference in valid containers

  var component = container.get_component(property_name, data_type);

• Containers will generally access controller object (View) if reference not set on container itself (next step)
• ? What if subsequent containers have component reference directly?
• Example: group container does not have reference, but view container does
• Options
1. Retrieve reference from container’s controller as fallback (current)
• Only single container will be evaluated (since a valid reference will be returned from controller as fallback)
• - Subsequent containers will not have a chance to retrieve reference
• - Pointless to have multiple containers
2. Do not use controller as fallback
• Add additional parameter to get_component()to skip fallback

  var container = get_component('group', View.Group, false);

• Return empty value if reference not found on component itself
• + All containers will be evaluated
4. Get reference to default component from controller
• Controller (View) is set as parent of all components
• Default component created if not previously created
• Uses initialization options to build component instance with default properties
• ? Do all components have a default?
• Viewer: Yes
• Theme: Yes
• Group: No
• ? Handling items without groups
1. Ungrouped items are displayed singly (current)
• No slideshow support for ungrouped items
• + Clear/straightforward operation
• + Server-side can add ungrouped items to group based on options (group by post, etc.)
2. Display ungrouped items as group
• Use a default group to group all items not explicitly placed in a group
• Ungrouped items will be displayed as a slideshow
• + Possible to easily cycle through ungrouped items
• - Overrides admin options
• - Items do not need to be grouped if they were not purposefully grouped
• - Items that you want to display in isolation will need to have to be explicitly placed in their own group
• Content Item: No
• All content items are unique and should point to valid content
• Content Type: No
• All content types registered manually

Return value

• Valid component type or NULL (e.g. if component reference not found)
• Wrapper methods (get_group(), get_viewer(), etc.) can use return value to validate data and return appropriate value

Set component reference (process)

Arguments

• Property name (string): Name of property to set (group, viewer, etc.)
• Value (object|string): Component reference
• string: ID of reference – stored in controller (View)
• object: Component instance reference
• Data type (Component Class [function]): Component type (View.Viewer, View.Group, etc.)
• Required data type for component

Methodology

1. Retrieve component instance from controller if ID supplied

   var component = this.get_parent().get_component(id, data_type);

• ? What to do if component with matching ID does not exist in controller?
• A: Options
1. Return empty value (null)
• Component reference not set on current object
• Continue to next step (container iteration) if attempting to set invalid value in get_component() to find valid component reference
2. Create new component
• Use supplied ID to initialize new component instance
• Use controller defaults/options to set new component’s properties
• Controller options are parsed (if not already parsed) to provide access to component-specific options/properties
• ? Use single method to initialize new components or use component-specific methods?
• A: Options
1. Single universal method
• Controller properties will need to parsed into groups so that new component will be passed appropriate values
• + Only one method to maintain when API changes, etc.
• + Components share same base definition (methods, properties, etc.)
• - Single method may become convoluted when components diverge a lot
2. Component-specific methods
• Create specific method for initializing each component (View.add_group(), etc.)
• + These methods should exist anyway for adding components directly
• ? How to add components if component-specific method does not exist
3. Component-specific + Universal method
• Use universal method (less specialized) if component-specific (more specialized) initialization method for component does not exist
• + Simple components may not need specialized methods
• + Allows more specialized creation of components as needed
• + Object’s attributes say that component should exist
• + Not overwriting anything – only creates new instance if ID does not exist
• Can customize component instance properties later if necessary
• New component instance saved to appropriate controller collection (Based on data type: View.groups, View.viewers, etc.)
2. Save component reference to specified property type

   this.property = component;

SLB: Notes – JS: Component References was originally published on Archetyped on March 8, 2012 11:37pm

• Do as little as possible at any given time (only what is necessary)
• e.g. Parse theme tags only when displaying theme, not during initialization, etc.
• Safe data access – Component instance data always accessible
• Cache component instance data/properties
• If something is parsed or processed, the result should be cached for future access

Displaying Content Item

1. Link clicked
• Click handler set on initialization
2. Determine Viewer
• Iterate through component hierarchy until a Viewer is found
• Priority
1. Content Item – set specifically for current item
2. Group – set for group that item is in
3. Default – set on View Controller as fallback Viewer
3. Set “Loading” flag (Viewer)
4. Load Viewer Theme
• Insert Theme layout into DOM (if not previously done)
• Parse Theme layout
• Static tags – UI, labels, etc.
• Dynamic tags: Item data, etc.
5. Load item content
• Determine Content Type
• Load Content Type
• Run renderer for displaying Content Type
6. Display Viewer
• Viewer event handlers (e.g. navigation, etc.) set as “live” events during initialization
7. Content loaded
8. Turn off “Loading” flag
9. Start timers, etc. (for slideshow)

SLB: Notes – JS: Processes was originally published on Archetyped on March 7, 2012 10:55am

• Insert predefined HTML
• Core and theme-specific
• Support dynamic content
• Changes on per-item basis
• Necessary to support multiple content types (e.g. images in <img> element, HTML in <div>, etc.)
• Support attributes/options
• Customize how tag is processed/output
• Support user-customizable options (UI labels, formatting, etc.)

Elements (Core)

• Content: Primary content (image, video, etc.) displayed in lightbox
• Dynamic: HTML changes based on content type
• Item Data: Data/attributes of current item
• Examples: Permalink, source URI, image dimensions, title, caption, description, etc.
• Available attributes based on item’s content type
• Common attributes
• Source URI (string): Direct URI to content (for display in lightbox)
• Image source, video file, etc.
• Permalink (string): Canonical URI for content (e.g. when viewed on its own page)
• Video page, attachment page, image URI, Website address, etc.
• Title (string): Item caption
• Derived from link if not otherwise available
• Group (obj): Group item belongs to
• Internal (bool): Whether item is internal media or not
• UI elements
• Static: Does not change per-item
• Labels: User-customizable UI content
• Navigation text: previous/next item, start/stop slideshow, close, etc.
• Predefined elements: HTML for building UI (close button, prev/next button, loading indicator, etc.)

Implementation

1. Dynamic Data (options)
1. Wrap tag output with DOM element
• Example:

  <span id="slb_tag-id" class="slb_dynamic_wrap">[tag output]</span>

• Wrapper indicates dynamic data using DOM attributes
• class: slb_dynamic_wrap
• id: slb_tag[id] (Points to object with tag options)
• Alternative: Set reference to raw tag as data on wrapper element itself

  $(el).data('slb_tag', tag);

• + Allows dynamic replacement of content in viewer
• Similar to current method of loading new content in lightbox (replace HTML inside of a wrapper DOM element)
• + Allows any tag to be dynamic
• ? Should all tags be dynamic?
• A: No, only those accessing data (item, environment, date/time, etc.)
• - Cannot use data within HTML tags (since tag output is wrapped in a DOM element itself)
• Example
  Original

  <a href="domain.com/file.html?id={tag}">Link text</a>

  Rendered

  <a href="domain.com/file.html?id=<span id="slb_tag-id">[tag output]</span>">Link text</a>

• Solution (options)
1. Build HTML tag using options in theme tag
• Example
• Link

  <a href="domain.com/file.html?id=[tag data]">Link text</a>

• Tag

  {tag pre='<a href="domain.com/file.html?id=' post='">Link text</a>'}

• Alt

  {tag format='<a href="domain.com/file.html?id=%s">Link text</a>'}

• Uses string formatting to replace %s with tag output
• Entire output wrapped in wrapper
• Original string format saved
• Formatted value inserted as HTML into DOM (wrapped)
• + Allows complex output using item data
• + Does not impede HTML output
• - Convoluted way to build HTML output using tag output
• - Limited: How to use other data within link? (link text, title attribute, etc.)
2. Register handlers for different tags
• Similar to CNR content type field templates
• Example: Link

  {link href="domain.com/file.html?id=%s" data="item.permalink"}Link text{/link}

• Attributes
• href: URI format
• data: Data to use in URI format
• title: Link title (can be string format)
• title_data: Data to use for Link title
• Link text: Wrapped in tag
• + More specific handling of output
• Attribute data will be properly formatted (escaped for URLs, etc.)
• + Simple: Don’t need to mess with HTML in tag attributes
• - More complex to implement
• + Highly flexible: any kind of output can be accomplished by tag handlers
2. Rebuild entire layout for each item
• Start with raw layout (with tags, etc.) every time an item is displayed
• - Inefficient: must parse entire layout for each item (even if few dynamic tags are present)
• Performance may suffer
• + Will always be a certain amount of dynamic data in layout (content, etc.)
• Parts of layout must always be rebuilt per-item anyway
• ? Visual smoothness? Rebuilding full layout affect transition between items?
• Likely
• + Simple: Don’t need to wrap tags since raw layout will be used every time
2. Tags (Default)
• item: Access item data/properties
• Example:{item.title} – Item title
• Dynamic: Yes
• Format modifiers: Yes
• {item.title|lower|escape} (makes item title lowercase and escapes it)
• ui: User interface output
• Example: {ui.nav_next} – Next item navigation link
• Dynamic: No
• Format modifiers: No
• Common attributes: Can be set on all default tags
• May be implemented differently by different tags
• class: CSS class
• id: Unique ID
3. Tag format (Options)
1. Curly braces + XML-style attributes
• Tags denoted by curly braces ({, })
• Options/attributes set XML-style: attribute="value"
• + Simple: Familiar to any using HTML
• + Fairly unique: Curly braces not common in normal content
• ? How do format modifiers fit in?
• Simple: {tag.prop|modifier}
• With Options
1. XML-style attributes followed by delimited modifiers: {tag.prop attribute="value"|modifier}
• Attributes processed first, then passed to modifiers
  
• + Clear separate between modifiers and attributes
• + Still pretty simple to write
• - Convoluted: 2 different modes for similar information (options that modify output)
2. Format modifier style: {tag.prop|attribute:value|modifier}
• - Attributes not clearly separated from modifiers (hard to tell when option is an attribute or a modifier)
• + Simple: Singular way to add options that modify output
• + Tag handler can use supported options and pass output to global modifiers after (with processed options removed)
• supports_modifiers flag in tag definition can determine whether output is processed by global modifiers or not
3. One or the other (attributes or modifiers): {tag.prop attribute="value"} or {tag.prop|modifier}
• - Limiting: May be useful to have access to properties and modifiers in tag
• ? When? (Use cases)
• Item: No – Modifiers only ({item.title|lower})
• UI: No – Attributes only ({ui.nav_next class="test"})
• Outputs DOM element, so should not be modified by standard modifiers (lower, etc.)
• Formatting of values (e.g. labels) should be handled via CSS
• Custom Tags: Possibly ({tag attr="value"|modifier})
• + Allows theme designer to further customize output from custom tags
2. Double braces (curly/square) + XML-style attributes
• Attributes same as 1
• Tags denoted by double braces ({{/}} or [[/]])
• + More unique: double braces even less common than single braces in content
• - More characters to type for every tag
• - Increases visual “noise” in layout
3. Other established format
• Liquid, Smarty, etc.
• Need to look into options
4. Registering External Tag Handlers (options)
1. Client file registration (via other plugins)
• Allow additional files to be registered with internal client files
• Use same structure: [handle, file, etc.]
• - Will need to expand file parser to handle external files
• + Not too difficult since external files should have full path rather than relative path (just look for presence of path constants)
• + Allows simple inclusion of JS files after internal files loaded
• JS file can register tags, etc.
• Use dependencies to determine order of loading external files
• + Also controls whether external file is loaded (if dependent on internal file that is not loaded, external file with not be loaded, etc.)
2. WP Hooks
• Fire hooks before/after various operations
• Events
• slb_head/slb_admin_head: Header files loaded
• slb_footer/slb_admin_footer: Footer files loaded
• slb_client_init: Client JS initialized
• + Allows external code to add files/code in proper location
• Ensures SLB’s files are loaded before external code is executed
• ? How to confirm necessary files have been loaded?
• Hooks will always fire, but different files are loaded based on various conditions (context, callbacks, etc.)
• A Use SLB functions in external code to determine if external file should be loaded
• PHP

  /* External Plugin */
  add_action('slb_head', 'ext_load_head_files');
  
  function ext_load_head_files() {
  	if ( slb_is_enabled() && slb_is_context('public') ) {
  		//Load files...
  	}
  }

• JS (object detection)

  /* Confirm SLB loaded */
  if ( !SLB || !SLB.View )
  	return false;
  
  /* Run code */
  SLB.View.add_tag(...);

• ? How to fire hook after files loaded?
• File loading is handled by WP enqueue/registration API (No direct loading)
• AAdd hook to trigger SLB hook

  //Low priority hook
  add_action('wp_head', 'call_slb_head', 99);
  
  function call_slb_head() {
  	//Fire internal hook
  	do_action('slb_head');
  }

5. Tag Handlers
• Properties
• id (string): Tag ID
• build (function): Function to build tag output
• attrs (object): Default attributes/values
• dynamic (bool): Tag rebuilt for each item or not
• supports_modifiers (bool): Determines if modifiers can be used on tag output

SLB: Notes – JS: Components: Themes: Layout Tags was originally published on Archetyped on March 6, 2012 11:53am

• Consistent access to base object (SLB global variable)
• Support for methods/properties
• Consistent access to utility/helper methods/properties (prefix, context, etc.)
• Organized structure
• Extendible – Attach members/data to objects
• e.g. SLB (base object), SLB.util (utility object), SLB.View (view controller), etc.

Implementation (Options)

1. Current: Object literals with extend method
• Define methods in object declaration
• - Object properties cannot reference self via this (references window object)
• Less modular code
• + Simple declarations
2. Constructor function
• Objects are instances of base class definition
• Base constructor defines standard properties/methods (utilities, etc.)

  SLB = new Base();

• All objects have direct access to standard methods/properties (SLB.View.util.get_prefix();)
• ? Better than single base object with properties/methods (SLB.View.base.util references SLB.util)
• A: Yes
• Will need to wrap initialization and attachment of new members into single method
• e.g. SLB.attach('View', {data});
• ? Method name? – currently extend, but may conflict with Class.extend() (Inheritance)
1. Single method – 2 modes (based on parameters)
• SLB.extend('View', data) (2 parameters)
• Add View member to SLB object
• Create new instance of base class inherited by View object
• data (object) – Properties/methods for new member
• SLB.extend(obj) (1 parameter)
• Extends SLB object and returns new instance
• + Simple
• + Single method for both related functionalities
• One version simply adds it to global object
• - Confusion: Better to have separate methods for sake of clarity?
• extend: Create new class inheriting base class
• attach: Add member to object (creating new class that inherits base class)
• Structure
• Class Definitions
• Base
• Utility/Helper methods
• References base object for instance properties (prefix, etc.)
• Member attachment functionality
• Standard properties/methods
• Core
• Extends Base class
• Functionality specific to core object
• Instance Objects
• Core (SLB)
• Base instance for all other members to be attached to
• Members
• View Controller (SLB.View)
• Lightbox functionality controller
• SLB.attach('View', obj class_definition)
• New View class created (extends Base class)
• + Access to standard properties/methods without having to “travel” to Core (SLB) object
• Components (viewers, groups, etc.)
• Attached via

  SLB.View.Viewer = SLB.View.extend(obj class_definition)

SLB: Notes – JS: Classes was originally published on Archetyped on February 28, 2012 10:21am

How to handle invalid callbacks?

Options

1. Current: Remove context completely
• Other valid contexts will still be evaluated
• - If no other contexts exist, file will always be loaded
• Not ideal behavior
2. Pass all callbacks to register method (whether valid or not
• Allow register method to determine how to handle invalid callbacks
• - Extra processing for file that should not be loaded
3. Remove callback and evaluate just context (string)
• - Callback is meant to be a condition of loading file
• Removal of callback will cause undesired loading of files
4. Track if no valid context exist for file (after parsing)
• Remove files with no valid contexts
• Files defined with empty contexts are allowed to pass
• Should always be loaded
• Use flag to track during parsing
• Example: $valid_context = false until valid context encountered
• If flag is false after all contexts evaluated, remove file
• ? Are there other conditions that should still allow file to load?
• e.g. callback property
• A: If contexts are set but all are invalid, global callback doesn’t matter
• Contexts & global callback are both evaluated when loading file

SLB: Notes – Client Files: Context Callbacks was originally published on Archetyped on February 27, 2012 03:26pm