Lingo-ology

I don’t think we should get rid of all the different tags, but I do think we can reduce them down to snippet/chunks being [[ ]] or [! !], TV’s and content being [* *], and placeholders/config settings being [+ +].

Quote from: OpenGeek at Nov 08, 2005, 10:50 AM

I don’t think we should get rid of all the different tags, but I do think we can reduce them down to snippet/chunks being [[ ]] or [! !], TV’s and content being [* *], and placeholders/config settings being [+ +].

Hmm,

You think we should merge site settings tags with placeholders?

We definitely need to keep [[ ]] and [! !]. We could combine [+ +] and [* *] but I don’t mind keeping them separate either.

What do you say we lose [~ ~] and make it a snippet/plugin?



Remember, we could easily write a backwards compatability plugin for a lot of this, so that we wouldn’t have to break templates/content with the old tags.

If they can be easily made available as needed, I don’t see a great reason not to do so.

Regarding the caching syntax of [[ vs. [!, I really am in favor of making that an automatic thing that can be set by a developer as a flag in the plugin (formerly snippet).

For example I don’t understand the fine distinction of why the menus don’t require [! calls and get cached when new pages are added, but a weblogin or contact form does. Omitting (or going overboard with) [! calls is an easy thing to do!

Quote from: aNoble at Nov 08, 2005, 10:54 AM

What do you say we lose [~ ~] and make it a snippet/plugin?

[[Link?id=123]]

Remember, we could easily write a backwards compatability plugin for a lot of this, so that we wouldn’t have to break templates/content with the old tags.

Existing [~ calls could be aliased internally via a "legacy compatibility plugin-module" to the new format via some simple regex as placeholders are set now.

We could also put a bunch of deprecated document parser functions and APIs in an extension to the base document parser class. Optimized/updated sites could run faster, while still maintaining legacy compatibility as neeeded.

This could also give us the opprotunity to rewrite/overhaul much of the API without breaking existing sites.

Or is this more of an undertaking than I’m thinking?

Quote from: rthrash at Nov 08, 2005, 10:56 AM

I really am in favor of making that an automatic thing that can be set by a developer as a flag in the plugin (formerly snippet).

That’s an interesting idea. I don’t think it would be very difficult to implement either. But I think it should be specified as a checkbox in the snippet/plugin instead of in the code. That would probably be better for performance. Plus some people may want to change it.

For instance, I may want to cache my menu and choose to refresh the cache whenever I add or delete a page. Or I may want it dynamic and not have to worry about refreshing the cache.

I’m all for simplifying, but let’s not take away features. I like the flexibility of calling a snippet/chunk/etc. as cached or uncached in different places. And I don’t think the link snippet thing is near as convenient as [~~]. Just me...

And the legacy plugins would just add overhead to support my syntax preference...

Hmmm,

I think I lik the [~~] more than [[Link?id=123]]. It’s much easier to write

So as it relates to tags:

[[Plugins]]
[+Placeholders+]
[*ContentFields*]
[~DocumentIDs~]

I’m thinking that we should still keep [()] separate as there might persons using things like [+email_address+] as a placeholder. What do you think?

Was thinking all the settings accessible via [( )] would become placeholders...some of them might need to be renamed to avoid conflicts with common placeholders like [+email_address+]

Agreed that it should be an overridable checkbox for caching, and that the benefits of lower support inquiries by putting developers in control of the caching parameters instead of altering how it’s called outweighs any slight perception of lost controll. 90%+ of the people I’d estimate would never be the wiser, and I can’t really think of an instance when you’d like to call the same plugin cached and non-cached in the same site. The workaround there (for the greater good), is a duplicate copy of the plugin in quesiton, one cached, the other not.

I think a release announcement containing the following is the way to spin it:

Automatic caching -- never worry about clients calling plugins (formerly snippets) improperly again by putting you in control of the caching parameter on the plugin page

I do like being able to call links in the convenient [~ format too, though... that’s probably worth keeping around in the main document parser class. Athough if I had never used it before I wouldn’t miss it and it would make the learning curve shorter for new users. I’m ok either way on this one.