Check Levi9 best QA positions to Backbase team!
×Закрыть

Портативний фреймворк або набір інструментів для веб-програміста

По ходу розробки і підтримки сайтів, мені доводиться часто стикатися з самописами, системами з убогою документацією чи невеликими скриптами, на зразок парсерів.

Для власної зручності я зашив набір методів і процедур, якими найчастіше користуюся, у окремий файл і підключаю його до коду в разі потреби. Вийшов такий собі портативний фреймворк зі всіма необхідними мені методами.

На практиці це в кілька разів прискорює роботу по правках вже існуючого сайту і/або написання невеликих скрипті, де використання повноцінного фреймворку є недоцільним.

На днях в мене з’явилася ідея оформити цей файл, як бібліотеку інструментів для веб-розробки і залити його в репозиторій.

Наразі в ньому закладене наступне:
— Методи роботи з базою MySQL
— Система Шоткодів
— Система Хуків
— Алгоритм Settings
— Алгоритм Content
— Алгоритм підключення шаблонів
— Алгоритм виведення повідомлень (для відладки коду)
— І ще ряд дрібних функцій та методів.

Кому цікаво, ось посилання на репозиторій: bitbucket.org/...atsura/uppercode-portable (доків поки немає).

Питання
А які функції, методи і алгоритми використовуєте ви для повсякденної роботи, який функціонал потрібен особисто вам і чи ви б взагалі користувалися подібним файлом? — напишіть будь ласка відповідь у коментарях.

Дякую за увагу.

👍НравитсяПонравилось0
В избранноеВ избранном0
LinkedIn

Похожие топики

Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Допустимые теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

Обхожусь такою штукою як: html5boilerplate.com , хоча іноді потрібно і це правити.

Наскільки я зрзумів, це набір шаблонів/заготовок для верстальника, а тема топіка — набір інструментіі для бекенду

Я думаю, що всі «бородаті PHP програмісти» через це пройшли.

Особисто в мене, 90% подібних розробок покрились прахом після того як перейшов на symfony, а потім на yii. (доречі, як на мене, yii на дві голови вище за symfony1, про symfony2 нічого не знаю).

З подібного коду залишилась лиш

function issetdef(&$var, $def=null, $possible=null)
{
    if (isset($var))
    {
        if ($possible===null)
            return $var;
        if (is_array($possible))
            return in_array($var, $possible) ? $var : $def;
        if ($var == $possible)
            return $var;
    }
    return $def;
}
і аналогічна nemptydef().

Решта ж наробок зазвичай вписується в yii-шу модель модуля або розширення, що зазвичай і використовується і має вузьке функціональне призначення, а не «ліба на всі випадки життя».

Это не портативный фреймворк и не набор инструментов, это просто свалка методов

Несколько замечаний по коду
1. Несколько классов в одном файле
2. Стиль кодирования
3. Константы в начале файла
4. Методы без заданного уровня доступа
5. Private свойства, статические методы и конструкторы, которые тяжело тестировать и наследовать. Тестами не покрыто
6. Поточна версія: 1.2 — подразумевает, что были 0.1..1.1 версии, которые можно скачать и потрогать, и почитать changelog. У вас только master ветка и какой-то тег ’tip’.

Теперь по поводу целей, которые вы приследуете...
— composer
— traits с семантическими названиями, т.к. у вас набор разноплановых методов, которые не относятся к конкретным сущностями
— покрыть тестами

P.s. Куча мест, где php5.3 и классы/объекты наше все — не аргумент

1. Несколько классов в одном файле
3. Константы в начале файла

Завданням було в 1 файлі розмістити все мені необхідне, а ліпити в 1 клас це все я не дуже ходів

2. Стиль кодирования
Це просто 2 слова, я не зрозумів, що не так з моїм стилем

Відносно 6-го пункту., по-моєму це вже питання авторських забаганок, для мене перша версія — версія 1.0

Ну і що, що 1 вітка, я цей файл на минулому тижні створив, закинув туди все, що мені було необхідно з моїх попередніх проектів + вніс походу справи кілька правок, і виправив баги. А тег — це взагалі програма (Hg), яка з меркуріалом працює, по замовчуванню додає — не розумію, в чому проблема.

І що не так з класами і об’єктами?

Ви коли критикуєте, то критикуйте по суті, а не робіть вигрузку тезисів.

З таким самим успіхом я можу прокртикувати ваш акаунт на доу:
1 — аватарка
2 — особисті дані
3 — пів місяця на порталі
4 — поганий стиль письма

ПС: сумнівної персоналізації акаунт, схожий на троля

Якщо ви думаєте, що я вирішив похизуватися своєю роботою, то глибоко помиляєтесь — моя мета зрозуміти чи варто мені розвивати ідею і допрацьовувати файл, чи це взагалі комусь окрім мене потрібно буде коли-небудь. Тому прошу або конструктивно критикувати або «не засмічувати ефір».

Дякую.

Мой комментарий не является критикой. Это моменты, на которые я обратил внимание. Это ваш код, и вам его использовать. Если он работает и работает правильно — это уже большая часть дела. Рефакторить можно очень долго.
Ну, а мой профайл — это мой профайл...

— по поводу фреймворков. Есть разные фреймворки — full stack и not-full-stack. В вашем случае это и не то, и не другое. У вас утилиты/библиотека. В текущий момент выбор фреймворка в php затруднен. Вектор направлен на создание фреймворков из компонентов с малой связанностью. НО full stack фреймворков мало (ZF2, SF2, Lavarel) и каждый из них обладает кучей недостатков. Большой уклон делается на rest api, но функционал/скорость/архитектура у всех хромает...
— стиль кодирования. Используйте PHP_CodeSniffer и PSR2 (или тот, который вы считаете нужным). Есть утилита для автоматизации github.com/...ot/PHP-CS-Fixer
— версирование. semver.org. Git hub теги можно использовать для фиксации версий. Т.е. если вы вчера залилил, то укажите версию 0.0.1. Получите здесь кучу критики, нарастите версии и выкатите потом 0.1.0... потом крутую либу с версией 1.0.0 и отметим это дело!
— покрытие тестами. Private свойства, статические методы, передача параметров напрямую в конструктор — это все усложняет тестирование.
— Классы и применение. Класс подразумевает реализацию какой-то сущности. Через интерфейсы вы можете наращивать присущий сущности функционал. Трейты удобны для добавление не относящегося к сущности функционала (для общего функционала, ИМХО, больше подходит абстрактный класс), типа утилит, работы с БД и т.д., что у вас в классе. У вас есть и утилиты и сущности. Но т.к. php не поддерживает множественное наследование, то ваша библиотека SQLQuery сразу накладывает ограничение для расширения класса, т.к. нужно будет наследоваться от вашего или делать какие-то обертки для него.
Если проблема именно в использовании одного файла — есть phar php.net/...using.intro.php
— Распространение. Сейчас набрали популярность менеджеры пакетами. Для php это composer. Почему это удобно... Когда вы начинаете разработку, некоторые требования бывают не до конца сформулированы. Поэтому делать импорт с мощью git и поддержвать зависимости, версии вручную накладно.
— www.phptherightway.com

помойму у тебя стальные нервы ;)

Красно дякую за конструктивність і конкретність, без пафосу і зверхності. Ваш коментар насправді дуже корисний.

чи варто мені розвивати ідею і допрацьовувати файл, чи це взагалі комусь окрім мене потрібно буде коли-небудь
Нет, в текущем виде это просто неподдерживаемый трэш без документации, тестов и смысла. Да о Вашем велосипеде никто даже не узнает!

Не согласен. Оформите, как законченный пакет с документацией и тестами. И из этого обязательно что-то получится в будущем!

Что получиться? Новый ORM?

Да. Есть аргументы почему не получится?
Из pet проектов всегда что-либо извлекается — опыт, польза от использования кода, деньги и т.д.
Уже то, что топикстартер залил код на bitbucket и создал обсуждение, это плюс ему
И, кстати, версия 2.0 бывает полностью переработанная версия 1.0, на которой набиваются шишки и получается опыт

А зачем нужен еще один ORM вообще?
Почитайте код. Его нужно стереть чуть более, чем полностью.

К чему эти ваши комментарии?
Я говорю — оформи код нормально, сделай библитеоку и веди нормально версии. Развивай код и смотри за его изменениями в истории. Что у него получится — это его дело.
Вы говорите — зачем это нужно? зачем еще один ORM?

Что вам ответить?! Пишите на ассемблере... зачем этот php

P.s. Больше не отвечаю на ваши реплики. Пишите топикстартеру, а не мне

Думаю, имеется ввиду, что это не нужно сообществу. А для самого разработчика, это конечно же плюс. Написал что-то => залил на битбакет => показал на ДОУ => получил по шапке => стал писать лучше | узнал о куче новых классных либ/фреймворков => профит!

я взяв частину своїх напрацювань, залив в 1 файл і підключив до діючого проекту, бо мені потрібні були ці функції.

Потім я подумав, що така штука могла б комусь ще пригодитись і вирішив спитати у цільової аудиторії. Не розумію, що тут поганого.

Крім того, я завжди думав, що форуми існують для обміну досвідом і якщо ви не готові до цього, тоді навіщо взагалі вступаєте в дискусію?

Дискуссии в этом топике напомнили, одну цитату: twitter.com/...​status/537286049505226752

На счет обмена опытом: я дал Вам несколько ссылок, которые считаю полезными и интересными. Со своей стороны, посмотрел Ваш код и сделал для себя выводы. Обмен опытом произошел, что не так то?

та наче все так, і за посилання я вам подякував, просто я не зовсім розумію, що ви мали наувазі тут:

Написал что-то => залил на битбакет => показал на ДОУ => получил по шапке => стал писать лучше | узнал о куче новых классных либ/фреймворков => профит!

що в цьому поганого?

В этом нет ничего плохого :) Наоборот — профит для личного развития ж.

в такоу разі, перепрошую — я вас не правильно зрозумів.

Не буду сперичктися, хоча не погоджуюся що це повний треш, всі функції там робочі і протестовані не раз.

Щодо форми, то це фактифно перша верія, яка так чи інакше буде переписуватися удосконалюватися і документуватися, якщо я зрозумію, що подібна річ буде потрібна комусь ще, окрім мене.

Знаете, смешно получается.
Делаешь code review подобного проекта, с &$array, global, eval, @ и прочими инфернальными трюками. И все функции — рабочие, а проект поднять хотя бы локально, без без подавления всех типов ошибок — очень сложно, а уж добавить что-либо в воронку этого месива или не дай Бог оптимизировать — просто нереально.

Вам дали отличную ссылку на PHP Right Way, и не один раз упомянули про SF2 / Doctrine 2. Лучше разберите их на компоненты (благо, это несложно ввиду особенностей дизайна) и возьмите те, которые нужны Вам в работе. Если будет нужно — расширите (благо, это несложно, ввиду особенностей дизайна). А перестать писать велосипеды нужно как можно раньше.

Хмм, т.е. отсутствие тестов, именование версий и опущенные модификаторы доступа вас смутили, а
mysql_*
$koma=", ";
addshashes, in db::protect()
global $PData; global $UCodeHooks;
— нет?

Откройте исходники WP, с которым человек работает...
Я так понимаю, топикстартер растет и развивается... хочется сделать что-то свое...
Так что, вышеуказанное меня не смущает
Смысл в чем, ты или что-то делаешь в плане развития, или не делаешь... Он сейчас оформит это в виде законченного пакета на packagist с версией 0.0.1. Т.е. будет готовый пакет, которым он будет пользоваться. Возможно он еще кому-то пригодится... через пару месяцев внесет правки и будет 0.0.2

Советую Laravel 5, или Symfony2. Большое количество пакетов и готовых решений из коробки есть под оба фреймверка. Первый больше подходит для небольших проектов, второй уже конечно для серьезных решений. Для Laravel есть orchestraplatform.com для симфони sonata-project.org

ps: сам пока юзаю laravel 5, очень доволен

1,5 роки тому перебирав фреймворки на те, який з них найкращий з точки зору швидкодії, вичерпності доків і легкості вивчення. Вибір впав між kohana, codeignitor i yii — зупинився на yii через повноту доків і інноваційність, хоч codeignitor видавався швидшим. Від зену і симфоні зразу відмовився через порівняно високий поріг входження і низьку продуктивність, а от про ларавел я почув перший раз тільки недавно, та ще не досліджував його. По відгуках знайомих — у нього зручна архітектура — програмер френдлі, такби мовити :)

Що ви можете на цю тему сказати про Laravel?

Symfony2 — прекрасний. Має божествену документацію і тисячі статей в стилі «для чайників».
Про який високий поріг входження ви говорите?

З приводу Laravel — він побудований на компонентах від Symfony і прикритий купою фасадів.
Сам зараз вивчаю Symfony і не нарадуюсь. До цього пробував розбиратися з Laravel — документація фігова, чесно кажучи. Це я про англійську версію.

Я читав критику і порівняння різних фреймворків — переді мною стояло завдання вибрати оптимальну технологію для подальшої роботи з нею новоспеченої команди. Зупинилися на yii.

Я категорически не советую использовать фасады. Они полностью противоречат идеи IoC. Мне кажется они их придумали что бы снизить порог вхождения.

Насчет документации согласен, она могла быть и получше. У них есть еще отличный laracasts.com с видео уроками, хотя и не все там бесплатно =). И кстати практически все вопросы можно решить просто изучив исходный код. Он там прост как пачка печенья.

Так я ж це саме і мав на увазі, що фасади — це костиль.

Я просто решил еще раз подчеркнуть это. Что бы никому в голову не пришло их использовать =)

Могу сказать что на Laravel можно писать как качественный код, так и гамнокод (привет фасады). В свое время я искал альтернативу первому зенду, по простоте и функциональности (без Doctrine и прочих вундервафлей, которые хобби проектам не нужны), но при этом с новомодными плюхами типа Composer, Dependency Injection, простой Active Record и прочие плюшки облегчающие жизнь. Laravel с этой задачей справляется на ура. Хотя конечно очень хочется иметь аналог сонаты. Благодаря composer есть возможность подключать библиотеки из symfony2 и zf2 и прочих. А что насчет скорости, я вот никогда не видел что бы тормозил php код. Узкое место чаще в плохой архитектуре самого приложения. Да и выиграть 5% производительности но потерять 100% скорости разработки тоже весьма сомнительный плюс, сервера нынче дешевле человеко-часов.

Цілком погоджуюсь, в мене був 1 випадок, коли програміст так накодив, що після нього довелося переробляти 80% роботи і продуктивність фреймворку не помогла...

Щодо симфоні, то треба буде промоніторити якось ще раз це питання, можливо я просто надто сильно спішив, коли моніторив фреймворки.

Simfony2 хороша в паре с Doctrine, если научится их готовить. Для сложных систем наверное лучше не придумать. Для простых — это как с пушки по воробьям.

Є Kohana 3.2, з парою доробок дозволяє швидко підняти новий проект с авторизацією і адмінкою. Але якщо починав би новий великий проект, віддав би перевагу чистому Kohana останньої версії, або навіть якомусь іншому фреймворку. А щось готове універсальним бути не може, ще й застаріває.

Kohana вроде уже не развивается, так что думаю для нового проекта кохану брать нецелесообразно, IMHO. Хотя помню когда-то его смотрел — симпатичный фреймворк.

Можно и другое что-то взять. В любом случае, тащить наработки 2-3 летней давности имеет смысл например в случае, когда надо сделать в краткие и точные сроки. А если время есть — то лучше выбрать хороший актуальный фреймворк, дописав всё нужное с нуля, руководствуясь полученным за последние годы опытом.

Изобретение велосипедов это конечно круто, но... В общем просто оставлю это здесь: www.phptherightway.com

За посилання дякую, та мова йде не про дублювання стандартних функцій і методів РНР, а про набір інструменрів для полегшення роботи програмісту.

Наприклад, зазвичай запити на UPDATE чи INSERT в базу формуються кожен окремо, ви прописуєте повністю весь запит, кожну кому, дужку і апостроф. Я ж роблю так:


global $sql;

$array = array(
   'title' => 'Заголовок',
   'text' => 'Якийсь текст',
   'category_id' => '2'
);
$sql->update('posts', " id='1' ", $array);

всі інші маніпуляції, формування запиту, екранування даних і отримання відповіді, робить метод сам.

На практиці це в кілька разів пришвидшує роботу і зменшує ймовірність виникнення помилки у синтаксисі запиту.

А у готовому фреймворку є query builder наприклад, який ще зручніше і супер-надійний у плані безпеки.

Я бы советовал взят какой ни будь современный наиболее распространенный фреймверк, и построить на нем свой набор инструментов. Сначала попытаться найти готовое решение, потом если таких нет то реализовать свое, как независимую библиотеку под каждую задачу. Таким образом ваш код не будет выделятся, и возможно даже кому то пригодится. На сегодняшний день, библиотека которая не распространяется через composer и не поддерживает автозагрузку например по стандарту psr-4, это моветон.

PS: как вариант можно еще рассмотреть микро фреймверки например Silex (микро симфони), это позволит вам остаться симфони совместимыми.

а что это шоткоды и хуки ?

Шоткод, це невеликий підрядок у строці, який при ініціалізації запускає функцію, результат якої вставляється в те місце строки, де було розміщено шоткод.

Наприклад, наступні рядки ідентичні:
global $PData; echo $PData->shortCode('Вартість розробки сайту [:DollarToGRN 500:] грн.');
і
echo 'Вартість розробки сайту '.DollarToGRN(500).'грн.';
З тою лиш різницею, що у першому випадку строку можна витягувати з бази даних.

Хук, з англійської гак, — це механізм, який дозволяє змінити результат виконання функції, шляхом запуску допоміжних функцій, не змінюючи коду основної функції.

Наприклад, ми розміщуємо ініціалізацію хука в середині тегу <head> і нам потрібно з різних файлів або при різних умовах підключити виконання якихось функцій (підключити бібліотеку JQuery і скрипти слайдера, якщо користувач на сторінці галереї), а з іншого файлу нам потрібно підключити скрипти lighbox для повного перегляд зображень. В даній замість того, щоб редагувати хед сторінки, ми просто підключаємо функцію до хуку типу filter і вертаємо HTML строку.

Хуки і шоткоди широко використовуються у багатьох двигунах і фреймворках — точно знаю, що в Yii є хуки, за шоткоди не впевнений, у WordPress і те і інше присутнє, а от в OpenCart ні хуків ні шоткодів немає, зате там дуже проста MVC модель, його лего допрацьовувати.

а во втором случае нельзя скл вызвать внутри DollarToGRN() ? я вообще предпочитаю сначала данные готовить а потом показывать
$amountInDollars = DollarToGRN(500) ;
echo ’Вартість розробки сайту ’.$amountInDollars.’грн.’
мне получается шорткоды вообще не нужны ?)))

Любе і різне )))

$amountInDollars = $PData->shortCode(’Вартість розробки сайту [:DollarToGRN 500:] грн.’);

Все залежить від ситуації і завдання. Якщо потрібно вивести слайдер у середині поста, то через візуальний редактор вставляти розмітку не дуже добре — шоткод, який вставляє в публікацію розмітку слайдера при генерації сторінки значно краще рішення.

Система шоткодів призначена для полегшення роботи зі строками, які зберігаються в базі.

ты хочешь сказать что шоткод будет включать еще и разметку а не просто строку ? и шо такое слайдер ?

спитай в гугла )

Думаю правильней это называть не шорт код, а фильтр (парсер?) контента.

Хуки не нужны ru.wikipedia.org/...проектирования
Готовое решение подключается в проект командой composer require illuminate/events. Правда для этого у вас проект должен использовать composer

Я думаю, що на рахунок хуків можна довго сперичатись. Потрібні вони чи ні — залежить від завдання і від того, що саме ви пишите.

Наприклад, якщо у вас є модуль чи функція, який ви використовуєте на різних проектах, то вибираючи між зміною коду самого модуля і підключення через хук потрібних функцій, я особисто віддаю перевагу другому, тому що це універсальніше з точки зору уніфікації коду в міжпроектному зрізі.

Якщо ж писати кожен раз все наново під кожен проект, тоді так — можна запросто обійтися без хуків. Та це викликає багато проблем у підтримці проекту — доведеться або преписувати доки, або кожен раз згадувати, як саме було реалізовано алгоритм у даному конкретному випадку — а це час. До того ж, якщо над проектом працює кілька програмістів, то це ще більше часу на розбір коду.

Очевидно вы не ходили по моей ссылке. Шаблон Observer является более оптимальным решением, чем просто хуки. И уже реализован не один раз не одним фреймверком.

Подписаться на комментарии