xp
xp copied to clipboard
Text component 2.0
Current text component implementation poses several problems and is not flexible enough
- It is always available (not everyone wants/need this in their setup)
- It is not possible to configure it in any way
- It uses built-in/default rendering (though this is possible to override with some tricks)
- In some cases, editing directly on the page may not really work (styles, processing of markup etc)
Solution: Treat text component similar to other components
- In app, introduce a new folder resources/site/text
- To allow use of text component on a page, minimum one app must implement it
- An app can implement multiple text components (ala parts)
- when inserting text component, one must choose which (but only if multiple are available)
- Each text component will have a form (like part)
- Additionally, the component XML must support a text element, for tuning the built-in "htmlarea" (similar to a regular htmlarea)
- Developers must provide their own controller to render the text component, just like a part
- Finally, consider how we to support editing without "full wysiwyg", i.e. meaning we simply place an Iframe with the editor on the page, rather than editing directly on the page with styles etc.
- Ofc, this also means we must persist information about which text component is being used
Backward compatibility
- We should also provide an app that can be added to sites, basically providing backward compatibility with current system-provided text component.
- Consider if this can be implemented pre xp8 or not?