All posts by keyeng TEE

the founder of gney, solution architect for grassland system. for detailed profile,

Grassland & PermasSky components

As mentioned previously, Grassland is not just a Desktop application but a combination of different Grassland components, be it web or desktop to suit different needs. Before we dive into how complicated scenario that Grassland can cater. Let’s us have some brief introduction to these basic components to facilitate our future discussions.

client6 Grassland Standalone

Basic components as a Standalone application or software can be run on computers. However, it is not limited to work alone. But through multi-client configuration. Few Standalone actually can connect to same database.

client Grassland Client

Client component is application to be installed and run in client machine. It can only works with the connection to server.

server Grassland Server

Server component is application or service running in server machine. It handles requests from other components.

microServer Grassland Micro Web Server (MWS)

It is a micro web service handles external HTTP request. Generally it does not work alone. Usually it attached with either Standalone, Client or Server.

ISSserver PermasSky

PermasSky is Generic Web / Cloud Service that hosted on Server Machine. It usually handles requests from web pages through browser or even from iOS or Android Apps.




What Grassland is not

After the last article posted, we gotten some attention as well as some feedbacks. There are discussions going on in different communitities and forums.

We hav summarized most frequent misconceptions.

This is NOT just a prototyping tool.
This is a actual development tool to build solution. Through Grassland, we have built numerous solutions. From POS, Invoicing, Accounting, CRM, ERP, MRP, Shop Floor System, Workshop System, Service Center Management, Queue System, websites and many more..
Not only that, single development effort on standalone solution (installation on single PC) can be scaled easily and smoothly to multiple clients (all applications connects to same database), server-client (client applications connects to server then server connects to database) or even more complex configurations.

Anyway, we won’t denied that Grassland can be used as a very effective prototyping tool or to do proof of concept considered the speeds of building application and its flexibility.

This is NOT what commonly saw Rapid Application Development (RAD) toolkit
Grassland is not drag and drop controls and components toolkits with nice themes. In fact those are used on User Interface(UI) or Presentation Layer. Grassland is not solely focused on UI. It actually consisting of components from Data Persistence Layer, Domain Layer, Service Layer, Business Layer, Communication Layer, Presentation Layer, and Cross Cutting Concerns.

But do not be scare of by the complexity suggested by those names, all are putting together using defaults and convention. Meaning you go in deep when really in need, but generally do not hav to touch those layers. What we suggesting here is the possibilities.

Now we answer why? Why Grassland covers all the scope and aspect of application development? The answer is Speed, Reliability, Affordable, Manageability.

To Grassland, these are interlinked. Grassland Dev working hard on making each statement, each expression, each line of code contains as much as information possible without sacrificing the readability. Fewer number of line to code improves the speed, easiness in maintaining or extending application.

This is NOT an Application Builder.
If you looking for building application through wizards or user interface, creating application without single line of code. Then it definitely disappoints you. The target user is developer. Grassland uniquely designed linearly scale development system, ironically the better you are as programmer or software developer the more you can harness from the power and flexibility from Grassland.

So, it is not Spreadsheet, or any other Data tables tool either. It requires programming. Grassland did it through aggressively reducing the architecture effort and skills needed. It is the abstraction of general application.


Hope above clear some of you doubt regarding Grassland.  Please tell us your option, or something else that confuses you regarding Grassland. Have a nice day!



30-Storey building built in 15 Days, how long needed for a simple Todo Application?

Things are moving a lot faster nowadays.  The expectation on speedy delivery is higher in all areas, including logistics, manufacturing, software development and in this case construction. However,  people expect more other than speed, but quality, consistency, as well as predictability.

Similar to Industrial Revolution in manufacturing, the transition to new processes of software development is necessary.

To build in speed, a well and careful planning, and of course standardization are required.

Yes, the building looks decent and similar to most of the buildings you can find in the city. However, we must admit that it serves its purpose well, just like most of the buildings can be found everywhere. Cost-benefit equation must be balanced on both side.

Looking back, how fast we can in building an application, let’s say simple to do list application, a fully usable application, storing records and updating records. We are not looking for most fanciful desktop application, but with decent look.

The answer given by Grassland System is 73 lines of C# code. Yes, these 73 lines of code must describe precisely the data to be stored, behavior and the look.

Actually I did not count line by line. It is done by VisualStudio. Not sure why TodoState is counted as 0 line though.

So how much can be done from this code. This is the result.

In this simple example, only C# code is needed. No WPF/Xaml knowledge is required.

This is how we spend our line of codes. Refer to Code Metric Result screenshot.

We start with most important part: Domain for Todo

    public class Todo : GrasslandAuditable
        public string Content { get; set; }
        public DateTime? Deadline { get; set; }
        public TodoState TodoState { get; set; }
        public DateTime? StartTime { get; set; }
        public string Location { get; set; }

Most of the code are self-explanatory. Only [ItemIdentifier] is used to allow user to identify particular item, say for example: ItemCode of a product, name of customer etc.  The domain will is used to generate database be it SQL Compact, MS SQL, MySQL through EntityFramework. Any kind of Database you can used so long you have the connector.

Following MLAWD model, we move on to Menu

    [SideBar(Header = "Todo", Icon = "Calendar", Color = "CornFlowerBlue")]
    public class TodoMenuV : MenuItemV { }

    public class TodoMenuVM : MenuItemVM
        public TodoMenuVM()
            var newquery = new UriQuery();
            newquery.Add("new", "new");

            this.SetMenuAction("To Dos", () => NavigationService.RequestList(typeof(TodosV), DisplayMode.View))
                .SetMenuAction("Manage To Dos", () => NavigationService.RequestList(typeof(TodosV), DisplayMode.Edit))
                .SetMenuAction("New To Do", () => NavigationService.RequestWork(typeof(TodoEditV), newquery));

Menu is simple accordion, where developer only need to set the name of the link and the action. Notice the attribute is used to describe the look of the Bar ie. Image/Icon, Name and Color.

Now is L – List

    public class TodosV : ListV { }

    public class TodosVM : ListVM<Todo>
        public TodosVM()
            : base(null, typeof(TodoEditV), typeof(TodoActionV))
            this.SetColumn(x => x.Content, width: -1)
                .SetColumn(x => x.TodoState, searchable: false)
                .SetColumn(x => x.Deadline)
                .SetColumn(x => x.StartTime);

Through the use of fluent interface and lambda expression.  List can be setup in seconds and mistake can be lowered to minimum. Notice, width is set to -1 means to 1* in xaml width, where as positive means pixel. As we pass in W – Work in List, so it wired up automatically when user allowed to update, create or delete particular items.

ListVM comprises of few components each manage certain functionality such as Search & Filter and Sort, Pagination, Multiselection,  Delete, Update, Create, Selection handler etc.

ListVM (VM means ViewModel by the way) are not talking to Database directly. It calls through Service Interface and in this case, default service instance will be generated and injected in run time.

Now, let’s move on to A – Action

List sometimes trigger action which is a bar on top. Specific action can be done on particular selected item.

    [RibbonContextual("To Do List", "LawnGreen")]
    public class TodoActionV : ActionV { }

    public class TodoActionVM : GrasslandMenuVM<Todo>
        [GrasslandActionTab(GroupName = "Operation",
            Icon = "Pencil", Color = "CornFlowerBlue")]
        private void Edit()
            var query = new UriQuery();
            query.Add("id", Model.Id.ToString());
            NavigationService.RequestNavigateAction(typeof(TodoEditV), query);

        [GrasslandActionTab(GroupName = "State",
            LargeImage = "/Grassland.Infrastructure;component/Images/document_mark_as_final.png")]
        private void inProgress()
            Model.TodoState = TodoState.InProgress;

        private bool canInProgress()
            return Model.TodoState != TodoState.InProgress;

        [GrasslandActionTab(GroupName = "State",
            LargeImage = "/Grassland.Infrastructure;component/Images/document_mark_as_final.png")]
        private void completed()
            Model.TodoState = TodoState.Completed;

RibbonContextual is used to describe the look of Action tab. As for View Model, Action button is generated based on assigned attribute, this draws the similarity of WebAPI controller where attribute describes exposed interface to the user. AutoCommand attribute actually just a shortcut to generate delegate command and ICommand. This small attribute really help us in remove great number boilerplate codes and improves readability.
our Non-UI & Non-WPF Developer, web Developer or pure C# Developer finds more comfortable this way, as they do not have knowledge about ICommand or DelegateCommand by PRISM. Note, ‘Can’ and ‘Show’ method can be added to determine whether showing the button or enable/disable the button.

    public class TodoEditV : WorkV
        public TodoEditV()
            AutoField.SetFieldType(this, GenerationType.Edit);

    public class TodoEditVM : WorkVM<Todo>
        public TodoEditVM()
                .AddField(() => Model.Location)
                .AddField(() => Model.TodoState, newLine: true)
                .AddField(() => Model.Deadline, newLine: true)
                .AddField(() => Model.Content, 3, true, 9, 80);

Now is the W – Work. In this example, we only create a edit interface. Of course, we can add an view interface too. SetFieldType let the UI/WPF changes the field type to Editing.
Same case with list, using fluent interface and lambda expression, we can add in the field easily. Field are generated based on type. Through the use of UIHint attribute, and DataType attribute, sometimes we can change the resulted field type of display as well as edit. For example, combo box to radio button, date picker or time picker or date time picker.

WorkV (View) is the view for standard form. Its comprises of different components. Responsive Grid, a special WPF Grid system same as the Grid System commonly used in Web design, particularly Bootstrap. This concept inevitably helps us in realizing UI generattion. Same with most popular system, ResponsiveGrid using 12 column system and by default all fields occupied 3 column. The other components the DynamicControls. It generates Label, Display and Editor. Display and Editor is then combine in AutoField which changes to Display to Editor or vice versa based on attached dependency property set.

There is it. About 51 lines of code described here. The rest of 22 lines of C# code is more of initializing database, setting up a module that Grassland System can recognize.

The example here is using Top Level of Grassland API which doing all User Interfaces generation particularly helpful those developer not so into XAML/WPF, MVVM. For those have knowledge about WPF/XAML, there is always a choice to substituting it with customized UserControl and ViewModel class.

We are looking for technology evangelist worldwide to work together improving Grassland as well as bringing affordable and reliable software solution to people who need it in a very short time frame.

Feel free to contact me directly at or whatsapp me @+60167328125 OR @+6591330938











Grassland’s MLAWD™ Design Model



MLAWD is the design model used by Grassland System. It means for both Grassland Designer and Grassland User.  To Grassland Designer, it serves as conceptual model when developing Grassland applications. On the other hand, it acts as a way point to easily guide user to use Grassland application without the need to digging into the detail.

For what is MLAWD? In Grassland, MLAWD are both Model and View Model, describe specific both User Interface and area of responsibilities.

  • M – Menu
  • L – List
  • A – Action
  • W – Work
  • D – Document


Navigation purposes of course. It serves as generally starting point for user to start their activities. Besides, it also can be use as a shortcut to something. For example, search document text box in Menu can be added to provide shortcut to particular document. Notifications can be added as well to give indication of particular status


List is used to display records in bulk, providing functions such as search, pagination, sort etc.


Certain actions can be applied or act on particular item, such as changing payment status, printing the record etc.


Work is where user will be spending most of time with. It is where user creating or editing records. However, it is not only limited to managing records. It is a general working area for the software.


Document is where document, report get printed, export to different format or email out. User get to preview the document before further action could be taken.


MLAWD flow
MLAWD flow

MLAWD flow diagram describes possible flows for different scenario. As shown, it can be easily followed and understood by Grassland designer and it translate to consistent application workflow where user have lesser learning curve.

For example, in an invoicing software.

to create invoice, we use MWD. Menu-Work-Document.

Menu should have a ‘new invoice’ link which leads user to Work which display New Invoice Form. After the form submitted, Document should show the ‘Invoice’ just created for user to print or email.

To go further, to edit invoice, we can opt for MLWD, Menu-List-Work-Document.

Menu direct user to a List of Invoice, from there user select that particular Invoice, there user can edit it in Work. After submitted, Document plays its role in showing edited Invoice.

One more example, to cancel Invoice, we choose MLA. Menu-List-Action.

Same as previous case after invoice selected. User choose ‘Cancel’ from the Action and no further action required.

These are possible flows that prevent complexity yet ensure high degree of flexibility.

  • ML
  • MLA
  • MLAW
  • MLW
  • MLWD
  • MW
  • MWD
  • MD








Grassland gets new Interface

I have been working on improving Grassland User Interface these few days. Our objective is to make Grassland Framework base design more inline with current design trend, flat and less intrusive yet able to cover most if not all functionalities offered by previous interface.

new design for grassland

The first noticeable change would be the menu bar,  we remove ‘outlook bar’ and completely redesign and development new menu bar which is quite commonly used in web application.

previous design

The older design have been with us quite sometime. It works well for us. However, there are few issues that raised by users as well as internally prompt us to redesign the menu bar.

As it is called outlook, indeed it is very powerful. It comes with a lot of features. For features refer to and here Odyssey indeed did an excellent job to duplicate all outlook bar features. I’m impressed.

Initially when we integrating Outlook Bar, our intention is to tap on existing outlook user have. So they can easily relate back to Grassland Applications especially when start with Business Applications. Most of our corporate customers have Outlook experience.  The decision to use Outlook Bar is not tough.

However, as times goes by, Grassland Applications expanding reach to other users, Consumers, less Outlook experience, at the same time, we notice they are growing number of corporate not using MS Outlook. New Grassland Application user start to have problem in using our Menu Bar.

The first issue complexity. For example the distance between menu section selection and the menu itself in old design. It get worse when we have long list of menu sections. There are users actually asking where to look for after they clicking the section they want and yes in user experience concept. It decreases explorability of the system. Users have problem in identifying where to go next after section is clicked. There are other operations proven to be difficulty for novice users or beginners such as hiding extra section at the bottom, when collapsed, clicking bar particular section pops up the menu.

Then is the aesthetic, in web development, flat design, and material design has become mature and becoming the main trend. Of course, we want to bring it into Grassland System, Desktop-based application.  Compare to previous design, we reduce greatly number of gradients, rounded corners, and shadows including Ribbon Bar at the top.

To make the whole application to look more appealing and easy to use. We change most of the button into embedded image button with icon only. Only those important action now remain as button, such as OK, Accept button.

Menu Bar

Basically is just a accordion with some modifications.  Accordion is widely use as menu in web application. We making it collapsible. When mouse over, the menu itself pops up at the side. So user can easily access the menu without extra click. We add a vertical scroll bar at the left and redesign the look so it looks more fit into current design. Also, normally added scroll bar will result layout shift and rearrange. It could be annoying when you expand particular menu or sub-menu and result and whole menu shift.

New menu bar

We increase greatly the size of button so to allow better usage on tablet and touch screen. We still considering whether the size of each sub menu sharing the same size of the main menu. Currently we still keep it as Hyperlink. One major consideration is the number of links. If converting them all, it will have a very long menu bar.

Ribbon Bar

Initially we thought of just replacing with current office 2007 look to Office 2013 Style for WPF Ribbon Bar. However, we discovered that there is no such style can be found on the web. Of course, keeping the same Office 2007 Ribbon look is not an option, especially with the new Menu Bar. So I left with few costly options: replacing other ribbon control and overidding the style and template myself.

Back in 2013, we did replacing Odyssey  Ribbon Bar to MS WPF Ribbon Bar. Now we did consider Fluent.Ribbon it looks promising. The only concern the effort to integrating in. We are ok with the features offered, to be exact more than we need. It is just the look. Besides, we actually have plan to redesign and replace ribbon bar to have a easier and better design of ‘Action Bar’

Hence, I go for second option for the moment to modify the style and template manually. The make things more complicated. I can not get the generic template for MS Ribbon. Not sure why. So have to extract them manually and redo the binding. The process is tedious. Since have to redo, I am thinking might as well make it even flatter and homogeneous look as part of Grassland.

Give ribbon bar a new look

Now should look more cohesive with Menu Bar even though not perfect yet.






Grassland Component: Configuration System

Let’s dive into more technical discussion as well as coding to have more understanding on how Grassland works.

A good application or system often than not have configuration, whether to configure certain behavior, sms gateway, colors and many other things.

NOTE: The example that we usually give is Desktop-based Application, however, generally it is applicable to Web-based system as well.

Grassland is designed to take care of managing, setting, and distribution of configuration. Yes, distribution of configuration in Server-Client environment. In Grassland Architecture Design, we defined Configuration, as something stored in database or persists in other form e.g. temporary file and it is subjected to be distributed to client application. These configurations are Application Level Configuration.

Please do not confuse with System Settings or Config File. Those are system-level settings like Server IP, or configure which modules to be initialized.

So what is the big deal with Configuration? Like the following should do it right?

    public class Configuration
        public const int NumberOfRetry1 = 5;

        public static int NumberOfRetry2 { get; set; }
        public static int NumberOfRetry3 = 3;

        //using application settings
        public int NumberOfRetry4
                return Settings.Default.NumberOfRetry4;

        public const string NumberOfRetry5 = "NumberOfRetry5";
        public void GetNumberOfRetry5()
            //then get something from the database using the const
            var configHere = Database.GetConfiguration(NumberOfRetry5);

        //string with hierarchy
        public const string RetrieveProductNumberOfRetry6 = "RetrieveProduct.NumberOfRetry6";
        public void GetNumberOfRetry6()
            //then get something from the database using the const
            var configHere = Database.GetConfiguration(NumberOfRetry6);

NumberOfRetry1: Need recompile to change
NumberOfRetry2: Need every start of the program, likely need recompile
NumberOfRetry3: Need recompile to change
NumberOfRetry4: Using Application Settings, seems good but how to distribute it to client? Need to persist into database.
NumberOfRetry5: No hierarchy, hard to manage configurations when they getting more.
NumberOfRetry6: Seems good, can build class around to group configuration together. A lot of repetitive to have additional configuration. Inheritance? and configuration value type?

Grassland is designed to be scalable, versatile. Those examples above may only good for small application, but not appopriatae for big or huge enterprise application. Hence those does not fit our purpose. Simply, we need something more powerful yet flexible. Here are our proposal:
1. Easy to use and create additional settings
2. Able to trace the configuration easily (VS, just press Shift + F12, get all the usage)
3. Distribution of these configuration from server to client
4. Client can override selected configurations
5. Inheritance
6. Default value when nothing is set
7. Viewable in database
8. No constant field, no static field, can be testable
9. Type Safe for configuration value
and the list can grow further.

Most importantly, Grassland System is a domain ignorant system, a clay. System must able to handle configuration from module that might only be known at run time. This is a major challenge in grassland design in every single component.

Here is what we come out in the end:

public class ConfigurationSystemExample
        //inject configuration manager
        public IConfigurationManager ConfigurationManager { get; set; }

        public void GetConfiguration()
            //specify the configuration set
            var result = ConfigurationManager.Set<SampleConfiguration>()
                //retrieve the value
                .Get(x => x.Name);

            //for nested value
            var result2 = ConfigurationManager.Set<SampleConfiguration>()
                .Get(x => x.ProductCollection.PageSize);

            //to configure
                //with property type information from reference class
                .Configure(x => x.ProductCollection.NumberOfRetry, 4);

    public class SampleConfiguration
        public string Name { get; set; }
        public int MaximumPages { get; set; }

        //inheritance, with hierarchy as well
        public TemplateConfig ProductCollection { get; set; }
        public TemplateConfig CustomerCollection { get; set; }

    public class TemplateConfig
        //each client application override server's distributed configuration by setting the value,
        //else it will return back server's value
        public int NumberOfRetry { get; set; }
        //default value when it is not configured
        public int PageSize { get; set; }

This how grassland’s design works and its design philosophy. We want to have something simple yet powerful that can work most of the time.
Creating configuration can be simple as create plain class, on top of that you get benefit of inheritance and hierarchical information and every configurable value is type safe.
For beginner, only 2 interfaces and 2 attributes need be learnt: retrieve and configure; default value and local (if they are building distributed software)

If using Grassland desktop-based, to make things even better. Grassland System automatically generates to configuration user interface.

    //just put attribute below to opt-in for generation
    public class CRMConfiguration
        public bool Enable { get; set; }
        public ProductCategoryConfiguration ProductCategory { get; set; }
        public BarcodeConfiguration Barcode { get; set; }
        public InventoryConfiguration Inventory { get; set; }
        public DeliveringConfiguration Delivering { get; set; }
        public CreditNoteConfiguration CreditNote { get; set; }
        public InvoicingConfiguration Invoicing { get; set; }
        public PricingConfiguration Pricing { get; set; }
        public SalesPersonConfiguration SalesPerson { get; set; }
        public CustomerConfiguration Customer { get; set; }
        public RetailConfiguration Retail { get; set; }
        public CashBillConfiguration CashBill { get; set; }
        public QuotationConfiguration Quotation { get; set; }
        public SalesOrderConfiguration SalesOrder { get; set; }
        public ReceiptConfiguration Receipt { get; set; }
        public ReportConfiguration Report { get; set; }
from flickr by Tyler McCall

In search of ways to build Dream into Reality

In previous article A Dream of Every Developer, we share the dream of developing a unique software framework to enable making ideas and concepts into actual working system in no time and challenges to material this concept.

Started only with the idea, I begin looking into possible areas of application. Besides, to check whether there are any existing idea or even product being offered currently. We found nothing close to it. The closest could be MS Access or Visual Studio Light Switch. But they are not the direction we going into.  We are building a system or a framework for quick software development, rapid application development, true one. I named it ‘Grassland System’. However, we facing difficulty in explaining the concept. Then we started to explain using terms like ‘Disposable Software’, ‘Software Template’, “System Template’.

Finally through discussion with a friend of mine, gotten a easier explanation:

from flickr by Tyler McCall
from flickr by Tyler McCall

Grassland System is like clay to form the desired system by shaping it. It has most of the ingredients you most of the time.

To design such system, we need to find out 2 things; what to make the clay, and what this clay supposed to make to.

Easy question but the essence of the whole concept. Without proper definition and accurate scope, surely the whole project destined to fail. I start focusing on second question, what this clay supposed to make to? or suppose to turn into? Of course, without constraint, I want it can be turned into anything and everything and this is impossible at least at the moment or first stage. Come back to the reality, it should be at least good for building tool, data entry, utilities, and business software like invoicing, pos etc.

So to start off we focus on small software like tools first, I extracted standard pattern of small and these disposable software based on years of working in software development. It gives me an overview of what generally needed for those type of software. Then we drafted the design and comes the birth of Grassland. After that, we start offer customized software services, by developing customized software, not only we can get deeper look on actual requirements from the market but only can take the opportunity to refine Grassland.

Slowly and steadily, through Grassland we build numerous applications be it small, big or huge, we built Material Planning for Factory, Enterprise Resource Planing for Factory, Queue Management System, Attendance System, Shop Floor, Invoicing, Customer Relationship Management, Inventory, Service System, Websites, Leasing Management, Issue Management, and even Grassland Deployment System is built with Grassland!