In the following example we revisited the sample project where we created a Chart Object with Telerik Reporting at runtime. Every time I create Chart objects at design time, I find myself going under the hood in one way or the other, this to enhance customization. Needless to say, I am not stating that design time does not enable us for customization. However, I rather enjoy going directly to the API. My perception is that in instances this might be a faster route.
Scaffolding all the client side models under an AngularJS application could be a laborious task. Even more laborious could become if we are to make changes to our model server side, and then have those changes be reflected client side. Now Imagine you are to have a good number of these models under a single application, moreover you are the only developer making this application a reality.
The technique exposed here is not always applicable. Nonetheless, It could be utilized in some application which could end up saving a great degree of time and heartache. In my scenario, the application utilized a NoSQL database on the back end. For most applications with this nature (NoSQL Databases such as RavenDB, MongoDB or DynamoDB) It is easy to implement what I am about to discuss.
A quick glance to my previous posts would show my liking to insightful quotes. I admire those who had the wonderful ability to recite them by memory.
Unfortunately, I have never possessed such a dazzling memory. Thus, I seek the ability to making quotes accessible hoping to increase my ability of sounding more insightful.
The example I am about to introduce, elaborates on one of my favorites C# open source libraries I have found – the HTML Agility Pack. This is a .NET code library that allows you to parse "out of the web" HTML files. The parser is very tolerant with "real world" malformed HTML. The object model is very similar to what proposes System.Xml, but for HTML documents.
I used HTML Agility Pack and SQLlite, in order to build a lightweight database that I could utilized in my mobile application. SQLlite is used constantly in mobile applications today, thus it is a good storage technology to be informed about.
In a later posts, I may introduce the discussion on creating Jquery Mobile controls on the mobile applications. However, In this post I will stay within the scope of the HTML Agility Pack Library.
If you were to build a SQLlite table similar to the one presented in this post, and if building it from a .NET application, It is important to download the SQLite drivers for .NET and the SQLlite Browser
“Today I Shed my Old Skin” - Og Mandino. This statement introduces the first scroll defined in one of the most compelling books I have ever red, The Greatest Salesman in the World. It has also been said - “There ought to be a better way.” I love this statement because at times it becomes the principle for moving us forward.
Representing time in a linear axis is a very ancient exercise; even more ancient that the conception of the Cartesian plane. Linear representation of time, indisputably, will continue to be an indispensable tradition in the illustration of change.
In programming, it is a habit to use OLE Automation Date (OADate), a numerical representation of time, in order to talk to the richest APIs and bring about the graphical representation of time. The approach has been adequate and successful at times, yet in instances it has lacked the flexibility that the representation of time inheritably has by nature.
“Today I shed my old Skin.” And I introduced a slight different approach to the OADate when dealing with time and time reference. This approach consists of time indexing, or the representation of time through simple integer unit.
The first time I was introduced to iBook, I was far from embracing this whole new reading concept.
I have yet the vivid memory of my parent quoting Spanish philosopher Marcelino Mendez y Pelayo – “Que lastima tenerme que morir, cuando me queda tanto por leer” It translates “It Is a shame I have to die, with so many books yet to read”
I cannot avoid wondering whether Mendez y Pelayo would have welcome iBooks, and sacrifice the touch of the paper fiber at the tips of his hands with ease.
Despite early hesitations of the community to give up the millenary art of flipping a page, Book-Like interfaces have been able to engage audiences in a very profound way.
This is an area of a lot of question and hassle. During the Telerik Reporting Webinar for Quarter 2, 2012. One of the areas of inquiries was the use of Telerik Reporting with MVVM pattern.
It is possible you would find yourself in a scenario of implementing Telerik Reporting into an existing MVVM project. It is also possible that the requirements of this project consist of avoiding changes to the existing WPF views. The views may play a very important role in generating the report data. Below I provided a brief strategy for bringing Telerik Reporting and MVVM pattern together, when feeding a report from an existing view is necessary.
Best practice is to create the Report in a class library, this practice apply even when producing reports for MVVM pattern. The only key variation is to create a constructor capable of receiving the report parameters or objects needed for the report to render, i.e:
Jim Rohn stated “Don’t wish it were easier, wish you were better.” Yet, I find myself resilient in desiring for things not only to be easier but also for them to be enjoyable. It is not my goal to challenge Jim Rohn wisdom, however, I believe I will adopt a similar principle “Don’t wish it were easier, wish it be enjoyable.”
In my pilgrimage as a software developer I find excitement when stumbling upon an Application Programming Interface (API) that make application development fun and enjoyable. In a previous post, I had the opportunity to show a brief task of creating a Telerik Report table. In this post, I take on a chart creation at run time. This area is one of the most enjoyable of the Teleirk Repoting API.
Like in any charting API available, it is imperative to understand the objects or components that bring about a chart object. In the section below, I attempt to explain a few chart components, although, within the context of the Telerik Report API. Understanding these will save up a substantial amount of time, this principle holds true for any API we may encounter.