subjects
Web Apps
TT280
TT281
TT282
Sciences
Computing
TT282 Desktop
Current students only.
|
Week Four
Web Servers and Scripting.
This is where the more practical side of the course begins in earnest. You will be installing either a web server of your choice or setting up your account on the OU's web server (the latter you will have to do anyway, to be able to test your ECA). I have chosen to stick with the OU's server as I don't want to install IIS on my machine. This is because I have a broadband connection and so am constantly connected to the Internet. This raises security issues with IIS.
There have been a few problems for some people re these installations, but this is a Web Apps course, and we expect some niggles, right? It wouldn't be the same if everything ran smoothly!
Scripting also starts this week, Chapter 1 of the course book is used as well as notes and examples in the study guide. Data types are thing first thing covered. After JavaScript, VBScript seems very "loose" in a syntax sense. There are no semi-colons to worry about, nor curly brackets. It isn't case sensitive. You don't even have to declare which data type you are using! All very odd, and I'm curious to see how I'll cope with it as I progress.
The discussion in the Teach conference this week centres around the following:
The new subject, 'Philosophy of ASP', follows below.
To an extent, a broader overview - the rationale, if you like - for ASP is absent; so let's look a little at the philosophy rather than the detail. It would be a good basis for a discussion if you were to consider the benefits (and problems, if you feel there are some that you would like to address) of ASP scripting. In other words, step back from the technical detail and approach the subject from a broader aspect - consider benefits (and problems!) of ASP for the company for whom you are designing, for you as the webpage designer, and of course for the ultimate target - the customer.
And, if/when, you exhaust discussion of the above, then consider what makes a good, or bad, script?
How do you acually write scripts? Do you copiously comment them for future use or (as we are so often guilty of) get carried away by enthusiasm to get the script working and then think about the commenting later (weeks later, sometimes!)?
Do you keep the ASP script separate from the html, as shown at the very start of the ASP book (pages 10 to 12); or do you create just one file as in Example 2 of the Week 4 Study Guide? Are there benefits of one approach over the other.
And, finally, when it all goes wrong, exactly how do you go about debugging the script(s)? The hard way is to laboriously work through the program line by line. But there are other options, so any suggestions? We'll probably keep this particular question running into next week too.
|
References for Week Four:
ASP Reference
Week Five
Script Procedures and Objects.
More hands-on coding, this week concerning functions and procedures. Objects and their properties and methods are introduced (easy if you've done M206 or OO programming before), classes are described although are optional for this course. The Response buffer and Response.Write are covered.
The discussion in the Teach conference this week centres around the following:
The Study Guide for Week 5 introduces some new (to some) features of VBScript and of scripting in general, which gives us even more to discuss in this conference.
So what I’d like you to do this week is to think about what you are doing as you go through the examples and consider some or all of the following issues.
- Debugging (continued).
Although it is satisfying to create a script that works, debugging is an essential part of programming even at the most trivial level, and skill at this only comes with experience. What we can do here though is to share our experiences and so learn from the challenges found in other people’s scripts.
As the scripts you write become more complex, you will find new things to look out for when debugging. As you gain experience you will probably find that you tend to work through a list of possible problems when you come across a script that doesn’t work as expected. If you do have a particular method that works for you, please share it here so that others may benefit from your experience and opinion. Also, has anyone come across a bug in their code that was particularly difficult to hunt down or so blindingly obvious that you overlooked it for hours? Let’s hear about these too.
- Organising the script.
We have already talked about how it is a good idea to separate the html from the script on a page. This week’s study guide goes further along this path and shows you how the script itself can be efficiently organised using sub procedures and functions as well as using included files.
What are the main advantages of doing this? Is it always ‘wrong’ to have a linear program structure? Or is it a matter of preference? Once you have had chance to try a few sample programs, share your thoughts here on this subject.
- Scope of Variables
The study guide states that "variables declared with a function or sub-procedure can only be used with the procedure. They are completely invisible to any portion of the script outside of the procedure."
The topic for discussion here is “Why?”. How can this feature be used to advantage by the programmer? ( Or is this sometimes a problem? )
|
Week Six
Processing Form Data.
Arrays get covered this week, and collections. How to manipulate collections, add and retrieve items using the appropriate "keys". Using control structures in programs such as If-Then-Else, For-Next, Do-While, Do-Until.
The discussion in the Teach conference this week centres around the following:
Forms - love 'em, or hate 'em?
As this week's subject is all about creating forms, I thought it may be useful to stand back from the technical details and consider the person being confronted with your form. The hardest part of creating a form is undoubtedly the intricacies of getting the code right. Because of this there is a tendency to forget about design aspects, navigation around the form, providing information to the customer to encourage him/her to complete the form etc.
First, and foremost, how do you encourage someone to fill in a form? I could give hints to kick the discussion off but won't. Suffice it to say that a blank form with no other information, will persuade me not to fill it in.
Consider also the design and layout of a form, or forms. What makes for good and bad practice?
Another issue is navigation around a form. Can you think of issues that hinder, or enhance navigation around a form? On far too many occasions it is obvious that the developer has given absolutely no thought to this - a technical solution/design is just put in place with no consideration for the end user.
When a form is submitted, what then? Do you provide any kind of response to the user, or let them assume it must have been accepted?
And finally, how do you intend to approach the legalities of the collection of data? Many people, rightly so, are concerned about data that is collected and what other uses there may be for it.
|
Second CMA
Have completed this one, but there has been a lot of debate around a few of the questions, when people have tried to test out the various choices in their browsers. Not all of them have worked properly, and so a couple may end up being marked as unsound. Overall I didn't find this CMA too difficult though.
Acknowledgements to Chris Bird and Veronica Yuill (on the course team for TT282) for the discussion topics above.
TOP
Onwards to Weeks 7 to 9.
|