* UI zum Bearbeiten von Personen angepaßt
* ContactEntryType verwendet nun RelationAttribute für die Typisierung
Diverse kleine Änderungen
git-svn-id: https://svn.libreccm.org/ccm/trunk@598 8810af33-2d31-482b-a856-94f89814c4df
So... jetzt sollten die Link-Attribute auch bei Links zwischen top-level ContentItems übernommen werden.
git-svn-id: https://svn.libreccm.org/ccm/trunk@589 8810af33-2d31-482b-a856-94f89814c4df
Habe den Fehler endlich gefunden... Es lassen sich jetzt Contact zu Personen hinzfügen.
git-svn-id: https://svn.libreccm.org/ccm/trunk@586 8810af33-2d31-482b-a856-94f89814c4df
* angepasste Spaltennamen zum Debuggen. Es gab einfach zuviele Spalten mit der Bezeichnung key
RelatedLink
* linkListName hinzufügt. Ist noch nicht vollständig... denke ich.
GenericPerson
* NullPointer Exception im PageCreate gelöst
* NotNullValidationListener zum Feld Nachname hinzugefügt
git-svn-id: https://svn.libreccm.org/ccm/trunk@581 8810af33-2d31-482b-a856-94f89814c4df
* Ab jetzt abgeleitet vom DomainObject, dadurch hatt man keine Abhängigkeiten mehr zu der ACSObject- und anderen Tabellen. Man kann die Tabelle nun einfach per pgAdmin3 füllen.
* NullPointer -Exception gefunden und entfernt. getRelationAttribute prüft nun, ob die Collection noch vor dem ersten Element steht.
git-svn-id: https://svn.libreccm.org/ccm/trunk@580 8810af33-2d31-482b-a856-94f89814c4df
- JavaDoc für ccm-sci-types-organization
- SciMember Type zu ccm-sci-types-organization hinzugefügt (abgeleitet von GenericPerson)
- GenericOrganizationalUnitPersonAddForm so angepasst, dass der Typ der anzuzeigenden Personen beschränkt werden kann (durch überschreiben einer Methode)
- CLI-Tool zum importieren von RelationAttributes als Übergangslösung, bis es eine GUI gibt.
git-svn-id: https://svn.libreccm.org/ccm/trunk@571 8810af33-2d31-482b-a856-94f89814c4df
aber im jeweiligen Objekt gespeichert. Das Formular kann durch Erstellen einer abgeleiteten Klasse mit einem einfachen Konstruktor und drei überschriebenen
Methoden verwendet werden (s. JavaDoc).
- SciProjectDescriptionUploadForm ist jetzt von AbstractTextUploadForm abgeleitet.
git-svn-id: https://svn.libreccm.org/ccm/trunk@569 8810af33-2d31-482b-a856-94f89814c4df
* Abgeleitet von ACSObject
* Diverse Anpassungen
* Kopiliert, ist aber noch nicht vollständig
git-svn-id: https://svn.libreccm.org/ccm/trunk@565 8810af33-2d31-482b-a856-94f89814c4df
* Titel und Name wird nun synchron zu den Daten gehalten.
* Ein paar kleine Fehlerkorrekturen
git-svn-id: https://svn.libreccm.org/ccm/trunk@564 8810af33-2d31-482b-a856-94f89814c4df
* public static ContentTypeCollection getSiblingsOf(ContentType ct) hinzugefügt, aber noch nicht getestet. Evt. funktioniert der Filter noch nicht richtig.
git-svn-id: https://svn.libreccm.org/ccm/trunk@563 8810af33-2d31-482b-a856-94f89814c4df
* RelatedLinks bzw. Links so erweitert, daß man den gewünschten CT angeben kann
git-svn-id: https://svn.libreccm.org/ccm/trunk@562 8810af33-2d31-482b-a856-94f89814c4df
* neuer, eigener CreateStep erzeugt (GenericPersonCreate). Von GenericPerson abgeleitete CTs müssen diese Klasse als createComponent in der AuthoringKit-XML-Datei eingetragen, damit der Name und der Titel des CIs automatisch erzeugt werden.
* Eintrag für Geschlecht hinzugefügt.
Member
* creationComponent geändert
git-svn-id: https://svn.libreccm.org/ccm/trunk@560 8810af33-2d31-482b-a856-94f89814c4df
- Neues Modul mit Contenttypen für wissenschaftliche Einrichtungen (noch nicht fertiggestellt)
git-svn-id: https://svn.libreccm.org/ccm/trunk@543 8810af33-2d31-482b-a856-94f89814c4df
* Initialisierung von
* Portlet
* LifeCycle
* publishToFile
ist komplett in einen eigenen, neuen Initializer verlegt.
* Initialisierung content-section ist auf Loader und Initializer neuen Typs verlegt.
* Initialisierung von content-center und cms-service ist in Initializer neuen Typs verlegt.
* Legacy Init wird nur noch im Rahmen der Initialisierung von Forms durch ccm-core benutzt.
Es funktioniert (noch) nicht (wieder):
* Background Thread fuer Alerts
* Erstellen weiterer Content Section bei einem restart via Parameter.
git-svn-id: https://svn.libreccm.org/ccm/trunk@509 8810af33-2d31-482b-a856-94f89814c4df
This bug causes the ItemSearch popup not to close when an item was selected.
git-svn-id: https://svn.libreccm.org/ccm/trunk@504 8810af33-2d31-482b-a856-94f89814c4df
- trunk/ccm-cms/src/com/arsdigita/cms/contenttypes/GenericPerson.java: Changed type for birthdate accessors from String to java.util.Date
- trunk/ccm-cms/src/com/arsdigita/cms/contenttypes/ui/GenericPersonPropertyForm.java: Changed start and end year of the date widget to 1900 (start) and the current
year (end)
- trunk/ccm-cms/src/com/arsdigita/cms/contenttypes/ui/GenericOrganizationalUnitPersonAddForm.java: Fixed error in the EditCellRenderer.
git-svn-id: https://svn.libreccm.org/ccm/trunk@496 8810af33-2d31-482b-a856-94f89814c4df
* Alle Konfigurations Parameter aus enterprise.init sind in neuen Konfigurationsdateien
* Ausnahme: Initialisierung Formbuilder, was durch ccm-core erfolgt.
* Die meisten Konfigurationsparameter liegen in c.ad.cms.LoderConfig.java
* Komplizierte Parameterlisten wie die Rollen im Content-Center sind noch hart codiert.
* Alter portlet initializer aufgeteilt in loader und initializer neu
* Alter sectioninitializer als Zwischenlösung ausgegliedert in SectionLegacyInitializer
* ~/xml/ContentTypeInitilizer verlegt in loader
* ~/installer/Initializer ersetzt durch Initializer neuen Typs.
Als neuer Fehler ist aufgetaucht, dass einige Keys im Content-Center nicht lokalisiert werden.
git-svn-id: https://svn.libreccm.org/ccm/trunk@471 8810af33-2d31-482b-a856-94f89814c4df
* Tabelle für Kontaktarten eingeführt - hat allerdings noch einen unschönen Namen (GenericContactType) was eigentlich GenericContact - Type bedeuten sollte, aber wahrscheinlich als Generic - ContentType interpretiert wird.
* Erste Version von GenericOrganization.pdl
git-svn-id: https://svn.libreccm.org/ccm/trunk@466 8810af33-2d31-482b-a856-94f89814c4df
* XML-Dateien hinzugefügt, damit die BaseTypes in die Tabelle content_types geladen werden und als interne Typen gekennzeichnet sind
* Euinige Fehlerkorrekturen an den UIs
ContentTypes
* Klasse ContentType und Tabelle content_types erweitert um Felder für ancestors und siblings um die Vererbungshierachie speichern zu können
* AbstractContentTypeLoader um Methode createPedigree erweitert, die aus der Verebungsstruktur der Klassen die Hierarchie ableitet und in der Datenbank speichert
* ItemSerachWidget angepaßt, so daß es nun auch abgeleitete Contenttypen akzeptiert. Es werden nun z.B. auch CT's von Type contenttypes.Member angezeigt und als Zuweisung akzeptiert, wenn nach dem Vaterobject basetypes.Person verlangt wird.
git-svn-id: https://svn.libreccm.org/ccm/trunk@438 8810af33-2d31-482b-a856-94f89814c4df
Kompiliert und läßt laden und starten, alledings gibt es eine Exception beim Anlegen eines neuen BaseContacts
BaseContacts so angepaßt, daß es den basetype verwendet.
git-svn-id: https://svn.libreccm.org/ccm/trunk@436 8810af33-2d31-482b-a856-94f89814c4df
* Die Konfigurations-Parameter waf.categorization.supported_languages und com.arsdigita.cms.languages zu waf.kernel.supported_languages zusammengefasst
* In DispatcherHelper eine Methode getNegotiatedLocale eingeführt, die beim Aushandeln der Locale zwischen Browser und CCM auch dem Konfigurations-Parameter waf.kernel.supported_languages respektiert
* Alle Aufrufe von DispatcherHelper.getRequest().getLocale() auf die neue Methode DispatcherHelper.getNegotiatedLocale() geändert.
* Konfiguration von Categorization geändert. Verwendet jetzt keinen eigenen Eintrag für die unterstützten Sprachen mehr. Stattdessen wird die Konfiguration von Kernel verwendet.
* ContentSectionInitializer geändert, so daß er nun Kernel.getConfig().getSupportedLanguages() verwendet.
Außerdem diverse Aufräumarbeiten (Unnötige Imports entfernt, Reformat, Annotationen hinzugefügt, Klammern bei If-Anweisungen) in den Sourcen, wo immer sie mir in die Händegefallen sind.
git-svn-id: https://svn.libreccm.org/ccm/trunk@419 8810af33-2d31-482b-a856-94f89814c4df
2. Versuch. Warum hat er das letzte Mal nicht eingecheckt?
* Angepaßte CreatePage, so daß die neuen Elemente nicht direkt bei der Erstellung abgefragt werden
* AddElement wurde so angepaßt, daß man nur optionale Elemente anlegen kann
* Mist.remove funktionsfähig gemacht
* ObjectType um remove-Methode erweiterert
Jetzt sollte der UDCT soweit funktionsfähig sein, daß er verwendbar wird. Es lassen sich neue Elemente ablegen und löschen. Es lassen sich neue CT anlegen und löschen.
git-svn-id: https://svn.libreccm.org/ccm/trunk@346 8810af33-2d31-482b-a856-94f89814c4df
* Angepaßte CreatePage, so daß die neuen Elemente nicht direkt bei der Erstellung abgefragt werden
* AddElement wurde so angepaßt, daß man nur optionale Elemente anlegen kann
* Mist.remove funktionsfähig gemacht
* ObjectType um remove-Methode erweiterert
Jetzt sollte der UDCT soweit funktionsfähig sein, daß er verwendbar wird. Es lassen sich neue Elemente ablegen und löschen. Es lassen sich neue CT anlegen und löschen.
git-svn-id: https://svn.libreccm.org/ccm/trunk@332 8810af33-2d31-482b-a856-94f89814c4df
Durch Einführung und Verwendung von ContentItemXMLRenderer weerden ContentBundles bei der Erzeugung der XML-Ausgabe zur ausgehandelten Sprache aufgelöst und statt des ContentBundles dieses neue Objekt ausgeben.
Es ist eine API-Änderung nötig gewesen: in DomainObjectTraversal.java mußte die walk()-Methode protected markiert werden.
(Dateien vergessen hinzuzufügen.)
git-svn-id: https://svn.libreccm.org/ccm/trunk@321 8810af33-2d31-482b-a856-94f89814c4df
Durch Einführung und Verwendung von ContentItemXMLRenderer weerden ContentBundles bei der Erzeugung der XML-Ausgabe zur ausgehandelten Sprache aufgelöst und statt des ContentBundles dieses neue Objekt ausgeben.
Es ist eine API-Änderung nötig gewesen: in DomainObjectTraversal.java mußte die walk()-Methode protected markiert werden.
(Dateien vergessen hinzuzufügen.)
git-svn-id: https://svn.libreccm.org/ccm/trunk@320 8810af33-2d31-482b-a856-94f89814c4df
Durch Einführung und Verwendung von ContentItemXMLRenderer weerden ContentBundles bei der Erzeugung der XML-Ausgabe zur ausgehandelten Sprache aufgelöst und statt des ContentBundles dieses neue Objekt ausgeben.
Es ist eine API-Änderung nötig gewesen: in DomainObjectTraversal.java mußte die walk()-Methode protected markiert werden.
git-svn-id: https://svn.libreccm.org/ccm/trunk@319 8810af33-2d31-482b-a856-94f89814c4df
Es sollte ebenfalls noch mit den alten Inhalten in der DB funktionieren, allerdings wird dann keine Sprachvariante ermittelt (altes Verhalten).
Problematisch kann sein, daß Links nun automatisch in eine andere Sprachversion wechseln, falls die gewünschte Variante nicht vorhanden ist. Ich bin mir noch nicht sicher, ob die Standardversion des ContentItems zurückgegeben wird, wenn keine Übereinstimmung gefunden werden kann, oder ob der Link dann entfällt.
git-svn-id: https://svn.libreccm.org/ccm/trunk@265 8810af33-2d31-482b-a856-94f89814c4df
- Display of information about index items is now more informative and accurate
- Upload option can now be turned off for text assets
using com.arsdigita.cms.hide_text_asset_upload_file configuration property
- Can hide the action for creating a content item from the content sections list
- Users were adding brackets () to the Name field of a content item in basic
properties resulting in "page not found" error when you try to open the
published item
git-svn-id: https://svn.libreccm.org/ccm/trunk@254 8810af33-2d31-482b-a856-94f89814c4df
Dieser Code ist jedoch ein wenig seltsam. Ich werde jetzt Multipartarticle analysieren und GenericOrganization auf dieser Basis anpassen. Auf den ersten Blick
schein der Code für die Verknüpfung zwischen dem Multipartarticle und seinen Sections einfacher zu verstehen zu sein (und wahrscheinlich auch sauberer...)
git-svn-id: https://svn.libreccm.org/ccm/trunk@181 8810af33-2d31-482b-a856-94f89814c4df
quasi
jensp
pb