OK I would say that the toughest ones are C++ and golang, and the myriad of java server frameworks. They all change folder structures, class structures, and most of the grouping of all operations depending on logic in the structure, rather than a template structure.
> On Jan 29, 2017, at 7:12 AM, sstein...@gmail.com wrote: > > Hi, can you possibly point me at the worst current case you can think of off > the top of your head i.e. where output varies depending on data? The simple > case is really straightforward; I'm working with the flaskConnexion at the > moment. > > Regardless of the edge cases, it seems to me that an awful lot of the > boilerplate could be replaced with a very small handful of utility functions > accepting lists (defaults for the language, from the configuration file, or, > worst case, declared in the code). > > The trigger issue for me, is that I want to change some of the non-standard > conventions used in the flaskConnexion template and I can't even rename a > file without having to clone (bleh!) the Java code and template files and > build an entirely new module. > > This is not optimal for many reasons I won't insult you by enumerating. > > Thanks, > > ssteinerX > > On Sunday, January 29, 2017 at 9:42:55 AM UTC-5, tony tam wrote: > Hi, I do agree the structure is a bit complicated. The challenge is that we > support many different languages and targets, each with their own > idiosyncrasies. It’s really impossible to have a standard structure. For > example, the output filenames vary in structure depending on the contents of > the data. > > That said, there’s many places to improve this, and maybe you have an idea > that hasn’t been tried yet. So please share what you’re thinking in more > detail. > >> On Jan 29, 2017, at 6:10 AM, sste...@ <>gmail.com <http://gmail.com/> wrote: >> >> Thanks, Tony. >> >> I have looked at that. >> >> From what I can gather from reading a bunch of the generators, the usual >> methodology involves lots of code and very little in the way of convention. >> >> For example, every file in the template has to be explicitly referenced in >> the Java file instead of iterating over a template directory. Also, the >> Java code has to specify the name of each output file to be generated rather >> than relying on a convention such as using filename.extension.mustache to >> generate filename.extension from the Mustache template file automatically. >> >> This could lead to the elimination of almost all the Java code in each >> generator as well as the ability to extend them easily which is virtually >> impossible now without modifying the Java code (e.g. to add a new template >> file). >> >> Has there been any work that you know of to reduce the amount of code by >> adopting a standard set of conventions for writing new generators? >> >> If it were done properly, the generators could be as simple as a set of >> template files in a standard layout, with a tiny bit of configuration to >> make it go. Very much a meta-swagger specification where very little >> configuration could drive the whole thing. >> >> Thanks again, >> >> ssteinerX >> >> On Saturday, January 28, 2017 at 12:52:57 PM UTC-5, tony tam wrote: >> Yes look in the readme for instructions for making a new module >> >> On Jan 28, 2017, at 9:34 AM, sste...@ <>gmail.com <http://gmail.com/> wrote: >> >>> So... >>> >>> I want to develop a new generator. >>> >>> I'd like to have it be a stand-alone bundle like: >>> >>> /mySuperBundle >>> README.md >>> .gitignore >>> /template >>> file1.md.mustache >>> file2.txt.mustache >>> /generator >>> mySuperBundle.java >>> >>> and so forth with tests etc. >>> >>> I'm an experienced programmer but have exactly zero experience setting up >>> or integrating with a Java project (on purpose; same reason I know nothing >>> about setting up Windows). >>> >>> This would seem a much better way of organizing new generators rather than >>> having them have to be monolithically compiled into the main project. >>> >>> So...is this even possible? Anyone want to help me get this set up or, if >>> it's been done before, a pointer to some clues? >>> >>> Thanks, >>> >>> ssteinerX >>> >>> -- >>> You received this message because you are subscribed to the Google Groups >>> "Swagger" group. >>> To unsubscribe from this group and stop receiving emails from it, send an >>> email to swagger-swaggersocket+unsubscr...@googlegroups.com <>. >>> For more options, visit https://groups.google.com/d/optout >>> <https://groups.google.com/d/optout>. >> >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Swagger" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to swagger-swaggersocket+unsubscr...@googlegroups.com <>. >> For more options, visit https://groups.google.com/d/optout >> <https://groups.google.com/d/optout>. > > > -- > You received this message because you are subscribed to the Google Groups > "Swagger" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to swagger-swaggersocket+unsubscr...@googlegroups.com > <mailto:swagger-swaggersocket+unsubscr...@googlegroups.com>. > For more options, visit https://groups.google.com/d/optout > <https://groups.google.com/d/optout>. -- You received this message because you are subscribed to the Google Groups "Swagger" group. To unsubscribe from this group and stop receiving emails from it, send an email to swagger-swaggersocket+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
