BestPicker.com is a new kind of search engine that demonstrates the power of Konsensys DreamBeans®. 100% of the HTML, JavaScript, CSS, and server-side Java code, database tables, and database queries on that web site were automatically generated by using DreamBeans.
By generating the entire web site, database, and database queries very quickly by selecting icons and setting properties on the icons, I was able spend most of my time focusing on the development of the web crawler and expert system that populate the database tables. Where do you want to spend you time? Do you want to spend your time grinding out HTML, JavaScript, CSS, XML, SQL, Java, etc. for your web site? Or do you want to focus you time on the application-specific code?
No other product can generate complex web/database applications without writing a lot code. For example, creating the database queries and HTML table for the Side-by-Side product comparison tables on the BestPicker.com web site was done by adding adding some icons representing database tables to a form icon, adding an "XY_table" icon to the form icon, and setting a few properties to specify the size of table, columns, etc. -- maybe 10 minutes of my time. To create similar table using tools like Spring or Visual Studio, would require weeks to write and debug!
NOTE: This is not a tool for generating your company home pages, etc. DreamBeans is tool to develop database-driven applications that use a browser window rather than your PC's application windows for display and input.
posted by George 3:48 AM
Unfortunately version 1.2.2554 is a major redesign due to a severe bug in Microsoft's Internet Explorer that Microsoft seems unwilling to fix. Namely, the well known location.replace function in Javascript corrupts UTF-8 pages. It works properly in FireFox, etc. -- but not in IE.
The ignoramuses at Microsoft think that we should be using AJAX instead of replace. I call them ignoramuses because they are definitely ignorant if they think AJAX can be used instead. Consider the simple use-case of using AJAX to replace a form including thousands of lines of Javascript associated with that form's elements. In that case, all browsers will use the Javascript from the previous page rather than the replaced Javascript if the Javascript functions have the same name (e.g., verifyInput())... And newly loaded Javascript fails to execute. That is definitely not what anone wants. Working around that limitation requires HUGE effort.
And while we're on the subject of AJAX, DreamBeans has used AJAX for years. But, it still required the use of Javascrpt replace() to make a web app act like an app rather than linked document pages. Sometimes you need to replace the entire web page (including Javascript) without changing the history. For example, a form asks you to click a button to submit your order, which then takes you to a confirmation page. Hitting the "back" should NOT take you back to the previous page asking you submit your order!
So, DreamBeans used AJAX to get the new web page and then did a replace("javascript:newpage()"); to replace the web page contents. That has worked fine for years!
However, when a DreamBeans customer reported a problem displaying UTF-8 characters in form fields (where the data came from a database), I finally tracked down the problem to Javascript replace() in IE. Like I said before works okay in FireFire fox. After searhing the internet I find out that this is a well known problem with IE's browsers...
It's taken weeks of effort to re-design DreamBeans to work-around Mirosoft's bug in the replace function. I'm normally not a Microsoft hater. I find that for every bug in Microsoft's browser that I have had to work-around, I have found three or four in Mozilla/FireFox over the years (but FireFox is starting to close that gap in quality race). But, right now I am really pissed off at Microsoft. "replace" is a very basic function in Javascript that should just work. It's bad enough that Javascript escape() doesn't work with UTF-8 characters (you have to use encodeURIComponent now). Escape also worked fine in DreamBeans generated apps until customers put UTF-8 in form elements.
"Instead of fixing the Javascript functions we have, why don't we invent some new f... way of doing it, so that millions of programmers around the world can each waste hundreds of hours each of their time. Oh, and if they complain, we'll make the new way a W3C or some other standard, so that the old way that didn't work really wasn't a bug after all"!!! Jerks!
posted by George 9:06 AM
Version 1.2.2554 adds some support for UTF-8 (internationalization). All web pages created a DreamBeans-generated application are now UTF-8. Further, UTF-8 storage/retrieval from databases is supported.
posted by George 9:01 AM
Version 1.2.2442 is a major redesign from 1.2.2338. The new design stores session information in the web page (client-side) rather than saving the session information of each user on the server. This new design has two major advantages:
- Reliability/Security -- Context/state switching between users is rock-solid (no chance of someone accidentally seeing your information on your web page). And, if a server goes down for some reason, the context/state is not lost. When the server is back up or failover to another server will read the context/state from the web page request.
- Scalability -- The new design is visibly faster (roughly twice as fast). And, performance will degrade much more gracefully when there are a large number of concurrent users.
I didn't want to implement the new design until version 1.3, but I ran into a serious context switching bug that would be very difficult to fix using the old design. So, I decided to bite the bullet and add the new design. You can expect a few bug fixes over the new week or two to stabilize the new design.
-George
posted by George 10:03 AM
I've been looking at the latest versions of technology like Java Server Faces, AspectJ, Hibernate, Spring Framework, and Seam to determine if DreamBeans can make use of them.
Java Server Faces is pretty good. It finally provides JSP pages with some higher level constructs to quickly create a user interfaces with data bindings. And some IDEs like NetBeans and JBuilder provide nice GUI's to contruct the user interface and generate the JSF code. I am considering having DreamBeans generate JSF code rather a Java servlet. No decision has been made yet.
AspectJ might have some application in DreamBeans for logging and database transactions.
I would love to take advantage of something like Hibernate to leverage the work of others in abstracting away JDBC ideosyncracies of various databases. But Hibernate is basically for persistance of Java objects, treating each member of a class as field in a relational table. The problem is that this makes it nearly impossible to do something like:
Join joinTable = new Join(department, person);
And DreamBeans has that capability. In fact, each relational operation in DreamBeans is a class, e.g., Join, OuterJoin, Union, etc. But, this would not be possible if layered on Hibernate.
Spring and Seam provide "frameworks" for generating "enterprise" applications. The idea is that certain design patterns make it possible to create these "enterprise" applications quickly. Both are seriously flawed in design, with result that you end up writing a lot more code and XML to wire objects together into an application than if you just wrote some code using some well known design patterns.
Spring and Seam require writing a lot XML, besides writing a lot code. Only, masochists like writing XML. Normal people, just want point-and-click, have the something generated (and don't care if is XML or something else). I don't even like read XML, let alone write it. That's one of the reasons I developed DreamBeans, it generates the web.xml, server.xml, etc. automatically. I got better things to do with my time than performing mundane tasks like writing XML, when there is no good reason why it can't be generated automatically.
A "simple" example in Seam's getting started documentation using JSF takes half hour to an hour to code in Java and XML. The same application can be created in 2 or 3 minutes in DreamBeans without writing a single line of code or XML. DreamBeans generates all the Java code and XML for you. It looks like Seam and Spring are steps backwards.
I plan to open source version 2 of DreamBeans (version 1 was grown organically and needs to be rearchitected underneath). I think at that point, retro techologies like Struts, JSP/ASP, Seam, and Spring are going to become forgotten technologies.
http://www.konsensys.com
-George
posted by George 4:32 PM
DreamBeans is starting to get pretty stable (some fairly large applications using a dozens of database tables and dozens of forms with trees and tables are all working well). Everything basically works except a new feature, XY_Table, that is displayed in icon palette but not yet documented. The XY_Table will documented after development is complete.
http://www.konsensys.com
-George
posted by George 4:24 PM
The reason why FeatureRequest, etc. have not gone into beta test yet, is that that there are still some compatibility issues, particularly with Firefox (AJAX-bug) and Oracle (JDBC cursor issue), for which I need to find work-arounds.
In the mean time, a new maintenance release of DreamBeans with many fixes should be posted in a couple of weeks. And I may decide to release FeatureRequest and just put in the release notes that it does not work with Oracle and FireFox due bugs in their products.
-George
http://www.konsensys.com
posted by George 10:27 AM
Version 1.2.1879 beta release of DreamBeans® contains fixes 62 bug fixes since the last note. A new version of DreamBeans® with one or two fixes are being posted every week or two.
The reason why FeatureRequest, etc. have not gone into beta test yet, is that that there are still some compatibility issues, particularly with Firefox (AJAX-bug) and Oracle (JDBC cursor issue), for which I need to find work-arounds.
posted by George 10:57 AM
Version 1.2.1817 beta release of DreamBeans® contains mostly fixes to the user interface.
DreamSuite has been delayed due to several reasons:
- An ill-fated attempt to portDreamBeans® source code to the lanugage c#. I was hoping to make DreamBeans® more attractive to the Windows developer, who doesn't know anything about Java and Java webservers. But, Microsoft's code to translate Java to C# left so many things to be fixed that the task was too daunting for the current level of resources.
- Embedding a webserver (Jetty) directly into DreamBeans®. Now, image buttons and other graphics display properly for a complete What-You-See-Is-What-You-Get (WYSIWG) experience.
- A redesign of the FeatureRequest and DefectTracker so that the two are more tightly integrated. Product components and features entered into the FeatureRequest component, are visible in the DefectTracker (once a feature is marked as implemented in FeatureRequest, then problem reports can be filed against the feature). Further, the new design provides a basis for some project management (resource and schedule estimation and tracking). Work on FeatureRequest and DefectTracker is now active.
posted by George 10:01 AM