RAD - Case Study Version 1

[David Burgun]

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

> Okay, I'll bite. I have just created your version 1. I have not  
> looked at version 2 yet.
>
> Here is my setup:
>
> 1 button: Choose
> 3 flds: BaseFolder, FolderContents, FileContents
>
> These controls were grouped. No name or custom properties were  
> assigned to anything. I set the listBehavior of the FolderContents  
> field to true, and put vertical scrollbars on FolderContents and  
> FileContents. Setup time: about 1 minute.

Setting up the controls so they look nice will be the same and will  
depend on what the customer wants. I'm happy to say this is even.

>
> Scripts:
>
> ** Choose button:
>
> on mouseUp
>   answer folder "Choose the base folder:"
>   if it <> "" then setFolder it
> end mouseUp
>
>
> ** FolderContents field:
>
> on selectionChanged
>   putFileContents (the selectedtext of me)
> end selectionChanged
>
> ** Stack script:
>
> on setfolder tFolder
>   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

Ok the actual gathering of the Files in a Folder is handled in my app  
was handled in a Library Stack so the code necessary to do this is  
not duped all over the place. You could do the same so the time taken  
to code this would be roughly the same. The same goes for getting the  
file contents.
>
> on putFileContents tFile
>   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
> end putFileContents

Ok, but you are hard coding control names which I was trying to  
avoid. For instance If the customer didn't want the path of the  
folder displayed anymore (e.g. there was just a choose button) then  
all I'd have to do is to delete the field. Using the method above  
you'd have to change the script otherwise you'd get an execution  
error. The same goes for any field, using ISM deleting a control  
stops the action initiator from sending to that control (since they  
no longer are "listening"). I guess you could prefix all control  
accesses with an "if exists() then" clause but this gets cumbersome  
and adds additional overhead. Also if the user wanted the folder path  
displayed in a number of places (say in different card(s) or even in  
different stack(s)), you'd have to change the script, whereas I'd  
just have to copy and paste the existing Folder Path name field and  
it would automatically pick up the folder when it was selected.

Also with my method I can paste in a control from another group and  
it will instantiate itself automatically and since there are no hard- 
coded control names you don't get any execution errors.

Also if you wanted these groups in another stack you'd have to paste  
the groups and then paste the Stack Script. If you already had  
handlers with the same name in the Stack Script you'd have to do some  
jiggerling in order to make it work.

With my method when

> Comparing our methods:
>
> Thing                       Mine         Yours
>
> # of objects with scripts     3             8
> # of custom properties        0             3
> # objects with custom props   0             8
> Total lines of script        21            63

Point taken about the number of Scripts, but bearing in mind the  
above flexibility, I'd rather have more scripts and not have to  
change things in other scripts. I could cut down on the number of  
scripts and sacrifice flexibility by "Listening" at a higher level.

All the Best
Dave