SNEAK PEAK: Combined Snippets + Chunks = Snippets

That would be really handy. I have a few snippets I use that could easily be converted to Plain HTML with this method. It would be really handy as shorthand for more comlicated html like embedded flash or PDF objects.

Quote from: rthrash at Aug 17, 2005, 09:56 AM

LOL

Raymond, that is too cool and too helpful!

lol

The problem here though Ryan is that once we start doing stuff like that we can no longer call those snippet’s "static" HTML blocks. They can even be made into none cacheable html snippet blocks

Quote from: xwisdom at Aug 17, 2005, 10:03 AM

The problem here though Ryan is that once we start doing stuff like that we can no longer call those snippet’s "static" HTML blocks. They can even be made into none cacheable html snippet blocks

FWIW, I disagree-- nothing gets executed, it’s just substitution. To me, it’s just like how you can include another chunk of HTML by having a [[anotherTag]]. (Which we already allow.)

BTW, regarding "Access Permissions": Both Raymond and Ryan are correct. If a Snippet is set to execute in the manager, you have to possess the correct assignment to see the Snippet on the menu or to run it. On the frontend you have to have the correct assignment before the snippet executes or returns content.

Access Permissions are Document Groups and User Groups. So, for instance, if you have a User Group of "Editors" that gives special control and/or allows access to unpublished pages, you would set that Snippet to "Editors" and can place it anywhere on the site without having to worry about it be accessed by the wrong sort of folk.

Hopefully that makes sense to everyone...

Quote from: infoclipper

FWIW, I disagree-- nothing gets executed, it’s just substitution.  To me, it’s just like how you can include another chunk of HTML by having a [[anotherTag]]. (Which we already allow.)

You’re correct nothing get’s executed it’s just subsituted or processed text. The point I’m trying to make here is that the output for some of these html snippets is directly dependent on their inputs. This means that the snippet’s output will vary based on the user’s input thus making it’s content dynamic.

Maybe we need a slightly different terminology, or use "non-logic" HTML as the terminology.

Quote from: rthrash at Aug 17, 2005, 11:50 AM

Maybe we need a slightly different terminology, or use "non-logic" HTML as the terminology.

Well, IMO there are really two types of snippets - PHP Snippets and HTML Snippets. It does not get any simpler than that. PHP Snippets used php code to render an out while HTML Snippets uses text and placeholders to render an output.

I’m fine with dynamic.

I think it’s one of those advanced features that 99% of the people will never use and never know about. But if we document it someplace, the 1% that will use it will think it’s the niftiest thing ever. And, as Adam pointed out, it will allow him to change some of his Snippets from executable code to dynamic HTML, which will be much more efficient as we avoid the eval() just to swap in some text. As it turns out, I also have some immediate projects that could use it.

Which brings me back to the Properties tab. Would anyone mind too much if I tweaked the way it displayed/allowed input of the parameters? The way its stored is fine, but I would like to make the front end editing/addition a bit more polished. Sort of like how you can maintain the parameters once you’ve created them, but allow you to make them the same way. Shouldn’t change anything with the way they are stored in the DB or the operation thereof.

Any objections?

Quote from: infoclipper at Aug 17, 2005, 12:05 PM

Which brings me back to the Properties tab.  Would anyone mind too much if I tweaked the way it displayed/allowed input of the parameters?  The way its stored is fine, but I would like to make the front end editing/addition a bit more polished.  Sort of like how you can maintain the parameters once you’ve created them, but allow you to make them the same way.  Shouldn’t change anything with the way they are stored in the DB or the operation thereof.

Any objections? 

I guess this is my call - No objections

FWIW, the original design is very restrictive but was the easiest way to get something going. It was design for codes not users which is kind of a bad thing to begin with.

What I also had in mind was to separate the jscripts from those pages into a javascript file to make it reuseable accross other manager pages.

Quote from: xwisdom at Aug 17, 2005, 12:22 PM

What I also had in mind was to separate the jscripts from those pages into a javascript file to make it reuseable accross other manager pages.

Already in progress; I’ve dropped at least half the JS from the manager already and am consolidating like mad.