You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 17 Next »

 

This document relates to the "Lower the Entry Barrier" initiative, codenamed "Ramp".

Please see child pages as well for larger concepts.

Here I will go into more detail about some of the concepts. These will probably be broken into individual documents.

Concepts to cover:

  • Template & Resource Loading Cascade
  • Inplace editing of Templates & Resources: Access filesystem
  • Config By File: Configuration & Bootstrap improvements
    • Work with config more like templates & resources.
    • JCR Document View or JSON. Autoloading. Autoexporting
    • Maybe it works like code in that it creates a dynamic configuration every time - not a permanent change to the configuration tree.
  • Better Javascript handling.
  • ConfigTree improvements. Extends insight. Template Extender tool.
  • Enable frontend developers to create apps & fields with templates.

References

STK 2.0 Workshop

http://wiki.magnolia-cms.com/download/attachments/42270723/stk-remarks-vpro.pdf

Template & Resource loading cascade & Filesystem loading

Templates & Resources (and any other file assets) should be treated equivalently where possible.

Current problems

  • Resources in repo are used by default (While templates in classpath are used by default)
  • Its hard to get Resources into the repo. (reinstall). Adding new resources must be easy.
  • Developers prefer to work on resources in the file-system - they are using IDE's.
  • Storing templates in modules requires a java development environment.

Proposal

In order to stay flexible and support different use cases - system should implement a "loading cascade": loading things in a specified way from a specified series of locations
By default, Templates/Resources should be loaded in the following order. Items loaded later override the previous ones. The order goes from least flexible to most flexible.

  1. Modules (classpath).
  2. Directory on the filesystem.
  3. Repository that have "override" box checked.
    1. A master configuration item causes all items from repository to override.

(Alternatively, perhaps the mechanism only loads templates/resources that are not yet defined, instead of overwriting as defined above, in which case the default order would be reversed.) 

Filesystem loading

  • System should watch all files in configured directory and when changed
    • reload them in the system
    • add them to the repository, reload them to the repository

Questions:

  • How to handle theme images?
  • Would GIT be a fourth option for a loading cascade? Could be -  but people could just use normal git to sync things on the filesystem. So maybe only the filesystem option is necessary.

To consider -

  • maybe things should actually not be loaded to repository. This means you cannot do a clean uninstall.
  • Should templates and resources really be loaded to separate locations in separate workspaces? What is the advantage of having these things scattered, instead of together?


Inplace editing of Templates & Resources: Access filesystem

What if nothing was stored in repository?: Not templates or resources?

  • Templates and resources do not get stored in repository.
    • Admincentral apps load the files from filesystem for display.
    • inplace editing - edits the files directly. (In exploded War)

That does not work for JARS, the files cannot be written to.


ConfigByFile - Autowrite to File on ConfigTree edits.

If writes to the configTree were automatically written back to the ConfigFile - that would solve problem of loosing changes made in adminCentral.
But how would the system know to which file to write?
And how would it know when to write given the likely situation that some configuration is defined by File, but some is loaded from Bootstraps?

Proposals for Consideration: (How to find file)

  • Filename is written as a property to the root node of the configuration it represents. So on change, it can walk down the tree till it finds the filename (or flag).
  • Unlike bootstraps, ConfigFiles always start at a specific level. There is a separate file for each app, each dialog, and the basic "config" node for a module. As this is set - its easy for the system to generate the filepath of the file and check if it exists.
  • All files are scanned to find matching file.


Questions

If a user makes a ConfigTree change to a node that is not created by ConfigByFile, does system create a file for this manual change?

If a user makes a ConfigTree change to a node that is created by ConfigByFile, but by another module - it's not correct that this change be written to the file of another module. If anything it should just be written to the "project module". As the project module has super dependencies, its always loaded last and so its ConfigFiles would be applied last, mimicking the manual change.

 

HTML Modules

This means a few things.

  • In AdminCentral, you can create a module. Why? - a place to store your configuration of new apps etc.
  • On the filesystem, you can populate a directory - and all contents of that directory are loaded and treated similar to a module - dependencies, etc (what else explicitly?)

How could that work? Maybe there is actually one java module which is a container for all of the "dynamic" "javafree modules".

What does the filesystem structure look like? It should probably match existing configuration and in-module file structures as closely as possible.

  • There is one root directory where the running system looks for these filesystem based modules. The filepath is configurable.
  • Each subdirectory is considered as a module. Each subdirectory contains an module.xml file which acts like a pom file, declaring dependencies and version. It or another file also act as module descriptor.
  • ....

 

Javafree Template

What would the file structure be for a component template stored in a directory. 
templateName.xml could be the template definition that ties everything together.

But if everything follows conventions, is this file actually necessary? If the directory holds a template script, a dialog configuration, a model, resources - then we dont need an xml file to redundantly point to all of these things again. Less boilerplate. Less chance to write something wrong.

  • Dir: myYoutubePlayer
    • myYoutubePlayer.ftl
    • myYoutubePlayerDialog.xml
    • myYoutubePlayerModel.js
    • resources
      • whatever.css
      • whatever.png
      • whatever.svg
      • whatever.js
      • whatever_en.properties
      • libs
        • superyoutube
        • parquetteLayout


  • No labels