* 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
quasi
jensp
pb