по крайней мере слово смещение прозвучало

Lamp/lemp я могу настроить без проблем. Смещение и длина чтобы знать откуда читать из хранилища. Клиенту отдавать пофайлово.

пофайлово - то есть, резать на сервере?

Да

ну это же тяжело)

для сервера

разве что вы их по 5-10 штук в одно будете склеивать, не больше иначе - упрётесь в ограничение время работы процессора также (я пропустил?) вы не сказали будут-ли изображения одинакового размера (хотя-бы по одной стороне), ибо это ооочень будет влиять на конечный результат по времени разве что, как решение, сделать cloudflare как кэширующий cdn, и кэшировать все изображения, чтобы ваш сервер не так нагружался (но по первым порам CPU будет 100%, или даже 150%)

в общем я этот фарс не продолжаю, но пользуясь случаем, советую всем юзать вот такую штуку - https://www.minio.io/ классно абстрагирует приложение от хранилища, имеет s3-совместимый апи и клиенты под все языки и платформы.

Не... не спрайты, он хочет с файлом работать напрямую. Читать побайтово со смещением. И все соотвествия смещения хранить в бд, или еще где. Это надо суметь вообще такое придумать. )) Для сервера это не очень напряжно, но цель не оправдывает средства. Бред.

в общем я этот фарс не продолжаю, но пользуясь случаем, советую всем юзать вот такую штуку - https://www.minio.io/ классно абстрагирует приложение от хранилища, имеет s3-совместимый апи и клиенты под все языки и платформы.

А можно в нём хранить отрендеренные тайлы mapnik'a ?

А можно в нём хранить отрендеренные тайлы mapnik'a ?

вы заливаете туда файл, у вас есть урл по которому этот файл доступен. можно?

вы заливаете туда файл, у вас есть урл по которому этот файл доступен. можно?

да. Отлично. Спасибо за сервис.

поддерживает бакеты, публичные ссылки, приватные ссылки на заданное время, временные урлы для заливки с клиента, заливку файлов програмно через апи

поддерживает бакеты, публичные ссылки, приватные ссылки на заданное время, временные урлы для заливки с клиента, заливку файлов програмно через апи

что такое бакет?

ведро в переводе). ну категория файлов. то есть не все в одно место складываается, а можно разделять.

в общем я этот фарс не продолжаю, но пользуясь случаем, советую всем юзать вот такую штуку - https://www.minio.io/ классно абстрагирует приложение от хранилища, имеет s3-совместимый апи и клиенты под все языки и платформы.

+1 Но вот проблему с ограничением на количество inodes это не решит. Зато даст очевидное приемущество в виде простой последующей миграции на другое S3 совместимое хранилище

+1 Но вот проблему с ограничением на количество inodes это не решит. Зато даст очевидное приемущество в виде простой последующей миграции на другое S3 совместимое хранилище

не решит. ее не надо решать. ни таким образом ни вообще.

Я с этим согласен, разъяснил для ТС

Кто нибудь реализовывал такое приложение, как ТС из этого топика http://www.yiiframework.ru/forum/viewtopic.php?f=19&t=22322 ?

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

я точно не скажу, но мне кажется, что так сейчас работают все популярные js framework'и

берут json данные с сервера, и на клиенте строят виды

делаешь апи, делаешь js-клиент. подойди с любой стороны)

можешь взять готовенький rest от yii, там уже 90% backend'а сделано за тебя

Проблема не в том чтобы на сервере отдавать. Проблема сделать front на современном js-фреймворке ) Технологий много. А на сервере, хоть json, хоть полноценный REST, хоть graphql

но судя по вопросу, с js-фреймворками ты совершенно не знаком. Удачного секса )

но судя по вопросу, с js-фреймворками ты совершенно не знаком. Удачного секса )

:D

Artur, бери Angular2, по нему много в интернете гайдов и доков. Если руки прямые, то никаких проблем с освоением не должно быть

заодно ts подучишь)

это понял, хочу сделать максимально расширяемый продукт. сейчас проект работает на yii2 basic. Проект, 1ый год, переходил из рук в руки. Вся логика в моделях, что не хорошо. и сейчас с этим много проблем. как и куда можно вынести логику именно в backend приложении? Те же связи, транзакции?

я ебусь только с бэкендом )

с js ебется другой )

так что тогда из той темы заинтересовало?

На клиенте все как было так и будет. Только данные отдаются не в готовом html, а в виде json данных. А на клиенте по этим данным рисуется весь html

так что тогда из той темы заинтересовало?

описание )

не, давай конкретнее

что хочешь?

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

На клиенте все как было так и будет. Только данные отдаются не в готовом html, а в виде json данных. А на клиенте по этим данным рисуется весь html

* блин на сервере как было...

как было мне не надо ) слишком толстые модели

почитай про graphql

да не надо ему вообще это.

а что надо не понятно

(

На клиенте все как было так и будет. Только данные отдаются не в готовом html, а в виде json данных. А на клиенте по этим данным рисуется весь html

Это зовётся SPA. Мы в компании перешли на этот подход. Очень удобно делить деятельность frontend и backend разработчиков. Yii рендеринг используем только в админке, а директорию frontend в advanced template переименовали в rest, там чисто REST интерфейсы

короче, надо сделать сервак чисто для АПИ. будут модели для таблиц из базы, будут active контроллеры (рест апи). куда и как можно вынести бизнес логику приложения?

короче, надо сделать сервак чисто для АПИ. будут модели для таблиц из базы, будут active контроллеры (рест апи). куда и как можно вынести бизнес логику приложения?

для апи или не апи - разницы нет. только вьюшки исчезают.

где хранить бизнес логику? в сервисах

что в обычном приложении, что в рест

Как организовать эти сервисы? просто класс, в которых находится вся логика? или что? может есть примеры реализаций сервисов?

условно говоря да. бизнес логику, которая завязана на состоянии одной модели, оставляем в модели (типа changeStatus, addOrderItem). Бизнес-логику касающуюся нескольких моделей и инфраструктурных вещей (типа отправить письма, уведомления, итд) - в сервисы

мы храним так же в моделях, просто на одну сущность, например пользователь, у нас несколько моделей

одна модель отвечает за работу с БД, другая за изменения аватара, принимает на вход модель для работы с бд и объект для работы с хранилищем

модель должна хранить свое состояние и иметь возможность изменять себя. вся остальная бизнес-логика - в сервисы

Это из симфони пришло) Ну тут игра терминами идет

Я наверно то же самое имею ввиду

в симфони тоже такого нет. есть модели, есть сервисы

хм, могу ошибаться, но похожие слова я слышал от гуру(вроде как) в симфони)

похожие - какие?

в симфони вообще модели нет

модель должна хранить свое состояние и иметь возможность изменять себя. вся остальная бизнес-логика - в сервисы

модель должна хранить свое состояние и иметь возможность изменять себя. вся остальная бизнес-логика - в сервисы

а, ну это стандартная практика программирования

в книжках пишут

Просто в классы запихать тоже не айс получается. Нужны еще как минимум command bus и еще какое-нибудь подобие service layer из слоистой архитектуры.

Просто в классы запихать тоже не айс получается. Нужны еще как минимум command bus и еще какое-нибудь подобие service layer из слоистой архитектуры.

просто классы и будут service layer

service layer - это не слоистая архитектура. просто слой любой хорошей архитектуры

слоистая - это более широкая парадигма

но в целом да, типа того

service layer - это не слоистая архитектура. просто слой любой хорошей архитектуры

Ну так слой же.))

ну так даже в обычной yii-лапше есть слои - контроллер, вьюшки, моделе-сервисо-хелперы, они же бд-адаптеры

ну так даже в обычной yii-лапше есть слои - контроллер, вьюшки, моделе-сервисо-хелперы, они же бд-адаптеры

Ну да. вообще-то. Я имел ввиду, что все-таки Service layer по хорошему нужно строить. Это ведь не просто будет набор классов, у них должен быть интерфейс определящий взаимодействие. А это уже нужно думать.

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

здраствуйте

Ну да. вообще-то. Я имел ввиду, что все-таки Service layer по хорошему нужно строить. Это ведь не просто будет набор классов, у них должен быть интерфейс определящий взаимодействие. А это уже нужно думать.

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

а есть у когото опыт разработки личного кабинета ?

а есть у когото опыт разработки личного кабинета ?

вряд ли. слишком редкая задача

http://web.archive.org/web/20081007231834/http://www.yiiframework.com/

Ого

Скоро 10 лет будет

ага