Creation of an API and templates using the Theme API

Hey! thanxs for your thoughts!

But, I was talking more like in a sub-modules thing, like the examples I said above: views, views_ui or context, context_ui, where the module views for example only contains the api and functionalities of Views, then the other one views_ui haves all the UI interface.
This is a good example of the use of a modular system.

I'm willing to spent a really good time doing a 3.x version, with help, of course :)

Cheers!,
Sebas.

Thanks jenlampton!

I think you are right about the sub-modules topic, and like guybedford said "would be a bit of a waste", I just wanna have the choice of disable (or not have at all) the interface, wich generate templates files in the DB, but it's ok, lets move on to the other ones.

Wysiwyg Template API and templates in files:

Why?

Today I work with a team of devs, and when is created a template it will require re creation of a Feature to pass the new exported template to everyone else, and this is pretty nice. But! now what about the thumb image? even sending the image to upload my devs colleges will generate problems like Features override for ever, and with every feature revert I will be loosing again the reference to the fid created in my local DB, eventually the editor user will suffer with this problem in every deploy.
The front-end engineers will suffer with the fact of having to code the template in a textarea, so every update or even through the development process will have to copy the code, paste it in a editor of preference, bla bla... borring! so code must be in code.

What can we do about this issues?

We can create a hook based API to declare our templates files, what files? templates files(.tpl.php) you already know how to deal with, suggestions like wysiwyg-templates--[machine-name].tpl.php
Important!, after the editor user inserts the template of choice in the textarea(like the body field of a content type) theres no relation or reference between the templates files. So if you change the default Theme, your content will remain the same. Good news, right? yeah, but there can be a problem, if you wanna make a little change in the markup, the changes will not reflect in content already created, remember, wysiwyg templates doesn't have any relation to the content.

So here is some suggestion of a hook:

/**
 * Implements hook_wisywig_template_info().
 */
function hook_wisywig_template_info() {

  $template_path = 'wysiwyg';
  $image_path = $template_path . '/img';

  return array(
    // Table with a Footer.
    'table_with_footer' => array(
      'title' => 'Table with Footer',
      // Optional, default: NULL
      'description' => 'Table with a footer and a paragraph in it at the end.',
      // Optional, default: NULL
      'image' => 'wisiwyg-template--table-with-footer.jpg',
      // Optional, default: "wysiwyg/img"
      'image_path' => $image_path,
      // Optional, default: "wisywig-template--[machine-name]"
      'template' => 'wisywig-template--table-with-footer',
      // Optional, default: "wysiwyg"
      'path' => $template_path,
    ),
    // Table with a Header.
    'table_with_header' => array(
      'title' => 'Table with header',
      'description' => 'Table with a header and a title in it.',
      'image' => 'wisiwyg-template--table-with-header.jpg',
    ),
    // Image with a right text.
    'image_with_right_text' => array(
      'title' => 'Image with a right text',
      'description' => 'Image(size 100x150) aligned to the left with a right text.',
    ),
  );
}

This hook assumes the templates are in your current or default theme, just like the hook_theme() works, besides maybe later will registered all the wisywig templates in it, using the drupal theme system, can open some other possibilities in the feature.

I have another suggestion of a "hook", but I prefer the first one:

/**
 * Implements hook_theme().
 */
function hook_theme() {

  $template_path = 'wysiwyg';
  $image_path = $template_path . '/img';

  return array(
    // Table with a Footer.
    'table_with_footer' => array(
      // Wysiwyg template's settings.
      'wysiwyg_template' => array(
        'title' => 'Table with Footer',
        // Optional, default: NULL
        'description' => 'Table with a footer and a paragraph in it at the end.',
        // Optional, default: NULL
        'image' => 'wisiwyg-template--table-with-footer.jpg',
        // Optional, default: "wysiwyg/img"
        'image_path' => $image_path,
      ),
      // Optional, default: "wysiwyg"
      'path' => $template_path,
      // Optional, default: "wisywig-template--[machine-name]"
      'template' => 'wisywig-template--table-with-footer',
    ),
    // Table with a Header.
    'table_with_header' => array(
      'wysiwyg_template' => array(
        'title' => 'Table with header',
        'description' => 'Table with a header and a title in it.',
        'image' => 'wisiwyg-template--table-with-header.jpg',
      ),
    ),
    // Image with a right text.
    'image_with_right_text' => array(
      'wysiwyg_template' => array(
        'title' => 'Image with a right text',
        'description' => 'Image(size 100x150) aligned to the left with a right text.',
      ),
    ),
  );
}

So, if someone likes the approaches suggested above, I can start doing a patch to a possible start of 3.x-dev branch :)

Cheers!

I wouldn't worry about that, because in the case the user creates a template through the interface, it can always use the features to export.

But, the thumb image probably must go in the feature along with the export. For that we can think in some solutions, this make sense to you?

Yeah! would be an honor to work with you guys in a dev branch of the 3.0 version, and even more as a maintainer.
I think when you give me the permissions as a maintainer i would be able to push the new branch :)

Cheers!

I see your point, but for me is a little weird if the interface write only in file-based, and i don't know if that is a good practice, today the Features module do that and always remain a database copy and enable the user to override it and make some changes.

Some suggestions and what we have for now:

1. Templates are always file-based, so will be necessary to write in files, where? default theme? here is some working being done for files exporting with uuid and Features http://drupal.org/node/1229670 and here http://drupal.org/node/808690

2. Two systems of templates for one functionality, through interface will write into database and then exporting using Features, or through the API wich enable the user to use a file-based templates just like theme() system of Drupal. What about the thumb image? no relation with Drupal files(fid) making image names and paths suggestions, for example the default Theme directory.

3. The user interface save the template data* into the database, still the API hook will be something like Views does with hook_views_default_views() converting the render of Features export into a file like [module].features.wysiwyg_template.inc using the hook_wisywig_template_default() based in the first suggestion of a hook(hook_wysiwyg_template_info()), with some differences like the "body" property wich contains the template's html code.
So the hook will save into the database too, and this is very well done by the Ctools export ui, this way is going to be more easy to manage the storage, in code and in the database.

The problem of the image repeats in all the cases, so I think we can came up with some idea for all the cases:
- Just in database.
- Just in code.
- In database and in code, through Features export.

Something to consider is the image upload could be optional, instead the use of "template image thumb" name suggestions. Other observation, the images are really light and small(100x70 pixels), so, we can do a simple serialize using base64 hashing, example:

iVBORw0KGgoAAAANSUhEUgAAAGQAAABGC ... ErkJggg==

this will avoid saving images into the upload directory when the template comes from the database.

The choice of templates being in files could be an option when creates/update the template through the UI, disabling the Body field, maybe this can work for the image problem too :)

Well, is a lot to think about, but something that I really liked is a move to Ctools export UI, just seems a perfect fit.

Cheers!