help a newbie

[sport...@gmail.com]

All,
I am attempting my first Joomla 1.5 component. It is a sports league
management component. I am starting with the backend. Can some one
point me to a good implemntation of a backend, I have many tabel to
administer, and need a nudge on how to set up the main contoller
which I assume will let me choose a atbel then use a specific table/
modle controler?

Thanks!

[Jonathan Lackey @zuno]

The best way I found is Joe LeBlanc's book "Learning Joomla! 1.5 Extension Development"

http://www.amazon.com/Learning-Joomla-1-5-Extension-Development/dp/1847196209/ref=sr_1_2?ie=UTF8&s=books&qid=1296923449&sr=8-2

I used it when I built my first component and I never would have figured it out without the book. It walks you step-by-step through the entire process of building the backend, frontend, modules and plugins.

Hope it helps.

Jon

Jonathan Lackey | vp, creative director

811 N Catalina Ave, Penthouse Suite . Redondo Beach CA . 90277
t:310.372.5263 . twitter @zuno . skype: zunostudios

zunostudios.com  facebook

--
You received this message because you are subscribed to the Google Groups "Joomla! General Development" group.
To post to this group, send an email to joomla-de...@googlegroups.com.
To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/joomla-dev-general?hl=en-GB.

[Mike Hamanaka]

The tutorial in that book shows how to build a restaurant review component, really good detail.

Mike Hamanaka

Website Production 

Vertualize.com

[sport...@gmail.com]

Ok I just got it from a local store, We will see how it goes from
here, Thanks!

On Feb 5, 9:16 am, "sportinu...@gmail.com" <sportinu...@gmail.com>
wrote:

[Alfred Vink]

I think all the Joomla publications from Packt are great, I just wish they
would come up with something for 1.6.....

Alfred

-----Oorspronkelijk bericht-----
Van: joomla-de...@googlegroups.com
[mailto:joomla-de...@googlegroups.com] Namens sport...@gmail.com
Verzonden: zaterdag 5 februari 2011 17:48
Aan: Joomla! General Development
Onderwerp: Re: help a newbie

--

[AJ]

Hi,

The book mentioned is a really good starting point. As your components become more complex you might find some of what I've listed below useful regarding structure.

I've found that when dealing with multiple tables it's best to create a controller/model for each table. Even two doesn't hurt. One for a single entry in the table and another for lists of entries. For example, in your situation, you might have the following:

Component name: com_sportsmanagement

Main Controller:
Class Name: SportsManagementController
Filename: /controller.php
Description: This could be used to redirect to your default "list" controller. For example, a list of Leagues or even showing a menu of some sort seeing as you have many tables or entities to manage.

Leagues Controller:
Class Name: SportsManagementControllerLeagues
Filename: /controllers/leagues.php
Description: This controller would handle everything to do with lists of Leagues. For example, viewing leagues, delete a league or many selected leagues

League Controller:
Class Name: SportsManagementControllerLeague
Filename: /controllers/league.php
Description: This controller would handle adding/modifying/perhaps removing a single League

The same structure would apply to your models and views:
League Model:
Class Name: SportsManagementModelLeague
Filename: models/league.php
Description: Contains logic to fetch a single league for display, edit, create (would be array/object representing a new league with default values for some fields etc.)

Leagues Model:
Class Name: SportsManagementModelLeagues
Filename: models/leagues.php
Description: Contains logic to fetch a list of leagues, handle pagination, update display order, etc.

Following the above structure, you'll find as things get more complex, it is easier to keep track of code, etc. Also, I've noticed that when using a structure like the above, the Joomla! MVC convenience methods all seem to fall into place.

Things I've noticed that you might want to avoid/keep in mind:

1) First, create a base controller/model and sometimes a base view. You can use these base classes to put common functionality in and share with your other controllers/models/views. A good example of this would be pagination, sort ordering, removing, etc. Even if they are empty to begin with, that's ok, you can add to them as you come across code that you feel will/could be used again. For example:

class SMControllerBase extends JController {}
class SMModelBase extends JModel {}
class SMViewBase extends JView{}

Then you would just extend these classes for your components actual controllers:
class SportsManagementControllerLeague extends SMControllerBase
{
    // controller methods and classes here
}

This is not really specific to Joomla!, but rather just good practice in general, so you may already be doing this. I wanted to mention it because I still dive in head first without thinking about things like this.

2) A lot of tutorials show pulling data from the request in the model, with methods like $model->getData(). I prefer at least having a method withing the model that can receive criteria. For example $model->getLeague(1234), where 1234 is the id of the League you are trying to get. If you really want to use the view::get('Data') type convenience methods, wrap the getLeague($id) method in a getData() method.

Example:
class SportsManagementModelLeague extends JModel
{
    public function getData()
    {
        $id = JRequest::getInt('id', 0);
        if (!$id) {
            return null;
        }
       
        return $this->getLeagueById($id);

    }

   public function getLeagueById ($id)
   {
       $dbo =& $this->getDBO();

       $sql = "SELECT * FROM #__sm_league ";
       $sql.= "WHERE id = " . $dbo->quote($id);

       $dbo->setQuery($sql);

       $result = $db->loadObject();

       // might want check for db error here

       return $result;
      
   }

}


Hope that helps out,
AJ

[sport...@gmail.com]

Thanks for the advice, I am not sure I understand the nuances yet. So
beside the usually table info and interactions what other back end
functionality shoud be considered?

On Feb 5, 10:52 am, AJ <amagon...@gmail.com> wrote:
> Hi,
>
> The book mentioned is a really good starting point. As your components
> become more complex you might find some of what I've listed below useful
> regarding structure.
>
> I've found that when dealing with multiple tables it's best to create a
> controller/model for each table. Even two doesn't hurt. One for a single
> entry in the table and another for lists of entries. For example, in your
> situation, you might have the following:
>
> Component name: com_sportsmanagement
>

> *Main Controller:*

> Class Name: SportsManagementController
> Filename: /controller.php
> Description: This could be used to redirect to your default "list"
> controller. For example, a list of Leagues or even showing a menu of some
> sort seeing as you have many tables or entities to manage.
>

> *Leagues Controller:*

> Class Name: SportsManagementControllerLeagues
> Filename: /controllers/leagues.php
> Description: This controller would handle everything to do with lists of
> Leagues. For example, viewing leagues, delete a league or many selected
> leagues
>

> *League Controller:*

> Class Name: SportsManagementControllerLeague
> Filename: /controllers/league.php
> Description: This controller would handle adding/modifying/perhaps removing
> a single League
>
> The same structure would apply to your models and views:

> *League Model:*

> Class Name: SportsManagementModelLeague
> Filename: models/league.php
> Description: Contains logic to fetch a single league for display, edit,
> create (would be array/object representing a new league with default values
> for some fields etc.)
>

> *Leagues Model:*

> Class Name: SportsManagementModelLeagues
> Filename: models/leagues.php
> Description: Contains logic to fetch a list of leagues, handle pagination,
> update display order, etc.
>
> Following the above structure, you'll find as things get more complex, it is
> easier to keep track of code, etc. Also, I've noticed that when using a
> structure like the above, the Joomla! MVC convenience methods all seem to
> fall into place.
>

> *Things I've noticed that you might want to avoid/keep in mind:*

> On Sat, Feb 5, 2011 at 10:16 AM, sportinu...@gmail.com <

>
>
>
> sportinu...@gmail.com> wrote:
> > All,
> > I am attempting my first Joomla 1.5 component.  It is a sports league
> > management component.  I am starting with the backend.  Can some one
> > point me to a good implemntation of a backend,  I have many tabel to
> > administer,  and need a nudge on how to set up the main contoller
> > which I assume will let me choose a atbel then use a specific table/
> > modle controler?
>
> > Thanks!
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Joomla! General Development" group.
> > To post to this group, send an email to
> > joomla-de...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > joomla-dev-gene...@googlegroups.com<joomla-dev-general%2Bunsubs­cr...@googlegroups.com>
> > .

> > For more options, visit this group at

> >http://groups.google.com/group/joomla-dev-general?hl=en-GB.- Hide quoted text -
>
> - Show quoted text -

[AJ]

Everything you could want to know is in the book you mentioned, however, as with most tutorials on the subject, discussion on structure and how it ties into the Joomla! MVC implementation can be a little thin.

Points to keep in mind though could include: design models with intention of reusing in the front end, make use of global html snippets for toolbar construction, place reusable code snippets in base controller/model/view class or in helpers, keeping to a structure as mentioned before, makes loading models and views much easier in Joomla! components, try to keep responsibility of models and controllers to managing a single record or a set of records from a single table. You may find that adding functionality for directly related tables fits well in here. So no need to create a controller/model for #__sm_league and #__sm_users_in_league because chances are the user controller/model will handle that when saving a users data.

An example of what I was talking about regarding model methods that accept parameters rather than relying on "global" values inside the model methods is shown belowl:

Say you have a method called model::getLeagueByUser(); It might look like this initially:

class SportsManagementModelLeague extends JModel
{
    public function getLeagueByUser()
    {
        $user =& JFactory::getUser();
        $user_id = (int)$user->get('id');
        $sql = "SELECT l.* FROM #__sm_league l WHERE l.id
                   IN (SELECT id FROM #__sm_users_in_league WHERE user_id = $user_id )";

       // set query
       // load object
       // return
    }
}

Down the road, you may end up wanting to do reports based on user id, etc. Seeing as the model accesses the user object directly there is no way to set the id of the user you want to get the league for. A better version might be

class SportsManagementModelLeague extends JModel
{
    public function getLeagueByUser($id = 0)
    {
        $user_id = (int)$id;
        if (!$user_id) {
            $user =& JFactory::getUser();
            $user_id = (int)$user->get('id');
        }

        $sql = "SELECT l.* FROM #__sm_league l WHERE l.id
                   IN (SELECT id FROM #__sm_users_in_league WHERE user_id = $user_id )";

       // set query
       // load object
       // return
    }
}

Another thing I was pointing out when mentioning that stuff is that I don't like to rely on JRequest::getVar('user_id') inside of models. While it might seem easier in the beginning, you will probably find yourself constantly going back to your model classes to see the exact name of the JRequest var key that you used for that parameter in that model method. Things can start to get a little more complicated than needed, in my opinion anyway. Example of using JRequest inside the model might look like:

class SportsManagementModelLeague extends JModel
{
    public function getLeagueByUser()
    {
        $user_id = JRequest::getInt('user_id', 0);

        if (!$user_id) {
            $user =& JFactory::getUser();
            $user_id = (int)$user->get('id');
        }

        $sql = "SELECT l.* FROM #__sm_league l WHERE l.id
                   IN (SELECT id FROM #__sm_users_in_league WHERE user_id = $user_id )";

       // set query
       // load object
       // return
    }
}

Just my thoughts on the subject. I've found there is no right way to build mvc components for Joomla! but following certain patters and directory structures, you can really take advantage of the full Joomla! MVC implementation.

Thanks,
AJ

To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.

[sport...@gmail.com]

Thanks for the info. I was thinking that the user could be involved
in more than one league, so you would have to dump all leagues or have
a stricter search criteria. You say you do not like Jrequest so do
you just use $_get, $_post and do your own value validation or
sanitisation?

> On Sat, Feb 5, 2011 at 12:10 PM, sportinu...@gmail.com <

> > > > joomla-dev-gene...@googlegroups.com<joomla-dev-general%2Bunsu...@googlegroups.com>

> > <joomla-dev-general%2Bunsubs­cr...@googlegroups.com>
> > > > .
> > > > For more options, visit this group at
> > > >http://groups.google.com/group/joomla-dev-general?hl=en-GB.-Hide
> > quoted text -
>
> > > - Show quoted text -
>
> > --
> > You received this message because you are subscribed to the Google Groups
> > "Joomla! General Development" group.
> > To post to this group, send an email to
> > joomla-de...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > joomla-dev-gene...@googlegroups.com<joomla-dev-general%2Bunsu...@googlegroups.com>

[AJ]

Hi, I was just using that as a random example off the top of my head. It's not that I don't like JRequest, it's a great feature of the Joomla! framework. What I was saying is that I don't like using it within the model directly. I prefer to pass in any external data that the model might use to find/manipulate data. For example, the second example below just seems more natural to me. Again, all personal preference though i suppose.

$league = $model->getLeague();  // This example assumes the league identifier is set in the request vars somewhere
$league = $model->getLeague(234) // This example expects an id is passed in as a parameter

I would imagine there is a reason why a lot of the examples i see use the first example, I guess I just like to feel a little more in control.

AJ

To unsubscribe from this group, send email to joomla-dev-gene...@googlegroups.com.

[sport...@gmail.com]

Thanks, I appreciate your info and opinion.

On Feb 6, 9:01 am, AJ <amagon...@gmail.com> wrote:
> Hi, I was just using that as a random example off the top of my head. It's
> not that I don't like JRequest, it's a great feature of the Joomla!
> framework. What I was saying is that I don't like using it within the model
> directly. I prefer to pass in any external data that the model might use to
> find/manipulate data. For example, the second example below just seems more
> natural to me. Again, all personal preference though i suppose.
>
> $league = $model->getLeague();  // This example assumes the league
> identifier is set in the request vars somewhere
> $league = $model->getLeague(234) // This example expects an id is passed in
> as a parameter
>
> I would imagine there is a reason why a lot of the examples i see use the
> first example, I guess I just like to feel a little more in control.
>
> AJ
>

> On Sun, Feb 6, 2011 at 9:34 AM, sportinu...@gmail.com <sportinu...@gmail.com

> ...
>
> read more »