Всё же немножко стрёмно с сохранением введённых данных…
Если логика такова, что всё что невидимо — является ненужным, то посылать серверу ещё кучу «ненужных данных», чтобы сервер их сортировал, убирал мусор и понимал что и как сохранять то:
1) Расходы траффика больше
2) Становится запутанной серверная часть, чего вроде бы пытались избежать
3) Белиберда в данных.
Например фирма регистрируется на сайте. Человек вначале затупил ввёл свой домашний адрес, потом вспомнил что он представитель конторы, выбрал в дропдауне Office вместо Home, ввёл адрес офиса и засабмитил, а сервер видит что поле с домашним адресом тоже не пустое и сохраняет и его, в результате офис имеет непонятно какой адрес. Не сильно кошерно как по мне.
Может всё же чистить данные?
А если вопрос в юзабилити, то тогда просто моно введённые данные хранить, а у инпутов просто убивать аттрибут name и тогда в сабмит они не попадут, и северер перегружать какой то заумной логикой не понадобится.
Всё же немножко стрёмно с сохранением введённых данных…
Если логика такова, что всё что невидимо — является ненужным, то посылать серверу ещё кучу «ненужных данных», чтобы сервер их сортировал, убирал мусор и понимал что и как сохранять то:
1) Расходы траффика больше
2) Становится запутанной серверная часть, чего вроде бы пытались избежать
3) Белиберда в данных.
Например фирма регистрируется на сайте. Человек вначале затупил ввёл свой домашний адрес, потом вспомнил что он представитель конторы, выбрал в дропдауне Office вместо Home, ввёл адрес офиса и засабмитил, а сервер видит что поле с домашним адресом тоже не пустое и сохраняет и его, в результате офис имеет непонятно какой адрес. Не сильно кошерно как по мне.
Может всё же чистить данные?
А если вопрос в юзабилити, то тогда просто моно введённые данные хранить, а у инпутов просто убивать аттрибут name и тогда в сабмит они не попадут, и северер перегружать какой то заумной логикой не понадобится.
А мне почему то кажется, что паника на пустом месте.
Когда е-книги только стали появляться разве не таже самая песня была с форматами и всем таким прочим?
Я бы сказал что топик больше о том «е-книги, чего хотелось бы, и что имеем.. .»
>>Данные генерируются скриптом. Поэтому получаем всего одну строчку в исходниках.
Ну здрасьте приехали. Тут играем, тут не играем, а тут рыбу заворачиваем. Если генерим скриптом, что что сложно сделать усилие и повесить ещё и бинды? или просто нравится ощущение от надписи при наведении на ссылку javascript:doSomeReallyBigShit()??
>>Таблица из 50 элементов, по 5 управляющих кнопок в каждой строке. Предлагаете по идентификатору к каждому элементу обращаться?
И так что мы имеем? 50 строчек копипаста вида
<a onclick='u touch my talala'>TOUCH NOW!</a>
каждой по 5 раз.
Или строку вида
$('table > tr ').each(function(){})
и 5 строк селекторов с
bind('click', callback)
для управляющих элементов.
>>Пример можно? Возможно мы про разные вещи говорим.
Да пожалуйста, я только за. Было у нас короче всё тоже самое
$('table > tr ').each(function(){})
Мы когда то js'ом выбирали 1ю таблицу из документа при условии что её родитель не был DIV с ID=TABLE и убивали в ней все ссылки. Таблица в диве раньше была первой, но из-за дива, мы выбирали 2ю, потому что её родитель боди к примеру.
Спустя некоторое время мы убрали у первой таблицы DIV скрипт не поменяли, и что вышло.
Теперь мы убиваем ссылки в нашей первой таблице, хотя надо во второй. А в первой у нас была наша ЛОГИКА без которой мы теперь в просаке. Надо менять скрипты.
А если бы мы селекторами аккуратно сами всё выбирали и вешали эвенты то такой бы беды и не всплыло.
По поводу JS в шаблоне. Как в таком случае следует расматривать такую, довольно таки удачную фичу, как _.template в underscore.js? С одной стороны конечно с ним очень частые проблемы, но зато крайне удобно.
>Чтобы скрипт снова начал работать, ему нужно или рассказывать постоянно про структуру, что откуда и >по какому принципу брать, или же
Эмм, даже в простейшем варианте без любых фреймворков и библиотек, разве document.getElement[s]By… не для этого то и создан был?
>Представление лучше знает, как оно устроено, и нужно всего лишь научить его попутно выполнять >действия.
Наглая ложь. Статическая часть представления после отрисовки тихо висит и молится, пока из-за пользовательский действий не наступит её удаление. А если в том представлении было что то на манер Lamo Code, то логика, которая якобы отлично смотрелась там, тупо исчезает, и в результате можно часами курить свой собственный код.
Вобщем я подведу итог моего мнения.
Я не считаю идею ни плохой ни хорошей. Она интересна но не более. Возможно она бы лучше смотрелась с другой бд, но никак не мускулом. One good reason, где начинаются хранимки, там кончается зона влияния mysql IMO.
В оправдание скажу ещё такую вещь. Вот я никогда не понимал почему все стремятся «запхнуть» много вещей в одну. Вот современный телефон с камерой мрз плеером и функцией позвонить допустим. Вроде бы 3 в 1м, но и камера УГ и плеер УГ да и телефон в помещении тоже хреново ловит. Физику и закон сохраниения энергии никто не отменял, и обойти не может.
Да и вы не поверите, человек это такое существо неуправляемое и всюду лезущее=)
Но вопрос в том что в js изначально и смысл другой владывали, по мимо слаботипизированного ооп и фукнционального <здесь ваш текст> языка. Так что теперь в поле ваш текст добавить " прикручиваемого везде, где только можно, ведь на нём так прияно писать"?
По поводу темы
> MySQL нет никаких встроенных функций и процедур и перед разработчиками стоит вопрос, какой язык выбрать
Тут уже полёт фантазии. В конретном контексте выбор будет в пользу языка, на котором программист пишет в данный период своей жизни/язык для которого будет намного проще это реализовать =) Так что тут уже как говорится, «как хочу». Но есть ещё и «как правильно».
Каждый думает в меру своей распущенности =)
Я вот с первого взгляда подумал, что это дело будет как то прикручиваться к сайту, на клиентской стороне, какая то, к примеру, поисковая форма с данными при помощи функции кормится мускулу, он её экзекутит и мы видим какой то результат.
А о чём вы?
Мне раньше часто говорили: «работает, не трогай!». Но как всегда я никого не слушал. (дурацкое любопытство и мечты об идеале ). Я не спорю. Да возможно у фичи будут свои поклонники. Но в чём профит? Что это кардинально поменяет в работе с данными? Или же это JFF? Т.к. если да, то «судья, я снимаю свои обвинения».
PL/SQL я не удивляюсь по довольно таки понятной причине. Просто не думаю что MySQL'y надо ещё третью ногу прикручивать. Со своими основными целями он слава богу справляется, а требовать от него чего то более тяжкого ( как я уже из опыта заметил :D ) просто ненадо. 70% ПС которые по разным причинам используют мускул, не пользуются даже половиной доступного функционала. Всё статично, Select'но-Update'но-Delete'но и иногда даже Left join'ово, и на этом всё.
Поэтому использование js как «альтернативного источника» хранимок, мне не совсем понятно. Не берусь утверждать, но возможно было бы интересней тогда написать простой компилятор JS -> PL и кормить его мускулу. Как бы и вам приятно, пишете на js, и мускул не мутирует в «неведому зверушку».
Зачем языку запросов ещё и скриптовый? о_О
О какой тогда защите данных можно говорить? А если генерить готовый sql запрос на клиентской стороне, а потом передавать в мускул, что же это тогда будет? Конечный запрос у клиента поменяли на запрос «уничтожь всех и вся» и админам есть чем заняться, так получается?
Не знаю. Сижу на арче с установленными 3ми гномами. Как сразу поставил, был приятно удивлён. До этого пару раз пытался перекашлять новую убунту с Юнити, но не смог, сильно лагало и тормозило на моём, сравнительно не слабом железе. А от третьих гномов получил море удовольствия. Всего то немножко докрутил напильником ( сделал тайтлбар помельче, и настроил hotkeys на сворачивание окна. Ну опционально можно и кнопки то вернуть). В совокупности с gnome-do с темой docky получил почти то же юнити, только вменяемо работающее и ничем не уступающее. и выглядит свежо.
Понравилось замечание автора про «кнопки под пальцы, интерфейс под планшет», но спешу поспорить на этот счёт. Непомню где, но я открыл окошко about и не нашёл там кнопки Х чтобы закрыть. В итоге закрыл нажатием Esc, что для планшета было бы крайне не удобно :)
Если логика такова, что всё что невидимо — является ненужным, то посылать серверу ещё кучу «ненужных данных», чтобы сервер их сортировал, убирал мусор и понимал что и как сохранять то:
1) Расходы траффика больше
2) Становится запутанной серверная часть, чего вроде бы пытались избежать
3) Белиберда в данных.
Например фирма регистрируется на сайте. Человек вначале затупил ввёл свой домашний адрес, потом вспомнил что он представитель конторы, выбрал в дропдауне Office вместо Home, ввёл адрес офиса и засабмитил, а сервер видит что поле с домашним адресом тоже не пустое и сохраняет и его, в результате офис имеет непонятно какой адрес. Не сильно кошерно как по мне.
Может всё же чистить данные?
А если вопрос в юзабилити, то тогда просто моно введённые данные хранить, а у инпутов просто убивать аттрибут name и тогда в сабмит они не попадут, и северер перегружать какой то заумной логикой не понадобится.
Если логика такова, что всё что невидимо — является ненужным, то посылать серверу ещё кучу «ненужных данных», чтобы сервер их сортировал, убирал мусор и понимал что и как сохранять то:
1) Расходы траффика больше
2) Становится запутанной серверная часть, чего вроде бы пытались избежать
3) Белиберда в данных.
Например фирма регистрируется на сайте. Человек вначале затупил ввёл свой домашний адрес, потом вспомнил что он представитель конторы, выбрал в дропдауне Office вместо Home, ввёл адрес офиса и засабмитил, а сервер видит что поле с домашним адресом тоже не пустое и сохраняет и его, в результате офис имеет непонятно какой адрес. Не сильно кошерно как по мне.
Может всё же чистить данные?
А если вопрос в юзабилити, то тогда просто моно введённые данные хранить, а у инпутов просто убивать аттрибут name и тогда в сабмит они не попадут, и северер перегружать какой то заумной логикой не понадобится.
Когда е-книги только стали появляться разве не таже самая песня была с форматами и всем таким прочим?
Я бы сказал что топик больше о том «е-книги, чего хотелось бы, и что имеем.. .»
Надеюсь это шутка. Когда в IE что то последний раз было нормально?
Ну здрасьте приехали. Тут играем, тут не играем, а тут рыбу заворачиваем. Если генерим скриптом, что что сложно сделать усилие и повесить ещё и бинды? или просто нравится ощущение от надписи при наведении на ссылку javascript:doSomeReallyBigShit()??
И так что мы имеем? 50 строчек копипаста вида
каждой по 5 раз.
Или строку вида
и 5 строк селекторов с
для управляющих элементов.
>>Пример можно? Возможно мы про разные вещи говорим.
Да пожалуйста, я только за. Было у нас короче всё тоже самое
Мы когда то js'ом выбирали 1ю таблицу из документа при условии что её родитель не был DIV с ID=TABLE и убивали в ней все ссылки. Таблица в диве раньше была первой, но из-за дива, мы выбирали 2ю, потому что её родитель боди к примеру.
Спустя некоторое время мы убрали у первой таблицы DIV скрипт не поменяли, и что вышло.
Теперь мы убиваем ссылки в нашей первой таблице, хотя надо во второй. А в первой у нас была наша ЛОГИКА без которой мы теперь в просаке. Надо менять скрипты.
А если бы мы селекторами аккуратно сами всё выбирали и вешали эвенты то такой бы беды и не всплыло.
Эмм, даже в простейшем варианте без любых фреймворков и библиотек, разве document.getElement[s]By… не для этого то и создан был?
>Представление лучше знает, как оно устроено, и нужно всего лишь научить его попутно выполнять >действия.
Наглая ложь. Статическая часть представления после отрисовки тихо висит и молится, пока из-за пользовательский действий не наступит её удаление. А если в том представлении было что то на манер Lamo Code, то логика, которая якобы отлично смотрелась там, тупо исчезает, и в результате можно часами курить свой собственный код.
Я не считаю идею ни плохой ни хорошей. Она интересна но не более. Возможно она бы лучше смотрелась с другой бд, но никак не мускулом. One good reason, где начинаются хранимки, там кончается зона влияния mysql IMO.
В оправдание скажу ещё такую вещь. Вот я никогда не понимал почему все стремятся «запхнуть» много вещей в одну. Вот современный телефон с камерой мрз плеером и функцией позвонить допустим. Вроде бы 3 в 1м, но и камера УГ и плеер УГ да и телефон в помещении тоже хреново ловит. Физику и закон сохраниения энергии никто не отменял, и обойти не может.
Но вопрос в том что в js изначально и смысл другой владывали, по мимо слаботипизированного ооп и фукнционального <здесь ваш текст> языка. Так что теперь в поле ваш текст добавить " прикручиваемого везде, где только можно, ведь на нём так прияно писать"?
> MySQL нет никаких встроенных функций и процедур и перед разработчиками стоит вопрос, какой язык выбрать
Тут уже полёт фантазии. В конретном контексте выбор будет в пользу языка, на котором программист пишет в данный период своей жизни/язык для которого будет намного проще это реализовать =) Так что тут уже как говорится, «как хочу». Но есть ещё и «как правильно».
Я вот с первого взгляда подумал, что это дело будет как то прикручиваться к сайту, на клиентской стороне, какая то, к примеру, поисковая форма с данными при помощи функции кормится мускулу, он её экзекутит и мы видим какой то результат.
А о чём вы?
Поэтому использование js как «альтернативного источника» хранимок, мне не совсем понятно. Не берусь утверждать, но возможно было бы интересней тогда написать простой компилятор JS -> PL и кормить его мускулу. Как бы и вам приятно, пишете на js, и мускул не мутирует в «неведому зверушку».
О какой тогда защите данных можно говорить? А если генерить готовый sql запрос на клиентской стороне, а потом передавать в мускул, что же это тогда будет? Конечный запрос у клиента поменяли на запрос «уничтожь всех и вся» и админам есть чем заняться, так получается?
Понравилось замечание автора про «кнопки под пальцы, интерфейс под планшет», но спешу поспорить на этот счёт. Непомню где, но я открыл окошко about и не нашёл там кнопки Х чтобы закрыть. В итоге закрыл нажатием Esc, что для планшета было бы крайне не удобно :)