Token replacement modules

[mindplay.dk]

I'm seeing more token replacement modules crop up lately - modules that pick up various tokens (with various syntax) in text/html fields, replacing them with various types of mark-up, snippets, images, etc.

Just a point of view: I think parsing and replacing tokens, and (more importantly) introducing augmented syntax, is the wrong solution for all of the problem I have seen people attempting to solve using this approach. Actually that's not specific to PW - a lot of CMS (and contributors) take this route, and it never leads to a very pleasant end-user experience.

In my opinion, from the end-user's perspective, it beckons the question: if you're going to make me learn other forms of mark-up, why not just give me a bare plain-text HTML editor and make me learn HTML?

At least HTML is one consistent syntax, it's universally useful, and it's not some strange mix of a whole bunch of other HTML-like syntaxes mixed into what is actually HTML.

I'm not posting this just to gripe - I've actually worked on (I think) a "better" solution in the past, but unfortunately it was never completed.

Rather than making people learn and type actual syntax, I used an approach with simple placeholder tokens, like so:

<h1>Welcome!</h1>
<p>Pretty picture of my pet fish:</p>
{fish}
<p>And my pet bird:</p>
{bird}

The placeholders are not "tags", and they don't have any actual "syntax" - the names are arbitrary and don't mean anything at all, except in terms of semantics used by the author.

They don't have attributes, and there is no concept of "blocks" or start/end tags.

They are all local to the body/content field you're editing, and have no shared meaning outside of the current context.

Instead, the client-side editor recognizes the {fish} and {bird} placeholders, while you're typing, and a graphical user interface appears, presenting you with a list of placeholders you've used in the text or WYSIWYG content-area you're editing.

You can then click on the placeholders in the list and decide what type of "macro" you would like to replace them with - then configure the properties of that macro. In the above example, you might select the {fish} or {bird} placeholder from the list, select the "image" macro, and upload or select from a library of images, configure cropping or resizing, perhaps watermarking, etc.

In ProcessWire, two very useful macros would be Page and Field - allowing you to expand a placeholder, replacing it with a rendered Page or an individual rendered Field from a specific Page. This very simple solution could enable you to build things like block systems or navigation without any additional programming - just simply define reusable Pages with snippets of content, images, or Page references and so on, in a reserved folder in the root of your site, and then pick from those using macros.

Is this comprehensible? (I might be able to dig up the very old prototype and post some screenshots)

And what do you think of this idea?

[mindplay.dk]

In fact, come to think of it, these "macros" don't have to be a new concept in ProcessWire at all - they could simply be Templates, and their user-interface would consist of Fields, and their php-templates would render sections/snippets for inline use, instead of full pages.

That way, you could make full use of any Fieldtypes you have installed, and you wouldn't need to write code to create new types of "macros".

[SiNNuT]

I definitely like your thinking here and agree that a lot of end users will benifit more from this kind of GUI/Popup approach for added functionality.

On the other hand i think that sometimes tag replacement works very well.  

[kongondo]

Mindplay,

I have read your post 4 times and I still don't see the fundamental differences between what you are suggesting and what the 3 tag parser modules we have (shortcodes, tag parser and hanna) do . 

A couple of thoughts...

The placeholders are not "tags", and they don't have any actual "syntax" - the names are arbitrary and don't mean anything at all, except in terms of semantics used by the author.

I see no difference between your placeholders and the tags/tokens used in the above modules. They are all placeholders in my book . I see no difference between { } and [ ].   The names in the above modules are also arbitrary (at least in the case of shortcodes and hanna).  You can even change the "placeholders" you want to use. 

You can then click on the placeholders in the list and decide what type of "macro" you would like to replace them with - then configure the properties of that macro. In the above example, you might select the {fish} or {bird} placeholder from the list, select the "image" macro, and upload or select from a library of images, configure cropping or resizing, perhaps watermarking, etc.

In the current modules, you make the decision about what type of "macro" you want when creating the "placeholder". The difference between your approach and the current approaches is when the decision is made. In fact, IMHO, if I'd be more confused if sometimes {fish} can mean images and in other cases {birds) and they "don't mean anything at all". I suspect I just don't get what you are suggesting . I agree though, that a GUI would make work easier for some people. I would accept this as a another choice rather than do away with the approach offered by the current modules.

One very important difference between the current modules and other CMS is what the modules actually do. I'll give an example from MODX since it is a tag based system I have used before. In MODX, when the system encounters the tag  [[*content*]], it replaces that with the "body" content. That is a fundamental difference with above modules. I consider the PW modules nothing more than search and replace tools . Unlike in MODX, where the user doesn't care how MODX works its API juju to replace [[*content*]] with actual text of the "body" content, in the PW modules, the user must still be able to write "PW API" (the PHP the tags will inject). I think this is a good thing and is in line with PW philosophy about the types of users it is targeting.

PW is growing and it is attracting many people with different skill sets. Part of this crowd are wanna-be-coders like me . These modules offer choice to people like me. Come to think of it, the modules are also useful to seasoned coders - e.g. ability to inject some code on a page rather than at the template file level. 

As long as these modules are not part of the core, I am happy. If I want point and click I'll use Joomla. I have to admit initially I was concerned with the different tags used by these modules (including Image Manager). Maybe it is not a big deal? After all, they are not part of the core.  

Anyway, I probably haven't understood your proposal. However, there is a place (and in the near future, I suspect a very big place) for modules like hanna considering the crowd PW is attracting. 

My 2 cents 

Cheers/k

[mindplay.dk]

@kongondo:

Shortcodes are mark-up. The tag parser is actually not just mark-up but code. Hanna is code/mark-up, depending on your definition. These modules define new inline mark-up syntax, and while that may be great for some people, learning yet another mark-up language isn't going to be everyone's cup of tea.

The key difference from what I'm suggesting, is that the meaning of a specific tag, mark-up or placeholder in those modules, is defined externally from the document where they're used.

So a placeholder like {fish} only has meaning within the document you're editing - there is no definition of {fish} external to the document you're editing, and it only has whatever meaning you attribute to it by (visually) defining what that placeholder will be replaced by.

To give a practical example, let's your site contains articles, and some of those articles have inline image galleries - inline with the body-content of the article, between two paragraphs, wherever the author elects to place it. Let's say each image gallery has a summary and a list of images each with a caption.

You could do it with inline code/tags like this:

<p>Nam consectetur mollis elit sit amet commodo. Cras fringilla, turpis pretium vestibulum adipiscing, massa est scelerisque odio, vitae pharetra dolor erat in nisi. Maecenas magna augue, volutpat in consequat id, feugiat eu lacus. Aliquam erat volutpat. Pellentesque vehicula mi vitae est vestibulum nec volutpat dolor blandit. Duis eu gravida sem. Sed et ligula ut est pretium ornare. Ut dictum tincidunt est a scelerisque.</p>

[[gallery float="right" summary="Colorful photo gallery of Piranhas in action" width="400"]]
  [[image id=789 caption="Adorable Piranhas flocking around my legs"]]
  [[image id=123 caption="Piranhas attacking my legs"]]
  [[image id=456 caption="What was left of my legs after the attack"]]
[[/gallery]]

<p>Maecenas malesuada facilisis lacus eget sodales. Phasellus ut quam a sem molestie egestas non non enim. Pellentesque orci lectus, auctor mattis ornare vel, tristique sed quam. Cras ac dui vel dui varius iaculis vitae gravida arcu. Curabitur non nulla felis. Sed viverra sagittis odio non ornare.</p>

What I'm proposing is you do it with a simple placeholder instead of code:

<p>Nam consectetur mollis elit sit amet commodo. Cras fringilla, turpis pretium vestibulum adipiscing, massa est scelerisque odio, vitae pharetra dolor erat in nisi. Maecenas magna augue, volutpat in consequat id, feugiat eu lacus. Aliquam erat volutpat. Pellentesque vehicula mi vitae est vestibulum nec volutpat dolor blandit. Duis eu gravida sem. Sed et ligula ut est pretium ornare. Ut dictum tincidunt est a scelerisque.</p>

{piranha gallery}

<p>Maecenas malesuada facilisis lacus eget sodales. Phasellus ut quam a sem molestie egestas non non enim. Pellentesque orci lectus, auctor mattis ornare vel, tristique sed quam. Cras ac dui vel dui varius iaculis vitae gravida arcu. Curabitur non nulla felis. Sed viverra sagittis odio non ornare.</p>

As soon as the WYSIWYG or textarea detects the {piranha gallery} placeholder in the content, the placeholder will show up on a list, and you can populate all the properties of the inline gallery block via inputs instead of typing mark-up.

It's just more user-friendly and faster to work with, in my opinion - and I like the fact that the placeholder {piranha gallery} has semantic meaning to a person editing the article, whereas actual mark-up has to be interpreted by the person editing when encountered. Because there's no mark-up, you can't make typos or other mistakes. It eliminates a learning curve.

And perhaps most importantly, it builds on existing ProcessWire concepts and introduces as little new functionality as possible, instead of introducing entirely new concepts and/or syntax.

[WillyC]

hana.pirana  gallery, u type :

[[gallery tag=pirana]]

,,gallery,, hana code :

$fotos=isset($tag)? $page->images->findTag($tag): $page->images; 
if(count($fotos)) {
  foreach($fotos as $foto) print "<img src=$foto->url>";
} else {
  print "<img src=/buttocks/fotos/bottolusk.jpg>";
}
 

have.this right do i mr.ryan ?

[[gallery float="right" summary="Colorful photo gallery of Piranhas in action" width="400"]]
[[image id=789 caption="Adorable Piranhas flocking around my legs"]]
[[image id=123 caption="Piranhas attacking my legs"]]
[[image id=456 caption="What was left of my legs after the attack"]]
[[/gallery]] 

mind.play.dkk u good  ​ 

[kongondo]

hana.pirana  gallery, u type :

[[gallery tag=pirana]]

,,gallery,, hana code :

$fotos=isset($tag)? $page->images->findTag($tag): $page->images; if(count($fotos)) {  foreach($fotos as $foto) print "<img src=$foto->url>";} else {  print "<img src=/buttocks/fotos/bottolusk.jpg>";} 

have.this right do i mr.ryan ?

WillyC, even the following will work with Hanna

Edit: with normal text; with PHP no....see below LAST EDIT:) All work single ( or { or [

{piranha} 

Just change the tags you want to use in TextformatterHannaCode module. I haven't tried it with PHP yet. 

 These single tags/square brackets will work in PHP mode. All the below work in hanna in PHP and text mode

[piranha]{piranha}(piranha)

Sorry for digression

Edited June 4, 2013 by kongondo

[apeisa]

Is this comprehensible? (I might be able to dig up the very old prototype and post some screenshots)

And what do you think of this idea?

I like the idea, but would love to see some screenshots to make concept more clear. Not sure I totally understand how this would behave?

[Wanze]

I'm not sure if I understand.

Do you mean something like modx revolution does with snippets? When you drag a snippet to a textarea, a popup appears which lets you specify all the options of the snippet per UI.

[mindplay.dk]

There's no drag and drop... hmm, this is hard to put in words, I should dig up that prototype and post it somewhere...

[mindplay.dk]

Okay, I found this old prototype and it's not so easy to deploy for various reasons, but I got it running locally, and here's a screenshot:

This implementation used in-place editing, so the ugly crap in the background is a webpage, and the editor in front is editing the content (which is markdown) in the main content area.

As you can see, the placeholders {fish} and {cat} appear on the list on the right, as you're typing - and this doesn't work or was never fully implemented, but imagine the "+" icons would pop open another dialog that lets you select a "macro" and configure it... simplest possible example would be an "image" macro that lets you upload an image and simply substitutes each placeholder for an <img> tag.

I don't know if that really clarifies anything...

[kongondo]

It does clarify things, thanks for posting.

Once you've configured the macro, does the placeholder then get replaced or it stays in place?

[mindplay.dk]

The placeholder is replaced when the content is rendered for display - it can't be replaced while you're still editing in a textarea or WYSIWYG.

In this old prototype, the markdown is actually rendered on the client-side, in real-time, while you're editing - and so it would have been able to make the substitutions in real-time, but that only works because you've got the markdown source in a popup, separated from the actual view.

It might could work with in-place editing - you would need something like Aloha editor, where you can make certain areas of content editable, so that the rendered macros would not be editable in-place. I'm not sure if this would ever work in IE though.