Blue Ink
Blue InkHomeBlue Ink SolutionsArticlesBlue Ink Net CommunityBlue Ink Demo ApplicationAbout Automated Architecture
My Profile
login/register
0

How Blue Ink Works

This paper will cover what the Blue Ink software development tool is and how it works, including key concepts and design goals. It will pay particular attention to Blue Ink Meta-Data and Blue Ink Templates in Sections Two and Three, and will close with a brief overview of The Blue Ink Net, which is part of Blue Ink's unique client-server architecture.

This paper will not cover Blue Ink's default template solution which outputs a .Net, n-tier web application. For more information see the Blue Ink Overview page or the Application Architecture page. This paper will also not cover benefits of using Blue Ink, which can be found on the Time Savings page or Other Blue Ink Benefits page. This paper is intended for a fairly technical audience.

The Blue Ink Product

Section One will provide an overview of what The Blue Ink Product is and will give more details by explaining how it works, its key concepts, and its unique design goals. This section will conclude with an overview of the features that make Blue Ink unique and the benefits those features provide.

Overview

Blue Ink a generally Rapid Application Development tool, but more specifically is a code generator, whose primary purpose is outputting programming code that can be used to compile an application. Blue Ink differentiates itself by generating all of the code for a database driven web site instantly and enabling a new application development process: Just-In-Time Application Generation (JAG).

How Blue Ink Works


Figure 2 - Blue Ink Functional Overview Using Templates, Blue Ink combines a database schema and user entered meta-data to produce a usable text output.

Blue Ink works by gathering information from a database and from the user and by running Blue Ink Templates that use that information to create text output.

The Blue Ink Meta-Data Repository

The information that Blue Ink gathers from the database consists of tables, columns, and relationships between tables. The information gathered from the user is additional information that cannot be found in the database, such as which tables should be updateable in the application, or what validation rules should be applied to which columns (since a field containing a phone number looks just like a field containing a zip code from the perspective of a database). Blue Ink stores all information gathered in The Blue Ink Meta-Data Repository (MDR) which it makes available to templates. The Blue Ink MDR is stored and maintained internally and is only usable in conjunction with The Blue Ink Product (meta-data may, however, be imported and exported as XML).

Blue Ink Templates

Using Blue Ink Templates, Blue Ink can take the information it has gathered and transform it to make meaningful text. Templates are the instructions for what to do with the meta-data and are themselves code that the user can modify. In fact, one of Blue Ink’s great strengths is that a developer can modify templates to gain complete control over the outputted application. Because Blue Ink Templates take a Blue Ink Meta-Data Repository as their input they are unique and can only be used in conjunction with Blue Ink.

Key Blue Ink Concepts

Run-Time Code Technology

Blue Ink Run-Time Code Technology is a unique and integral part of how Blue Ink works and is used by both Meta-Data Questions in the creation of pre-generated Meta-Data Answers and by Blue Ink Templates in the outputting of text. Run-Time code is programming code (in the Microsoft C# language at present, although other languages may be supported) that a Blue Ink user may modify and that Blue Ink will compile and run. Blue Ink template code is the most obvious example of run-time code. Template code is programming code whose primary purpose is to take a set of inputs provided by Blue Ink (the Blue Ink MDR) and build a string of text that Blue Ink can output to a file. Allowing a user to write actual code that Blue Ink will compile and run provides an enormous amount of flexibility for the developer who is undoubtedly quite accustomed to writing code anyway.

The Blue Ink Net

Blue Ink uses a client-server architecture based on web services that allows The Blue Ink Application (client) to communicate with The Blue Ink Net (server) over the Internet. This architecture allows community based services such as message boards and support forums to be built directly into Blue Ink. This architecture also allows Blue Ink’s unique payment method of service based pricing where the cost of application generation is based on the size of a user’s database.

Design Goals Unique to Blue Ink

From its inception Blue Ink has been designed to accomplish specific goals. These goals and how Blue Ink implements the goals (described later in this document) make Blue Ink unique in the code generation world.

Application Wide Focus

Blue Ink is designed to approach building an application from the perspective of not just generating useful bits and pieces of an application, but generating an entire functionally complete and working application. Blue Ink ships with default Blue Ink Templates that provide the capability to build a functionally complete Microsoft .Net web application. Particularly for Full Projects, providing an application-wide focus refers to not just building any application, but building one based on an enterprise level architecture and industry accepted standards, that supports re-use (not accomplishing the same task in several different places in code), that provides flexibility, that is as close as possible to a developer’s ideal application.

Flexibility

Blue Ink is designed to support the flexibility that developers require to output any type of application. Blue Ink supports these flexibility requirements at a more coarse grained level of detail through questions and answers and at an extremely fine grained level of detail through templates. This allows a developer to:

  1. Generate an application using Blue Ink in as few clicks as possible;
  2. To go back and answer meta-data questions, maybe to change which fields can be searched on or what textual name is given to different fields and then to re-generate the site and see the results of the more course-grained changes;
  3. To then go back and change templates to affect sections of the architecture (perhaps optimize how the application handles session state) or to add new pieces of functionality (like the ability to delete).

This flexibility allows the iterative customization aspect of the JAG methodology.

Instant Application Generation

Blue Ink is designed to generate an application as quickly and accurately as possible. Blue Ink accomplishes this goal through a unique aspect of its Meta-Data Questions: its ability to pre-generate default values for Meta-Data Answers that may then be modified by the user. Pre-generated answers are based on Blue Ink’s unique Run-Time Code concept, thus allowing an enormous amount of intelligence to be added to the answer pre-generation process, not just by Blue Ink staff, but also by Blue Ink users who choose to develop template solutions.

What Makes The Blue Ink Product Unique

Following is summary of the key points that make Blue Ink unique:

  • Blue Ink forms the cornerstone of the Just-In-Time Application Generation Methodology that enables applications to be built faster and more predictably than ever before.
  • Blue Ink uses Meta-Data Questions and Answers that allow a developer to quickly make course grained changes to a generated application.
  • Blue Ink uses Run-Time Code Technology to intelligently pre-generate Meta-Data Answers thus minimizing the amount of customization required of the developer.
  • Blue Ink implements templates with Run-Time Code Technology to provide a developer with complete control over a generated application.
  • The Blue Ink Client integrates with The Blue Ink Net via web services to provide community based services directly in the application.

Extensible Meta Data

Section two will describe Blue Ink’s unique extensible meta-data by first providing a couple of examples and then describing meta-data in more detail. The description of meta-data will include a summary and will cover the two aspects of meta-data: database meta-data and user entered meta-data. The section will close by describing the most unique aspect of Blue Ink’s Meta-Data: Default Values and Question Code.

Examples

The Blue Ink default template that generates a Microsoft .Net application contains the following questions that help illustrate meta-data questions.

ClassLibraryProjectLocation

The following table describes a fairly simple meta-data question.

Question Name: ClassLibraryProjectLocation
Question: “What is the base location for this .Net project?”
Result (what the answer will be used for): “All projects (e.g. data access, business components) will be placed in folders under this folder.”
Answer Type: Short String (as opposed to a yes/no value for instance)
Relates To: Database (so it is only asked once per project, this is as opposed to table related questions which must be answered for each table in the database schema)
Default Confidence: (how likely the pre-generated answer is to be correct) Very Likely

This meta-data question has question code associated with it that will provide a pre-generated answer if the user does not explicitly set one. The following code segment demonstrates this concept:

mobjDefaultValue = 
	Environment.GetFolderPath(System.Environment.SpecialFolder.Personal) +
	"\\Visual Studio Projects\\" + 
	rowDb.ProjectName;

The variable mobjDefaultValue must be set to a string (because of the Answer Type Short String) that will provide the default answer when a user opens a new project that contains this question. Environment.GetFolderPath() is a function that is provided by the Microsoft .Net Framework that can get folders on a user’s local computer. In this case it retrieves the location of “My Documents” (which is located in a different folder on every computer for every user). To this it appends the “Visual Studio Projects” folder, and to this it appends the name of the current project, which is set by the user when they create a new project.

The end result is that when a user creates a new project with this meta-data question the default value for where to place code will be: “[My Documents]\Visual Studio Documents\[Project Name].”

UserEditable

Question Name: UserEditable
Question: “Should the user be able to update this field?”
Result (what the answer will be used for): “If yes then the edit page will display edit controls for this field, otherwise it will not. This question applies to the editability of foreign keys as well as data fields.”
Answer Type: Boolean (i.e. yes/no)
Relates To: Columns
Default Confidence: (how likely the pre-generated answer is to be correct) Fairly Likely

Because this meta-data question relates to columns it would normally be asked for every column of every table. However, the question code has another element to it that tells Blue Ink whether to ask the question or not. The relevant question code for this question is simply:

mblnAskQuestion = rowColumn.Updatable;
mobjDefaultValue = rowColumn.Updatable;

The first line says to only ask this question for fields that are updateable in the database and the second line says that the default value for the question should always be true if the database column is updateable and false otherwise.

Thus for a date stamp field (which always contains the last updated date, but is not directly editable), this question will not even be asked. If the template that writes the edit page asks if a date stamp field is editable it will get a “no” response. If the same template asks whether a regular updateable field is editable it will retrieve the user’s answer to the question which will always be yes by default.

Summary

Meta-data is to Blue Ink what nouns are to the English language. Meta-data only holds information that can be acted on by templates; meta-data does not do anything in and of itself. There are two types of meta-data that Blue Ink uses: database meta-data, which consists of information that Blue Ink gathers from the database of a Blue Ink project, and questions and answers meta-data, which Blue Ink gathers from the user of a Blue Ink project. The information Blue Ink gathers from the database consists of tables, columns, and relationships between tables. This information serves as the foundation for an entire Blue Ink project.

The information Blue Ink gathers from the user is in the form of answers to meta-data questions. When a user downloads a template solution they also download meta-data questions (or alternatively they can always add meta-data questions to an existing template solution) that ask questions based on the database schema. These questions can apply to different parts of the database (e.g. table specific or column specific questions). What makes this form of Blue Ink meta-data especially unique is that they can also pre-generate default values using Blue Ink Runtime Code that a question author can set. Anyone generating an application with Blue Ink can then answer the questions and modify the default values. When the Blue Ink project is generated, the templates will have access to all the meta-data for the project and they can use that information when generating code.

Database Meta-Data

Blue Ink gathers information about a database when a Blue Ink project is created. It connects to Database Management Systems (DBMS) (e.g. Microsoft SQL Server, Oracle, MS Access) to retrieve a database schema. It stores this information internally in a proprietary format that a Blue Ink user has full access to through templates.

When Blue Ink downloads a database it analyses the database and infers the type of each table. Each table may be either a lookup table, an associative table, or an entity. This information becomes a basis for the answers to many of the default meta-data questions (lookup tables typically are only ever dropdowns that do not necessarily need insert & update operations, associative tables are normally just pass-through tables that may be deleted or created but rarely modified to relate two entities and entities are tables that require update, insert, or view detail operations).

Blue Ink retrieves information for each column such as its null-ability, whether it is auto-incrementing, its precision, scale and length, whether it is updateable, and what data type it has. Blue Ink has a sophisticated method of determining the data type, which can be different for every DBMS, and mapping it internally to other common data types such as Microsoft C# language data types or XML’s XSD data types. These mappings relieve the template writer from having to worry about what data type a column actually is by allowing them to simply say what language they intend to write code for.

Questions & Answers

Meta-data questions allow template designers to ask arbitrary questions about a database schema to the users of a Blue Ink project. The answers to these question can then be used in templates to better customize the template output.

Meta-data questions are an element of template solutions (thus template designers typically create questions). A given template solution may have any number of meta-data questions, and a meta-data question may be shared among several template solutions (a template designer may a pre-existing question to their template solution). Questions exist independently of their answers in database projects, so a question may be answered differently for each blue ink project.

The following fields must be entered when adding a new question to a template solution:

Result

It is important to describe to the user what the result of her answer will produce on the code. Separating this out into a separate field ensures that a question author will not forget to describe the result.

Relates To

Questions may relate to the following parts of a database:

  • The Database
  • Tables
  • Columns
  • Incoming Relationships
  • Outgoing Relationships

Questions relating to the database will only be asked once (since there can be only one database per Blue Ink project). Questions relating to tables will be asked for every table in a user’s database, and columns will be asked for each column. Incoming relationships refer to (child) tables that have a foreign key to the current table, and outgoing relationships refer to the foreign keys that the current table has that point to related (parent) tables.

Answer Types

Currently answer types for a question are either Boolean, short string, or long string. Questions with a Boolean answer type may only be answered with yes/no values, and questions with short string (single line response) or long string (multi line response) answer types may only be answered with textual answers.

Nested Questions

Questions may be nested to form a tree-like structure of question. This allows child questions to be notified when the answer of a parent question changes. This allows for questions like “Would you like Blue Ink to generate the code to handle security in your application” to have a set of sub questions such as “Which table in your database will hold users?” When a user answers the parent question it would notify the child questions that could turn on or off whether they need to be asked or not (mblnAskQuestion).

Multiple Answers

Questions may be able to have multiple answers if they are marked to allow it. Multiple answers may be valuable in circumstances where a question designer wants to capture multiple business rules for each table.

Confidence

Confidence for a question describes how likely the pre-generated default value is to be correct. Typically entering a default confidence for a question is sufficient (in the example above it is very likely that the answer to the ClassLibraryProjectLocation question is correct).

Sometimes it is can only be known at run-time what the confidence of a particular answer will be. In this case the confidence can be set by the question code. Consider a question that asks what the natural language singular (i.e. not plural) name for a table is. If the question code can figure out that that most tables are named with plural names then it can with some accuracy drop any final “s” in a table name to make it singular. However, when some table names end in consonants the likelihood for pre-generating the correct natural name drops since it appears the name may already be in the singular. Thus the question code could set the confidence lower.

Default Values for Answers

The most important aspect of the way Blue Ink handles meta-data is its ability to pre-generate default values for meta-data. This speeds a developer’s time to build an application immensely, especially when the answers are more correct than not. With default values, questions and answers begin to function more as an ability to customize an outputted application that has already been build than as laborious work that must be completed prior to building an application.

Question Code

Question code is the mechanism for setting question values, the most important of which is default answer values, when a Blue Ink project needs answers to questions. Question code is currently Microsoft C# code (although it could be any language that will run under the Microsoft .Net Framework such as Visual Basic.Net) that is entered by a question designer when creating a question that can then be published with a template solution and used by developers who choose to download that template solution for their projects. When a developer answers questions, or when they generate their Blue Ink project into an application, Blue Ink tries to compile their question code using the compiler provided by Microsoft’s reflection namespace.

After a question has been compiled it is instantiated once for each part of the database it applies to (questions that apply to tables will be instantiated once per table) and a reference to the part of the database a question is instantiated for will be passed into the question code instance. For instance if there is a Customer and an Order table in a database and a question that relates to tables, the question will be instantiated twice, once instance will receive a reference to the Customer table and one instance will receive a reference to the Order table. The question instance can then make decisions about how to set its default value, whether or not to ask the question for this part of the database, and optionally how confident it is about its default answer, based on the information provided to it.

Templates

Section Five will open with an example of a Blue Ink Template and will follow with a template summary description and then move to more detailed template information. The more detailed information will consist of information on how templates are grouped, the attributes of template in Blue Ink, and the meat of templates: template code. The section will close with some example uses of templates.

Example

Templates are inherently more complex than questions because they are almost entirely code-based, but the following example is designed to demonstrate a more simple view of what templates can do.

Select All Stored Procedure

Stored procedures are compiled pieces of code that reside in a database to speed access to data. The following example is a small part of one template that Blue Ink provides with its default .Net template solution that writes stored procedures. The goal of this example is to write a single file with the following text for every table in a database:

CREATE PROCEDURE dbo.usp_[table]_SelectAll
select [column1], [column2], … [columnN]
from [table]

Running the output on a database should result in creating a stored procedure for every table that when run will selects all rows. The template to accomplish this would have the following characteristics.

Template Name: SelectAll
Execution Frequency: Once (as opposed to running the template for each table)
Execution Result: (what to do with the resulting text) Write To File – Always Overwrite
Language: T-Sql

The relevant template code for this example would look like the following C# programming code.

1: public void Execute(MdrDataSet tdsMdr, MdrDataSet.DatabasesRow rowDb) {
2:	// instantiate a string builder to hold the code we are outputting
3:	sb = new StringBuilder(1000);
4:	// never ignore results (ie always write the file)
5:	mblnIgnoreResults = false;
6:	// retrieve the “ClassLibraryProjectLocation” meta-data answer
7:	string strProjectLocation =
8:		tdsMdr.FindAnswer("ClassLibraryProjectLocation").TextAnswer;
9:	string strFileName = "GenerateSelectAllSp.sql";
10:	// set the file name that the execution results should be written to
11:	FileName =  String.Format("{0}\\{1}", strProjectLocation, strFileName);1
12:
13:	// for each table
14:	foreach (MdrDataSet.DbTablesRow rowTable in rowDb.GetDbTablesRows()) {
15:		// hold the table name in a variable
16:		string strTableName = rowTable.TableName;
17:		// write line #1
18:		sb.AppendFormat(
19:			“CREATE PROCEDURE dbo.usp_{0}_SelectAll\r\n”, strTableName);
20:		// write “select [column #1]”
21:		sb.AppendFormat(“select {0}”, rowTable.GetColumnsRows()[0].ColumnName);
22:		// for each column in the current table
23:		foreach (MdrDataSet.ColumnsRow rowColumn in rowTable.GetColumnsRows()) {
24:			string strColumnName = rowColumn.ColumnName;
25:			sb.AppendFormat(“, {0}”, strColumnName);
26:		} // end for each column
27:
28:		sb.AppendFormat(“\r\n from {0}”, strTableName);
29:
30:	} // end for each table
31:} // end function

While the code sample does not need to be understood in detail there are a couple of important points to take away. Specifically on lines #7 and #8 the template retrieves the Answer to the “ClassLibraryProjectLocation” meta-data question. Note that this question from the previous section defaults to a sub-folder of the user’s “My Documents” folder, however the user could have overwritten this answer to be, for instance, on a network drive. The template then uses this information to specify what folder and file to output its code to.

The other important point of the sample is the way in which the template code loops through every column of every table in the database. Line #1 says that this template expects to be passed a reference to a database, line #14 then loops through every table in the database, and line #23 loops through every column of the current table. Throughout all this iteration a large string is being built with the calls to sb.Append or sb.AppendFormat.

After running this code Blue Ink will extract the string that has been created, that is stored in the variable sb, and will write it to the location specified by the variable FileName.

Summary

If meta-data is the equivalent of nouns to the English language, then templates are the equivalent of verbs. Templates use the meta-data that Blue Ink has gathered to output text output such as programming code. Blue Ink currently implements templates in a unique way by using C# code that is compiled and run when a Blue Ink project generates code.

Template Groupings

To help organize templates Blue Ink requires they be grouped. Templates belong to Template Projects, which typically would represent one project in a large solution such as the user interface tier, or the data access tier. Template projects are then grouped into template solutions which represent a group of projects that are intended to work together. One Blue Ink project (which contains only one database) can contain multiple template solutions.

Template Attributes

Execution Frequency

Execution frequency refers to how often to generate a template when generating a Blue Ink project. A template can be executed once, in which case a reference to the database will be passed in to the template code, or once per table, in which case for each Table Blue Ink will execute the template code and pass a reference to the current table.

Execution Result

The primary objective of executing template code is to create text (generally programming code). The execution result attribute says what to do with the resulting text. The following options are available:

  • Display on Screen
  • Write to File – Always Overwrite
  • Write to File – Write Once
  • Write to File – Prompt if Changed

The options are fairly self-explanatory. Changed refers to whether the file has changed since Blue Ink last generated it, in other words whether a developer has made manual changes to the file.

Language

Language refers to what the output type of the template will be. Selecting this attribute helps use the appropriate data type when the template refers to a particular data type.

Template Code

The template code is the most important part of a template. The template code is essentially the instructions for what to write.

Template Class

The template code must be organized into a class by the name of Template that must have an Execute method and three members: sb, mblnIgnoreResults, and mstrFileName.

StringBuilder

The sb class member is a StringBuilder class that holds all output that a template will write. After running the execute method the Blue Ink program expects to find the resulting code in this member.

IgnoreResults

The mblnIgnoreResults member determines whether to use the results in sb or not. If mblnIgnoreResults is set to true, then no file will be written or displayed on the screen for that call to the Execute method.

FileName

If mblnIgnoreResults is not true, and the Template Execution Result is not set to display on screen, then Blue Ink will write the results of this call to the Execute method to the location in the mstrFileName member.

Access to Meta-Data

Meta-data is accessible to template code through a data store, specifically a typed dataset, which is made available to template code. This data store is of type MdrDataSet and it holds Blue Ink’s cache of tables, columns, relationships, meta-data questions, and user-entered answers. A copy of MdrDataSet is passed as a parameter to the template along with a reference to either the database or a particular table depending on the value of ExecutionFrequency. As is observable in the example this data can then be used to add text to the StringBuilder with an infinite amount of variation.

Access to Answer Meta-Data

Access to answer meta-data is performed through the MdrDataSet that is passed to template code. One could go through the Answers table that is provided in the MdrDataSet, but there are several methods available to the MdrDataSet called FindAnswer that are designed to access answer meta-data more easily. The sample template uses the version of FindAnswer for questions that relate to databases, but there are other versions that relate to tables, columns, and incoming & outgoing relationships.

Examples of Uses for Templates

Because of the versatility of Blue Ink’s implementation of templates and meta-data, a template solution can perform much more than simply creating a Microsoft .Net web application. A template solution could be developed to write a Java 2 Enterprise Edition (J2EE) web application or another database enabled desktop or other application, or write user documentation for a system where the documentation pieces are stored in meta-data answers. There are also many Database Administrator (DBA) tasks that could be greatly aided by the use of Blue Ink such as writing triggers to track all changes to a database or helping data migration, or writing technical database documentation.

The Blue Ink Net


Figure 2 Blue Ink’s Distributed Architecture Blue Ink consists of client applications that communicate with the Blue Ink Net server though the Internet

Section Four will provide a summary of Blue Ink’s unique client-server architecture and the benefits of template sharing and community services that this architecture provides.

Summary

In addition to the template and meta-data aspects that make Blue Ink unique, Blue Ink also uses web services to integrate the Internet directly into the Blue Ink application. In fact, Blue Ink was designed from the ground up with to take advantage of the power of the Internet. Blue Ink consists of two applications: the Blue Ink Net Server (aka Blue Ink Net) and Blue Ink Clients. Blue Ink Clients are downloadable from the Blue Ink website and are installed on a developer’s machine. The clients communicate with the Blue Ink Net through the Internet using web services. The client application performs the bulk of the work, but due to its connection to Blue Ink Net it supports many additional features including: community based support, message boards, the ability to provide feedback, feature requests, template sharing, template reviews, and defect tracking.

Template Sharing

Template sharing is a powerful and unique feature of Blue Ink. While other products may have the ability to share templates on-line, Blue Ink takes this a step further by directly allowing the sharing of templates through the application. The process starts when a developer modifies an existing template solution or creates a new one and decides to publish the unique template. When this occurs the template is available to other developers to download and try. As other developers in the community use these unique community created template solutions they may post comments about the template solutions or rate them.

Community Services

While a user community is nothing new to many applications, just like template sharing, Blue Ink takes the concept a step further by directly integrating the user community into the Blue Ink application by using web services. Specifically Blue Ink provides such features as news, message boards, community based support, feature requests, and the ability to provide feedback directly from within Blue Ink.

Conclusion

This paper has covered what the Blue Ink software development tool is and how it works. The article has included Blue Ink's approach to meta-data and templates, it's key concepts and design goals, and additionally touched on what The Blue Ink Net is. If you still have questions please do not hesitate to contact us.





FAQ's:

What is JAG?

Can I still use Microsoft Visual Studio?

What is the Blue Ink Net?


Related Links:

Blue Ink Overview

Just-In-Time Application Generation


ARTICLES

What is Rapid Application Development?


QUESTIONS?

Call us toll free:
(877) 756-3595

Or Visit Forums

    

Copyright © 2017 Automated Architecture, Inc. All rights reserved.