Sling CMS / component framework

[Sandro Boehme <sa...@gmx.de>]

Hello Sling developers,

thanks again for your feedback on my last question (Would you use the 
CMS or do you know someone who would?). It was very good to have! It 
made me recognize that interest in a Sling CMS is limited (showcase for 
Sling and use cases of Ondrej).

This is why I would be more than happy if you can tell me if it would be 
useful in the phase before. When it can not yet be used as a CMS without 
a developer as there are no components at the marketplace.
This is the phase when it has to be useful for developers that create 
individual websites based on a web framework (like Sling).
I think that it would be useful for them, to have a frontend component 
framework on top of Sling that adds only minimum overhead and also 
provides tooling to actually (re-)use the components on a page and share 
them (for free or for sale) at the marketplace.

++ The Page Editor is not needed ++
o Also with an other editor other code can be added to the page and the 
component can be moved around and deleted without problems. For adding a 
component without the Page Editor one has to make sure that its id is 
unique at the page. This will be easier after the implementation allows 
to use textual ids (not done yet).

o One can work on a page with the Page Editor tool and the IDE or 
texteditor interchangeably.

++ Page Editor ++
The wysiwyg Page Editor allows to move frontend components from a 
toolbar to a page and to move them around on a page. If there are nested 
pages it can also move components from page to page while managing the 
uniqueness of the component id. The icons (move, delete, edit) and other 
HTML, CSS and JavaScript code is not persistent at the page it is added 
to the page at runtime instead. This way no preview code has to be 
removed later on.
The Page Editor also contains a universal editor for the component 
content. There the user can enter the content in child resources and 
properties that the component needs.

++ HTML frontend component API ++
To have a HTML component that needs no data access only three simple 
changes need to be made to the HTML block:
1. Additional "component" css class.
2. Additional "data-component-type='component-type-name'"
3. Additional "data-component-id='1234'"

++ JavaScript frontent component API ++
To use JavaScript to access the content of the component the previous 
changes need to be made and the JavaScript API can be used to read the 
component content the user entered via JSON from the server.

++ JSP API ++
The component code can be wrapped with a custom tag that provides the 
page context attribute "componentResource". It is the root that contains 
the content the user entered for the component and can be used in JSP 
based components.

++ Sightly API ++
It is still work in progress and current tests make me confident that 
the API will also be straightforward.

++ page structure ++
The usual resource (super) type script resolution process and the 
include mechanisms are used to reuse pages. Components are also used for 
structuring and nesting components within a page. A css class 
"container" within a component defines a placeholder to drop other 
nested components.

++ frontend dependency management ++
This is work in progress. It should be possible to optionally define 
frontend packages (like jQuery, Bootstrap,...) as component dependencies 
in a package.json (similar to npm) and get these dependencies including 
their transitive dependencies resolved, downloaded and installed on the 
fly. Current tests show that it's possible using JSPM.

++ bundle dependencies ++
It should be possible to define OSGi bundles in the package.json as 
dependencies as well. That is still part of the backlog.


Does that motivate you to use it and to you know of others who would use it?

Thanks for reading,

Sandro