AEM Component Builder

In the current AEM world, there are way too often the situations when developers end up building new AEM components (and not use the core components).

The experience of building a new component is not very pleasant, prone to human mistakes due to the heavy ponderous coding. Working manually with the XML to define the dialogs makes the developer very often lose focus on the big picture and easy get lost into details about not forgetting to add the well-known <items> element, or to keep track of tabs, or to properly arrange dialog fields, or to make the dropdowns work (specially when we have multiple dependent ones) and so on. All becomes even more complicated when he needs to (also manually) add extra clientlibs having to careful when writing it and not add a typo. On top of this, he often needs to go on the Granite UI Foundation specification page to lookup for the component in question and see what is the overall structure, what attributes it accepts and what they do, and then come back in the XML and manually add what he needs.

Currently the Components tool (/libs/wcm/core/content/sites/components.html) is very poor. It is only giving you info data, not giving you much power to edit the component.

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.