In the name of all that is simple, ActiveRecord::Base.to_xml
Finally, a major league database programming framework that supports dumping persistent objects structure and state out to XML!
Shoot, what could be easier?
Anyway, that is exactly what the ActiveRecord::Base.to_xml method in Ruby On Rails 1.1 does. Active Record objects can now be serialized into an XML document structure. They even output the XML processing instruction at the beginning of it.
Their format is not bad at all.
Not very complicated, really. The only thing you have to watch out for - is the possibility of cycles in the data model. If you have that, you run the risk of inciting an infinite loop. Not terribly pleasant.
I wrote a feature for a system quite some time ago that created almost identical output. It only took a few hours to program it, and I did it on a Saturday afternoon, in fact.
In my case, I did not have to worry infinite loops. The existing data model I was working with did not have one. If it had though, I could simply have pruned it at the point the cycle occurred, stubbed it with a special circular-reference element as a sort of out-of-band way of specifying circular object references, or done an ID/IDREF or some other similar XML semantic trick such as XLink.
One could even provide a way for the serializer to do that on the fly. But my API was as simple as I could make it for the problem at hand. So none of that stuff. And I knew I could do the other stuff if the need arose.
Now in Rails case, since they are are trying to support applications that have not even been written yet, they had to tackle this issue sooner rather than later. Their solution is rather simple.
You can specify an :include option - which takes a list of field names for fields which are first-level associations with the record being dumped out to XML, and it will chase them.
Or, you can specify an :except option. In that case, you feed it a list of field names to leave out. Kind of a skip-list. In fact, then it appears to be necessary to specify a :skip_instruct option and set it to a value of true.
Alternatively, you can use :only - which I take it is an opposite of :except.
What I remember was very cool about this XML format is that it is very easy for XSLT scripts/stylesheets to work with. For that matter, CSS 2.1 stylesheets could even work with it - at least a little.
To an XSLT stylesheet though, this XML is basically like modeling clay. It can walk the structure, take the information it wants, output the data values from the fields - and create.... whatever.
Generally, a web page is what gets spit out. However, in this MIME-aware, XML-enabled world - getting a PDF file or something even more exotic is no problem. [Very soon, SVG and DHTML-enabled Canvas elements are for web-style automatically-generated documents.]
And it most systems, that is generally the whole point of 90% of what the system does! Nobody spends a million or a billion dollars so there is a way to get information into it. They spend millions and billions of dollars so they can get information out! Think about it....
Something else this will probably vastly simplify, besides creating human-readable representations of information in the computer easily - is testing.
With this feature, being able to get a snapshot of the currently used object becomes universally easy. It might make all kinds of debugging easier too.
Hopefully, someone will create some non-intrusive debugging or logging tools that take advantage of this. Without introducing bugs or new complexities in the process, of course!
Being able to easily get an accurate snapshot of the data model objects as XML has another advantage.
This is exactly what you need for the model portion of an XForms document. If you are using XForms, instead of the older HTML forms (invented way back in the early 1990s) - you can just use this to populate your model.
Iterating over the ActiveRecord object graph, perusing its metadata might do a fair bit of the work for you as far as specifying the constraints needed by the XForms document.
All that is left is to mention what data entry fields are needed, and include CSS style sheets to give it a nice layout that looks pretty. The latter will probably be the web designer job and the former will of course wind up being the programmer job.
So, this is a handy feature Ruby On Rails 1.1 has included.
I have a hunch there will be a lot of people doing very clever things with it in 2006. And by sometime in 2007, people will already be saying: oh, yeah that trick.
Shoot, what could be easier?
Anyway, that is exactly what the ActiveRecord::Base.to_xml method in Ruby On Rails 1.1 does. Active Record objects can now be serialized into an XML document structure. They even output the XML processing instruction at the beginning of it.
Their format is not bad at all.
- Field names become element names.
- The data type of the value in the field for non-string fields (e.g. date, integer, etc.) will be explicitly mentioned as the value of type attribute on the element.
- Element contents are a string representation of the value for simple values, and for object values - the object is simply serialized nested within the element for the current field.
Not very complicated, really. The only thing you have to watch out for - is the possibility of cycles in the data model. If you have that, you run the risk of inciting an infinite loop. Not terribly pleasant.
I wrote a feature for a system quite some time ago that created almost identical output. It only took a few hours to program it, and I did it on a Saturday afternoon, in fact.
In my case, I did not have to worry infinite loops. The existing data model I was working with did not have one. If it had though, I could simply have pruned it at the point the cycle occurred, stubbed it with a special circular-reference element as a sort of out-of-band way of specifying circular object references, or done an ID/IDREF or some other similar XML semantic trick such as XLink.
One could even provide a way for the serializer to do that on the fly. But my API was as simple as I could make it for the problem at hand. So none of that stuff. And I knew I could do the other stuff if the need arose.
Now in Rails case, since they are are trying to support applications that have not even been written yet, they had to tackle this issue sooner rather than later. Their solution is rather simple.
You can specify an :include option - which takes a list of field names for fields which are first-level associations with the record being dumped out to XML, and it will chase them.
Or, you can specify an :except option. In that case, you feed it a list of field names to leave out. Kind of a skip-list. In fact, then it appears to be necessary to specify a :skip_instruct option and set it to a value of true.
Alternatively, you can use :only - which I take it is an opposite of :except.
What I remember was very cool about this XML format is that it is very easy for XSLT scripts/stylesheets to work with. For that matter, CSS 2.1 stylesheets could even work with it - at least a little.
To an XSLT stylesheet though, this XML is basically like modeling clay. It can walk the structure, take the information it wants, output the data values from the fields - and create.... whatever.
Generally, a web page is what gets spit out. However, in this MIME-aware, XML-enabled world - getting a PDF file or something even more exotic is no problem. [Very soon, SVG and DHTML-enabled Canvas elements are for web-style automatically-generated documents.]
And it most systems, that is generally the whole point of 90% of what the system does! Nobody spends a million or a billion dollars so there is a way to get information into it. They spend millions and billions of dollars so they can get information out! Think about it....
Something else this will probably vastly simplify, besides creating human-readable representations of information in the computer easily - is testing.
With this feature, being able to get a snapshot of the currently used object becomes universally easy. It might make all kinds of debugging easier too.
Hopefully, someone will create some non-intrusive debugging or logging tools that take advantage of this. Without introducing bugs or new complexities in the process, of course!
Being able to easily get an accurate snapshot of the data model objects as XML has another advantage.
This is exactly what you need for the model portion of an XForms document. If you are using XForms, instead of the older HTML forms (invented way back in the early 1990s) - you can just use this to populate your model.
Iterating over the ActiveRecord object graph, perusing its metadata might do a fair bit of the work for you as far as specifying the constraints needed by the XForms document.
All that is left is to mention what data entry fields are needed, and include CSS style sheets to give it a nice layout that looks pretty. The latter will probably be the web designer job and the former will of course wind up being the programmer job.
So, this is a handy feature Ruby On Rails 1.1 has included.
I have a hunch there will be a lot of people doing very clever things with it in 2006. And by sometime in 2007, people will already be saying: oh, yeah that trick.
Technorati Tags:
programming, ruby, rubyonrails, xml, testing
0 Comments:
Post a Comment
<< Home