Don't be shy, express yourself on things you don't like in Li3. Don't be stingy with criticisms (I personally like being abused). Makes your criticism as detailed as possible with comparisons with how it works with your favorite framework if possible.

Thanks in advance for helping us to make Li3 an even better framework.

Example of usage:

bash console/li3 test tests --format=plain |& tee plain.txt

Example Output:

before:

----
Test
----

S.......................SS......SSS.........................
............................................................
..S...F.....................................................
..SSSSSSSSSSSSS.............................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
...............E..E.........................................
............................................................
............................................................
............................................................
............................................................
................

After:

----
Test
----

S.......................SS......SSS.........................
............................................................
..S...F.....................................................
..SSSSSSSSSSSSS.............................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
............................................................
...............E..E.........................................
............................................................
............................................................
............................................................
............................................................
................

What about using http://packagist.org and composer to manage plugin dependencies? It looks like it is getting more traction and maybe we can integrate it with the Library class too. Also, if people are encouraged to add their plugins there too we have a "central" repository of libraries which can easily be reused.

This is marked as an RFC and it would be cool to get comments both from the core devs and the community to see what they think about it and how they want to use it.

Regards, Michael

The biggest suggestion, from our users, is for better documentation so on Saturday, May 18th 2013 starting at 9am CST (-6) to 5pm CST we are having our very first documentation hack day!

This is when we all get together and add as much documentation do the code comments or the li3 manual.

Right now, list below things you wish were more documented such as classes, methods, procedures, or anything you just don't understand after reading the current documentation!

Later, on May 18th head into #li3 on irc.freenode.net and we'll get to work! We can give you something to document, or feel free to work on one you know a little about or want to learn about by documenting it. We'll keep the discussion going to prevent overlapping.

Anybody can contribute, so I'll see you then!

when you find entity model with fields parameter and this result don't include fields that has defined in model validate, you can't save it and you take validate error on not selected fields.

This lifts the dependency on composer/installers and uses composer autoloading directly.

This makes lithium no longer install into /libraries/lithium, but instead puts it into /vendor/UnionOfRad/lithium/lithium (second lithium is needed for psr-0 path completion).

Now, I'm not sure if you actually want this. The benefit of doing so is that it plays nice with everyone else. Instead of saying "fuck you, I'm going to make my own folder", putting everything in the vendor dir allows all the library code to be in one place, and the end user can customize it if he wants to.

Let me know if you have any questions.

This PR replaces #916. It was originally spawned off of composer/composer#1865.

There is a shift coming in the MongoDB Native Driver for PHP: http://blog.mongodb.org/post/36666163412/introducing-mongoclient?yey

Specifically as of version 1.3.0, Mongo will be deprecated and replaced with MongoClient

There's a few new features, that I'm aware of:

• Write Concern, which will replace safe and fsync.
  • array("w" => 3)
• Read Preference which provides better control than setSlaveOkay over replica sets.
  • array("readPreference" => MongoClient::RP_PRIMARY_PREFERRED)

(see: http://us2.php.net/manual/en/mongoclient.construct.php for reference)

I have a users table which I get all rows (there are 4 total) by calling

$users = Users::all();

my index page displays my results

        <?php foreach ($users as $user) { ?>
            <li>
                <?=$user->username; ?>
            </li>
        <?php } ?>

of which only 2 show, with ids 1 and 3 showing

a call to $users->count(); returns 2 results

querying the $sql variable shows: SELECT * FROM "users" AS "Users";

If I delete the row with id 1, ids 2 and 4 will show.

My conclusion is that for some reason, only every other row will get returned to the record set. I created a quick php page to query the sqlite table and there are 4 rows to begin with, and my deletion of row with id 1 will only delete that one row. My php page:

try {
    //open the database
    $db = new PDO('sqlite:..\data\PSER.db');

    //create the database
    //$db->exec("CREATE TABLE users(id integer PRIMARY KEY, username text UNIQUE NOT NULL, password text, usertype integer)");    
    //$db->exec("ALTER TABLE users ADD COLUMN usertype");

    //now output the data to a simple html table...
    print "<table border=1>";
    print "<tr><td>id</td><td>username</td><td>password</td><td>usertype</td></tr>";
    $result = $db->query('SELECT * FROM "users" AS "Users"');
    foreach($result as $row)
    {
      print "<tr><td>".$row['id']."</td>";
      print "<td>".$row['username']."</td>";
      print "<td>".$row['password']."</td>";
      print "<td>".$row['usertype']."</td></tr>";
    }
    print "</table>";

    // close the database connection
    $db = NULL;
}
catch(PDOException $e) {
    print 'Exception : '.$e->getMessage();
}


?>

I got pulled down lithium from git on the 2nd, what am I doing wrong?

I have created a little test for anyone willing to check it out: http://pastium.org/view/4a35aeb1bf856634d7185df970bc7981

Basically, after saving the second list of documents in "otherDocs", the content of "docs" is inserted inside the parent document which we don't want...

I've been looking at the _update method inside Exporter.php and it seems the results it's giving for embedded documents are not really appropriate.

Hope this helps!

(Mongo version 1.8.2)

Originally discussed in #855, the current formatters don't pass through constant values like MySQL's CURRENT_TIMESTAMP when set as the default value for a column in the database. This fixes that issue by replacing the named function date with a closure that can be overridden by subclasses. It also addresses deprecating the odd _toNativeBoolean() method that acts as a formatter on the Postgres adapter in favor of this new approach. A patch for the Postgres adapter is included.

• assertXX & assertNotXX should share the same code base.
• consistent API for assertNull() / assetNotNull().
• adding missing assetNotIdentical().
• normalize line endings.
• typo fix: renaming $actual to $result all way long
• remove assertRegExp(), conflict with assertPattern().
• remove assertNotRegExp, conflict with assertNoPattern().
• remove assertEmpty(), conflict with assertFalse().
• remove assertNotEmpty(), conflict with assertTrue().

Redis use database 0 by default. In my project, I had to get the data from another database. I read this document. I added the selected database configuration to the lovely lithium.

Lithium Version: 1.0

$data = MyModel::all([
    'fields' => [
        'IFNULL(prices->\'$."1"\', prices->\'$."default"\') as MyModel.price',
    ],
])->data();

I'm trying to access a value of a json field in my field list (returns many results and processing serverside isn't very feasible because of speed concerns). I'm getting an error in /data/source/Database.php on line 680. It appears to be splitting all the field name values on '.' in order to sort them?

I have also tried 'MyModel.price' => 'IFNULL(prices->\'$."1"\', prices->\'$."default"\')' and received the same result.

To my knowledge there is no way to retrieve data from a JSON field within a query without specifying a path, which requires using the '$.field' notation. Is there a way for me to mark this as a calculated field and prevent this from happening? Alternately is there an official way to access JSON fields with li3, or to disable this "sorting" from occurring?

In case of Couchdb 2.3 the method: $this->connection->{$method}($path, $data, $options); in https://github.com/UnionOfRAD/lithium/blob/bec3f4fdf61ea5002904754f43941ad1430ecec7/data/source/http/adapter/CouchDb.php#L122 is an array instead of string..

This breaks the logic inside of the describe function.

In the case where multiple types are registered to lithium\net\http\Media with the same content type, even when distinguished by conditions, an instance of lithium\action\Request will fail to determine the correct type to use to decode the request body. For example, if we register another type which uses 'application/json' as a content type like this:

use lithium\net\http\Media;

Media::type('json_base64', ['application/json'], [
    'encode' => function ($data) {
        return base64_encode(json_encode($data));
    },
    'decode' => function ($data) {
        return json_decode(base64_decode($data), true);
    },
    'cast' => true,
    'conditions' => [
        'http:content_transfer_encoding' => 'base64'
    ]
]);

A call to Media::type('application/json') will return an array like:

[
	'json_base64',
	'json'
]

This case is not handled by lithium\net\http\Message::type(), which causes lithium\action\Request::$_type to be assigned as the content type of 'application/json'.

Futhermore, when Request::body() is called to decode the request body, the Media class fails to find a handler for 'application/json' (it expects a short name like 'json').

To fix this, lithium\net\http\Message::type() must be extended by lithium\action\Request. In the case that $type is a string and equals the result of the parent's call, we can loop over each type returned by Media::type() and attempt to match the request to it like this:

public function type($type = null) {                                            
    if (!$type && !empty($this->params['type'])) {                              
        $type = $this->params['type'];                                          
    }                                                                           
    $_type = parent::type($type);                                               
    if (is_string($type) && $_type === $type) {                                 
        $media = $this->_classes['media'];                                      
        $content = $media::type($type);                                         
        if (is_array($content) && !isset($content['content'])) {                
            foreach ($content as $short_type) {                                 
                $conf = $media::type($short_type);                              
                $conf['name'] = $short_type;                                    
                if ($media::match($this, $conf)) {                              
                    $_type = $short_type;                                       
                    break;                                                      
                }                                                               
            }                                                                   
        }                                                                       
    }                                                                           
    return ($this->_type = $_type);                                             
}

This will correctly determine a single short name to use for the type of the request data, and it can now correctly decode the request body.