Евген Трезвых: И одновременно другие пакеты, которые тянут пакет 2 получается используют и пакет 1, хотя он и не нужен. Мне кажется в ваших пакетах нарушаются принципы ооп. Посмотрите лекцию о grasp шаблонах, если не знакомы с ними - www.youtube.com/watch?v=8wRQ92Hg2bY&index=2&list=P...
sim3x: Это не теория, у меня на одного клиента, готового сделать что-то на фреймворке приходится наверное с десяток (в том числе из них постоянные клиенты), которым нужно что-то простое (= реализуемое функционалом существующих cms) и подешевле. Причем тот один, которому нужен проект на фреймворке просто не сможет реализовать его на cms.
sim3x: дело ведь не только в наличии толкового разраба. На него надо во-первых, больше денег, во-вторых - больше времени. А суровые бизнес реалии говорят: дешевле и быстрее - лучше. И уже с точки зрения бизнеса тратить на темную лошадку на старте в 5 раз больше ресурсов становится нелепо. Хотя подчеркну, я сейчас говорю о тех проектах, аналоги которых можно разработать дешевле, а не о чисто кастомном функционале, который на вордпрессе окажется слепить сложнее, чем на фреймворке.
для старта вполне себе используется, помню с пару лет назад мобайл ревью работал на вордпрессе, он уже тогда был достаточно приличным по размеру сайтом. Если деньги есть - конечно все на стероидах, да подороже сделать. Но если на старте нужно сэкономить, а требуемый функционал покрывается той же джумлой или еще чем - почему бы не использовать cms, пока та справляется? Деньги появятся - можно уже заказывать разработку хоть на симфонии, хоть на ноде, хоть на черте лысом. Но проект может и не дожить до того светлого момента.
Pauletto: В целом подход управления по списку ключей правильный и в этом плане вы на верном пути (по крайней мере с моей точки зрения) - иначе вы никак различные сущности не разделите, а кешировать все одной кучей смысла не имеет, просто мне сейчас кажется, что вы акцентируетесь на редисе и в результате напишете сильно завязанный на этом хранилище код. Я предлагаю вам для начала абстрагироваться от редиса как хранилища и накидать общий интерфейс для общения с хранилищем, через который и работать (вдруг вам придется потом поменять редис на что-то другое). В ларавеле работа с кешем и различными хранилищами уже есть из коробки и мне кажется, что в yii подобный функционал тоже должен быть, ну или хотя бы должен быть сторонний пакет. Интерфейс несложный на самом деле, в нем всего -то накидать пару основных методов, которые вам потребуются (создать ключ, удалить ключ, проверить существование ключа, удалить все, получить значение ключа, задать время хранения ключа, может еще работу с группами ключей организовать. типа найти все ключи news.* ).
Другое дело что логику работы с самим кешем (отдельно с типовым абстрактным хранилищем, а не с редисом конкретно) вам надо продумать. К примеру я бы задумался, почему если редактор делает что-то не то, то это сохраняется в кэше? Можно ведь повесить обнуление кеша новостей на событие "сохранениеНовости", а создание на первое из открытие - как раз тот самый прокси паттерн (зачем редактору лезть и нажимать вручную кнопку каждый раз, если это можно автоматизировать?). Я кстати тоже плохо объясняю :) Либо скрипт будет автоматически сравнивать дату изменения новости и дату в кэше и либо отдавать кэш, либо пересчитывать его заново.
Pauletto: Ну тут по задаче вам смотреть. Может ваше "лежат отдельно" подразумевает общую базу данных, а может сейчас окажется, что все на разных серверах лежит и вы будете через rest api сейчас новости подтягивать, я же не знаю. Может вы новости раз в день кэшировать будете и вся оптимизация на этом закончится и не попросят ничего в ближайший год, а может это только первый шаг к полноценной оптимизации и вам нужно нормальное решение для кэширования всего и вся, чтобы потом не развалилось ничего и в код контроллеров не требовалось лезть на каждый чих.
FloorZ: в силу недостаточно компетентного менеджмента компании. Нет, хорошо, конечно, когда везде соломка подстелена, но люди-то все равно неидеальны и от всего не застраховаться. а akuma при подобном подходе в будущем имеет куда большие шансы занять место незаменимого начальника при его уходе, так как будет обладать необходимыми знаниями. И владельцу компании умные самостоятельные люди будут куда полезнее, чем поленья, неспособные самостоятельно что-то сделать. Другое дело, оценит ли это само руководство или нет.
sitev_ru: как и все остальное во фреймворке - для удобства и экономии времени разработчика. Пока вы озадачиваетесь написанием механизма разбора адресной строки, другой разработчик возьмет фреймворк, в котором этот механизм реализован (как и многие другие типичные задачи) и используют его для того, чтобы писать необходимую им логику приложения. Причем в нем уже есть то, с чем вы наверняка столкнетесь в будущем: тип запроса (get, post, put, delete), унификация получения от них параметров (тех, что в get идут после знака вопроса), роутинг, валидация данных. Какой смысл кодеру писать логику разбора адресной строки, если он может просто написать "адрес, соответствующий шаблонку /user/{id} обрабатывается контроллером User"? Ну и учитывая, что симфония все-таки фреймворк для веб-приложений, в подавляющем количестве случаев данные будут поступать именно из http запросов.
Максим Глушков: файлов в phpmyadmin? если вы про значения ячеек в таблицах, то с ходу оптимальное решение не назову, можно либо так: it-pages.ru/mysql-massovoe-izmenenie-znachenijj-v-... (думаю, для изменения части прокатит where like %part%, но не сталкивался с подобной задачей давно) либо сделать экспорт sql в файл, потом открыть фал в текстовом редакторе и произвести замену, после чего залить измененный sql дамп обратно, либо задать новый вопрос на тостере :)
А если вы хотите генерировать js посредством php, то тоже лучше не стоит так делать - это кривая архитектура. Лучше сделайте, чтобы ваш скрипт запрашивал через аякс необходимые данные у сервера и их уже обрабатывал.
Тикет системы - это другое. Если человек желает найти скрипт для создания биржи или подобного продукта в поисковике, он не будет вводить "тикет системы".
думаю, лучше бы указать количество примерное значений а также подумать о том, будете ли вы осуществлять по ним в дальнейшем поиск и сортировку. А так если их только положить и достать, то возможно достаточно преобразовать массив в json перед сохранением и затем отдавать напрямую на фронтэнд, где график построится яваскриптом, но сильно зависит от задачи.
AlievMix: писать на вордпрессе - очень бредовое решение. Это блоговый движок с устаревшей архитектурой (сейчас назвать этот набор функций архитектурой стыдно), не имеющий никакого отношения к вашей задаче. "Навсегда" в данном случае обернется тем, что кроме автора за поддержку вашего решения браться никто не станет (по крайней мере из соображающих парней), а автор либо сможет заломить цену на доработку, либо исчезнет и ваша система замрет в статисе без каких-либо доработок, причем будет хорошо, если разработка вообще дойдет до финала. Бегите как от огня от того разработчика, если он делает системы учета на вордпрессе в 2015 году. Для затравки: habrahabr.ru/post/251257
А то, что ответа здесь не получили - скорее всего требования к системе настолько специфичны, что никто в существующих решениях их не встречал (обычно здесь хорошо советуют по коду, особенностям фреймворков/cms, либо по готовым решениям для типовых задач). Если писать с нуля, то использовать для этого нормальные современные фреймворки, а не блогодвижок: yii2, laravel, symfony 2.
Киньте весточку мне на ящик bonesbrain[gmail.com], интересно будет поговорить по вашей системе.
Sanes: это же не тз на разработку, человек спросил основное, что хотел бы видеть в готовом продукте и есть ли такой продукт. Если пойдет заказывать с нуля, тогда уже и будет писать, что да как совместно с разрабом.
