mosquito 0 Опубликовано 11 июня, 2009 Жалоба Share Опубликовано 11 июня, 2009 заметил еще некоторые ну не очень ошыбки =) но все же: 1. при поиске в админке к примеру из категории сейфы ищем по слову "сейф" и снова находим нашу категорию "Сейфы" из за такой рекурсии потерялось 5 мин времени думая что гдето баг в коде =) 2. как то не оч смотрится в апи двига vam_draw_form как начало формы и простое '</form>' как окончание ) оч понравилась реализация роботы с формами в друпале тут тож можно чтото подобное прикрутить) Ссылка на сообщение Поделиться на другие сайты
support 447 Опубликовано 12 июня, 2009 Жалоба Share Опубликовано 12 июня, 2009 2. Ну а как, если форма открыта, её нужно же закрывать. Ссылка на сообщение Поделиться на другие сайты
mosquito 0 Опубликовано 12 июня, 2009 Автор Жалоба Share Опубликовано 12 июня, 2009 ну это понятно) я о том что если мы начинаем форму вызовом апи то и заканчиватся она должна им.... типа сделать одну ф-ю: vam_draw_form(name, params, ....){ $form = "<form name=$name ... >"; foreach ($params as $param) $form .= $param; $form .= "</form>"; return или print $form; } к примеру Ссылка на сообщение Поделиться на другие сайты
support 447 Опубликовано 12 июня, 2009 Жалоба Share Опубликовано 12 июня, 2009 Так работать не будет. У тебя ж метка /form выведется сразу после form тэга. Есть же ещё функции для полей формы: vam_draw_* Ссылка на сообщение Поделиться на другие сайты
mosquito 0 Опубликовано 12 июня, 2009 Автор Жалоба Share Опубликовано 12 июня, 2009 Так работать не будет.У тебя ж метка /form выведется сразу после form тэга. будет. мы у параметры передаем всю внутренность формы типа так: vam_draw_form('form 1', array( vam_draw_...(), vam_draw_...(), vam_draw_...(), ), ... ){} где vam_draw_...() наши елементы Ссылка на сообщение Поделиться на другие сайты
support 447 Опубликовано 12 июня, 2009 Жалоба Share Опубликовано 12 июня, 2009 vam_draw_form и vam_draw функции в разных же файлах находятся, в не вложены друг в друга. Если б все функции для форм были в одном файле, такой бы вариант работал. Ссылка на сообщение Поделиться на другие сайты
mosquito 0 Опубликовано 12 июня, 2009 Автор Жалоба Share Опубликовано 12 июня, 2009 бля... это будет в шаблоне использовано (последний пример) это вызов ф-и... у нас все файлы включены в аппликейшн_топ.пхп тоесть простото что мы делам echo vam_draw... мы будем передавать в draw_form как параметры и уже выводить echo vam_draw_form.... ну это так для розмышлений в коде много чего нужно(можно) менять... он мне не лч енравится как програмисту хоть и не про) понимаю что ты сейчас этим врятли будеш заниматься... но если вамшоп 2.0 делать то лутче б код был полностью пересмотрен) а так это будет почти тоже что джумла 1 и джумла 1.5 -) Ссылка на сообщение Поделиться на другие сайты
support 447 Опубликовано 12 июня, 2009 Жалоба Share Опубликовано 12 июня, 2009 В том коде, что есть сейчас, лучше вставлять /form в шаблон. Ссылка на сообщение Поделиться на другие сайты
ABerezin 0 Опубликовано 12 июня, 2009 Жалоба Share Опубликовано 12 июня, 2009 Тем более что форма может большой и содержать в себе массу вложенных html-элементов (таблицы, дивы, картинки и т.д.). Ссылка на сообщение Поделиться на другие сайты
mosquito 0 Опубликовано 12 июня, 2009 Автор Жалоба Share Опубликовано 12 июня, 2009 а в чем разница в таком коде: echo vam_draw_form();echo "<div>dsdjlfsd</div>";echo " sdfjlsdf ". vam_draw_input_field();echo " sdfjlsdf ". vam_draw_input_field();echo " sdfjlsdf ". vam_draw_input_field();echo "label dsdf";echo "</form>";[/code] и: [code]echo vam_draw_form("form name",array("<div>dsdjlfsd</div>",echo " sdfjlsdf ". vam_draw_input_field(),echo " sdfjlsdf ". vam_draw_input_field(),echo " sdfjlsdf ". vam_draw_input_field(), "label dsdf",// ewe parametru)); обьем кода не намного поменялся... + второй пример гарантирует закрытие формы... пс вас 2 я один( нечесно =) жаль что тут на форуме мало с кем можно чтото пообсуждать( Ссылка на сообщение Поделиться на другие сайты
support 447 Опубликовано 12 июня, 2009 Жалоба Share Опубликовано 12 июня, 2009 Ты предлагаешь вот такой код в шаблон вставлять?! Сейчас же в коде определяются метки с данными, в шаблон вставляются только метки. Зачем усложнять шаблоны подобным кодом?! Ссылка на сообщение Поделиться на другие сайты
mosquito 0 Опубликовано 12 июня, 2009 Автор Жалоба Share Опубликовано 12 июня, 2009 ну впринцыпе в пхп файл, хотя тут с шаблоном формы надо будет чтот придумать я просто прив как пример с друпала там не сматрти поэтому такой проблемы нету а вообще тут много можно спорить токо некому( но мне от смарти польза только во встроенном кэшырованиии так как я еще не оч разобрался как самому чтото в кэш загнать) а так простого PHPTemplate достаточно было б Ссылка на сообщение Поделиться на другие сайты
support 447 Опубликовано 12 июня, 2009 Жалоба Share Опубликовано 12 июня, 2009 Если не нагружать шаблоны php кодом и выносить весь код в отдельные html-файлы, то в принципе тоже самое и получается, что со смарти. В тех же osc3 и zen-cart смарти не используется, но, в принципе, довольно неплохо сделано, в смысле не сильно усложняют шаблоны php кодом. Это ж не суть важно, какой движок шаблонный, либо вообще обычный php аккуратное написанный и разложенный по полочкам. Ссылка на сообщение Поделиться на другие сайты
mosquito 0 Опубликовано 12 июня, 2009 Автор Жалоба Share Опубликовано 12 июня, 2009 не суть важно но все же если берем смарти то там метки метки ... и при встрече такого куска кода (то что выше писал) вставить в смарти то это уже будет как "нагрузка" а если использовать шаблонную систему типа друпаловской там мы можем определить форму вторым методом (форма с внутреностью как параметры =) ) где будет и пхп и хтмл код вперемешку и это не будет считатся как плохой код жудательно отделять пхп и хтмл, для чего типа используется смарти, хотя я б не сказал что все так уж отделено без этого неполучается( тут можно много говорить) надо будет когдато сесть посмотреть что из этого получится -) Ссылка на сообщение Поделиться на другие сайты
support 447 Опубликовано 12 июня, 2009 Жалоба Share Опубликовано 12 июня, 2009 Да ничего не получится, у всех вкусы разные, это ж не имеет какого-то решающего значения. Но мне лично кажется, что всё равно нужно идти по пути упрощения кода, а не постоянно что-то наворачивать, навешивать и усложнять. Чем проще, тем лучше. Тем легче разобраться, тем легче найти ошибку. Ссылка на сообщение Поделиться на другие сайты
Midas 0 Опубликовано 12 июня, 2009 Жалоба Share Опубликовано 12 июня, 2009 Да ничего не получится, у всех вкусы разные, это ж не имеет какого-то решающего значения. Но мне лично кажется, что всё равно нужно идти по пути упрощения кода, а не постоянно что-то наворачивать, навешивать и усложнять. Чем проще, тем лучше. Тем легче разобраться, тем легче найти ошибку. Полностью согласен. Ссылка на сообщение Поделиться на другие сайты
mosquito 0 Опубликовано 12 июня, 2009 Автор Жалоба Share Опубликовано 12 июня, 2009 я тож согласен иначе чтото б уже написал =) но все же кто знает что тот вариант намного сложнее его еще никто не делал ) чтото тут уже менять понятно сложнее реализовать чем продолжатьь дальше уже существующий апи и т.д. пс можно закрывать тему один против троих =) Ссылка на сообщение Поделиться на другие сайты
ABerezin 0 Опубликовано 13 июня, 2009 Жалоба Share Опубликовано 13 июня, 2009 Проблем с реализацией нет. А вот с использованием проблем будет куча. Ссылка на сообщение Поделиться на другие сайты
Рекомендуемые сообщения