idas wrote:
Hi Otis,
There seems to be some sort of problem getting my message across, that's why I suggested we call, we can speak dutch and not discuss code but my additional needs in the designer...
I'm not doing phone calls in general and definitely not if there's even a small chance some code has to be discussed or I have to point you to a URL. But I think I have a proper picture. My previous assumption was that you wanted to extend the code generated by the designer for the 4 frameworks, but you want to effectively add another framework.
I'm not trying to generate this extra information, I'm not yet trying to generate any code.
This extra information is information (properties) which I need to be able to enter and store in de designer, let's say for instance that I'm adding a Field to an Entity, I enter the name, order, type, Is PK, Optional, ReadOnly etc... in addition I want/need to be able to store DatabaseType, BusinessObjectType, .NETtype.
For example:
Let's say I want to add a the field Status to Invoice, I'd need to be able to enter the following information.
Name "Status"
Order
Type System.Int32
IsPk false
Optional false
ReadOnly false
Max Length N/A
Precision N/A
Scale N/A
Description N/A
IsFK N/A
*DatabaseType D_ENUM
*BusinessObjectType Interfaces.Enums.EInvoiceStatus
*NETType System
the first 11 are avaible in the designer, but I'm wondering how we could store the other 3 properties for each field as we absolutely need those for our code-gen.
A similar case can be made for Entity and Relation in wich we also need to be able to store additional information.
There are two ways to extend the data in the entity model: through custom properties, which are simple name-value strings, and settings. Settings are name-value pairs where the value can be typed and e.g. be selected from a list, you can use defaults etc.
The 'custom properties' can be applied to the project (entity model), entities and the like and fields.
Settings can be applied to project, entities (and typedlists,typedviews etc.) , fields, navigators etc. This is all described in the SDK: http://www.llblgen.com/Documentation/5.1/SDK/Frameworksandsettings.htm
This has already been discussed above, so I don't know if you have looked at it yet. It describes what files you have to create for another framework. You can use that to further understand how the existing files work.
It's really straight forward, but the files discussed in the SDK are the minimum amount of files you have to create. It's also not done in an afternoon: you have to define the framework itself, the frameworksettings file, the validator dll (which can be simple btw), the templatebindings for the templates and the templates itself, and a preset file which dictates which tasks to run which which templateids. All files are pre-filtered on the framework name, so if the entity model uses your framework, the files used, like templatebindings, presets, the validator etc. are all filtered, so they have to contain the name of your framework as the supported framework.
The settings in a .frameworksettings file show up as a setting on the element(s) they're defined for and you can alter their values in the designer.
Now to the part where I kept asking how the generated code would look like: you already know that, as the code in your existing framework is the code you need to generate. This thus means you want to add support for your existing framework to the designer: as an entitymodel target framework (similar to EF, LLBLGen Pro etc.). To write the templates, it's crucial you know how the code looks like that these templates have to generate.
It also means that if the code you're generating are e.g. poco classes with attributes on class / property etc., you can also choose to define attributes in the attribute system of the designer, and not through settings.
