RAD - Case Study Version 2

[David Burgun]

On 25 Mar 2006, at 19:50, J. Landman Gay wrote:

> I've done version 2. It took me longer to figure out your scripts  
> than to write my own. Total scripting time was actually about ten  
> minutes, the rest was in trying to decipher yours so as to figure  
> out what I needed to do.

Ok! That's usually the case in my experience!

>
>> Using ISM all I had to do was this:
>> 1. Copy and Paste the existing groups in question -   
>> Group_SelectFolder, Group_SelectFile and Group_FileContents so  
>> there  were now two of each.
>> 2. Arrange the new groups nicely in the window.
>> 3. Change any user visible text to read A and B as appropriate.
>> 4. Change the custom properties "cpFolderKind" and "cpFileKind"  
>> so  that the new groups now read FolderKindB and FileKindB.
>> That's all I needed to do to get the basic functionality of having  
>> 2  x Base Folders, 2 x FIle Lists and 2 x File Contents working.  
>> (I  repeated this action just now in a test stack and it took less  
>> than 5  minutes).
>
> I did exactly the same thing, but I didn't need to do step 4  
> because my method uses no custom properties. I option-dragged the  
> existing group to create a duplicate. Took 2 seconds, and that is  
> all that was required.

I didn't know about option-drag! Thanks!

>> With this working, I needed to add a new Group to do the compare.  
>> The  pseudo code for this (very close to the real code) is shown  
>> below  marked as Version 2.
>
> I only added a single button, not in any group, called "Compare".  
> It has a one-liner script:
>
> on mouseup
>  compareFiles
> end mouseup

I didn't need to put it into a group either, I could have just added  
a single button.
>
> After that, all I needed to do was alter the master stack script. I  
> needed to add 1 line to the existing script, and add two new  
> handlers and a constant. Here is what I did:
>
> constant kCompareNumber
>
> on setfolder tFolder -- this one is unchanged
>   put the ID of the owner of the target into tGrp
>   put tFolder into fld "basefolder" of grp ID tGrp
>   put the directory into tOldDir
>   set the directory to tFolder
>   put the files into fld "folderContents" of grp ID tGrp
>   put "" into fld "fileContents" of grp ID tGrp
>   set the directory to tOldDir
> end setfolder
>
> on putFileContents tFile -- added 1 line at end
>   put the ID of the owner of the target into tGrp
>   put fld "basefolder" of grp ID tGrp & slash & tFile into tFilePath
>   put url ("file:"&tFilePath) into fld "fileContents" of grp ID tGrp
>   set the enabled of btn  "Compare" to (the number of items in \
>        validFlds() = kCompareNumber)
> end putFileContents
>
> on compareFiles -- new handler
>   put validFlds() into tFldList
>   if the number of items in tFldList <> kCompareNumber
>   then exit compareFiles
>   repeat for each item i in tFldList
>     set the hilitedlines of fld id i to calcCompare(tFldList)
>   end repeat
> end compareFiles
>
> function validFlds -- new hander
>   repeat with x = 1 to the number of grps
>     if there is a fld "fileContents" of grp x and fld  
> "fileContents" of grp x <> ""
>     then put the ID of fld "fileContents" of grp x & comma after  
> tFldList
>   end repeat
>   delete last char of tFldList
>   return tFldList
> end validFlds
>
> Because these handlers are all in the same script, changing it  
> affects all existing groups and any new groups that are cloned from  
> the existing. I have made the new handlers extensible so that you  
> could compare 3 or 4 or any number of text fields simply by  
> changing the number of items required, which is stored in the  
> constant kCompareNumber.

Ok, I get your point about cloning and having the "master" script  
inherit, it's true you lose some of this by using ISM, but I think  
that the flexibility you gain is worth it.

> You didn't show the actual handler that compares the files, but  
> that's okay, presumably mine and yours would be fairly similar and  
> do the same thing, so we don't have to consider that in our  
> comparison.

Agreed, my compare routine is actually in a Library Stack and it  
takes 2 files as input rather than comparing the contents of a the  
fields.

>
> I didn't have to change anything in the existing groups, and my  
> scripts are (to my eyes, anyway) easier to follow and debug later.  
> They are much shorter. They don't require any custom properties or  
> special treatment.

I didn't 100% need the custom properties, it just seemed better  
practice to do it that way.

> Seems easier to me, but maybe I'm just too used to the xtalk  
> paradigm. By comparison, your way looks complex, difficult to  
> debug, and there are scripts in so very many places that following  
> the messaging path in a debugging session seems harder than it  
> really has to be. Again, maybe it's just my own perception.

In this case I'd agree that debugging may be slightly easier, but on  
a more complex app I'd say my method is easier, since you can easily  
trace a message path.

> It's been an interesting exercise for a Saturday afternoon, thanks  
> for the opportunity. I'll bow out now.

Agreed! Thanks for taking part!
All the Best
Dave