Question regarding scripting support in OO3

[Thomas Ingham]

Or there's always the old list standby:

	set parent path of rowD to parent path of rowB
	//which defaults to one position or another, probably start
	move rowD to end of items of rowA
	//or positionally ordinate to an item #.

The confusion I'm having in seeing where the problem is, is that if I'm 
programmatically moving items, wouldn't I first need to know what items 
were in what position to begin with. I would suppose that automation 
would be a bit different, but for that I'd start with a node tree 
regardless:

set root to record {name:string_contents,contents:list_subitems}
where subitems is just another record of the same form, then iterate 
and build the new document in order.

I guess it's my own narrow mindedness on such issues that I can only 
think of one case where indexing would be useful, assigning numerics 
and whatnot. But I'm kind of stupid, so it makes sense.

It's cool that you are looking at adding features, regardless, which 
focus on developer support particularly.

-t

On May 5, 2004, at 7:15 PM, Timothy J. Wood wrote:

>
> On Wednesday, May 5, 2004, at 03:25  PM, Thomas Ingham wrote:
>> -- assuming property parent path
>> set parent path of rowD to path of parent of rowB
>
>   This works in Finder since files aren't ordered in the filesystem, 
> only in the view (sort of like having persistent column sorting 
> enabled).  This would get us the right parent, but we'd not know 
> whether to be above or below RowB.
>
>   Still this idea may have legs -- you could imagine that there would 
> be a 'location' object or record that would contain a parent and a 
> index.
>
>   So maybe you could do something like:
>
> 	set location of RowD to location of RowA -- Moves RowD to where RowA 
> was, thus pushing RowA down one slot
>
>   or (forgive the probably bogus record syntax):
>
> 	set LocationA to location of RowA
> 	set location of RowD to {parent:parent of LocationA, index:index of 
> LocationA + 1}
>
>   and we could possibly have the location accessible as both an 
> aggregate record and the individual parts so you could do something 
> like:
>
> 	set location of RowD to {parent:parent of RowA, index:index of RowA + 
> 1}
>
>   But, maybe there is an even better suggestion out there based on 
> this idea (also, I'd suspect that 'index' is reserved and my syntax is 
> probably busted since I'm just typing off the top of my head here :)
>
> -tim
>
> (Actually, the more I think about this the more I like it -- you could 
> also maybe do "set index of MyRow to index of MyRow - 1" to move a row 
> up one slot w/o referring to any other row)
>