What is your favourite syntax for including a plugin on a page?

[Zegnåt]

Was working on a plugin and was thinking about this.

There is Dominion style:

Code:

(% pluginName : commaDelimitedString %)

There is SquareIt style:

Code:

{pluginName_string}

p01’s DokuWiki style:

Code:

{{ pluginName : commaDelimitedString }}

Whitespace should be ignored by the parser when possible, so the “commaDelimitedString” can use line breaks and spaces.

Which syntax do you people prefer? Do you maybe know of a better syntax, maybe used by a different platform?

Let’s see if we can come-up with some kind of user standard for our plugin authors to use.



Edited to add DokuWiki style, adapted by p01.

[p01]

Good idea to standardize this.
I was wondering too.

Actually i have used "dominion style", although I dislike these percents, because I thought it was the GS standard.
The second one seems to me too simple, the plugins syntax have to be recognizable and not interfere with normal writing (if I want write a word between {}, I have to avoid all plugins names?).

I like dokuwiki syntax :

Code:

{{plugin>options&options&options}}

Who can be more clear :

Code:

{{plugin : comma, delimited, string}}

With possibility of formatting as necessary :

Code:

{{plugin : writing, options, in,
           multiple,
           lines,
           for,
           readability}}

[Zegnåt]

Added to the topic, thanks for your input.

[Oleg06]

Yes, a lot of plugin developers, they replace each other, some quit their jobs are not completed yet, it would be nice for them to work once in one direction, because some plugins just break other plugins

[JWH_Matthew]

I personally like using Dominion style.

Although I don't know how to write a plugin to utilize it, I think this looks the best and I personally have never needed to use '(%'.

[Zegnåt]

Although I don’t know how to write a plugin to utilize it

I’m thinking of writing a parser function that people can just use for plugin development. But I’d like us to settle on a certain format first.

Too bad this forum doesn’t allow for polls.

[Knitter]

I don't really like any of that, why do I need another language, and whatever plugin syntax you choose you're creating a new language, to produce output that PHP can easily produce?

If you're thinking of template system, there are already a lot of them that can be used, why invent a new system? If it's not template related why do I need such a syntax?

I tried the contact plugin that's more recommended around here and the syntax is just strange, why use something like (% contact %) when I can just instantiate the contact object, set it up and call some method on it that shows the contact where I want?

What is the real, measurable, advantage that using such syntax/system offers?

[p01]

I don't really like any of that, why do I need another language, and whatever why use something like (% contact %) when I can just instantiate the contact object, set it up and call some method on it that shows the contact where I want?

What is the real, measurable, advantage that using such syntax/system offers?

Hi,

The main advantage of a tag system is to allow non-developers to instanciate and manipulate plugins without open, understand and edit source code.
Main part of users will not have the time, desire or skills to write code but will be able to write a simple tag in a page.

For example, the majority of websites using p01-contact have the most basic use of it. Clearly, without the tag system, many of them would have not integrated it.

[Knitter]

That's a view I often get from other developers but that have yet to see proven. As an example, with is the difference between (% contact %) and $contact->show() or simply showContact()?

For someone who doesn't know code, any type of code, all three options are new, all three options require learning, all of them are code, either we call them tags or not they are following a predefined syntax and produce some output if used correctly. There is no difference, to someone who doesn't know how to use a programming language between using a tag or using a method that is explained in the plugin documentation.

In fact, such a person doesn't need to understand what a programming language is, just what to write in order for the form, in this example, to show in some page.

Tag system for configuration options is just overhead, use simple HTML controls that everyone can understand, that's what they are there for. If we are talking about using the output of some plugin in a template then I see no use for a tag system.

Don't get me wrong, I can understand a need for a tag system, I just can't see any use for it in GS. If GS needs a tag system, so that plugins use a standard set of tools, then there are several systems already created, no need to invent one. And if the tag system is target at non-developers, where are they going to use it? They will either create the template, and will have to understand PHP to do so as GS templates are PHP files, or, if they are using the tags in a page content then a simple tag provided by GS would be enough.

Nevertheless, I'm not against the creation of such system, and it's inclusion in GS. I was just voicing out that I really can't see a benefit in this feature, more to the point: what is gained doesn't seem enough to cover what is lost/spent. Maybe I'm just not understand the all issue.