@qfox в ноде нету асинка как такового. У вас асинхронная только работа с IO, как только в дело вступает JS все превращается в старое доброе однопоточное приложение. Мы можем что-то делать в ноде пока ждем данных. Как только они приходят - все идет согласно event loop.
Что до идущего в лес фреймворка - он то тут причем? вы же не фреймвор редактируете, а решения под него. Это нормальное явление. Суть в том что бы делиться наработками, тогда в будущем кому-то нужно будет меньше допиливать. Вообще забавно, но в СНГ не особо любят контрибьютить.
@Kwisatz нашли опенсурс решение которое подходит или почти подходит? Что-то не нравится? pull-реквест!
Причем тут фреймворки вообще? Берем angular.js, он дает вам власть в виде директив. Ищим директиву под ваши требования: ngTable. Видим что у нас не поддерживается из коробки фиксированный хэдер таблицы - идем в ишусы. Ищем, кто-то уже спрашивал (задача то распространенная) - читаем. Если есть решение - используем. Нету решения, делаем свое. В контексте задачи - это только верстка. В итоге мы тратим минимум времени на реализацию и никаких изменений в саму директиву не вносим. Если у вас есть решение проблемы, делимся им с сообществом хоть в каком виде. Может кто заимплементит нормально уже.
Мне кажется проблема вовсе не во фреймворках/библиотеках/готовых решения, а в том, как с ними работать.
@ilyaplot хотя с шарингом сессия я пожалуй погорячился, если у вас сессия регенерируется периодически. Просто можно две сессии хранить. Или еще чего придумать.
@ilyaplot а что вас смущает? Установите токену время жизни в минуту или меньше.
Суть проблемы в том, что вам как-то надо связать сессии для домена A и B, так как куки для A прочитать с B не выйдет, а без них у вас нету никакой информации, позволяющей понять что текущий пользователь именно тот, кто он есть.
Подход с картинкой позволяет объеденить и даже расшарить одну php-шную сессию на два домена.
@Radiocity на моих проектах верстаю я, так что для меня больше синтаксический сахар без ущерба для производительности и безопасности.
А еще я люблю расширять twig кастомными штуками, правда этим я занимаюсь на домашних проектах-концептах. Наприме в голове сидит назойливая мысль запилить генератор CMS-ок с inline-редактированием (sir-trevor вдохновил и еще пара проектов) из шаблонов на twig. Пока сделал только основу для генерации и маршрутизацию (то есть просто сделал компилятор статических сайтов). До inline-редактирования руки не доходят, ибо подостыл уже и другие дела есть.
@DubecZ MVC это несколько паттернов. Если вы хотите лучше понять что это есть такое, откуда пошло и что дает... да и просто что бы могли потом знакомых и коллег загрузить умными словами, почитайте и послушайте. По ссылке довольно хорошая лекция, можно посмотреть расслабиться, там очень хорошо мужик объясняет что есть паттерны откуда все пошло и рассказывает какие-то основы. Конкретно про GRASP - вот. www.youtube.com/watch?v=UxXsCS6fbJ0
@DubecZ я бы даже это паттерном не называл. Если вам интересно, то вот: https://ru.wikipedia.org/wiki/GRASP - почитайте. Может любопытно будет. Так же поищите в сети видио различные где разжовывают эти принципы на примерах (обычно java но думаю вы поймете и просто со слов). www.youtube.com/watch?v=S-RjiMAxHio
@maxyc_webber в ооп тоже могут быть глобалы - статические классы и сингелтоны с фасадами тому подтверждение.
Можно массу способов придумать как максимально развязать код и не использовать при этом глобальные переменные. Можно сделать функцию-фасад, которая будет предоставлять вам нужные ресурсы. В итоге код у вас будет завязан только на одну эту функцию, а данные останутся в целости и сохранности. не доступные для изменений. Тогда процедурный код не превратится в полное гуано.
@copyloc вы всегда можете посмотреть в дебагере браузера (вкладка ресурсы у хрома) что у нас сейчас записано в куки. И вообще почитайте что из себя куки представляют, так же полезно. Ну и про HTTP за одно. Хотя бы базовые вещи.
@copyloc для начала попробуйте записать чего в сессию/куку, разберитесь с этим. Затем придумайте что хранить в сессии или куке, что бы можно было в коде понять, авторизован чувак или нет. Собственно это все. Обычно все чуть сложнее, но попробуйте хотя бы это. А как будет хоть какой код, хоть сколько нибудь рабочий, тогда уже можно говорить.
@HaJIuBauKa ну ваш комментарий если в суть не вдаваться так же на бред смахивает. "какой MVC вы используете". Звучит как будто бы MVC уже стало синонимом фреймворка (хотя это не так).
@Tantacula нода стабильна, но если у вас мало опыта в разработке под ноду выкатывать что-то на прод будет уже рисковано. Там масса нюансов, которые вам придется самостоятельно ресолвить. Да, за коды появилось много того, что сильно упрощает жизнь. Но имхо, я не вижу вообще никакого смысла писать web-сайты на ноде. Приложения, сервисы, апишки, демоны - да, смысл есть. Есть так же эксперементальные штуки типа meteor.js (для меня они все еще эксперементальные), которые исповедуют философию "один и тот же код на сервере и на клиенте". Но опять же сложные штуки писать будет уже проблемно.
@dmitriylanets да, можно реализовать на composer или частично его использовать. Там есть механизмы контроля версий, проверка обновлений и т.д. Просто это все сделано под cli.
Я лично сделал бы так. Если зависимости мои (модули, плагины и т.д.) и они приватны, можно поднять satis (менеджер репозиториев для composer) на своем сервере, ну или если у вас все на github/packagist, то проблем как бы и не будет. Можно пакеты через composer/installers ставить, словом вариантов масса.
Затем я реализовал бы на основе composer свой инструмент для проверки наличия новых версий (можно спокойно взять из composer.lock текущие версии зависимостей, посмотреть какие версии у нас появились в репозиториях и сформировать список).
Обновление и откат версий чуть сложнее, так как нужно еще думать о секьюрности и все такое, хотя так же вопрос решаемый.
То есть это не так что бы готовое решение, просто можно механизмы контроля версий зависимостей и их скачку реюзать, уже выходит сильно проще.
я думаю что не стоит этого делать и обходиться ужасными конструкциями вида
((item.getFoo() || {}). fooParam || {}).bar