Hi Paul
You're obviously right, and it's a good point, that this variable naming
convention ([element name]_[attribute_name]) could cause problems in the
circumstance that you've illustrated. In the tag's defence, it's not really
intended to support the potential unlimited complexity of an XML document,
but rather to provide an easy means of database-like data storage with XML.
We're using it with attribute-heavy XML files:
<person id= "1" email = "[EMAIL PROTECTED]">tom dyson</person>
<person id= "2" email = "[EMAIL PROTECTED]">paul johnston</person>
where the [element name]_[attribute_name] convention is easy to read. But
perhaps I should forget this and just give attributes the same status as
element names, so that the XML above would yield the variables
person, email, id
Then you would only run into problems if you called attributes the same
thing as some elements, eg:
<person id= "1" email = "[EMAIL PROTECTED]">tom dyson</person>
<id>345</id>
I guess this is pretty unlikely, and it certainly wouldn't be very good
practice, but it's still possible. I don't think I understand what you're
saying about creating a unique key for the attribute - can you clarify?
Best wishes
Tom
> Just a question...
>
> You return the data as a query (fair enough), but...
>
> you return attributes as: [element name]_[attribute_name]
>
> This could cause problems if you have (say)
>
> <help file="true"/>
> <help_file>
> This is the help file.
> </help_file>
>
> Now I know that this is badly written XML, BUT the situation can occur.
> This will produce two variables called:
>
> help_file = "true"
> help_file = "This is the help file."
>
> I would therefore call into question how you intend to add in attributes.
>
> The normal way of doing so would be to create a unique key for the attribute
> whilst being able to refer back to the original code.
>
> Anyone else agree that this could cause a problem?
>
> Paul
-----------------------+
cf-xml mailing list
[EMAIL PROTECTED]
http://torchbox.com/xml
