Using EMongoDataProvider with CListView reveals an other small bug. Yii expects the data returned from CDataProvider::fetchData() to be index based. Currently its an associative array where the key is representing the PK of the document.
The fix is very simple: In EMongoDataProvider:108 change this line
return iterator_to_array($this->_cursor);
to
return iterator_to_array($this->_cursor, false);
in order to generate an index-based array.
Indeed I do believe that function should return a index-based array, commited 
Surely there must be a way to put both a composer compatible autoloader in the source tree, so that this can be put on packagist? I’m not sure I see how there would be a conflict with that one and the regular Yii autoloader, the latter which would simply be loading classes as usual and the composer one wouldn’t be used in this case. Thoughts?
I must admit I haven’t ever used composer, I only briefly looked into it. I am looking into composer support for this extension now.
Great, thanks I think it’s super easy, just have a look at https://github.com/Crisu83/yii-less or some other one of Crisu’s extensions to see an example.
I’ve recently started using Composer and it’s a real breeze to just add a line in your ‘require’ array and run composer update and have it all managed for you. Also easy to set up namespaces and autoloading.
Indeed that is very simple, I don’t even need to use the composer autoloader if I just have to provide configuration like that.
I’ll look into completing this today.
I have written a composer.json file now which should work but whenever I attempt to upload it to the packagist site it keeps saying they had a problem their end, I try to clean my browser session and re-log in but then I get a 500 error :\.
So it will be up as soon as that gets fixed
Thanks for great extension, Sammaye.
Is there an easy way to display validation errors of embedded documents and embedded arrays through CHtml::errorSummary($model) or CHtml::error($model)? How do you realize validation process in your applications?
It uses much the same setup as Yii but nested within the root document in array form. Hmmm, it seems that the error summary cannot just take a plain array which kinda sucks.
I might need to write an additional little function some where that can do what CHtml cannot.
CHtml::errorSummary() is designed to take instances of CModel, and EMongoModel extends from that class, hence it has getErrors() which is what errorSummary() use. What is the problem, can you not give it an instance of EMongoModel?
Also, I’d like to point out that EMongoModel shouldn’t override getErrors() since it doesn’t do anything that the parent equivalent doesn’t do. Removing this (and potentially other overriding methods that does the same thing as parent) can clean up the class a bit
The problem is that subdocuments are not enclosed in EMongoModel classes, they are simply arrays and the error summary functions do not recognise array nesting for errors.
Yea, however, if you check the comments above it you will realise that I added a new method which modified a private variable in the parent. PHP OO accession works in such a way that if you want to modify a parent variable directly that is of private scope you cannot. You have to duplicate all the code associated with that var whose functionality you wish to keep.
Gotha. Too bad. Hate redundancy 
Indeed I hated the thought of it too 
if only Yii had getters and setters for direct manipulation of the errors var
Can’t you use a combination of getting and setting/complementing the errors from the parent?
The only way to add errors to the var atm from the parent instance is to assume you are adding a message to a field and nothing else I don’t think, unless you mean something else?
To let people know, I will most likely start to remake MongoYii for Yii2 in the coming weeks/months (depending on how long it takes for the Yii team to say that the API etc is not going to change).
So I have full intention of porting MongoYii in its current form, hopefully without breaking too much, to Yii2
Is just me that the MongoCursor always returns empty whichever would be the collection?
I’m doing this:
<?php
echo '<pre>';
var_dump( Yii::app()->mongodb->historical->find() );
echo '</pre>';
?>
I’m sure the collection name historical and the db in the config are totally correct, and of course the collection has results.
Due to how MongoDB works that won’t get a cursor but instead a MongoCollection object. This is fundamentally how the PHP driver works. If you want a MongoCursor to return you will need to use a read function like find or findOne
I am afraid that’s not happening to me.
Var_dump returning the following:
object(MongoCursor)#44 (0) {
}
And by analysing my code you can see that I’m using the method find() to return it.
Yes it will only return a MongoCursor, what exactly are you trying to return? If you are trying to return all results from that collection then you can try iterator_to_array($cursor)