onphp / onphp-framework Goto Github PK

Суть вопроса: предлагаю сделать GenericDAO::makeOnlyObject(), GenericDAO::makeObject() и, возможно, некоторые другие методы as final public.

Мы столкнулись с проблемой переопределения свойств объекта в identity map при построении списков объектов (см. BaseDaoWorker::fetchList() и GenericDAO::addObjectListToMap()). Данные в makeObject() попадали через кастомный запрос.

Использование методов GenericDAO::makeOnlyObject(), GenericDAO::makeObject() мы видим только в приведённом выше контексте, и считаем, что так делать не следует. Предлагаемые изменения огородят других разработчиков от подобного рода ошибок.

Друзья, извините за пустой pull request, но я не знаю иного способа оповестить сообщество.
У нас в Wapstart есть пара вакансий разработчиков.

Мы работаем с onphp (и не только).

Если кого-то заинтересовало, то резюме можно посылать мне.

Знаю что с onPHP работает и прекрасная половина человечества, жалко конечно что их нет тут, но все же мы все поздравляем их с прекрасным этим днем, желаем быть по жизни неотразимыми и привносить не только в onPHP но и в повседневную жизнь только самые хорошие и приятные емоции, а тем кто еще не стал еще мамой, становится самой прекрасной и продвинутой мамой на земле :)

В общем, с прздиком вас наши дорогие.

P.S. Присоединяйтесь к нам сюда, мы хорошие и не кусаемся :)

Выложив сайт на рабочий сервер (FreeBSD 8.1-RELEASE-p2, если что) стал получать такие вот письма:

class: WrongStateException
code: 0
message: cannot unlink /var/tmp/onPHP/fsdw/228703724.1306449303.154492846..removing, though it should be empty now

#0 /home/carrera/onPHP/main/DAOs/Handlers/FileSystemSegmentHandler.class.php(82): FileUtils::removeDirectory('/var/tmp/onPHP/...', true)
#1 /home/carrera/onPHP/main/DAOs/Workers/VoodooDaoWorker.class.php(102): FileSystemSegmentHandler->drop()
#2 /home/carrera/onPHP/main/DAOs/GenericDAO.class.php(321): VoodooDaoWorker->uncacheLists()
#3 /home/carrera/carrera.nichost.ru/project/src/classes/Auto/DAOs/AutoCartDAO.class.php(28): GenericDAO->uncacheLists()
#4 /home/carrera/onPHP/main/DAOs/Workers/CommonDaoWorker.class.php(486): AutoCartDAO->uncacheLists()
#5 /home/carrera/onPHP/main/DAOs/GenericDAO.class.php(306): CommonDaoWorker->uncacheById(1478)
#6 /home/carrera/onPHP/main/DAOs/GenericDAO.class.php(367): GenericDAO->uncacheById(1478)
#7 /home/carrera/onPHP/main/DAOs/GenericDAO.class.php(354): GenericDAO->doInject(Object(InsertQuery), Object(Cart))
#8 /home/carrera/onPHP/main/DAOs/StorableDAO.class.php(35): GenericDAO->inject(Object(InsertQuery), Object(Cart))

При этом локально под gentoo такого не наблюдалось.

За последние две недели я написал какой-то вариант конвертера и потихоньку пофиксиваю его сейчас.
Результат можно увидеть в момем бранче masterNs.

Вопросы которые хочу поднять:

1. Сейчас я сделал что все классы лежат в одном неймспейсе - Onphp (исключение - тесты они лежат в Onphp\Tests). Меня один общий неймспейс более чем устраивает, но есть и другое мнение что должно быть именование на "поднеймспейсы" по именам папок. Причины на это - что вот тако вот повелось и есть PSR0 который рекомендует так именовать. Есть ли еще что-то кроме выше упомянутого против одного общего неймспейса? Причина почему я хочу один общий неймспейс - мне не нравится как файлы разложены по папкам. Где-то есть логика, а где-то нет, но в общем случае не видно бонусов от кучи неймспейсов.
2. Я написал конвертер, который конвертирует всё в неймспейсы. Не слишком хороший и не все умеет, но работает. Совсем через чуть чуть я его добавлю в тот же бренч.
   Не умеет из того что нужно что б он умел (т.е. не поленюсь и сделаю):
   • не умеет работать с alias'ами неймспейсов
   • не умеет следаить за константами что бы отличать от названий классов
   • не умеет распозновать функции вне классов, что бы отличать от названий классов.
3. Кто-нибудь уже использует 5.4? :) Вопрос не просто так - конвертер я из эксперимента сделал совсем чуть чуть с трейтами и где-то с короткой инициализацией массивов.

У многих из нас в проекте есть каталог src/: src/controllers/, src/views/, src/etc...
Я предлагаю переименовать его в app/: app/controllers/, app/views/ app/etc...
Это можно сделать в project.skel.
Считаю, что название app нагляднее и правильнее.

Нам для внутренних нужд нужна вот такая штука:
https://github.com/Wapstart/onphp-framework/blob/1.0-wapstart/core/OSQL/UnquotedDbString.class.php
Ее можно использовать для sql инъекций или других полезных вещей.

У себя мы ее точно оставим.
В мастер вливать?

Постараюсь описать прецендент. Допустим у нас есть класс Actor у который связан через OneToOne с классом Film через propery 'bestFilm' и связь в таком случае fetch="lazy"

Приведу в пример следующий код (в коде транслит, т.к. там проблема с кодировкой):

<?php
$actor = Actor::dao()->getById(16); //Get some actor
$film = $actor->getBestFilm(); //get best film from actor (and film stay in actor now)
$filmId = $film->getId(); //get best film id
Film::dao()->uncacheLists();
//compare object:
print spl_object_hash($actor->getBestFilm())."\n";
print spl_object_hash(Film::dao()->getById($filmId))."\n";
?>

В результате у нас оказывается два разных экземпляра с одинаковым идентификатором, что может привести к путанице кода и коллизии.
В случае когда объект fetch cascade или join - автоматически уберечься от этого нельзя. Однако в случае lazy, от подобных прецендентов можно уберечься если в Actor не хранить ссылку на объект film, а хранить лишь идентификатор, а метод getBestFilm переписать на:

<?php
public function getBestFilm()
{
    if ($this->bestFilmId !== null) {
        return Film::dao()->getById($this->bestFilmId);
    }
    return null;
}
?>

При этом лишних запросов byId в базу не появиться, т.к. либо объект будет браться из identityMap либо кэша. А загружаться из базы будет лишь если кэш сброшен.

Плюсы: возможность избежать описанных выше коллизий и удерживания старых объектов в других объектах

Минусы: работа с объектами связанными по fetch="lazy" будет несколько отличаться от работы с объектами связанным join или cascade.

Заранее извиняюсь, если нарушаю правила объявления проблемы.
В форме, примитив алиас при импорте выдает ошибку, что не может найти примитив внутри него содержащийся!
Пример кода:

include 'global.inc.php.tpl';
$form = Form::create()->
    add(Primitive::alias('n', Primitive::integer('number')))->
    import(array('n' => 42));

var_dump($form->export());

в результате:
PHP Fatal error: Uncaught [number does not match known primitives or rules] in:
#0 /home/vasu/hosting/onphp-github/core/Form/Form.class.php(451): Form->markGood('number')

...

Предлагаю указать в вики и прочих документациях, что нам нужен php >= 5.3. За одним отказаться от поддержки 5.2 в мастер ветке.

Друзья, предлагаю внедрить в мастер namespaces
Не вижу смысла отписываться по поводу профита, если есть веские "против" - давайте подискутируем.

У onPHP отличная структура папок, и autoloader требует минимальных модификаций в принципе.

1. корень namepsace - onPHP.
   namespace onPHP;
2. namespaces должны соответствовать текущей структуре папок, получаем для core/Logic/BinaryExpression
   namespace onPHP/core/Logic;
3. В файлах запрещается использовать прямое обращение по полному пути к классу.
   То есть не
   $a = new onPHP/core/Logic/BinaryExpression(),
   а
   use onPHP/core/Logic/BinaryExpression;
   $a = new BinaryExpression();
4. Потребуется переписать Autoloader, в принципе можно отказаться от ini_set в проектах в пользу разрешения классов строго по пути namepsaces, но тогда нужно сделать соответствие корня namespace его папке в системе, чтобы можно безболезненно подключать onPHP в свой проект, использовать свои namepsaces. В этом плане я считаю правильным задавать alias, как, это, например реализовано в yii:
   То есть будет что-то вроде:
   Autoloader::registerAlias('onPHP', ONPHP_CORE_PATH);
   Autoloader::registerAlias('myAPP', MY_APP_DIR);

Мастер тогда начнем разрабатывать уже в рамках 5.3, и метим его в 2.0 тэг.

Думаю стоит обсудить все тонкости и подводные камни, что скажите?

PrimitiveString:

    class PrimitiveString extends FiltrablePrimitive
    {
        // ...

        public function import($scope)
        {
            // ...
        }
    }

BasePrimitive:

    abstract class BasePrimitive
    {
        // ...

        protected function import($scope)
        {
            // ...
        }
    }

   /**
     * @test
     */
    public function testHttpsNonStandardPort()
    {
        $urlString = "https://some.path.to.com:444/hey.html";
        $url = HttpUrl::create()->parse($urlString);
        $this->assertTrue($url->isValid());
    }

Бага, фича?

При запуске тестов, наблюдается вот это:
Call to undefined method Memcached::create()

Потому что:

$ php -m | grep mem
memcached

$ php -v
PHP 5.3.6

Я так понимаю это конфликт наименования классов. Какие идеи?

http://www.php.net/manual/en/class.memcached.php

Проблема при использовании UTF-8 в PostgresDialect.class.php

public static function prepareFullText($words, $logic)
    {
        Assert::isArray($words);

        $glue = ($logic == DB::FULL_TEXT_AND) ? ' & ' : ' | ';

        return
            strtolower(
                implode(
                    $glue,
                    array_map(
                        array('PostgresDialect', 'quoteValue'),
                        $words
                    )
                )
            );
    }

собственно strtolower некорретно обрабатывает некоторые unicode символы и вместо него должен быть mb_strtolower.

Собственно я здесь новенький ) подскажите плз, как предложить внести фикс в код.

Добрый день. Речь про коммит 8485d51

Кейз

$property = ObjectProperty::create()->setName('someName');

$bigObject =
 BigObject::create()->setName('father')->
 setObjectProperty($property);

$property->dao()->add($property);
$bigObject->dao()->add($bigObject);

Вот с таким кодом в $bigObject потеряется ссылка на $property, ибо id в $property появился уже после того как он был присвоен $bigObject

У нас в коде кое-что сломалось. В нашем бранче я откатил изменения из этого коммита. Но про мастер я не могу принять соответствующего решения.

Добрый день!

У нас тут в ютном чатике возникла дискуссия по поводу singleton.
Мы пришли к тому, что второй параметр в методе getInstance лишний.

final public static function getInstance(
            $class, $args = null /* , ... */
        )

if (!isset(self::$instances[$class]))

Непонятно как должен вести себя Singleton, когда мы пытаемся получить инстанс с параметрами, отличными от переданных при предыдущем вызове: создавать новый объект или изменять состояние текущего.

Что думаете?

builder.php читает имя класса вместо названия поля
один объект ссылается на список других через таблицу связей
причём, правильно генерит структуру БД, но падает на Checking

CREATE TABLE object_link
(
id serial NOT NULL,
from_id integer NOT NULL,
to_id integer NOT NULL,
...

Checking sanity of generated files:

..... Object (18/4/C/

ERROR: 42703: column object_link.object_id does not exist - SELECT "object_link"."id", "object_link"."from_id", "object_link"."to_id" FROM "object_link" WHERE ("object_link"."object_id" = '37')

meta_config.xml

    <?xml version="1.0"?>
    <!DOCTYPE metaconfiguration SYSTEM "meta.dtd">
    <metaconfiguration>
        <classes>
            <class name="Object" type="final">
                <properties>
                    <identifier type="Integer" />
                    <property name="name"                           type="String"   size="255"                                          required="true" />
                    <property name="ObjectLinkList"                    type="ObjectLink"                   relation="OneToMany"                required="false" />
                </properties>
                <pattern name="DictionaryClass" />
            </class>

            <class name="ObjectLink" type="final">
                <properties>
                    <identifier type="Integer" />
                    <property name="from"                           type="Object"                          relation="OneToOne"    fetch="lazy" required="true"  />
                    <property name="to"                             type="Object"                          relation="OneToOne"    fetch="lazy" required="true"  />
                </properties>
                <pattern name="DictionaryClass"  />
            </class>

        </classes>

При генерации схемы класса, у которого в мете есть "extends", пропускается генерация кода для его relation-ов.

Происходит это, судя по всему, благодаря этой строке:
https://github.com/onPHP/onphp-framework/blob/master/meta/builders/SchemaBuilder.class.php#L66

Зачем здесь эта проверка, и будет ли корректно заменить в ней $class->getParent() на !$class->getPattern()->tableExists()?

Вот такой код:

<?php
$object1 = SomeDao->getById(1);
$object2 = SomeDao->getById(2);

SomeDao->take($object1->setSomeProp('prop1');

$object2 = SomeDao->getById(2);  // Да, мне нужно сделать второй раз getById
SomeDao->take($object1->setSomeProp('prop2');

сохранит в БД только одну первую запись для $object1.
Сделает он это потому, что при первом take, вызывается CommonDaoWorker::uncacheById,
в котором вызывается GenericDAO::uncacheLists. Дальше GenericDAO::dropIdentityMap и в нем есть строчка:
$this->identityMap = array().
Из-за этого, когда мы в следующий раз будем вызывать getById(2), то нам вернется ссылка на объект из кэша(GenericDAO::getById, CommonDaoWorker::getById, BaseDaoWorker::getCachedById) и поэтому, чтобы мы не засетили в него, при попытке take переменная $changed, определенная как
$changed = ($old->$getter() !== $object->$getter()) || ($old->$getter() != $object->$getter());
никогда не будет true, т.к. $old и $object один и тот же объект.

Решается, заменой второй строчки
$object2 = SomeDao->getById(2);
на
$object2 = clone SomeDao->getById(2);

Прокомментируйте пожалуйста, баг ли это и есть ли верное решение.

2011/4/19 Sergey Sergeev
Внимание, вопрос. Мы сохраняем Odd-numbered versions for development
releases (http://en.wikipedia.org/wiki/Software_versioning), то есть
когда minor-version нечетное число для разрабатываемой версии
(master'а), а четное число для стабильной (tags)?

Наглядно получаем следующую картину:
будущий master - это 1.3. Он должен релизиться в tag 1.4.0, 1.4.1, 1.4.2 и т.п.
затем 1.5, в 1.6.0, 1.6.1, 1.6.2

Вообще говоря, данная система нумерации признана устаревшей (см.
википедию). Linux Kernel перестали ее использовать с 2004 года.
Система применяется/применялась для ПО с длительным циклом разработки.

Ваши мысли и предложения. Что скажите?

в misc/Autoloader.inc.php на 103 строке вызывается функция __autoload(), которая нигде не определена.
Если переместить файл с классом и не чистить кеш автолоада, то оно ломается

Подозреваю, что ноги растут 6f89aee
Это я что-то не так делаю или править надо?

ps. global.inc.php у меня из коробки.

Часто бывает по быстрому создать структуру из уже имеющегося проекта, вот
пример консольной утилиты для генерации sql структуры.

misc/makeSqlSchema.php

Если кому нибудь будет полезна волью в общую ветку.

Предлагаю обсудить идею работу с файлами.
Идея: Работать с файлами через бизнес объект, т.е. File::dao()->add($file)

Плюсы:

• можно будет легко цеплять через ManyToMany к любым объектам через мету, что легко, удобно и быстро

Минусы:

• Это конечно лишние запросы к б.д. (хотя тут нас может спасти кэш),
• В некоторых случаях работа с файлами очень критична, ну тут думаю доточать тем кому это надо будет.

В общем предлагаю хранить в File:

• ID
• Название
• Описание
• MimeType
• Название файла
• Размер в байтах
• Дата создания
• Дата модификации
• [serverType - Тип сервера хранилища]

Дальше вопрос стоит что-же делать с FileDAO и Worker-ом ? Тут несколько путей:

1. Это написать специфичный Worker унаследованный от StorableDAO в котором будет происходить перемещение, копирование файла в новое место после добавления, изменения и удаления.
2. Оставить Worker FileDAO в покое и добавить некий Enumeration тип к File, к примеру 'serverType' и для каждого сервер (Local file server, WebDAV file server, FTP file server ....) написать воркеты которые тупо будут отвечать за премещение-копирование, изменение и удаление файла с сервера и вызывать его в FileDAO::add, take, drop, save
   К примеру:
   FileDAO.class.php

class FileDAO extends AutoFileDAO
    {

        public function add(Identifiable $object)
        {
            $db = DBPool::getByDao($this);

            try {
                $db->begin();


                $object->getServerType()->toWorker()->add($object); // Здесь вызов нужного воркера
                $parent = parent::add($object);

                $db->commit();

                return $parent;
            }catch (Exception $e) {
                $db->rollback();
                throw $e;
            }
            return /*void*/;
        }
    ...

    }

Собственно у кого какие на эти вещи предпочтения, идеи и дополнения прошу высказываться :-)

Предыдущяя лицензия была выдана JetBrains-ом нам до конца февраял я им отписал о продлении этой лицензии.
Ждем, в течении 2-3 дней они должны по идее прислать обновленную лицензию.

Опубликую ее тут :-)

Собственно сюда приаттачю решение шде Enumeration реализованно через Static свойства

Немного истории: Сейчас у нас класс Enumeration выглядит как обычный класс с неститчным свойством $names
и совсем непонятно зачем создавать обьект чтобы, к примеру получить ids или получить названия (алиас)

вообщем не логично, по скорости работы и потребелнию памяти мы с stev тестили одинаково ))), он не даст мне соврать )))

Привет всем! Помогите со следующим вопросом плз.
Нужно из таблицы ManyToMany получать данные отсортированные по id этой таблицы.
Через критерию UnifiedContainerWorker не получилось, так как Criteria требует чтобы было dao, которое устанавливается в критерию, наследовалось от класса ProtoDAO, но класс dao ManyToMany не наследуется от ProtoDAO.

Нашел такое решение:
переопределил в классе своем DAО классе ManyToMany функцию fetchList, в которую
полностью скопипастил родительскую функцию с приватными методоми
и при этом изменил только одну строчку:
$query = $this->worker->makeFetchQuery();
на
$query = $this->worker->makeFetchQuery()->orderBy('id');
Решение некрасивое и неправильное.
Как правильно?

Товарищи,
Хотел бы поднять вопрос о именовании интерфейсов, в очередной раз.

Сергей Сергеев, мне поведал что именовать классы интерфейса с заглавной буквы это не хорошо, и это затруднило перенос некоторых наработок из проектов в onPHP

Но я вижу что многие в своих наработках все равно используют такое именование.

Удобней именовать интерфейсы с заглавной буквы или с прописной (что нарушает CS) по нескольким причинам:

• "I" - указывает что это интерфейс, удобней ориентироваться при автокомплите.
• облегчает поиск доступных интерфейсов при разных проверках и объявлениях.
• коротко и понятно.

Писать все слово InterfaseMyBigBoomPlugin - не годится

примеры:

// up
IController
IRunable
IInnerController

//down
iController
iRunable
iInnerController

Хотелось бы узнать ваше мнение.

Мучал перед сном sqlite и наткнулся на непонятную штуку:

<?php
$query1 = OSQL::select()->from('ing_ingredient')->get(SQLFunction::create('COUNT', '*')->setAlias('count'));
$query2 = OSQL::select()->from('ing_ingredient')->get(SQLFunction::create('COUNT', '*'), 'count');
$db = DBPool::me()->getLink('ing');
var_dump($db->queryRow($query1));
var_dump($db->queryRow($query2));

И получал вот такой var_dump в первом и втором результате соотвественно:

array(1) {
  [""]=>
  string(1) "2"
}
array(1) {
  ["count"]=>
  string(1) "2"
}

Хотя sql вроде бы генериться один и тот же:

SELECT COUNT('*') AS "count" FROM "ing_ingredient"
SELECT COUNT('*') AS "count" FROM "ing_ingredient"

Попадалось кому-нить что-нить подобное? :) Подозреваю что дело, возможно, в настройках локали, но пока не нашел в чем именно оно.

Возникла не ловящаяся бага, видимо, после начала использования Postgres 9.1. На разных системах по разному эскейпятся данные и подчас не корректно. Речь о функциях в PostgresDialect - pg_escape_string и pg_escape_bytea. Сталкивался ли кто-нибудь с подобным?

Если решение не найдется от чего зависит различное поведение этих функций, то, думаю возьмусь переписать PgSQL на использование PDO адаптера. Помимо этого попробую сделать все диалекты не синглтонами и что бы в их методы эскейпинга передовался текущий ресурс соединения для явного использования, т.к. например pg_escape_string на деле использует последний коннект к базе, но не явно.

Конфликт возникает, например, при генерации меты.

Вот текст ошибки:
PHP Fatal error: CurlHttpResponse cannot implement HttpResponse - it is not an interface in Z:\git\onPHP\main\Net\Http\CurlHttpResponse.class.php on line 16

Ошибка возникает из-за подключенного в php модуля php_http, в котором существует класс HttpResponse.

Спасибо за внимание.

Собственно добаляем поддержку uuid

см. http://ru.wikipedia.org/wiki/UUID

Всем привет, общаясь с Сергеем Сергеевым, договорились сдвинуться с мертвой точки и перейти от фиксов версии 1.0, которая висит уже больше года, к версии 1.1 и в будущем как-то почаще делать новые промежуточные версии. В данном случае переход 1.1 обуславливается/требует следующие пункты:

1. master считается версией 1.1 и разработка ведется на нем.
2. Коммиты обратно совместимые с 1.0 переносятся туда через git-cherry pick
3. Стабильной версией все так же пока считается 1.0, master используется на свой страх и риск
4. В 1.1 могут быть изменения ломающие BC - но их нужно заявлять и обсуждать - стоит ли ломать, так же необходимо составлять правила миграции с 1.0 на 1.1
5. master и все последующие версии мы считаем совместимыми с php >= 5.3
6. Заводим в issue - milestone'ы 1.0 и master (1.1) ;)
7. Подчеркну - координально ломать BC при переходе между 1.X версиями (например, с версии 1.3 на версию 1.4 добавить namespace'ы) не предусматривается, перенос текущих рабочих проектов в рамках 1.* должен быть максимально прост.

Текущий список изменений которые хочется чтоб вошли в 1.1, но не вошли в 1.0 следующий:

1. Code clean & add SocketMemcached instead of Memcached (#78) - ломает BC и пусть попадает только в 1.1
2. Static Enum vs Non-Static Enumeration (#82) - требует версии php >= 5.3, идет в 1.1 плюс ко всему Enumeration объявить @deprecated и через несколько релизов вырезать. Написать как партировать текущие Enumeration'ы в Enum.
3. Я потихоньку у себя в fork'е мучаю TaggableDaoWorker который автоматически кэширует запрос по нескольким тегам и соотвественно раскешивает. Добился что бы оно успешно работало все связи OneToOne использует fetch="lazy" + при этом сам lazy изменен и ломает немного BC. Эту штуку надо обсуждать и о ней я распишу чуть позже, наверное, на выходных, если времени будет достаточно.
4. Не портированный SQLite на PDO до недавнего времени не давал мне добить задачу с классом InnerTransaction, позволяющем делать вложенные транзакции и не задумываться об этом, используя механизмы savepoint'ов во всех трех базах (postgresql, mysql, sqlite3). Эту же штуку я подумываю встроить в onPHP, там где он сам делает begin-commit;
5. Вышел стабильный релиз библиотеки pecl amqp, в master планируется переход на pecl amqp stable 1.X, вероятно,
   может немного измениться API.

Классы AMQP в нашей библиотеке пресекатеся с некоторыми классами новой версии AMQP (((
К примеру там появился AMQPQueue

В общем трабл, надо наверно учитывать этот факт, т.к. сейчас наша либа работает только до amqp <= 0.3.1
а акутальная версия

1.0.3 stable 2012-05-19

Вот такие вот дела

На днях столкнулся со странным и нелогичным, как мне кажется, поведением DateRange, а именно..
У класса DateRange есть методы toString() и toDateString(), которые практически идентичны (копипаст?) и решают задачу представления объекта строкой. Результатом работы этого метода служит строка такого вида 'YYYY-MM-DD - YYY-MM-DD'.
В свою очередь DateRangeList::makeRange() позволяет распарсить строку и получить на выходе объект DateRange.
Все это прекрасно работает, за исключением тех случаев, когда левая либо правая граница DateRange не пуста.

Дело в том, что когда одна из границ не задана, DateRange формирует строку 'YYYY-MM-DD'. Хотя, по идее, должен сформировать ' - YYY-MM-DD' или 'YYYY-MM-DD - '. Ведь DateRangeList может распарсить именно такую строку.

Если короче, то получается так:

$range = DateRangeList::makeRange(' - 2011-09-06');
echo $range->toDateString();
//2011-09-06

$range2 = DateRangeList::makeRange($range->toDateString());
echo $range2->toDateString();
//2011-09-06 - 2011-09-06

Мне кажется, что это стоит исправить. А заодно избавиться от копипаста в DataRange и убрать артефакты в PrimitiveDateRange. Ваше мнение?

А давайте добавим метод toString() в PartViewer, чтобы можно было не только вставлять part-шаблон в шаблон, но и строку получать для дальнейшей обработки. Например, для использования в javascript. Собственно патч:

diff --git a/main/Flow/PartViewer.class.php b/main/Flow/PartViewer.class.php
index cce11ff..fa17f4c
--- a/main/Flow/PartViewer.class.php
+++ b/main/Flow/PartViewer.class.php
@@ -57,6 +57,13 @@
                        return $this;
                }

+               public function toString($model = null)
+               {
+                       ob_start();
+                       $this->view($model);
+                       return ob_get_clean();
+               }
+

DBTable.class.php: корекция названия индекса для CREATE INDEX
причина: они почти сразу начинаются пересекаться по имени
название не содержит имя таблицы
убрал разделители _ в имени таблиц и полей для визуального разделения(хотя можно добавить двойные, наверное)
убрал _id а-ля объекты. теоретически могут начать пересекаться если в таблице есть с_id и без

http://pastebin.com/eEfAcz9z

если не уместно - удалите или меня попросите :(

Всем ку!
Возникла интересная ошибка:
Пусть у нас есть сущность с полями, одно и которых поле email.
Дальше пишем критерию в DAO этого объекта:
Criteria::create($this)->
add(Expression::eq('email', $email))->
get();
Все работает хорошо до тех пор пока в поле email не придут данные типа: [email protected]
Тогда выпадает ошибка WrongArgumentException, так как срабатывает Assert::isTrue в недрах onPHP.
Расследование привело к следующему:
Трейс примерно следующий:

/onPHP/v.1.0/main/Criteria/Criteria.class.php(473): Criteria->fillSelectQuery(Object(SelectQuery))

/onPHP/v.1.0/main/Criteria/Criteria.class.php(490): SQLChain->toMapped(Object(UpProfileDAO), Object(SelectQuery))

/onPHP/v.1.0/core/OSQL/SQLChain.class.php(59): ProtoDAO->guessAtom(Object(BinaryExpression), Object(SelectQuery))

/onPHP/v.1.0/main/DAOs/ProtoDAO.class.php(390): BinaryExpression->toMapped(Object(UpProfileDAO), Object(SelectQuery))

onPHP/v.1.0/core/Logic/BinaryExpression.class.php(103): ProtoDAO->guessAtom('phone.sahkaa@gm...', Object(SelectQuery))

/onPHP/v.1.0/main/DAOs/ProtoDAO.class.php(375): ProtoDAO->processPath(Object(ProtoUpProfile), 'email.anyemail@an...', Object(SelectQuery), 'up_profile', true, NULL)

И в onPHP/v.1.0/main/DAOs/ProtoDAO.class.php(194): Assert::isTrue(false) уже и срабатывает Assert.

Срабатывает следующим образом там:
$probablyPath - это наш email, который мы засетили в критерию

$path = explode('.', $probablyPath);
Здесь мы наш email разбивает по точке. В результате $path[0] = 'email'

        try {
            $property = $proto->getPropertyByName($path[0]);

//Вот тут то зачем то вытаскивается из прото объекта LightMetaProperty для email и дальше не отрабытвает catch и ...
} catch (MissingElementException $e) {
// oh, it's a value, not a property
return new DBValue($probablyPath);
}
//var_dump($property); exit();

        unset($path[0]);

// .. все рушится в этом Ассерте!
Assert::isTrue(
$property->getRelationId() != null
&& !$property->isGenericType()
);

Ктото может прокоментировать почему такая логика? Зачем ему в данном случае прото? в чем смысл?
Пофиксить смог только что попробовав применить DBValue::create()...
Но все равно хотелось бы услышать комментарии, так как получается надо во избежание ошибок сразу же везде вставлять DBValue.

При клонировании контейнера не клонируются worker а передается по ссылке, что приводит к проблемам (вот одна из них):

$container1 = $object->getBooks();

$container2 = clone $container1;

$container2->setCriteria(
          Criteria::create()->add(...)
);


echo 'conatiner1 criteria ' . "\n";
 var_dump( $container1->getCriteria() )  // Must be null, but ...
echo "\n";

echo 'conatiner2 criteria ' . "\n";
 var_dump( $container2->getCriteria() )  
echo "\n";

нужно проверить подпись в подписанном XML с использованием этого стандарта.
Дело в том, что сам подписанный XML формируется в .NET под С# и не хочет проверяться ни в какую под PHP.
В С# подпись проверяется хорошо.
Вручную проверить не получается подобрать, что они конкретно подписывают.
Уже использовал XmlSecLibs - не подходят. Сами с собой работают, с С# нет.
Может кто сталкивался напишите.

Есть проблема с анкешом при работе с CarefulDatabaseRunner: изменения объектов идут через dao, там же происходит анкеш объектов, но объекты в базе не меняются. После всех действий, если команда завершилась успешно, мы коммитим результат. После коммита мы не уверены, что в кеше не лежат старые объекты.

Вариант с повторным анкешом после коммита выглядит костыльным; здесь предлагаю обсудить варианты решения подобных кейсов.

В настоящий момент при импорте пустой строки в любом случае (даже если не задана минимальная длина строки через setMin) не получаем в value пустую строку, а получаем null, хотя это разные значения (в том числе и для БД). Есть предложение изменить на следующий код:

public function import($scope)
{
    if (!BasePrimitive::import($scope))
        return null;

    if (!is_scalar($scope[$this->name]) || is_bool($scope[$this->name]))
        return false;

    $this->value = (string) $scope[$this->name];

    $this->selfFilter();

    if (is_string($this->value)) {
        $length = mb_strlen($this->value);

        if(
            ($this->max === null || $length <= $this->max)
            && ($this->min === null || $length >= $this->min)
            && ($this->pattern === null || preg_match($this->pattern, $this->value))
        )
            return true;
    }

    $this->value = null;

    return false;
}

Предыстория - мне нужна поддержка http://pgfoundry.org/docman/view.php/1000079/117/README.txt в onphp.
Для этого хочу ввести в мету IpRange или аналог.

За одним можно сделать так, чтобы автосгенеренные геттеры с type="Inet" возвращали IpAdress, а не string. Но это сломает bc.

RFC.

Привет коллеги.

У меня тут предложение возникло, а не добавить ли нам проект в https://travis-ci.org/
Это система непрерывной интеграции.

Т.е. при мерже в мастер система начинает гонять по ним тесты, в конце мы все сможем посмотреть результаты.

Вполне себе хороший способ держать код в хорошем состоянии.
В общем кому инетресно поробности тут (http://about.travis-ci.org/docs/)

Один из наших коллег, друзей @stev взялся за этот механизм, но почему-то он решил его сделать в тихоря, а тема довольно таки непростая.

Это механизм Widget-ов, т.е. некоторые классы, механизмы по работе в основном с клиентской частью, который позволит упростить создание и использование, в основном, HTML элементов.

Мы уже со @stev общались на эту тему, но сообщество это сила и по этому лучше этот вопрос вытащить сюда, дабы понять что нам всем нужно от этого механизма и каким он должен быть!

Слово уступаю Евгению aka @stev :-)

На странице "Форма, пример" есть пример добавления правила в форму:

//Добавляем правило проверки совпадения двух полей (password == password_confirm)
$form->add(
    Primitive::rule('is_password_confirmed')->
        // Из какой формы будут братся значения для валидации
        setForm($form)->
        // Expression условие
        setExpression(
            // При условии того что выражение будет истинно
            Expression::isTrue(
                // Если варажения эквивалентны
                Expression::eq(
                    FormField::create('password'),
                    FormField::create('password_confirm')
                )
            )
        )
);

Насколько я понимаю, он не правильный. Исправленный вариант:

$form->addRule(
        'is_password_confirmed',
        Expression::isTrue(
                Expression::eq(
                        FormField::create('password'),
                        FormField::create('password_confirm')
                )
        )
);

В процессе эксплуатации типографа всплыла неправильная обработка ситуации с вложенными кавычками. В тестах используется пример '""text" text"', преобразуемый в '«„text“ text»'. Но часто попадаются куски текста такого вида: '"text" "text"', а они преобразуются в '«text„ “text»', что как мне кажется неправильно.

У существующего Timestamp есть проблема - он всегда создается в текущей timezone. При этом внутреннее его представление - это Unixtime.

С созданием Timestamp в текущем времени есть проблема - время у всех разное. Например, DateUtils::alignToSeconds() будет отдавать разные результаты в разных TZ при одинаковом наборе параметров. Сейчас у нас на Берлинской TZ тесты не проходят.

В рамках этого issue я предлагаю дать возможность создавать Timestamp объекты в UTC. BC это не сломает.

Добавляем поддержку JsonPView & JsonXssView кому надо welcome :-)

Идеи ?

Создам новый Issue взамен старого (#83), что бы оно было более видно.
За последнее время потихоньку потихоньку, да набрался в мастере набор отличий от версии 1.0 и чуть чуть опишу основные из них:

• сегодня я наконец замержил измененный Autoloader и использвание InnerTransaction в onPHP.
• Из того что хотел сделать, но еще не довел - это TaggableDaoWorker - который больше нужного ломает BC. Однако из него было вынесено измененное раскешивание и добавлено в мастере.
• Так же в мастере есть TimestampTZ
• немного переписанный CurlHttpClient теперь может отправлять файл через функции curl'а
• Остальное можно прочитать на специально странице в вике 1.0 => 1.1 Там же описано все где изменилась обратная совместимость (BC) и какие изменения нужно сделать у себя в проекте.

В общем, если нет протестов, то сегодня/завтра создам бранч 1.1 от текущего мастера.

Дальше можно по обсуждать что бы поделать еще в будуйщем. У меня все еще в планах для себя заниматься по чуть чуть в свободное время вот такими задачами:

• пофиксить генерацию базы по мете, что бы сначала создавались все таблицы а уж потом на них вешались constraint'ы. Этим, видимо, не сильно кто-то увлекался/увлекается, но поправить хочется
• наконец добраться до namespace'ов и по возможности сделать конвертирование проектов на них.
• мучать дальше TaggableDaoWorker