Re: Shortening variable list passed onto subroutines
Re: Shortening variable list passed onto subroutines
- Subject: Re: Shortening variable list passed onto subroutines
- From: Jay Louvion <email@hidden>
- Date: Mon, 06 Feb 2006 19:19:32 +0100
Title: Re: Shortening variable list passed onto subroutines
On 17/1/06 16:45, "has" <email@hidden> wrote:
> 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
> --
Thanks so much for your time in teaching me some really useful things. I do still encouter a problem, though; even though I quite understand the principle of a record being self-documenting (the result pane is quite explanatory), somehow the info isn’t sent back into the main script: “Variable StartDate is not defined” for eg. Any hints on what might simply be a classic newbie mistake ?
J.
Jay Louvion
Studio Casagrande
3, rue Müller-Brun
1208 Geneva
T+4122 840 3272
F+4122 840 3271
skypeme:
jaylouvion
www.studiocasagrande.com
P Please consider the environment before printing this email.
_______________________________________________
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