November 25, 2014

Does Santa Claus need a CRB check?

My correspondence with a local council ....

The TransWilts Community Rail Partnership has arranged for Santa Claus to be in the waiting room at Swindon Station on one weekend day in December when the train from Westbury arrives, and to meet with the children and their parents / guardians before it returns, giving them gifts and having a brief chat with them.

It’s been suggested that I let you know, as the interpretation of Chid Protection rules differs between authorities, and I feel that any questions you have should be resolved ahead of time. All of the children on the trip will be accompanied by their parents or guardians at all times, and they will have pre booked the trip in the anticipation of their children meeting Santa. The trip is being arranged with the help of First Great Western who are adding an extra carriage to the train that day, and their station manger has approved and is assisting at Swindon Station.

An enquiry last year along similar lines, when Santa was in Wiltshire, informed us that we were find under their interpretation of the rules - but I thought I had best check.

Graham



SBCVPWMMED01.sbcintra.com rejected your message to the following email addresses:

customerservices@swindon.gov.uk
Your message wasn't delivered due to a permission or security issue. It may have been rejected by a moderator, the address may only accept email from certain senders, or another restriction may be preventing delivery. For more tips to help resolve this issue, see DSN code 5.7.1 in Exchange Online - Office 365. If the problem continues, contact your helpdesk.


SBCVPWMMED01.sbcintra.com gave this error:
Message rejected as spam by Content Filtering.


Dear Sir / Madam ...

Attached below is a copy of an email I send to you about an hour ago, asking whether I needed to let you know about a certain visitor to Swindon one coming weekend.

In view of my message being return (as far as I can make out) as spam - i.e. an email you don't want - may I assume that I don't need to notify you further? I did try calling in, but neither Zxxx on the switchboard nor Rxxxxx in Child services were able to give me a clear answer, nor were able to advise me on ho to re-send the email. Perhaps you could call me if I need to take it further?

Many thanks

Graham


Dear Graham,

Thank you for your email dated 20th November 2014.

Can you supply us with a little bit more information regarding who the visitor will be or why they will be visiting? So I can forward your enquiry onto the right team.

Kind regards,

Customer Services
Swindon Borough Council


Err .... I'm not sure what more there is to tell.

The gentleman visiting is the former chair of the Xxxxxxxx - Pxxxxx Jxxxxx - and he will be dressed in a red costume with a (fake) white beard, as it traditional in the UK at this time of year. The purpose of his visit will be to help bestow the season's spirit on the children, and to provide an appropriate gift to each of them. The gifts, and the rail travel from Westbury / Trowbridge / Melksham to Swindon will have been pre booked by parents / guardians of the children, and the children will in every case be accompanied at all times by that person or another family member or similar who the parents / guardians choose to let take the children.

My original email, which came back as part of your initial rejection of my message, contained the further details I felt you might require, and remains copied on the bottom of this. I'm sure you'll appreciate that to copy them in a more prominent place in the email might well result in my message being rejected by your automated system once again.


Thank you for your email dated 21st November 2014.

I can confirm your request has been passed on to our licencing department, who will be in contact regarding your enquiry.

Kind regards


Dear Graham

Firstly I apologise for the length of time it has taken to respond to your initial enquiry and the confusion over which department would be able to respond to you.

We can confirm that it is not necessary for you to make a formal notification of this event but thank you for bringing to our attention. As 'Santa' will not be left unsupervised we have no child protection issues.

Kind regards


I look forward to seeing many happy children and their parents and guardians on the trains from Westbury, Trowbridge and Melksham to Swindon on Sunday, 14th December 2014!. See http://twcrp.info/santa for more details. pre booking required if you want to see Santa!

Posted by gje at 07:40 PM | Comments (0)
More about Graham Ellis of Well House Consultants
Related topics: via article database

November 24, 2014

Folk music train, Westbury to Swindon round trip, 14th December 2014

On Sunday, 14th December 2014, the TransWilts Community Rail Parnership is pround to present "The Folk Train". We're taking over a carriage on the 17:20 train from Westbury to Swindon (running as a two coach train that day) and will be featureing Emily Jones and Angeline Morrison who will keep us entertained all the way to Swindon and back.

Music, travel, minced pie, soft drink ... all inclusive for just £10.00 - please book by emailing Phil McMullen (via twcrp@mail.com), or in person at the Melksham Tourist Information Centre.

Passengers are welcome to join at Trowbridge (17:26) and Melksham (17:36). Return gets to Westbury at 19:12 (Trowbridge 19:06, Melksham 18:50).

Also on 14th December - Santa will be meeting children who travel on the 13:15 and on the 16:15 from Westbury to Swindon and back. 13:15 fully booked; a few places left on the 16:15, tickets at the local Tourist Information Centres in Melksham and Trowbridge and at the Westbury Heritage Centre [more]

Finally - the 10:32 train is a special celebration of the first year of the improved TransWilts service ... trains on this line were just 2 each way a day until December 2013, when the service was increased to 8 each way (between 5 and 7 each way on Sundays). Passenger numbers have grown very well, and as a "thank you" Wiltshire Council is inviting lots of the movers and shakers, and guests, onto the 10:32 fro a trip to Swindon and back.

See [here] for Angeline Morrison and [here] for Emily Jones.

Posted by gje at 11:12 PM | Comments (0)
Related topics: via article database

November 23, 2014

Good, stable, reliable local businesses

I took a phone call from Robin Denton, of Denton's directories. For as long as we've lived in Melksham, "Denton's" has been delivered every year and has been the direcory of choice that we keep to hand when looking for local numbers. We have a limited marketing budget (and a limited need to advertise the hotel; even yesterday - a wet November Saturday - we had to turn down walk-in would-be guests because we were fully booked). However, Denton's does get looked at, and does bring the occasional enquiry which turns into a visitor then an annual repeat visitor.

Good, stable, local businesses mean so much to us and to the local economy. It's a testimony to both of our companies that I knew Robin when he called, discussed his IT, and was able to give him the go-ahead with unaltered working for the coming year. Both of our companies move forward from a strong base, with things changin, but with things changing to mirror the times. When Denton's was set up in 1967, no-one would have thought of online, but they now have an online dietory, and facebook and twitter. And when Well House Consultants was set up in 1995, we would not have through of a hotel and accommodation.

Last night, we had a split between business and leisure (event in Melksham) guests. Everyone staying with is was with a company or group that has stayed before - guests become friends who know how the place works, and when it works for them, that leaves them in their comfort zone and coming back to us.

And tomorrow I start a series of courses for an organisation I have trained before. Not for a very long time, let it be said. But then in the training business, I certainly don't want the same person to take the same course a second time as that would indicate a degree of failure the first time ... it does - and acceptably - happen on rare occasions where someone learns but gets pulled from a project, only to find him / herself on a similar project a number of years later. Testimony to our training, I think, that they come back to us.

Things do change, and do need to change. I said to Robin that exactly the same text suits for 2015 as suited for 2014 (and 2013) on our adverts. It's too early to say what the case will be for 2016 yet, but I am very much aware of 2000 new homes, and a number of businesses, moving to Melksham, and I'm also aware of plans to include a 125 room hotel as part of one of the developements. For sure, the coming of the canal will help Melksham move itself into a leisure and tourism niche, but thats going to call in some adjustments and changes just as we've seen changes at Denton's and at Well House Consultants over the years.

Posted by gje at 07:06 AM | Comments (0)
Related topics: via article database

November 22, 2014

Learning to program - comments, documentation and test code

Updates material from our courses for newcomers to programming ... we're very happy to help newcomers learn about the basic principles of programming, running an extra day for a very small group on the front of our regular courses for delegates who have programmed before, but in different languages.


In this final session of "learning to program in xxx", I'm going to stress the importance of some of the more mundane elements, but practical requirements of programming.

1. You should comment your code so that the PROGRAMMER who follows behind you (or yourself in a year or two) can understand what has been done, and pick it up, fix issues, and update it. You should also include things like a version number so that you're not left puzzling which version is which, nor fixing an old version

2. You should document your code so that the USER who makes use of it knows how to do so. That user could be someone visiting your web page, running your application, or another programmer calling in elements of your code as part of his program; we've seen the use of library routines during the day so far ... and YOU may be providing such library routines.

3. You should provide SAMPLE / TEST code so that you can test the continued operatation of the application / routines in the future, and ensure that they're still running right when you transfer a copy to a computer running a different operating system.

Comments and documentation are not, entirely, extras that you have to provide in addition to the running code. By a good choice of variable names, and by insetting the code sensibly and spacing it out, you're doing much of than work within the code. And your test code not only helps you get the code right in the first place, but also provides examples of how it should be used for others who'll be making use of your code.

Posted by gje at 03:32 PM | Comments (0)
Related topics: via article database

Learning to program - what are algorithms and design patterns?

There are common themes for how programming statements are put together to give complete section of code to perform combined tasks. And typically these are putting together building blocks in a similar way to we would do things if we were working something out by hand.

Looking for the maximum value in a column of numbers, for example, we would start off by guessing that the first number was the maximum, and then we would check against each of the following numbers to see if it was greater, updating our guess if it was. Come the end of the reading down the column, the final value is no longer just a guess, it really is the maximum.

Such standard application of coding is known as the application of algorithms or design patterns - that latter term especially applicable to what we'll describe to you later on the course as Object Oriented Programming

All the languages that we teach have at least some algorithms and / or design patterns built into the language, as standard pieces of code in the library that we've referred to earlier in this module. In some languages, such as Lua and Tcl the standard libraries are quite small, and on the course we'll be showing you how to code certain algorithms yourself. In others such as PHP, we have a standing joke around the class that says "there's a function to do that" ... and indeed a huge array of common functions are available to you which you can call up in a single line to run a particular algorithm against some of your variables, passing back a result into another variable. Java, Python, Perl and Ruby - and some of the other languages - have a large number of algorithms available to you, included in the language distribution (as so present on your computer's disc / file system) but only loaded in to memory at run time, typically on your request through a program statement asking for them to be loaded. And resources are available in virtually every language on teh web to provide shared algorithms which, whilst to commonly enough needed to included in the distribuiton, are never the less worth sharing.

Posted by gje at 03:16 PM | Comments (0)
Related topics: via article database

Learning to program - variables and constants

Further material from our "learning to program in ...." courses ... an introduction to variables and constants

variable basics

Information - data - needs to be stored in a program between statements. Or rather it needs to be stored in the computer's memory. At the lowest of levels, that's a binary pattern of 0s and 1s in a numbered memory location that's encoded in such a way that it can be formed back into something that represents a number, or a string of text. I've programmed computers that work like this - in the very early days - it works, but it's pretty impractical for anything but elementary programs. So what do we do?
- We give descriptive names to the places we need to store the data
- We allow the programming language stuff to decide where to store the data in memory so we don't have to bother
- We have the programming language deal with all the low level formatting too

Variable names are typically of the programmer's choice, subject to a strict series of rules that differ from langauge to language. Typically, they'll be comprise a letter, followed by more letters, digits and underscores. Maximum name length, whether capital and lower case letters have a different meaning, whether a variable name may start with an underscore differ. Also
- In some langauges, variable names are [sometime] preceeded by a special character - a "sigil"
- And in some languages, certain words can't be used as variable names - "reserved words" such as if and break

In some languages, the programmer is required to state the names of the variable that wil be used so that the compiler can allocate memory efficiently; that also has the benefit of making the programmer thinks about exactly what's going on. In other languages, it's the langauge internals which work out what storage is needed, and how it's to be used / coded, based on the context in which it's used in the code. Although this latter solution sounds easiest to write and is good, it does have the disadvantage that it's all too easy for a variable to be misnamed and for the programmer to end up with a 'bug' that's hard to find.

On types and Scope

I've mentioned different types of data that need to be stored .. there are whole numbers, numbers with decimals, pieces of text, and others too - collections or groups of variables, booleans ("true" or "false") and indeed composite varaibles of our own type definition. As you get deeper into programming, you'll need to understand these various type.

Data sometimes need to be converted between types - for example a string of characters input by our user at the keyboard needs converting into a number on which calculations can be done. In sorme languages, this is done automatically for you, but in others you have to request explcitly that it be done.

There's also the matter, as programs grow, of how long the data in them (and the name) is retained - it would be wasteful in a long running program to retain data that's only required for a very short period as the program starts up right through to when the program finished running, but it would be frustrating if the programmer came to use a piece of data to find that it had gone away. There's the further matter here of a program that's got sections written by different programmers, and the need for variable names used by each of the programmers to be distinct from each other. Think of two families living in the same town, both who have daughters who they name "Lorna". That's find and good around the home, but when the two young ladies end up in the same class as school, the teacher says "please stand up Lorna" and both will stand up ... so there needs to be something extra. This subject is called the scope of a variable, and it's so important that we raise it to make you aware of an upcoming issue even on your very first day of programming, though solutions and detailed discussions must wait until we're further into the course.

Constants

There are some numbers - "constants" - which won't change (or you don't expect to change) in your program. There are 24 hours in a day, and 7 days in a week. And there are some values which are constant to you - the maximumm number of delegates on a public course might always be 7, the number of working days in the week might be 5, the BMI levels below which and above which a person is regarded as being unhealth may 20.0 and 25.0.

There's nothing to stop you writing these numbers directly into your program, but that's not a good idea:
* You'll find it hard to find all occurrences of the number should it ever change
* You'll write code that's confusing in the extreme if the same constant happens to apply to two things
* The code won't be very descriptive when you come to read it back.

So you'll find that early on we recommend that you assign constants into named locations, and on this first day of the course we'll use variables. However, many languages also support a special notation for named constants, and if you use that:
* Your code can run more efficiently as there needs to be no mechanism to amend a value
* In languges which statically assign memory, a whole heap of complexity can be solved is the constant is a "maximm number of ..."
* The maintenance programmer is clearly told "this value won't be changing at run time"
* The constant can be much more widely scoped so that its's available right through your code without scope conflicts.

Posted by gje at 02:40 PM | Comments (0)
Related topics: via article database

Learning to program - Loop statements such as while

If your program always ran each statement just once (indeed skipping over statements which were in blocks in false conditions) it would run very quickly and would have little use. You couldn't (for example) run a program which went through a whole series of results from a database query and displayed particular data from each of them (plus perhaps a summary on the end).

while

So all programming languages have the ability to repeat a block of code, and the most fundamentel of these repeats ("loops") looks like this:
  while {some sort of condition is true} then {run a group of statements}

You'll note that this is exactly the same format as the if statement in the previous section, apart from the replacement of the word if by the word while. Operationally, it differs in that once the group of statements in the block has been performed, the program rechecks the condition and if it's still true it runs the block again, keeping doing so until the condition becomes false.

Note

* If the condition is false when first checked, the block isn't performed at all - a loop runs zero or more times
* If the condition never goes false you potentially have an infinite loop that goes on for ever
* Conditions are just the same as the conditions mentioned for the if statement in the language you're learning.

Newcomers to programming sometimes take a few minutes to grasp their first program with a loop statement, as for the first time the code jups backwards as well as forwards as it runs. And they sometimes have trouble working out which statements go where.

* If something may need to be run multiple times, it goes within the block (or within the condition to the while)
* If something only runs once and that's BEFORE the code in the block that may repeat, it goes before the while ("initialisation")
* If something runs once after any repeated code, that goes AFTER the block that may repeat (e.g. printing a total

Your tutor will show you a while loop in the language you're learning at this point, and have you write one too.

breaking out of loops

At times, you'll want to jump out of the middle of a loop and continue running code below - if (for eaxmple) you've identified inoming record that you were looking for from a stream of data, or if you have reached a threshold. So languages provide you with a statement that you can put witin a loop to get out of that loop even though the condition at the top hasn't been checked and gone false. The keyword used is usually break but sometimes (in some languages) it's last.

Putting a break into a loop to be run unconditionally would be rather pointless, so you'll find that any break statements will be within a conditional statement such as i(but not limited to) an if within the loop.

Most languages also support a continue statement (sometimes next) which allows you to skip the rest of the block code and go back up to test the condition straight away. Very useful if you're filtering a stream of data and you've identified a record such as a comment that you want to skip over without further processing.

Some languages have other flow controls in loops to - you may come across redo and retry. Early programming languages supported goto statements (and indeed some still do), but except in exceptional circumstances, their use is discouraged - they make for code that it very difficult to debug or to follow, and often impractical to upgrade when specifications change ... and there are now far better ways.

Other loops

while is the most fundamental loop statement, and it's the natural one for us to choose to introduce on this first day of our "learning to program in ..." course. But there are many other forms of loops that you'll come across later in the course, and in practise you'll find such other loops used more that while. Keyowords are for, foreach, loop, until and repeat.

If you are writing web applications (Java Servlets or JSPs, PHP scripts, or CGI or otherwise server based code in other languages such as Ruby, Python, Tcl, Lua, C or C++) Your whole application will potentially be run in a loop. Each time a user submits a form to your code, (or an automated client calls up your URL), the code is run, in effect in a loop that's controlled by the web server with your code be the innards or the loop. This means that there are times wher code towards the top of your web application may be run after code than appears later in your web application (due to condtionals) even though it doesn't look like it's in a loop at first glance.

Posted by gje at 10:55 AM | Comments (0)
Related topics: via article database

November 21, 2014

Learning to Program - the conditional statement (if)

Every language has some sort of conditional statement. That's a way of looking at some sort of setting or status in the program and performing some sort of action based on that setting or status.

such statements take the form ...
  if {some sort of condition is true} then {run a group of statements}

if

The word if applies in every language that we teach at Well House Consultants at present, but how we define the condition, how we signify the end of the condition and the start of the group of statements, and how we stop and start that group varies.

Some definitions
- a BLOCK of code is a series of statements grouped together. Actually zero or more statements, as at times you'll want to have a "do nothing" group
- DELIMITERS are the characters or character groupings thet start and end blocks. They may be the words then and , they may be the characters { and }, or thy may be a pattern of spaces and tabs that insets the block in the source code. Sometimes they may be left out, and if the language supports that they imply a block of a single statement.

The condition that's used in an if statement if going to be an expression that evaluates to a "yes" or "no" value - true or false. Exactly what comprises true and false varies between languages - very often if your conditional expression works out at zero, that's false and it it works out to any other number, that's true. But numbers are only used in this way a small proportion of the time, as languages come with special oeprators which compare two values and return true or false based on that comparison. Commonly they are:
  == ... "is equal to"
  != ... "is not equal to"
  < ... "is less than"
  <= ... "is less than or equal to"
  > ... "is greater than"
  >= ... "is greater than or equal to"

But BEWARE ... in some languages (SQL and Lua) even these vary, and in many languages (Perl, PHP, Shell for example) there are alternatives which do somewhat different things, and in some (Java, Python, Ruby, SQL, C, C++ for example) there are functions (I'lltell you about those another time) which you may call to make alternative comparisons. In other words, you're never limited to just the six comarisons.

These are notes to accompany your "Learning to program in xxxxx" course at Well House Consultants, so I'm not going to attempt to describe all the options here. Instead, your tutor will demonstrate the first, most basic conditional statements to you at this point and let you try them out.

One of the question that comes up for newcomers to programming is "why do I need a closing delimiter?". It's needed to tell your program that you've reached then end of code that's only run in certain circumstances and you're back into "always" code beyond that point. Imagine that you're driving a car and you decide to pull into a service station:
  if (ineed == "loo") then { ......}
The block of code in the curly braces defines what you need to do in the service station, but then when you get backon the main road it's "carry on as before", even if one or two of the variables (such as your comfort level) have been amended. The closure is vital as it removes the need for all subsequent code to be repeated - it's an indication of the coming together.

elseif and else

Usually, you'll want to perform one action if a condition is true, and some different action if the condition is false. Whilst it would be possible for you to write the "opposite" if statement, that's ineffiecent (at writing and run time) and prone to error, so languages support some sort of otherwise statement.

You can follow an if with one or more elseif or elsif or elif clauses (the keyword varies from language to language!) which in each case will have a further condition attached to them, and they'll have a block of code that runs if that alternative condition is true.

Note that the order of the various conditions is important, as once a true condition is found as the code runs, that's the block that will be run and the following ones won't be, even if the condition on them is also true.

Finally, you may finish your if statement with else and a block to accompany it. This is your 'catch all' or safety net which will be performed if neither the if condition, nor any of the el[se]if conditions was true. The else is optional, you can only have one of them, and there is no condition attached to it.

nested and joined conditions

You'll often find that you want to test for conditions within conditions (i.e. within the block of what to do) and you can do this. If you've stopped at the service area above because you needed a natural break, you'll be making other subsidiary decisions in there about wheth to use the loo, have a coffee, buy sweets for the kids, call your desination to update your arrival time, etc. Note that you'll complete all of those extra actions before you complete the main action of making a stop at the service area ... So nested conditional start in the order 1, 2, 3 but end 3, 2, 1.

There are also times that you want to perform a certain action only if two conditions are true. You could do this with nested blocks, but you'll also have an alternative, typically using the words and or or to link up conditions into a single composite conditions. Very often, either && or & are alternatives (with subtle differences) for and, and or may be relplaced by || or |. This is a subject for much deeper study later in the course.

testing

As soon as you start introducing condtional code, you introduce multiple routes through the code so it becomes very important to give throught to a thorough testing regime.

As a minimum, you should test your progran before its use in a live application by running every single possible condition though its true and false routes. And you should consider also:
* Running your code such that all combinations of conditions are tested
* Testing your data where both valid and invalid user inputs are made
* Remember to test "boundary" conditions ... if you're testing for age under 18, run your code with (say) 16 and 20 ... BUT ALSO with 18 itself.

Testing gets to be repetitive and (let's admit it) a bit boring at times, and it's far too easy for us to skip. Yet it really should be repeated in full for each and every iteration / release of the code. We'll broach the detail of testing later on the course, but for the moment bear in mind that a standard set of tests, automated in a file so that you can easily rerun them, and with extra software to pick up hundreds or thousands of passes and the occasional fail is going to be far better that your programmer working through each and every test at every upgrade. You might even want to write the tests before you write the code that it's going to be testing - that's Test Driven Development or TDD

Posted by gje at 07:53 PM | Comments (0)
Related topics: via article database

November 20, 2014

Are administration / review charges on hotel guests acceptable?

I see from the press that a hotel in Blackpool charges £100 to guests who post poor reviews of them online, and that the hotel is rated as number 858 of 894 hotels in the town. My cynic's view is that they might be finding it a goor way to raise extra money, especially as they're quite a cheap place towards the lower end of the market.

These day, though, all good hotels and B and B proprietors are working to get good reviews, thoughtful in handling justified but poor reviews, and concerned at what do do in the event in an unjustified, perhaps malicious, slamming. You may wonder "would that really happen" ... well, yes, I'm afraid it would.

1. We opened our doors to the cameras of "Four in a Bed" - a TV show in which only the highlights of a week's visits by guests least likely to choose to stay (given the option) are broadcast. It's set up to be an interesting show, and it's marvellous publicity - but it also raises emotions including (we have learned) in people who have never stayed, and who judge a place purely by what they see of it and its owners on TV, and have those emotions raised to such an extent that they follow up on what they think as if they had stayed.

2. People love a bargain. And some love complaining in order to get a better deal. "We always look for faults when we check in so we can complain and get an upgrade" said a contact to me once ... and I can believe it of her. We've been caught once (once too many) when I suggested to a guest who had reported a spec on the mirror that shouln't have been there that she pay what she felt to be the right amount, and she walked out at the end of her stay paying nothing. And this tiny minority of people will quite cheerfully threaten a poor review unless [insert what they want here] ... occasionally following through if the hotel doesn't give way.

So, I have an understanding for the folks in Blackpool. I think they have it wrong; I think they need to look at their product as say "perhaps these people have a point" ... but I do have an understanding.

And I was taken by a peverse parallel too. We too have a £100 charge in our terms and conditions which we may levy. We have a very late cancellation without penalty policy as business guests do need to change plans at the last minute on occasions, but late cancellations do cost us. So we reserve the right to make a charge of up to £100 in cicumstances where cancellations are not bona fide or prompt - say someone books a room "just in case", or if they decide they're not travelling weeks ahead, but only let us know with little notice. And we would also apply the charge should someone cancel, then phone in to re-book a few minutes later and ask for a last minute bargain price because "I know you had a room just cancel". They would probably find, indeed, that they weren't welcome to rebook even with the £100 penalty as the trust that's needed between guests and operator would have been broken. We have - never - made the charge. But if there's a good case to do so, make no mistake that we would.

Posted by gje at 06:00 PM | Comments (0)
Related topics: via article database

An example of Model-View-Controller techniques in a Perl / CGI script

Separating out the look and feel of a web application, the calculation logic involved therein, the standard stuff that's needed in most web applications, and the glue that holds the pieces together was become pretty standard web programming practise.

We call the look and feel the VIEW
We call the calculation logic the MODEL
We call the standard stuff that runs it all the FRAMEWORK
We call the glue holding it together the CONTROLLER
And we call the standard functions we need to do extra bits the HELPERS

If you have with a very small application, then all this separating out of elements is more trouble than it's worth ... and on our courses, we start with small applications. However, in the last couple of days I wrote a Perl script using the Common Gateway Interface as part of a web server deployment course, and split it down to show where the elements come from. The complete script is here and you can run it [here].

Take a look at the script, projected here on the left, and you'll see the work I did on the course to show delegates where each of the elements lie in my simple script.

• the HTML at the page base is the view
• the calculation code to convert a height and weight into a BMI is the model
• the logic that takes and checks the inputs, calls the model and puts the results into a hash is the controller
• Helpers populate the view with the contents of the hash and output them
• the framework is new code that's written to wrap the other components together.

So the actual code ...
The Framework - [here]
The Model - [here]
The View - [here]
The Controller - [here]
and the Helpers [here].

Posted by gje at 04:13 PM | Comments (0)
Useful link: Perl training
Related topics: via article database

Well House Consultants Ltd.
Copyright 2014