Перейти к содержанию
Официальный форум поддержки Simpla

Почему симпла не подходит для крупных проектов


Рекомендуемые сообщения

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

 

- нужно получить с блога ответ json с соответствующим заголовком
- ответ должен быть записан в логе - код ответа, время выполнения 
- логируем два метода - BlogView->fetch_post() и BlogView->fetch_blog
- если метод BlogView->fetch_post() ответил с кодом 404 отправляем администратору уведомление
- с любых контроллеров нужно иметь возможность переадресовать клиента на указанный адрес но логер должен записать результат запроса
- очень важно - в классах View ничего менять нельзя (ну за исключением тех не сложных правок для кода и типа ответа о которых говорил Корс но никто их не видел)

 

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

 

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

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

И вообще, я бы эту задачу разбил на две отдельные подзадачи, поскольку они почти не связаны - 1) запись в логи, 2) работа с ответами в разных форматах.

Ссылка на сообщение
Поделиться на другие сайты
  • Ответов 80
  • Дата создания
  • Последний ответ

Лучшие авторы в теме

Лучшие авторы в теме

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

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

И вообще, я бы эту задачу разбил на две отдельные подзадачи, поскольку они почти не связаны - 1) запись в логи, 2) работа с ответами в разных форматах.

 

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

 

Задачи очень связаны. логер тут в качестве примера, если на данный момент не совсем понятна суть задачи, в дальнейшем все встанет на свои места. Задача стоит в том что бы запрос прошел определенный маршрут и вернулся нужный результат, без прерывания работы приложение где либо. А основная цель это - вынести логику которая декорирует или дополняете контроллеры в отдельные "функции", объекты, файлы, без разницы... Так что бы она не нагромождалась там где ее быть не должно

Изменено пользователем DaVinci
Ссылка на сообщение
Поделиться на другие сайты

На данный момент мы не можем манипулировать маршрутом запроса, не можем остановить его по определенному условию не оборвав работу приложения ниже. Мы не можем модифицировать ни запрос ни ответ...

Ссылка на сообщение
Поделиться на другие сайты

если косноязычно могу пояснить кодом

 

Поясняйте можно любым способом, который Вам нравится, лишь бы было понятно.

Например, с самого начала сказано

1. нужно получить с блога ответ json с соответствующим заголовком

 

Как минимум два вопроса возникают:

1.1 "с блога" - что имеется в виду? С какого-то URL? То ли имеется в виду общая страница блога, то ли отдельный пост, то ли и то и другое... 

1.2 Всегда хотите "с блога ответ JSON", или в одних случаях HTML, в других JSON, в третьих еще что? Если несколько случаев, то надо бы описать хоть два из них и придумать приметы, как их распознавать...

Ссылка на сообщение
Поделиться на другие сайты

Поясняйте можно любым способом, который Вам нравится, лишь бы было понятно.

Например, с самого начала сказано

1. нужно получить с блога ответ json с соответствующим заголовком

 

Как минимум два вопроса возникают:

1.1 "с блога" - что имеется в виду? С какого-то URL? То ли имеется в виду общая страница блога, то ли отдельный пост, то ли и то и другое...

1.2 Всегда хотите "с блога ответ JSON", или в одних случаях HTML, в других JSON, в третьих еще что? Если несколько случаев, то надо бы описать хоть два из них и придумать приметы, как их распознавать...

вот мой вопрос

 

Подскажите как мне с любого контроллера (view), к примеру BlogView метода fetch_blog вернуть результат в виде JSON?

 

Нужно уточнить что вернуть посты или отрендереный tpl? Если в этом недопонимание - вернуть клиенту массив $posts в виде json. Вы ведь в своём ответе использовали вовсе не существующую в данном методе переменную. Хотя вариантов было как минимум два - массив $posts либо отрендеренный tpl.

Изменено пользователем DaVinci
Ссылка на сообщение
Поделиться на другие сайты

Так как это понимать - ваша невнимательность?

 

По поводу заголовков даже и представить не мог что вам об этом надо напоминать или уточнять.

Ссылка на сообщение
Поделиться на другие сайты

Да и черт с ними с этими заголовками, все чего не хватает попутно набросаем. Хотелось бы предметно погворить. есть у вас пример кода который относительно не сложно решает поставленную задачу?

Ссылка на сообщение
Поделиться на другие сайты

задача все та же. очень много букв но ни одного примера решения.

 

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

 

- нужно получить с блога ответ json с соответствующим заголовком
- ответ должен быть записан в логе - код ответа, время выполнения 
- логируем два метода - BlogView->fetch_post() и BlogView->fetch_blog
- если метод BlogView->fetch_post() ответил с кодом 404 отправляем администратору уведомление
- с любых контроллеров нужно иметь возможность переадресовать клиента на указанный адрес но логер должен записать результат запроса
- очень важно - в классах View ничего менять нельзя (ну за исключением тех не сложных правок для кода и типа ответа о которых говорил Корс но никто их не видел)

 

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

 

могу предположить что под "Эту задачу можно решить относительно не сложно и при этом что бы симпла осталась такой как есть." кроется подтверждение моих слов о неизбежном нагромождении логики либо в точке входа либо в контроллере. но есть вполне небеспочвенные основания полагать что от Корса мы ничего так и не увидим

Изменено пользователем DaVinci
Ссылка на сообщение
Поделиться на другие сайты

вот мой вопрос

 

Подскажите как мне с любого контроллера (view), к примеру BlogView метода fetch_blog вернуть результат в виде JSON?

 

Нужно уточнить что вернуть посты или отрендереный tpl? Если в этом недопонимание - вернуть клиенту массив $posts в виде json. Вы ведь в своём ответе использовали вовсе не существующую в данном методе переменную. Хотя вариантов было как минимум два - массив $posts либо отрендеренный tpl.

 

Если надо вернуть из fetch_blog результат в виде JSON какой-нибудь, то ответ был уже дан в #17, повторю:

$some_var=array(8,5);

return json_encode($some_var);

 

Если надо вернуть из функции fetch_blog массив $posts в виде json, то так:

return json_encode($posts);

 

Вставлять в конце fetch_blog вместо текущего

return $body;

 

Вроде бы проще некуда...

Ссылка на сообщение
Поделиться на другие сайты

Вроде бы проще некуда...

 

Но тогда в IndexView ваш ответ обернется корневым шаблоном index.tpl

Если добавите die; то не будет подсчет времени и логер не будет работать (если захотите навесить)

Еще нужно заголовки сервера добавить

Изменено пользователем Maksclub
Ссылка на сообщение
Поделиться на другие сайты

Но тогда в IndexView ваш ответ обернется корневым шаблоном index.tpl

Если добавите die; то не будет подсчет времени и логер не будет работать (если захотите навесить)

Еще нужно заголовки сервера добавить

 

Вы совершенно правы.

 

Но это все НЕ относится к поставленной задаче. Задача была в том, чтобы "вернуть из функции fetch_blog массив $posts в виде json", а это предлагаемый способ полностью выполняет.

 

Если требуется что-то добавочно, то и задачу надо ставить полностью и осмысленно. Насколько можно понять Ваши желания, задача решается совсем не сложно стандартными средствами Simpla.

Ссылка на сообщение
Поделиться на другие сайты

Макс, как тебе ответ?)))))

 

Нужно просто как то вот это - «совсем не сложно стандартными средствами Simpla.» скомпилировать и все. А я то думал...

Изменено пользователем DaVinci
Ссылка на сообщение
Поделиться на другие сайты

Но это все НЕ относится к поставленной задаче. Задача была в том, чтобы "вернуть из функции fetch_blog массив $posts в виде json", а это предлагаемый способ полностью выполняет.

 

Друг, ну вы лукавите. Вы как юрист зацепились за слова.

Но вам же понятно было, на каком уровне абстракции обозначается задача и что от вас хотят. Так как есть контекст обсуждения проблемы, не нужно отрывать его в угоду спора, когда вы хотите.

 

Понятное дело нужно универсальное решение, которое бы:

- отдавало с любого метода контроллера JSON/XML/HTML (на выходе в браузере, консоле), а если более полно -- с ендпоинта (роута) отдавало бы в нужном формате данные

- отдавало любые нужные заголовки сервера

- логировалось это добро

- и прочая постобработка некого (в нашем случае очень) абстрактного response

 

...

 

Отдельно хочу отметить, что тут многие понимают проблему Симплы и от вас не ждут магии и понимают проблему, тк Request/Response фреймворки и на основе их идей микрофреймворки сравнительно недавно стали популярны... Как и популяризация посредников и пайплайнов. 

И все понмиают,  что Симпла точно делалась без учета этого добра, и справедливости ради автор даже начал пилить REST, понимая зачем и куда это нужно...

Так что ваши трюки с подлавливанием неточных и абстрактных формулировок (в нашем то абстрактном хрупком мире людей) точно ни к чему, тк все всё понимают тут.

Изменено пользователем Maksclub
Ссылка на сообщение
Поделиться на другие сайты

Но это все НЕ относится к поставленной задаче. Задача была в том, чтобы "вернуть из функции fetch_blog массив $posts в виде json", а это предлагаемый способ полностью выполняет.

 

Не дай бох... то есть вы работаете ИСКЛЮЧИТЕЛЬНО под задачу? Задача пришла -- вы накостыляли?

Ссылка на сообщение
Поделиться на другие сайты

Ой-йо! Макс стой, куда ты!!! ))))) Надеюсь ты понимаешь что разговариваешь с процедурщиком, там ведь логика такая же как код - куча мысли, мало что по делу, ничего не понять  :D Тут ведь постановка задачи должна являться решением самой задачи, ты не понимаешь всю глубину)) Ты думаешь он шутит, я уверен что он полностью серьезен.

Изменено пользователем DaVinci
Ссылка на сообщение
Поделиться на другие сайты

Да, собственно хотелось посмотреть как мыслит "процедурный программист" и во что превращаются приложения после их деятельности, но этому не бывать, они скромные очень. Хотя нет, увидели, 4 страницы трепа и все ни о чем, все ему чего то не понятно и нужны уточнения, все у него просто решается и ни строчки полезного кода... Это показательно.

Изменено пользователем DaVinci
Ссылка на сообщение
Поделиться на другие сайты

Я утверждаю, и это именно так, что при любом масштабировании логика в симпле появляется либо в контроллере (к нему можно отнести все классы View в том числе админку) либо в точке входа. подойдем к обсуждению с более доступного примера

 

<?php

function design($val): string {
    return (string) $val;
}

function blogView() {
    return 'content';
}

function indexView() {
    if( $content = design(blogView()) ) {
       return $content;
    }
    return false;
}

// ------ index ------

$time_start = microtime(true);

session_start();

$result = indexView();

header("Content-type: text/html; charset=UTF-8");    
print $result;

print microtime(true) - $time_start;

// ------ end index ------

 

что можно сказать? что точка входа всегда ждем два типа данных false и string, при этом результат отправляется клиенту с типом html.

 

развернем маршрут нашего запроса и ответа в виде массива

 

$stages = [];

$stages[] = 'start';
$stages[] = 'time_start';
$stages[] = 'session_start';
$stages[] = 'run indexView';
$stages[] = 'run blogView';
$stages[] = 'return indexView';
$stages[] = 'return index';
$stages[] = 'print result';
$stages[] = 'print time';
$stages[] = 'end';

print_r($stages);

 

вот так примерно выглядит симпла и для того что навесить дополнительную логику нам ничего не остается как просто натыкать в этот массив дополнительные stage через которые обязательно должен пройти запрос. это произойдет либо до run indexView либо после, в run blogView или после return index. Эта пачка будет расти с каждым последующим обвесом, и "простыми правками" тут дело не исправить. Если вы убежденны в обратном значит, на данный момент, просто не понимаете сути проблемы.

 

Конечно же если для вас по 3000 строк в документе с огромным количеством условий это не проблема, продолжайте в том же духе, ваше дело. решение могут быть разными, но "простые правки" ничто не изменят. Нужно менять подход в целом

Изменено пользователем DaVinci
Ссылка на сообщение
Поделиться на другие сайты

Количество логики в масштабных проектах растет с каждым последующим обвесом. Задача платформы быть гибкой к изменениям и тут без разницы большое ли приложение или маленькое.

 

Вот пример - возможно вам приходилось делать на базе сиплы простой сайт, просто информационные страницы. и тут приходилось вырезать все лишнее. Рассмотрим к примеру безобидное условие которые вшито в View.php

 

if($currency_id = $this->request->get('currency_id', 'integer')) {
    $_SESSION['currency_id'] = $currency_id;
    header("Location: ".$this->request->url(array('currency_id'=>null)));
} 

что может быть проще - нам надо взять гет параметр и записать его в сессию. Но что ему делать в нашем приложении которое в нем не нуждается. Просто удалим его. А почему бы вот такие условия которые нужны нам только в определенной конфигурации подставлять в цепочку обработки только когда в этом есть потребность.

 

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

Изменено пользователем DaVinci
Ссылка на сообщение
Поделиться на другие сайты

Прийдя к мысли о том что платформа должна быть конфигурируемый вносим новое понятие как компонент. но где его поселить в симпле, вспоминаем что в ней нет банальной автоподгрузки классов. Есть в симпле список каких то апи которые нам надо объявлять для того что бы воспользоваться классом. Странно... Но нет, есть выход - один товарищ посоветовал пользоваться require http://forum.simplacms.ru/topic/13643-simpla-namespace/page-2?do=findComment&comment=106907, как это у него выглядит даже не знаю но его совету я не последую и вам не советую.

 

Ладно, написали автозагрузку классов, или воспользовались Composer что крайне логично в современном мире разработки.

 

Теперь пойдем конфигурировать наше приложение. Набросаем stage и поместим друг за другом

 

<?php

$setCurrency = function($result) {
    return array_merge($result, ['setCurrency']);
};

$design = function($result) {
    return array_merge($result, ['design']);
};

$indexView = function($result) {
    return array_merge($result, ['indexView']);
};

$blogView = function($result) {
    return array_merge($result, ['content']);
};

$result = [];
$result =  $setCurrency( $indexView( $design( $blogView($result) ) ) );

print_r($result); 

 

Здорово! В любой момент можно просто убрать $setCurrency(). Машинально можно сложить последовательность именно так, но нет, результат надо развернуть 

 

$result =  $blogView( $design( $indexView( $setCurrency($result) ) ) );

Работать не совсем удобно, приходиться вкладывать stage и соблюдать последовательность на каком то этапе станет проблематично

Изменено пользователем DaVinci
Ссылка на сообщение
Поделиться на другие сайты

Исправим это неудобство и создадим некую последовательность которая будет восприниматься проще

 

<?php

$setCurrency = function($result) {
    return array_merge($result, ['setCurrency']);
};

$design = function($result) {
    return array_merge($result, ['design']);
};

$indexView = function($result) {
    return array_merge($result, ['indexView']);
};

$blogView = function($result) {
    return array_merge($result, ['content']);
};

$stages = [
    $setCurrency,
    $design,
    $indexView,
    $blogView
];

$result = [];
foreach($stages as $stage) {
    $result =  $stage($result);
}

print_r($result);

 

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

Изменено пользователем DaVinci
Ссылка на сообщение
Поделиться на другие сайты

Что же не так с нашим приложением? Ах да, мы хотел добавить логер для того что бы записывать результат. Что может быть проще добавляем его в цепочку

 

<?php

$setCurrency = function($result) {
    return array_merge($result, ['setCurrency']);
};

$design = function($result) {
    return array_merge($result, ['design']);
};

$indexView = function($result) {
    return array_merge($result, ['indexView']);
};

$blogView = function($result) {
    return array_merge($result, ['content']);
};

$logger = function($result) {
    return array_merge($result, ['logger']);
};

$result = [];

$stages = [
    $setCurrency,
    $design,
    $indexView,
    $logger,
    $blogView
];

foreach($stages as $stage) {
    $result =  $stage($result);
}

print_r($result); 

но нет, результат не тот. Логер стартовал но ему надо как то узнать результат $blogView. Теперь понятно что наша пачка осталась все такой же процедурной (линейной). Что то с этим надо сделать ...)))

Ссылка на сообщение
Поделиться на другие сайты

Понятное дело нужно универсальное решение, которое бы:

- отдавало с любого метода контроллера JSON/XML/HTML (на выходе в браузере, консоле), а если более полно -- с ендпоинта (роута) отдавало бы в нужном формате данные

- отдавало любые нужные заголовки сервера

- логировалось это добро

- и прочая постобработка некого (в нашем случае очень) абстрактного response

 

Могу предположить, что Вы имеете в виду следующее:

1. По адресу site.ru/blog результат должен быть такой же как сейчас.

2. По адресу site.ru/json/blog возвращается JSON (массив $posts) с правильным заголовком.

3. В лог записываются сведения о всех подобных вызовах с подсчетом времени выполнения запроса сервером.

И аналогично по прочим стандартным для Simpla адресам (catalog, product, user) - всем или части.

 

Если требуется так, то все делается легко стандартными методами Simpla.

Изменено пользователем phukortsin
Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

Вы можете написать сейчас и зарегистрироваться позже. Если у вас есть аккаунт, авторизуйтесь, чтобы опубликовать от имени своего аккаунта.

Гость
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

Загрузка...
×
×
  • Создать...