001    package de.deepamehta.core;
002    
003    import de.deepamehta.core.model.AssociationDefinitionModel;
004    import de.deepamehta.core.model.IndexMode;
005    import de.deepamehta.core.model.TypeModel;
006    
007    import java.util.Collection;
008    import java.util.List;
009    
010    
011    
012    public interface Type extends Topic {
013    
014    
015    
016        // === Model ===
017    
018        // --- Data Type ---
019    
020        String getDataTypeUri();
021    
022        void setDataTypeUri(String dataTypeUri);
023    
024        // --- Index Modes ---
025    
026        List<IndexMode> getIndexModes();
027    
028        void addIndexMode(IndexMode indexMode);
029    
030        // --- Association Definitions ---
031    
032        Collection<AssociationDefinition> getAssocDefs();
033    
034        AssociationDefinition getAssocDef(String childTypeUri);
035    
036        boolean hasAssocDef(String childTypeUri);
037    
038        Type addAssocDef(AssociationDefinitionModel assocDef);
039    
040        /**
041         * @param   beforeChildTypeUri  the assoc def <i>before</i> the assoc def is inserted into the sequence.
042         *                              If <code>null</code> the assoc def is appended at the end.
043         */
044        Type addAssocDefBefore(AssociationDefinitionModel assocDef, String beforeChildTypeUri);
045    
046        /**
047         * Note: in contrast to the other "update" methods this one updates the memory only, not the DB!
048         * If you want to update memory and DB use {@link AssociationDefinition#update}.
049         * <p>
050         * This method is here to support a special case: the user retypes an association which results in
051         * a changed type definition. In this case the DB is already up-to-date and only the type's memory
052         * representation must be updated. So, here the DB update is the *cause* for a necessary memory-update.
053         * Normally the situation is vice-versa: the DB update is the necessary *effect* of a memory-update.
054         * <p>
055         * ### TODO: get rid of this peculiar situation and remove this method. This might be achieved by using
056         * the PRE_UPDATE_ASSOCIATION hook instead the POST_UPDATE_ASSOCIATION hook in the Type Editor module.
057         * On pre-update we would perform a regular {@link AssociationDefinition#update} and suppress further
058         * processing by returning false.
059         *
060         * @param   assocDef    the new association definition.
061         *                      Note: in contrast to the other "update" methods this one does not support partial updates.
062         *                      That is all association definition fields must be initialized.
063         */
064        void updateAssocDef(AssociationDefinitionModel assocDef);
065    
066        Type removeAssocDef(String childTypeUri);
067    
068        // --- Label Configuration ---
069    
070        List<String> getLabelConfig();
071    
072        void setLabelConfig(List<String> labelConfig);
073    
074        // --- View Configuration ---
075    
076        ViewConfiguration getViewConfig();
077    
078        // FIXME: to be dropped
079        Object getViewConfig(String typeUri, String settingUri);
080    
081        // ---
082    
083        TypeModel getModel();
084    
085    
086    
087        // === Updating ===
088    
089        void update(TypeModel model);
090    }