Note: for those of you who do not mind modifying your component, skip this section and go to Approach 2.

Here we are going to make the assumption that you are not the developer of the component and you want to add inline editing support, or you do not want to modify the code of your component.

In either case, we are going to have to utilize Joomla’s event based plugin system, namely content plugins, to get the job done.

In most cases, components will fire off the onPrepareContent and onAfterDisplayContent events, when they are displaying content for their item detail and category type views. However, if this is not the case in your component, you will need to skip this section and go to the next section below.

The inline editing framework provides an event listener handler, for those events for components wanting inline editing support, for their defined types.

In our MyCCK component, we fire off both the onPrepareContent and onAfterDisplayContent event, for our item view. And only the onPrepareContent, for the blog category view.

Okay first, we are going to create a directory structure as follows:

+files_inlinemycck   [FILES_INLINE + COMPONENT NAME]
|
------+extensions
|
---mycck.php  [COMPONENT NAME]
|
------+contexts
|
---+mycck            [COMPONENT NAME]
|
-----category.php  	[TYPE NAME as explained in XML]
|
-----item.php        [TYPE NAME as explained in XML]
|
-----blog.php        [TYPE NAME as explained in XML]
|
index.html
|
inlinemyck.xml  [INLINE +  COMPONENT NAME].xml

Do not worry about the content you need to put into the files for now, that will be explained in detail later. For now, just create the folders and files for your component.

The only file we need to concern ourselves with in this section, is the mycck.php file.

In this file, we are going to add two methods:

1. prepare.
2. display.

The names of these methods match the names of the Joomla’s events: onPrepareContent and onAfterDisplayContent. And as you probably guessed, these methods will be called respectively, with their namesake Joomla events.

So to add these methods, we will create a class as follows:

class ARKExtensionsMyCCK extends  ARKExtensionsBase
{

		
	public  function __construct($context, $item, $params)
	{
			//call parent construtor
			 parent::__construct($context, $item, $params);
			 //set allowable context array for inline editing
			 $this->inline_allowed_contexts = array ('com_mycck.item','com_mycck.category');
			 
	}	
	
	public  function prepare() 
	{

	}

}	

ARKExtensionsMyCCK extends the ARKExtensionsBase class because it does a lot of things for us behind the scenes that we want.

You notice that we added a constructor. This is required to set things up; we may have specific things to do for our component, and we have to define the inline allowed_contexts array.

The constructor takes three parameters: the context, current item, and the parameters for the current item.

The context we are talking about here, is the context in which the content plugin event was fired, in your component. So, in other words, it comes down to what view the content plugin event was fired. Or in the case of a CCK, in what type/element this event was fired when rendering that type. This parameter context, is, in fact, a requirement by Joomla for most content plugin events. Joomla needs to know where or when the plugin event was fired.

In our case for the MyCCK component, we have two contexts, in which our events are fired: one when we are rendering our types for the category view and the other when we are, for the main, item type.

So we added the line in the constructor:

$this->inline_allowed_contexts = array('com_mycck.item','com_mycck.category');

That is it really; apart from calling the parent constructor.     

Next we will look at the code we will add, to the prepare method, for our MyCCK component:

public function prepare()
{
	
			
   //Are we allowed to edit in this context 
		
	if($this->context != 'com_content.category')  //override base check as we only fire this for category description
	{
		return false;
	}
	
	if(isset($this->item->introtext)) //Ensure this is only fired off for a category
		return false;
	
	//Set Data Item Type
	$this->type = 'category';		  	

	//Permisson Check
	if(!isset($this->id))
	{
		$id = $this->app->input->get('id',0);
		$this->id = $id ? $id : 0;   
	}
	//Set Asset number 
	 $asset = 'com_content.category.' . $this->id;
	
	$table = JTable::getInstance('category',’MyCCK’);
	$table->load($this->id);
	$createdBy = $table->created_user_id;
	
	$user = JFactory::getUser();		
	//can user edit item if not then bail
	if (!($user->authorise('core.edit', $asset) || ($user->authorise('core.edit.own', $asset) && $user->id == $createdBy)) )
	{
		return false;
	}	
	
	//need to override base class here for following check for categories
	/*filter article to see if it is being used to load a module if so skip it
	[widgetkit]
	{loadmodule}
	{loadposition}
	{module}
	{modulepos}
	{modulepos}
	{component}
	{article(s)}
	*/

	$text = $table->description;
	$test = preg_match('/\{(?:loadmodule|loadposition|module|modulepos|component|articles?)\s+(.*?)\}/i',$text);

	if(!$test)
		$test = preg_match('/\[widgetkit\s+(.*?)\]/i',$text);
	
	if($test)
	{	
		return;
	}
	
			return parent::prepare();	
}

The first thing we do in the prepare method is that we do a check to ensure we only create an editable region for our type if we are in the category view. In our MyCCK component, this is sufficient enough and should be in yours. If, however, the item object you pass into this event also has some type ID, of sorts, please feel free to use that as well.

if($this->context != 'com_mycck.category')  //override base check as we only fire this for category description
{
	return false;
}

In the next line, we wanted to ensure in our component, that we only process the category type and not the blog item type, so that it is only dealt with in the display event. In our case, the context is the same for both the category and the category blog item types, so this extra check is needed.

if(isset($this->item->introtext)) //Ensure this is only fired off for a category
	return false;

After this, we check permissions using Joomla’s Assets system, to check if the user has permission to do inline editing, for our categories:

$user = JFactory::getUser();		
//can user edit item if not then bail
if (!($user->authorise('core.edit', $asset) || ($user->authorise('core.edit.own', $asset) && $user->id == $createdBy)) )
{
      return false;
}

Now let us add the display method:

public function display()
{
	
	//If this item already proccessed
	
	if(isset($this->item->proccessedInline) && $this->item->proccessedInline)
		return false;	

		
	//Are we allowed to edit in this context 
		
	//override base check if needed

	//Set Data Item Type
	$this->type = str_replace($this->app->input->get('option').'.','',$this->context);

if($this->type == "category" ) //we are in blog view so set type to blog
	{
		$this->type = 'blog';
	}
	
	//Permisson Check
	
	//Set Asset number 
	$asset = 'com_content.item.'.$this->id;
	$createdBy = $this->item->created_by;
	
	$user = JFactory::getUser();		
	//can user edit item if not then bail
	if (!($user->authorise('core.edit', $asset) || ($user->authorise('core.edit.own', $asset) && $user->id == $createdBy)) )
	{
		return false;
	}		
		
}

The first thing, we see in this function is a check to see if the ‘processedInline’ flag on the item object has been set to true. This will be the case if the item that is currently being processed has, in fact, been already processed in the prepare function, above.

Okay, now, as below, we set the Data Item type so that the rest of the system knows what type it is dealing with.

//Set Data Item Type

$this->type = str_replace($this->app->input->get('option').'.','',$this->context);

Now, we check if the type is an item type, or, in fact, a category blog type:

if($this->type == "category" || $this->type == "featured") //we are in blog view so set type to blog
{
	$this->type = 'blog';
	$update_introtext = true;

}

Next, we do a permission check, to see if the current user is allowed to do inline editing.

This should all be pretty standard stuff by now:

 //Permission Check
		
//Set Asset number 

$asset = 'com_content.item.'.$this->id;
$createdBy = $this->item->created_by;
$user = JFactory::getUser();		
//can user edit item if not then bail
if (!($user->authorise('core.edit', $asset) || ($user->authorise('core.edit.own', $asset) && $user->id == $createdBy)) )
{
	return false;
}

What are views you may ask?

Views are simply a way of presenting data in your component to the end users. This is normally done by splitting your component into manageable sections, and each section then is responsible for displaying data, in some viewable form, to the user.

In the world of inline editing, you must decide what view you want to be editable by the end user.

Are some views going to be read only?

This is for you to decide.

Once you have done that, you will then need to tell the inline editing framework what views are to be editable.

More on this later, when we will go through this tutorial, using a working example.

The next thing we need to do is to instruct Joomla how to make our types, we defined above, editable when we log into Joomla.

Okay, so far we have told Joomla what our inline types are, in our XML, above, for our component, but now we need to get Joomla to trigger the editor when we click on one of those types, so they will be editable by the user.

There are three approaches we can do to achieve this goal, in this section.

We shall go into detail here on these approaches, using our component MyCCK as a real life example.

In our component, we have two views: One is a blog category, and the other, the Item detailed page.

In the category view, we want the category description to be editable and also each of the blog items. In the Item view, we want the text of the Item(article) to be editable upon clicking anywhere, in the text area.

So how do we do this?

We have three approaches to achieve this.

What are types?

Well, we just covered, that views are simply the page you want to edit. So types or elements are fields on the page that the user is allowed to edit. You can consider a view or web page made up of different viewable elements or types. Some of these types, you may not want to be editable and be read only. So again this is a decision you must make on what element or type will be editable when it comes to editing your component inline.

Okay, let’s recap, we have, now, mentioned that for a component to support our inline editing framework, that we will have to tell the framework what views are allowed to be editable, and what elements/types on that view are, actually, editable as well. 

We will, now, go on with a detailed working example on how to do all of this.

So to start, let's say, we have a component called MyCCK, a simple Content Construction Kit. This component will have a simple item view and a category blog view.

So, the views are:

• Item.
• Category

In this Simple Content Construction Kit, it will have in the item a main article field/type, and in the category blog view, there will be two more types, which will be the category type and the item blog type, for each blog item displayed.

So, the types are:

• Category
• Item
• Blog

To tell the inline editing systems this information, we are going to make a simple package/plugin for Joomla.

So, in the XML install file in this package we will add these elements for the above information:

<extensionName> com_mycck </extensionName>
<!-- allowable views for inline editing //-->
<views>	
<view>item</view>
<view>category</view>
</views>

<!-- add context element if context is different to extension Name //-->

<!-- extension types to be used for inline editing //-->
<types>
<type>category</type>
<type>item</type>
<type>blog</type>
</types>

The new XML element called, ‘extensionName’ is needed to tell the system the name of the component to add inline editing support. In this example, it will be called com_mycck.

Don’t worry about where we put these XML elements in our XML install file for now, we will cover that more in detail, in the XML Installation Manifest File section.