Quickedit Integration Ideas

Quote from: MadeMyDay at Aug 03, 2006, 05:32 AM

Would it be possible (in combination with quickedit) to - somehow - edit the entries of a ditto listing via quickedit? Reason is I often use ditto to show a list of content items which are not accessible as a detail page. So the only possibility to edit their content/TVs is via manager. So one possibility for editing could be a parameter passed to the ditto call (eg. &editable=1 &editgroups=administrator) and then I have edit symbol/link (perhaps placable via placeholder in the ditto tpl) from where I can edit its content. Of course it would be possible with a snippet which displays edit links in the listing only for administrators, but I think it could well be integrated in ditto itself.

Editing document content with Ditto and QuickEdit seems simple. I think it’s easiest to first see how you could add these links in with a custom template, and then look at how it could be "integrated" into Ditto itself.

The following Ditto template chunk code works to add QE edit links to a document title.

By default this is hidden, but the QE routine changes the style of QE_Link. Or something like that.

So. How could Ditto automate this?

Method 1: MODx Consistency
If I wanted this Edit link on the title of an actual document, I would add # to the name.

Therefore it would be consistent if you could pass to Ditto in the template:


(There is an issue here, and that is that "title" isn’t the name of the field that is being picked up, and for Ditto’s various "pick best available thing" fields like "summary" it is questionable which field should actually be edited. I shall sidestep that for the moment.)

Anyway. Upon finding a variable that starts #, Ditto would know to plonk something like
at the end.

Ditto could also check to see if QE is initialised, rather than outputting hidden links to everyone.

Method 2: Just the edit button
Like the above, except the template would contain:

ie anything that starts ## would result in Ditto plonking out the equivalent of at the specified place but without the actual content, thus the edit button could be anywhere and you could also have an edit button for TVs that aren’t displayed (useful if they are being used for filtering but not displayed, for example).

Method 3: Both 1 and 2
You’ll note that one uses # and t’other ##. That would enable both methods to coexist.

Method 4: Alternate Template For Manager Users
Could be used with 1 and or 2, but would basically be an over-ride template. I’m not convinced this method should be in Ditto itself; this could be better done with a snippet that used editgroups and conditionals to determine which Ditto call to make.

Method 4: Inline AJAX editing
Instead of using QuickEdit, ### could turn fields into form fields which could be edited and saved using AJAX.

I’m happy enough with Method 0: Bung Some Javascript Links In An Admin-Only Version Of The Template.

Mark, what method were you trying?

EDIT: Just realised I didn’t state two things about my methodology.

Firstly, I see this as a template issue not a snippet variable issue. It is important to be able to decide which TVs a user can edit.
Secondly, the javascript call to QuickEdit omits the highlight-content bit because the hassle in getting that to work outweighs the slim benefits.

Up until the next version I had no way of detecting the # prefix to add the code. Now, in 1.1 I do.

Hurrah!

Yeah, the "ditto just has to understand the # prefix" was a bit of a leap (although not as much of a leap as Method 4).
That’s great news that you can cope with that in 1.1.
Does that mean this all falls into place now?

#1 Yes
#2 Possibly
#4 I wish but I have no idea how to code that...

RE: #1: Current Quickedit links are rendered as "Edit: Field". Does it make sense to render Ditto QE links as "Edit: Pagetitle : Field" where Pagetitle is the pagetitle of the current Ditto item? Or should this be another field?

That’s a good question. Personally I think it will be sufficient to just say Edit: Field, as that way things would line up nicely.
I wouldn’t want one button saying "Edit: Penny Lane: Content" and the one below saying "Edit: There’s A Guy Works Down The Chip Shop Swears He’s Elvis: Content".

Having said that, if you want to go down that road, I think that pagetitle is a reasonable assumption for the default. However, I’m sure people would ask if they can change it, so it’s probably worth letting people specify the field used for the prefix (or no field).

There’s a situation where any of the following would be the best:
&QEPrefix=`id`
&QEPrefix=``
&QEPrefix=`menutitle`
&QEPrefix=`alias`

but as I say pagetitle is the most commonly filled out field and should be the default.