Концептуально, «class» сам по себе образует пространство имен. Для классов есть чудная арифметика, позволяющая эти пространства имен комбинировать — слово extends все знают?… И главное — эти чудеса живут в языке еще со времен PHP4. =)
Т.е. нужно было разрешить расширять класс новыми именами и вкладывать классы друг в друга. Автоматически бы получили всеми любимые mixin'ы, приватные классы и проч. прелести. Все в рамках традиционного ООП. И новый синтаксис тогда был бы не нужен. Но нет — php'шники, ввели новую недо-сущность namespace и новый недо-синтаксис, и докучи чуть не огребли проблемы с парсингом. Где ум, блин?… :)
Для каких целей создавался «Сервис структур Hivext»?
Какую СУБД для хранения данных использует Ваш сервис?
На какие объемы данных рассчитываете и как решаются вопросы масштабирования?
структур позволяет разработчикам создавать свои приложения в стиле ООП, позволяет манипулировать и управлять типами и объектами разрабатываемых приложений
Судя по API, «сервис структур»…, действительно, всего лишь сервис структур. :) Отличительными признаками ООП являются абстракция, наследование, инкапсуляция и полиморфизм. Т.е., если развитие сервиса планируется именно в направлении ООП, то на данный момент, API покрывает лишь малую часть заявленного функционала.
По просьбе обчитавшихся верстальщиков, мы сделали наследование шаблонов в смарти-подобном ШД под php.
Но наследование это весьма специфичная штука. В быту, этим словом может обозначаться куча совершенно разных по смыслу понятий:
* обобщение — все страницы которы должны выглядить однообразно, наследуются от общего для них шаблона some_layout.html;
* композиция — в pager.html реализовать блок постраничной листалки и наследовать от него шаблоны, где нужна листалка,
* делегирование — определить блок в шаблоне и рисовать им, или не определять — тогда пусть рисует блок из родительского шаблона
* и т.д.Н
Неподготовленные люди воспринимают наследование, как универсальный инструмент, типа серебряной пули…, даже не так — типа серебряной термоядерной ракеты. Однако, как только кол-во шаблонов в проекте перерастает учебные объемы, то состояние аффекта у них быстро проходит. А на смену ему приходит ужас, поскольку они осознают, что больше не в состоянии контролировать эффекты, создаваемые «иерархиями» шаблонов в несколько этажей.
В общем, если для формирования «представления» нужна сколь-нибудь продвинутая «логика», то лучше этой «логикой» озадачивать программистов. Ну а у них для этого есть отдельный от ШД-«представления» инструментарий. ㋡
кстати, можно задать еще один вопрос про статью? ;)
в части «Общий контент» Вы предложили формат и набор процедур для сохранения мультиязычных данных в общем поле БД. Почему не используете стандартные serialize()/unserialize()? На первый взгляд это было бы проще.
Вы упорно не приводите примеров и я продолжаю непонимать. ㋡
Возможно вот где проблема. Для выборки мультиязычных данных может применяться еще одно правило: «отдавать контент на языке Ⓐ, а если его нет, — на языке оригинала», где язык оригинала это тот, на котором была изначально написана контентина. Тогда версии на всех остальных языках это переводы. А перевод уже _зависят_ от оригинального текста. Наличие такой зависимости влияет на структуру БД.
Для реализации этой идеи на основе Вашего примера, в таблицу news нужно добавить поле news_orig_lang (язык, на котором была изначально написана новость).
Тогда запрос вида: вытащить «перевод» и оригинал будет выглядить так:
SELECT * news_id N
INNER JOIN news_contents NC ON N.news_id = NC.news_id AND NC.lang = N.news_orig_lang
LEFT JOIN news_contents NCtr ON N.news_id = NCtr.news_id AND NCtr.lang = ?userUILang
т.е. через INNER JOIN цепляется язык оригинала, а через LEFT JOIN — перевод.
А из базы контент выгребается сразу на двух языках: языке юзера и языке по умолчанию? Т.е. так:
SELECT *
FROM news N
INNER JOIN news_contents NC ON N.news_id = NC.news_id
WHERE NC.news_lang IN (?clientUILang, ?defaultLang)
Мне понравилась идея разбивать таблицы, так что одна будет содержать поля, которые не зависят от языка, а другая — текстовые.
> 1 таблица (table1)
> news_id
> news_start
> news_stop
> news_visible
> 2 таблица (table2)
> news_id – уникальный номер новости из первой таблицы
> news_lang – уникальный двухбуквенный идентификатор языковых данных
> news_subject – тема (заголовок) новости
> news_short – короткая новость на языке с кодом из news_lang
> news_full – полная новость на языке с кодом из news_lang
В своей статье ты определил, что текстовый контент новости уникален для каждого языка. Т.е. между языками он не пересекается. Поэтому чутье подсказывает, что нужно создавать table2_ru, table2_en и т.д. — индексы меньше, поиск быстрее. Но ты предлагаешь переводы хранить в одной таблице. Каков в этом практический смысл?
> Я, кстати, писал не про данный конкретный пример, но просто когда я критикую, я стараюсть также перечислять возможные варианты.
ничего не имею против критики «на всякий случай» — пусть не расслабляются. =)
> В «древности» люди были не дураки и не плодили типы и функции просто так. В данном случае нам достаточно ввести 1 Exception, типа APIException и заворачивать в него всю информацию об ошибке, нежели плодить иерархию из типов.
Судя по тяге «достаточности» Вы в реале либо отшельник, либо скупердяй. :) На всякий случай, хочу отметить, что «достаточно» это не всегда «выгодно». В «древности» люди были невежественны, ибо имели очень смутное представление о типизации и инкапсуляции. Но в отличие от первобытных программистов, современные понимают, что типизация и инкапсуляция _выгодны_, поскольку помогают бороться с различными аномалиями кода. Если предполагается, что код не одноразовый, а будет переиспользоваться, то выгоднее каждую исключительную ситуацию описать class'ом, чем заставлять код на высших уровнях городить анализ кодов возврата. Анализ кодов возврата ненадежен и излишне многословен это уже многократно было проверенно в процессе эволюции человечества. :)
> Вы только не учли одну вещь. Статья позиционируется в ООП-парадигме. Об этом нам как бы говорят комменты автора и тэг «ооп».
Основной смысл механизма исключений — поддержка строго-иерархического разделения ответственности за идентификацию исключительной ситуации и принятие решения о дальнейших действиях — на мой взгляд, в примере показан изумительно. Комменты в коде — великолепны. О MVC речи не шло. Тег «ооп» пусть останется на совести автора.
> для передачи мета-информации об ошибке, сделать более общий тип excetpion, но с доп. объектом, в котором будет инкапсулирована эта информация и т.д.
Думаю, не надо так делать. Это антипаттерн для исключений. Наличие мета-информации связанной с ситуацией, ни как не должно влиять на тип exception.
В языках программирования, информация о том, «что есть» данные (isA), выражается при помощи типа. В механизме try-throw-catch, для представления информации об исключительной ситуации, служит объект-исключение. Тип такого объекта должен быть достаточен для идентификации этой ситуации на более высоких уровнях приложения, которые будут перехватывать исключение.
Если тип исключения будет мало информативен («СлучиласьКакаяТоФигня»), то это приведет к усложнению логики перехвата (например, анализу дополнительных данных в объекте). Поскольку решение о бросании исключения принимается в какой-то отдной точке кода, а анализ будет производиться во многих (пример, одна библиотечная функция <-> много приложений, которые ее используют), то малоинформативные исключения вынуждают делать кучу сложной работы.
Поэтому при выборе типа исключения рулит конкретизация, а излишнее обобщение как раз вредно. При необходимости, отношение обобщения между исключениями выражается при помощи наследования (в PHP все исключения это Exception).
> Если вы так делаете редирект, то ваш код крайне запутан, потому что Exception не дает нам знания о том, куда передается управление. Предполагается, что только в обработчик ошибок. Плюс к этому, это нарушение интерсфейса на самом деле. Редирект — это точно такое же View с точки зрения MVC, например
По смыслу, редирект это действие — переход из одного состояния в другое. А действия находятся за рамками структурного паттерна MVC. Для представления действий есть собственные паттерны (например, редирект можно описать как Command). Не понимаю, зачем пытаться все описать лишь тремя словами: M V C — как будто других слов нет (или «можно обойтись» это Ваше кредо?). Впрочем слогласен, что Exception здесь тоже жесть. :)
> Такое использование сильно похоже на процедурный стиль, а там можно обойтись и без Exception.
Не спорю, без исключений можно обойтись. Точно так же в процедурном стиле можно обходиться и без других языковых конструкций: switch, for, foreach, do-while,… — в пределе достаточно использовать if и goto. :) Мне кажется, что утверждение «не нужен, потому что можно обойтись», с практической точки зрения, лишено смысла.
Замечу, что Exceptions в стиле try-throw-catch это чисто процедурный механизм. Просто он получил популярность в ООП-языках, поэтому часто ассоциируется с этим подходом. Но это не так. Как мы видим в примере из статьи, данная конструкция может прекрасно работать безо всякого ООП даже в «лапше».
с опытом это пройдет. =)
Т.е. нужно было разрешить расширять класс новыми именами и вкладывать классы друг в друга. Автоматически бы получили всеми любимые mixin'ы, приватные классы и проч. прелести. Все в рамках традиционного ООП. И новый синтаксис тогда был бы не нужен. Но нет — php'шники, ввели новую недо-сущность namespace и новый недо-синтаксис, и докучи чуть не огребли проблемы с парсингом. Где ум, блин?… :)
Какую СУБД для хранения данных использует Ваш сервис?
На какие объемы данных рассчитываете и как решаются вопросы масштабирования?
Судя по API, «сервис структур»…, действительно, всего лишь сервис структур. :) Отличительными признаками ООП являются абстракция, наследование, инкапсуляция и полиморфизм. Т.е., если развитие сервиса планируется именно в направлении ООП, то на данный момент, API покрывает лишь малую часть заявленного функционала.
Но наследование это весьма специфичная штука. В быту, этим словом может обозначаться куча совершенно разных по смыслу понятий:
* обобщение — все страницы которы должны выглядить однообразно, наследуются от общего для них шаблона some_layout.html;
* композиция — в pager.html реализовать блок постраничной листалки и наследовать от него шаблоны, где нужна листалка,
* делегирование — определить блок в шаблоне и рисовать им, или не определять — тогда пусть рисует блок из родительского шаблона
* и т.д.Н
Неподготовленные люди воспринимают наследование, как универсальный инструмент, типа серебряной пули…, даже не так — типа серебряной термоядерной ракеты. Однако, как только кол-во шаблонов в проекте перерастает учебные объемы, то состояние аффекта у них быстро проходит. А на смену ему приходит ужас, поскольку они осознают, что больше не в состоянии контролировать эффекты, создаваемые «иерархиями» шаблонов в несколько этажей.
В общем, если для формирования «представления» нужна сколь-нибудь продвинутая «логика», то лучше этой «логикой» озадачивать программистов. Ну а у них для этого есть отдельный от ШД-«представления» инструментарий. ㋡
в части «Общий контент» Вы предложили формат и набор процедур для сохранения мультиязычных данных в общем поле БД. Почему не используете стандартные serialize()/unserialize()? На первый взгляд это было бы проще.
Возможно вот где проблема. Для выборки мультиязычных данных может применяться еще одно правило: «отдавать контент на языке Ⓐ, а если его нет, — на языке оригинала», где язык оригинала это тот, на котором была изначально написана контентина. Тогда версии на всех остальных языках это переводы. А перевод уже _зависят_ от оригинального текста. Наличие такой зависимости влияет на структуру БД.
Для реализации этой идеи на основе Вашего примера, в таблицу news нужно добавить поле news_orig_lang (язык, на котором была изначально написана новость).
news:
news_id, news_orig_lang, news_start, …
news_content:
news_id, news_lang, news_subject, …
Тогда запрос вида: вытащить «перевод» и оригинал будет выглядить так:
SELECT * news_id N
INNER JOIN news_contents NC ON N.news_id = NC.news_id AND NC.lang = N.news_orig_lang
LEFT JOIN news_contents NCtr ON N.news_id = NCtr.news_id AND NCtr.lang = ?userUILang
т.е. через INNER JOIN цепляется язык оригинала, а через LEFT JOIN — перевод.
SELECT *
FROM news N
INNER JOIN news_contents NC ON N.news_id = NC.news_id
WHERE NC.news_lang IN (?clientUILang, ?defaultLang)
> 1 таблица (table1)
> news_id
> news_start
> news_stop
> news_visible
> 2 таблица (table2)
> news_id – уникальный номер новости из первой таблицы
> news_lang – уникальный двухбуквенный идентификатор языковых данных
> news_subject – тема (заголовок) новости
> news_short – короткая новость на языке с кодом из news_lang
> news_full – полная новость на языке с кодом из news_lang
В своей статье ты определил, что текстовый контент новости уникален для каждого языка. Т.е. между языками он не пересекается. Поэтому чутье подсказывает, что нужно создавать table2_ru, table2_en и т.д. — индексы меньше, поиск быстрее. Но ты предлагаешь переводы хранить в одной таблице. Каков в этом практический смысл?
ничего не имею против критики «на всякий случай» — пусть не расслабляются. =)
> В «древности» люди были не дураки и не плодили типы и функции просто так. В данном случае нам достаточно ввести 1 Exception, типа APIException и заворачивать в него всю информацию об ошибке, нежели плодить иерархию из типов.
Судя по тяге «достаточности» Вы в реале либо отшельник, либо скупердяй. :) На всякий случай, хочу отметить, что «достаточно» это не всегда «выгодно». В «древности» люди были невежественны, ибо имели очень смутное представление о типизации и инкапсуляции. Но в отличие от первобытных программистов, современные понимают, что типизация и инкапсуляция _выгодны_, поскольку помогают бороться с различными аномалиями кода. Если предполагается, что код не одноразовый, а будет переиспользоваться, то выгоднее каждую исключительную ситуацию описать class'ом, чем заставлять код на высших уровнях городить анализ кодов возврата. Анализ кодов возврата ненадежен и излишне многословен это уже многократно было проверенно в процессе эволюции человечества. :)
Основной смысл механизма исключений — поддержка строго-иерархического разделения ответственности за идентификацию исключительной ситуации и принятие решения о дальнейших действиях — на мой взгляд, в примере показан изумительно. Комменты в коде — великолепны. О MVC речи не шло. Тег «ооп» пусть останется на совести автора.
Думаю, не надо так делать. Это антипаттерн для исключений. Наличие мета-информации связанной с ситуацией, ни как не должно влиять на тип exception.
В языках программирования, информация о том, «что есть» данные (isA), выражается при помощи типа. В механизме try-throw-catch, для представления информации об исключительной ситуации, служит объект-исключение. Тип такого объекта должен быть достаточен для идентификации этой ситуации на более высоких уровнях приложения, которые будут перехватывать исключение.
Если тип исключения будет мало информативен («СлучиласьКакаяТоФигня»), то это приведет к усложнению логики перехвата (например, анализу дополнительных данных в объекте). Поскольку решение о бросании исключения принимается в какой-то отдной точке кода, а анализ будет производиться во многих (пример, одна библиотечная функция <-> много приложений, которые ее используют), то малоинформативные исключения вынуждают делать кучу сложной работы.
Поэтому при выборе типа исключения рулит конкретизация, а излишнее обобщение как раз вредно. При необходимости, отношение обобщения между исключениями выражается при помощи наследования (в PHP все исключения это Exception).
По смыслу, редирект это действие — переход из одного состояния в другое. А действия находятся за рамками структурного паттерна MVC. Для представления действий есть собственные паттерны (например, редирект можно описать как Command). Не понимаю, зачем пытаться все описать лишь тремя словами: M V C — как будто других слов нет (или «можно обойтись» это Ваше кредо?). Впрочем слогласен, что Exception здесь тоже жесть. :)
Не спорю, без исключений можно обойтись. Точно так же в процедурном стиле можно обходиться и без других языковых конструкций: switch, for, foreach, do-while,… — в пределе достаточно использовать if и goto. :) Мне кажется, что утверждение «не нужен, потому что можно обойтись», с практической точки зрения, лишено смысла.
Замечу, что Exceptions в стиле try-throw-catch это чисто процедурный механизм. Просто он получил популярность в ООП-языках, поэтому часто ассоциируется с этим подходом. Но это не так. Как мы видим в примере из статьи, данная конструкция может прекрасно работать безо всякого ООП даже в «лапше».