New feature to easily edit in place

[xavier]

If you have used flickr or facebook, you know what I'm taking about: you click on some items on the page (say the title of the picture) type it and enter, voila, you have updated the title without leaving the page, without going to any form

Thanks to the good folks at PTP, we have made good progress in that direction
http://issues.civicrm.org/jira/browse/CRM-9798

To make it work, you need to put to information in the page: what's the entity to modify (can contain one or more fields), and what's the field(s) that users can modify

say that you want to let users modify the job title directly in the summary page

1) add somewhere (as high as you can in the dom)
<div id="contact-{$contactId}" class="crm-entity>
For that you can re-use an existing div, for instance (what I did) the one on line
126: <div  class="crm-block crm-content-block crm-contact-page">

so id="entity-id" eg. contact-42 or activity-123 and the class is "crm-entity"

you put is as hight as possible because it can be used by several "fields"

2) and around the job title
<td class="crmf-job_title crm-editable crm-contact-job_title">{$job_title}</td>

Here as well, it's re-using an existing dom element (the td this time). The important classes are
crmf-{fieldname} (note the crmf- for fields) and crm-editable, to say it's editable


Once that's in place you need to activate the magic:

Code: [Select]

{literal}<script>
  (function($) {
    $(function(){
      $('.crm-editable').crmEditable();
    });
  }(cj));
</script>{/literal}
crmEditable (defined in js/rest.js) contains several options, like 'success' a function to call when the field has been saved on the server (so you can change other parts on the page, display a custom "saved" message...)

To note: it's using crmAPI in the background to save on the server, it's assuming the API to modify the entity exists (and works to modify a single field) and by default, assume your civicrm install is at the root of your domain

The url to call for the ajax rest can already be configured, but we are working to make it even more transparent

Still to do:
1) use it on more pages on civicrm where it makes sense (can work as well on tables, like search results)

2) use it for different types than a simple edit text. the underlying plugin (jeditable) can work with select (lists of options) and so on, that's "simply" a matter of adding it to crmEditable

And any help more than welcome...

X+

[Donald Lobo]

We are also adding inline edit for the email and phone fields to v4.2. We should ensure that the survey "profile" inline code and the contact edit form use the same code and standards

lobo

[xavier]

Kurund and I irced a bit about it.

They are two options for "complex" entities (eg email having the email, the location type, if it's for bulk email...)

1) the "real" edit in place
In that case, each 'field' is handled separately, and you would edit the email (john@doe.com) and save it and change the location type and save it.

Con: you have n (simple) requests when you modify n fields of the same entity
Pro: it's a direct access for every field and faster
IMO makes sense if most of the change modification are only for one field (eg only changing the location type, or only changing the email)

that's this edit in place I'm describing here

2) the "dialog/pop-up"
you open a pop up to modify all fields in one go. That's pretty much the existing interface, but it saves to have to load a new separated page for the form, save and go back to this page
 
Pro: it offers a "transactional" commit/rollback (ie. if you change both the location type & email, it will save/not save them together).
Pro: it is somewhat less resource intensive on the server if several modifications
Con: IMO, it doesn't offer as many benefits over the "normal" forms (based on my experience with the drupal overlay module that is the first thing I disable when I install D7).
Con: pop-up/dialogs don't work anyway with big forms (eg. if height>screen, it's weird)

So 1) is pretty much the only option if it's a really complex entity (eg contacts).

3) another UI option is grids like (like a spreadsheet). Works quite well if you have tabular data (or as an improved version of batch update)


Anyway, if you want to use 2), we got a few things in place

$().crmForm('url') that ajax load the form, ajax saves it and trap the result (used on the wrench on the profile edit on trunk.profile). Will do a separate forum post

The "quick/smart & easy way" IMO would be:
http://svn.civicrm.org/civicrm/branches/trunk.profile/templates/CRM/Contact/Page/Inline/AddEmail.tpl

1) create a template(bit of html -part of the main page but hidden) with the fields being the same name as on the api (eg email location_type_id...)
a) use the {crmAPI to define the select (eg list of locations) if they are simple to fetch
b) use $().crmAPI if too complex/expensive to load (or too dynamic)

and use  $().crmAPI() to "submit" the changes on the server and get a json that says if it worked or not and use it.

REM: this assumes simple enough validations (eg. mostly mandatory fields/format) the API error messages aren't (yet?) super advanced

If the form can be used in several places (eg. several emails on the same summary contact), it can use mustache to replace the variable data (id, email...)

Benefits: it's instantaneous to click to edit, fast to save and it needs 0 aditional lines of code

[Eileen]

So, say we wanted to make the 'title' field editable on the manage event screen while @ the sprint, (assuming it's in trunk by then) what would be the steps?

[xavier]

on the template where you want to edit in place (say templates/CRM/Event/Page/EventInfo.tpl )

add in a dom near the top (where the event is)
<div id="event-{$event.id} class="crm-entity vevent crm-block crm-event-info-form-block">

and where the title is displayed
<div class="crmf-title crm-editable">{$event.title}</div>

and run the script to initialize the edit in place (it would need an extra test to see if the user has the right to edit the event around it so it does it only for admin users)

Code: [Select]

{literal}<script>
  (function($) {
    $(function(){
      $('.crm-editable').crmEditable();
    });
  }(cj));
</script>{/literal}

If the title isn't displayed in the template itself but set in the h1 by the CMS, you'd need to use jquery to add the crmf-title and crm-entities so it'd be something like

Code: [Select]

<script>
var event_id = {$event.id};
{literal}
  (function($) {
    $(function(){
      $('body').addClass('crm-entity').attr('id','event-'+event_id);
      $('h1.page-title').addClass('crmf-title').crmEditable();
    });
  }(cj));
</script>{/literal}