Команда разработчиков

Ну, ОК. Доводы по существу тебя не убеждают (или ты их попросту не понимаешь). Колкости тоже не заставляют задуматься. Потом не говори, что тебя не предупреждали.

Совместимость часто экономически оправдана. И не кати бочку на олдскульных проггеров. Многим нынешним до них еще расти и расти и никогда не дорасти.

И не оплевывай то, в чем нифига не разбираешься. На картинке показано всего лишь то, что у ОС есть системное пространство и прикладное. В современных монолитных ОС тоже есть kernel space и user space. Некоторые участки – это вообще не ОЗУ, а отображаемые в физ. адресное пространство ПЗУ и видеопамять (отличная архитектурная идея). А последние два участка связаны с ограничениями древних процессоров на размер адресуемого пространства памяти и соотв. ограничениями тогдашних ОС. В современных ОС их не различают. А «дыры» могут быть не только в первом меге, но и под др. «верхними границами». Также физ. адресное пространство делят на участки еще и потому, что с памятью может работать не только проц, но и др. устройства, у которых могут быть свои ограничения на размер адресуемого пространства памяти.

---------- Добавлено 14.03.2020 в 12:46 ----------

Кстати, современные компы имеют спец. режим загрузки, скрывающий все древнее наследие от ОС, т.е. при его использовании ОС стартует не в реальном режиме проца.

Вот это счас здесь писать - примерно тот же эффект как проститутке с 5-ю классами образования лекцию по матанализу и статистике читать! Чел нахватался верхов и корчит из-себя умного

---------- Добавлено 14.03.2020 в 12:19 ----------

Я против - пускай отвлекается - веселее, иначе что - про плагины вордпресса читать?

А тут человек лбом ломится, пытаясь реализовать то что давно есть, вместо того чтоб изучить и улучшить - интересно же) 🍿

Sly32, а больше здесь уже нечего писать ;)

---------- Добавлено 14.03.2020 в 13:25 ----------

Поддерживаю разговор, чтобы не совсем гнобить ТСа. А психиатора ему пусть другие приглашают, например родственники :)

miketomlin, вот вы знаете строение компьтера, неужели не было мыслей как можно его улучшить, более организовано всё сделать?

Есть люди которые не думают, а просто делают как другие и таких ~90%, мало кто меняет этот мир, в основном гадят на ближнего как вы сейчас на меня.

Что там изучать в вордпресе-то :) посмотрел и всё понятно, смысл говно улучшать, проще свой инструмент с ноля сделать чем это(WP) править...

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

А при чем тут вордпресс? я им с 2017 не занимаюсь, к примеру.

Есть отличный Симфони если брать пхп, например. С кучей готовых штук

Вы просто все что-то пытаетесь улучшить, даже не вникая в то как это работает и как удобнее. Сама идея парсить ХМЛ вместо шаблонизатора давно устарела, но вы все за нее цепляетесь. По итогу - трудно читаемый код, неудобство использования. А та же jinja2 - понятна, удобна, расширяема

Вы вот все пишете что перепишете лучше, но вот я еще не увидел ни одного примера улучшения.

Отстаньте от него, он пока улучшает CMS, скоро поймет что его фреймворк не такой быстрый из за строения современных процессоров, пойдет делать свой проц на новой, никому до сели невиданной архитектуре... ну точнее будет писать об этом на форуме, делать то конечно ничего не будет. ТС у нас теоретик, он может только думать и рассуждать о высоком, а выполнять рутинную работу это не про него, именно для неё и нужна команда =)) он будет философствовать а остальные трудиться

Я не парсю xml, парсить значить брать из чего-то и вставлять в другое, я использую его как язык разметки, то есть обрабатываю команды прописанные в нём, это может быть вставка каркаса страницы, блоков, слайдеров, чего угодно, а в структуре просто указание что надо. xml интуитивно понятен похож на HTML к которому мы привыкли, к тому же его обработка ведётся не надстройкой, а встроенной библиотекой в php

<title>{% block title %}{% endblock %}</title>
<ul>
{% for user in users %}
  <li><a href="{{ user.url }}">{{ user.username }}</a></li>
{% endfor %}
</ul>

это для питона и это банальный шаблонизатор, а у меня по сути обработчик команд

у меня это может выглядеть так

<rec node.="component">
  <title>Заголовок</title>
  <users node.users="parametr"/>
</rec>

То есть подключается макет разметки component из узла node

Вставляется заголовок в метку.

Выполняется метод users узла node заполняя список пользователей

Всё разложено по полочкам, компонент, стили для него, методы обработки.

У вас же и учусь. Вы ничего другого не понимаете.

Мдяяя... Вы вообще откуда в нашу сферу попали? С полей, завода?

Это не обязательно для питона. Это для шаблонизатора.

ArbNet, зачем ты это городишь. Если хочешь связать все в кучу для дегрейда, то хоть V используй например Vue и форматтер какой-то на PHP. А то дальше форм это не пойдет.

Ладно хрен с ним с вызовом, пусть будет, не так уж это и плохо, хоть и не читаемо.

ВОпрос:

Как будет выглядеть реализация users? Как отфильтровать parametr по какому либо из полей? Как передать сколько юзеров я зочу вывести и как построить по всему этому пагинацию?

Вы привели слишком простой пример, прям очень простой, хотелось бы более жизненный. Есть массив товаров, на страницы 3 ноды (слайдера), в первый надо вывести товары с флагом sale, во втором c флагом popular и в третьем которые юзер ранее смотрел/покупал, по факту это нода должна быть списком каталога. Как описать эту банальную простейшую задачу на вашем супер мега умном и в то же время простом шаблонизаторе? Про пагинацию тоже можете добавить пару слов. Потому что есть 4 нода такая же, только она выводит на страницы список товаров раздела текущего с пагинацией.

И еще хотелось бы весь layout увидеть целиком, а не просто вызов абстрактный в вакуме.