pkp/pkp-lib#836 book hooks and layout

[NateWr]

This implements a more consistent markup pattern that we can use to allow components on the frontend to be added and swapped around while maintaining some visual consistency. This is useful, for example, to ensure the AddThis plugin or other plugins which add content via the hooks can blend in with other components on the page.

It's documented here and ideally will be a pattern that we maintain for other themes, so that plugin markup output can remain compatible with multiple themes.

In terms of our long-term goals, presses will want some way to control the content that appears on the book page. Bozana has pointed out that everyone is going to a pretty different set of content they want on the page. The hooks are a first-step for adding content. But I see flexibility progressing in maybe three stages:

(1) The hooks allow plugins to add content, and the markup pattern provides a clear way to keep the design consistent.

(2) We display all the core information via the hooks ourselves (abstract, downlaodable files, etc). We can then create a simple interface for them to choose where to put content, eg:

Content	Main Panel	Details Panel	Hide
Authors	[X] Main	[ ] Details Panel	[ ] Hidden
Published Date	[ ] Main	[X] Details Panel	[ ] Hidden
DOI	[ ] Main	[X] Details Panel	[ ] Hidden

At this point plugins could register to appear on this table in the settings area:

Content	Main Panel	Details Panel	Hide
Authors	[X] Main	[ ] Details Panel	[ ] Hidden
Published Date	[ ] Main	[X] Details Panel	[ ] Hidden
DOI	[ ] Main	[X] Details Panel	[ ] Hidden
AddThis	[ ] Main	[X] Details Panel	[ ] Hidden

(3) We actually make the article page function like sidebar blocks, so they can re-order them as they'd like.

If you agree that 3 would be somewhere we want to end up, should we adjust the markup pattern now, so that it follows the same markup pattern as block plugin markup? This would mean that, eventually, we could have convergence in the systems we have to manage (just one sidebar system, instead of having a separate kind of content block management system just for books).

The markup is easy to change now if you think it's a target worth aiming for.

[asmecher]

That looks sensible, Nate.

As for ways to make built-in content (author lists, etc.) rearrangeable on par with content added by plugins etc.:

I think we'll need to continue with both a set of hooks (so plugins can work with content) and content coded directly in the templates (where it'll be something our community can work with without diving into the system deeply).

Naive question: do you think it might be feasible to delegate ordering of elements completely to CSS (the order property)?

[NateWr]

Flexbox isn't supported until IE10, so order is out for now. When we can start deploying flexbox regularly, pretty much everything is going to change. :) Although relying on CSS order to solve problems like this will have negative implications on document order, which is still used by screen readers and other assistive devices.

What's your objection to including components (like abstract, published date, etc) in the hook scheme? We'd still use templates for them, they just wouldn't be coded directly into the one obj_monograph_full.tpl. I was thinking our hook system could be extended with a priority property which could be used to set the order in which items attached to a hook are executed. This would make it fairly easy to generate a UI for re-ordering components attached to a hook.

[asmecher]

No objection to this, just considering the simplest/most readable way to maintain both plugin-based and template-based content without too much contortion. Agreed that flexbox is out of reach just yet, so let's continue without it.

For content within templates, it should be possible to add some Smarty functions to do something like...

{hook_group name="MyHookNameHere"}
    {hook_content label="submission.abstract"}
       (Smarty code to present submission abstract)
    {/hook_content}
    {hook_content label="submission.authors"}
        (Smarty code to present submission authors)
    {/hook_content}
{/hook_group}

The hook_content functions add hooks, then when the hook_group ends, it calls the hook. Any additional registrants that were added via plugins would therefore be able to interact with this too.

That'll keep things decently readable within the template while adding flexibility. The contortion comes in when we need to have templates self-describe so that some tool within administration can be used to rearrange the content added by these, alongside content that might come from plugins. That's why the hook_content clauses each have a label -- that's the text that'll be presented within administration to permit re-ordering of the pieces.

In the administration area, we'd need to invoke the front-end template in order to cause those hooks to register themselves...

$templateMgr->fetch('path/to/frontend/template.tpl'); // Throw away the results; only needed for hook registrations

...plus some additional grunting and sweating to get the sequences to save and load. But I don't think that'll be too bad.

Does that sound like a reasonable and maintainable approach?

[NateWr]

Yeah I like that approach because it will keep the core content right there in the template file rather than forcing people to figure out where it's buried in another file.

I'm just going to save this discussion into my own trello for now, and we can come back it for 3.0 if we have time -- or later if we don't.