onphp / onphp-framework Goto Github PK
View Code? Open in Web Editor NEWonPHP is the mature GPL'ed multi-purpose object-oriented PHP framework.
onPHP is the mature GPL'ed multi-purpose object-oriented PHP framework.
Суть вопроса: предлагаю сделать 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.
Вопросы которые хочу поднять:
У многих из нас в проекте есть каталог 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 требует минимальных модификаций в принципе.
Мастер тогда начнем разрабатывать уже в рамках 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
Я так понимаю это конфликт наименования классов. Какие идеи?
Проблема при использовании 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 структуры.
Если кому нибудь будет полезна волью в общую ветку.
Предлагаю обсудить идею работу с файлами.
Идея: Работать с файлами через бизнес объект, т.е. File::dao()->add($file)
Плюсы:
Минусы:
В общем предлагаю хранить в File:
Дальше вопрос стоит что-же делать с FileDAO и Worker-ом ? Тут несколько путей:
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) по нескольким причинам:
Писать все слово 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
Всем привет, общаясь с Сергеем Сергеевым, договорились сдвинуться с мертвой точки и перейти от фиксов версии 1.0, которая висит уже больше года, к версии 1.1 и в будущем как-то почаще делать новые промежуточные версии. В данном случае переход 1.1 обуславливается/требует следующие пункты:
Текущий список изменений которые хочется чтоб вошли в 1.1, но не вошли в 1.0 следующий:
Классы 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 и без
если не уместно - удалите или меня попросите :(
Всем ку!
Возникла интересная ошибка:
Пусть у нас есть сущность с полями, одно и которых поле 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 и чуть чуть опишу основные из них:
В общем, если нет протестов, то сегодня/завтра создам бранч 1.1 от текущего мастера.
Дальше можно по обсуждать что бы поделать еще в будуйщем. У меня все еще в планах для себя заниматься по чуть чуть в свободное время вот такими задачами:
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.