As announced before on Visual WebGui.com, the 6.2.2 release which is expected to be released later this week will provide compatibility to MS Silverlight RC0/RTW.
As you probably know, Microsoft recently released a new version of Silverlight which provides almost no compatibility backwards to older Silverlight versions. This means that all the released VWG Silverlight applications will not work with this new MS Silverlight version.
Furthermore, Microsoft triggered an automatic update mechanism inside Internet Explorer to have the Silverlight ActiveX update without asking. As a result, all computers with MS Silverlight client installed on it have the new version, unless the user manually removed it.
Since Microsoft released this incompatible version, our Silverlight development team has been working very hard on modifying Visual WebGui to get in line with those changes and support the new MS version once again. We were also promised by Microsoft director in Silverlight group that this was the last back compatibility breaking.
Learn more about developing Silverlight Applications with Visual WebGui
On Nov 24 at 9am PT, Visual WebGui will be presenting another Webcast as part of the MSDN Webcast series:
Integrating Visual WebGui into Visual Studio Simplifies Development and Saves Time and Money
In this webcast, we will demonstrate the new integration, usability & compatibility features introduced with version 6.2.
Attend this webcast to learn how the Visual WebGui platform increases productivity when developing AJAX DHTML and Microsoft Silverlight applications, saving time and money. And learn about Visual WebGui's complete integration into the Microsoft Visual Studio development system, a consolidated installation process, and the opportunity to use Microsoft Visual Studio Express Editions for software evaluation and trials.
I would like to share with you the release announcement of Visual WebGui 6.2.1 SDK made last week by Gizmox.
The Visual Webgui SDK now incorporates both the DHTML and the Silverlight and enables to work with both .NET 2.0 and 3.5 on the same machine. In addition, the new release includes the new wrapper feature announced earlier.
Version 6.2 presented some important enhancements mainly to the developer experience as it introduced a complete integration into Visual Studio, a consolidated installation process and compatibility with Visual Studio Express edition and DharpDevelop.
Here is a more detailed about this version description:
New feature Summary
ASP.NET Control Wrapper wizard Asp.Net Wrapper wizard added to Visual WebGui infrastructure.
This wizard enhances Visual WebGui abilities and allows you to use any ASP.NET thirdparty control that you have and add it to you Visual WebGui application as an out ofthe box control. Making Visual WebGui applications even richer than before.
VWG-2721 Tabbing between controls bug solved
VWG-3097 Problems with Flow Layout Panel bug solved
VWG-3140 Integration package and source control problems solved
VWG-3189 Installation prerequisites warnings & errors issues fixed
VWG-3143 DateTimePicker in Time Format with ShowUpDown set to true AM/PM problem fixed
VWG-2363 TextBoxValidation IntegerMaskValidator fixed and dosent allows non-numeric characters
VWG-3139 Now you can install 2.0 and 3.5 at the same time
VWG-3178 Unnecessary padding was removed from bottom RibbonBarGroup
VWG-3130 EnterKeydown event Problem was fixed and is now fired
VWG-2460 TreeView events issues solved
VWG-3077 DataGridView border fixed
VWG-2699 Anchor in HtmlBox fix
VWG-3078 Session state serialization under IIS fixed
VWG-3076 Charting in catalog fixed
VWG-3033 Theme registration in VS2005 solved
VWG-3061 Problem with controls events in FlowLayoutPanel solved
The Visual WebGui framework is available as a free download here
Visual WebGui is about to release an ASP.NET Control Wrapper which will be included in the upcoming SDK release.
The ASP.NET Control Wrapper enables the adaptation of any ASP.NET component to a VWG control, whether bought from a third party such as Infragistics, Telerik, DevExpress, etc, or created independently. This will surely increase the richness of your control library by utilizing any available ASP.NET control.
The new wrapping feature is not only useful but also simple to use. In a few quick steps the desired control is "wrapped" and ready to use in a VWG project by dragging & dropping it.
The VWG development team is working extremely hard these days in order to make it into the next Visual WebGui release which is expected in the next few days.
Stay tuned for more detailes as it is released on www.VisualWebGui.com.
The new 'empty client' approach lead by Visual WebGui to AJAX is set to offer fundamental, infrastructure solutions to the three major setbacks of AJAX listed bellow. This approach shifts all processing, including UI logic to server, much like the old Main Frame paradigm did, and leaves the web client empty.
The first setback of traditional AJAX is the complexity in creating AJAX application for enterprise's scenarios which is time consuming and therefore brings doubtful ROI. The second setback is that there is a lack of AJAX technologies that can support high level data centric enterprise applications. The last but not least in importance, is security concerns as AJAX is known to raise real security concerns which enterprise applications with sensitive data cannot tolerate.
If the client is empty, everything is processed on the server. This concept enables highly productive, desktop development methodologies for web development as well as allowing complex applications running responsively on the network. Finally, since there is no data, no logic and no open services on the client, this approach presents a highly secured alternative to conventional client-side AJAX.
You can read more about the design time and runtime advantages of the 'empty client' AJAX on VisualWebGui.com
Visual WebGui is an innovative framework for developing data intensive web applications based on its revolutionary 'empty client' platform.
The VWG framework empowers developers to build & deploy AJAX / Silverlight applications atop its platform using WinForms desktop methodologies and still allowing full flexibility, scalability, performance, security or complexity.
While conventional AJAX requires developers to program using a number of different client-side and server-side languages in multi level architecture, the 'empty client' platform enables the use of a single model with one layer. This allows developers to focus on what they want to achieve rather than on how to do so.
The reason is because the 'empty client' approach could supply well known desktop methodologies for web development. This leads to a much simpler design patterns and lets developers design highly interactive, data rich applications with basically the same productivity of designing desktop applications by dragging and dropping controls.
In addition, it is possible to provide pre-defined application blocks with the 'empty client' approach as most of the processing is done on the server. This drives up even more the efficiency and productivity of developing AJAX and enables the customization and extension of .NET components.
You can get the gem from RubyForge with (something like) the following :
$ sudo gem install merb --include-dependencies
You can then generate your first Merb project and run it with the following:
$ merb-gen app my_application
$ cd my_application
Then, of course, you'll want to read the documentation.
Over at Read Write Web they have written a very interesting post about Google. They ask a great question, Is Google Spreading Itself Too Thin? This is a very interesting question as in recent years Google has expanded way beyond search.
Below is an excerpt from the post.
What About Chrome?
Chrome showed Google's brand power in the market. A pretty geeky story (better performance and sandbox security for plug-ins) got tremendous traction in the media and prompted people who had never even made the jump from Explorer to Firefox to look at Chrome.
But it is very hard to see any strategic advantage for Google in splintering the browser market even further. Surely their interest lies in making sure Firefox gains against Explorer? Why not simply continue helping Mozilla?
This looks like an engineering project (yes, a very cool engineering project) that got out to market with a "oh, well, why not, seems a shame to throw it away" rationale.
Has Boredom Become an Issue Inside the Googleplex?
It is almost as if Google is bored. The cash just keeps rolling in. How do they exercise those amazing minds? This is not an uncommon problem. My first job was with a small publishing company in London that had one amazing cash cow and lots of "loss leaders". I naively asked one of the owners why he did this, why not just have the cash cow? He thought for a while and said "well, what would I do every day?"
You can read the full post here.
So, let me know your thoughts, Is Google Spreading Itself Too Thin?
In part 1 of this 2 part series on auto re-sizing iFrames I explained the basic principal of how it would work (you can read part1 here). Today I will give code examples to better demonstrate how you would accomplish this in the real word.
Below is an example of the server side proxy that would be used (this example is written in classic asp [as I needed to use this scripting language for the server that this script was to run on] but this could easily be re-written in your favorite language).
</head>" >" MoreData = TheData MoreData = Replace(TheData,"</head>",MoreData2) Response.Write (MoreData) Set MyConnection = Nothing %>
So, in order to have an iFrame that re-sizes you would simple call the proxy url from the iFrames src property and set the url parameter (that us passed into the proxy) to the url of the page that you would like to display in the iFrame.
Tucked inside the somewhat innocuous announcement that a new committer has joined the Rails core team (Josh Peek, who had worked on Rails via the Google Summer of Code) was the surprising revelation that Ruby on Rails 2.2 will be thread safe. Even more surprising was the statement:
The actual thread safety won’t really matter much to most people, but it’ll surely look nice on your enterprisey check list of Features Your Framework Must Have To Get Play Around Here.
Huh? Thread safety not important? As much as I sometimes feel nostalgic about 1990's CGI programming (ah, signing bonuses...*sniff*), statements like that are just plain embarassing, and don't do much to promote Ruby or Ruby on Rails. And before anyone counters that stable versions of Ruby still don't use native (kernel) threads, think again: JRuby does. It may well turn out that JRuby + RoR 2.2 will be the the power combo for Ruby developers in 2008 and beyond...those that are serious about concurrency, at least.