Galkov писал(а):
Естественно, все это в рассчете на исполнение в Design-Timeвот это задача номер 1 на ближайшее время. Доработать кодогенератор так, чтобы в любой моент времени для любых данных скрипта можно было сказать какого они типа. Принцип Guid-ов останется, но конечно же только для Design-Time. В конечном приложение их уже не будет.
Galkov, решил таки тут задасться вопросом, а чего нам еще конкретно не хватает, чтобы сделать свой настоящий и полноценный элемент в пакете WEB из элементов низкого уровня? Оказалось что совсем чуть чуть:
code_1598.txt
Чтобы из этого получить полноценный элемент нужно memory заменить на некий компонент с двумя точками(верхняя Data и нижняя Result) и одним св-вом(Data), работающий так: если верхняя точка включена, то передавать данные с нее на точку Result, иначе если св-во Data задано, то передавать его и в противном случае считать точку Result не подключенной. Положим элемент сделать не сложно однако требуется то, о чем мы уже как-то говорили: нужно сделать интерфейс через который кодогенератор сможет у самого элемента спросить о подключенности его точек. Скажем, у описанного компонента этот интерфейс реализовывался бы так:
func isLinked(point)
if(point = "Result")
return(isset(Data))
end
endОднако делать такой интерфейс сейчас не хочется. Вызов парсинга hws на каждый linked в скрипте это очень ресурсоемкая процедура. Испытывать на медленном варианте конечно можно, но слишком уж заметна эта медлительность получается. Да и хинты над точками начнут заметно тормозить.
Впрочем не факт еще, что такой интерфейс является удачным. Может быть стоит боле общий:
func getState(cmd, object)
switch(cmd)
case IS_POINT:
if(object = "Result")
return(isset(Data))
end
end
endсобственно тема для размышления
[size=-2]------ Добавлено в 17:16
PS: сделав такой элемент и вставив его в схему таким образом:
code_1599.txt
мы по идее получим конечный код при любых включениях вточности таким, каким он получается в элементе md5
Поиск
Друзья
Администрация