Идея переименования файла заключалась в том, чтобы имя файла всегда соответствовало обозначению документа. Таким образом, при регистрации документа вычислялось обозначение документа. Сохранялось в атрибуте. При импорте файла с любыми именем в elma, должно было происходить его переименование. При изменении обозначения документа и уже существующем файле его имя тоже должно было измениться. Не велика сложность, неправда ли?
Наивные, см. ticket 23220
Мне уже не нужна помощь, спасибо. Я себе помог.
>>Тут нечего сказать, рад что вы смогли справиться с проблемой.
Я то как рад был бороться с проблемой, которой не должно быть!
Очередной раз подчеркну, что система работала почти 2 года. Я заставил ее делать все что нужно. Проблема была именно в том, что начала деградировать производительность и мне было реально страшно запускать на ней другие процессы, если она с существующими кое-как справляется.
Насчет внедрения «как в маленьких, так и больших компаниях» можно отдельную статью написать. Я насмотрелся и наслушался. Вкратце, не все внедрения можно считать удачными, даже если от них нет обратной связи, но они исправно платят мзду. Хотя, кому что является критерием успешности.
Мой жизненный опыт показывает, что 80% внедрений выполненных интеграторами попадают в категорию «ежики плакали, но продолжали жрать кактусы».
>>Не знаю, зачем вам могло это понадобится, но раз исправили за 2 месяца, в этом был какой-то резон.
Какая разница зачем? Есть потребность. Есть доступ к файлам в коде. Присваиваю новое имя, ан нет. Оказывается так нельзя! Но решили и ладно. Правда 2 месяца ждать возможности переименовать файл… круто! Если вы контачите с разработчиками: ticket 19492
>>сможете прислать экспорт процесса?
Сейчас в этом нет смысла. Добавлю только, что в техподдержку отправлял всю базу. Если верно понял, ребята на своей стороне поднимали нашу базу, запускали процессы и изучали причины. ticket #19556
>>ELMA это серьезный продукт с огромным функционалом
Да кто спорит, но не наивные же ошибки! Когда ошибка глубоко, как с теми же дубликатами задач, я был готов простить и понять и терпеливо ждал исправления. Ситуации бывают разные, может и впрямь я создал такую, что система повела себя неожиданно.
Windows, Word, Excel, серьезные продукты с огромным функционалом, но они же не допускают подобных смешных ошибок. Ошибки есть, не спорю и некоторые клонируются и из версии в версию (например, Excel до сих пор не переваривает множество квадратных скобок в именах файлов).
Про поиск.
Нет конечно, не было новостью. Но это стало еще одной «ложкой дегтя» среди прочих. Кстати, поиск глючил, но сейчас точно не вспомню как именно. Нестабильно искал, что ли. Скажем, пользователь ищет — не находит документа, который точно есть, а на другом компьютере под другим пользователем находится. Права в порядке. На след. день такой проблемы нет. И в техподдержку не напишешь.
Про скорость.
Суть ведь не в используемой базе данных. Сервер мощный и под elma и под ms sql. Но система тормозит страшно! Я даже знаю ответ почему, но мне от этого не легче. Повлиять на это не могу. Кстати, я не один такой (читайте комментарии выше).
P.S. Самый фееричный ticket — 20973. Меня убеждали в том, что XML ответ на SOAP запрос с encoding=utf-8 может (!) и совершенно нормально, что содержит русские символы в кодировке 1251! Где это видано, чтобы XML с encoding=utf8 допускал содержание национальных символов в другой кодировке? Мне пришлось строки кодировать в base64, передавать и раскодировать обратно.
Вы, tearexs, похоже из техподдержки elma. Вот поясните, почему нативный код вида:
var manager = EntityManager.Instance;
DateTime startdate = new DateTime(entity.RegDate.Value.Year, 1, 1);
DateTime enddate = new DateTime(entity.RegDate.Value.Year, 12, 31);
var allInYear = from d in manager.FindAll()
where d.RegDate.Value >= startdate && d.RegDate.Value <= enddate
orderby d.CntNum
select d;
if (allInYear.Count() == 0)
entity.CntNum = 1;
else
entity.CntNum = allInYear.Last().CntNum + 1;
Выполняется примерно в 1000 раз медленнее обращения к базе через c#'овский SqlConnection?!
Прошу процитировать, что именно делает статью «гадкой» и «притянутой за уши», если она на самом деле является описанием собственного опыта перехода от одной системы к другой.
Уважаемый автор комментария. Вы похоже даже не прочитали статью. Я явно указал на то, что систему elma изучил и довольно детально. Более того, я запустил ее в эксплуатацию! И она успешно работала до 2015 года! Почти 2 года! Поэтому не надо упирать на недостаток средств или компетенции. Техподдержка elma получила от меня, как они сами писали, «очень полезный фидбек».
Укажите мне место в статье, которое очерняет «столь замечательный продукт».
1. На скриншотах интерфейс easla.com как он есть. Ничего не допиливалось. Есть темы (theme), если это важно.
2. Разработка интерфейса чего, простите? Вы про разработку easla.com или про разработку процессов в ней? Если последнее, то никак. Просто создаете объект, накидываете в него атрибуты и все готово. Про это есть отдельные статьи. Например: https://habrahabr.ru/company/easla/blog/281839/
3. В easla.com нет понятия «отрисовка процесса», т.к. в ней нет редактора блок-схем, как в elma или в Lotsia PDM Plus. Я работал с обеими этими системами и в обеих настраивал процессы с помощью блок-схем. Или мои требования завышены, или возможности систем ограничены, но в конечном счете проблем больше, чем преимуществ. Работая несколько лет с системой TDMS, которая описывает поведение кодом, сделал для себя вывод, что такой подход оптимальный. Именно он и реализован в easla.com. Все поведение объектов описывается кодом на PHP. Разумеется, возможности PHP урезаны в целях безопасности.
Все описанные выше процессы сделаны «с нуля». Подробнее, см. другие статьи, например: https://habrahabr.ru/company/easla/blog/281999/
В части затрат времени, если вы PHP-программист, то наверняка знаете, что такое ООП :) Поэтому идеологию easla.com поймете минут за 20. После этого сможете сваять новый объект с атрибутами и действиями за час. Проще понять что и как работает на конкретном примере, поэтому была статья: https://habrahabr.ru/company/easla/blog/281479/
4. На текущий момент несколько сотен пользователей онлайн.
Я не понимаю, что именно «неприлично»? Я что, написал в блоге, что elma плохая система? Я как-то дискредитировал ее? Я как пользователь elma указал на проблемы, с которым столкнулся лично. Лично! И даже не указывал на их систематичность, и нигде явным образом не написал, что «не покупайте elma». Напротив, в конце дописал, что кому-то она подойдет, но нам не подошла.
Статья может быть интересна как потенциальным потребителям elma, ищущим отзывы о системе, так и нынешним пользователям системы, которые, возможно, столкнулись с похожими проблемами.
Цель статьи, поделиться опытом перехода с одной системы на другую. Только и всего!
P.S. Я могу только предположить, что всполошились представители команды разработчиков elma. Надо же позаботиться о том, чтобы заминусовать статью и она не нашла большого круга читателей.
А если я и пользователь, и сотрудник, как быть?! Как насчет «бест практик», когда разработчик сам пользуется тем, что написал? :)
Убрать их оплаченного хаба?
Я так и думал, что примут за антирекламу, а не объективную оценку. Ну хорошо, убрал бы я в статье упоминания об elma и easla.com — это было бы политкорректно, но неинформативно?
Я подошел к написанию статьи как программист, который внедрял систему elma, отгреб шишек и перешел на другую, которую, кстати, сам и написал. Показал объективные причины перехода. Недостатки предыдущего решения. Преимущества нынешнего инструмента.
P.S. Скажем так, я в составе команды разработчиков easla.com, поэтому в платном блоге. Это важно?
Из всех критикующих комментариев складывается впечатление, как будто Yii всей своей сущностью и натурой заставляет программиста писать неэффективный/буксующий код, а все остальные фреймворки — нет. По-моему все зависит от программиста, его компетенции в PHP в целом и в Yii в частности!
Как говорится, нечего на зеркало кивать, коли рожей не вышел.
Зачем же так категорично. Лично мне пришлось такую задачу решать. Банальный экспорт данных. Их может быть много и их надо тащить на сторону PHP.
Сперва пробовал CActiveDataProvider, таскал по 100 записей. Получилось невыносимо медленно. Переделал на CArrayDataProvider и все зашевелилось.
Если запросы из приложения на Yii будут возвращать десятки записей, т.е. фреймворку придется создавать только десятки AR, то вполне сопоставимы. Скажем так, конечный пользователь не заметит разницу.
Но если вы имеете ввиду, что запросы будут возвращать 100500+ записей, то от AR надо отказаться.
Наивные, см. ticket 23220
Мне уже не нужна помощь, спасибо. Я себе помог.
>>Тут нечего сказать, рад что вы смогли справиться с проблемой.
Я то как рад был бороться с проблемой, которой не должно быть!
Очередной раз подчеркну, что система работала почти 2 года. Я заставил ее делать все что нужно. Проблема была именно в том, что начала деградировать производительность и мне было реально страшно запускать на ней другие процессы, если она с существующими кое-как справляется.
Мой жизненный опыт показывает, что 80% внедрений выполненных интеграторами попадают в категорию «ежики плакали, но продолжали жрать кактусы».
Какая разница зачем? Есть потребность. Есть доступ к файлам в коде. Присваиваю новое имя, ан нет. Оказывается так нельзя! Но решили и ладно. Правда 2 месяца ждать возможности переименовать файл… круто! Если вы контачите с разработчиками: ticket 19492
>>сможете прислать экспорт процесса?
Сейчас в этом нет смысла. Добавлю только, что в техподдержку отправлял всю базу. Если верно понял, ребята на своей стороне поднимали нашу базу, запускали процессы и изучали причины. ticket #19556
>>ELMA это серьезный продукт с огромным функционалом
Да кто спорит, но не наивные же ошибки! Когда ошибка глубоко, как с теми же дубликатами задач, я был готов простить и понять и терпеливо ждал исправления. Ситуации бывают разные, может и впрямь я создал такую, что система повела себя неожиданно.
Windows, Word, Excel, серьезные продукты с огромным функционалом, но они же не допускают подобных смешных ошибок. Ошибки есть, не спорю и некоторые клонируются и из версии в версию (например, Excel до сих пор не переваривает множество квадратных скобок в именах файлов).
Про поиск.
Нет конечно, не было новостью. Но это стало еще одной «ложкой дегтя» среди прочих. Кстати, поиск глючил, но сейчас точно не вспомню как именно. Нестабильно искал, что ли. Скажем, пользователь ищет — не находит документа, который точно есть, а на другом компьютере под другим пользователем находится. Права в порядке. На след. день такой проблемы нет. И в техподдержку не напишешь.
Про скорость.
Суть ведь не в используемой базе данных. Сервер мощный и под elma и под ms sql. Но система тормозит страшно! Я даже знаю ответ почему, но мне от этого не легче. Повлиять на это не могу. Кстати, я не один такой (читайте комментарии выше).
P.S. Самый фееричный ticket — 20973. Меня убеждали в том, что XML ответ на SOAP запрос с encoding=utf-8 может (!) и совершенно нормально, что содержит русские символы в кодировке 1251! Где это видано, чтобы XML с encoding=utf8 допускал содержание национальных символов в другой кодировке? Мне пришлось строки кодировать в base64, передавать и раскодировать обратно.
var manager = EntityManager.Instance;
DateTime startdate = new DateTime(entity.RegDate.Value.Year, 1, 1);
DateTime enddate = new DateTime(entity.RegDate.Value.Year, 12, 31);
var allInYear = from d in manager.FindAll()
where d.RegDate.Value >= startdate && d.RegDate.Value <= enddate
orderby d.CntNum
select d;
if (allInYear.Count() == 0)
entity.CntNum = 1;
else
entity.CntNum = allInYear.Last().CntNum + 1;
Выполняется примерно в 1000 раз медленнее обращения к базе через c#'овский SqlConnection?!
Укажите мне место в статье, которое очерняет «столь замечательный продукт».
2. Разработка интерфейса чего, простите? Вы про разработку easla.com или про разработку процессов в ней? Если последнее, то никак. Просто создаете объект, накидываете в него атрибуты и все готово. Про это есть отдельные статьи. Например: https://habrahabr.ru/company/easla/blog/281839/
3. В easla.com нет понятия «отрисовка процесса», т.к. в ней нет редактора блок-схем, как в elma или в Lotsia PDM Plus. Я работал с обеими этими системами и в обеих настраивал процессы с помощью блок-схем. Или мои требования завышены, или возможности систем ограничены, но в конечном счете проблем больше, чем преимуществ. Работая несколько лет с системой TDMS, которая описывает поведение кодом, сделал для себя вывод, что такой подход оптимальный. Именно он и реализован в easla.com. Все поведение объектов описывается кодом на PHP. Разумеется, возможности PHP урезаны в целях безопасности.
Все описанные выше процессы сделаны «с нуля». Подробнее, см. другие статьи, например: https://habrahabr.ru/company/easla/blog/281999/
В части затрат времени, если вы PHP-программист, то наверняка знаете, что такое ООП :) Поэтому идеологию easla.com поймете минут за 20. После этого сможете сваять новый объект с атрибутами и действиями за час. Проще понять что и как работает на конкретном примере, поэтому была статья: https://habrahabr.ru/company/easla/blog/281479/
4. На текущий момент несколько сотен пользователей онлайн.
Статья может быть интересна как потенциальным потребителям elma, ищущим отзывы о системе, так и нынешним пользователям системы, которые, возможно, столкнулись с похожими проблемами.
Цель статьи, поделиться опытом перехода с одной системы на другую. Только и всего!
P.S. Я могу только предположить, что всполошились представители команды разработчиков elma. Надо же позаботиться о том, чтобы заминусовать статью и она не нашла большого круга читателей.
Убрать их оплаченного хаба?
Я подошел к написанию статьи как программист, который внедрял систему elma, отгреб шишек и перешел на другую, которую, кстати, сам и написал. Показал объективные причины перехода. Недостатки предыдущего решения. Преимущества нынешнего инструмента.
P.S. Скажем так, я в составе команды разработчиков easla.com, поэтому в платном блоге. Это важно?
Как говорится, нечего на зеркало кивать, коли рожей не вышел.
Сперва пробовал CActiveDataProvider, таскал по 100 записей. Получилось невыносимо медленно. Переделал на CArrayDataProvider и все зашевелилось.
Но если вы имеете ввиду, что запросы будут возвращать 100500+ записей, то от AR надо отказаться.