Need Community: new Field Tags Module

[Adam Kiss]

Hi everyone,

today I just got so angry with me not releasing anything, even though I work on multiple things, that I just pushed to my Github repository this new module I've been playing with.

It adds the ability to hook onto Textarea as Textformatter and upon loading, it parses the textarea and replaces parts enclosed with double curly brackets with respective tags. Tags can have multiple parameters, even though final syntax haven't been selected yet.

The last (major) problem I currently have (besides this isn't module yet, only working PHP Class) is how to provide extensibility without having developers to touch the code of the Module–Ideally, without having any file in the site/modules/ directory to customize.

The current 0.1 code can be found here: https://github.com/a...ter-ProcessWire

Edit, 16.4.2012: Hillariously, Diogo had created something solving the same problem here: . To be honest, I feel like my solution is (possibly) more robust, even though Phillip's is a little further, as it already works.

I will take it okay, if you'll thinking this is too much, and Diogo's solution is enough, as there is little point in having two modules this alike – granted, one's functionality is subset of the other's, but still.

Diogo, if you went further with your code then it's currently shared, I'd like to give the Class already written to you (if it helps). If not, I would be glad if you could join me in creation of this robust, configurable module.

[diogo]

Adam, I'll be away from the computer for two days, starting in 2 minutes. Feel free to copy what you want from my code, use it on your module, and make the result the official one. When you finish it, feel also free (as administrator) to edit my thread and remove the file

[Pete]

Edit, 16.4.2012:

Have you moved to Australia or have you been working on a time machine recently?

I know, unnecessarily picky

[Adam Kiss]

Have you moved to Australia or have you been working on a time machine recently?

That's what I got for being lazy to edit...

Anyway, Pete, Antti, Ryan, and others... any ideas? I'm baffled mostly with the custom functions part, how to let sitebuilders extend this, nicely.

[ryan]

Looking good Adam! I replied in Diogo's thread something that may be more applicable here:

That link mentions referencing other pages with a tag. So one way to make tags extendable is by tying them to a page and rendering the output of the page. I think there are cool possibilities there, but don't think it's enough...

If we're going to have an extendable tags system, it probably needs to be a module that other modules can add hook functions to, and they become tags. It would utilize the existing hook system. That way another module could add a {subpages} tag by doing something like this:

public function init() {
   $tagscript = wire('modules')->get('Tagscript');
   $tagscript->addHook('tag_subpages', $this, 'subpages');
}

public function subpages($event) {
   $page = $event->arguments[0]; 
   $children = $page->children();
   $out = "<ul class='subpages'>";
   foreach($children as $child) $out .= "<li><a href='{$child->url}'>{$child->title}</a></li>";
   $out .= "</ul>";
   $event->return = $out; 
} 

As for format of tags, I think it may make sense to use the existing selector format already used elsewhere in PW. There is already a built-in parser for it, it would be consistent, and it could pass the params in the selector directly to the tag event in the $event->data array. So an example of a tag would be this:

{subpages: limit=10, include=all}  

...and the tag_subpages function would retrieve them like this:

$limit = 0;
if(isset($event->data['limit'])) $limit = (int) $event->data['limit'];

Further along, we'd also want to be able to do this for markup independence:

{subpages: limit=10, include=all}
<li><a href='{url}'>{title}</a></li>
{/subpages}

I have a parser that does that that I was working on awhile ago. Might be time to resurface it.

[Adam Kiss]

Interesting idea with the extendability via the Hook system–that also solves the problem I had – You basically only create a file, let our module know that it has some hooks avail. and add that module to PW... Great idea!

Now:

• How do I make the plugin hookable?
  
• How do I make the syntax blocks?
  
• Do we want to support this also in template files?
  

I think You've mentioned you have the first two things solved already, could you send me the code? (Ideally, could you fork the GitHub repo, create dir _ideas and move your files there?)

Regarding the third one, I thought of this as a way to easily mention field from inside of other field, so you don't have to split your blog posts or create your own tags. But how do we support it in template files, when you have so many ways of creating your template files?

[ryan]

How do I make the plugin hookable?

Any class method preceded with 3 underscores is hookable (assuming it extends a PW class like Wire or WireData). So just make your method name ___myFunction() rather than myFunction(). Use just myFunction() (no underscores) when you call it.

How do I make the syntax blocks?

I don't understand the question?

Do we want to support this also in template files?

Not easily done since PW include()'s templates rather than eval()'s them. Meaning, PW can't modify the template before executing it. The way it could be done is by using compiled templates where a compiler converts tags in a template file to PHP code and then saves it as a compiled template. PW then includes the compiled template rather than the original. It's something we'll probably eventually support, but it's a little complex.

The other option is hooking into Page::render and replacing tags from there. But that's not ideal because you don't really know where those tags came from at that point. They could have come from user input (like a comment). So you lack the ability to filter at this stage.

I think You've mentioned you have the first two things solved already, could you send me the code? (Ideally, could you fork the GitHub repo, create dir _ideas and move your files there?)

It's a PW class that I made 2 years ago, before PW was even released, and I haven't looked at it since then. I just took a look at it now, and it's not in a state where I think it would be helpful or functional. I'd made it as a proof of concept to revisit when the time came to support EE style loops and open/close tags with embeded markup. But that's all it does... it's not an actual tag engine. It's just notes to myself on how a markup embeeded tag might work. I'll still send it to you if you want it, but realize that: 1) it is not a functional module, and 2) It's been awhile, it's a mess, and inexplicable at the moment.

[Adam Kiss]

By the block syntax I meant this:

 {% blocktag: param1=value, param2=value %}
 {% /blocktag %}

I think I should be able to capture this, I just thought you have the code ready for this already, that's why I just asked how to do it; I think that one ungreedy regexp with two capture zones could be okay for version 1 (one simple ungreedy regexp could not deal with stacked/multiple tags of the same type)

Regarding the hookability: Ryan, can you provide the crudest possible way of doing this with Textformatter, please? thank you!

[ryan]

I think I should be able to capture this, I just thought you have the code ready for this already, that's why I just asked how to do it; I think that one ungreedy regexp with two capture zones could be okay for version 1 (one simple ungreedy regexp could not deal with stacked/multiple tags of the same type)

Regexp is definitely the easiest way to go here. You could do it with just string functions, but it would be a pain for sure. As for the block syntax, I would suggest that simpler is better. People will use them if they don't have to remember too much, so something like {tag} or even {{tag}} is I think easier to remember than {% tag %}.

Regarding the hookability: Ryan, can you provide the crudest possible way of doing this with Textformatter, please? thank you!

I'm not sure that I understand -- do you want to hook into a textformatter's format() function, or do you want the textformatter to hook into something else?

[diogo]

Adam, is there anything new on this? Just referenced this thread on the other module page (no URL because it still has to be approved by Ryan)

http://modules.processwire.com/modules/textformatter-image-tags/

[Adam Kiss]

Currently, no.

I've had just too much stuff going on, but that will (hopefully) change soon - I'm slowly trying to transform myself from 'work until 120% done' to release small, release often.