Mashing it up with dbQwikSite

What is a Mashup? For me it conjures up images of a bunch of cooks, all mashing away at a pot of boiled potatoes. But in the world of web development it means piecing together discreet units of available web functionality into a single integrated application.

Wikipedia defines a mash up as:

Mashup (web application hybrid)
In technology, a mashup is a web application that combines data from more than one source into a single integrated tool; an example is the use of cartographic data from Google Maps to add location information to real-estate data, thereby creating a new and distinct web service that was not originally provided by either source.

Before I say anything more let me show you are screen shot of something I was playing with in dbQwikSite before I looked up the term in Wikipedia.

What you are looking at is a dbQwikSite page that I have in our Real Estate test project in which I added a Windows® Live Map. I had created, almost verbatim, the Wikipedia definition of a MashUp. The listing data is all in the dbQwikSite Real Estate database, but the Map is pulled in from Microsoft. After copying sample code from the Live Maps interactive SDK and fiddling with the custom code a bit, miracles of miracles I made a MashUp in about 15 minutes.

Well that’s not all, check this out. I made this over two months ago, when I was testing Developer Edition. This page uses Google Charts APIs to produce graphs of a data page generated by dbQwikSite.

Here’s another graph… ok, so it’s not a “true” MashUp by definitions. It is using Microsoft’s Siverlight 2 technology which is not a web service, but I didn’t have to know anything about coding graphs, just enough to call the JavaScripts and pass the right parameters. It’s just so pretty, I could not resist showing it off.

So today, it dawned on me, I was creating MashUps and I didn’t even know it. At first I said to myself “Naw, it can’t be that easy, MashUps are the realm of web gurus. I must be missing something.” So off to Wikipedia I went, to delve into the real meaning of MashUps. I stopped reading after I read the example I quoted earlier. “Wow! This is cool!” I thought to myself. There’s something big going on here, code generation plus MashUps what an awesome, powerful combination.

By themselves these web services like Google Charts and Windows Maps are interesting. But they only become valuable when placed within a meaningful context. Let’s face it you are much more interested in a map to the new house you are going to buy than just “a map”. And you are likely much more interested in a plot of your sales than a graph of data that is not yours.

What MashUp developers do is take all these nice “gadgets” and knit them into an application to enhance their applications. These guys are the guys writing the back end processing, digging data out of their databases and integrating these fantastic web services to enrich their web applications. But, wait a minute; dbQwikSite users know that they don’t have to code the back end. The code generator of dbQwikSite does that for you. So we just made the job of creating MashUp web sites magnitudes easier. Let dbQwikSite churn out the back end code and a basic interface then add a few lines of custom code to call web services and we are making MashUps in the blink of an eye.

While I still think that MashUp is a funny term, I do agree that the concept is valid and very powerful. Even more powerful is when you marry that technology to the dbQwikSite code generation technology to web services technology in MashUps. You can produce some pretty advanced websites at lighting speeds by “Mashing it Up” with dbQwikSite.

Rave Review from Bangkok Post

This Wednesday, then I opened my morning paper I was pleasantly surprised to find that Thailand's largest newspaper had done a review of dbQwikSite by their resident Web Design columnist. It's quite a positive review so I thought I would share it with you.
Read the full review here. (updated link Jun 9 2008)

Here are a few kudos from the article: (in the event that the above link gets "retired")

I do not normally get excited about a code generation tool but I have watched this local product evolve and it just keeps getting better.

Remember this is a local Thai product that rivals the bigger US equivalents and is of course a lot less expensive

If you are looking for a deceptively inexpensive web site builder and don't want to pay someone to build one for you then I recommend that you try dbQwikSite.

If you are wondering: No I'm not on the board or payroll - this is just a great product.

Smart XSL Snippets: Mini Code Generators

Today we released dbQwikSite 5.3.0.3. By most counts, this is a simple maintenance release but hiding in the list of updates there appears one rather mundane looking item entitled “xsl snippet support”. Looks pretty small and simple on the surface, but this single new feature infers some pretty powerful implications. It means that you can make mini-code generators inside the dbQwikSite generation framework.

Let’s take a closer look at this feature. We call it XSL code snippets. What it means that in any of the 150-plus custom code insert points found in Developer Edition, you can write an XSL(T) template. But this is not a template transforming xml data to format HTML in the browser. These XSL templates work a code generation time and they work against the XML of your project. This is really cool, because it means that you can access all the design information stored in your project model to generate code snippets. It takes a bit of time to wrap your mind around the concept but once you do the implications are quite interesting.

Let’s step back a bit. Let’s say we are working with Developer edition, which in itself is very powerful. What we can do is add in new script code to enhance our generated pages. We can do all kinds of neat things by typing in “static” script syntax into insert points / events. Ok, so we can understand adding code snippets to our pages. But what about a “smart snippet”? One that can write the code snippet for you. One that can know about other pages in your project, one that can react to the design setting contained in your project model. That’s exactly what the XSL snippets offer. And when you think about it, that’s exactly what the dbQwikSite code generation engines does, translates your design setting to code. But what’s extra cool about the XSL snippets is that it is you who defines what is to be generated, rather than the code generation engine itself. Now, that’s pretty advanced flexibility, and you won’t find this type of power in any competing tool. If you are lucky you may get “events” and then only a handful at best. With dbQwikSite you get over 150 “events” and you get smart snippets that can actually generate code themselves.

So why would we ever write a smart snippet. There are a number of situations that make smart snippets indispensible. The first one that comes to mind is to be able to have code snippets that is “project aware”, for example you may want to create code that adds new page flows, but without the names of the other pages, you could not so this, smart snippets can gather information from the project XML. Another situation is to make a snippet that is settings aware, for example you want it to create code differently if the page is secured or not, or if the group has a shopping cart. These are examples where smart snippets can outperform their “static” counterparts. You can write snippets that are not project specific, they are generic and self adjusting between projects. Another example could be a multi-scripting language snippet. For example rather than writing two snippets, one in ASP and one PHP and maintaining, managing and distributing both snippets, you have only one smart snippet, that automatically detects the generation language and inserts the correct language syntax.

Granted, writing smart snippets may not be for everyone. You can get along quite well inserting ordinary “static” script code into your insert points. To write a smart snippet, you need an understanding of the project XML and XSL as well as the code that you want to generate. But if you are into these technologies, you may be interested in a few of the details of the mechanics of XSL smart snippets. To create a smart snippet, you do as you would for any other kind of code snippet. But instead of typing in script syntax you type in an XSL template, and check the box that says this is a XSL snippet. During code generation, your XSL is executed and the output is placed into the insert point that invokes the snippet. Your snippet is passed the entire DOM of project XML, as well as two parameters. The two parameters are the Page ID and the Item ID (when applicable), giving you the context of the call to your XSL. You can easily work your way through the DOM to access Groups, Pages and other project objects to produce the code syntax you need.

That’s it, one small item in a maintenance release, the gives you an extremely powerful capability, a capability that you won’t find elsewhere. And even if you are not up to writing your own smarts snippets others will write and share smart snippets and you can benefit. This is yet another way that we are providing ways for the user community to contribute to the development of dbQwikSite. With our first step about a year ago providing an XML project model, to support for user defined project reports, addition of a plug-in architecture, user definable payment processing page generation, code snippets and now smart snippets. You can look forward to dbQwikSite becoming more powerful and more flexible with every release.

Web Developer Edition Now Available

dbQwikSite Developer Edition is now available for download. Developer Edition makes its debut as part of the release of 5.3. In a nutshell, Developer addition let’s you add your own custom code into your website projects. The concept is simple, but the ramifications are profound. It means that you can now extend and enhance your generated pages. Developer edition opens the door to a realm of possibilities.

I have been pushing for Developer Edition for almost a year now. I knew that I wanted it, I knew that it would be kewel (cool). What I didn’t know was exactly what it meant to web developers and web designers until I started testing it. It was like having my hands untied, or taking the rev limiter off your sports car. Now, I could do things that I had seen on other sites, but were beyond the capabilities of code generation.

Don’t get me wrong, I love the other editions of dbQwikSite, and every time I use them I am grateful that I don’t have to hand code thousands of lines of code. I always amazed what I can do in 10 minutes with this software. But, being the overachiever I am, I always want more! More features, more cool stuff, more flexibility. That’s exactly what I got with dbQwikSite Developer Edition. To date, I had to wait for the developers to have the time to code new features. I know from emails of our users that I am not the only one that wished that we could provide features faster. With Developer Edition, the game changed overnight. The only one that was holding back features was me, not the developers. I wanted graphs, I added graphs! I wanted conditional highlighting, I added conditional highlighting! I wanted a search on the data lists page, I added it! You get the idea, I am sure. It was instant gratification. It was the freedom to do much, much more without giving up all the “cushy” benefits of my beloved code generator.

Here is a copy of the promotional video I made to introduce Developer Edition.
The quality a bit blurry here, there is bigger one on the home page of dbQwikSite

If I have caught your interest, then you likely want to know more about what’s inside the new edition. Developer looks the same as other editions. What’s new is a “In-line code editor”. When you are working with a page, you click the “custom code” option in the popup menus. What you see is the generated source code. Inside the code, there are input boxes we call “insert points” in which you can type your own custom code. There are over 150 of these insert points at key places in the processing. Some are “events” like “after open dataset” and “on focus” of a control. Others do not related directly to an event, but more to places in code where you may want to add your own code, an example is “CSS Includes” it is not an event, but you may wish to include your own CSS files at this point in the source code. As you may have gathered, there are insert points for both client and server side scripting.

Besides the code editor, there are several reports designed specifically for web developer in mind edition such as the custom code report. You don’t need to hunt through each page looking for custom code in your project. Just run this handy report, and you’ll know exactly what custom code you have in your project. Another powerhouse feature is a complete custom code versioning mechanism built right into dbQwikSite. Every time you modify a custom code block, a new version is saved into your project. You can use the Version Management Interactive Report to view a complete history of your custom code blocks. What’s more, you can even “revert” back to previous versions if you discover you somehow messed things up along the way. Behind the scenes there have been some changes to the way pages are generated to allow better control of presentation by JavaScript. Ids are assigned to page elements; the contents of the page are now embedded in layout matrix of divs that let you insert content around generated elements. Variable name abstractions have been added to let you code using variable names that are readable and do not get changed when you do design changes.

If you want to give developer a try, you need the new executable program file. To get the most recent exe new users can download PE and existing users can run live update. All editions let you preview Developer’s entire user interface. If you want to test drive the code generation, just run in Full Trial mode. Upgrade pricing is available to all version 5 users. Details can be found on the web site.

Code Generators are Not Evil

Recently I had someone ask me “I want to learn to make web sites. Tell, me honestly, if I buy your product, won’t it make me lazy?” I thought that was an interesting question. I combed the web and found several articles about how “real web coders” should not use code generators and that by using a code generator you will never develop the skills of a “real web developer”. I can appreciate some of the comments made in these blogs. But what strikes me as ironic is that these articles are reminiscent, of arguments made 30 years about the “evils” of high level programming languages such as COBOL and BASIC. I remember the arguments that if developers did not understand the assembly code generated, they were not really knowing what they were doing, and that some sort of evil end would come to the software developed by these “ignorant” coders using high level tools. Who could possibly create software when you were completely out of touch about what they were really doing at a binary level.

Well, I openly admit that using high level tools may produce code that is less efficient as hand coding every line, carefully scrutinizing every function and operation. But let’s step back and take a lesson from history of technology. First, things first… there was no “dooms day.” Programs written by “ignorant” programmers using high level programming languages, worked. What’s more, nobody codes in assembler any more, except in very niche applications. What is true is that high level programming languages empowered more people to produce more helpful software that has been successfully adopted by millions of users around the globe. How many programs do we use today were developed using assembler? “Very Few” is the answer.

History shows us that advancement in tools that help deliver the software that people want are not “evil.” Nor is it true that the people using these tools are “ignorant”. I would argue that the people using empowering tools may be “ignorant” about the technical details of what is happening under the covers, BUT they are actually “enlightened” individuals knowing more about the end product. Making technology more usable empowers people with knowledge about the final “solution” to become more involved in producing the solution. Moreover, people using these tools are able to focus more about the “what” the applications should do over the “how” to do it. The end result is better solutions, faster. There is no evil in this. And just because I don’t know how to repair my car, does not mean that I cannot use it to do some very productive things… like getting to work. Software tools are getting more advanced, and like our cars, we can use them to reach our “software destinations” without all being certified mechanics.

I personally grew up on code generators, in the 80’s “case tools” were all the rage. I leaned to design better systems, by worrying less about the “how to build” and more about the “what to build”. I learned that, as a project manager, I could get more productivity from my team, in less time and to higher quality standards by using automated coding tools. I learned that most of the programmers where happier to concentrate on the desired business goals of the project than on the correct syntax for a particular line of code. And to acknowledge the “dooms sayers” that, yes, you cannot escape the technology and that performance still needs to be considered. But that said, it less of an issue than they would like to make it to be. By producing the solution faster, and testing it earlier, you can identify the performance bottlenecks and call in the hard-core techies to “save us all” as needed. But what I found is that, in reality, the performance issues may only be relevant in 15% of an application. The other 85% can operate happily as is. Either there is no performance issue to begin with, or that this particular part of the system is used only by a few users, or that used so infrequently that it is not worth the investment to make it high performance.

Now I’ll share with you the answer I gave to the question “will it make me lazy”. My answer is “No, it will make you productive.” Why would we think it is “lazy” to not do things the hard way? To me, if you are achieving your goals, faster that’s hardly the definition of lazy. For a non-technical user to undertake the task of making a website is hardly lazy. For a professional web developer to not waste time hand coding pages that can be generated out-of-the-box is not lazy. To direct your energy in to value added features rather than debugging code is not lazy. Using the right tools for the job is “smart” not lazy.

If your objective is to learn to code, then a code generator is not going to prevent that from happening. Only you will prevent yourself from learning. Back to my car analogy, just because I can drive my car does not prevent me from learning to be a mechanic. In fact, true story, as a teen I learned all the basics of car mechanics from a small book and my old car. I spent a lot of time learning by doing, starting small, with fixing hoses to eventually rebuilding much of the engine and brake system. Having a car to tinker with did not impede my learning, it helped me learn. Likewise having a code generator to tinker with can actually be a learning aid. By enabling features, studying the code generated you can learn in an interactive, “by example” manner. In the same way that I worked my way “up” in my car mechanic skills; you can work your way up the technical learning curve as you have the need and inclination. But the great part is you can still have your working web site while you are learning.

With the introduction of dbQwikSite Developer Edition, I would say that using dbQwikSite code generator as a learning aid is even more practical than ever before. Developer Edition let’s you insert your own custom code into the generated code. So, you can “tinker” with your pages with ease. You can see how things are working in the code and add your own code to make your pages do more, adding features without having to be an expert. You can learn to code one-line-at-a-time while dbQwikSite fills in all the gaps. And, of course, if you are an expert in JavaScript or Server Side scripting you can make your generated pages do things only you can dream of.

To all the authors of all the blogs I read about “real programmers”, I offer the following counter points.
1) It is not every do-it-yourself web builder’s objective to become a coding guru
2) Understanding code is important but not more important than understanding the web site functionality that you are building.
3) If you bill or are paid by the hour, it would be professionally “negligent” to insist to hand code every single web page when there are tools available to enhance your productivity.
4) Coding is a means to an end, not an end into itself.
5) Don’t sweat it, “real programmers” are still needed, for all the “cool creative” stuff. Let the code generators do all the “boring repetitive” stuff.