[MAGNOLIA-68] Packaging of repository content Created: 21/Aug/04 Updated: 10/May/05 Resolved: 10/May/05 |
|
| Status: | Closed |
| Project: | Magnolia |
| Component/s: | core |
| Affects Version/s: | 2.0 Final |
| Fix Version/s: | 2.1 Final |
| Type: | Improvement | Priority: | Minor |
| Reporter: | Ralf Hirning | Assignee: | Sameer Charles |
| Resolution: | Fixed | Votes: | 10 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Template: |
|
| Acceptance criteria: |
Empty
|
| Task DoD: |
[ ]*
Doc/release notes changes? Comment present?
[ ]*
Downstream builds green?
[ ]*
Solution information and context easily available?
[ ]*
Tests
[ ]*
FixVersion filled and not yet released
[ ] 
Architecture Decision Record (ADR)
|
| Date of First Response: |
| Description |
|
Definition/configuration of templates and paragraphs are stored in the If I create a new template/paragraph, I have a The transfer from author to public could eventually be done via activation (not implemented yet). |
| Comments |
| Comment by Boris Kraft [ 12/Oct/04 ] |
|
Anything that is stored in the repository can eventually be activated. This is not only true for intra-environment but also for inter-environment. You should be able to publish as follows: dev authoring -> dev public -> test authoring & test public -> prod authoring & prod public "->" means a subscription relationship. Templates are currently not stored in the repository, and therefore manual interaction is still needed. Storing the templates in the repository would additionally version them, which would be pretty cool. Anyhow, the ability to package a template in its entirety would certainly be very valuable, as it could also be used as a distribution mechanism for templates. Imagine that you can download a template (a set of pages, paragraphs, jars, maybe modules) and install them through the Magnolia GUI. This in turn would require a mechanism to manage templates an a higher level, which currently we do not have. |
| Comment by Bert Schulzki [ 15/Dec/04 ] |
|
But Replication is not possible, if the production author environment is behind a multi-zone firewall. But as supporting such (common!) environments be essential, there must be a way for offline replication of content and configuration. |
| Comment by Ramon Buckland [ 16/Dec/04 ] |
|
Export and import of config, content and users could be handled It could be managed on the Gui with two extra "menu items on the drop down of |
| Comment by Michael Aemisegger [ 17/Dec/04 ] |
|
It would be nice if the visibility of context menu was configurable. We could introduce some sort of context menu configruation in the config admin section and allow/deny access to a particular context menu for specified roles through acl. For example, the superuser is allowed to perform all context menu operations, an editor in the role 'editor' would not see the conext menu entry for "Import node ..." / "Export node ...". |
| Comment by Jaume Moral [ 18/Jan/05 ] |
|
I think that export/import from GUI will be fine, but a external tool to "dump" the whole repository or a part of it into a xml file will be very useful too. I'm thinking in a tool like import/export in some databases. In Oracle, for instance, they are used to move data between non connected databases, a feature that I miss in Magnolia repository. I think that manage JSP templates is not a priority. The prority is the data inside the repository. |
| Comment by Stefan Frank [ 18/Jan/05 ] |
|
If I'd make up a wishlist for magnolia, this would be on top: The configuration for the model for Templates and paragraph are currently stored in the repository only and can only be edited via the browser interface. This makes the editing-process quite painful. Some attributes are reserved(like name, type, controlType) although the values are not checked. The presence of required attributes is also not checked (is it at least documented somewhere, apart from the samples?). Having an xml-config-format and a corresponding xsd, that makes sure, that only valid template, dialog and paragraph definitions enter the repository would make my life easier: I could use an external tool to build my model and then import it. This would also make deployment easier: If I understand it right, "deployment" only works from the admincentral (by using activate) - which is a labourous task and cannot easily be repeated and automated. As activation only works on branches, you have to manually reconstruct deployment units of dialogs, paragraphs and templates that belong together and have to be "activated" together. Having xml-config-files as a unit of deployment would solve this issue... |
| Comment by Andreas Weder [ 18/Jan/05 ] |
|
Stefan, I second your comment. |
| Comment by Sameer Charles [ 10/May/05 ] |
|
xml export on tree view implemented by fabrizio |