Monthly Archives: April 2010

Update for 7.1

An update for 7.1 is going out today, there are no new features introduced in this release, but there is a change (for the better) that you’ll soon have:

CHANGE: Code generation only executes from the application tree window, this prevents generation with partial or unsaved changes and ensures consistency for code generation.

What this new change boils down to is a subtle (or not so subtle, depending on your work style) change to where and when you can initiate code generation. In all previous releases the IDE was very loose about allowing you to initiate code generation from just about anywhere within the Application Generator dialogs and supporting components (Designers, Embed Editor, etc.), without consideration for the current state of uncommitted changes, and unfortunately this flexibility opened up avenues for introducing problems into the generated code. Imagine if you changed a Window or Report and exited the Designer, now the structure has changed but you haven’t committed the changes at the Procedure level, but while still on Procedure Properties you execute code generation. What should generate? Should AppGen somehow restore the old structure (probably not what you want), or auto-commit the changes to the Procedure, again not a decision that should happen without an explicit choice by the developer. The implemented solution for this is very simple, the AppGen will inform you to return to the main window, which in turn forces you to either save the partial changes or abort them. The result is 100% consistency in the generated code, at the cost of having to make an explicit decision to save or abort changes at the Procedure level. Besides this change (for the better and safer) there are a good number of other fixes. You can read the entire list here

Update for 7.1

An update for 7.1 is going out today, one of the really nice improvements is this release:

FEATURE: New option in “Tools/Options/Clarion/Clarion for Windows/General” – Use lightweight parsing mode (enabled by default). Used only if project parsing is set to “Parse all hand-coded projects and only applications opened for editing”. If this option is enabled only the PROGRAM file will be parsed on project reparsing to refresh global information for code completion. Each MEMBER file will be parsed only when a procedure located within this MEMBER file is opened for editing.

What this new feature boils down to is a very noticeable improvement in performance for parsing large applications, especially when working with embedded code. There are also several other refinements for code completion, some fixes for conversion of TXRs to the the new .REPXL format (used in the new ReportWriter), and a number of other fixes. You can read the entire list here

.Net Application Generator

In this post I’ll try to provide a complete overview and our best estimate on when you’ll have this new technology in your own hands. Diego Borojovich is leading the team working on the new .Net Application Generator (AppGen.Net), and if you have attended any DevCon events over these last years then you probably have met Diego. He’s been working with Clarion for over 16 years, and joined the SoftVelocity development team 8 years ago. You’ll be hearing a lot more from Diego in blog posts in the upcoming weeks as he talks in-depth about the new AppGen.Net, the template language, and how the new code generation/template system works.

Let’s start from the top; the Code Generation engine in AppGen.Net is completely new. It has its architectural and conceptual roots in the Clarion Win32 AppGen, and that technology is blended with the functionality found in the Text Template Transformation Toolkit (T4).

The template language used in the new AppGen.Net is a complete departure from the syntax used by the templates in our Win32 Application Generator.  It uses an extended set of the T4 template directives. It’s very easy to work with the template code and templates can be used in any type of project (WinForm, WebForm, CompactForms, Web Services, etc.). And just like with our Win32 AppGen you can write templates to create any type of output that you need – CLN, CS, ASPX, HTML, SQL, XML, or anything else you need.

The syntax for the new templates is similar to what you see in an ASP.NET .ASPX source file – here’s a small snippet so that you get a feel for what it looks like:

<#@ template language=”C#” debug=”true” type=”ProcedureExtension” name = “DescriptionOutput” family = “Clarion.Linq”#>
<#@ assembly name=”mscorlib.dll” #>
<#@ assembly name=”System.dll” #>
<#@ import namespace=”System” #>
<#@ import namespace=”SoftVelocity.TextTemplating” #>
<#@ property processor=”PropertyProcessor” name=”MyDescription” type=”System.String” defaultValue=”None”#>
<#%+ CustomGlobalData priority = “1000”#>

I already mentioned that the AppGen.Net template system supports an extended set of the T4 template directives, these extended directives include equivalence for our #PROCEDURE, #CODE, #GROUP, #CONTROL, #EMBED and #AT and #EXTENSION directives as found in our Win32 template system. And you may have noticed in the first line of the template snippet where it reads “template language=C#”? In the first release, all the templates are coded in C#, but in a future release we plan to let you use any .Net language to write your own templates. The templates themselves can utilize the entire .Net Framework, including any 3rd party components, and that gives us (and you) incredible power and flexibility in the template system; meaning there are really no limits to what you can do in a template (outside of is your own imagination). If you plan on writing templates you’ll be glad to know that inside the IDE we already have T4 syntax highlighting in the editor, and in the near future we’ll be adding code completion support.

The template system has the concept of a template registry, just as we have now. But with AppGen.Net when templates are registered into the IDE they are automatically compiled into a binary assembly. Compiling the templates provides for faster code generation, immediate detection of syntax errors, and makes it easy to share templates within a team.

In the initial public release the generated data access layer will let you select from two data access frameworks; LINQ to File, and LINQ to SQL.  (It’s possible that we will also provide a template set for generating a plain ADO.NET data access)

What is LINQ to FILE?

LINQ to FILE utilizes our own LINQ provider that encapsulates an ABC-styled framework — using LINQ syntax for accessing and updating data via our underlying File Driver technology. The LINQ to FILE provider maintains referential integrity and also handles auto incrementing of keys. The LINQ to File data access layer can also utilize our managed .Net IP driver. If you’re not already familiar with LINQ syntax here is a simple example of the syntax used for retrieving data:

query? = from class in ClassesQuery    |
where class.RoomNumber < 10   |
select class

This LINQ query will retrieve all records where the column RoomNumber is less then 10, it’s really that simple. And using a LINQ query with a Where clause instead of filtering records in a Loop provides a noticeable increase in performance. Using the LINQ to File lets us work with powerful SQL-like query and update capabilities, working with all of our FILE Drivers, and integrated into the LINQ to FILE provider is functionality essentially equivalent to that in our existing ABC framework.

What Is LINQ to SQL?

LINQ to SQL is itself a light-weight ORM (object relational mapping) implementation that ships as part of .NET 3.5, that allows you to model a relational database using .NET classes.  You can then query the database using LINQ, as well as update/insert/delete data from it. LINQ to SQL supports transactions, views, and stored procedures.  The templates provide an easy way to integrate data validation and business logic rules directly into your data model.

In addition to the two LINQ frameworks we plan to add template support for working with several additional technologies for the data access layer;  options for data access will look like this:

•    LINQtoFile
•    LINQtoSQL
•    NHibernate
•    CSLA
•    ADO.Net

We also plan to have templates for supporting these technologies:

•    Windows Communication Foundation (WCF) is the .Net programming model for building service-oriented applications.
•    Web Services (for exchanging data)

And I should mention that we’re providing template sets to support the three target platforms; Winforms (desktop), WebForms (Web) and Compact Forms (Mobile devices). The templates being developed for .Net offer code generation in 2 language flavors C# and Clarion#, and eventually we’ll add VB to the list.

I want to mention a few things about the user interface generated by the templates. These are options that the templates will provide for the user interface layer:

•    Winforms (using the standard .Net Framework controls, or a designated 3rd party component set)
•    CompactForms (using the standard .Net Framework controls, or a designated 3rd party component set)
•    Webforms (using the standard .Net Framework controls, designated 3rd party component set, Ajax Library, and in the future Silverlight)
•    WPF – Windows Presentation Foundation: (using the standard .Net Framework controls, or a designated 3rd party component set)
(The WPF support will come after the initial release, and although we don’t presently have a full-blown designer, we will have UI edit capabilities, and of course you can use many different external tools to create and work on the UI as the code is completely separate from the other layers)

For creation of the UI the templates read the control settings from the Dictionary, just as we do now in the Win32 AppGen, but we plan to provide (as a configuration option) the ability to specify that the templates use an external file for control mappings, and in this file we’ll store the fully-qualified name of the control, along with its properties (i.e. font, width, height, etc.). The controls specified in the config file will map back to the controls supported in the templates for generating the UI. This feature means that you can specify the use of 3rd party components and the Template Wizards will generate the UI using those controls and properties.

Here are a few miscellaneous new features that are worthy of mention which are planned to be introduced with the new AppGen.Net:

•    Option to generate test cases (nUnit) for aspects of the APP
•    Ability to attach developer documentation/working notes directly into the .APP and/or to individual procedures

And something else exciting is coming up; we are happy to announce that the templates to power these technologies will be made part of an open collaborative community project so that anyone interested can participate in their ongoing development. This collaborative project will contain all of the new Clarion templates and sample Apps.

And this project is not just for the new .Net templates, we’ll be adding all of our Clarion templates (Win32 and .Net), as well as new example Apps. With this project the Clarion community will always have access to the very latest updates, as well as contribute patches, and add new templates and sample Apps.

Now the question at hand is when will you get it?  We have had to revise our earlier estimates to allow extra time for some of the integration tasks in our switch over to the new AppGen.Net, and the revised estimate for delivering a full beta is now about 5-6 weeks from today, putting it into a late-May early-June time frame. However, it is very likely that we’ll release the new AppGen.Net with some reduced template support before that. That first early release will support generation of code targeted at the data access layer, in other words it will be without the tie-in with the Designers. And that release also will likely include Application and Procedure Wizard functionality. So that first release will provide a big increase in productivity in two areas, and it’ll also allow those who are interested, to start working on the template code itself. Very importantly it’ll also let us get feedback from you on the AppGen.Net UI itself, which is very valuable to us all.