|
Have a built-in UI tool to design a component in a more visual way rather then manual XML work, that should do the following:
1. It can be integrated with the available Granite typical components for an easy drag and drop in the dialog design.
It can also provide easy access to each Granite component behavior, elements and so on. By having a visual drag-and-drop approach it can prevent developer for breaking the XML.
It can contain with hints and documentation tooltips, for ease of understanding and guidance for making best choices
2. It can provide a list of available clientlibs from project for selection
In this way it will prevent the developer to make typos and not properly link his component to the expected clientlib
3. It can better control granite data, renderconditions, granite classes, *-showhide-target etc
Having a holistic way across the entire dialog will avoid having inconsistencies or mismatches.
4. I can define component title, group, icon, initial field values and so on.
5. It might even allow developer to add a Readme.md file.
The readme would contain the component’s documentation (like usage instructions) which can later be used by the editors and developers alike.
6. It might even be able to run the component in isolation, before even include it in project.
Here there might be some potential constraints, considering component will run outside project context, so in the real project we might have slightly different results, but this a details left open to be clarified later on.
7. And it can also grow as a tool in the future, to add more component related features.
- For example the OOTB Component tool allows you to see where is the component used. But it can do much more, like for example to have an one click away button to update all component instances with the new updated version.
8. It might even had a integration feature with project’s github, so that the component could be directly committed to basecode, once is verified and approved.
Currently developers do this in two cumbersome-ish ways:
- either create a package, download it, unpack it and put the stuff in the project codebase
- or, when the component is already in project basecode, use aemsync to make manual changes on the component in their IDE and verify them in AEM afterwards
9. For now we can keep the HTL out of this tool, even if this could potentially be handled here as well.
------------------------------------------------------------------------------------------------------------------
The solution is not refined in depth, so there is a lot of room to change the idea. But the whole point is that we need a better, safer, easier and faster way to create AEM components.
|
