Data Binding

Event Registration

Xml VS Json

Question still to be answered: Xml or Json as a UI modeling language?

Control Rendering From Templates

I din't want to hardcode the rendering part, so I decided to use html templates instead. Templates will be delivered as a part of the library, but it is a standard html which can be easily adjusted.

The Very First Draft

The idea should be clear enough from the screenshot, but I will add couple of remarks.

As I said, all UI will be rendered on the client by the library. Still you should be able to tell the library what to render. Options are:
- give it an html, which will be 'animated' by js. This will work only in the simplest scenarios. Once we get to the gridview, for example, we will have to generate the rows dynamically, based on the data received from the server.
- give it some kind of html templates, that then be completed by js. But it cannot be just any html. Js will be too dependent on what is exactly in this html to be able to process it correctly.
- use properties and parameters and set everything through the code. This is kind of java way, which has 4 IDE's and not a single one with the visual form editor. WinForms also use this appoach generating tons of ugly code in partial classes. For me it's just too much code that does not do anything.
- and finally, it could be some new markup (xml or json), that describes a UI in terms of windows and controls, similar to XAML.

I like this option because:
- this seems like the right abstraction level. If I am describing the treeview, why should I describe it as a bunch of divs and not call it treeview?
- this makes the markup independent of implementation.
- there is no data in this markup - only presentation. You will need to bind the data to the control before it is rendered.
- customers can customize UI, say, by adding they own fields
- this markup is easy to generate with the tools

Maybe it's too much words, but, as I said, the picture should be enough already.

The Future Web Application

Is it over? Is the battle between smart windows client and stupid web client over? Is it the smart web client who won it?

Let's face it: no one want rich client anymore, if it is a Windows client. Even Microsoft. Everyone wants to access applications from iPads, Samsung tablets and integrate them with their wikis and confluence pages.

It's time to bite the bullet. Say goodbye to the bad guy. Embrace the web.

OK, web. What does it mean, exactly? ASP.NET? ASP.NET MVC? Yes, I am a Microsoft-oriented developer, cannot really think of anything else.

This is what we have today.

The topmost layer of your application server tier (here for simplicity called 'MVC') generates HTML, spits it out to the client where js libraries ensure 'progressive enhancement'.

To hell with progressive enhancement. We are talking now about full-blown enterprise application, say, ERP system, in the web. There is no progressive enhancement, if you don't have javaScript, too bad, you have no ERP.

I must admit, ASP.NET MVC does a pretty good job helping me to produce the HTML out of my C# classes. But then the fairy tale ends and we enter the gates of hell: namely, model-view-controller paradigm going along with the stateless nature of the web so well. Actions are fine, but there is no road back, it's only forward. The whole UI lifecycle is a constant movement forward, from point A to B then to C and never, never back to A. 

You are on the customers list page, then you go to the next page to add a new customer, then you go to the list of customers. Not back to the list of customers, but to yet another list of customers. Drag along all your filter state, you'll never return to pick them up.

Want to save data? Postback the form. Oh, you are updating the grid? Put all your stuff in the form hidden field. No, honestly, I cannot live like this.

This is the future:

All the server calls are requests for the data, not the UI. REST is the protocol, JSON is a data format. Do I hear someone saying 'oData"?

And what do you know, we have a stateful client, in the web.

Missing piece, apparently, is a library, UI framework that could render the UI completely on the client and make the development easy. Guess what I am working on.

RedUI First Post

This is a blog dedicated to the RedUI project: rich UI client library written in js.

Why do we need one more UI framework?

Simply because no other framework is good enough. Honestly, I am a bit shocked that in our times there is still no gridview html tag. Or treeview, or listview, or datepicker. Coming from desktop applications world, this sounds like a stone age.

Surprisingly, this doesn't concern web developers much, neither does loosely typed syntax of js, the lingua franca of the web, for some reason. Neither the fact that there is no other choice, really.

But I don't want to spend so much time on UI as they do. I want to be able to ask for the treeview, bind it to the datasource and go on with implementing business features.

jQuery UI might be a solution sometime.
KendoUI looks great, but is ridiculously expensive.
Ext JS looks amazing, but also not cheap.

And there are billions of others, and most of them are crap. I need something of my own.