Yii 3.0 ideas for consideration

tahpot · December 30, 2018, 2:28am

Hi,

Firstly a big thank you to everyone involved in Yii. It’s a fantastic framework, very well designed, fast and incredibly flexible.

For the past 2 years I’ve used Yii2 for building many application for clients. As part of those projects, I have developed a lot of additional functionality which may be of interest to include or at least think about for Yii 3.0.

Advanced ActiveRecord

ActiveRecord is awesome, but it can be better

I’d like to see the concept of a field and fieldType that provides default rules(), labels() database save() and load() methods for pre/post processing of database data into a PHP format along with various metadata relating to the field.

You can see an implementation of this in Yii2 here:

https://github.com/Mozzler/yii2-base/blob/master/models/Model.php (see modelFields())

The concept of scenarios in Yii2 was new to me and it makes so much sense. In fact, I think it’s use should be expanded to be aligned with any action including view and index actions so an autogenerated CRUD layout can be generated using the fields in those scenarios.

Models have actions that have URL’s. A getUrl() method on a Model works really well and simplifies URL creation across most of the application.

RBAC

The current RBAC implementation is rather complicated to understand and configure while it heavily uses the database which isn’t particularly performant. It also only restricts access to controllers and not the underlying database.

The features I would like to see:

Only roles stored in the database for increased performance and no need to support migrations
Expand RBAC support to ActiveRecord to restrict access closer to the database for increased security and consistency of security rules across web and api applications.
Support security policies / rules that generate a filter to apply to the database to dynamically restrict result sets or database updates – this provides huge flexibility and leverages the performance of the database to do a lot of heavy lifting.
Leverage Yii’s excellent configuration mechanism to quickly configure permissions
Support controller inheritance so security policies attached on a parent are inherited by a child
Support configuration file to override default RBAC configuration defined within controllers

I have almost finished porting across code that does most of this in Yii2 here: https://github.com/Mozzler/yii2-rbac

Widgets

The concept of a widget as a re-usable piece of front end functionality is great, however the common use case is to have server code, javascript and CSS all working coherently together which requires fiddling with assets.

I would like to see widgets support a convention of auto-locating of relevant widget files. ie: You may have PanelWidget.php, PanelWidget.css, PanelWidget.js where the .css and .js are auto-loaded if they exist.

You can see a primitive implementation of this here:

github.com

Mozzler/yii2-base/blob/master/widgets/BaseWidget.php

<?php
namespace mozzler\base\widgets;

use yii\base\Widget;
use yii\helpers\ArrayHelper;
use yii\web\View as WebView;

use mozzler\base\helpers\WidgetHelper;

class BaseWidget extends Widget {
	
	public $viewName = null;
	public $dirName = null;
	public $config = [];
	
	public function defaultConfig()
	{
		return [
			'widgetConfig' => []
		];

This file has been truncated. show original

CRUD

Yii2’s Gii takes the approach of building CRUD controllers, views etc. as part of the build. I want to dynamically build the CRUD and allow for easily redesigning / customising a core CRUD application.

For the most part I actually want the views to be inherited based on the Model inheritance hierarchy.

For example, if I create a BaseModel with CRUD views (create, read, update, index) and then create a sub-model BlogPostModel that inherits from BaseModel, I would like those CRUD views to be “inherited”.

Under this approach, I could simply adjust the index linked to BaseModel to change the default template for all models in my application.

Extending this further, BlogPostModel may exist in a third party extension and I have extended it further with two new models MyImagePostModel and MyTextPostModel.

Under this approach, I have complete control over customising the view templates for each of MyImagePostModel and MyTextPostModel… or alternatively I can customise the view templates of BlogPostModel which will change both MyImagePostModel and MyTextPostModel at once… or alternatively I can customise BlogPostModel view templates to change everything,.

This becomes very powerful with larger applications and especially when having a “base” set of CRUD templates that can be rapidly re-styled across a whole application for a new project.

Again, I have implemented this in Yii2, with an added bonus of merging in controller inheritance.

github.com

Mozzler/yii2-base/blob/master/controllers/ModelController.php

<?php
namespace mozzler\base\controllers;

use mozzler\base\helpers\ControllerHelper;
use yii\helpers\ArrayHelper;

class ModelController extends WebController {
	
	public $modelClass;
	public static $moduleClass = 'mozzler\base\Module';
	
	public function init() {
		parent::init();
		
		$this->data['model'] = $this->getModel();
	}
	
	public function actions() {
		return ArrayHelper::merge(parent::actions(), [
			'create' => [

This file has been truncated. show original

github.com

Mozzler/yii2-base/blob/master/yii/web/View.php

<?php
namespace mozzler\base\yii\web;

use Yii;
use yii\web\View as WebView;
use yii\base\ViewContextInterface;
use yii\base\InvalidCallException;
use mozzler\base\controllers\WebController;


class View extends WebView {
	
	/**
     * @inheritdoc
     *
     * Add support for finding views based on controller hierarchy
     */
	protected function findViewFile($view, $context = null)
    {
        if (strncmp($view, '@', 1) === 0) {

This file has been truncated. show original

There’s a lot there and I’ve put these notes down quickly, so hopefully they make some sense!

Let me know if there’s any interest in the above and I may be able to free up some time to implement the above in Yii3.

Cheers,
Chris

machour · January 10, 2019, 7:41am

Hi Chris and thank you for your suggestions !

Here’s some feedback:

Advanced ActiveRecord: I’ve started looking at your implementation. I see some problematic stuff (like getUrl() which IMHO shouldn’t be there at all, as you are mixing concerns: app vs model).

As for field, I fail to see the benefit from your repo. Could you provide a sample of a model using this feature ?

RBAC: Are you aware that you can use PhpManager instead of the database to store data?

Adding RBAC to ActiveRecord seems to me like a mix of concerns again. Proper permissions should be checked before using AR.

Widgets: Not all widget use CSS/JS, so implementing this treatment automatically as a base wouldn’t make much sense.

CRUD: Being a heavy Gii user, I understand why you came up with this view inheritance approach. But this may not suit everyone’s needs / structure.

For example, the last app I’ve been building require totally different looking index/c/r/u/d layouts. Current Gii behavior allowed me to quickly stub all my views, before customizing them. If your mechanism was adopted as default, would that mean that I’d have to create all this files by hand?

This is why Gii enables you to create your own code-generation template to tailor the generated code to your taste.

All in all, I think that what you are proposing is implementable in user-land, i.e., on top of the current Yii framework. I’m convinced that every developer heavily relying on Yii for projects came up with their own private templates/components tailored for their own needs (just like you did here).

Yii goal is to be as generic as possible, and should remain like this.

You may want to post your suggestions as issues on the relevant repositories (yiisoft/rbac, yiisoft/yii-gii, …) to get more feedback from the core team.

mmx · December 26, 2019, 6:57am

Yii2 already allows him to do what he wants in the theme configuration block. You can redirect (substitute) the current crud view location to a views directory or modules directory added to the theme. I’m assuming this feature will be included with Yii3. The current Theme Styling docs need a bit of work to elaborate on this more. You can also use the same feature for component and widget views.