-
Notifications
You must be signed in to change notification settings - Fork 70
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Proposal: CobiGen as wizard #192
Comments
Nice, and good news: we are dreaming the same dream 👍
Although, the work on the code base of CobiGen is quite silent these days, we are working on the next generation features. I am pleased to hear, that we share the same mind set about that! |
Awesome 👍
Lets have a coffee next week together. I already implemented this for a telco-media customer ~9 years ago. It used some graph-theory algorithm but was after all not complex and easier than I though initially. |
Stale topic. Please negotiate closing or discussing the relevance of this ticket. |
Antoher visionary feature request for cobigen as there is such a high potential if you look further:
Just like Eclipse offers to create new class, interface or enum we should extend CobiGen to offer creation of new use-case, dialog, component, etc.
Then just enter the name of the "thing" to crate (or as required additional properties) and with a click on generate you have your new "thing" ready and working. Instead of existing Eclipse feature this will however not just create a single java file but an entire structure of packages with java files and potentially other types all defined by the templates behind this.
Even further CobiGen could offer refactoring of these "things". This would imply a reverse-mapping of the code to a template structure and back to the code. Then I could do a rename of a component that does not only rename a single file but the interface, implementation, instance variables, etc.
All tricky stuff I assume but this would really boost the developers performance and helps you to be more agile and flexible to changing demands.
Feel free to move this to an unplanned milestone with lower prio but we should IMHO have a workshop about the next-gen CobiGen and how it should be designed considering this and #164, #150 / #158, #123, #124, #157, #153, etc. We have to think far beyond the current implementation and design a new "template language" and "template configuration" that will support such use-cases and be highly maintainable. Then CobiGen templates will more or less become the architecture definition of your project. Maybe CobiGen core could also be reused to build an architecture analysis tool that "understands" if hand-written, generated or mixed code matches this defined architecture, render a high-level and clickable architecture of your code that allows to drill down. This way you would not only see tons of classes in packages but really components containing units (component-parts) with entity, UC, service, etc. around business data, etc.
If I am already dreaming you could also think about an architecture update just by getting a new release of the architecture definition (templates) and trigger the upgrade. But please do not get me wrong here. I have a strong vision but really want to go for the next step that brings us a working and usable solution better than what we have today. But you have to think big to take the small steps into the right direction.
The text was updated successfully, but these errors were encountered: