* Setting up your local environment * Add the following to the appropriate connector in your tomcat's server.xml: URIEncoding="UTF-8" * Ensure that the Environment Variable "sf_ontologydir" is set and pointing to /path/to/project/ontology/ (in Eclipse: Run Configurations->Your Tomcat->Environment) * If you want to see other user's data in your local installation, change line 51 in EditDatabase.java to "Model myModel = factsDb.model;" * Threading model * There is just one big lock per user (the user's [source:trunk/skipforward/src/de/opendfki/skipforward/FactsDatabase.java FactsDatabase] instance); it's acquired immediately in [source:trunk/skipforward/src/de/opendfki/skipforward/ui/web de.opendfki.skipforward.ui.web] servlets. * If you create a background thread or something similar, make sure you get the lock * MVC * [source:trunk/skipforward/src/de/opendfki/skipforward/ui/web de.opendfki.skipforward.ui.web] servlets call [source:trunk/skipforward/src/de/opendfki/skipforward/ui 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 [source:trunk/skipforward/src/de/opendfki/skipforward/ui/beans de.opendfki.skipforward.ui.beans] * bean renderers can be found in [source:trunk/skipforward/src/de/opendfki/skipforward/ui/st 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 [source:trunk/skipforward/src/de/opendfki/skipforward/vocabulary de.opendfki.skipforward.vocabulary] * beans provide some convenience methods (e.g., getLabel(), etc.) * beans instances are built using [source:trunk/skipforward/src/de/opendfki/skipforward/FactsDatabase.java 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 * nb features are feature types such as "Name" or "Written by" - the full type is defined by the value(s) a feature instance uses then * keep in mind nb features may take multiple values per feature instance (e.g., "board game players: min X, max Y") * 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 is most likely a mistake.