Front end content editing

Adam,

Good job on the new fixes for the Front-end Editing. As far as names go I think I prefer "Inline Editing" but that’s just me

The new format tat you have proposed will most likely cause confusion when we roll out TVOs. Sometime ago Jason came up with the idea of converting TVs into objects using the [*tv|functionName:parameter*] format. Now consider this [*tv:editable|functionName:parameter*].

IMO I think for something like [*#tv*] we only have to check for the first character in the name to see if it’s a "#" then process accordingly. The mergeDocumentContent could then be modified to remove "#" from tv name and process them accordingly. This means that if someone decides to remove/disable the plugins there pages will still work.

Here are some other formats that we can choose from to represent editable tvs:

[*`tvname*]
[*!tvname*]
[*@tvname*]
[*$tvname*]
[*&tvname*]
[*-tvname*]
[*+tvname*]
[*~tvname*]
[*?tvname*]
[*/tvname*]
[*^tvname*]

What do you think?

Could we have a double-star? [**tvName*]

Sounds good to me. I wasn’t aware of he TV/Object paramaters. I’ll make the change to use [*#tvname*] tonight and post my changes. Or if anyone else likes some other syntax better that’s fine with me too.

BTW, you may want to take a look at my recent code. I’ve made some changes for caching sake so that now there are two differnt specific times that the output has to be manipulated. One is before any of the other merge functions are run and the document is cached, which is what you’ve already developed I assume and the other is just before the content is actually rendered after caching. This is because we can’t have the edit links being cached so we have to cache a comment in it’s place and then replace the comments with the links before rendering.

So you may have to create another event or maybe you can think of a better way to handle it?

Quote from: rthrash at Jul 29, 2005, 09:02 AM

Could we have a double-star? [**tvName*]

We could use the double star but I could see it being a bit more problematic in the code. Also what are you going to do for non-caching TVs? [!*tvname!] or [!!tvname!]?

Do you mean non-caching snippets?

Quote from: aNoble at Jul 29, 2005, 09:12 AM

We could use the double star but I could see it being a bit more problematic in the code. Also what are you going to do for non-caching TVs? [!*tvname!] or [!!tvname!]?

Yeah, I pefer we use some other format than the double star.

As for cache we can leave that out for now. We have to be careful not to flood users with too many parsing formats but we can consider the [!*!] options for future releases. This again depends on what the developers decide.

The core will take care of caching in TP4. There will no longer be any need for [!snippet!] to indicate cacheable snippets. There will be a Cacheable checkbox on the following resources snippets, chunks and tvs

We will still allow users to handle snippets via [!!] but new formats for the other objects would have to be carefully thought out.

Sounds good to me. I was getting the cacheable stippets and TVs confused. Using cacheable checkboxes on Snippets and TVs sounds like a great idea to me.

Quote from: aNoble at Jul 29, 2005, 09:55 AM

Sounds good to me. I was getting the cacheable stippets and TVs confused. Using cacheable checkboxes on Snippets and TVs sounds like a great idea to me.

(whisper)
The cacheable checkboxes thingy was Ryan’s idea. He doesn’t like the techie [!!] stuff and I kind of agree with him

Now this brings up a thought... what if we just got rid of the distinction between them altogether and have the parser be intelligent enough to know if there’s logic then it’s a snippet? Or we could have a checkbox in the resource box header:

[ x ] parse for logic

The above would mean treat as a snippet, otherwise treat as just a chunk.

This also brings up one more thought. I thnk it would be very handy to standardize on some (optional) header format for snippets/chunks. That way when they’re inserted or installed in the to-be-done installer, it could automagically parse the header info for the snippet name, description, caching requirements, author, copyright, contact info, etc.

Good ideas?

I like the idea of having "header" information associated with snippets/chunks.

I don’t know if having the parser automatically figure out the difference between snippets and chunks would work, the real problem would be if a chunk happened to be javascript. Differentiating between HTML and PHP is doable but differentiating between PHP and javascript could be extremely difficult. One way we could get around it would be to just require the use of <?php ?>. If this would work fairly well from a programming standpoint and performance wise, I think it would be a good option. We would really be combining snippets and chunks into one thing that could be a snippet, a chunk or a hybrid of both.