I checked out the comment below. ;-) Certainly, the multitude of hello(s) is confusing. What I did is to rename most everything.
Whenever there's something like HelloWhateverHello, the first Hello represents the component front-end, and the second represents the view/model. By the way, each view has its own model, which I think is pretty much standard MVC architecture. On the other hand, one controller can control several views, although this example doesn't do so.
Conversely, if you see HellosWhateverHello or HellosWhateverHellos, the first Hellos represents the adminstrative back-end, and the Hello or Hellos at the end refers to the view for editing one greeting or for listing all greetings, respectively. (Replace *Whatever* with Model, View, or Controller as appropriate.)
So, I renamed all this to look like FrontWhateverContent, AdminWhateverEdit, AdminWhateverList, and so on. Then I had to rename directories and files as well, so that models/hello.php became models/content.php in the front-end and models/edit.php in the back-end. Likewise, views/hello/ becomes views/content/ in the front-end and views/edit in the back-end. Also, in the back-end only, models/hellos.php & views/hellos/ become models/list.php & views/list. Lastly, I changed controllers/hello.php to controllers/edit.php, to reflect the change from HellosControllerHello to AdminControllerEdit.
Hope this clears things up a bit. It's a tedious refactoring exercise to do all this renaming, but it *is* doable. Good luck.
I'm not sure if anybody checks this, but I'm having a difficult time making my own component out of this document.
The first three chapters of this documentation are great. They are simple and to the point. The fourth, this page, is very confusing.
First off, the word "hello" is way over loaded. In the Creating an Admin Interface there are two models and two views: Hello and Hellos
It's impossible to know why we need two different models. Why cant we use one model and two views? Its totally impossible to understand which one gets called when.
I have discovered there are a lot of name conventions used here, but after reading this document over and over, it's still very difficult to know what the conventions are. This is probably stemming from "hello" being way too overloaded.
The method "get()" in JView is called in both views. It is supposed to automatically know which model to use, and which method to call. However, I don't think I followed the naming convention correctly, as it simply is not working (I get empty data with no error).
I think I could untangle the naming conventions myself, but with "hello" so overloaded in this example, I am having no luck guessing.
The documentation was great upto chapter 3. Got confused in 4th chapter.
Also, this doesn't cover how to create sub menus for a component See example
Apart from a small error in part 4 which I have now corrected
$row =& $this->items[$i]; $checked = JHTML::_( 'grid.id', $i, $row->id ); $link = JRoute::_( 'index.php?option=com_hello>controller=hello>task=edit>cid='. $row->id );
$row =& $this->items[$i]; $checked = JHTML::_( 'grid.id', $i, $row->id ); $link = JRoute::_( 'index.php?option=com_hello&controller=hello&task=edit&cid='. $row->id );
James Conroy 16:29, 16 February 2009 (UTC)
Have been able to create components using this set of tutorials, but am missing how to use non-string based data in the administrator interface.
The admin form only has one field (a string) and it might be useful to have either examples of, or a link to some other examples of how to view / capture other types of data such as :
Checkboxes (boolean) Dropdown menus / radio button (int or string)
While it is easy to add the HTML form components (and even populate them with the values from the model), it isn't immediately clear how to recapture the data of these alternative types.
There is another tutorial I have seen on this wiki that has the "build in a rich editor" function, could use a link from this page.
Craig Moore 13:06, 09 May 2009 (UTC)
First of all, great tutorial, a very good effort to explain the basics.
Maybe just my problem: I personally prefer to edit several files at a time, what means, i have 10-20 tabs open in my editor (UltraEdit). In my case that means, that my editor tab-bar looks like:
hello.php - controller.php - hello.php - hello.php - hello.php - controller.php - hellos.php - and so on ...
I would kiss the shoes of everyone who would:
1.) precisely explain naming conventions for files of components (which file may, which file must be called hello.php)
2.) resolve the hello.php-maze in this tutorial with more speaking filenames
Thanks to the authors, best regards and a hello to everyone
Suggestion for improvement.
I also found Part 4 hard to follow and lacking explanation of why various names/paths/parameters were chosen. For a beginner trying to understand Joomla! MVC conventions I found another component backend howto that gave more of the details I was looking for: 
Hope this helps someone else. -Mike M3t00 15:55, 10 June 2009 (UTC)
I'm actually even more confused now.
Only by reading through this discussion did it occur to me that you need to use multiple views to handle the various tasks in the controller. That seems like an important concept that is not entirely obvious to someone trying to learn the joomla framework. And yet now that I recognize the concept, it's not obvious what the best practices would be to implement multiple views. I'll work on it.
Despite that, this is still an extremely valuable tutorial -- especially considering that much of the rest of the API documentation is sparse at best. The entire joomla documentation in general could definitely benefit from a bit of a re-org.
EDIT: OK. So after reading through part 4 of the tutorial again, it is clear to me about the multiple views. So, looking back, it would have been valuable to explain that in the introduction. Something like:
"Now we will create an administrator section to create the greetings. It uses 2 views. The first view, called Hellos, will present a list of greetings with the ability to add new ones or remove old ones. The second view will allow the user to edit each greeting."
That would have helped tremendously. In any case, I got it now. I feel a little stupid for missing that the first time around, but maybe it was because it was late at night.
Chapters 1 and 2 were easy to follow. Chapter 3 contains some glitches that took me some time to understand but reading this chapter made everything really confusing. It took me a time to realise the Hello's, just my subject with only the focus clarifies already some impact. After re- and re-re reading it becomes clear to me what is meant. After re-reading the reason for using Hellos (as an Admin List) became clear and re-re- reading made the Admin single view/tmpl Hello obvious again. Why not rename these to:
This would make everything much more readable, would set a clear context and increase the ease of understanding.
--M.A.S.H 12:37, 3 August 2009 (UTC)
If the writers have no objection I propose to split this chapter into two. There are multiple good reasons for doing so but the most important three are the following:
If no objections I will initiate this spilt soon.
--M.A.S.H 07:34, 10 August 2009 (UTC)
I think splitting it is a good idea and should improve readability. I look forward to seeing your improvements. Chris Davenport 08:51, 10 August 2009 (UTC)
I agree Part 4 gets confusing. I see what it is attempting to demonstrate but it is confusing to jump into a completely new example rather than use an example from the onset that could cover the details of the controls in the Admin area.
Maybe choosing a slightly more complex example than 'Hello world!' from the beginning?
Will be good to see this article when it's been updated!
I'm removing the so-called hint from the section titled 'Mapping a Joomla! MVC component from the example.'
I've never seen the 'registered' method, and I think it's bogus.
Please respond if I'm wrong.
HobbesPDX 20:19, 6 March 2010 (UTC)
I'd like to suggest to the community, that the expansive note, in section 3.2.3, regarding sharing template/view elements, using include/require, should be moved to another article.
It's a very helpful point, but I feel it adds unnecessary and extra information to an already complex document.
--HobbesPDX 21:00, 6 March 2010 (UTC)