Joomla! Documentation - User contributions [en]

Talk:Calendar form field type

2012-11-15T12:44:02Z

Exps1:

If you need MM-DD-YYYY format create a new calendar type. In 2.5.8 setting format to %m-%d-%Y still throws fatal error.

See long discussion here : http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_id=8103&tracker_item_id=20826

For my requirement the solution was to create a new type using jQuery UI datepicker. Lots of formatting options

<?php
defined('_JEXEC') or die('Restricted access');
/**
* Resource Manager Extension
*
* @author Micah Fletcher
* @copyright 2012 Extensible Point Solutions Inc. All Right Reserved
* @license GNU GPL version 3, http://www.gnu.org/copyleft/gpl.html
* @link http://www.exps.ca
* @version 1.0.0
* @since 2.5.6
* */
jimport('joomla.form.formfield');
/**
* Field JQuery UI DatePicker form field class
*/
class JFormFieldJuiDatePicker extends JFormField {

/**
* field type
* @var string
*/
protected $type = 'JuiDatePicker';

/**
* Method to get the field input markup
*/
protected function getInput() {

//script in parent

$js = 'jQuery(function() {

jQuery("#'.$this->id.'").datepicker({

showButtonPanel: true,
showOn: "both",
dateFormat: "'.$this->element['format'].'",
defaultDate: "'.$this->element['defaultDate'].'",
changeYear: true
});
});';

JFactory::getDocument()->addScriptDeclaration($js);

// The input field
// class='required' for client side validation
$class = '';

if ($this->required) {

$class = ' class="required"';
}

$html = array();
$html[] = '<input ' . $class . ' type="text" name="' . $this->name . '" id="' . $this->id . '" size="30" value="' . $this->value . '" />';

return implode("\n", $html);
}
}

Talk:Calendar form field type

2012-11-14T20:51:22Z

Exps1:

Talk:Calendar form field type

2012-11-14T02:02:49Z

Exps1: /* Work around for MM-DD-YYYY */

it seems like the 'format' uses the one from strftime, not date. Maybe it would be best to indeed change to date format anyway, but as it is, the documentation points to the wrong information

== Work around for MM-DD-YYYY ==

If you set the format to "%m-%d-%Y" the calendar formats dates correctly.
However, if you specify default="NOW" a parse error is thrown like:

DateTime::__construct() [datetime.--construct]: Failed to parse time string (11-13-2012) at position 0 (1): Unexpected character

This seems to be because $this->value must be in dd-mm-yyyy format.

If you need to have MM-DD-YYYY format AND set the default date create a new calendar type and add:

if($format == "%m-%d-%Y"){
//put value in dd-mm-yyyy
$tmp = explode("-", $this->value);

if($tmp){
$this->value = $tmp[1]."-".$tmp[0]."-".$tmp[2];
}
}

Note: Have not tested when using filter.

Talk:Calendar form field type

2012-11-14T02:02:08Z

Exps1: /* Work around for MM-DD-YYYY */ new section

Talk:Search Engine Friendly URLs

2012-11-07T13:53:14Z

Exps1: Created page with "JRouter class link http://docs.joomla.org/API16:JRouter"

JRouter class link http://docs.joomla.org/API16:JRouter

Archived talk:Developing a MVC Component/Adding an install-uninstall-update script file

2012-10-30T16:02:58Z

Exps1: /* Postflight - uninstall */ new section

I vote for some additional code in the preflight method, since everybody should check against a suitable version prior to install. Here is the code from the v1.6 preflight method example. I will wait for a week, before adding it to the page. Maybe there are suggestions for V2.5, that should be merged into this code, before we publish it.
--[[User:Gorgonz|gorgonz]] 06:05, 26 May 2012 (CDT)

First we must add some private members to the com_helloWorldInstallerScript class

<source lang="php">
/*
* The release value to be displayed and checked against throughout this file.
*/
private $release = '1.0';

/*
* Find mimimum required joomla version for this extension. It will be read from the version attribute (install tag) in the manifest file
*/
private $minimum_joomla_release = '2.5.0';

</source>

And here is the implementation

<source lang="php">

/*
* $parent is the class calling this method.
* $type is the type of change (install, update or discover_install, not uninstall).
* preflight runs before anything else and while the extracted files are in the uploaded temp folder.
* If preflight returns false, Joomla will abort the update and undo everything already done.
*/
function preflight( $type, $parent ) {

// this component does not work with Joomla releases prior to 2.5
// abort if the current Joomla release is older
$jversion = new JVersion();

// Extract the version number from the manifest. This will overwrite the 1.0 value set above
$this->release=$parent->get("manifest")->version;

// Find mimimum required joomla version
$this->minimum_joomla_release=$parent->get("manifest")->attributes()->version;

if( version_compare( $jversion->getShortVersion(), $this->minimum_joomla_release, 'lt' ) ) {
Jerror::raiseWarning(null, 'Cannot install com_helloWorld update in a Joomla release prior to '.$this->minimum_joomla_release);
return false;
}

// abort if the component being installed is not newer than the currently installed version
if ( $type == 'update' ) {
$oldRelease = $this->getParam('version');
$rel = $oldRelease . ' to ' . $this->release;
if ( version_compare( $this->release, $oldRelease, 'le' ) ) {
Jerror::raiseWarning(null, 'Incorrect version sequence. Cannot upgrade ' . $rel);
return false;
}
}
else { $rel = $this->release; }

echo '<p>' . JText::_('COM_HELLOWORLD_UPDATE_PREFLIGHT_' . $type . ' ' . $rel) . '</p>';
}
</source>

== Postflight - uninstall ==

Testing in joomla 2.5.7 it seems that postflight does not handle "uninstall" as indicated here.
This doc: http://docs.joomla.org/Managing_Component_Updates_with_Joomla!1.6_-_Part_3
seems to have the correct definition of postflight.

Should we update the article?

User:Rvsjoen/tutorial/Developing a Module/Part 06

2012-05-16T15:43:42Z

Exps1: Added language file to manifest, previous entry just copies language folder to module

= Accessing the database =

This part is meant to provide you with a short example on how to access the database and run a query from a module. This is no different than running a query anywhere else in Joomla! but since modules are often the first place you start to learn to write extensions, this tutorial seems like a natural place to cover it.

With your favorite editor, edit the following file

<span id="helper.php">
'''<tt>helper.php</tt>'''
<source lang="php">
<?php

/**
* @package Joomla.Tutorials
* @subpackage Module
* @copyright Copyright (C) 2005 - 2010 Open Source Matters, Inc. All rights reserved.
* @license License GNU General Public License version 2 or later; see LICENSE.txt
*/

// No direct access to this file
defined('_JEXEC') or die;

class modHelloWorldHelper
{
public static function getGreeting() {
return "Message from the helper";
}

public static function getCurrentUsers() {
$db = JFactory::getDBO();
$db->setQuery($db->getQuery(true)
->select("COUNT(*) as users")
->from("#__session")
);
return $db->loadResult();
}
}
</source>
</span>

Here we add a function to our helper class, the function will simply return the number of currently active sessions by counting the number of rows in the session table.

With your favorite editor, edit the following file

<span id="tmpl/default.php">
'''<tt>tmpl/default.php</tt>'''
<source lang="php">
<?php

/**
* @package Joomla.Tutorials
* @subpackage Module
* @copyright Copyright (C) 2005 - 2010 Open Source Matters, Inc. All rights reserved.
* @license License GNU General Public License version 2 or later; see LICENSE.txt
*/

// No direct access to this file
defined('_JEXEC') or die;
?>

<p><?php echo $params->get('greeting', JText::_('MOD_HELLOWORLD_GREETING_DEFAULT')); ?></p>
<p><?php echo modHelloWorldHelper::getGreeting(); ?></p>
<p>There are <?php echo modHelloWorldHelper::getCurrentUsers(); ?> user(s) logged in</p>
</source>
</span>

Here we modify the module template to echo out the number of currently active users, as provided by our helper.

With your favorite editor, edit the following file

<span id="mod_helloworld.xml">
'''<tt>mod_helloworld.xml</tt>'''
<source lang="xml">
<?xml version="1.0" encoding="utf-8"?>
<extension type="module" version="2.5.0" method="upgrade">

<name>MOD_HELLOWORLD</name>

<creationDate>Once upon a time</creationDate>
<author>John Doe</author>
<authorEmail>john.doe@example.org</authorEmail>
<authorUrl>http://www.example.org</authorUrl>
<copyright>Copyright Info</copyright>
<license>License Info</license>

<version>0.0.6</version>

<description>MOD_HELLOWORLD_XML_DESCRIPTION</description>


<files>
<filename module="mod_helloworld">mod_helloworld.php</filename>
<filename>mod_helloworld.xml</filename>
<filename>helper.php</filename>
<folder>tmpl</folder>
</files>
<languages folder="language">
<language tag="en-GB">en-GB/en-GB.mod_helloworld.ini</language>
<language tag="en-GB">en-GB/en-GB.mod_helloworld.sys.ini</language>
</languages>
<config>
<fields name="params">
<fieldset name="basic">
<field
name="greeting"
type="text"
default="MOD_HELLOWORLD_GREETING_DEFAULT"
label="MOD_HELLOWORLD_GREETING_LABEL"
description="MOD_HELLOWORLD_GREETING_DESC"
/>
</fieldset>
</fields>
</config>

</extension>
</source>
</span>

== File listing ==

* <tt>[[#mod_helloworld.xml|mod_helloworld.xml]]</tt>
* <tt>[[User:Rvsjoen/tutorial/Developing_a_Module/Part_05#mod_helloworld.php|mod_helloworld.php]]</tt>
* <tt>[[#tmpl/default.php|tmpl/default.php]]</tt>
* <tt>[[User:Rvsjoen/tutorial/Developing_a_Module/Part_04#language/en-GB.mod_helloworld.ini|language/en-GB.mod_helloworld.ini]]</tt>
* <tt>[[User:Rvsjoen/tutorial/Developing_a_Module/Part_04#language/en-GB.mod_helloworld.sys.ini|language/en-GB.mod_helloworld.sys.ini]]</tt>
* <tt>[[#helper.php|helper.php]]</tt>

== Testing your module ==

For details on how to install the module into your Joomla! site, refer to the information provided in
[[User:Rvsjoen/tutorial/Developing_a_Module/Part_01#Installation_and_Testing|Part 01]].

== Download this part ==

[https://github.com/downloads/rvsjoen/joomla-tutorials/mod_helloworld-part06.zip Download example package]

{{:Chunks:Developing_a_Module_Contents}}

Archived talk:Developing a MVC Component/Adding categories

2011-08-04T12:05:26Z

Exps1:

Why $query = new JDatabaseQuery;
but not $query = &new JDatabaseQuery; ?

In ../models/fields/helloworld.php on line 29

If you use the line, $query = new JDatabaseQuery;, component works, but when helloworlds is added as menu item it causes the following error when item is clicked:

Fatal error: Cannot instantiate abstract class JDatabaseQuery in C:\xampp\htdocs\test_site\administrator\components\com_helloworld\models\fields\helloworld.php on line 29

Reverting back to code from part 11, $query = $db->getQuery(true);, does not throw error.

Just an observation.

J1.5 talk:Component parameters

2009-10-16T13:19:17Z

Exps1: /* Setting in XML Installer */

I find the terms "frontend" and "backend" confusing when applied in this context.

also, links to the standard parameter types would be extremely useful.
http://docs.joomla.org/Standard_parameter_types

Overall, I found the article extremely useful.

Commercemeister, thanks for your comments. Could you please explain what you find confusing about frontend and backend? They are commonly used to refer to the main site and the administration parts of a Joomla! website, respectively. It would be helpful to know how you think they should be clarified (or you could even just do it yourself - that's the beauty of a wiki!). Thanks too for the note about parameter types - the article did originally link to a page with this information, but then that page was changed. I will update it.

One final point - please sign your comments using the four tildes at the end (<nowiki>~~~~</nowiki>). Thanks, [[User:Mike dowler|Mike]] 16:18, 3 September 2008 (EDT)

I'm confused about the differences between the types of parameters.
So you've got Parameters (Basic), (Advanced), (Component) and (System).

Now what kind of parameters would you put in (basic) and what in (component) if both can be overriden in the menu you create for the component ?
I just don't see the distinction between the two...
[[User:Alfred|Alfred]] 14:12, 25 September 2008 (EDT)

Alfred, 'Basic' and 'Advanced' parameters are just 'article-specific' parameters - the only difference between 'basic' and 'advanced' is in how they are displayed in the back end. 'Article-specific' parameters are those that are only ever going to apply to that article, whereas 'Component' parameters are set for the component as a whole. As you point out, both types can be overridden for a particular menu link; administrators using your component will thank you if such overrides are the exception rather than the rule!

So, in the screenshot shown, there is the basic parameter 'Description text' field which (IIRC) provides a description of the article. It would make no sense to have this as a component parameter, since you would need to override it almost every time you use it. Note that there is no 'right' or 'wrong' here, just common sense. If a parameter is likely to be the same across the site (e.g. choosing whether or not to display the name of the author, which is likely to be fixed to maintain a consistent feel to a site), then put it in the component params. If it's likely to change in each case, make it an article param. If both would be useful, then use both. (Just make sure that you give the article param a 'Use global' (i.e. empty string) option as default, so that the component parameter works as expected.) [[User:Mike dowler|Mike]] 18:23, 28 October 2008 (EDT)

== Component level params must be saved before they show up ==

I've seen this effect in several extensions, and it was very confusing and not obvious at first. Perhaps a note can be added. The issue is that the default params for the component, usually accessed by "Preferences" may not have been actually entered into the database.

It would be nice to just have a note, especially in the overrides section, that you need to make sure the component params are actually saved. It would also be nice if 3rd party components that use these config params either place a notice to the user that params must be saved, or make sure that the default params are entered into the database during the installation process, if these params do not yet exist.

Hope this makes some sense. I'm not really sure the best solution to this problem, but more documentation about this potential pitfall I'm sure would be helpful.

Snellcode, good point. Tbh, I think the whole parameters subject is a little difficult to get hold of - my main reason for writing this was so that I could get everything straight in my own head. The way it ''should'' work is that the <code>COMPONENT_NAME.xml</code> installation file creates the parameters in the database, so that the component defaults are already set. If this is '''not''' done, then you are right - it is necessary to open the 'parameters' window, choose the values, and save, so that the parameters are created. The wrong way to do things, which may be what is going on, is to try to combine both steps (ignoring the installation file) and give the <code><param /></code> elements in the <code>config.xml</code> file <code>default</code> values. These will show up in the parameters window, but do not appear in the database until they are saved. The article does kind of refer to this, but I will think about how to make it more explicit.

You could try point the 3PDs to this article, or simply vote with your feet and use a different extension! [[User:Mike dowler|Mike]] 21:36, 17 February 2009 (UTC)

== Referencing the parameters XML file in the install file ==
I have deleted Jmgonet's paragraph about adding a reference to the install file, as I think it is outside the scope of this article (which tbh is already complicated enough!) The article is aimed at those developing components, who should be aware of the need to ensure that all necessary files are installed (covered adequately elsewhere). In any case, the best option is to use a <code><folder /></code> tag in the install file, rather than lots of <code><filename /></code> tags; that way, there is no need to list every single file, and less risk of a file being missed. Hope that's ok! [[User:Mike dowler|Mike]] 21:54, 17 February 2009 (UTC)

== Example Code ==

I am trying to understand all of what has been said on this page. I have a background in php but haven't programmed for years.

It would really help me if a example component was made and offered up as a zip file. Something just VERY simple, it wouldn't even need to fulfill a any kind of function. Just show me a working example without all the other stuff. It would not even need to show everything talked about on the page, just the common stuff. After people have the basics, I am sure they could understand your article without an working example.

Thanks

Dr. Sassafras

== Install ==

One more note about the install.

I now understand by reading the discussion, but it would be nice somewhere in the article if it said that loading the settings was not NECESSARY in the install. It was unclear to me when the install was mentioned if I had to include it in the install, and go through a install for any of what was being said to work.

I know these might be very basic concepts. But thats where I am right now. You have to start somewhere.

Dr. Sassafras

''In an MVC structure, this code would be placed in the view.html.php file for the particular view required.

Assuming that the item parameters are stored in the params field, and that the particular item has been loaded into the $row object by the method, you would then add in the item parameters to the $params object using:''

Please give an example of this. Don't know what you are talking about. I don't see the an example of how to load the $row ether.

I have been able to get global preferences set, but don't have enough info override the globals with page specific ones.

[[User:Drsassafras|Drsassafras]] 20:16, 21 March 2009 (UTC)

== Setting <params> in XML Installer ==

There is an issue with using the XML installer file to set params field values in jos_component.
See: http://joomlacode.org/gf/project/joomla/tracker/?action=TrackerItemEdit&tracker_item_id=17767

Including the following code in the XML install file has no affect - db field params remains empty until users saves config in view.
<install>
..
<params>
<param name="foo" default="bar" />
</params>
..
</install>

[[User:Exps1|Exps1]] 12:54, 16 October 2009 (UTC)

J1.5 talk:Component parameters

2009-10-16T13:01:59Z

Exps1: /* Setting in XML Installer */

J1.5 talk:Component parameters

2009-10-16T12:54:41Z

Exps1: /* Setting in XML Installer */ new section

J1.5:Developing a MVC Component/Basic Backend Framework

2009-10-16T00:11:50Z

Exps1: /* The Hellos View */

== Introduction ==
This article focuses on the entry page/article for the administrator. Whilst the MVC pattern is the same as for the frontend user, this chapter will rapidly go though all steps and setup the backend counter part in the admin section. This article will only focus on setting up the Basic Framework with a list of all the ''Hellos'' but without user interaction. The actual user interaction is added in the succeeding article [[Developing a Model-View-Controller Component - Part 6 - Adding Backend Actions]].

== Tutorial specific naming ==
Within the next articles the explanation of this administrator section we will keep as close as possible to the component name. For the general overview, lists from the database, we will use ''Hellos'' as identification. The ''Hellos'' naming will be used for viewing and controlling multiple Hellos at once from the database. When selecting a single Hello for Editing or Adding we will use the singular ''Hello'' as naming for the Controller and View. This ''Admin Hello'' has no functional relation with the ''Site Hello'' (the only dependency is the database content of cause).

Where parts 1,2 and 3 of the MVC explanation were working in the site directory tree of com_hello, part 5 and 6 will focus on the admin directory tree. Part 5 and 6 will not add or change files in the site directory tree. Look at the XML file in the attached example of the full com_hello implementation. The XML configuration file will help you with the exact location of the different files being used in this and the following chapter.

== Creating the Basic Framework ==

The basic framework of the administrator panel is very similar to the site portion. The main entry point for the administrator section of the component is hello.php. This file is identical to the hello.php file that was used in the site portion except the name of the controller it loads will be changed to HellosController. The default controller is also called controller.php and this file is identical to the default controller in the site portion, with the exception that the controller is named HellosController instead of HelloController. This difference is so that JController will by default load the hellos view, which will display a list of our greetings.

Here is the listing for hello.php:

<source lang="php"><?php
/**
* @package Joomla.Tutorials
* @subpackage Components
* @link http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_4
* @license GNU/GPL
*/

// No direct access

defined( '_JEXEC' ) or die( 'Restricted access' );

// Require the base controller

require_once( JPATH_COMPONENT.DS.'controller.php' );

// Require specific controller if requested
if($controller = JRequest::getWord('controller')) {
$path = JPATH_COMPONENT.DS.'controllers'.DS.$controller.'.php';
if (file_exists($path)) {
require_once $path;
} else {
$controller = '';
}
}

// Create the controller
$classname = 'HellosController'.$controller;
$controller = new $classname( );

// Perform the Request task
$controller->execute( JRequest::getVar( 'task' ) );

// Redirect if set by the controller
$controller->redirect();</source>

The view and model that we will start with is the hellos view and the hellos model. We will start with the model.

==== The Hellos Model ====

The Hellos Model will be very simple. The only operation that we currently need is the ability to retrieve the list of hellos from the database. This operation will be implemented in a method called getData().

The JModel class has a built in protected method called _getList(). This method can be used to simplify the task of retrieving a list of records from the database. We simply need to pass it the query and it will return the list of records.

At a later point in time, we might want to use our query from within another method. Therefore, we will create a private method called _buildQuery() which will return the query that will be passed to _getList(). This makes it easier to change the query as well since it is localized in one place.

Therefore we need two methods in our class: getData() and _buildQuery().

_buildQuery() simply returns the query. It looks like:

<source lang="php">/**
* Returns the query
* @return string The query to be used to retrieve the rows from the database
*/
function _buildQuery()
{
$query = ' SELECT * '
. ' FROM #__hello '
;

return $query;
}</source>

getData() will obtain the query and retrieve the records from the database. Now it might happen that we need to retrieve this list of data twice in one page load. It would be a waste to have to query the database twice. Therefore, we will have this method store the data in a protected property so that on subsequent requests it can simply return the data it has already retrieved. This property will be called _data. (''<-- Naming convention conflict. Private or Protected data should be preceded with a '_' but as this reference is returned to the view where this data is directly accessed, this data can only be considered as public.'')

Here is the getData() method:

<source lang="php">/**
* Retrieves the hello data
* @return array Array of objects containing the data from the database
*/
function getData()
{
// Lets load the data if it doesn't already exist
if (empty( $this->_data ))
{
$query = $this->_buildQuery();
$this->_data = $this->_getList( $query );
}

return $this->_data;
}</source>

The completed model looks like:

<source lang="php"><?php
/**
* Hellos Model for Hello World Component
*
* @package Joomla.Tutorials
* @subpackage Components
* @link http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_4
* @license GNU/GPL
*/

// Check to ensure this file is included in Joomla!
defined('_JEXEC') or die();

jimport( 'joomla.application.component.model' );

/**
* Hello Model
*
* @package Joomla.Tutorials
* @subpackage Components
*/
class HellosModelHellos extends JModel
{
/**
* Hellos data array
*
* @var array
*/
var $_data;

/**
* Returns the query
* @return string The query to be used to retrieve the rows from the database
*/
function _buildQuery()
{
$query = ' SELECT * '
. ' FROM #__hello '
;
return $query;
}

/**
* Retrieves the hello data
* @return array Array of objects containing the data from the database
*/
function getData()
{
// Lets load the data if it doesn't already exist
if (empty( $this->_data ))
{
$query = $this->_buildQuery();
$this->_data = $this->_getList( $query );
}

return $this->_data;
}
}</source>

This file is saved as models/hellos.php.

==== The Hellos View ====

Now that we have a model to retrieve our data, we need to display it. This view will be fairly similar to the view from the site section as well.

Just as our model was automatically instantiated in the site, so it is in the administrator. Methods that start with get in the model can be accessed using the get() method of the JView class. So our view has three lines: one to retrieve the data from the model, one to push the data into the template, and one to invoke the display method to display the output. Thus we have:

<source lang="php"><?php
/**
* Hellos View for Hello World Component
*
* @package Joomla.Tutorials
* @subpackage Components
* @link http://docs.joomla.org/Developing_a_Model-View-Controller_Component_-_Part_4
* @license GNU/GPL
*/

// Check to ensure this file is included in Joomla!
defined('_JEXEC') or die();

jimport( 'joomla.application.component.view' );

/**
* Hellos View
*
* @package Joomla.Tutorials
* @subpackage Components
*/
class HellosViewHellos extends JView
{
/**
* Hellos view display method
* @return void
**/
function display($tpl = null)
{
JToolBarHelper::title( JText::_( 'Hello Manager' ), 'generic.png' );
JToolBarHelper::deleteList();
JToolBarHelper::editListX();
JToolBarHelper::addNewX();

// Get data from the model
$items =& $this->get( 'Data');

$this->assignRef( 'items', $items );

parent::display($tpl);
}
}</source>

This file is saved as views/hellos/view.html.php.

Look carefully at the almost hidden differences compared to ''site'' example. The data is stored in a variable that is encapsulated within the model. Because the data amount is huge due to using the very handy _getList(), the need for returning a reference instead of a value is obvious. This is handled in:
$items =& $this->get( 'Data');
Looking again at this line and you will notice another difference with respect to the ''site'' view.html.php. The calling of the model function is done implicit. The actual model function name is getData(). In the ''site'' example you had to call following two lines:
$model =& $this->getModel();
$greeting = $model->getData();
Both lines are now taken care of by calling: <code>$this->get( 'Data');</code>. Under the surface of this <code>get()</code> the 'Data' is prefixed with 'get' so when using this function make sure the model functions are preceded with 'get'. This function can also be used in the ''site'' section. It is considered good programming practise to keep the data in the model and access it by reference, <code>get()</code> methods are the preferred way of getting data from the model.

==== The Hellos Template ====

The template will take the data pushed into it from the view and produce the output. We will display our output in a simple table. While the frontend template was very simple, in the administrator we will need a minimal amount of extra logic to handle looping through the data.

Here is our template:

<source lang="php"><?php defined('_JEXEC') or die('Restricted access'); ?>
<form action="index.php" method="post" name="adminForm">
<div id="editcell">
<table class="adminlist">
<thead>
<tr>
<th width="5">
<?php echo JText::_( 'ID' ); ?>
</th>
<th>
<?php echo JText::_( 'Greeting' ); ?>
</th>
</tr>
</thead>
<?php
$k = 0;
for ($i=0, $n=count( $this->items ); $i < $n; $i++)
{
$row =& $this->items[$i];
?>
<tr class="<?php echo "row$k"; ?>">
<td>
<?php echo $row->id; ?>
</td>
<td>
<?php echo $row->greeting; ?>
</td>
</tr>
<?php
$k = 1 - $k;
}
?>
</table>
</div>

<input type="hidden" name="option" value="com_hello" />
<input type="hidden" name="task" value="" />
<input type="hidden" name="boxchecked" value="0" />
<input type="hidden" name="controller" value="hello" />

</form></source>

This template is saved as views/hellos/tmpl/default.php.

You will notice that our output is enclosed in a form. Though this is not necessary now, it will be soon.

We have now completed the basic part of the first view. We have added five files to the admin section of our component:

* hello.php
* controller.php
* models/hellos.php
* views/hellos/view.html.php
* views/hellos/tmpl/default.php

You can now add these files to the XML install file and give it a try!

== Conclusion ==

We have now implemented a basic framework for the backend admin component. A list where all of the Hellos are displayed. The next chapter will extend this framework and add user interaction / database manipulation.

== Articles in this Series ==
[[Developing a Model-View-Controller Component - Part 1]]

[[Developing a Model-View-Controller Component - Part 2 - Adding a Model]]

[[Developing a Model-View-Controller Component - Part 3 - Using the Database]]

[[Developing a Model-View-Controller Component - Part 4 - Creating an Administrator Interface]]

[[Developing a Model-View-Controller Component - Part 5 - Basic Backend Framework]]

[[Developing a Model-View-Controller Component - Part 6 - Adding Backend Actions]]

== Contributors ==
* staalanden
* jamesconroyuk

== Download ==

The full admin component can be downloaded at: [http://joomlacode.org/gf/download/frsrelease/8111/29436/com_hello4_01.zip com_hello4_01].

[[Category:Development]]

J1.5 talk:Developing a MVC Component/Using the Database

2009-10-15T13:43:19Z

Exps1: /* Saving the install/uninstall files */ new section

Although it is mentioned in the article, I think it is important to underline where the install.sql and uninstall.sql files have to be placed:

install.sql and uninstall.sql files have to be mentioned in two places:
* In one of the file sections. For example:
<files folder="admin">
<filename>...</filename>
<filename>...</filename>
<filename>install.sql</filename>
<filename>uninstall.sql</filename>
</files>
* In the ''install'' / ''uninstall'' sections.

Of course, the files have to be copied in the correct folder (in the example, it should be the ''admin'' folder).

When data is read from a database, it can be retrieved in the class constructor:

// The constructor accesses the database, and retrieves all properties.
function __construct($config = array()) {
parent::__construct($config); // To transmit configuration to parent class.
$db =& JFactory::getDBO();
$query = 'SELECT greeting FROM #__hello';
$db->setQuery( $query );
$this->greeting = $db->loadResult();
}
// The private property
var $greeting;
// The public property accessor
function getGreeting() {
return $this->greeting;
}

/* 2009-07-21 */
* Are those file names for "install.utf8.sql" and "uninstall.utf8.sql" correctly written into XML file? I see files "install.sql" and "uninstall.sql", but in the text, there says the files will be named "install.utf8.sql" and "uninstall.utf8.sql"?

== Some glitches ==
I followed the MVC explanation step by step but this section contains some glitches.

The .sql files should NOT contain '.utf' in the file names. The installer will not find the files (verified on Joomla! 1.5.12).

As indicated above, storing the (un)instal.sql should be in admin directory. So to be concrete the last lines of the chapters "Creating the Installation SQL File" and "Creating the uninstall SQL file" should be:

We will ... called ./admin/install.sql
We will ... called ./admin/uninstall.sql

(both glitches are not in the attachment belonging to the article; the component file: com_hello3_01 is correct)<br>
--[[User:M.A.S.H|M.A.S.H]] 12:09, 2 August 2009 (UTC)

== Saving the install/uninstall files ==

On my system I ran into a problem with the intall.sql / uninstall.sql files.
I wanted to avoid using the <query> tags by including them in the script and having JIntaller run them. I created files using MySQL Query Browser testing them to make sure they worked.
When the component is installed JInstaller raises a 1064 db error, which did not make any sense.
The problem was occurring because I was saving the script as type "SQL Script File UTF-8", which seemed logical because the charset is utf8. The file must be saved as type "SQL Script File ANSI" or you get the 1064 db error.

Using Joomla 1.5.14, MSQL Query Browser 1.2.12, XP sp3

[[User:Exps1|Exps1]] 13:43, 15 October 2009 (UTC)