I’ve recently been involved with two major
projects at opposing ends of the web developer’s spectrum: the first involved
converting an old site, whose table-based layout dated from many years ago, to
a new CSS design; the other is an information source whose identity I can’t
reveal for commercial reasons, and the object is to make it accessible via web
and mobile devices. This second project gives me the opportunity to revisit web
services, and in particular the new easy development tools promised in Visual
Studio 11.1 was quite unprepared for the struggle that ensued...
First, the saga of updating that old site,
It was written and maintained in Dreamweaver, using Templates and Library
items, so template changes could be made to a single file that then updated all
pages based on it - this made some basic changes simple to apply, but it was
still necessary to go through each individual page and correct old code. Search
and replace can help in this process if applied carefully (and thank goodness
for backups!), but in the end, it needed someone to carefully go through all
the relevant pages, edit the HTML and test them in various browsers. This
particular site worked via dynamic pages written in ASP, so there were fewer to
edit than might appear from browsing the site, but still more than 400, which
took time and was a chore that required the assistance of headphones and good
music.
It was curiously satisfying to remove lots
of redundant tags and watch tidier, more readable code emerge, though.
When performing such a tidy-up, there will
remain places where using a table is still perfectly sensible - for instance,
to display a grid of results - and it’s important to test such pages in various
browsers (which, thankfully, behave similarly nowadays). Regrettably, the
exception to this may still be Microsoft’s Internet Explorer - and I say “may”
because IE9 is now pretty standards-compliant in many areas. There is, however,
one major gotcha that you should be aware of: its “quirks” mode. In this mode,
IE9 will behave like a non-standards-compliant older version, so that older
websites can still be made to render correctly in modern browsers. Switching
between modes can be performed manually by the user or automatically by the
browser, but the most common way to force IE not to use “quirks” mode is to
make sure that the first line of your page code says:
<!DOCTYPE = HTML >
With IE, you can easily check what mode the
browser thinks it’s using for a particular page by opening Developer Tools,
where at the end of the top line of the menu you’ll be told what the current
document mode is. By clicking on this you can change the mode, so you can see
how differently a page renders in the various modes. You can also tell IE9 to
render as IE7 or IE8 using this option, should you need to test for those;
personally, I prefer to use a virtual machine with those actual browser
versions installed to make sure all works as it should.
Internet
Explorer 9
The other change we made to this website
was to the usage of Dreamweaver library objects. These are user-defined
reusable pieces of HTML that you can select and insert into a web page, the
idea being that you need change the code only in the library object itself and
Dreamweaver will update all pages that use this object with the revised code.
The drawback to this is that any change to a commonly used library object may
result in several hundred web pages getting changed and needing to be
re-uploaded to the live site. To ease the updating of library objects, which we
use for code on this site that might be changed often (such as submenus), we
switched them to use server-side “include files”, text files containing HTML
code that’s inserted into the web page at runtime using the tag:
<! -- #include virtual="/my_include_file.shtml"
-->
The reason for the shtml extension is to
distinguish the include file from a normal HTML file - an include file, while
containing HTML code, isn’t a properly formed HTML page file with <head>
and <body> tags. To use such include files you also need to tell the web
server you wish to do so, and in IIS this is a simple checkbox in the Home
Directory I Configuration area, while in Apache you need to add the following
line to your HTTPD.CONF or .HTACCESS file:
Options +Includes
You then need to tell it what files to
treat as include files:
AddType text/html .shtml
AddOutputFilter INCLUDES .shtml
The advantage of using includes is that,
should you make a change to the code in one of these files - say, for example,
to alter a link in a menu - all you need do is upload the new file and the
hundreds of pages that use it will update immediately, rather than having to
upload these pages again with their updated library item. There’s a small
server overhead since it has to process each file to see whether it includes
this code, but even for very busy sites this isn’t often an issue.
As good as a REST
With all these changes made and tested, it
was time to attack a new project - whose exact purpose I can’t currently
reveal, but the principles involved in its design and development are relevant
for similar tasks. It involves a database of commercial information sitting on
a server out on the web, which is to be made available via web services so it
can be viewed via a variety of mobile devices as well as web apps viewable in a
browser.
My favourite development tool is
Microsoft’s Visual Studio, which can be used for a variety of languages
including JavaScript and jQuery, and also offers basic HTML design tools - most
importantly, though, it gives me IntelliSense help with code syntax, plus full
debugging features. This said, I have to agree with Jon Honey ball’s column on
the subject in which he bemoaned the lack of any great HTML5 tools that would
make development as easy as it once was in Visual Basic 3.
Visual
Studio jQuery IntelliSense
Remembering those days, I think the coolest
thing about VB development was that you could drag and drop all your components
onto a form and then “wire them up”, often simply through dropdown list
selections - and, finally, for the clever tweaks you could delve into the code
and hack away. While this process often didn’t result in a nicely crafted
product, it did mean that programs could be written and made to work fairly
quickly, and it allowed a lot of people to experience the thrill of doing this.
I remember at that time, a very skilled C++
programmer friend decided that he should start to look at writing code for this
“new-fangled Windows thing”. After two weeks’ work he’d managed a simple
application that opened and closed windows: I achieved a similar effect with VB
in about five minutes - so while I admired his efforts, the way Windows coding
was going for the majority of us seemed quite obvious to me. It’s too easy to
don rose-tinted spectacles about the programs we wrote back then, and many of
them would struggle to serve more than a dozen concurrent users, whereas now we
think nothing of building web apps that can serve thousands. We’ve certainly
moved on in that respect, but alas many of the development tools have reverted
to being little more than fancy text editors with some code prompting: that
casual dragging and dropping of objects and setting of events and methods to
get them working seems to have disappeared.
Even where it is still offered, you’ll find
that the only way to get certain functions to work is by adding more code to
the object involved; if you’re not aware what this code has to be, it can leave
you floundering for days. For a good example, take a look at data binding in
Silverlight, where you have to manually enter (Binding) tags into the XAML code
that defines your page objects. Why can’t I simply navigate from the list
control on the phone app I’m developing to my data source (which the project knows
all about), then select the fields I want displayed, click OK and have that
boring code written for me? Sure, Visual Studio does write a lot of code for
you - for instance, when adding web services but why not take it that simple
step further? Is it because the code required is so easy that a child could
write it? I don’t think so.
Here
is the XAML code to render a WPF ListBox control as a Checked ListBox control
Looking through the reams of forum posts
about the best way to achieve such tasks, (and not helped by the fact these
techniques change with every release of any of the underlying technologies), it
seems to me the examples posted by obviously very clever people at Microsoft
are often unnecessarily complicated. One gets the impression that each contributor
is putting in more effort to impress their peers than they are to illustrate a
technique in the clearest possible way. Is it just me who feels this way?
Anyway, back to the project...
There are rare occasions when the opposite
is true. If I say that creating a RESTful web service using Data Entity
Framework should take less than five minutes, you might at first wonder why
anyone would want to do that anyway. Bear with me. Web services come in two
main flavours that define the way they communicate between application and the
service. These flavours are called SOAP and REST, and while SOAP is perhaps
better for big financial institutions thanks to its superior security, RESTful
services scale better - and it can be argued they’re better suited to web
applications, as they can exploit the web server’s caching mechanism to improve
performance. More to the point, in this case a Windows Phone Silverlight
application can consume only REST web services, so REST it has to be.
With the stopwatch running, let’s step
through the process of creating one. The easiest way if you’re using Microsoft
products is to first create a website in Visual Studio, then add to this
project an item and select “ADO .NET data entity”. A wizard will ask you to
select your database or to create an empty model. The reason for that second
option is that it lets you then design your data entity structure, from which a
database will be automatically created - clever stuff. If you instead choose to
create your entities from an existing database, it will ask you to connect to a
data source that your project knows about and what items you wish to include.
Normally you’ll just select the tables you need your web service to access, and
once this is done a graphical representation of the database structure is
generated; if necessary, you can tweak things from within the UI.
ADO.NET Entity Model
The next step is to create the web service
that looks at this data entity, so add another item to your project, this time
a WCF service. It’s here that the handholding stops: up to this point Visual
Studio’s UI has been helping you along, but now you have to roll up your
sleeves and start manual code editing. There are some code hints to help you.
Open up the code file for your web service - if your web service were called
mywebsvc and your selected C# as the programming language, this file would be
MYWEBSVC.CS; it will be MYWEBSVC.VB if you choose Visual Basic as your
language. In this file you’ll need to edit the first line in the Public Class
to tell it what data entity to look at. This was the name shown in the wizard
when you were adding the database to the data entity, and in this example it’s
called MTF.ntities so your altered code line will look like this:
Inherits DataService(Of MTEntities)
You also need to set the access level to
your entities: here you can define read or write levels of access - but for now
let’s just allow all areas to have read-only access, using the command line:
config.SetEntitySetAccessRule("*",EntitySetRights.AllRead)
It would have been a nice touch if this
code could have been auto-generated by the wizard when creating this web
service, because the next stage is nothing short of magical. Run your website
from within Visual Studio and once the browser has loaded with the default
screen, add the name of your web service to the end of the URL so it looks
something like this:
http://localhost:50222/WebSite2/mywebsvc.
svc
You’ll get back a basic structure of your
service as an XML feed that should look like this:
<?xml version="1.0"
encoding="UTF-8" standalone="true"?>
<service xmlns="http://www.wB.org/2007/app"
xmlns:app="http://www.w3.org/2007/app"
xmlns: atom="http://mm.w3.org/2005/Atom"
xml:base="http://localhost:50222/WebSite2/ WcfDataService.svc/">
<workspace>
<atom:title>Default</atom:title>
«collection href="Articles">
<atom:title>Articles</atom:title>
</collection>
</workspace>
</service>
Nothing particularly impressive there, but
it’s now that things become interesting. The important part here is the
collection “Articles”, which tells you the name of the dataset that you can
query - and here comes the magic. You now have a dataset that you can query in a
multitude of ways without writing any more code.
For a simple example, let’s assume that
your dataset is small so that you’re quite happy to return all its records -
simply type the following into the URL:
http://localhost:50222WebSite2/
mywebsvc.svc/Articles
Note here that all the extra bits that you
add to this URL will be case-sensitive, so “articles” wouldn’t work. If, as in
the real world, we want to return a subset of our data then the URL would look
something like this:
http://localhost:50222/WebSite2/mywebsvc.svc/Articles?$filter=Amount gt 100
Entering this would return all the records
where the Amount field is greater than 100, or if you want only a few fields returned
you could type the following:
http://localhost:50222/WebSite2/wcfdataservice.svc/Articles?$select=Titie,datetodisplay
You’ll have noticed that the output is in
XML, which is fine, but what if you wanted the output from your web service to
be in the more compact JSON form? While OData supports the adding of a command
to the end of the URL to change the output format, WCF Data Services doesn’t
support this and you’ll need to jump through some hoops by modifying the HTTP
headers in your web service code. Full support for the OData specification is
promised, but no deadline has been given.
The query language is quite extensive, and
I’m sure you can see from this little illustration that building a fully queryable
web service from a database is now a simple task, which saves you having to
write code in your web service for all the various types of query that your or
others’ applications might need.
LINQPad
The
free LINQPad not only allows you to test UNO to XML queries, as here, but will
also run C# and VB code for testing.
When fumbling my way around code, I often
find myself creating several projects in Visual Studio just to test them out,
and I always start their names with “test” so I know to delete them later. The
other day, I came across a useful free tool that lets you run code written in
C#, VB and F# as well as LINQ, (along with code hinting in the paid-for
version) and see the results immediately. LINQPad (www.linqpad. com) enables you to test
code and queries and check their output before committing them to your project
- you can connect to a web service, then build and test a LINQ query and view
its output in the results window. Numerous samples are provided, and
right-clicking on your data connection in LINQPad will offer several query
types based on this data, which you can then edit further to get you started.
LINQPad is one of those useful utilities such as Notepad++ that makes solving
coding problems so much quicker.
