GeneratorApp Documentation Screens

In this article is the first from a series of posts that will contain screenshots, explanations, tutorials, howtos and “What is this?” – about my GeneratorApp Tool.

In general my idea about the GeneratorApp is:

  1. Import from some database or enter – type in on your own – some domain models, relations and descriptions about some problem area into the tool.
  2.  Setup the environment for your projects (outside of the tool), enter what you want to output from the above definitions (in the tool)
  3. Generate code. Extend it and modify it according to your business logic needs using object oriented inheritance, static methods or some other approaches, next time when the requirements change – enter them into my tool – generate them again and make minimal changes to your custom code.

The first screen contains a list of “applications”,

a button to enter a license purchased from my site

, a button to add new application that needs source code generation, an import button to get started quickly with previously defined models with source from:

  • From previously exported to file application.
  • From previously generated application. At the time of writing this article only import from GWT_MODELS is working because of my focus on actually generating.
  • From existing relational database. Here – the platform type field is only to know what platform to add when the importing is finished (not required in the actual importing)

On every record here you have the following functionalities: 

  • The applications can be copied (duplicated) so you have two definitions of the same model and make modifications to one of the and try stuff out.
  • They can be exported to a JSON file – that is specific for my Generator Tool. This file can be backed up for security reasons, transferred to another user of my tool and/or imported to it via one of the import options.
  • And of course – there are buttons – one that is used to activate the generation process and another that is a delete application button.

Applications have a name and a list of databases. The databases can again – be imported from existing ones – in another article I explained how to add integrate in my tool support for other databases – or you could create them on your own.

The upper fields on the database details screen are used rarely – if you use plain Simple DriverManager JDBC Data Access for example. If you use some ORM or JDBC with ContextResource – where the connection is defined outside of the code – in the application server, these fields are optional. More about it in another article.

Next there is a grid with the platforms included to this database. I’ll make a separate post about each platform – what is expected as an input in the fields and what the GeneratorApp outputs.

Next there are three grids – grid with tables, grid with properties/fields and grid with references.

The grid with tables is static one – it doesn’t refreshes and it stays unchanged by outside changes. Tables represent your domain models in database terms.

  • There is a button in the bottom for adding new tables, and when you click on the names in the grid – edit dialog appears – the same as when adding.
  • There is a delete button
  • And you can select a table by clicking on the number of fields. Then – the grid with Fields and the grid with References are refreshed.

The functionality of the grids with fields and references is very much the same – basic user interface for managing records. The properties of the fields are several and are very much known to a developer that uses databases.

  • Fields:
    • Name
    • Size
    • Is it nullable
    • Is it primary key
    • is it auto increment
    • type
    • Is it visual field. This flag is used in some generators to put the value of this property to the user interface in lists and forms.


  • References – currently my tool can describe basic database relations. They need two tables and two fields – one field from each table. There are probably cases when you need two or more fields for mapping two tables. I realized that after I already created the tool. For now I haven’t encountered a need for such relations in my apps sense I started the tool and this change is currently in low priority for me. If it is important for you – you could write me.

    • The source table is the currently selected table
    • Source Property list is the fields of the current table
    • There is a combo with the tables to choose a target table.
    • There is a target property list – a combo box with the fields of the target table
    • The last combo box is Reference Type with two options – 1:N and N:1. Don’t get me wrong – I know that in the relational world exist also relations of type 1:1 and N:M. Adding such relations is also in my To-Do list with low priority for now. This can change in the future

The next tutorial will be more give more details about the input and output of the generators and the technologies that are applied to.

Add comment