Re: Shortening variable list passed onto subroutines
Re: Shortening variable list passed onto subroutines
- Subject: Re: Shortening variable list passed onto subroutines
- From: has <email@hidden>
- Date: Tue, 17 Jan 2006 15:45:50 +0000
Jay Louvion wrote:
>I've been dabbling seriously for the first time (and think I've got it at
>last) in subroutines, but I was wondering if there is away of shortening a
>variable list passed onto it. The list is taken from a tab delimited text.
Since all this data is closely related and obviously intended to be used together, treat is as a single unit. The obvious way is to collect it in a record (which makes it self-documenting):
on parseContentString(contentString)
set {StartDate, EndDate, StartTime, EndTime, ToDoNr, ¬
ToDoStatus, ToDoAction, ToDoActionDetail, |project|, ¬
Category, ThePriority, Photographers} to splitText(contentString, tab)
set StartDate to (text 5 thru end) of StartDate
try
set EndDate to (text 5 thru end) of EndDate
on error
set EndDate to StartDate
end try
return {StartDate:StartDate, EndDate:EndDate, StartTime:¬
StartTime, EndTime:EndTime, ToDoNr:ToDoNr, ToDoStatus:¬
ToDoStatus, ToDoAction:ToDoAction, ToDoActionDetail:¬
ToDoActionDetail, |project|:|project|, Category:¬
Category, ThePriority:ThePriority, Photographers:Photographers}
end parseContentString
There's a few values that don't need to be included as they can be derived as needed from the data already in the record.
A couple other tips...
Reasons for using handlers:
1. Provide separation of concerns; i.e. each handler does one well-defined job; for example, parsing the contentString belongs in its own handler, not mooshed into the code for creating iCal and Mail entries.
In your case, you'd call the above parseContentString() handler to parse the incoming message, then pass the resulting record to the DefineFields_n_iCalOpts() and MakeEmail() handlers which should only have to deal with creating the appropriate iCal events and Mail messages from that data. (You'll also need to rejig your error trapping and reporting code for the modified design, of course.)
2. Prevent unnecessary duplication of code; the iCalErrorLog and mailErrorLog handlers are virtually identical; so you can factor out the identical portions to reduce the amount of code you have to deal with:
on iCalErrorLog(ErrMssg, ToDoNr)
sendErrorLog(message, ToDoNr, "iCal")
end iCalErrorLog
on mailErrorLog(ErrMssg, ToDoNr)
sendErrorLog(message, ToDoNr, "Mail")
end mailErrorLog
on sendErrorLog(ErrMssg, ToDoNr, AppName)
set theSubject to AppName & " Error Report: ToDo " & ToDoNr
set theContent to return & "La confirmation pour la ToDo N° " & ToDoNr & ¬
" n'a pas pu être envoyée correctement depuis " & AppName & "." & ¬
return & return & ¬
"Le message retourné par le script est le suivant: " & ¬
return & return & ErrMssg
--
tell application "Mail"
tell (make new outgoing message with properties ¬
{subject:theSubject, sender:"email@hidden", content:¬
theContent, visible:false})
make new to recipient at end of to recipients ¬
with properties {name:"Roger", address:"email@hidden"}
make new cc recipient at end of cc recipients ¬
with properties {name:"Jay", address:"email@hidden"}
send
end tell
end tell
end sendErrorLog
If you want to polish your skills you might consider borrowing/buying a copy of Code Complete or similarly approachable book on good basic software design techniques. Understanding the motivations for doing things is just as important as knowing how to do them, and a bit of background theory starts to be helpful when you get to this stage.
HTH
has
--
http://freespace.virgin.net/hamish.sanderson/
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden