Если вопрос "в принципе", то на других проектах в основном без автосвязывания. Если не считать предоставляемые механизмы сторонних инструментов, а так лично сам не использую в своих реализацих.
В случае фреймворка - тут как раз "подзадача" самому покрутить рефлексию. Набраться с ней опыта и "попримерять" ее на свои задачи :)
Я смотрел (ему ж уж сколько лет то).. Но оговорюсь сразу: для меня сериалы это отдых после рабочего дня, т.е. вот такой формат непринужденный, без чернухи, вполне себе подходит. Можно охарактеризовать: если б можно было бы развидеть, то посмотрел бы с удовольствием вновь. Единственное там в хорошем качестве наверно нет даже. Стало напрягать качество :)
Последнее время все наше кино смотрю, чет ни как зарубежное не заходит.... тут решил дай ка про спорт импортное что то посмотрю - несколько фильмов в обед подряд попробовал в основном тема про единоборства (бокс, бои....)... все как под копирку : в начале главный герой огребает, вылетает из профессии, потом долго мучается, мечтает, ну и в конце фильма бой где он навалял главному злодею.... т.е. фильмы скорее про психологию, а не про спорт где тяжелая работа, пот и кровь приводят к победе...
Это, кстати, я могу аргументировать:
1. Любой человек в любой области накапливает опыт. В этом накопленном опыте ему что то нравится, что то нет и так далее. Переходя к разработке фреймоворков: вполне естественно, что имея за плечами опыт разработки в не учебных/академических проектах накапливаешь опыт: какие решения, идеи хорошие и удобные, какие нет. Соотвтственно и свое решение строишь с учетом опыта. Берешь на вооружение хорошее и удобное (и этом может быть алгоритмы, идеи, интерфейсы взаимодействия, те же стандарты, PSR и прочее и прочее) - делаешь свою реализацию, а что показалось плохим и не удобным переделываешь. Если опыта нет (особенно даже если учебного) - то тут будет все по максимуму свое. Но у меня нет цели делать из принципа "главное, чтоб не было похоже на что то существующее" (считаю такой принцип не разумным). по этому да у меня есть решения которые похожи на типовые.
2. Фреймоворк должен быть привычным. Особенно в той парадигме в которой задумал я: он должен подходить для максимального числа проектов (в т.ч. и для чайников - через создание на его базе конструктора сайтов или MCP сервера, помогающего чайнику объяснить словами свои хотелки ИИ, а тот ему сгенерит). А если расчет и на разработчиков глупо их полностью переучивать. Фреймворк должен помогать выполнять основную задачу, а не загружать мозг дополнительными навыками. При чем если делать исходя "главное чтоб не как у всех" придется и самому полностью переучиваться, а это не имеет смысла в тех моментах которые считаешь правильными.
Вот в этом и вся беда человечества, не умных людей, которые бегут за толпой и не думают своей головой.
ЗЫ. Эксперимент с обезьянками помнишь, я лично его почти всегда в такие моменты вспоминаю.
Да это пока сознательно. Сейчас вынашиваю мысль добавить в фрейморк сервисы для работы файловой системой и убрать это все туда. Но пока не решил когда это делать, если до релиза шаблонизатора не сделаю - то в шаблонизатор пока по сути "костыль" добавлю не дающий выползать ща пределы.
Тоже понимаю. Пока идеология - не брать лишнюю ответственность. Т.е. разработчик должен позаботится о подготовке данных. Тут честно пока для себя не принял решение окончательное.
Пасиб. подумаю.
Тут идея такая то все же localVars это переменные блока. тоже еще у меня нет 100% видения как правильно. Вероятно уже по обкатаю на том же проекте форума - может что пойму для себя. :)
Интересно. подумаю
Тут из собственного опыта. На самом деле надо и так и так. Скорее всего будет добавлена директива типа csrf-input.
Да. TODO там не спроста :) обязательно этот вопрос будет изучаться.
Об этом, если честно, даже не подумал...
А причем тут "люди".? Это все работает под капотом. разработчику (а именно эту роль выполняет человек создающий сайт) не обязательно даже будет знать как это работает. очень условно у него будет метод подключения страницы (читай шаблона страницы). и он даже может не знать, что там вообще есть кеширование. Это, на мой взгляд, правильная работа хорошего инструмента. т.е. как пример псевдокодм
ShowPage('index.xml');
Т.е. пользователь сказал что он хочет видеть страницу. Остальное не его проблемы. Даже могу продемонстрировать на твоем фреймворке. (на той версии что у меня и, оговорюсь, я уже подзабыл его детали реализации, так что только по беглому поиску и взгляду) Правда тут с некоторым допущением у тебя сразу логика запускается некоторая на основе разбора xml. Но ее можно упаковать (в этом случае правда больше подойдет "классический кеш" (наподобии как описан в PSR)
class Manual { final public function Load(string $name){//..некоторый код if(file_exists($way)){ $cache = new FileRelatedCache('/tmp',$way, 86400); if ($cache->exsists()) { // достаем из кеша } else { $xml=simplexml_load_file($way); if($xml){ // обработка $cache->save($data); } } }//..некоторый код }}
Т.е. все происходит внутри твоего метода. Это можно и не показывать пользователю, только дать ему инструмент сброса кеша по требованию
Собственно , там и ни чего сложного. Бывают различия например в принципах инвалидации кеша, бывают дополнительные (и интересные) навороты. У меня пока все достаточно просто вот код (там не большой класс)
по сути просто вычисляется хеш от полного пути файла. срваниваются время файла кеша и файла шаблона, учитывается заданное время жизни. и, собственно, все.. Особо ни каких хитростей.
Ну вот, а ты говоришь "видео". Какой смысл (если принимать во внимание твое пожелание выше) если ты не смотришь, а все, что смог выдать это "Говорить тут не чего, всё банально по методичкам.." - для этого ни видео, даже кода не нужно. Ведь обоснования требуют размышлений... :)
Это самое бесполезное пояснение. Цель данной темы попробовать обсуждать вопросы разработки и ведения проекта. Даже если "по методичке". Что не так? В чем недостаток этих подходов? Для чего делать иначе - какой будет профит? В таком ключе ты можешь вести обсуждение?
