[PHP] Уродский прототип (и наверно реализация). Как исправить?

ООП тебя спасет, да в пыхе есть ООП, удивлен?

$result = $query_fields->exclude("some","secret","fields")->show($record_id);

в пхп это такие ключевые аргументы для бедных.

по второй функции -- тоже как-то так надо переписать

возможно стоит возвращать нулевой $add_id (если облом)и убрать &$add_ending

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

так что тот вариант должен заканчиваться наверно так:

->get($record_id)->show_with($html_template);

> ООП тебя спасет

судя по всему, ему еще и концепции ORM непомешало бы покурить.

> ->get($record_id)->show_with($html_template);

/me рвет волосы на жопе.

> $result = $query_fields->exclude("some","secret","fields")->show($record_id);

То есть, вы считаете что все указывает на необходимость создания объекта "запрашиватель_полей" (query_fields) ?

Он считает, что секс с PHP это цель а не средство.

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

Ну у меня шаблонов нет в обычном их понимании. У меня есть эээ... «запрос представления данных».

<query name="news">

  <table name="news">

    <field name="head" type="text">
     <querytext val="Текст новости"/>
     <sizeonscreen val="80"/>
     <maxlen val="200"/>
     <empty val="0"/>
     <transform val="notag"/>
    </field>

    <field name="text" type="bbtextarea">
      <querytext val="Текст новости"/>
      <maxlen val="30000"/>
      <empty val="0"/>
      <transgform val="bbtag"/>
    </field>

    <field name="type" type="radio">
      <querytext val="Тип новости"/>
      <radioitem val="Обычная новость"/>
      <radioitem val="Молния"/>
      <radioitem val="Анонс"/>
      <empty val="0"/>
    </field>

    <field name="visible" type="checkbox">
      <querytext val="Новость разрешена к просмотру"/>
      <defaultvalue val="1"/>
      <empty val="0"/>
    </field>

  </table>

</query>

Для их распасивания использую модель. И в программе передаю только имя «запроса» (как говорил выше, в переменной $query_field). По этому имени легко извлекаются любые данные «запроса» с помощью методов модели.

Видимо, этого недостаточно, надо извлеченный запрос представить в виде объекта. Хотя, не понимаю, какой профит будет, если вместо

$field_name=get_field_name_by_num('news',2); // Вернет "type"

буду писать

$current_query=new $query_field('news');
...
$field_name=$current_query->get_field_name_by_num(2);

Вопрос на засыпку: а www.linux.org.ru/group.jsp?group=19109 нафига надо?

> Вопрос на засыпку: а http://www.linux.org.ru/group.jsp?group=19109 нафига надо?

Да я чота забыл, что такой подфорум есть. Я воспринимаю PHP больше как мультиплатформенный язык программирования.

я всего лишь предлагал способ избавиться от кучи неименованных аргументов, порядок которых легко спутать (бывает еще способ f(array('asdf'=>7,'qwer'=>82)), но он хуже)

я не предлагаю все подстичь под объектную гребенку, как в яве,

но простенький ORM -- действительно очень полезен

> $field_name=get_field_name_by_num('news',2);

чуствую, что тебе много что придется переписывать

>> ->get($record_id)->show_with($html_template);

> /me рвет волосы на жопе

не понял юмор.

>бывает еще способ f(array('asdf'=>7,'qwer'=>82)), но он хуже

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

> не понял юмор.

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

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

f(array('asdf'=>7,'qwer'=>82))

$f->asdf(7)->qwer(82)

и где компактность?

кроме того, в моем способе опечатку ловит интерпретатор/компилятор, как мы тут РНР назовем

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

ты так конкретных притензий не предъявил, а мой либастрал еще местами с багами

в общем, перефасовка полученного из БД array-я в объект (которую мой либастрал показывает как имеющую офигенную важность для тебя) имеет смысл в яве (т.к. там есть аннотации на члены и методы), но достаточно сомнительна в РНР, где у всех этих объектов (независимо от класса) методы одни и те же (а что-то нетривиальное проще делать на уровне хранимых процедур скл)

в добавок, шаблонизатором похрен, лежит запись из БД в array-е или объекте -- им нужен набор полей, но никак не методы объекта

>ты так конкретных притензий не предъявил

ну вобщем, дело твое как делать. я просто довольно длительное время занимаюсь сопровождением и разработкой крупного проекта с жестким ООП, и такой код мне как крупным напильником по мозгу...
особенно такая реализация "псевдо-шаблонов".

> перефасовка полученного из БД array-я в объект (которую мой либастрал показывает как имеющую офигенную важность для тебя)

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

> шаблонизатором похрен, лежит запись из БД в array-е или объекте

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

> я просто довольно длительное время занимаюсь сопровождением и разработкой крупного проекта с жестким ООП,

ммм... это на чем же жесткий ООП? не на РНР случаем?

ты не поверишь, но на нем это тоже возможно.