Without a doubt the single most asked question I hear is: "When is version 6 coming?" The answer too often eludes me. But today I am happy to say... it's on the way.
After going through some staffing changes, version 6 took some hits in terms of both scope and delivery schedule. I have been avoiding answering that most prevalent question because, I just did not want to misguide our loyal user community. Amid all the forum rumors of the lack of delivery of new versions, I did not want to add to the confusion.
Truth be told we have been working on version 6 all along and it is shaping up for a release. Version 6 offers a range of new features that should make dbQwikSite generated web sites more powerful and flexible than ever before. The list is not yet finalized, as we try to squeeze in those last few features before freezing development to begin testing in earnest. V6 focus is on two areas, making pages more powerful for the end user and on design flexibility to allow designers greater control on the look of generated pages.
In the area of more powerful pages, look forward to: multiple categories, in-line edit/update, group actions against multiple selected records, new user controls, and enhanced search capabilities.
In the area of design you can expect to see: custom add/update form support, enhanced CSS classes, customizable HTML sections on all pages.
The above lists are not comprehensive, but should give you an idea of what to expect. As far as delivery dates, these will depend on testing results. Tomorrow is the date set to set the final scope and thus the development target deadline. After that some testing, and finally general release. It's hard to say exactly when these will occur, but stay tuned to this blog for news and updates.
Beyond V6. Many will note that V6 does not include true dot net code generation. That's because we wanted to do that right, and rather than shoehorning dot net functionality into the more classic paradigm of dbQwikSite generated pages, we decided to come out with an all-new version of dbQwikSite for dot net. That in no way infers that we are dropping PHP support. Quite the contrary, we are planning to migrate PHP into the same framework as the dot net product, leveraging a class oriented code generation in both languages. This will open new doors to PHP users, as well as Microsoft platform users who wish to extend and enhance dbQwikSite generated code.
Showing posts with label ASP. Show all posts
Showing posts with label ASP. Show all posts
Tuesday, July 07, 2009
Friday, May 23, 2008
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.
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.
Friday, February 01, 2008
Google Checkout++ new in dbQwikSite 5.2.3.0
Today we released dbQwikSite 5.2.3.0. This release concentrates on enhancing payment gateway support. There are two major payment gateway enhancement offered in this release. The first is the addition of support for Google Checkout and the second is the ability to add your own payment gateways to dbQwikSite.
Those who know Google Checkout, likely know that there are two flavors of checkout; a single charge checkout and a multi-item checkout. The good news is that dbQwikSite support both flavors. If you just want to bill the bottom line, then the single item checkout is what you want. If you want to have an itemized billing then the multi-item checkout is just the ticket.
When it comes to native payment gateway support, the list now includes: PayPal, Google Checkout, Authorize.net, World Pay, SecPay, and VCS. However that is only the beginning, now you can add your own payment gateway support to dbQwikSite. Under the covers, we have added a payment gateway plug-in architecture, which means that not only TheDevShop, but also you, can add new payment gateways without the need for programming. So, virtually any payment gateway can be supported by dbQwikSite.
Adding a new payment gateway involves defining XML and XSL files. There are basically 2 steps, define the user input needed during design this is done using an XML document, and define an XSL that transforms saved dbQwikSite model into a web script. To create payment gateways you likely need some proficiently in XML Style Sheets. The great part is that these gateway plug-ins not project specific, that means that they can be shared amongst users. There is no “compiling” or “updating” involved, just drop the XML/XSL in the right folder and “presto” a new payment gateway. If you do happen to delve into creating a payment gateway plug-in and want to share it, just send the files to support and we will add them to the plug-in download page. Other users, I am sure, will be most appreciative. Documentation on how to create payment gateway plug-ins can be found on the dbQwikSite download page http://www.dbqwiksite.com/download.html in the “Other Downloads” section.
On other news, many people are asking about Developer Edition. It is definitely still on the product road map. The release has been delayed as we decided to do some serious R & D into two areas: “proper” .net support and Web 2.0 support. As that effort winds down we turn our attention back to developer edition. We have just set up our first beta tester and we are starting to move forward on the development of Developer Edition. An later this year, you should see some great stuff as a result of our R & D being incorporated into the product.
Those who know Google Checkout, likely know that there are two flavors of checkout; a single charge checkout and a multi-item checkout. The good news is that dbQwikSite support both flavors. If you just want to bill the bottom line, then the single item checkout is what you want. If you want to have an itemized billing then the multi-item checkout is just the ticket.
When it comes to native payment gateway support, the list now includes: PayPal, Google Checkout, Authorize.net, World Pay, SecPay, and VCS. However that is only the beginning, now you can add your own payment gateway support to dbQwikSite. Under the covers, we have added a payment gateway plug-in architecture, which means that not only TheDevShop, but also you, can add new payment gateways without the need for programming. So, virtually any payment gateway can be supported by dbQwikSite.
Adding a new payment gateway involves defining XML and XSL files. There are basically 2 steps, define the user input needed during design this is done using an XML document, and define an XSL that transforms saved dbQwikSite model into a web script. To create payment gateways you likely need some proficiently in XML Style Sheets. The great part is that these gateway plug-ins not project specific, that means that they can be shared amongst users. There is no “compiling” or “updating” involved, just drop the XML/XSL in the right folder and “presto” a new payment gateway. If you do happen to delve into creating a payment gateway plug-in and want to share it, just send the files to support and we will add them to the plug-in download page. Other users, I am sure, will be most appreciative. Documentation on how to create payment gateway plug-ins can be found on the dbQwikSite download page http://www.dbqwiksite.com/download.html in the “Other Downloads” section.
On other news, many people are asking about Developer Edition. It is definitely still on the product road map. The release has been delayed as we decided to do some serious R & D into two areas: “proper” .net support and Web 2.0 support. As that effort winds down we turn our attention back to developer edition. We have just set up our first beta tester and we are starting to move forward on the development of Developer Edition. An later this year, you should see some great stuff as a result of our R & D being incorporated into the product.
Subscribe to:
Posts (Atom)