Как в одну строчку кода сделать xml-рыбу? - Страница 3

wvxvw · 29.05.2010, 22:40

Не, вы не поняли

Если не будет ошибки - значит ок, все замечательно, а если будет, то вот вам и валидация, чего еще нужно?
Т.е. смысл валидации - создаем документ типа того же XSL / DTD. Ну, давайте, для примера XSL:

Код:

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">
	<xsl:template match="//foo">
		<xsl:if test="not(bar)">
		Node foo has no bar children.
		But this is OK because XSL does not really validate anything.
		You will have to guess based on this message.
		</xsl:if>
	</xsl:template>
</xsl:stylesheet>

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

Код AS3:

<foo>.*.bar[0];

А вот Е4Х сразу же вам и сообщит об ошибке. Т.е. не нужно писать дополнительный код для того, чтобы делать валидацию, само E4X выражение уже ее делает. Ну тоесть не бывает ситуаций, когда вам нужно сделать более универсальный валидатор - сам по себе язык уже валидатор.
Ну, как бы, в реальной жизни вы будете знать, что из базы должны прийти данные вот, например такой стуктуры:

Код:

<foo><bar/></foo>

И вы же будете писать обработку типа xml.bar. И этого уже достаточно - вы сразу же написали и проверку и получение данных. Если вам нужно убедится, что bar - единственный узел - xml.bar.length() == 1, ну и так далее. Ничего универсальнее этого используя E4X вы не придумаете.
Не знаю, это все равно, что регулярными выражениями генерить регулярные выражения

orcpochta · 29.05.2010, 23:35

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

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

Вот различные потоки данных:
1)
<item id="1" name="item 1" />
<item id="2" name="item 2" />
...
<item id="n" name="item n" />

2)
<contact name="Andrey" age="27" phone="333-222-333" />
<contact name="Petr" age="24" phone="" />
...
<contact name="Mikhail" age="" phone="111-222-333" />

3)
<image name="image 1" path="../assets/img1.jpg" />
<image name="image 2" path="../assets/img2.jpg" />
<image name="image 3" path="../assets/img3.jpg" author="Petrov" />
<photo name="image" path="../assets/image.jpg" />

При направлении потока данных в компонент, он должен взять и построить таблицу, в которой шапка - это имена атрибутов (1: id, name; 2: name, age, phone; 3: name, path), строка - это отдельный элемент xml-листа, столбец - это атрибут.
Если мы смогли построить такую таблицу, то мы гарантировали, что:
1) во входящем потоке именно столько элементов, сколько строк в нашей таблице и все они одного типа (item или же contact) - никто не забыт, ничто не забыто
2) атрибутов в каждом элементе потока ровно столько, сколько у нас столбцов в таблице, и все они имеют тот же порядок и тип - это значит, что мы обработали корректно все свойства каждого элемента ничего не пропустив.

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

Далее, в потоке №3 3-ий и 4-ый элемент рушат однородность потока, т.е. нельзя корректно обработать эти элементы с принципом, что данные типа "image", шапка - name и path, и соответствующее им содержимое. Значит, либо в поток закралось что-то лишнее, что нельзя обработать, либо чего-то не хватает. Такие данные не могут считаться валидными по своей структуре, т.к. пришлось бы делать отсев, т.е. терять часть этих данных - такое сразу бракуется моим компонентом, потому, как он не смог бы выразить их визуально в срезе однородности данных.

Добавлено через 6 минут
практическое применение: банковские транзакции

wvxvw · 30.05.2010, 00:08

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

orcpochta · 30.05.2010, 00:11

Цитата:

Сообщение от wvxvw

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

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

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

Wolsh · 30.05.2010, 00:43

Названия столбцов - откуда? Они передаются в той же xml, так ведь? Разве не логичней при заполнении спрашивать у узла атрибут по переданному имени и его значение вставлять в таблицу? Если такого атрибута нет - ну так нет его, пустая ячейка.

orcpochta · 30.05.2010, 00:55

Цитата:

Сообщение от Wolsh

Названия столбцов - откуда? Они передаются в той же xml, так ведь? Разве не логичней при заполнении спрашивать у узла атрибут по переданному имени и его значение вставлять в таблицу? Если такого атрибута нет - ну так нет его, пустая ячейка.

названия столбцов - это имена атрибутов
логично, когда у узла есть все эти атрибуты и ничего лишнего
если какого-то атрибута нет или есть лишние, то это нарушение целостности и однородности данных

Добавлено через 1 минуту
пустая ячейка - это когда значение атрибута есть пустая строка, а не когда мы где-то потеряли эти данные или нам прислали часть данных из другой оперы

wvxvw · 30.05.2010, 01:30

А почему первый всегда валидный?

orcpochta · 30.05.2010, 08:56

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

udaaff · 30.05.2010, 11:18

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

orcpochta · 30.05.2010, 11:29

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

на счет компонента:

Цитата:

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

мой компонент должен отображать однородные данные, то что вы описали - это просто DataGrid без какой-либо претензии на однородность

Цитата:

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

задача моего компонента до безобразия проста - отобразить порцию неизвестных по структуре, но однородных данных - и ему говорить ничего не надо))