HTML+CSS+JavaScript

Как в js проверить, есть ли уже элемент в массиве?

Это вы "реализуете поиск"? Если да, то каким образом у вас могут быть одинаковые элементы? И зачем вообще массив в этом случае?
Если нет, то перебором и сравнением в цикле. А можно join и поиск в строке.

Да - это поиск. Вот идея поиска. По клику на ссылки формировать массив.
Допустим, у меня набор ссылок типа авто c такими id:
id[1] id[2] id[3]
И ссылки с маркой авто: marka[90] marka[67] marka[3]
По клику на ссылку я беру ID каждой и помещаю значение ID в массив и получаю что-то вроде этого:

array (id[1] ,id[2] ,id[3],marka[90],marka[67],marka[3])

Пользователь можешь кликнуть по ссылке несколько раз, тогда в массив занесется столько же раз значение ID. В лучшем варианте, было бы неплохо массив сформировать в виде:

array(marka=>array(90,67,3), id=>array(1,2,3)) или же array(marka => '90,67,3', id='1,2,3')

Затем это все красиво преобразовать в строку и добавить в value input hidden. Возможно, слишком замудрил
Что скажете?

1) Именно элемент А как ссылка ради того чтобы ее щелкнуть, это плохо.
2) Кто вам не разрешает игнорировать вторичные щелчки по элементам.
3) В JS нет ассоциативных массивов, но есть объекты.

По первому пункту можете предложить альтернативу и чем плохо?

2) пришла лишь мысль сделать счетчик кликов и если >1 то не обрабатывать..

А установка/сброс и проверка атрибута элемента?

Или еще можно создавать input hidden с value ="marka[90]" и тд. И потом применить serialize();

Ужас.

Речь не об альтернативе, а о том, что щелкнуть можно по любому элементу на странице. А href="#" return еще как false, ну это... Ссылка, это ссылка для перехода по указанному адресу, и лучше когда она используется по назначению.

А теперь о вашем наборе. Форма чья, ваша? Элементы ее кто определяет, вы? На выданной пользователю странице можно ввести произвольные id или только те, что вы определили?
Разве нельзя щелчок по элементу связать с выбором скрытого чекбокса, и иметь таких чекбоксов в форме столько, сколько id для выбора вы определяете? А имена чекбоксов как ключ массива разве нельзя указать?

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

1) Форма моя. Для каждой категории name формы отличается.
2) Элементы определяю я, каждый элемент со своим ID
3) На выбранной странице можно ввести лишь те, которые определены.
4) Про чекбоксы ничего не понял. Допустим произошел клику по ссылке, получили id это ссылки (id="id[89]") при этом активируется скрытый чекбокс.
Как мне определить, какой чекбокс активировать? Какой смысл в нем я не уловил, разве что, из будет столько же, сколько количество доступных элементов.

Для каждой категории name формы отличается. - и что из этого следует? У вас что на одной странице куча форм?

Я вам написал о чекбоксах в надежде на то, что вы додумаете, не получилось, жаль. Что же, вернемся к массивам.

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

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

Думайте...

Кажется понял преимущество вашего способа.Как сделаю - отпишу

Маленькое уточнение. Достаточно ли одного select для этого? Если да, то я правильно понял Вас

array(marka=>array(90,67,3), id=>array(1,2,3)) или же array(marka => '90,67,3', id='1,2,3')

Это то, что вы хотите получать на сервере, то есть параметры, по которым будет происходить выборка. Вопрос - достаточно ли одного списка для этого?

Сейчас я решил формировать один select с value равными
mark[819]
mark[820]
mark[821]
mark[822]
mark[825]
mark[826]
mark[833]
id[3]
id[6]
id[9]
И уже на стороне сервера это обрабатывать. Либо можно сделать несколько select для ID и для Mark

Если вы решили сделать один список, значит вы не поняли о чем я говорил.

Если у вас есть два набора элементов, например span, щелчком по которым вы будете указывать выбор пользователя, то ответьте себе на вопросы:

1) как вы сможете одновременно выбрать несколько опций в списке ( а вам как минимум две выбрать возможно придется), если список не с множественным выбором? А если с множественным, то легко ли будет управлять такой "кухней"?
2) как вы планируете связать выбор элемента span с опцией списка?
3) стоит ли усложнять все как на клиенте, так и на сервере?

В общем где-то близко летаю..
Мои мысли такие:

Допустим, есть 3 вида ссылок с такими ID

- mark[56] - id[45] - type[45]

По клику в js получаем ID каждой, после чего, вырезаем "mark" или "id" . дальше находим select с этими id="mark" или id="id" и туда вставляем option value = 56 или option value = 45. и устанавливаем атибут selected
В итоге у нас 2 списка select, с нужными значениями и именами (mark и id), что свободно обрабатывается на стороне сервера.

А зачем все это? Ну как бы вы делали, если бы делали просто, обычные списки и в них выбор? Думаю ваш пользователь не стал бы делать запросы на все mark, id и прочее, а вы бы прописали все опции списков и все.

Не знаю где вы там летаете, но думаете вы точно не логично. Как вы связываете таблицы свои? Привыкли к термину id и используете его? А что это по сути означает? А это означает, что у вас в прямом смысле слова имеется набор массивов (таблиц), элементы которых вы связываете по их индексам. Так почему же элементы массива на странице вы пытаетесь создавать, что затратно само по себе, вместо того, чтобы просто связать готовые? Решение у вас под ногами валяется, а вы окольными путями не понять что пытаетесь делать.

function setValue(e) {    if(e.tagName=='SPAN') {       var prt = e.parentNode.id;       var elm = document.getElementById(prt).getElementsByTagName('span');       for(i=0; i<elm.length; i++) {          if(elm[i]==e) {             document.getElementById(prt+'id').options[i].selected=true;             break;          }        }     }  } </script> <b>Sets 1</b> <div id="m" onclick="setValue(event.target || event.srcElement)">   <span>Set 1</span>   <span>Set 2</span>   <span>Set 3</span>   <span>Set 4</span>   </div> <b>Sets 2</b> <div id="p" onclick="setValue(event.target || event.srcElement)">   <span>Set 1</span>   <span>Set 2</span>   <span>Set 3</span> </div> <form> <select id="mid" name="s1" style="display: none;">   <option value="10">   <option value="12">   <option value="15">   <option value="16"> </select> <select id="pid" name="s2" style="display: none;">   <option value="34">   <option value="24">   <option value="53"> </select> <input type="submit" value="Search" /> </form>

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

PS. Добавление элементов предполагает и удаление их. В этом случае, то как вы подходите к такой реализации никуда не годится. В этом случае тем более нужно абстрагироваться от множества различных имен, оперируя ими в сценариях. В противном случае вас неминуемо ждет громоздкий сценарий как на клиенте, так и на сервере.

Не понятна строчка var elm = document.getElementById(prt).getElementsByTagName('span');
Потом получаем длину этого элемента и проверяем, если элемент по которому кликнули совпадает с тем что уже есть в option то делаем его selected.
Как я понимаю, созданные списки select нужны лишь для ограничения предлагаемого выбора (кол-во кликаемых объектов)

1. Эта строчка возвращает коллекцию элементов span указанного родителя (того, в котором был выбран элемент).
2. Получаем не длину элемента, а размер массива этих элементов.
3. Проверяем, равен ли текущий (в итерации цикла) элемент массива элементов, элементу по которому произвели щелчок, таким образом определяем индекс опции списка, которую нужно выбрать.
4. Списки нужны для того, чтобы отправить на сервер выбор пользователя, к каким либо ограничениям они отношения не имеют, просто в данных списках нельзя сделать множественный выбор, а выбор опции в нем, автоматически снимает выбор с ранее выбранной опции.

Сомнительно. тут строгая последовательность span и option, а если элементы span я выведу в другой очередности? тогда будет выбрана другая option

Что сомнительно?
Тут нет строгой последовательности, тут есть соответствие последовательности одного набора, последовательности другому - span -> option, и разве большая проблема расставить эту последовательность так, как вам угодно?

function setValue(e) {     if(e.tagName == 'A') {        var prt = e.parentNode.id;        alert(prt);       var elm = document.getElementById(prt).getElementsByTagName('a');           for(i=0; i<elm.length; i++) {                    if(elm[i]==e) {              document.getElementById(prt+'_auto').options[i].selected=true;              break;           }         }      }   }

Не сработало для html вида:

<div id="type" onclick="setValue(event.target || event.srcElement)">        <a href="#" id="type[1]">       <img src="http://kolesa.com/public/images/icons/body_1.png"></a>        <a href="#" id="type[2]">       <img src="http://kolesa.com/public/images/icons/body_2.png"></a>         <a href="#" id="type[3]">       <img src="http://kolesa.com/public/images/icons/body_3.png"></a>     </div> <select name="type_auto"> <option value="1">1</option> <option value="2">2</option> <option value="3">3</option> </select>

Опять я привязался к ID, получается что это лишнее.. что подставляется при сравнении в цикле в качестве e?

А как вы предполагаете, почему у вас не сработало? А потому, что щелкаете вы по картинке, а в условии проверяете щелчок по ссылке. К чему у вас ссылки:
1. нужно произвести переход?
2. произвести щелчок по картинке?
3. для того чтобы получить курсор "ручкой"?

Перехода по адресу, как и внутри страницы, вроде бы как не нужно? А по картинке без тега А щелкнуть невозможно, и назначит картинке курсор "ручкой" никак нельзя? Откуда эта дурная привычка втюхивать на страницу фиктивную ссылку ради чего-то необъяснимого?

function setValue(e) {      if(e.tagName == 'IMG') {         var prt = e.parentNode.id;       //alert(e.sourceIndex-e.parentNode.sourceIndex-1)         var elm = document.getElementById(prt).getElementsByTagName('img');         for(i=0; i<elm.length; i++) {            if(elm[i]==e) {               document.getElementById(prt+'_auto').options[i].selected=true;              break;            }          }       }    } </script> <div id="type" onclick="setValue(event.target || event.srcElement)">     <img src="http://kolesa.com/public/images/icons/body_1.png" />     <img src="http://kolesa.com/public/images/icons/body_2.png" />     <img src="http://kolesa.com/public/images/icons/body_3.png" />  </div>  <select name="type_auto">  <option value="1">1</option>  <option value="2">2</option>  <option value="3">3</option>

Что с чем сравнивается я уже писал - элемент по которому произвели щелчок с элементами набора в которые он и сам входит. Это для того, чтобы получить индекс элемента. Для IE можно было бы обойтись и без всякого цикла - расскоментируйте строку кода в функции и вы увидите индекс элемента в наборе. Но свойство sourceIndex к сожалению поддерживается только MSIE.

Этот код, это простой подход к вашей задаче, и основывается он на том, что в силу своей функциональности элемент select делает за вас некоторую работу - выполняет роль автоматического переключателя, которому нужно сообщать только позицию, все остальное он сделает сам. Если выбрать иные элементы для этого, то такое переключение вам придется делать программно.

Управляя элементами посредством их индекса в наборе, и при этом управляемые элементы являются источниками значений, нет необходимости в управляющих элементах прописывать параметры дублирующие эти значения, так как у вас в тегах А прописано, да еще с явными указаниями индексов. И давно пора уже уяснить - первый индекс в наборе (а равно как и в массиве, без указания иного) это 0, а никак не 1.

Вам так важно какие имена идентификаторов будут иметь элементы, и вы их "любовно" будете называть "_auto", "_type"...? А оно нужно? Хотите, пишите, но в этом случае имя идентификатора списка (если говорить относительно этого примера) и имя идентификатора родителя элементов стройте по иному принципу, добавляйте код формирующий эту ссылку на идентификатор, если простого формирования (как в примере) будет недостаточно. А по большому счету, это совсем не нужно, достаточно простого именования, не важно что это будет, главное по единому правилу, которое в данном примере определяется в функции - имя родителя+одинаковые для всех списков часть имени идентификатора. А кроме идентификатора у элемента есть и атрибут name, в котором, и пишите "_auto", "_type"... Но даже и в атрибуте name списков имен типа "_auto", "_type" совсем не нужно, это даже вредно, и вот почему.

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

А вредность "разношерстного" именования, когда на одной странице управляемые элементы (элементы определяющие значения) будут иметь одни имена, на другой другие, на третьей иные, заключается в том, что в этом случае на серверной стороне придется производить проверку и обработку параметров/данных для каждой страницы индивидуально. А ведь страница (будем считать, что это и есть категория в вашем контексте) это все лишь иной идентификатор ее определяющий, как и набор значений пришедших из формы - это набор идентификаторов определяющих записи в таблице. И решаемая задача для всех одна - поиск по выбранным параметрам (хотя поиском назвать это можно только с натяжкой, это скорее выборка по выбранным параметрам).

Отсюда следует, что клиентская сторона должна отдавать серверу не "_auto", "_type" и "_чего_только_не_взбредет", а однотипный для всех страниц набор данных, в котором идентификатор категории, это ключ/ссылка/вектор определяющий таблицу/набор_таблиц/набор_полей, к которым нужно произвести запрос, а идентификаторы наборов определяют параметры запросов. В этом случае добавить новое условие или параметр к запросу, это просто описать в серверном наборе этот параметр/условие, а в клиентском наборе добавить соответствующий элемент/элементы. При этом код клиентской стороны изменять не потребуется. В этом случае и серверный обработчик для всех страниц будет один и тот же, работающий по одному и тому же правилу.

Все что выше доступно для понимания. Спасибо. Хотелось бы разобрать вот это:

RE: Отсюда следует, что клиентская сторона должна отдавать серверу не "_auto", "_type" и "_чего_только_не_взбредет", а однотипный для всех страниц набор данных, в котором идентификатор категории, это ключ/ссылка/вектор определяющий таблицу/набор_таблиц/набор_полей, к которым нужно произвести запрос, а идентификаторы наборов определяют параметры запросов. В этом случае добавить новое условие или параметр к запросу, это просто описать в серверном наборе этот параметр/условие, а в клиентском наборе добавить соответствующий элемент/элементы. При этом код клиентской стороны изменять не потребуется. В этом случае и серверный обработчик для всех страниц будет один и тот же, работающий по одному и тому же правилу.

Как же принимать/распознать списки select на стороне сервера, если не указывать для них name "_auto", "_typ"? Как определить этот идентификатор? Это идентификатор для всех элементов находящихся в нем?
Нужен пример простой для наращивания.

Вы немного не так поняли. Ключи (имена списков в данном случае) обязательно нужно указывать, иначе вы их просто не получите на сервере. Я имел ввиду несколько иное.

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

А по этой ссылке можно определить следующее - есть две четко определенные группы параметров, первая, это набор неких id для выборки, а вторая, это произвольные значения, условия выборки. При этом первая группа может иметь разное число строк разной длины (ширина набора) от страницы к странице. Вторая группа может иметь, не иметь, или иметь различный способ определения значений, например, диапазон от и до, либо больше/меньше/строго равно.

Теперь представим, что вы именуете на первой странице первую группу как "_auto", "_type"..., на второй странице как "_moto", "_toto"..., на следующей еще как-то, то на сервере вам придется проверять строго по именам, что за ключи пришли (перебирать все их поименно), чтобы определиться с какой страницей вы работаете, какую при этом проверку, какие действия над ними надо произвести, и т.д., и т.п.. Ради справедливости стоит отметить, что это конечно же не такая и проблема большая, зная о том, что пересечением массивов можно всегда вычленить нужное. Но для большинства операций, которые вам обязательно потребуется делать, как то приведение значение к целому перед запросом к базе, все эти ключи пустой звук - они не нужны для этого.

А теперь представим, что ваши списки определяющие первую группу, это массив под одним и тем же ключом, например, ids[], на всех страницах. Просто таких списков (элементов массива) на страницах может быть разное количество. Так как вы работаете со страницами (категориями), то вам обязательно потребуется ее идентификатор, пусть это будет ключ cat, также один и тот же для всех страниц.

В этом случае серверу не надо определяться с ключами, который из из них и что означает. Сервер знает, что ему надо получать всегда массив ids, с помощью array_map() значения этого массива приводить к целому, и если после этого среди его значений не будет равных нулю, то все в порядке, продолжать выполнение операций.

А операции будут одни и те же - получить таблицу/таблицы, получить имена полей, сформировать запрос, используя значения полученного массива как параметры этого запроса. При этом ключи полученного массива являются ссылками на параметры запроса.

Как конкретно, это будет зависеть от структуры таблиц, от их набора, к которым придется обращаться, поэтому для примера просто. Например, первая страница это категория 1, вторая 2. И клиент вернул серверу массив:

array(cat=1, ids=array(10,12))

После обработки которого у вас будет массив $ids, определяющий значения для запроса.

На сервере существует массив, который описывает связь этого массива с таблицами и параметрами запроса. Например:

<? $link=array(    1=>array( //набор параметров запроса первой страницы         'table'=>'table_name', //таблица или таблицы участвующие в запросе        'fields'=>array('fld1='.$ids[0], 'fld2='.$ids[1])        ),    //параметры запроса второй страницы     2=>array('tbl1, tbl2 WHERE fld1='.$ids[0].' AND fld2='.$ids[1].' AND fld3='.$ids[2])       );

По значению ключа cat из этого массива выбираются параметры запроса (пример для страницы 1) или уже сформированная часть запроса (пример для страницы 2). При этом пример со второй страницей конечно проще, но в таком подходе есть один недостаток - хотя и можно, но сложно проверить соответствие числу поступивших параметров. То есть, если над вами шутят, и вы не хотите казусов, то нужно проверять число поступивших параметров числу запроса. В первом случае (ключ страницы 1), это сделать просто, сравнив число элементов массива $ids с числом элементов ключа fields массива $link. Кроме этого, параметры первой страницы позволяет производить некие дополнительные манипуляции с набором, если это требуется.

Объявление элементов массива, это ведь не только просто указание ключ=>значение, это может быть как выражение=>выражение, а значит можно описать все что угодно, а получить строку параметров из описанного массива выражений, так это просто implode().

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

Что касается поиска на стороне сервера - сложностей нет. Сложность в формировании массива на стороне клиента.
Если вернуться к написанному Вами:

А теперь представим, что ваши списки определяющие первую группу, это массив под одним и тем же ключом, например, ids[], на всех страницах.

Что вы называете в данном случае ключом? Допусти у меня набор ссылок (группа) - что будет ключом здесь?
Как я понимаю, cat - это некий идентификатор страницы, а ids[] это массив из индексов всех элементов страницы, по которым можно произвести клик и которые задействованы в поиске.
Вот как мне на стороне клиента сформировать этот ids[]?

Уж извините..

>Вот как мне на стороне клиента сформировать этот ids[]?

Я ведь писал, да и писать ничего не надо, так как сложности в этом нет. Если в контексте кода приведенного ранее, то достаточно именовать списки как name=ids[]. Вот и получите на сервере массив этот как вложенный массив массива в $_GET.

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

Т-е все сводится к одному списку select с именем ids[] и value равными индексу(или ID) кликабельных элементов?

Не понимаю в каком направлении вы думаете, если на вопрос "хватит ли одного списка" для выбора и передачи нескольких параметров, ответ вроде бы был. Если вам надо передать одно значение, хватит одно списка, как впрочем и любого другого элемента формы. В этом случае и именовать список или иной элемент как элемент массива совсем не требуется. Но если выбирается и передается несколько параметров, то как вы вы сможете передать их одним списком (трудности связанные со списком с множественным выбором уже отмечались), или любым другим одним элементом, или одним элементом массива?

Все таки без примера на стороне клиента - не разобраться..суть понятна в целом, но некоторые моменты выпадают из понимания

Если разные списки select, то как сформировать общий ids массив который и передать серверу?

Какой вам еще нужен пример, если я вам изначально показал код с двумя списками, и которым достаточно каждому дать имя - <select id=mid name=ids[]> и <select id=pid name=ids[]> ?

<select id=mid name=ids[]> и <select id=pid name=ids[]>

И вот тут я тоже задавал вопрос - получается что 2 select c одинаковым именем - это и есть один select с таким именем, и как потом его на стороне сервера обработать?
Как определить из массива что array(cat=1, ids=array(10,12))

10 это марка автомобиля Toyota а 12 это уже тип авто (грузовик)

А пример на сервер я для чего вам писал?
Если вы знаете, что первый список определяет марку, а второй тип, и при этом марке соответствует имя поля mark в таблице, а тип это имя поля auto, и с данной страницы при этом вы запрашиваете только марку и тип, то велика ли трудность это прописать для примера выше:
fields=>array('mark='.$ids[0], 'type='.$ids[0]) ?
А 10 и 12, это id значения соответственно, которые позволят выбрать именно Тойету и грузовик. Вы что-то путаете котлеты с мухами.
Назовите хоть "чертом", но описать соответствия одного другому, какая может быть трудность в этом?

Давайте так..

Есть 2 скрытых списка (поиск по 2-м критериям):

1) По марке авто

<select id=mid name=ids[]> <option value="38"></option> <option value="19"></option> ....

</select>

2) По модели авто

<select id=pid name=ids[]> <option value="90"></option> <option value="34"></option> </select>

У обоих элементов name=ids[], т-е на сервер полетит массив ids (сформированный из selected элементов списка), массив будет одномерный.

_________
На странице есть ссылки выбора (критерии выбора), по клику на которые, как мы уже установили выше - делается select по индексам. Т-е по клику в двух списках происходит выборка тех элементов option, которые полетят на сервер как элементы массива ids.

_________________
Как теперь на сервере обработать этот массив и установить взаимосвязь, т-е что 38 и 19 это относится к марке авто, а 90 и 34 - к модели авто..
Т-е как формируется массив

fields=>array('mark='.$ids[0], 'type='.$ids[0])

мне не ясно..и почему индексы 0?

Индексы равны 0 потому, что скопировал, а не подправил. Я вам уже тут целую повесть написал и все об одном и том же, и выше есть пример, где все правильно, можно было бы и догадаться, что я просто ошибся, от усталости. Отправьте эту форму и смотрите.

<? if($_GET) {    print_r($_GET); //соответствуют индексы массива вашим 38 и 90?    $ids = array_map('intval', $_GET['ids']);    if(!array_intersect($ids, array(0))) { //не дурят, работаем       $sql = 'SELECT * FROM table WHERE ';       //это так только в примере, а вообще массив этих параметров       //можно описать загодя, как настройки, и подключать его здесь        $link = array('fields'=>array('mark='.$ids[0], 'type='.$ids[1]));       $sql .= implode(' AND ', $link['fields']);       echo $sql; //смотрим результат       //ну как, соответствуют в итоге ваши цифры вашим именам?     } } ?> <form> <!--  Если для вас это такая трудность, то будем ссылаться на список,  который определяет марку как mid, по первому символу от слова mark и он у нас в форме первый, а значит его индекс в GET массиве будет равен 0 -->  <select id="mid" name="ids[]">  <option value="38" selected>38</option>  <option value="19">19</option> </select> <!--  а на список, который определяет тип tid, соответственно первому символу от слова type и он у нас в форме второй, а значит его индекс в GET массиве будет равен 1 --> <select id="tid" name="ids[]">  <option value="90" selected>90</option>  <option value="34">34</option>  </select> <input type="submit" value="Send" /> </form>

Я же вам несколько раз повторял - что для индексного набора важен порядок, для именованного же набора, был бы важен общий принцип именования.

А как же быть для

multiple="multiple"

?

И каким образом будут определятся в нем значения, если Тойета и грузовик?

В этом и проблема. Какие варианты?

Вариант, когда Тоейета, Мазда, Хонда, Камаз..., это один набор, а седан, кабриолет, джип, грузовик, это другой связанный с первым набор, и при этом в каждом наборе можно выбрать по одному варианту, многократно описан выше. И это описание базировалось на ваших словах и ссылке вами представленной. И если именно к такой задаче вы желаете "прикрутить" список со множественным выбором, то этот элемент в данном случае совсем не походит.

Что вам на самом деле надо мне не известно, поэтому о каких вариантах и для чего может идти речь? Можно и мультисписок, можно и иное решение, можно много решений применить, но зная исходное.

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

Немного истории. В далекие времена, когда зарождались железяки именующиеся компьютерами, их разработчики уже понимали, что это необычные железки, а программные. Такая железяка могла служить для выполнения любого каприза хозяина, и поэтому снабдили ее портами, к которым хозяин мог подключать свои капризы. А чтобы понимать эти капризы хозяина, разработчики придумали прерывания.

По меркам того времени железяка получилась вполне не плохая, но без мозгов она бы так и осталась железякой. Но бог послал чародеев и кудесников, которые с этой задачей справились, как то чародея Стива Возняка и кудесника Билла, и родили они дочек, назвав их операционными системами. Хотя первая дочка Билла была скорее падчерицей ему, тем не менее он вложил в нее свои семена. Родители ОС прекрасно понимали выгоду портов и прерываний в железяке, и снабдили свои ОС еще и программными прерываниями. "Зашибись!" - воскликнул Билл в конце работы, потирая руки, и понимая аппаратные и материальные выгоды такого решения. Именно с тех пор и храниться в Национальном музее США документ известный как "Билл о правах", на котором русский турист (любитель писать на заборах) дописал мелом - "на PS-DOS 1.0", но это уже новейшая история.

Выгоды

Прерывание - это запрос устройства к центральному процессору на выполнение программы обслуживающей это устройство. А связывают устройства и программы их обслуживающие таблица векторов прерываний. Эта таблица всегда имеет одно и тоже расположение (адрес) - в начале памяти (нулевой адрес), и занимает фиксированную ее часть, и представляет собой адреса (точки входа) по которым и расположены программы обслуживания прерываний. Это означает, что можно не меняя вектор, изменить программу на которую указывает вектор, и тогда...

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

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

И при всем при этом разнообразии разработчику ПО совсем не обязательно знать адреса векторов, ему достаточно знать их номера, как-то INT 20, INT 21... А уж, если писать ПО на языках "человеческого понимания", то он может вообще даже и не подозревать об этих номерах, как и векторах прерываний вообще.

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

И к чему тут прерывания, если мне нужна Тойета грузовик?

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

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

Не мудрствуя лукаво, вы зашили во внешнее устройство команду "Тойета" для центрального процессора, который снабдили макро-операциями для этой команды, а оконечное устройство научили выдавать результат этой команды. Все бы ничего, но завтра вам потребовалась команда "Хонда". Пришлось зашивать во внешнее устройство новую команду, процессору определять макро-операции для нее, а оконечное устройство выдавать новые данные.

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

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

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

И как это работает?

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

Если уже на данном этапе имеется несколько страниц, с которых предполагается отправка формы, а тем более, если страницы с подобными формами будут добавляться в будущем, то иметь обработчики по векторам как массив описывающий их, это означает, что при каждом добавлении страницы придется править код - перепрошивать процессор. Следовательно, вектора обработчиков (id страниц) лучше хранить в базе, под которыми и будут описываться параметры обработчиков. Тогда, добавляя новую страницу, достаточно в такой таблице описать параметры драйвера обработчика ее формы, учитывая соглашения по адресации.

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

Финита

Не гоните лошадь, вы не на скачках, на вас ставку никто не делал, и прийти первым не значит еще выиграть. Лучше остановиться и подумать как прийти к финишу с наименьшими затратами сена, по кратчайшему пути. А когда свяжите воедино все, определитесь с тем, что необходимо для этого, что будет более оптимальным, родите хотя бы "эскизы" своих устройств логически связанных с оконечными, с драйверами обработки их, тогда, и только тогда, можно будет говорить предметно - о внешних устройствах ваших (формах) в этом разделе, и о драйверах для них в соответствующем разделе. А данная тема, это только как предложение подумать "как...", и как показывает ее русло, совсем не базируется на требуемом.

Возникла вот такая идея:
В таблице cars у меня есть поля:

Transmission Control Petrol Marka Model
В каждом поле храниться уникальное число, определяющее TITLE из другой таблице по связи

cars.Petrol = table2.id, где Table2.id

уникальный идентификатор.

ID         TITLE 1           Легковые 78         Бензин 20         Toyota 189       E-678

Идея в том, чтобы на стороне клиента сформировать список Select из всех накликанных ссылок, т-е SELECT примет вид:

<option value="1"></option> <option value="78"></option> <option value="20"></option> <option value="189"></option>

А на стороне сервера принимать это массив, удалить повторяющиеся элементы массива и подставить данные в запрос, для определенных полей Transmission Control Petrol Marka Model

SELECT * from Cars WHERE Transmission Control Petrol Marka Model IN(1,78,20,189)

_______________________________________________________________________
Как вариант искать и снизить нагрузку на базу такая:

1) Отсортировать полученный массив в порядке возрастания
2) Взять первый элемент массива и выполнить запрос:

SELECT * from Cars WHERE Control = 189 OR Pertol = 189 OR Marka = 189 OR Model = 189.

3) Если запрос выполнится, то для

следующего запроса

с числом 78, мы отсекам одно поле, результат которого от первого запроса, т-е если 189 было найдено в Marka, то следующий запрос примет вид:

SELECT * from Cars WHERE Control = 189 OR Pertol = 189  OR Model = 189.

Причем от предыщего запроса с 189 выдернуть ID записи, чтобы следующий раз не тянуть все записи в таблице, а добивать на оставшиеся значения запись с этим ID, в случае, если не найдено, искать по другим строкам.
И так далее до последнего элемента массива.

Тут придется писать реруксию, либо вложенный SELECT, что Вы думаете об этом?

>А на стороне сервера принимать это массив, удалить повторяющиеся элементы массива и подставить данные в запрос

Оригинально, имеем список значений: 1, 78, 20, 189 и при этом на сервере нужно удалить повторяющиеся элементы! Это какие и из чего они у вас появились?

>Тут придется писать реруксию, либо вложенный SELECT, что Вы думаете об этом?

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

Вы вообще понимаете то, что в базе вы выбираете строку, значения столбцов которой должны быть равны указанным в запросе, из чего следует, что значение 1 - это элемент одного списка, 78 - второго списка, 20 третьего и т.д.?

В общем так - сперва в раздел MySQL, разберитесь с таблицами, с запросами, а потом только сюда, и создавайте другую тему, это пора закрывать - конкретно и предметно в новой теме, если конечно родите что-то.