I have a question related to Kademi platform. In normal page templating, I can use #docs for exploring properties and methods of an object but in EDM template, I can not. Do you know how to do that?
You can use #docs in theme/emailBase.html
Variables specific to automation are copied into the templating model for the base template, so can be referenced from $page.model.xxx, where xxx is the same variable name as in the automation template
For example, if you're writing an automation template for an event, and you're not sure what the event is and what properties it has, use this;
#docs($page.model.event)
Related
I want to generate c# asp.net core razor pages with many projects: Application, Domain, Infrastructure, Core etc.
I would like to know if Telosys is extensible to allow a custom console program to be called with arguments: , so this program can do some code merges in order to preserve possible additions/changes to the code a developer did since the previous code generation?
C# can have some directives called #region to partition the code and these will be "regenerate only regions" and outside these regions the developer can put his own code. We need to preserver his code.
C# Partial classes and methods can also help.
I want to have capability to merge newly re-generated code (e.g. entity class - I can add some properties or change some property name, type, annotations, tags etc.) into previously generated entity class. This could be done by creating #region .... #endregion where the code can be regenerated into and all the code that is outside these regions should be preserved. See: efg.loresoft.com/en/latest/regeneration So I would like to know if there would be a way to temporarily generate files in a TMPGEN folder and allow some "merge program to run" that will mege new code with previously generated code (with some code added by the developer) previously determining if merge is needed (compare hashes)
This is the code from EntityFrameworkCore.Generator tool that merges existing regions https://github.com/loresoft/EntityFrameworkCore.Generator..EntityFrameworkCore.Generator.Core/Templates/CodeTemplateBase.cs has the protected virtual method:
void MergeOutput(string fullPath, string outputContent) show that fullPath is an existing file and outputContent is the result of parsing the template (new content). RegionParser uses these namespaces: Microsoft.CodeAnalysis.CSharp; and Microsoft.CodeAnalysis.CSharp.Syntax;
so I need to user c# console application to user this preserver region code.
Thanks,
Rad
Yes, Telosys is extensible by using specific Java classes loaded in the template context with $loader
See : Is it possible in a Telosys template to call a function created specifically?
So, you just have to create a Java class to launch any Shell command
For example, see : How to get java getRuntime().exec() to run a command-line program with arguments?
I'm in an AX 2012 R2 environment.
I've a custom document service in our environment. I can see it by opening the AIFService form in the AOT. There may be a better way of browsing all the available document services. I haven't found it yet.
Anyway, how do I find out all the parts (query, document name, document class name) associated with this custom service, assuming the standard naming conventions haven't been followed?
Thank you.
To know what document services are available, go to the AOT - Classes - AIFDocumentService. Right click the class, then Add-Ins - Type hierarchy browser. You'll get a list of all document service classes.
To find the document class based on the service, just open the source code of the service and look at the code. The create method for example takes a parameter of the type of the document and the find methods returns an object of that type.
In the document class declaration you will find a marco. The name of that macro (minus DCT) will be the name of your query. The AxBC classes will be Ax + the name of the table, for example AxInventTable.
You can use this code:
AxdWizardParameters axdWizardParameters;
;
axdWizardParameters = AifServiceClassGenerator::getServiceParameters(classStr(YOURSERVICECLASSNAME));
info(axdWizardParameters.parmAifServiceClassName());
info(axdWizardParameters.parmAifEntityClassName());
info(axdWizardParameters.parmName());
info(axdWizardParameters.parmQueryName());
What is a valid reason for using the 'ADO.NET EntityObject Generator' with EF? In case you don't know, it generates a T4 file that does the building of the entities from the edmx. You can then change the T4 file to change how the entities are generated.
My question is: other than changing the base class in which entities are derived (also implementing interfaces) and changing the accessibility of entities and/or the context objects and naming conventions, what use does this have? Considering the existing features of EF and partial classes.
I've come up with 2
Grab the table/column descriptions from the database and populate the summary on the entities and properties
Generate light wieght DTO's and do auto mapping.
1 seems like too much work considering it only updates the comments on the models, not the edmx itself (although it could do so)
2 Is this even useful?
We have done a few things with the T4 templates. The first one is to split out the generated code into one class per file, instead of one massive file. This just makes it easier to navigate and browse through the entities.
The second, and more important one, is to automatically generate data annotation validation attributes such as StringLength and Required. This lets us validate our entities with a single function call, and it makes sure that their validation attributes are always in sync with the database (since if we change a column length in the DB, for example, the generated StringLength() attribute is then updated when we do 'Update model from database').
At a previous job, we also added base classes and interfaces to the entities, as you mentioned in your question.
Here's a snippet from our T4 template that checks for required columns and string lengths and adds the necessary validation attributes:
''' <summary>
''' <#=SummaryComment(primitiveProperty)#>
''' </summary><#=LongDescriptionCommentElement(primitiveProperty, 1)#>
<EdmScalarPropertyAttribute(EntityKeyProperty:=<#=code.CreateLiteral(ef.IsKey(primitiveProperty))#>, IsNullable:=<#=code.CreateLiteral(ef.IsNullable(primitiveProperty))#>)>
<DataMemberAttribute()>
<#+
' begin required attribute
If Not ef.IsNullable(primitiveProperty) and not ef.IsKey(primitiveProperty) then
#>
<#+
If ef.ClrType(primitiveProperty.TypeUsage) = GetType(Guid) Then
#>
<GuidRequiredAttribute(ErrorMessage:="<#=FixName(code.Escape(primitiveProperty))#> is required")>
<#+
Else
#>
<RequiredAttribute(ErrorMessage:="<#=FixName(code.Escape(primitiveProperty))#> is required")>
<#+
End If
#>
<#+
End If
If HasMaxLength(primitiveProperty.TypeUsage) then
Dim d = MaxLength(primitiveProperty.TypeUsage)
#>
<StringLengthAttribute(<#=d#>, ErrorMessage:="<#=FixName(code.Escape(primitiveProperty))#> cannot be longer than <#=d#> characters")>
<#+
End If
#>
Well, the reason is that you can do anything with it. So, why don't have it? Of course the usage of T4 is very limited to some special cases, and most of the time it doesn't make sense to use it. On the other hand you can do funky stuff with it. For example you can define some user defined stuff. Let's say you have a Sort column in your table. Then you could define a query function where it automatically sorts every entry if this column exists. Maybe too trivial for an example, but there are tons of other weird architectures where it makes much more sense.
You can also make use of other code generation stuff, without EF. So it's certainly here for completeness and extendability.
T4 template replaces custom tool used in EFv1 to generate code behind file (.designer.cs file with all classes). The main advantage of T4 is that you can change it per project just by modifying text .tt file. In case of custom tool changes were mostly impossible.
With T4 you have complete control over entity classes generated from your EDMX. It is transformation of EDMX into C# or VB.NET files. The default template creates class files with features required by most of developers but if you need anything else you can simply go to your .tt file and add it.
Possibilities for changes are unlimited because EDMX file itself is extensible. On behind EDMX is just XML file and you can include your own custom XML elements in this file (it has some restrictions but it is possible - here is some example for SQL generation in model first approach). Once you have custom elements in EDMX you can use them in T4 template as decision logic for additional features you want to include in generated code. Entity designer is also extensible - you can create custom extensions which will be stored as custom elements in EDMX file. Both EDMX and Entity designer extensions are nicely described in book Entity Framework in Action.
I know this is an old question, but I would have liked to come across this information when I started out.
In our case where we have a win32 Delphi client in our multi-tier solution, I've used the templates (in C#) to generate the DTO classes in .Net, and the win32 counterparts.
This allows us to encapsulate the CRUD functionality on the client using largely auto-generated Delphi code:
procedure Delete;
class function DeleteDto(const _dESPATCHID: integer) : boolean;
class function GetNextID : integer;
class function Get(const _dESPATCHID: integer) : TDtoDESPATCH; overload;
class function Collection(const __filterXml: string): TList<TDtoDESPATCH>;
function Load: boolean; overload;
function Populate(_primaryDict : TDictionary<string, Variant>) : boolean;
function Save : boolean; overload;
Change tracking from the client can also be automated, so each property setter will mark the changed property, to ensure only changed properties are updated.
For example:
procedure TDtoDESPATCH.SetSCT_STATUS(const value : string);
begin
if (self.IsLoaded) and (inherited SCT_STATUS <> value) then
begin
TrackChange('SCT_STATUS');
self.Modified:= True;
end;
inherited SCT_STATUS := value;
end;
On the server side, another template takes care of all the CRUD operations in an auto-generated WCF service that's also exposed as an asmx web service. The Interface, WCF methods and all annotations are generated from the template.
// convert to entity
var _entity = _dto.ToEntity();
if(exists)
{
Global.LogActivity(string.Format("{0} - profile {1}, updating DESPATCH: {2}", racID, profile, _dto.ChangedProperties ));
// Attach the entity to the db
db.DESPATCHes.Attach(_entity);
// Change tracking
ChangeTracking<DESPATCH>(_dto.ModifiedProperties, db, _entity);
}
In a scenario where WIN32 has to be part of the solution, hand coding all this would be a (worse) nightmare.
I've used them quite a bit to generate code that is useful to us at a Datalayer level.
Altering whether they implement additional contracts (interfaces), adding methods, annotations and in the case of a non-layered application (and NOT recommended beyond this) adding property changed notification.
By adding some of these items to the generation at the Datalayer, I've been able to use a template in the Model project to generate the boiler plate code at this level too.
Bottom line, if you can safely get the computer to code for you, then it's well worth while. In our case 80% of basic plumbing work can be code genned - if it's incorrect, it's generally very easy to fix and regenerate.
Does anybody know how to create his own models and controllers in Orchard-based projects? I have an empty project and a pack of screenshots for pages, but I don't know with what to begin. If it is possible, please show an example.
Thanks.
You should start off at the documentation page. There is an 'Extending Orchard' section which walks you through how to create a module, with data access, content parts, and content fields.
Use the command line to generate the module using the code generation module
Documentation here
Then install the Code Generation Extensions from Piotr and follow the instructions on his blog. http://www.szmyd.com.pl/blog/generating-orchard-content-parts-via-command-line
Module adds an Orchard command-line command “codegen part”. It’s
syntax is as follows:
codegen part [/Properties:]
For example:
codegen part Modules.Shop ProductPart /Properties: Name:string,
Price:int
Properties is an optional parameter, so if you’d like to create an
empty part you can just write
codegen part Modules.Shop ProductPart
The command creates a handler, driver, model, record, display and
editor shapes and updates the Placement.info file with default
Content:before placement for your part shape. If you provide
/Properties parameter, the model, record and editor shapes will be
filled with appropriate code accordingly.
When I'm generating/refreshing my model from the database, how do I specify which template to use?
At the moment, despite having my new template, it still uses the default. Then I have to go in and clear out the contents of 'MyDatabase.Designer.cs', then manually go in to my template and run it.
Surely I can just specify which template my model should use?
At first, you should disable the default code generation. The simplest solution is to clear the Custom Tool property of the model file.
After this just run your template.
There is even simpler way: go to the model Properties and set the Code Generation Strategy property to None.