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; }

F&B Point of Sale System examples

Buttons and features
F&B POS: Buttons and features

The Point of Sale system is operated by only 17 keys (the numeric keypad on keyboard) and this is what makes it possible to take order of your customers using small device such as the mobile phone.

Followings are the examples of using the numeric keypad to take order, add special request from customer, takeaway order, issue bill and make payment. This may also be done directly on the screen when using a touch screen monitor.

F&B POS example 1: Take order
F&B POS example 1: Take order
F&B POS example 2: Add remark for order e.g. less ice, less sugar etc.
F&B POS example 2: Add remark for order e.g. less ice, less sugar etc.
F&B POS example 3: Takeaway order
F&B POS example 3: Takeaway order
F&B POS example 4: Add remark for takeaway order
F&B POS example 4: Add remark for takeaway order
F&B POS example 5: Change the quantity for selected item
F&B POS example 5: Change the quantity for selected item
F&B POS example 6: Bill F&B POS example 7: Payment
F&B POS example 6: Bill
F&B POS example 7: Payment



Designing and Developing POS – Continued

Previously, we talked about designing and developing POS from scratch. We have an interesting idea that translate num pad to fully functional POS operation. The benefits we gotten from the new design. Its advantages, Easy and Fast. Easy for new comer, Fast for advanced user.

Aside from that, a smooth transition from beginner to advanced. Less learning curve what you learn on first day, applicable to the work later on till you become advanced user. We notice that so many times from our customers experience. The experience is pleasant. At the start, beginner may using touch screen to press buttons or select product to the carts. As time goes by, they start to remember most of the codes and getting familiar with the process. Then they start working on Numpad, but may not entirely however they are in the direction of using Numpad solely.

Besides, with this design, if you have limited budget. You can start POS even without touch screen, of course you may face certain learning curve that either have to entirely using Numpad operation or using mouse which definitely slower.

Grassland POS is ambitious. Even we are design and develop at first in desktop. But definitely we are looking for more particularly Mobile and Tablet which is particularly important.

Same thing, we want to rethink mobile solution for POS, not entirely on its own but assist operation of Grassland POS. Besides, Kiosk, why not mobile ordering, order check etc especially for Food and Beverages Industry like restaurant. So the question would be how Mobile App for Grassland POS should be like, what is the different between from other vendor. What concept are we selling?

Something particularly attract our attention, we notice tablet maybe there are some vendors but they are very little mobile app for POS that we known off. Reason? Maybe something to do with limited screen space. Some tablet POS we come to know already trying very hard to sequencing everything into the 11inch display. Mobile phone, can be even worse. If you have a button of every possible action. Maybe you already have our answer now? SmartMov II!

At first, we are looking on possible solution on mobile, suddenly we realized that we already have a solution: moving SmartMov II to mobile phone. As SmartMov II, is proven to be working and receive good response from the market. There is little chance that it din work on mobile. Having only numpad on mobile phone, it fits the screen perfectly, easy to press, even with single hand. Besides, it will be smooth transition again from desktop user to mobile user. They can use interchangeably because is the same key stroke, same flow, nothing changes, virtually no learning curve.

FNB in real action






A Dream of every Developer

I am very enthusiastic in programming particularly in .NET where I started and very deep into GUI i.e. WPF in the starting, then go wider into other areas in WCF, database, designing, architecture, c#, design patterns etc. try to understand all concepts that I could and reading as much as I could while I am working in University.

After that, using these knowledge to put testing kits, demo tools for my professor. As you know, there are many of these software needed in that environment, you need to develop something for capturing data, analyzing the data, or interfacing for some devices and you can not have much time and budget to go source of similar application. Then I start to realize maybe there is something out that allow you to build application fast. I did found some, they called RAD, and you guess it, it is only User Interface Toolkits.

Then after, I got very lucky joining company that could put almost every I learn in previously to be in practice. Those knowledge and skill got proven and much of the effort are appreciated and result produced beyond expectation. Experience earned. I started to handle more design, and design and implement system and components. Then I realize again there is great in prototyping your design, at least proof of concept. Best if this can be shorten, or virtually eliminated.

These thoughts started forming shape. Hey, maybe we can have something for developer or novice or beginner to  develop fast, very fast and efficient. Ha I can see senior developer or architecture are smiling saying no way to have single architecture that fit every needs and solutions. Database can be different, can be network etc. But I look at it at another perspective, just something you can get in very short time without much cost, call it ‘Disposable’ and something can last and always extend so long it meets your demands within the budget and time frame. ‘Efficient, Effective, and Affordable’ and lastly lower the barrier to test out ideas and concepts, ‘Possibilities’. Forming the major pillars of Grassland Design. (Please take a lot on Grassland Manifesto for more information)

Soon after, is not hard to found that that developing a program that generates program is every software developer’s dream. Yet it could likely become a nightmare soon after. It is very hard to accomplish as the scope is wide and goal could be vague if not defined properly. Might end up to become another User Interface Toolkit (not true RAD). It is even harder when at the first the place it supposed to be domain knowledge ignorant. After all, it should be the mainframe for developing / prototyping software, application, and testing any new concept or ideas.

Stay tuned for the strategy to tackle the challenges.