@nepster09, ngRepeat это ngRepeat. Типа циклы в шаблонах, с датабиндингом и всеми делами. Потрудитесь хотя бы демки на главной странице офф сайта глянуть...
https://github.com/nishp1/angular-delegate-event - модуль с реализацией обработчиков, как я понимаю как раз на document оно навешивает обработчики. Хотя опять же не рекомендую делать именно так, но самый простой вариант в вашем случае, ибо делает именно то что вы хотите сделать.
+ можно вообще инкапсулировать всю таблицу в какую-то грид-директиву, и там внутри уже навешивать хэндлеры.
@affka, как показывает практика, найти хорошего php-шника или js-ника, который кроме самого языка знает как его правильно использовать, ничуть не проще, чем разработчика на ruby, python... А быть может даже проще, хотя это спорный вопрос.
@affka, причина отказа от портирования Symfony2 на node.js в отсутствии практической пользы и отсутствия интереса у сообщества я думаю. На самом деле я не вижу в этом смысла. Ровно как и писать что-то большое целиком на node.js. Нода хороша для чего-то маленького и быстрого. Скажем мне нравится на нем писать какие-то сервисные демоны по доставке сообщений, так как на нем написать что-то подобное проще чем на php. Так же на нем удобно имплементить restfull сервисы. Ну и штуки типа meteor.js любопытны.
Если же нужно писать что-то больше и чувствительное к производительности, лучше уж взять golang.
@affka, вы видимо и не пытались найти такой фреймворк. Посмотрели бы в сторону CompoundJS, geddy, Locomotive... Хотя как по мне Express.js хватает, и проблем со структурой у него так же нету. В любом случае надеюсь вы не под чистую копируете архитектуру Yii2.
Из забавных - была попытка портировать Symfony на node.js, вместе с dependency injection и т.п.
@DDanya, не только у шаблонизатора Go, много где такие теги используются, собственно именно по этому такие теги использует и AngularJS, ибо это уже своего рода стандартная форма вывода значений переменных.
Другое дело что:
- Обычно шаблонизаторы предоставляют возможность эскейпить часть шаблона, что бы предотвратить такие вот конфликты.
- Шаблонам angularjs не место в шаблонах go. Если у вас приложение на angular.js, то на go вы должны реализовать только rest api. Словом полностью разделить фронт и бэк на два разных проекта. Если же у вас angular.js используется для какой-то части фреймворка - так же можно задуматься зачем это делается.
@alekciy, чуть все же поясню:
я бы делал эту логику как отдельную библиотеку, не зависящую от фреймворка (только от других библиотек). И тогда вопрос "какой фреймворк" уже не стоит, ибо в итоге разницы нету. Просто этот подход проще обустроить с silex-ом. Фронтэнд для подобного сервиса я бы всеравно писал на angular.js, так что от фреймворка мне нужна только гибкость в плане разработки RESTFull сервисов (а это библиотеки JMSSerializer, stackphp и т.д.). Тот же stackphp так легко и просто интегрировать в yii не выйдет, ибо от использования HttpKernel разработчики yii отказались.
@HaruAtari, вы не правы. Zend2 определенно лучше Yii2, другое дело что Yii2 для большинства задач хватает.
Псевдопростота Yii порождает ворох говнокода каждый день, и не дай бог вам на поддержку достанется такое вот наследие. Я не стану писать на Yii что-то сложнее интернет магазина/форума.
@theaidem, гонять хеловорды в бенчмарках дело бесполезное. На худо бедно сложном приложении go за счет параллелизма будет давать нехилый прирост производительности.
