Ok I am working on my generator and need ideas ...

[Jorg]

I need some ideas guys!

I am working on my XML based Wizard for wxTreeMultiCtrl. This will allow people to create easy wizards (also for in IDE's). The wizard wrapper is a simple XML parser that loads in a couple of defined variables and presents them in a tree structure.

The wizard format looks like:

Code: Select all

<generate>
	<vars>
		<item id="PRJNAME" type=string" />
		<item id="PRJTYPE" type="radiolist">
			<listitem value="0">Create GUI project</listitem>
			<listitem value="1">Create library</listitem>
			<listitem value="2">Create console</listitem>
		</item>
	</vars>
	
	<wizard name="PRJGEN">
		<category caption="Project specifics">
			<item id="PRJNAME" />
			<item id="PRJTYPE" />
		</category>
	</wizard>
</generate>

As you can see it is very easy to set up a project generator (we talked about creating a wxWidgets project generator), or even setup a bakefile generator.

For my future tool I will use the XML wrapper to replace wxCRP and allow people to generate e.g. project frameworks. Like pre-selecting a main form, inserting config stuff, etc.

Only, I would like to have a little survey or think-along what else could be generated and if people would actually use it!

For example when the wxWidgets community hands out templates to create e.g. custom components, users can simply generate the code base, and fill in the blanks. Since this wizard setup is much easier and well categorised, it is multi functional, so what else would be useful to be able to be generated?

Thanks,
- Jorgen

[AkiraDev]

Hi Jorg!

Both modularity and compatibility with XRC are important.

I would like your XML format to be able to parse XRC as well - for GUI predefinitions.

The ability to include other documents of the same format or XRC resources in some way would be a great bonus! Something like a <include resource="mydialog.xrc" format=XRC>, or <include wizard=".......">, etc.

Can't wait for the successor of wxCRP!

Greets

[Jorg]

Hi AkiraDev!

This is how I kind of think the generator will work (I have discussed this in length with Micheal Sogstrop, he helped me with wxCRP).

The user can select a base solution. This can be an empty project frame. The wizard will provide options like add an about dialog, add preferences, can set the project name etc.

The generator will then generate the code. This will be similar to the way wxCRP does it. The whole base solution will be a compilable and workable template on disk (in the repository of the generator). To generate code based upon the options set (e.g. USE_ABOUTDLG is checked as option), the code in the cpp file for the maindlg.cpp window will be something like;

// __TPL IF USE_ABOUTDLG
MyAboutDlg *dlg = new MyAboutDlg(..);
dlg->ShowModal();
dlg->Destroy();
// __TMP ENDIF

Now, this code fragment is from the code in the repository. The user will not see the // __TPL comments, they are only used to generate this stuff conditionally.

So, when the user checks the option for the about dialog, the generator will create a base class for it, and you might even already fill in the contents of the about dialog.

I hope this makes a bit sense. The user gets ready to go code, with a project file to build it.

Now, I am also thinking about adding and deleting features to the existing code. What if you would like to add an about dialog later ? You might as well fire up the generator again, check that one option for the about dialog and re-generate the code.

To make sure the program does not overwrite your changed code, I decided to use a DIFF algoritm. The app simply diffs a base copy to the working dir, and adds the newly generated code. This way the code stays clean of comment markers, and can still be very flexible, PLUS the user gets to see what is added and approve upon it!

So in a nutshell, that will be the next generator. What do you mean with parsing XRC files? I would say, the XRC file is an option for your project to generate a base XRC file. Remember, it will all be generated from code templates. I decided not to add XML logic that describes yet another GUI like XRC does, it is already a good and solid mechanism.

I hope this clarifies the intent of the generator. I think I will call him Templar. I will also add features to (for example) generate makefiles. In the wizard you add the files you wish for your project, and it generates a makefile / DSW / SLN file like Bakefile does, but a bit more flexible towards the user.

Regards,
- Jorgen

[Jorg]

Hmmm re-reading your comments makes me wonder, are you thinking the code generator will take an XML definition file to spew out code?

The purpose is to define the wizard, and this will be presented to the user als questions to something that is generated.

I have thought about defining everything in XML, like windows and classes, and I have made some cases to test how complex it will get, and it was nearly impossible to implement some kind of code readback and still leave the user with enough flexibility. I think creating an XML descriptive language to directly write code is nice, but it adds a new layer of complexity and learning to a project. After a while, you know how to create an about dialog, and rather do it by hand then defining this in XML. At least that is what I am afraid of.

Although my mind is still undecisive ... the XML generation sounded very applealing to me for a while. To define classes like;

Code: Select all

<class name="MyClass" template="wxDialog">
    <member name="m_name" type="wxString" get="true" set="true" />
</class>

To define a class that will expand to a C++ source code with a member inside?

To generate stuff for the user, there are two worlds .. one is the generate-by-question which is the wizard idea. It generates a code base based upon some simple questions.

It looks like;



This is what the user will see. Then the generation app will create code based upon the questions defined. Ofcourse this is an old pic, also text can be entered, radio choices etc.

The other world is define-by-xml and generate code by translation, like you think .. the power will be in the simplicity of the XML syntax, and based upon some XML arguments, a lot of code can be created. This is a bigger challenge then the question-wizard approach ..

What do you think is more succesful? I am still open to both suggestions.

- Jorgen

[daddydave]

So if we split the wxCRP NG users into two different coders, the designer and the client coder...

1. The designer creates the wizard in XML.

2. And the client coder runs the wizard to turn the XML into generated C++ output and just views XML as an internal representation he doesn't have to care about.

Is that a reasonable approximation of what you are considering?

I wonder if this alternative would be feasible/better/worse/too abstract:

1. The designer runs a wizard that generates client wizards as output and just views XML as an internal representation he doesn't have to care about.

2. The client coder runs the client wizard to turn the XML created by the designer wizard into generated C++ output and just views XML as an internal representation he doesn't have to care about.

[AkiraDev]

The purpose is to define the wizard, and this will be presented to the user als questions to something that is generated.

I have thought about defining everything in XML, like windows and classes, and I have made some cases to test how complex it will get, and it was nearly impossible to implement some kind of code readback and still leave the user with enough flexibility. I think creating an XML descriptive language to directly write code is nice, but it adds a new layer of complexity and learning to a project. After a while, you know how to create an about dialog, and rather do it by hand then defining this in XML. At least that is what I am afraid of.

Yes, that's what I thought of, but I was considering whether it could convert existing files into XML templates of your format, or even whether the code-generator might even be able to handle those. What's more, I just thought that having < include... > style tags will allow to split XML templates into particular modules.

[Jorg]

Ok, we are apperantly discussing two types which are now mixed. Let me sketch a scenario how I *thought* my generator would work:

Scenario 1:
A user wants to quicky generate a makefile or visual studio project (or both) for his project.

- He starts up the generator app

- Selects a template that produces a wx project

- Checks some options like LIB project, Console project

- Fills in some files that are in the project (e.g. adding them to a list)

- Checks options what to produce e.g makefile, VS6/7 project and what else

- Selects generate and the generator produces the files on disk for the user.

In this scenario a template from the repository is chosen like in wxCRP. The person has now on disk a start project.

Scenario 1.1:
The user wants to update the project files

- The generator app is started again

- The work cache is loaded, which means all the options are there as he used them

- The user adds two more files

- The user adds a DEFINE to be turned on or off e.g. wxUSE_CHECKBOXES

- The user presses generate again

- The project files on disk are now updated.

Ok this is one of the scenarios for generating a project file.

Another scenario could be:

Scenario 2:
The user wants to quickly create a derived class from e.g. wxPanel to fill in

- The user starts up the generator

- A template is chosen that generates a cpp/h file for a wxpanel derived class

- The user fills in the name of the class
- The user fills in the filenames
- The user checks options like implement an event table, sets the predefined flags such as TAB_TRAVERSAL, the border, maybe even background color
- The user presses generate

The class files on disk are created.

Scenario 3:
The user wants to create a basic application framework

- The user starts up the generator

- A template is chosen that generates the basic GUI project
- The user fills in the name of the application
- The user checks if he wants an about box
- The user checks if he wants default window settings being written
- The user selects which XPM is the icon, and which *.ico is used to be written in the res file
- When the about box is selected, the user can add the default text
- The user selects if he wants a wxFrame or wxDialog derived class
- A selection is made if the XRC or in code creation must be used

- Generate is pressed

A default framework is written to disk, with a default XRC file that covers the window creation is created, a project file is there, and everuthing compiles.

Scenario 3.1:
The user wants to alter the generated framework

The user changed the files already, added some stuff, but realised he really wanted to have e.g. the config management and forgot to turn it on.

- The user starts up the generator app
- The cache is loaded, the default settings are displayed
- The user checks the option for using a wxConfig object in his code
- The user checks that an options dialog is created

- The user presses generate

The code is generated, but since the code on disk differs from the code re-generated, the files are presented to the user. The red areas in the file are removed, the green areas are added. The user can approve the changes by selecting OK, or go back to the wizard and uncheck or alter settings.

- The user approves the settings
- New code is written on disk.

In conclusion

So, basically this is what I wanted to create. The templates on disk are compilable C++ / H and project files that can be altered by the template mechanism. Basically it will generate what you want by selecting the options.

The templates that turn into code can be created by anyone. It would be ofcourse cool if wxWidgets would also distribute templates like this, so the users can simply generate the code by checking some options.

The XML based code generation is a different story. I will elaborate that later.

- Jorgen