concept for future magnolia (possibly 3.5) (MAGNOLIA-587)

[MAGNOLIA-761] Modules Created: 03/Mar/06  Updated: 17/Mar/09  Resolved: 15/Mar/06

Status: Closed
Project: Magnolia
Component/s: admininterface, core
Affects Version/s: None
Fix Version/s: 3.0 Beta 1

Type: Sub-task Priority: Major
Reporter: Philipp Bärfuss Assignee: Philipp Bärfuss
Resolution: Duplicate Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified

Issue Links:
relation
is related to MAGNOLIA-768 New Modules Mechanism Closed
Template:
Date of First Response:

 Description   

We have done the major step for modularizing magnolia. I would like go a step further before we release 3.0.

Goal


  • tie everything together (one jar per module)
  • slim webapp (only stuff which an enduser concerns about: templates, css)
  • easier development process

Changes
-------
A) Additional Bootstrap

  • A module has a bootstrap dir in the resources (during installation the content get's imported)

B) Templates , .. per module

  • Each module configuration has a dialog, paragraph, templates config (instead of registering them in the templating module)
  • The current templating module is renamed to samples

C) remove admindocroot and admintemplates

  • only the template and paragraph jsps and resources are extracted from the jar and written to the filesystem
  • the resources used in the admin interface are served by the resource servlet
  • NO jsps for the admin-interface (see below)

D) New module definition no longer in the manifest file

  • the definition is in an xml file META-INF/magnolia/xxx.xml
    --> during development one has not always a proper jar (with manifest)

E) subdir per module

  • docroot/module
  • templates/module
  • if a new version is installed the dirs get rewritten completely

NO JSP in the admin interfaces
______________________________
In future we will use JSF and FreeMarker. As a mid-step I would like to change the dialogpages (not the dialogs). We call them newly pages. The default page uses a template named like the classname. With this we can avoid the jsps in admintemplates. The module register it's pages (like we do currently for trees, ...) and a main servlet processes this pages.



 Comments   
Comment by Fabrizio Giustina [ 03/Mar/06 ]

some actions takes on C) remove admindocroot and admintemplates:
the new servlet that reads files directly from the classpath is ready: any file that is in a directory called "mgnl-resources" can be directly accessed using the path ".resources/" (for example "mgnl-resources/editor/sample.txt" can be accessed using http://server/context/.resources/editor/sample.txt").
Some of the admininterface files have been moved and the fckeditor resources are now in its own jar. Will go on moving all the other non-jsp files.

Comment by Philipp Bracher [ 03/Mar/06 ]

F) Restart after installation
The admin central shows a 'restart the system' message if a new module was installed

  • may be new servlets added
  • a new repository registerd in repositories.xml
  • ...
Comment by Philipp Bracher [ 13/Mar/06 ]

I have changed the following (not yet checked in):

Better initialization process:

  • ModuleRegistration
  • ModuleLoader

Module definition:

  • a module has a xml descriptor (definition, dipendencies, servlets, repositories, ...)

Default module:

  • can have and loads: dialogs, paragraphs, templates, trees, controls
    --> the content of one module (for example the samples module) is tied together now

Observation:

  • the managers inherit ObservedManager which handles the observation centralized (no
    registration of listeners everywhere)

Configurable:

  • ParagraphManager
  • TemplateManager
  • DialogManager
  • ControlsManager
    ...

Resources:

  • removed the admindocroot
  • some util methods to handle resources (in jars and classes dir)
Comment by Philipp Bracher [ 13/Mar/06 ]

and not to forget: killed a lot of static methods

Comment by Boris Kraft [ 13/Mar/06 ]

Did anybody ever think of uninstalling modules again?

  • if the installation itself breaks, we want to make sure that we leave no crap in the repositories etc (transactional installation?)
  • if we decide to remove a module, how can we also remove the entries made to repositories? Do we want to?

I think it would be nice to have something like a module section in adminCentral that shows installed modules and allows us to uninstall or install a module at runtime. How much overlapü is there with Ralfs new deployment mechanism?

Comment by Ralf Hirning [ 13/Mar/06 ]

Yes there is an overlap, but I would like to have both.

We can combine them and use packaging to install a module.
Just define packages holding the necessary files and repository entries. The module jar
would then only contain class files and typical java resouces.
It should even be possible to undeploy a module using packaging with proper package definition.

Deployment:
1. Install Module package
2. Restart Magnolia
3. Install repository package if you want to deploy entries to a new repository

It would be nice if we could omit the restart

Comment by Philipp Bracher [ 13/Mar/06 ]

I think it will take time to consolidate both. Therfore I propose to use the system as it is (with my changes and your packaging module) for the next relase.

Modules: for magnolia / modules developers

Packages: for templaters, system administrators, ...

I think both can provit from each other if we handle it clever enough.

the module mechanism brings:

  • lifecycle
  • content is tied together
  • descriptor
  • servlet registration
  • repository registration
  • for developing core components

The packaging brings:

  • interface for creation & administration of packages
  • versions
  • deploy /undeploy
  • no restart
  • for developing projects

Perhaps we should meet (virtual or real) after the next release to consolidate this

Comment by Philipp Bracher [ 15/Mar/06 ]

I commited the main code:

Lifecycle:

  • ModuleRegistration (checks dependencies)
  • ModuleLoader (initialization order follows dependencies)

Module Descriptor (betwixt used to read the modules xml descriptor):

  • ModuleDefinition
  • ServletDefinition
  • RepositoryDefinition

ObservedManager (reloading after a registered node changed)

  • ObservedManager
  • ParagraphManager
  • TemplateManager
  • DialogHandlerManager
  • ControlsManager
  • TreeHandlerManager
  • PageHandlerManager

Default Modoule Implementation: AbstractModule

  • bootsraps the fiels config.modules.name.* in the resource folder mgnl-bootsrap (additional files can be defined in the descriptor)
  • copy files to the filesysten from mgnl-content/templates/module and docroot/module (additional files can be defined in the descriptor)
  • registers servlets defined in the descriptor
  • registers repositories
  • set restartNeeded flag if a servlet or repository was registered
  • during the initialization all dialogs, paragraphs, templates, controls, trees and pages are registered by there manager

I will add subtasks to define the open points.

Comment by Philipp Bracher [ 15/Mar/06 ]

Is now MAGNOLIA-768

Generated at Mon Feb 12 03:20:25 CET 2024 using Jira 9.4.2#940002-sha1:46d1a51de284217efdcb32434eab47a99af2938b.