how is Yii2 supposed to be better compared to Y1.1 from different points of view:
– architectural
– speed, efficiency
– integration with other frameworks (Bootstrap, …)
– any other reasons why you are creating 2.0
In other words, documentation that can help me decide whether now is the time for me to invest in moving to Yii2 and whether it is worth the trouble. I am developing a rather larger web application (not your usual website, but a true application) in Yii1.1. Parts of it could be written in Yii2 since it will consist of multiple sites working together on the same data.
I am sure there must be documentation out there that describes the goals of 2.0 and how those compare to 1.1.
Yet the only links I found are these in the readme of the github repository.
There’s no long term roadmap yet. It will be set after stable release. As for now, there will be beta at the end of this week. Then 2—3 weeks of polishing, more polishing, RC and then stable.
2.1) In architectural terms 2.0 is the new framework with the best taken from 1.1 and then significantly improved. It’s more flexible, with better syntax and actually simpler in its core.
2.2) As for speed, Yii itself was never a bottleneck. We care about performance but not fanatically. In my personal tests 2.0 was faster than 1.1 (for a test I’ve built simple apps using some views + active record backed by MySQL).
2.3) 2.0 is definitely more efficient than 1.1 in terms of development speed. There are more tools such as new debugger, much better error handling, a good number of official extensions and about 250 unofficial ones.
2.4) 2.0 is integrated with bootstrap via official extension package. It is used by default since bootstrap is very common nowadays but can be easily dropped with just a single Composer command. More stuff out of the box:
Twig
Smarty
Swiftmailer
Sphinx
EelasticSearch
Redis
MongoDB
jQueryUI
Imagine
Codeception
Faker
Auth clients (OAuth etc.)
2.5) We’re creating it because we work with Yii ourselves and see what can be improved constantly. In 1.0 some things weren’t too much revolutionary and compatibility breaking so these went into 1.1 but we had more and more ideas that were impossible to implement in 1.1 without breaking it and, since we’re taking it seriously, we’ve created 2.0 while continuing to support 1.1 (it is supported till 2016).
Thank you Samdark for your elaborate answer. And while I am at it, thank you and the Yii team for the Yii framework and the excellent documentation.
I have been reading the Yii2 docs to get a better insight into the big changes and I like what I see. The framework delivers the same functionality as before, only better architected, cleaner, with modern framework integration. There is not a real "paradigm shift", correct ?
Here are a few things that struck me when developing in Yii1.1, and at first sight will not be addressed in 2.0:
Yii is not a shield between the "outside world" and the web application. In Yii1.1 I find myself writing quite a lot of code just to test the validity of incoming data. As a developer I would expect the framework to sit between the incoming requests and the application, delivering only sanitized data. There are validation rules, but these validate only model attributes, not any hidden input fields needed to control application logic, or variables passed in the GET url. The UrlManager can be configured to only allow correct GET parameters, but that is not its purpose and would be awkward. Also, it would not allow corrective actions such as inserting default values or raising errors. It would be nice to have the option to tell the framework about any other parameters coming in (other than the active attributes) and what to do when these are missing or tampered with. This could be an option for a whole controller or per action within a controller.
Date and number formatting. There are tools in the framework to format a date or number into a desired format, but that only solves halve the problem. When data is coming into the application, it will be in the local format and will have to be translated back into a system format (e.g. to do date calculations, to save it as a datetime).
It would be very handy if there would be an option to set the application’s datetime and number format (i.e. the formatting the user will see) and have the framework do the translation automatically. That way a developer can set the format once and be sure that whenever he handles a date, it will be in that format. The framework converts automatically when saving/loading.
In my case, all dates are dd/mm/yyyy and numbers use a comma as decimal seperator. In Yii1.1 I implemented this with afterFind and beforeSave of CActiverRecordBehavior. It can be done, it just feels like this should be part of the framework.
For most applications this point will be of minor importance, but for some I think it can have a performace impact: there is no way to tell wether a POST with model data actually contains edited data or that the user simply clicked the submit button to close the window (or whatever the next step in the application is). What happens if you follow the standard Yii way is: the model is loaded from the database, attributes get massively assigned, then the model is updated in the database. This is an expensive operation, especially the update.
Adding a checksum to the model (calculated after loading from the database and after any behaviors have formatted values) could be compared to a freshly calculated checksum when the data comes back. The model would know it was not edited so no update is necessary.
I have implemented this in Yii1.1, but it is pretty complicated since behaviors and validations can modify attribute values. But what I have is a model that behaves exactly like a CActiveRecord and “knows” whether or not it is dirty. Note that this differs from the Yii2 dirtyAttributes implementation, since I believe this will not take into account behaviors and validation rules that modify a model’s attributes (i.e. in Yii2 a model will be dirty as soon as a behavior changed a value).
Sorry for this long post, but maybe it can be inspirational for future development.
Yes. I think Yii paradigm is good for what it is intended for in 1.1 so there was no point changing it in 2.0 slightly.
You can’t really automatically sanitize against every possible attack vector for all possible data types. That’s why you should use whitelisting instead of sanitizing when possible and sanitize depending on context in the rest of the cases.
Anyway, if you have ideas how to make developer’s life easier, post at github and we’ll discuss how it can be applied to the framework and the implementation details.
Yeah, I think there’s no change about it in 2.0. At least for now. There were tickets at github, you may search and propose solutions.
If behavior changed a value it probably should be saved. Shouldn’t it?
3). 2.0 has dirty attribute feature. If there is no change to your loaded model (i.e., the user inputs are the same as the existing values), no actual DB update will be performed.
save, which first calls beforeSave (e.g. cast to format for database, audit info), then updates
The model is in the form as it was presented to the user in step 2 (obviously), but also at the end of step 4. So calculate the checksum at step 4, then when save() is called (and before any beforeSave), compare the current checksum with the previously calculated one. If equal: no save needed. (my model returns true, and sets a flag to indicate no actual data was written to the database)
Upon a find() a behavior modifies it to 11/04/2014.
If a user has not edited the date, the date remains 11/04/2014, i.e. the value after the modification by the behavior.
To decide whether a record is dirty or not, you want to compare the POST data to the loaded model after behaviors have done their job.
(you could even take a philosophical look at it: if the user did not change any user editable fields, why would you decide that this record is dirty and not some other random record that he also did not touch ?)
What if the user changes the value to 11/01/2014? Do you have code to format it to YYYY-MM-DD before saving to DB? If you are relying on DB to do this conversion, then nope, Yii doesn’t support this and will not. If you have code to do the conversion, then I don’t see a problem.
Changing from the "application format" to the database format happens in beforeSave (via behavior).
So if the user changes a value from 11/04/2014 to 11/01/2014, then it is exactly this that is compared and thus decided to be dirty.
The save then changes 11/01/2014 to 2014-01-11 before the actual sql update happens.
What you do not want to compare is 11/01/2014 with 2014-04-11, i.e. you do not want to compare user input in application format from POST with the value after loading from the database. The record will always be dirty, regardless of user input.
If you change back the format in beforeSave, then I don’t see a problem because the dirty detection happens after beforeSave().
After the model is loaded, the attribute is changed from 2014-04-11 to 11/04/2014 by your behavior. At this stage, the attribute is dirty.
If the user makes no change and you save the model, your behavior will change back the format to 2014-04-11 in beforeSave(). At this stage, the attribute is NOT dirty. As a result, the code after beforeSave() will not save this attribute.
That is not a problem, au contraire, that is excellent!
Audit attributes though will always be dirty (new update time set in the behavior) and should be ignored.
Looking at the BaseActiveRecord code, I see it can be done:
if ($model->getDirtyAttributes(array_of_attributes_except_audit)!==[])
$model->update(); //update all dirty attributes
It could be done more efficiently if there were an unmarkAttributeDirty.
Please allow me to make 2 more remarks:
null values in the database come back as empty strings in the POST. In that case you will consider them as changed. In the database these might remain null though. In Yii1.1 this is CDbColumnSchema->typecast that will do this during the save() operation.
if you only need to know whether the record is dirty, then calculating a hash is probably more efficient, e.g. md5(serialize($this->getAttributes()).
