Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Message from discussion Object oriented components , any plan?
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Duccio Gasparri  
View profile  
 More options Apr 19 2012, 10:19 am
From: Duccio Gasparri <duccio.gaspa...@gmail.com>
Date: Thu, 19 Apr 2012 07:19:23 -0700 (PDT)
Local: Thurs, Apr 19 2012 10:19 am
Subject: Re: [jcms] Object oriented components , any plan?

I did pull 193 (about JController::factory) and 194 (componentHelper)
https://github.com/joomla/joomla-cms/pull/193 and
https://github.com/joomla/joomla-cms/pull/194 if you want to take a look.

The real issue with com_media is from line 43 to 75 of media.php:

$cmd    = JRequest::getCmd('task', null);

if (strpos($cmd, '.') != false) {
[...]

// Set the name for the controller and instantiate it
$controllerClass = 'MediaController'.ucfirst($controllerName);

if (class_exists($controllerClass)) {
    $controller = new $controllerClass();

}

else {
    JError::raiseError(500, JText::_('JERROR_INVALID_CONTROLLER_CLASS'));

}

because it does exactly what the new renderComponent would do. It is about
simplifying it rather than recoding it, but before moving forward with all
the libraries I'd like to hear if the pulls I did on GitHub are in the
right direction.

I'm stuck in those two issues:

1) do we want to mantain both com_example/example.php and
com_example/controller.php files? Should we decide to merge it in one
single file? (controller.php? example.php, which would be the standard one?)
2) for the components that do other stuff, where do we want to put it? In
the base file as they are now, they would be loaded so it is not an issue
to "leave them there". But looking forward, let's try to find a better
place.

There are two kinds of stuff that could be done at startup, the general
bootstrapping (such as defining constants) which should be done only once
and maybe called statically, and an init() for (for example) checking if
the user is authorized, which should be more associated with execute than
to __construct().

Four options come to my mind:
       a) create hooks inside JController (onBootstrap, onBeforeFactory and
onAfterFactory, onBeforeExecute and onAfterExecute)
       b) similar to the previous one, leave people free to overload the
factory and __construct methods without creating a hook  (function
factory(..) { /* ... do your stufff */ $instance = parent::factory(); /* do
other stuff */ }
       c) create a init() method to be called right after __construct(); so
that if I want to just set a couple of variable, I can just define this
init() function
       d) create a static bootstrap() method to be called once by factory()
or by construct()

The more we add methods, the less clear the code will be to understand and
to extend/change so we must be careful. Point c can be just done
overloading __construct() and point d by overloading factory and
contructor, but init and bootstrap are quite easy to remember and I don't
see them as big issues.

I have no clue on what could be the best option...

On Thursday, April 19, 2012 2:49:24 PM UTC+2, elin wrote:

> The scary one to look at is com_media in the front end, someone needs to
> take up refactoring that one....

> In com_banners we have ...

> $controller->execute(JRequest::getVar('task', 'click'));

> Also  ... we are requiring all these specific helpers by name but why not
> just assume that if there is a helper in the right place it should be
> loaded or even better load it when it is actually needed?

> Elin

> On Tuesday, April 17, 2012 4:08:15 PM UTC-4, Rouven Weßling wrote:

>> That has already happened. However I don't think that impacts Duccio's
>> proposal. JComponentHelper is eventually going to leave the platform
>> anyways. (it will be moved to the CMS than).

>> What I'm wondering is, if components currently do anything else in their
>> main file to bootstap the extension that couldn't be done in controllers
>> constructor?

>> Also I wonder if there's a backward compatibility impact.

>> Otherwise I quite like the idea, it could help reduce the amount of
>> essentially duplicate code quite a bit.

>> Rouven


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.