Здравей,

Супер тема. Ще се възползвам освен да ти отговоря и да направя едно цялостно пояснение за фреймуърка, който се изисква, така че се надявам да стане ясно за всички, които евентуално имат въпроси :)

1. Иска се раутинг система по подразбиране, която в общия случай е controller/action/parameter1/parameter2

2. Иска се някакъв лесен начин, дивелъпърът да може да конфигурира различна раутинг система. Би било хубаво дефолтната да остане в сила, освен ако той изрично не е казал да се използва единствено и само неговата. Т.е. каква е идеята:

- Ако имаме два контролера - Users и Topics и двата контролера миат метод add() и имаме конфигурация, която казва, че като извикаш с POST usertopics/addnewtopic/ ще се извика TopicsController->add(), то трябва когато потребителят достъпи:

    2.1. users/add - да извика UserController->add();

    2.2 topics/add - да не се извика нищо, евентуално да даде грешка, че такъв раут не съществува  

    2.3. usertopics/addnewtopic - да извика TopicsController->add()

- т.е. кастъм раутовете са с по-голям приоритет от тези по подразбиране

3. Areas са нещо като модули, които си имат собствени контролери. Ако например правиш комплексно приложение и то си има в него форум (както например системата на СофтУни) - то форумът е една Area. представяме си го като една папка Areas в нея папка Forum и в нея контролери, модели и вю-та. В такъв случай site.com/forum/topics/read/6 ще извика от Froum area-та, TopicsController->read(6)

3.1. Иска се да има лесен начин да се дефинират къстъм раутове за area-та, които отново имат по-висок приоритет от раутовете по подразбиране. Конфигът на една Area не може да пипа в конфига на глобалния сайт или на другиа Area

4. Strongly typed views са вю-та, които можеш да извикаш само и единствено с определен тип модел. Нека си представим, че имаш View-то views/users/edit.php и да речем, че за да деноутваш, че определено вю приема само определен модел, то най-отгоре във вю-то си сложил анотация за модел променливата

/** @var \MyFramework\Models\User $model */

От тук даже IDE-то занапред в страницата, когато извикаш $model-> ще дава подсказки за методите от този клас

Когато, да речем, от контролера UsersController, метода edit() искаш да върнеш View и да му подадеш информация, си длъжен да подадеш обект от този тип \MyFramework\Models\User и ако не го направиш, трябва апп-а да гръмне когато се окаже, че си се опитал да достъпиш това вю, но на него не му е подадем обект от същия тип.

Вярно:

class UsersController
{
   public function edit($id)
   {
      $userData = $this->repo->getUsers()->findOneById($id);
      $user = new \MyFramework\Models\User($userData['name'], $userData['email']);
      return new View($user);
    }
}

Грешно:

class UsersController
{
   public function edit($id)
   {
      $userData = $this->repo->getUsers()->findOneById($id);
      $user = new \MyFramework\Services\TopicService($userData['name'], $userData['email']);
      return new View($user);
    }

5. Binding model-и - тук се иска да може определени методи, които ще се ползват за POST да приемат обект от определен тип и фреймуъркът като диспачва рикуеста, да хване какво има в POST масива и да напълни с него обект от съответния тип и да извика метода с вече напълнения обект. Ако има несъотвествия в POST масива със сигнатурата на байндинг модел обекта - да мята грешка.

Например

class UsersController
{
   public function edit(UserBindingModel $user)
   {
       $this->repo->getUsers()
           ->findOneById($user->getId())
           ->setName($user->getName())
           ->setEmail($user->getEmail())
       ->save();
   }
}

Горе долу става ясно, че този UserBindingModel явно има $id, $name, $email. В такъв случай, ако в $_POST няма ключовете id, name, email то нещо не е наред. Ако ги има - трябва да създаде този обект и да извика edit() с него

6. ViewHelper-ите са някакво консистентно API с което лесно може да се рендира HTML, използвайки РНР., например:

FormViewHelper::init()
    ->initTextBox()
         ->setName('username')
         ->setValue('pesho')
         ->setAttribute('class', 'field-green')
         ->create()
    ->initPasswordBox()
         ->setName('password')
         ->setAttribute('id', 'input-pass')
         ->create()
    ->render();

7. Анотации - това са коментари (doc blocks), които могат да се слага преди декларацията на някой клас/метод. Има езервирани тагове/анотации от PHPDoc като @param, @return и т.н. Тук се иска да си измислим наши си и даправим някакви действия, когато над някой метод съществува такава анотация. Анотациите могат да се четат с рифлекшън и тук идеята е, за да се диспачне рикуеста да се сканират контролерите и техните методи и да се види дали някой не притежава анотация, която да отговаря на текущия рикуест. Например дали над някой метод не пише

/**
* @POST
* @Route("user/profile")
* @param UserBindingModel $user
* @return View
*/
public function edit(UserBindingModel $user)
{

Което значи, че ако е дошъл рикуест user/profile през POST-а, трябва да се сканира методите и да видят дали някой няма точно това, което го има по-горе и ако го имат - да извика него.

8. Dependency Injection - тук се иска в някакъв конфигурационен файл да се опишат зависимостите на обектите и когато фреймуъркът трябва да вдигне даде обект (контролер) да провер в конфигурацията дали той не зависи от някакви обекти и съответно да ги инстанцира тях и да му ги подаде.

Например

class UsersController
{
     /**
     * @var \MyFramework\Data\IRepository
     */
     private $repo;

    public function edit(UserBindingModel $user)
    {
        $this->repo->getUsers()...

Ще резултира в Call to an undefined method getUsers() on a non-object ако $repo не е инициализирано. И тъй като не е инициализирано, ще трбябва фреймуъркът да види дали в конфигурацията някъде не е описана тази зависимост и да я резолне. Може обаче тази зависимост да зависи от други неща и ще трябва да резолвне и тях, за да я инстанцира нея. Например XML конфигурация:

<controller name="UsersController">
     <dependency name="repo" type="\MyFramework\Data\IRepository" mapTo="\MyFramework\Data\UsersRepository">
         <dependency name="db" type="\MyFramework\Adapters\IDatabaseAdapter" mapTo="\MyFramework\Adapters\MySQLAdapter" />
     </dependency>
</controller>

Тук трябва фреймуъркът да разпознае, че UsersController има зависимост с име 'repo' която е от определен тип, а нейният конкретен обект е UsersRepository. Обаче пък тази зависимост си има нейна зависимост с име на полето 'db', която е от определен тип, а обектът, който трябва да направи е MySQLAdapter. Трябва да се получи нещо като

$db = new MySQLAdapter();
$repo = new UsersRepository();
$repo->db = $db;
$usersController = new UsersController();
$usersController->repo = $repo;

$usersController->edit($user)

Разбира се през рифлекшън, тъй като например полетата $db и $repo в съответните класове бяха private.

Здравейте :)

Искам да попитам за вмъкването на Binding моделите в контролерите.

class TopicsController
{
    public function listTopics($someId, UserBindingModel $m ) //this is line 15
    {
    }
}

Горния код връща Catchable fatal error: Argument 2 passed to App\Areas\Forum\Controllers\TopicsController::listTopics() must be an instance of App\Bindings\UserBindingModel, null given inC:\xampp2\htdocs\project.com\app\areas\forum\controllers\TopicsController.php on line 15

В случая listTopics се вика при POST и самото байндване работи. Ако го махна "UserBindingModel $m" от параметрите и в самия метод добавя:

$g = new UserBindingModel();
echo $g->getName();

работи без никакъв проблем, ако приемем че в POST заявката имам ключ name.

Как може да се направи така, че да работи кода от първия snippet?

Аз отново имам питане, този път конкретно по CMS заданието. Захванах се да го мъча него, но ми звучи малко абстрактно като изисквания. Първо, става въпрос за ивентите:

• The Editor can attach events to these elements (e.g. what to happen when form posts)
• There have to be different predefined events (mail sending, db storage, comments (the posted form content could be later visible somewhere in the site)

@Royal, ще съм благодарен на едно две пояснителни изречения. Какво точно (или може би как се иска от нас) да имплементираме по тия две точки? Ще се радвам и колегите да се включат, ако имат идея или си представят как би могла да бъде реализирана идеята по тези точки. Трудно ми е да формулирам конкретен въпрос, защото ми бяга контекста/идеята на това...

Отделно за гридовете - отново - каква е идеята им, за какво ще се ползват и как си го представяте. На мен още ми е трудно да вникна конкретно в тези два детайла, а ми се иска, защото искам да дефинирам цялостното поведение на цмс-а, преди да го имплементирам.

Мерси отново и поздрави! :)