[Pythonmac-SIG] FBAs with bundlebuilder?

[has]

Ronald Oussoren wrote:

>>I've made it as procedural as possible, avoiding any need to write 
>>classes as most ASers don't know squat about OOP. This means I 
>>can't use 'aehandler' decorators and auto-discovery here, since 
>>decorators don't work on modules, but never mind...
>Decorators would also work on module level functions, but you'd have 
>to create the Application instance before defining the ae-functions.

You mean pass the application instance to each decorator as you 
declare it, yes? Yeah, that'd work, though it doesn't really gain us 
much over the current procedural approach. I'm a little torn on 
whether using decorators to hold metadata really makes a worthwhile 
difference over traditional 'install handler' calls anyway. And 
there's still an argument for putting aete data in a .rsrc file so 
clients don't need to launch the app just to get its terminology - a 
common annoyance with some Cocoa apps - though having everything in 
one file written as plain Python code does ease development, which is 
the main goal of this particular project. I guess user testing will 
finally determine what works best; I should be starting this quite 
shortly.


>You would need python2.4 to use decorators, which would make it 
>harder to get your code accepted in the AS community.

2.3 has decorator support, but yeah, for the 'improved' decorator 
syntax you'd need 2.4. Course, I'm forgetting that Python tends 
towards storing scripts in source form, so an FBA written for 2.4 
wouldn't work on 2.3 unless the author used a .pyc rather than .py 
file (assuming the Python bytecode is still backwards-compatible). 
Probably too many headaches for now.


>>It's something I still intend to explore in the broader aeom 
>>framework, which will be targeted squarely at Python-based 
>>application developers and support stuff like resolving object 
>>specifiers against an application's object model. Though it's early 
>>days and I'm still working on ideas for this as it's a pretty major 
>>project. [1][2]
>
>That sounds like major undertaking, especially when you want to 
>support more than one GUI toolkit (Carbon, Cocoa, WxWidgets, ...).

Shouldn't be, the Apple Event Object Model is just another 
View-Controller (i.e. a peer to GUI, CLI, RPC, web, etc. interfaces) 
and operates mostly on an application's Model layer. The only View 
class that's normally made scriptable is Window, and we should avoid 
direct coupling to specific GUI frameworks anyway.

(For developer convenience and end-user consistency we can always 
define a standard Window class scripting API [c.f. the default window 
class in Cocoa Scripting] and leave individual GUI frameworks to 
implement support for that API themselves as and when they wish to.)

Some GUI toolkits also provide their own Application and Document 
classes (i.e. Model layer), which are other classes we might want to 
provide some default support for (c.f. Cocoa Scripting again). Again, 
we should avoid directly coupling aeom to these, but can define a 
standard API and leave these frameworks to target that if they wish 
to provide some default scripting support to developers.


Regarding the aeom's general design, it's essential that it can be 
loosely coupled to application Models. The developer should be able 
to construct a Controller layer that presents as a direct 
representation of the scripting interface and operates as a proxy to 
the Model layer's actual API.

Developers could also, if they wish, employ aeom objects in their 
Model layer, mixing in aeom's generic attribute and relationship 
classes to provide the basic foundation for their object model. e.g. 
An Application object typically contains a private list containing 
zero or more Document instances plus public methods for adding, 
retrieving and removing them. Chances are this functionality is 
obtained as an prebuilt class provided by a standard application 
framework and incorporated into the user's Application object as a 
superclass/mixin/attribute. aeom classes would become just another 
available option here, with the added advantage that their standard 
query-based API for accessing and manipulating the application object 
model can be used both internally by the application itself and, 
externally, via aem.receive.

With sufficient refinement, there's no reason why aeom + 
aem.types.objectspecifiers couldn't stand independently of Apple 
events and MacOS. Any application could use aeom in implementing and 
operating some or all of its object model, regardless of whether or 
not that application also supports RPC. And I don't think it'd be too 
hard to write an XML-RPC bridge for those less fortunate OSes not 
blessed with an Apple Event Manager - basically you'd just need to go 
through aem and replace all the Carbon.AE connections with xmlrpclib 
bindings to create a new xmlrpcm package.


There will be practical design problems with aeom, of course; the 
most obvious being how to get good [default] performance out of it, 
since evaluating queries will almost inevitably involve a bit more 
expense than evaluating simple Python references.



>>BTW, anyone know if there's a bug/request filed on BB-built 
>>applications to do something about them falling over and dying upon 
>>launch if there's a bug in the top-level code of the mainprogram 
>>script or that of any of its dependencies.
>
>Bundlebuilder could use some surgery. One thing I'd like to add to 
>bundlebuilder is the use of a custom main program, like the one used 
>in the PyObjC Xcode templates. That would remove one step in 
>bootstrap process, and would probably make it easier to add an error 
>dialog.

Anything that'd make BB and BB-built apps more developer- and 
user-friendly would be very good indeed. (BTW, isn't Bob working on 
BB improvements as well?)


>>[1] Any ideas if/how an Apple Event Object Model support framework 
>>could be made to play nice with PyObjC apps?
>
>Does the Carbon Apple Event Manager use CFRunLoop for running the 
>main event loop? If so, it should be possible to use your code in a 
>Cocoa application. I haven't played around with supporting AE in a 
>Cocoa application yet, which makes it hard to answer you question :-)

I know very little about Cocoa programming (or Carbon programming, 
for that matter), which also makes it hard. When it comes to learning 
this stuff, I am definitely in remedial class, so the ball is 
probably in your court at this point.:p But if we (I?) are going to 
do all this work to bless Python with decent AEOM support, it'd be 
good to see if/how it could integrate into pure Python/hybrid 
Python-ObjC Cocoa apps.

Cheers,

has
-- 
http://freespace.virgin.net/hamish.sanderson/