wolverin,

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

Опишите причину таких странных желаний. Похоже вы выбрали не верный способ решения проблемы и теперь спрашиваете про своё решение, а не саму проблему.

wolverin,

Как вариант, можно из jQuery вытянуть текущее состояние формы и добавить в него любые поля\значения и отправить POST.

wolverinможно конечно через JS на onclick что ли каждый раз обновлять переменную... но может как то элементарнее способ есть
Нет никакой магии. Самый простой способ - запердолить описание внутрь value. Например, value="1:значение" и на сервере распарсить.

wolverinчтобы потом не запрашивать это полное описание по новой, а просто отобразить на следующей странице
1) Если к слою работы с БД прикрутить кэш, то запрашивать описание по новой вообще не страшно. А даже полезно, вдруг эта страница будет открываться другим use case-ом? То есть в твоём решении вторая страница получает +1 к зависимости от первой. Чем больше зависимостей, тем сложнее купировать волну изменений кода при реализации изменений требований.
2) В 90х состояние клиента хранили на сервере в HttpSession. Если ты пишешь в этом стиле, то запхай значения в сессию.
3) В нулевых поняли что хранить состояние на сервере не эффективно и ресурсоёмко, при росте числа клиентов ресурсы сервера заканчиваются слишком быстро. Поэтому появилась тенденция хранить состояние на клиенте. DHTML, AJAX и jQuery - наше всё. Отправляй что хочешь и куда хочешь и не надо бороться с ограничениями HTML FORM.

wolverinда тоже про это думал, но не ужели нету тега-атрибута, ведь по сути это же обычный список с ключом
Это вопрос не для Java форума.

wolverinда естественно 2ая страница зависит от 1ой и не может быть открыта без нее
Предлагаю высечь в граните ТЗ целиком. А то, не дай бог, кто его поменять решит.

wolverinс одной стороны да, а с другой все же вопрос как вытащить эти значения в жаве )
Опять ракурс странный. Проблема не в том чтобы вытащить в Java. Проблема в том чтобы отправить их в POST и это к Java вообще никакого отношения не имеет.

wolverin1. другим это как? только из одной же страницы делается post и ему бы обратно вернуть что выбрал

Сегодня у вас страница №2 открывается из страницы №1, а завтра из страницы №3. Если у вас №2 зависит от №1, то завтра вы садитесь всё переписывать для реализации №3. Google -> GRASP -> Coupling and Cohesion

wolverin2. да вот и не хотелось в сессию ничего пихать, уже имея печальный опыт взаимодействия потоков

Забота о синхронизации mutable состояния перпендикулярна проблема хранения чего либо в сессии. Я не говорю что это правильно. Я просто предлагаю как вариант. Кэш на уровнее БД в данном случае на много логичнее, так как эти данные не уникальны для клиента.

wolverin3. хранить хорошо, но мне нужно на клиента уже готовую html из jsp отдать
Мне просто тяжело понять зачем в 2016 году писать подобный код. Археологический интерес?