Delphi Blog
This blog is now closed. All future posts will be here
It's here - 5/3/2006
(Disclaimer: This is still to some extend preview technology and some things might change before final release)
There's a saying in Spanish "lo prometido es deuda", roughly translated "that what is promised, is a debt". We promised better and more direct Ajax support for Intraweb, and now it's here. Yes, sure it's the initial phase but the architecture has been layed out for full support, the rest is just icing on the cake.
How does it work? Well first of all, this is "pre-release" version of what will be in 8.0.23 and after. There are still some 'gotchas' and certain 'hicups' but as I said, we are working on fixing them. However, here is a sneak preview of what is in store.
Asynchronous Calls
Fist and foremost, Ajax is about Javascript: it implies Javascript, whether you like it or not. Javascript isn't all that bad. Wait a minute! I hear someone shouting out already "didn't you say we don't need to learn JS for IW????" Hold your horses...I'll explain later on.
8.0.23 introduces certain new properties and events. Buttons, Edits, ListBoxes, etc. all have (and those that do not yet, will do) new events which are of the type AsyncXXXX, where XXX is Click, DoubleClick, Change, etc, as shown in the figure below.
These calls make an asynchronous call to the server using AJAX techniques. When you double-click any event, you get the typical Delphi event where you can type in code. For example, let us take a OnAsyncClick event of a TIWButton:
procedure TformMain.IWButton1AsyncClick(Sender:
TObject;
Session: TIWApplication);
begin
end;
The Session parameter represents the WebApplication object (Session object) under which this call is made. Intraweb takes care of the following:
1. When an Ajax call is made, it verifies that the session is valid and there is no hijacking taking place.
2. It identifies the correct session and looks up the correct event handler to handle the server side event
3. It submits the required information for the event.
What does 3 mean? Well, if you have ever done any AJAX calls, you know that on the server side you somehow need to access the information submitted. This is normally done using Javascript with calls such as document.getElementByID(.....). Not here! Intraweb already processes this information and copies the values to the form's controls, so that you can directly access the value submitted using your normal Delphi properties, i.e. IWEdit1.Text has the submitted value.
But doesn't this create an overhead? No. Intraweb allows you to specify what you want to send over the wire using properties of the control. Apart from the events, each control has a series of properties that define what you want Intraweb to submit when you make the asynchronous call. There is one for each event. This way you can have different events submit different things. The following figure shows an example:
apControl indicates that ONLY the actual control value is submitted back. apForm indicates that all the form is submitted.
So, now we have the information on the server, what do we do next? Well, here is where Javascript comes into play. We need to update the information. What we are going to be adding is a whole set of Javascript routines to make development easier. Let's take an example: Adding a value typed into an IWEdit to a IWListBox. One way of doing it would be:
procedure
TformMain.IWButton1AsyncClick(Sender: TObject;
Session:
TIWApplication);
begin
if Session.Browser in [brNetscape7]then
begin
Session.SendAsyncResponse(Format('document.getElementById("IWLISTBOX1").
appendChild(new Option("%s", "%s"))',
[IWEdit1.Text, IWEdit1.Text]));
end else begin
Session.SendAsyncResponse(Format('document.getElementById("IWLISTBOX1").
add(new Option("%s", "%s"))',
[IWEdit1.Text, IWEdit1.Text]));
end;
end;
An "Intraweb way" would be:
procedure
TformMain.IWButton1AsyncClick(Sender: TObject;
Session:
TIWApplication);
begin
Session.EmitCommand(AddListBoxEntry(IWListBox1,
IWEdit1.Text,
IWEdit1.Text));
Session.SendAsyncResponse;
end;
where AddListBoxEntry is a predefined function offered by Intraweb that calls an equivalent Javascript call that automatically adds an entry to the listbox specified and emits the correct code based on the browser. This allows Intraweb to be extensible and not limited to what the libraries will offer, and only limited by the imagination of the developer.
The great thing is that this new async calls work in both umAll and umPartial and we are going to be adding a lot more functionality.
The ultimate idea is for us to not have to make Javascript calls to make updates. However, this is not done overnight and therefore require time and investment. We could have held off on all Ajax support until we came up with an approach for doing this, but we made the decision not to. By releasing support for Ajax in phases, we not only allow our users to make use of the technology now, but we also do not limit it to what Intraweb can offer today, but what can be done. So stay tuned...there is more to come!
Silverlight, Linq, Xml, Intraweb, Ajax and REST - 6/1/2008
I've updated the support for Silverlight in Intraweb to support the changes for the Silverlight 2 beta that has recently come out. To test the new functionality, I decided to put together a demo that shows how to not only use Silverlight controls, but to also interact with them using Intraweb. I then decided to take it one step further and use Intraweb as a service to provide data to the silverlight control.
Here I had two options: use Intraweb as a SOAP server, something that can be done very easily using Arcana's Elite Suite (now open source and available here) or use REST. I decided to choose SOAP so that I could show how easy it is. Unfortunately it didn't work. Not because Intraweb failed, nor did Arcana's components, but Silverlight did. It turns out that Silverlight has issues with certain web services.
So I had to opt for using REST, which in fact is good because it shows the simplicity and beauty of this architecture, where we get rid of the SOAP overhead. With
Intraweb, implementing a REST service is extremely simple. All that is required is to process the information in the OnBeforeDispatch and set the Handled property to True.
Since this is quite long (not that it's complicated, but I want to explain things with as much detail as I can), I've divided it up into several posts:
[Note: Integrating Intraweb and Silverlight is not complicated. The purpose of this demo is to show pretty much all the different things you can do and make use of a variety of technologies and techniques]
1. Creating the REST Intraweb Server
2. Consuming Data from Silverlight
3. Talking to Intraweb Controls from Silverlight
4. Talking to Silverlight Controls from Intraweb using Ajax
The final result is show below. It's not meant to be pretty, but functional and instructive. I'm using the AdventureWorks database shipped with SQL Server 2005. Download code from here
Windows Communication Foundation - 5/1/2008
Next week (finally) "Introducción a Windows Communication Foundation" will hit the book stores. It's the first book I've authored entirely on my own, and for now I can say that I won't be writing another for at least a few years. It drains a lot out of you. It's been a fun and at times frustrating ride, but at the end of the day, it's good to see your work completed.
So what is this book and why is it in Spanish? Well to be honest, it started out as a tutorial I started writing in Spanish, seeing the lack of documentation that existed on WCF. However, the project got converted into a book and took a bit longer than expected. Who is this book aimed at? For people who have little or no knowledge of WCF. It's not an in-depth book (around 200 pages), but at the same time it's not a "superficial" one either. I try and cover most of the important concepts that are used in WCF and are needed in daily work.
It's not a Hands-On-Lab (which I don't like personally) in that you don't follow a series of steps to create a project. I explain the concepts behind each thing I introduce and don't cover each and every individual step required, since most of them are obvious and not related to WCF. In other words, if you're expecting a book like:
1. Select File -> New -> WCF Service Library
2. Create a new App.Config file and type <bla bla bla>
3. Build and Deploy
then it's the wrong book for you. I introduce concepts gradually but explain them fully.
It also is not a reference book or an in-depth book about WCF or it's extensiblity (and that's why it's called Introduction to WCF).
Having said all that, if you buy it, I hope you enjoy it and provide me with feedback. For more information and purchasing options see Krasis Press
[P.S. there are no current planes to publish this on Lulu.com]
-------------------------------------------------------------------
La semana que viene (por fin), Introducción a Windows Communication Foundation estará disponible en las distintas librerías (FNAC, Casa del Libro) así como directamente desde Krasis Press. Es el primer libro que he escrito como único autor y puedo decir que no escribiré otro hasta pasado por lo menos un par de años. Aunque ha sido muy divertido, también requiere mucho esfuerzo. Pero al final del día, merece la pena ver el trabajo de uno mismo plasmado en algo físico.
¿Por qué el libro y por qué en castellano? El libro empezó como un proyecto que iba a ser un tutorial sobre WCF, a vista de la falta de información sobre esta tecnología en castellano. Sin embargo, por varios motivos, se convirtió en un libro.
¿A quién está destinado el libro? Es para desarrolladores que tienen poco o ningún conocimiento de WCF: No se trata ni de un libro de referencias ni un hands-on-lab (libro guiado paso a paso), sino más bien de un libro que introduce los conceptos de la tecnología de manera gradual, pero a la vez en detalle. Al ser un libro de unas 200 páginas, tampoco se toca en temas profundos como la extensibilidad de WCF, aunque si se ve casi todos los puntos importantes de WCF que son necesarios para su uso "diario".
Dicho esto, espero que os guste y me encantaría recibir cualquier tipo de comentario al respecto.
Design for Testability - 4/22/2008
I've been meaning to blog about a new tool I've been using for some projects for the past month, called TypeMock, but I kept delaying it. Today, after a "debate" on alt.net mailing list, I've decided to say a couple of things and hopefully end the deabte it with this post. So to put you in context, a little background. TypeMock is a mocking framework that allows you to mock objects that don't necessarily implement an interface. This makes it extremely easy to mock objects in legacy code or code over which you have no control over (for example using TypeMock for testing ASP.NET MVC). It also has a very nice and elegant syntax (called Natural Mocks) that makes your tests easy and clean.
There are other frameworks for mocking, such as RhinoMocks or NMock, both of which require classes you want to mock to implement an interface (interface/abstract class). I've been using RhinoMock up to now until I switched recently to TypeMock.
Chad Myers was asking for reasons as to why he should use TypeMock since he already has reasons why not to use it. I responded with two points:
1. It allows you to test legacy code or code you do not have control over.
2. It doesn't force you to implement interfaces just for the sake of testability
And it seems that point 2, with some people didn't go through too well. So for the last time, let me clear it up.
I tend to design my systems with loosely coupled classes where I use interfaces and dependency injection when I need it. What does that mean? It means when I know that there is a possiblity that I might need a different implementation for a particular class. Now beforehand it's not always possible to know what your system might need in the future, in which case I tend to abstract my classes. However, there are certain situations where I do know for sure, 100% guaranteed, that I do not have a need for abstracting a particular class (how often does an RFC protocol implementation change?). These are the times where I do not see a need to introduce dependency injection just for the sake of testability.
Now one argument against that is that if a class is tightly coupled enough so as to not require abstraction, then the unit test should be more an integration test. That's great in theory but not always possible in practice. I might have to perform unit tests on my code where certain dependent classes aren't viable to be tested.
In summary, if I'm using a mocking framework that allows me to overcome these situations, whether caused by my own code or not, and at the same time allows me (nothing can prevent you) to continue with my good practices, I don't see a reason why I shouldn't use it. If on top of that I get a nice syntax and other features all the better. What it doesn't imply is that just because I can now mock concrete classes that I should forget about concepts such as dependency injection.
I still haven't received a response on in this debate about why would you abstract all your classes Maybe it's because of testing frameworks imposing it on your design? But to be honest, I've given up asking.
Intraweb Courseware - 4/15/2008
Dr. Bob has just released his Intraweb (VCL for the Web) courseware and
it's pretty amazing. It covers Application Mode, PageMode and all the
recent additions such as Asynchronous support (Ajax). Well worth the
money, specially if you go for the special package that includes
support. Bob's been working with Intraweb for many years and he has a
very thorough knowledge of the architecture, so make sure you check it out. The table of contents is online
Unit Testing: It's not only about regression testing - 4/8/2008
A lot of times when you're introduced to Unit Testing, you're sold on the fact that it's the best way to have regression testing in place. That's 100% accurate. Whether you practice Test Driven Development or take a test-after (test-last, POUT, whatever you want to call it....) approach, creating unit tests allows you to test changes in your code and make sure that bug fix, change or new feature hasn't broken any functionality. However, one of the great added values to Unit Testing that often doesn't get as much attention as it should, although always present, is documentation.
How many times have you come across some piece of code that you needed to change and was wondering why you did something the way you did? Talk to your colleagues, look for documentation, look for comments, only to find nobody recalls anything and not one word jotted down anywhere about it. This is where a good suite of unit tests come in handy. If you have tests that verify behavior of your code, and also make sure that your code coverage is quite high (over 80%), you have a good chance to find out why something is coded in a particular way. Even if you don't name your tests with a "specification orientated" convention, it is still very valuable to know that when you make that change, your tests still run. And the higher the code coverage, the less chances are that something will fail on deployment.
So whether or not you or your colleagues recall why you did something in a particular way, you might not need to if you document your code with tests.
Finalbuilder just went continuous and so will Intraweb - 4/7/2008
Many know I've been a Finalbuilder fan from day one. Recently they came out with a server version of their product which allowed you to run builds unattended on some machine (different from automated builds based on Windows Scheduler). However, it still lacked some of the main features demanded by a proper Continuous Integration tool.
Well they've just released FB 6 along with the server version and I'm really impressed. Just look at the feature set here. I'm really desperate to try it out and the first thing I'm going to do is create continuous builds for Intraweb. I've been spending the past week cleaning up our build process and this will be the perfect opportunity to test out FB6. Great timing.
Amusing... - 3/31/2008
So I'm reading DelphiFeeds.com today after being "disconnected" from my feeds for a bit, and I find a whole bunch of posts about TMS Software. One of them was about their new web site which I must say, Bruno....about time dude! It looks really nice :). However, two of the posts were regarding TMS's support for the Ribbon bars of Office 2007. I was surprised to learn that according to this blog post, it seems TMS is violating something. It doesn't mention what it's violating and the reason behind it is that the MS agreement specifically says that it cannot. What's ironic though is that the document is available (once you agree to the terms and conditions).
Anyway, in my attempt to find out, I went through the document and let's just say that this was a complete waste of time (hmm... labels two pixels out of place is a big deal for certain companies). If you're interested, make sure you download the document yourself and read it.
What I fail to understand though is the purpose of the series of posts. First there's one indicating how TMS is violating stuff, then another two saying how they've fixed the issue and how wonderful their web site looks. I guess emails have gone out of fashion?
But hey, who am I to be a judge of what someone posts on their blog. Remember, I keep complaining about a certain installer software. Mind you, I have tried other means and approaches prior to blogging and it has been 90% caused by my continuous frustration of wasted time.
Arcana Intraweb Components go OpenSource - 3/8/2008
If you're an Intraweb user, you've no doubt heard of the Intraweb component pack from Arcana. It contains many great components, including the famous Dialogs Pack. If you haven't tried it, now is your chance. It's become OpenSource and you can find all the code at:
http://code.google.com/p/iwelite/
Basta! / Ekon - 2/15/2008
Next Sunday I'm leaving for for Germany. I'll be doing a talk at Basta! on MSBuild and a power workshop at Ekon on Agile in Delphi. Although the talk will be using Delphi code (I'll be doing examples in both Delphi for Win32 and .NET), the concepts can be applied to any language or platform.
So if you're in Europe, sign up for one of the two conferences. They are really great events, held both in English and German. With Basta! having over 70 speakers and Ekon having many of the well-known members of the Delphi community, I'm sure you'll find something to suit your liking.