View ==== Conceptualization ----------------- The MyCoRe-directory (*src/main/resources*) contains all code needed for rendering the data to be displayed on the screen. So this corresponds to the view in an MVC approach. It is done by xsl-files that (unfortunately) contain some logic that really belongs to the controller. Thus, the division is not as clear as implied in theory. I will point at this issue more specifically in the relevant subsection below. Among the resources are all images, styles, and javascripts. Implementation -------------- The view component handles the visual representation in the form of an interface that allows interaction between the user and the task to be carried out by the machine. As a webservice in the present case, all interaction happens via a browser, i.e. webpages are visualized and responses are recognized by registering mouse or keyboard events. More specifically, a webpage is rendered by transforming xml documents to html pages. The MyCoRe repository framework uses an open source XSLT processor from Apache, `Xalan `_. This engine transforms document nodes described by the XPath syntax into hypertext making use of a special form of template matching. All templates are collected in so called xml-encoded stylesheets. Since there are two data models with two different structures, it is good practice to define two stylesheet files one for each data model. As a demonstration, in the listing below a short extract is given for rendering the word data. .. code-block:: xml :caption: word data rendering in morphilo.xsl :name: morphilo.xsl

... ... ... ... This template matches with the root node of each *MyCoRe object* ensuring that a valid MyCoRe model is used and checking that the document to be processed contains a unique identifier, here a *MyCoRe-ID*, and the name of the correct data model, here *morphilo*. Then, another template, *objectAction*, is called together with two parameters, the ids of the document object and attached files. In the remainder all relevant information from the document is accessed by XPath, such as the word and the lemma, and enriched with hypertext annotations it is rendered as a hypertext document. The template *objectAction* is key to understand the coupling process in the software framework. It is therefore separately listed in :ref:`objActionTempl`. .. _objActionTempl: .. code-block:: xml :caption: template ObjectAction :linenos: :emphasize-lines: 7, 15, 19
The *objectAction* template defines the selection menu appearing -- once manual tagging has started -- on the upper right hand side of the webpage entitled *Annotieren* and displaying the two options *next word* or *back to project*. The first thing to note here is that in line 7 a simple test excludes all guest users from accessing the procedure. After ensuring that only the user who owns the corpus project has access (line 15), s/he will be able to access the drop down menu, which is really a url, e.g. line 19. The attentive reader might have noticed that the url exactly matches the definition in the *web-fragment.xml* as shown in listing :ref:`webxml`, line 17, which resolves to the respective java class there. Really, this mechanism is the data interface within the MVC pattern. The url also contains two variables, named *derivCorp* and *corpID*, that are needed to identify the corpus and file object by the java classes (see section :ref:`controller-section`). The morphilo.xsl stylesheet contains yet another modification that deserves mention. In listing :ref:`derobjectTempl`, line 18, two menu options -- *Tag automatically* and *Tag manually* -- are defined. The former option initiates ProcessCorpusServlet.java as can be seen again in listing :ref:`webxml`, line 7, which determines words that are not in the master data base. Still, it is important to note that the menu option is only displayed if two restrictions are met. First, a file has to be uploaded (line 19) and, second, there must be only one file. This is necessary because in the annotation process other files will be generated that store the words that were not yet processed or a file that includes the final result. The generated files follow a certain pattern. The file harboring the final, entire TEI-annotated corpus is prefixed by *tagged*, the other file is prefixed *untagged*. This circumstance is exploited for manipulating the second option (line 27). A loop runs through all files in the respective directory and if a file name starts with *untagged*, the option to manually tag is displayed. .. _derobjectTempl: .. code-block:: xml :caption: derobject template :linenos: :emphasize-lines: 18,19, 27 ...
    |\label{ln:morphMenu}| |\label{ln:1test}| |\label{ln:2test}|
    • |\label{ln:loop}|
    • ...
Besides the two stylesheets *morphilo.xsl* and *corpmeta.xsl*, other stylesheets have to be adjusted. They will not be discussed in detail here for they are self-explanatory for the most part. Essentially, they render the overall layout (*common-layout.xsl*, *skeleton_layout_template.xsl*) or the presentation of the search results (*response-page.xsl*) and definitions of the solr search fields (*searchfields-solr.xsl*). The former and latter also inherit templates from *response-general.xsl* and *response-browse.xsl*, in which the navigation bar of search results can be changed. For the use of multilinguality a separate configuration directory has to be created containing as many *.property*-files as different languages want to be displayed. In the current case these are restricted to German and English (*messages_de.properties* and *messages_en.properties*). The property files include all *i18n* definitions. All these files are located in the *resources* directory. Furthermore, a search mask and a page for manually entering the annotations had to be designed. For these files a specially designed xml standard (*xed*) is recommended to be used within the repository framework.