On 2/5/07, David Huynh <[EMAIL PROTECTED]> wrote: > Johan Sundström wrote: > > Is there any reason why the id property of items are not available as > > facets, ex:content data and the like? I'd like to list my cities in > > the facet browse panel as .location.city.id, but can't (the facet does > > not show up at all). > > > > http://ecmanaut.googlepages.com/choir-events.html > > Can you use .label instead? Not the same but almost. For that particular > example, I think .location.city would be sufficient. > > I just thought "id" isn't really a property. But I'm open to more > flexibility.
I do, at the moment, though I'd prefer the flexibility. I organized my city id:s so they would be fully qualified by country and city name and thus unique enough for the scope of this hack, and used labels to convey the name of a city alone. In my facet view I would want to show the fully qualified name, though, so people could tell Paris, France from Paris, Tennessee, For instance. Of course I'd gladly do that with a facet specification along the lines of ".location.city + ', ' + .location.city.country", but I had a feeling that might be asking a bit much again. ;-) I'm also one for flexibility, though, and so far I have not dug deep enough in the language / expression bits of the code to understand what is so difficult about supporting that kind of flexibility. (Users believe this liberates them from being limited by whatever obstacles might lay hidden there. In a way they are even right about that stance. ;-) Regarding id being a property or not, here is how I perceive it, as a javascript hacker (to pick some trait that felt potentially relevant). All the data I enter into a system is in some way a property of it, and dynamic reflection (I'm a bit too far into the night to be really sure I'm using comp.sci terms properly now, though, so tune your blur filter appropriately :-) is often more useful than data hiding. Maybe I'm not quite attuned to how to best organize data yet, but I was sort of assuming I might not have to think so hard about it, given the "your data, your mess, your problem" philosophy mentioned. (And it felt to me like id:s would be part of that. :-) I'm still not sure I've fully taken in the scope of those id:s being the *only* property that discerns between two different items in the system, though; I would have felt much more comfortable in an environment where items were compartmented into separate id namespaces by item type. Not having that still feels somewhat wrong to me, though it has not yet been a practical issue. I guess I'll have to start employing id tagging techniques once I move into Book and People items or the like. And then I can buy that you'd rarely want to see the id:s themselves. ...Almost. ;-) (Still very useful for debugging and developing an exhibit!) -- / Johan Sundström, http://ecmanaut.blogspot.com/ _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
