• Threading model
  • There is just one big lock per user (the user's FactsDatabase instance); it's acquired immediately in de.opendfki.skipforward.ui.web servlets.
  • If you create a background thread or something similar, make sure you get the lock
• MVC
  • de.opendfki.skipforward.ui.web servlets call de.opendfki.skipforward.ui class methods; these build views (using custom beans, typically), build HTML using StringTemplate, and return the HTML
  • there are some MVC helper beans (not to be confused with the RDF beans) in de.opendfki.skipforward.ui.beans
  • bean renderers can be found in de.opendfki.skipforward.ui.st
    • these renderers are used for basic types or if Java code is needed for generating the HTML - otherwise, normal templates are used.
• RDF Beans
  • interfaces are in de.opendfki.skipforward.vocabulary
  • beans provide some convenience methods (e.g., getLabel(), etc.)
  • beans instances are built using FactsDatabase methods
  • beans are throwaway objects and do not have any internal state - every change using their setters is immediately persisted in RDF
  • beans are associated with their corresponding FactsDatabase so you cannot pass one bean instance to another user
• non-binary features
  • non-binary features are somewhat nasty to handle since their (rather generic) feature type isn't very helpful ("Name") - you need a feature instance to know the full type ("Name: Miller")
  • when comparing feature types for equality, you should use feature123.getFeatureTypeId() instead of feature123.getFeatureType().getUri() - the ID is the feature type URI plus added values ("Miller" in the example above)
  • same for getting labels: feature123.getFeatureType().getLabel() is not very helpful (again, "Name") - use feature123.getFeatureTypeLabel() instead.
  • thus, writing code that uses something like Map<FeatureType, ...> is most likely a mistake.