Developing a MVC Component/Creating an Administrator Interface
(Redirected from Talk:Developing a Model-View-Controller Component/1.5/Creating an Administrator Interface)
- 1 Renaming Part 4
- 2 "Hello" Overloaded
- 3 Great up to chapter 3
- 4 Suggestions for improvement
- 5 REALLY GOOD DOCUMENTATION
- 6 Excellent documentation, but could use a slight extension
- 7 Really a great tutorial ... but too many hello.php's
- 8 Good Tutorial
- 9 RE: Renaming Part 4
- 10 Component Hello, Site Hello, Admin Hellos, Admin Hello
- 11 Splitting up article into two articles
- 12 Confusing
- 13 Hint in 'Mapping' section
- 14 Move 'sharing template parts' note to another article?
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.
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 See example
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.
REALLY GOOD DOCUMENTATION
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)
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
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)
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:
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)
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 have to add my agreement to this -- the Hello World was a fine, basic example -- no need to crummy up the lesson with this sudden deviation into an entirely different example.
This article should be moved to its' own section, IMHO. --HobbesPDX 23:21, 6 March 2010 (UTC)
I have to disagree with you. If you read the comments in Parts 5 and 6 it is obvious that a lot of people have troubles understanding the concept of 'site' and 'admin' (most of them are a little lazy). Even worse, some have no idea what the concept is about. This Part is an important try to make the change between front-end and back-end module development (including user interaction) as is clearly indicated in the introduction paragraph of Part 4. I have added a more explicit remark though that this Part can be skipped. --M.A.S.H 10:36, 15 July 2010 (UTC)
I'm confused... when the original author says FORM, does he mean input form or the template format (file in /views/<view_name>/tmpl/<view_name>.<format>.php)?
The other previous tutorial in the series was great, but this one took the whole night to understand.
Hint in 'Mapping' section
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 have returned the 'hint' by making just a reference to the User object. This because verifying in templates whether a specific user or in general a registered user, is viewing a page is a common approach to make a difference in page creation in your template modules. This is a common question on the internet and therefore a hint to the User object is really supportive.
--M.A.S.H 10:48, 15 July 2010 (UTC)
Move 'sharing template parts' note to another article?
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)
I agree. Let's create a Part 7 with tips and tricks. All the hints could be moved there.
--M.A.S.H 12:16, 26 July 2010 (UTC)