Разноє

 Якщо б в верстальщиків не було так багато креативності, ми зараз мали б набагато семантичніший веб.

— "Це правда! Я маю фреймворк, який може відобразити CRUD за допомогою однієї стрічки коду. Він може рендерити веб-сторінки, використовуючи MVC паттерн з найменшими зусиллями, і немає значення як ви накапарите з HTML в своїх темплатах і з CSS в своїх стилях, з нашою технологією "зроби-красіво" ваш сайт завжди матиме достойний вигляд. По суті фреймворк навіть вибере лей-аут сторінки, який буде найкраще підходити для відвідувача, при тому ще й з самими оптимальними показниками виконання, з якими вам коли-небудь приходилось стикатись".

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

Фреймворк, який би допомагав вирішити будь-яку проблему, яку ви можете уявити просто не існує і не може бути створений з декількох причинам.

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

По-друге, фреймворк повинен бути великим і малим одночасно. Якщо ви побудуєте фреймворк, який буде робити масу речей, він у вас получиться великим. Якщо вам потрібно буде застосувати тільки один аспект, то у вас можуть виникнути накладки з цим. Користі від здорового фреймворка не буде, якого для того щоб розвернути, потрібно інсталювати і настроїти, якщо все, що ви хотіли зробити, — це маленький скрипт на 5 стрічок, який запускається по crontab. Звісно фреймворк може бути більш захищеним в цьому випадку, але подумайте про кількість include-ів і перевірок, які повинен виконати фреймворк перед тим, як добереться до виконання власне вашого коду! В конкретному випадку краще буде використати компонентний фреймворк, або частину великого фреймворка.

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

Один з аргументів в користь використання єдиного інструмента є можливість спеціалізації розробників на виконанні одного (одноманітного) завдання. Використання правильного інструменту зробить розробника набагато ефективнішим загалом. Розділити кусок дерева молотком буде важко, і результат, що ми отримаємо, не буде одним з кращих, не залежно від того яким б "майстром молотка" ви не були. Набагато корисніше знати, що є такий пристрій як пила і яке його застосування. Якщо ви не знаєте яким боком пила повинна бути повернена вверх, — не хвилюйтесь, — це можна дізнатись із документації до пили або запитати в людей, які користувались пилою раніше, на форумах підтримки.

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

Оригінальна стаття.

Доброго вечора,

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

Не так давно, а рівно тиждень назад, до мене прийшло трошки вільного часу на роботі, який я вирішив використати розробляючи якісь інструменти для покращення і пришвидшення побудови сайтів. В силу того, що я не ЦМСочнік, тобто ніколи не страждав написанням якихось CMS по три-чотири версії як інші це робили, але старався розробляти більш цікаві і не рутинні речі. Побавившись з джанго я зрозумів, що дуже багато вирішує для фреймворка його вигляд в робочому стані. Я говорю наразі про адмін частину, яка в джанго вже побудована і моделюється на основі ORM і бази даних.

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

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

До того я довго працював з Magento, особливо мені сподобалось як обробляються форми на адмін частині, багато перечитав коду як це все робити за допомогою Prototype. Також дуже цікаво розібратись в Varien бібліотеках, які постачаються разом з Magento і використовують Prototype як нижчий рівень, але про це варто писати окрему статтю.

Я пішов по шляху меншого супротиву, я розумію як працює Prototype, познайомився з його API, але не провів жодного вечора на сайті з документацією, тому вирішив взяти собі на озброєння jQuery-UI, яке мені здалось і красивішим і не менш функціональним.

З технічної точки зору в мене получився абстрактний котроллер, в якому зібрана загальна логіка CRUD інтерфейсу для будь-якої сутності і який в бекенді має ORM модель для роботи з базою даних (власне це теж варто б винести в інтерфейс, який може замість бази використовувати якийсь xml або ще інший ресурс даних) і декількох виглядів, які власне відповідають за виведення списку елементів, створення, редагування і видалення. Кошерно, по MVC паттерну.

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

Як тільки виправлю всі баги і витестую — викладу прототип подивиитсь. Далі — напевне будемо прикручувати до блога.

P.S.: в вордпресса дуже гарно перероблена адмін частина в версії 2.7. Один з факторів, який надихнув на таке.

P.P.S.: луччє б ото комєнти прикрутив сюди, замість того шоб всяку непонятну ахінєю нести.

"Во время боя с имперской армадой наши повстанцы захватили чертежи нового ужастного оружия империи"

Власне схема.

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

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

Директорія system дублює структуру application, плюс додана директорія core всередині system. Для рядового розробника це не має значення, в core знаходяться ядро фреймворка (як говорять framework glue), що забезпечує зв'язну і послідовну роботу. 

Каскадна файлова система забезпечується автопідключенням Kohana. Можна виділити три рівні системи:

• application: при підключенні файла Kohana дивиться сюди в першу чергу. Якщо файл знайдено, то його загружають і далі пошук файла припиняється.
• modules: якщо файл не був знайдений на рівні application, то проводиться пошук файла в підключених модулях.
• system: якщо до того файл не був знайдений, то Kohana пробує знайти файл в системній директорії.

Дана структура файлів забезпечує легке перевизначення та розширення конкретних класів згідно потреб конкретної аплікації. Єдиним, що слід зауважити: файл config.php повинен знаходитись на рівні application. Всі інші Контролери, Моделі, Вигляди, Конфігураційні файли, Хелпери і Бібліотеки розміщені за бажанням розробника. Малюнок наглядно ілюструє роботу каскадної файлової системи. Клікабельний.