Re: [MacPerl] Mac::Glue progress

[Vincent Nonnenmacher <dpi@pobox.oleane.com>]

>Today I worked on fetching data from a returned event.  I am going to be
>making a new version of Mac::AppleEvents::Simple that provides get() and
>data() methods, which work similarly to the AEDesc methods, but they break
>lists up into Perl lists.

thats sound great.
Let me try to rexplain what I was try to say two weeks ago.

In terms of programming a scriptable app master the Object support LIb and
all the internal guts a lazzy programmer fall into a design decision wich
fall in providing class_info records. In that way you just have to
implement get/set handler deciphering an object specifier to your real live
object and then parse the provided record and patch or return any
property/value found inside that record object (mainly a class taged list
of AEDesc).

That's explain why a lot of scripatble app (Xpress, Apple Media Tool etc)
are presenting record oriented properties as a whole insteda of offering
each one to the scripter.

In that case writing script for those app lead to 'pattern' like this one :

1) build an object specifier for example get object 1 of parentObj n of ...
2) retreive the value of a property that return an entire 'reco' object
3) patch that record using applescript management of sub properties inside
that list (record is a taged list of class/values)
4) set back that record with patch values with a set record_prop of <object
specifier>


This means that any get or data method of Simple will have to be able to
parse and build anonymous list of properties from the glue file to be able
to access any member given its class name form the application.

and things gets worse when some application return context sensitive type
of record for a property. For example an object in a app that got different
meaning in different incarnation and for that carry different properties.

Take an image database for exmaple that could specify a property "duration"
for a movie object and a "bounds" rect for a picture with the same
appleevent that patch a "Media" object.

So a hierarchy like :

MediaObject
  properties:
  kind           -- a kind of object specifier based on an app specific enum
  MediaInfoRec   -- a dependant upon object type properties 'reco' record.

and {duration"integer} for movies
{x:integer,y:integer,width:integer,height:integer}

then to patch such an object (provided this is legal for the application)
you could write
set myInfo to  MediaInfoRec of <object specifier for a MediaObject>
set duration of myInfo to 10
set  MediaInfoRec of <object specifier for a MediaObject> to myInfo

for a movie and

set MediaInfoRec of <object specifier for a MediaObject> to {x:0,y:0}

for a picture object.

>
>Anyway, I also changed the _obj() method to simply o(), and _prop()
>(property) is p().  I know those are not the clearest of names, but they
>could be called often enough that Shorter Is Better.  I think so, anyway.
>You tell me.

I personaly dislike meaningless method names but this is your choice.

[...]

>and skip the rest altogether.  But this is Just a Test of what can be done.
>Sometimes you do need to get a descriptor back and do something with it, so
>that's what I am doing.

I think that every scripter will need a way to :

1) specify all the possible selection criteria and get an error when the
glue can't make an objecft specifier from the class hash.

2) save for further reuse in perl an object reference the referecne
specifier that OSL give back umodified to make further script object ->
real app object mapping.

3) have a way to grab a list of objects from a returned reply and use
thoses as futur object specifier for further processing (like get all
elements that match a test (range, boolean exp etc)

4) build an on the fly AE 'rec' record from any valid class type augmented
with class defined by the application.

During my investigation of simple and Glue I was just wondering if a whole
different approach could be to simply build AEGizmo expressions using the
glued file and fire them to it instead of building the AEDesc by hand. It
would be much faster and perhaps more simplier to debug an any stage of the
process because they would be strings.

---------------------------------------------------------------------
Vincent Nonnenmacher
DPI SA
116 Av de la Republique
38320 BRESSON
tel :  (33) 476 33 25 06        mailto:dpi@pobox.oleane.com
fax : (33) 476 33 25 01        http://worldserver.oleane.com/DPI



***** Want to unsubscribe from this list?
***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch