J1.5 talk:Developing a MVC Component/Creating an Administrator Interface

Renaming Part 4

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.

"Hello" Overloaded

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.

Great up to chapter 3

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 File:Http://www.vojtechovsky.net/joomla/component/tutorial-joomla-1.5-free-component.png

Suggestions for improvement

• This is a really long and tedious tutorial with a lot of very useful information in it. I think it would help to break it down into parts or creating separate tutorials covering this material.

Link title

REALLY GOOD DOCUMENTATION

Apart from a small error in part 4 which I have now corrected

did read:

       $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 );

now reads:

       $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)

Excellent documentation, but could use a slight extension

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)

Really a great tutorial ... but too many hello.php's

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

Jochen

Good Tutorial

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: [1]

Hope this helps someone else. -Mike M3t00 15:55, 10 June 2009 (UTC)

RE: Renaming Part 4

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.

Component Hello, Site Hello, Admin Hellos, Admin Hello

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:

• Manage_Hello_List
• Manage_Hello_Item

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)

Splitting up article into two articles

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:

• This chapter is huge making reading a tedious job, overwhelming and scaring away the once that this article is intended for.
• This article has two logical section so braking it at Adding Functionality doesn't harm any body and helps newbies in achieving results. Being able to check a chapter and visually see the intermediate result is always the best motivation.
• Technically the same split at Adding Functionality is making a difference in know-how. the first part is not really new when you followed the site part examples Developing a Model-View-Controller Component 1, 2 and 3. Old wine in new bottles. The second part really goes into depth and requires good basic programming skills and a general understanding of HTML form handling.

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)