yiisoft / yii2 Goto Github PK

• Minimal PHP version: #35
• mb_string: #26

The extension contains a set of widgets implementing various features provided by Twitter Bootstrap.

Either we need to implement a fallback or bump PHP version up to 5.4.

Similar to that in 1.1, except that we don't need other locale data (we will use PECL INTL).

Similar to that in 1.1.

https://github.com/yiisoft/yii2/wiki/Core-framework-code-style

Often we have a problem with supporting several servers. I propose prepare smart config and make it depends from environment.

My opinion the next syntax can help flexible load configuration during environment. We get element with key '' and add to him element with environment name.

return array (
    '' => array(
        'basePath'=>dirname(__FILE__).DIRECTORY_SEPARATOR.'..',
        'name'=>'****',

        'db'=>array(
            'connectionString' => 'mysql:host=localhost;dbname=name',
            'emulatePrepare' => true,
            'username' => 'aaaa',
            'password' => 'aaaa',
            'charset' => 'utf8',
        ),
    ),

    'development' => array(

        'db'=>array (
            'username' => 'bbbb',
            'password' => 'bbbb',
        ),

    ),

    'test' => array()
)

This is more of a note, really. In forefront of yiisoft/yii#2183, @resurtm and I discussed that it might be worth to use the pecl::intl package instead of some 3^rd party userland library. Main reason being that pecl::intl is being shipped as a default extension since PHP v5.3.

I remember @samdark said (IIRC at YiiConf 2012) that mailing component will be bundled with the Yii2. We should make decision what's the best approach after all: to create SwiftMailer/PHPMailer wrapper component OR to design from scratch something totally new.

Existing extensions, references and projects:

• http://www.yiiframework.com/extension/mail
• http://swiftmailer.org/
• http://phpmailer.worxware.com/
• http://framework.zend.com/manual/1.12/en/zend.mail.html

Similar to that in 1.1. With locale-dependent support?

like it was done here: yiisoft/yii#2163

Similar as 1.1.
Please also refer to the implementation of DbCache and DbSession for API design of the class.

http://www.cubrid.org/

This ticket collects the minimal PHP version requirements from various classes. We will determine the final minimal version requirement when we finish the core framework classes.

• 5.3.2
  • stream_resolve_include_path
• 5.3.3
  • Json::decode(): use of constant JSON_ERROR_UTF8, http://us1.php.net/manual/en/function.json-last-error.php
• 5.3.7
  • SecurityHelper::generateSalt(): use of $2x$ and $2y$ Blowfish modes to deal with potential high-bit attacks. See http://www.php.net/manual/en/function.crypt.php
  • Fatal error handler doesn't work well on Windows in some cases for PHP < 5.3.7

The skeleton should contain multi-tier directory structure (something similar to http://www.yiiframework.com/wiki/155/the-directory-structure-of-the-yii-project-site).

It should contain tools supporting environment switching, deployment, etc.

It should contain a ready-to-use backend, and a nearly empty frontend.

TODO:

• rename backstage → backend

frontend

• Login/signup via Facebook (extension?)
• Signup.
• Password reset.

backstage

• Backstage layout.
• RBAC-controller controller permissions.
• Ability to generate frontend URLs.
• Error log viewer.

console

• Ability to generate frontend URLs.

Publishing a code snippet

\Yii::app()->clientScript->registerScript('name', 'some encoded js');

Packages

There should be no way to publish a file without defining a package for it in order
to support combining and processing assets. All the core classes, extensions and
modules should use packages.

Package definition

return array(
    'package1' => array(
        'basePath' => '@app/scripts'
        'map' => array(
            '*.js' => 'all.js', // append all JS into single file
            '*.ts' => 'all.js', // append all TypeScript into single file
        ),
        'process' => array(
            // how to deal with *.ts
            '*.ts' => function($fileName, $outputDir) {
                exec('…');
            }
        ),
    ),
    'package2' => array(
        'basePath' => '@app/styles',
        'map' => array(
            '*.less', // do not map, just include
        ),
        'process' => array(
            '*.less' => function($fileName, $outputDir) {
                exec(…);
            }
        ),
        'depends' => array(
            'package1',
        ),
    ),
);

Asset mappings

The idea of mappings is to be able to map one or more source files into same of less
number of destination files. Typically we have a number of source assets such as
a.js, b.js, c.js, d.js. We need to be able to map:

1. Every *.js to all.js.
2. a.js and b.js to ab.js while c.js and d.js to cd.js.

If all these from point 2 are separate packages, then if a is required ab.js
will be included in the page source.

By default each asset maps to the same named file.

Processing

1. Determine the order of the scripts based on dependencies.
2. Build ordered list.
3. Iterate list, write contents of each file from the file itself to the corresponding map file.

Adding package on the fly

\Yii::app()->clientScript->addPackage('name', array(...definition...));

Adding package to the page

\Yii::app()->clientScript->registerPackage('name');

When doing it:

• Check if package already registered. If yes, skip it.
• Check if package has dependencies. If yes, process these one by one first.
• Build a list of files from 'map'.
• Iterate over 'map'. For each record:
  • Find matching files. Check if these are matching processing rules. If yes,
    process file.
  • After file is processed (or processing is skipped), write it to the corresponding
    file from 'map' or the the same named file if not defined.

Package processing

Common tasks needed for resources:

1. Process resource content, write to the corresponding file. Processing can be either
   internal or external. Should be customizable per resource. Should support wildcards.
2. Map multiple resources into single file. Support either just mapping or actual
   writing.
3. Ability to specify how resource (or a wildcard) should be published
   (i.e. define a place on the page where it should be written).
4. Ability to define how exactly resources are included and in which order.

Extensions

If extension registers any resources it should be specified in application's
extensions section of the config. Each record will point to extension's config.

The whole process should be described in the extension's readme.md. Will be automated
in future in case of installing via Composer.

Modules

We have a list of currently enabled modules in the application config (modules)
so we can get package definitions from module config file located at moduleName/config/packages.php.

This is partially done: yii\helpers\ConsoleColor.
Remaining work:

• rethink API
• Grace fall back on unsupported terminals
• implement wrappers in console/Controller
• Test on most terminals
• complete documentation
• improve yii commands with color and other cute stuff
• not add support for magic properties as global options (needed for color switch)

This is a design discussion about what I18N features should be provided,what locale data are needed, and how they should be parsed and stored.

Better support for testing models and controllers.

possibly using Twitter bootstrap styles.

Service for collect resources(js,css) from included templates on page and merge it to one file. One for css and one for JavaScript.

好像了解下yii2的情况, 目前已经完成多少.为何不释出让大家看看.也能讨论下yii2的需求.

哎哟不错哟.沙发,哈哈!希望别关掉了...

It should require minimal user configuration, and should be eye catching (probably use Twitter Bootstrap styling). Its file structure should be similar to that in 1.1.

The goal is to provide a skeleton for very simple Web applications which contain some static pages and a couple of dynamic pages (e.g. company info pages.)

Some references:

• https://github.com/malyshev/yii-debug-toolbar
• http://cr0t.github.com/yiidebugtb/

Features to implement:

• Display internal route (module/controller/action).
• Display view files used during current request.
• Display SQL queries performed. Should be able to either display these sequentially, order by time, group similar queries while sorting by query count and displaying total time for a group.
• Display GET/POST etc.
• Provide API so developers will be able to add their own data to the toolbar.
• Display framework version.
• Display PHP version.
• Overall time/memory for the current page.

Similar to that in 1.1

Will implement:

redis (versions >= 2.6) (pull request: #905 merged)

• http://redis.io/topics/protocol
• https://github.com/nrk/predis/blob/v0.7/lib/Predis/Network/StreamConnection.php#L70
• https://github.com/Shumkov/Rediska
• https://github.com/ptrofimov/tinyredisclient/blob/master/src/TinyRedisClient.php
• phpnode: https://github.com/phpnode/YiiRedis/blob/master/ARedisRecord.php
• https://github.com/jdp/redisent/blob/master/src/redisent/Redis.php
• Cluster: https://github.com/colinmollenhour/credis
• Redis Connection Class
• Redis Active Record Class
• Redis Active Query Class
• Redis Extended Active Query Class (where, order, ...)
• Redis Relation Concept
• Redis Relation Implementation
• Redis Transaction Class (will not be implemented as retrieving values from redis is not possible in a transaction)
• Redis Cache (ready on master)
• Redis Session (via yii\web\CacheSession and yii\caching\RedisCache)

elastic search (pull request: #1295 merged)

• elastic search: https://github.com/phpnode/YiiBlocks/tree/master/elasticSearch
• Connection Class
• Active Record Class
• Active Query Class
• Relation Concept
• Relation Implementation
• Transaction Class(?)

mongodb (pull request: #1438 merged)

• http://docs.mongodb.org/manual/reference/sql-comparison/
• http://docs.mongodb.org/ecosystem/drivers/php-libraries/
• http://snmaynard.com/2012/10/17/things-i-wish-i-knew-about-mongodb-a-year-ago/
• http://www.yiiframework.com/extension/mongoyii/
• http://php.net/manual/en/class.mongoclient.php
• https://github.com/Sammaye/MongoYii
• https://github.com/canni/YiiMongoDbSuite
• Connection Class
• Active Record Class
• Active Query Class
• Relation Concept
• Relation Implementation
• Transaction Class(?)

Sphinx (Pull Request merged)

http://sphinxsearch.com/

Other systems that may get implemented (suggestions welcome):

• solr: https://github.com/phpnode/YiiSolr
• neo4j: https://github.com/Haensel/Neo4Yii
• couchdb: http://couchdb.apache.org/
• orientdb
  • http://www.orientdb.org/
  • https://github.com/AntonTerekhov/OrientDB-PHP
  • http://odino.org/graph-in-php-through-orientdb/
  • https://github.com/nuvolabase/orientdb

Other resources:

• https://github.com/Haensel/ActiveResource

In Yii 1.x, there is quite some code that seeks for support from PHP's multibyte string library, silently falling back if this extension is not installed. I'd like to propose turning mbstring into a required extension, improving multibyte string handling in a save fashion and increasing code readability in the core.

As I see it, this extension isn't too exotic for mass-webhosters as a number of applications either got soft or hard dependencies on mbstring (phpMyAdmin and Drupal got soft dependencies, Horde might cease function without it and I think same goes for Joomla).

I am not sure what is the best place to put wish list, But it would be really help full if the framework provides some better approach for raising and handling events between different modules. Application level interrupts you can say.
like if a user save function is called, i can handle beforeSave afterSave of User model, in some other module.

Similar to that in 1.1.

with commonly used image manipulation helper methods.

Should we use reCAPTCHA or our own fonts?

Similar to that in 1.1, but should be better designed (consistent with the design used in bootstrap extension).

1. In the application messageSource there should be sourcePaths property with empty array as default value.
2. When searching for message files application message source component will start with paths from sourcePaths. If nothing matches it will fallback to default behavior i.e. checking application's messages directory (or what's set as messages directory).
3. Extension author will be able to register additional message sources for his extension like the following:

\Yii::$app->messageSource['myExtension'] = __DIR__.'/messages';

A good place to have the code above is init method in case it's a Component or __construct if it's just a regular PHP class.