-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
tony2001
TeaM PHPClub
>Минуточку. КТО объединяем массивы?
кодер
верстальщик к этому отношения не имеет.
>Тот, кто кодит логику? А он не ясновидящий,
>чтобы заранее угадать, что дизайнер захочет
>вывести это в одной колонке, а не в двух
>соседних.
ха
вот оно твое "ненужное" общение.
программер должен представлять что будет на сайте и как это будет выглядеть.
ясновидящий ?
вообще это тонкий юмор делать что-то даже не имея об этом представления...
>Там весь HTML в одном файле.
это ХТМЛ с псевдо-кодом (или наоборот)
>Откуда? Из четко расписанного и
>согласованного ТЗ, где учтено все включая
>особенности верстки в HTML?
гм. ИЗ ОБЩЕНИЯ.
они работают командой над проектом, следовательно, им необходимо общаться!
кодер
верстальщик к этому отношения не имеет.
>Тот, кто кодит логику? А он не ясновидящий,
>чтобы заранее угадать, что дизайнер захочет
>вывести это в одной колонке, а не в двух
>соседних.
ха
вот оно твое "ненужное" общение.
программер должен представлять что будет на сайте и как это будет выглядеть.
ясновидящий ?
вообще это тонкий юмор делать что-то даже не имея об этом представления...
>Там весь HTML в одном файле.
это ХТМЛ с псевдо-кодом (или наоборот)
>Откуда? Из четко расписанного и
>согласованного ТЗ, где учтено все включая
>особенности верстки в HTML?
гм. ИЗ ОБЩЕНИЯ.
они работают командой над проектом, следовательно, им необходимо общаться!
Crazy
Developer
Это абсолютно излишне. Он знает, что должен заполнить $data1 и $data2 правильными данными и предоставить доступ к ним верстальщику. Ему должно быть абсолютно безразлично, как именно их отобразят -- это уже компетенция дизайнера и верстальщика.
Без такого разделения вообще вся идея повторного использования компонент идет лесом.
Работник должен знать свой фронт работ. Если человек кодит проводку платежа и при этом заморачивается цветом выводимых сообщений -- его нужно уволить. Пока не принес непоправимого вреда фирме.
Это код на языке шаблонов. Который есть расширение HTML.
Реально только в мелких проектах и просто смертельно для сопровождения.
Crazy
Developer
Нет возможности согласовать термины не цепляясь к словам. В принципе невозможно.
Итак, с PHP мы определились -- там живет код. Теперь перейдем к данным и представлениям.
Данными в данном контексте я называю некоторую информацию, являющуюся результатом выполнения алгоритма.
Представлением -- опять же а данном контексте -- я называю ту внешнюю форму, в которой данные передаются клиенту.
Пример: в результате вычислений мы получили два числа: 100 и 50. Это данные. Мы их отобразили в виде картинки: кружок с красным и зеленым секторами. Это представление.
Согласование терминов -- процесс итеративный. Соответственно, жду возражений и поправок.
tony2001
TeaM PHPClub
>Если человек кодит проводку платежа и при
>этом заморачивается цветом выводимых
>сообщений -- его нужно уволить
уважаемый, мне кажется, что вы начинаете передергивать.
речь не идет о цвете сообщений, речь идет о ДАННЫХ, которые надо забить в проводку и о полях, которые надо заполнить.
мне почему-то кажется, что ЭТИ данные ему надо знать.
>этом заморачивается цветом выводимых
>сообщений -- его нужно уволить
уважаемый, мне кажется, что вы начинаете передергивать.
речь не идет о цвете сообщений, речь идет о ДАННЫХ, которые надо забить в проводку и о полях, которые надо заполнить.
мне почему-то кажется, что ЭТИ данные ему надо знать.
tony2001
TeaM PHPClub
>Пример: в результате вычислений мы
>получили два числа: 100 и 50. Это данные. Мы
>их отобразили в виде картинки: кружок с
>красным и зеленым секторами. Это
>представление.
угу, прнимаю этот пример.
теперь вернемся к нашим баранам - используя Смарти и ПХП внутри ХТМЛ получаем, что:
есть код, который производит данные (100 и 50)
есть КОД, который _управляет_ отображением этих данных (заметьте: не отображает, а _управляет_ отображением).
есть представление, которое собсно и отображает.
да/нет ?
>получили два числа: 100 и 50. Это данные. Мы
>их отобразили в виде картинки: кружок с
>красным и зеленым секторами. Это
>представление.
угу, прнимаю этот пример.
теперь вернемся к нашим баранам - используя Смарти и ПХП внутри ХТМЛ получаем, что:
есть код, который производит данные (100 и 50)
есть КОД, который _управляет_ отображением этих данных (заметьте: не отображает, а _управляет_ отображением).
есть представление, которое собсно и отображает.
да/нет ?
Mammoth
Guest
Очень интересно. Стоило отлучиться на полчаса, а тут уже столько всего написали. Я, к моему сожалению, уже не смогу сегодня пообщаться - в 19 очень важное свидание, но учтите: У МЕНЯ ЕСТЬ ЧТО СКАЗАТЬ!!! До завтра!
tony2001
TeaM PHPClub
>У МЕНЯ ЕСТЬ ЧТО СКАЗАТЬ!!!
это угроза ? =)
господа. я не думаю, что наш спор кому либо интересен, кроме нас троих.
посему предлагаю перейти в почту.
[email protected]
это угроза ? =)
господа. я не думаю, что наш спор кому либо интересен, кроме нас троих.
посему предлагаю перейти в почту.
[email protected]
tony2001
TeaM PHPClub
me>программер должен представлять что будет на сайте и как это
me>будет выглядеть.
you>Это абсолютно излишне.
....
you>ЭТИ знания верстальщик берет в спецификации.
???????????
знания о там ЧТО он выводит на конкретной странице кодеру не нужны ??
то есть он будет тупо выводить два массива раздельно, даже не зная о том, что их можно объединить, т.к. на самом деле это и есть один массив? (сорри, но пример именно такой, из песни слов не выкинешь).
простите, но я вас перестал понимать вообще.
я всегда считал, что от понимания в команде зависит и качество работы тоже.
теперь оказывается, что понимание и общение вообще (!!) - это все лишнее, не нужное.
так ? или я не понял чего-то ?
>Плохо то, что ты соединяешь не те два уровня.
аргументы, плз...
me>будет выглядеть.
you>Это абсолютно излишне.
....
you>ЭТИ знания верстальщик берет в спецификации.
???????????
знания о там ЧТО он выводит на конкретной странице кодеру не нужны ??
то есть он будет тупо выводить два массива раздельно, даже не зная о том, что их можно объединить, т.к. на самом деле это и есть один массив? (сорри, но пример именно такой, из песни слов не выкинешь).
простите, но я вас перестал понимать вообще.
я всегда считал, что от понимания в команде зависит и качество работы тоже.
теперь оказывается, что понимание и общение вообще (!!) - это все лишнее, не нужное.
так ? или я не понял чего-то ?
>Плохо то, что ты соединяешь не те два уровня.
аргументы, плз...
Crazy
Developer
Наоборот. Ему нужны знания о том, ЧТО он выводит. И вредны знания о том, КАК это хочет отрисовать верстальщик.
Он не имеет права ничего выводить. Он имеет право только приготовить данные согласно спецификации и обеспечить доступ к ним (согласно той же спецификации).
Что-то ты странное говоришь. Я уже несколько раз подчеркнул, что это два РАЗНЫХ набора данных. Например -- список сезонных скидок на чайники и список рекомендуемых к приоьретению товаров текущего раздела.
В данном случае верстальщик расположил их в одной таблице. А мог вывести в двух разных. А мог из каждого сделатьл отдельный select. Это -- его право и его обязанность.
Ты путаешь понимание и бессистемное общение. Первое -- нужно. Для этого есть спецификации. Второе -- вредно.
Рассмотрим на том же примере: ты поручил слияние массивов кодеру. Соответственно -- лишил верстальщика возможности самостоятельно вывести их по-отдельности.
Это значит, что мы в лучшем случае получаем 10-15-минутную задержку в работе. В худшем -- теряем несколько дней, пока заболевший кодер не выйдет на работу, чтобы сделать совершенно тривиальную правку.
Если же, как я уже говорил, верстальщик и кодер суть одно лицо, то это слияние правомерно. Но в этом случае и в шаблонах особой нужды нет -- одно баловство.
Crazy
Developer
Я не наблюдаю скрипта с двумя массивами, чтобы это проверить. В приведенном ранее примере массив был один.
Итак, каков будет этот скрипт, если учесть, что верстальщик -- в разных скинах -- может вывести как одним списком, так и по-отдельности?
Каков будет скрипт, если у нас 5 наборов данных и возможны любые комбинации прихотей верстальщика (считаем, что предвилдя уход кодера в отпуск он сразу его попросил все это предусмотреть).
Crazy
Developer
Разумеется спорно. Разные способы организации работы дают итоге разные правила Я расказал о своих. Не виду причин, по которым кто-либо не имел права так организовать работу, что спецификации становятся бесполезны и абсолютно необходимо постоянное живое человеческое общение.
Простейший пример -- наличие в проекте ключевого сотрудника, которые органически не способен ни читать, ни понимать формальные тексты. Такого, который может продуктивно общаться только глядя в глаза и держа в руках бутылочку пива. Бывает. видел. И если такого нельзя уволить -- приходится играть по его правилам.
То же относится и к комбинациям слияний.