Laravel игнорирует метод в контроллере

#laravel #controller #php #маршрутизация

                    
Есть контроллер:
class HomeController extends BaseController {
    public function index() {
        return View::make('hello');
    }
}

и при наличии роута:
Route::get('/', 'HomeController@index');

появляется ошибка:
BadMethodCallException 
Method [index] does not exist.

Команда php artisan routes, возвращает то что нужно:
+--------+------------+------+----------------------+----------------+---------------+
| Domain | URI        | Name | Action               | Before Filters | After Filters |
+--------+------------+------+----------------------+----------------+---------------+
|        | GET|HEAD / |      | HomeController@index |                |               |
+--------+------------+------+----------------------+----------------+---------------+

Версия: Laravel 4.2.11    

Ответы

Ответ 1

Проблема решена. Вся проблема была в том что в папке vendor/laravel находилась папка
laravel полностью дублирующая корневую директорию из-за этого пространства имен спутались
и поиск был не в корневой директории а в папке vendor.
Пригодится кому-нибудь на будущее. :)


Ответ 2

А в HomeController у Вас, видимо, дефолтный метод остался, да?
Попробуйте роут прописать как-нибудь так:
Route::get('/', ['as' => 'home', 'uses' => 'HomeController@showWelcome']);

Ещё может быть косяк с автолоадингом. Попробуйте:

удалить папку vendor
удалить файл bootstrap/compiled.php
запустите composer update

JavaFX FXML, для чего Controller?

#java #javafx #controller #fxml

В уроках об FXML говорится об пользе и преимуществах разделения интерфейса и логики
в программах, но есть ещё непонятный мне класс "Controller" (помимо классов логики
и интерфейса) . В чём его идея, какую функцию он выполняет? В чём преимущество такого
подхода? 
    

Ответы

Ответ 1

Возможно, Вам будет интересно мое мнение:

Лично я считаю, что термин "controller" в документации FXML следует воспринимать
не более, чем то, что в других технологиях называется "code behind".

То есть это просто дополнительный код для выполнения задач связанных с отображением
"вида" (view). (Под "видом" я здесь имею в виду конкретный участок пользовательского
интерфейса).

FXMLLoader с помощью инъекций связывает объект контроллера с деревом объектов,
которое он нагенерил по fxml-разметке. А также предоставляет некоторые другие 
возможности, например, одностороннюю привязку ("${expression}") атрибутов-свойств
и прочее.

Но вот, к примеру, двусторонняя привязка ("#{...}") FXMLLoader'ом так до сих пор
не реализована,
и класс контроллера — это как раз подходящее место для ее описания.

Без сомнения, то, что будет в этом "code behind" полностью зависит от вашего подхода
и самодисциплины.
Как со стороны размещения бизнес-логики, так и со стороны разделения зон ответственности
программиста и дизайнера.

Именно Вам решать, будет ли этот класс толстым носителем логики, или лишь тонкой
прослойкой между моделью и видом.

При этом, даже, если вы будуте использовать какой-то определенный фреймворк (например,
mvvmFx),
то это не спасет вас от возможности ошибочно разместить часть бизнес-логики модели
в "code behind"
определенного вида (эта ошибка может и обнаружится, когда такая функциональность
потребуется в другом месте).

С другой стороны, помня о том, что css-стили (кроме USER_AGENT) имеют определенное
преимущество над JavaFx-свойствами узлов, 
в контроллере имеет смысл описывать настройки интерфейса с помощью JavaFx-свойств,
а не заданием css-стилей —
для того, чтобы дизайнер впоследствии смог исправить интерфейс указанием css-стилей.
И даже в этом случае программист может сказать свое "последнее слово", восстанавливая
значение свойства в обработчике изменения этого свойства ;)



Под словами "определенное преимущество" я имею ввиду то, что 
css-стиль перекрывает соответствующее ему свойство. Но только в момент
перепроверки стилей. А до этой перепроверки будет действовать свойство.
Например, можно установить какое-либо свойство узлу (в обработчике нажатия другой
кнопки) и это будет отражено на экране, но при наведении на узел курсора мыши, узлу
устанавливается
псевдокласс hover и выполняется переустановка его стилей в соответствии
с псевдоклассом, тем самым свойство будет заменено стилем. После того, 
как курсор мыши будет убран с узла, у него будет также убран псевдокласс hover. Это
изменение псевдоклассов опять повлечет переустановку стилей узла, но в этих стилях
не указано то изменение, которое делалось для свойства в обработчике. Поэтому свойство
на экране отражено не будет, хотя оно и работало вначале некоторое время.

Yii2 имя текущего контроллера в модуле

#php #yii2 #controller #modules

Есть базовый класс для всех модулей

namespace app\components;

use Yii;

class Module extends \yii\base\Module
{
    public function init()
    {
        parent::init();

        var_dump(Yii::$app->controller->id); // null :(
    }
}


Все модули расширяются от него, т.е.

namespace app\modules\test;

class Module extends \app\components\Module
{
    //
}


Как мне получить название текущего контроллера в базовом классе модуля ? 

Yii::$app->controller->id


возвращает null
    

Ответы

Ответ 1

Ну для начала не 

Yii::$app->controller->id


а 

Yii::app()->controller->id


Тогда он выдаст тебе название контроллера.

//UPD

Ты вызываешь его из init() модуля. Что может дать тебе этот вызов, если он не значет
какой контроллер у тебя сейчас.
Он и будет тебе всегда NULL показывать!

и если вопрос звучит именно так


  Как мне получить название текущего контроллера в базовом классе модуля
  ?


то ответ никак. т.к. модуль не знает о контроллере ничего чтобы выдать какую-то информацию.


Ответ 2

Я думаю самым простым решением будет создание еще одного класса от которого будут
наследоваться все остальные, в котором можно делать операции с ид контроллеров.

class MainController extends yii\base\Controller { 
    // some... 
     public function beforeAction($event)
    {
         $ct = $event->controller->id; // current ctrl
         return parent::beforeAction($event);
    }
 }


А от него наследовать уже все остальные контроллеры 

class PostController extends MainController {   // do something... }

Laravel игнорирует метод в контроллере

Есть контроллер: class HomeController extends BaseController { public function index() { return View::make('hello'); } } и при наличии роута: Route::get('/', 'HomeController@index'); появляется ошибка: BadMethodCallException Method [index] does not exist. Команда php artisan routes, возвращает то что нужно: +--------+------------+------+----------------------+----------------+---------------+ | Domain | URI | Name | Action | Before Filters | After Filters | +--------+------------+------+----------------------+----------------+---------------+ | | GET|HEAD / | | HomeController@index | | | +--------+------------+------+----------------------+----------------+---------------+ Версия: Laravel 4.2.11

Ответ

Проблема решена. Вся проблема была в том что в папке vendor/laravel находилась папка laravel полностью дублирующая корневую директорию из-за этого пространства имен спутались и поиск был не в корневой директории а в папке vendor Пригодится кому-нибудь на будущее. :)

JavaFX FXML, для чего Controller?

В уроках об FXML говорится об пользе и преимуществах разделения интерфейса и логики в программах, но есть ещё непонятный мне класс "Controller" (помимо классов логики и интерфейса) . В чём его идея, какую функцию он выполняет? В чём преимущество такого подхода?

Ответ

Возможно, Вам будет интересно мое мнение:
Лично я считаю, что термин "controller" в документации FXML следует воспринимать не более, чем то, что в других технологиях называется "code behind".
То есть это просто дополнительный код для выполнения задач связанных с отображением "вида" (view). (Под "видом" я здесь имею в виду конкретный участок пользовательского интерфейса).
FXMLLoader с помощью инъекций связывает объект контроллера с деревом объектов, которое он нагенерил по fxml-разметке. А также предоставляет некоторые другие возможности, например, одностороннюю привязку ("${expression}") атрибутов-свойств и прочее.
Но вот, к примеру, двусторонняя привязка ("#{...}") FXMLLoader'ом так до сих пор не реализована, и класс контроллера — это как раз подходящее место для ее описания.
Без сомнения, то, что будет в этом "code behind" полностью зависит от вашего подхода и самодисциплины. Как со стороны размещения бизнес-логики, так и со стороны разделения зон ответственности программиста и дизайнера.
Именно Вам решать, будет ли этот класс толстым носителем логики, или лишь тонкой прослойкой между моделью и видом.
При этом, даже, если вы будуте использовать какой-то определенный фреймворк (например, mvvmFx), то это не спасет вас от возможности ошибочно разместить часть бизнес-логики модели в "code behind" определенного вида (эта ошибка может и обнаружится, когда такая функциональность потребуется в другом месте).
С другой стороны, помня о том, что css-стили (кроме USER_AGENT) имеют определенное преимущество над JavaFx-свойствами узлов, в контроллере имеет смысл описывать настройки интерфейса с помощью JavaFx-свойств, а не заданием css-стилей — для того, чтобы дизайнер впоследствии смог исправить интерфейс указанием css-стилей. И даже в этом случае программист может сказать свое "последнее слово", восстанавливая значение свойства в обработчике изменения этого свойства ;)

Под словами "определенное преимущество" я имею ввиду то, что css-стиль перекрывает соответствующее ему свойство. Но только в момент перепроверки стилей. А до этой перепроверки будет действовать свойство. Например, можно установить какое-либо свойство узлу (в обработчике нажатия другой кнопки) и это будет отражено на экране, но при наведении на узел курсора мыши, узлу устанавливается псевдокласс hover и выполняется переустановка его стилей в соответствии с псевдоклассом, тем самым свойство будет заменено стилем. После того, как курсор мыши будет убран с узла, у него будет также убран псевдокласс hover. Это изменение псевдоклассов опять повлечет переустановку стилей узла, но в этих стилях не указано то изменение, которое делалось для свойства в обработчике. Поэтому свойство на экране отражено не будет, хотя оно и работало вначале некоторое время.