Perhaps one should use the schema to specify, for a given property, a default value (which in many cases might be the string "missing". Then if-statements could select for the default value as well.
Johan Sundström wrote: >>> Is there some way of doing an "if-not-exists" or an "else" clause for >>> the if variants? For now I have settled with a select/case construct >>> naming all possible values and defaulting to an ex:content, as above, >>> but it's not very pretty: >>> >>> <span ex:select=".end"> >>> <span ex:case="2006" ex:content=".end"></span> >>> ... >>> <span ex:case="1997" ex:content=".end"></span> >>> <span ex:content="'present'"></span> >>> </span> >>> >> Do you have a suggestion for how an "else" clause would look like in html? >> > > Nothing better than allowing for the negation of any if test, at worst > via an ex:not attribute, but preferably via a not() function of the > test expression (or an if-not-exists, in the former case). > > I just stumbled on an even better example of where something like this > is needed; items which have a title and an optional url, where you > want to render the title as a link when posible. > > >>> I would like to have (the option of) a "field not present" marker, >>> getting some predefined value in the facet list, i e the lack of an >>> end year above being listed as "present". Is it possible already via >>> the type system or something else I've overlooked? >>> >> No, that's not possible yet. Do you want that default to show up in both >> the facet and lens templates? >> > > The worst kind of feedback, I'm afraid; either mode of operation has > useful aspects to it. For this data set it would be helpful having > both (as I would not have to do if/else blocks for those facets). > > My gut feeling suggests there probably are use cases where a lens > would need to be able to discern the cases "field not present" from > "predefined not-present value inserted" from one another, though. But > perhaps it's not an either/or scenario? > > >>> Also, having the expressive power of the testing language in the case >>> constructs would be nice, perhaps allowing constructs like those I >>> intuited first, like >>> >>> <span ex:select=".end"> >>> <span ex:case="< 2000" ex:content=".end"></span> >>> <span ex:case="= undefined" ex:content="'present'"></span> >>> </span> >>> >> Hmm, I was afraid of making a full programming language... :) >> > > Don't feel (too) pressured to. ;-) > > A generic way of integrating user provided custom javascript functions > for reformatting or doing your own tests / filters would probably be > more useful than a slightly extended query language. But maybe (or > perhaps rather "probably") that is already there if you just grok > Exhibit.Functions, Exhibit.Expression._operators and friends? > > _______________________________________________ General mailing list [email protected] http://simile.mit.edu/mailman/listinfo/general
