Easy Snippet UI / Snippet model

Just a thought... (maybe it’s already there but I still don’t have a clear picture of all that modx can do )

What if we would create a standard way/model of knowing for which parameters a specific snippet can take.
Like each snippet has an added variable with parameter naming, description and how parameters can be combined (like parameter2 can only be used if parameter1 is set to " 1").. something like how the module interface works now .
If we agree on a format it’s possible to create plugins for the HTML Editor/Textbox to use some sort of click&play interface which inserts snippet tags into templates/documents.

Example to illustrate:

instead of typing: [[Snippet &par=`this`&par2=`that`&par3=`what`]] in the content field.

- You click on "Insert Snippet" in the content/template editor
- Choose the snippet from a list of available snippets
- Set the parameters by using a generated setup dialog (by using the snippet parameter model)
- Set the snippet to cached or uncached
- Click DONE

and the code is added.

edit:

also possible to add something to the html content editor parser that will filter the "[[Snippet]]" format into a snippet icon; when clicked on displaying the Edit Snippet Parameters dialog.

Something like this allready in progress: TinyMCE plugin - insert snippet from the tinyMCE toolbar

But yea, some guidelines are needed to make the plugin to be able to get available snippet parameters/defaul values/etc for each snippet.

Quote from: doze at Aug 21, 2006, 05:33 AM

Something like this allready in progress: TinyMCE plugin - insert snippet from the tinyMCE toolbar

But yea, some guidelines are needed to make the plugin to be able to get available snippet parameters/defaul values/etc for each snippet.

Yeah that’s exactly what I’m talking about, thanks for the reference (missed that one).

I’d really like to discuss such a model/standard for snippets (and i’m a big fan of storing such information into an xml string)

Agree, and there’s been some discussion recently of an edit view that would actually require something like this.

bs is right that the module interface has a parameter section which could be adapted for snippets / snippet instances:

ie variable=label;type;defaultvalue

And that’s already pretty good, because it’s copy/pasteable. I see no benefit in an XML string, it would simply add bloat. However, it should be the same as the module parameters and if that moves to XML then it would make sense to change in line.

The part:
Quote from: bS at Aug 21, 2006, 05:26 AM

and how parameters can be combined (like parameter2 can only be used if parameter1 is set to " 1")

is more awkward. This would mean adding conditions:

which would presumably then be used to show/hide options accordingly. It would be nice to have, but probably not necessary for the first release.

i have the (bad?) habit to xmlize configuration stuff lately

I don’t care how the "string" will look like eventualy, however from a developers point of view I find editing and viewing an xml object more relaxed than a string of &,= and ;’s

also agree on your opinion on the condition part.. i’m just illustrating where it could go eventually.

imho, we need a standard for defining a snippet (name, version, description, parameters) pref. from the code itself, ea. once at install (after this it’s put into a column of the snippet table, and later on maybe even edit from the manager) ofcourse keeping the possibillity for quick’n’dirty method of writing simple snippets. It’s up to other elements of modx what to do with the provided parameter data. One certain implementation would be the snippet gui in the editor.

Agree on Version. I’m currently tending to put that at the beginning of a description. I note that much of supplied content includes .

I believe that OpenGeek’s vision for MODx 1.0 sees all snippets/chunks/modules being essentially the same thing. There is versioning within that, but that’s more of a "version 2, version 3" rather than "1.0, hacked version of 1.0, 1.1" etc. A version-label field will be useful - theoretically it could also be checked by a dependent snippet to ensure compatability - eg DittoCal might need Ditto 1.02 or somesuch.

All in all, I think this area is definitely something to return to once 0.9.5 is out the door and we can decide what work is worth completing for 0.9.x and what is worth designing for 1.0.

Thanks for stirring this topic up again. It’s been a long-standing thing I’ve wanted to address, and now it seems like an appropriate time to bring it back up (post 0.9.5, that is).