Схема: сабмит формы -> обработать ввод большого количества разных контролов

[wvxvw]

Вопрос теоретического характера:
Переделываю свой старый проект, и вот в нем есть одно место, которое мне очень не нравится, а придумать, как бы его переделать не могу...
Вобщем, что есть: набор из полтора десятка разных форм, каждая из которых состоит из еще 1-2 десятка контролов. Все формы при изменении значения в хотя бы одном контроле сабмитят новое значение обработчику который должен 1. обновить состояние экрана, 2. обновить ХМЛ представление того, что происходит на экране + иногда обновить состояние связаных контролов (например, можно одновременно изменить ширину и положение по Х объекта - нужно обновить сразу 2 значения). Сейчас обработчик выглядит как длинющий switch-case с вложенными switch-case примерно так:

onSubmit(evt:FormEvent):void
{
	switch(evt.form)
	case 1:
	switch(evt.formElement)
	{
		case 1:
			screen.layer[1].updateElement(elementID = 1, elementValue = evt.value);
			xml.form[1].@formElement = evt.value;
			...
		case 2:
		...
	}
	case 2:
		...
	case N:
	...
}

Проблема еще и в том, что значение контрола может быть чем угодно, т.е. строкой, числом, массивом... на форме может быть несколько однотипных контролов, которые можно различить только по ID, но тем не менее, нужно выполнить разные действия при изменении значения в том и другом.
Недостатки такого метода очевидны - если на форме добавится / удалится 1 контрол нужно делать изменения в обработчике. Не возможно сгенерить форму "на лету", т.е. технически, конечно, можно, но обработчик не будет знать что делать с импутом от такой формы... + этот switch-case неимоверной длины (строк 400 чтоб не соврать) и вобщем, выглядит это крайне удручающе =)
Вопрос: как бы перепроектировать это дело, чтобы 1. можно было избежать switch-case, 2. создавать формы "на лету"?

[chatlano]

как насчет того чтобы унаследовать контролы от одного класса или организовать интрейфес который реализуют разные классы и далее используя полиморфизм избавиться от switch? более подробно можно почитать у Фаулера в "Рефакторинг"

[wvxvw]

Контролы и так наследуются от одного класса... проблема в том, что на форме может быть, например, 2 input text, один сабмитит значение в виде XX:YY, другой - "абвгд". И обработать, соответственно, нужно по-разному. А как пишется фамилия автора "Рефакторинга" по-английски? Чего-то я не соображу..

[chatlano]

Martin Fowler "Refactoring Improving the Design of Existing Code". По поводу разных инпутов. Если формат ввода разный можно и два разных класса организовать?

[wvxvw]

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

ЗЫ. За книжку пасиб, буду искать =)

[Яски]

Создай класс контроллов с полями-значениями. В каждом контролле храни список связанных контроллов. XML и перерисовщик экрана тоже контроллы. При изменении значения в контролле, контролл вызывает метод update у всех связанных с ним контроллов. В твоей схеме фигово то, что отдельный класс занимается выполнением чужой работы.

[Felicast]

может я неправильно понял, но я делал примерно так(прошу прощения UML-редактора под рукой не оказалось):
два класса: элемент и форма.

элемент:
	onSubmitEl
	дополнительные поля
форма:
	onSubmit
	addElement
	список элементов

при добавлении элемента, мы указываем функцию onSubmitEl
в функции onSubmit проходимся по всем элементам и выполняем onSubmitEl

[wvxvw]

Сообщение от Яски

Создай класс контроллов с полями-значениями. В каждом контролле храни список связанных контроллов. XML и перерисовщик экрана тоже контроллы. При изменении значения в контролле, контролл вызывает метод update у всех связанных с ним контроллов. В твоей схеме фигово то, что отдельный класс занимается выполнением чужой работы.

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

Felicast:
Не знаю... мне если честно не хочется делать десятки замен в ХМЛе просто так. т.е. если на каждый сабмит переписывать все значения элементов на форме (при том, что изменилось оно только у одного... ) мне кажется нерационально

[Яски]

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

[wvxvw]

Дело в том, что не хочется в сеттере проверять, а действительно ли изменилось свойство, потому что иногда для этого пройдеться несколько фор-инов вложеных запустить... легче просто переписать по-новой.
А то получится:

var _abc:String;
var _def:String;

function abc(s:String):void
{
	_abc = s;
	def(s);
}
function def(s:String):void
{
	_def = s;
	abc(s);
}