How to use the Items
Magnus Alvestad
However I'm curious what the best practise is when you have retrieved
your items and want to access the attributes. At the moment I'm doing
stuff like this:
def objects = {
val sdb_objects = account domain "SV_Objects"
var objs: Map[Int, WorldObj] = Map()
for (o <- sdb_objects.items) {
val a = o.attributes
try {
objs = objs + ((o.name.toInt, WorldObj(swf(a).first, name
(a).first, width(a).first.toInt, height(a).first.toInt, 0, typ
(a).first, category(a).first == "floor")))
}
catch { case _ => ; /* TODO log error */ }
}
objs
}
but all that .first.toInt etc seems a bit cumbersome. How are others
handling this?
-Magnus
Robin Barooah
I presume swc, name, width, height, and category, are Attribute
objects from org.sublime.Attributes?
e.g.
import org.sublime.Attributes._
val name = attribute("swc")
val width = attribute("width")
If this is the mechanism you're using, then you can add a type
conversion to the attribute definition.
e.g.
import org.sublime.Attributes._
import org.sublime.Conversions._
val name = attribute("swc")
val width = attribute("", PositiveInt)
That will eliminate the need for the .toInt.
To get around having to keep doing .first, which is needed because
simpleDB doesn't constrain the number of values an attribute can have,
I have a pattern matching mechanism:
Where you define a pattern object - for example:
val articleHeader = matches(first(tags), first(title),
first(author),
first(created) or now)
And then you use a pattern match to extract the values:
val article = o.attributes match {
case articleHeader(topic, title, author, created) =>
Some(new Article (topic, title, author, created))
case _ => None
}
The pattern objects can be defined using the modifiers, "only",
"first", "each", and "any", and default values can be supplied as part
of the pattern. If part of the pattern doesn't match and there's no
default, then the whole record doesn't match.
This is nice because not only does it give you a clean way to avoid
the boilerplate, it also provides a neat path for handling unexpected
records which can occur with SimpleDB because of eventual consistency
and the lack of constraints.
I haven't put the code that goes behind this into the library yet,
because I haven't used it very much and I consider it experimental,
however if people are ok with that, I'd be willing to put it in.
-Robin
Magnus Alvestad
> because I haven't used it very much and I consider it experimental,
> however if people are ok with that, I'd be willing to put it in.
Sounds useful to me.
-Magnus