andrew-kandels / contain Goto Github PK

I would expect that it would output: true / false. Found this while unit testing against arrays as assertEquals.

Example:

• 'isSubmitted' => false
• 'isSubmitted' => '0'

The generated formatting is; well.. ugly :) Might want to run php-cs-fixer on it or clean it up

I have entity definitions on different levels of components... For instance: MyModule\MyService\Entity\Definition

Allow sub-entity properties to also be set using dot notation (in addition to the nested arrays):

$a->fromArray(array('p1' => '1', 'subentity.p1' => '1'))

When will Contain support DynamoDB‽‽

Dude; need your help to write the driver part of this. I have the connection part (aka the easy part) done. Just working through the adapter and it is very mongolishious so I'm not quite sure where to put in some of the logistical items.

When running Compile Namespace the result of the generated entity and assets show the namespace as the full path to that namespace.

If model A has properties p1 and p2 and you call:

$a->fromArray(array('p1' => '1', 'p2' => '2', 'p3' => 3))

It should set properties p1/p2 as expected; but also set an extended property for "p3" to 3.

There shouldn't be any downside to this as extended properties are never exported -- just a little extra space.

There's a subtle variable name bug in AbstractEntity's isValid method. First $values is set with all of the entity property values after they've been filtered, then when looping over any validation messages, $values is used as the value variable in the foreach statement, overwriting the original array of filtered values.

https://github.com/andrew-kandels/contain/blob/master/src/Contain/Entity/AbstractEntity.php#L550-L552

Entity\Property\Type\ListEntity can not be defined on more than one model's properties at a time. I believe it may be an issue with the pivoter sharing data or not resetting properly.

$param = new Param();
$messages = array();
if ($request->isPost()) {

        $form->setData($request->getPost());
  echo 'hiiiiii'; 
       if (!$form->isValid()) 
      {
            $errors = $param->getInputfilter();
            foreach($errors as $key=>$row)
            {
                if (!empty($row) && $key != 'submit') {
                    foreach($row as  $rower)
                    {
                        //save error(s) per-element that
                        //needed by Javascript
                        $messages[$key][] = $rower;    
                    }
                }
            }
        }

// $messages=$form->setInputFilter($param->getInputFilter());
var_dump($messages);
if (!empty($messages)){
$response->setContent(\Zend\Json\Json::encode($messages));
} else
{
$response->setContent(\Zend\Json\Json::encode(array('success'=>1)));
return $response;
}

There is a limited amount of work that you need to do in order to provide a way to support modules rather than having to support a whole application. Although since it is different I decided it might be best to open an issue about it.

I'm not sure if it is intentional or not but since it is populated on the entity it would seem to me that the entity should run the validators against the entries.

Say for instance a validator on a number field; you give it a string value it will still populate and not complain.

1. ContainTest\Entity\StringTypeTest::testParseNoValue
   Failed asserting that '' is null.

/Users/mwillbanks/Projects/contain/tests/Contain/Entity/Property/Type/StringTypeTest.php:20

I have not changed anything around this area; so I'm guessing that you may have made the change on purpose OR it's a 🐛

Allow sub-entity properties to be white-listed using a dot notation:

$model->export(array('field1', 'field2', 'subentity.field1')))

While compiled entities provide the best performance and a larger degree of enforceability it does have drawbacks such as the inability to dynamically alter a document such that a "plugin" might do to add it's own data into the flow.

Take for instance a content management system or anything of the like. You might have a plugin that wants to store information on each post. It would be expensive to fetch that data from a separate collection rather than to store it in the same collection.

Therefore there are really a few different options here:

1. Modify the entity definition through the use of events at compile time.
2. Modify the entity by allowing more or less proxy methods.

In case 2 above you might use __call() and provide the logic for implementing the getter/setter based off of the definition. Otherwise the other route here is to simply fetch the properties and have to fetch them from the extended properties area.