Re: Libraries and effiency
Re: Libraries and effiency
- Subject: Re: Libraries and effiency
- From: Tommy Bollman <email@hidden>
- Date: Sat, 7 Aug 2010 13:17:11 +0200
Hello Phillip
This looks very good, I had figured I would use a property list like this with the Library Loader script I am working, and can be found at MacScripter.net <http://www.macscripter.net/viewtopic.php?id=33487 > : It is very user centric, you have full access to all the files within the editor of your preference. This is centered around hardcoded paths, since the paths are predefined within the script like the properties list does. You then really just select the library category, then choose the file you want to create a loader statement for, -the correct loader statement will then be pasted onto the clipboard.
-I was about to implement creation of a property list like yours, during installation /reconfiguration this weekend, -and may still manage that!.
The Library Lister is about to be integrated with the Loader, to provide all the functionality, which involves creating hard coded statements, and I will support ScriptFactory and AppleMods.
Having said this. The LibraryLister were created with optimum speed in mind, so that it is possible, and useful to list what you are currently working on. It remains to bee seen if that is possible when the lister will have to figurer out paths, and include files that are implicitly loaded, when the utility will have to search the paths, looking for the files.
To make this practical, I would like to have properties for loader systems installed. And which Loader System exclusively a given folder supports.
I would also like to add that clippings files were you store snippets to cut and paste is also a part of the whole picture.
I now prefer to have the clippings embedded in descriptive handler names, and use LibraryLister to sort them out. That is because the Loader and the Lister works in tandem. The loader opens the file in the editor on demand, and the I list the clippings with the lister.
To make matters worse, one can also categorize script libraries into two types, - the simple ones with just handlers, and the more complex ones, which can store and retrieve properties, (these needs special considerations during both construction, and calling, especially when used in a Script Server. The Script Server Skeleton is almost finished and will be shipped before the end of this day and supports loading such.
The issue with the complex libraries, is that it can't easily be deduced that they are of this type. You may embed a library within a script object for several reasons. I feel that an explicit definition is appropriate.
I feel that having a property denoting that a certain library should be run or not is overkill. (Not thought thoroughly on this)
I find it rather unnatural to have to group code by the loader system involved.
To make it all glue good together, I will implement a collection property, which lets me easily find all files, which say works on files, without regard to loader system, as I find this to be the most natural approach when you write code, -by functionality, and not by loader system. The code really shouldn't be categorized by loader system; it would have been nicer if the files were categorized so that one could categorize source files by functionality. -But that may not be practical. And maybe this task of is better implemented as a library file database (small list tool).
Summary
To you Ideas for a property list system, I would like to add the properties holding loader systems, and which directory structure supports which loader system, 0 : Hard coding, 1 AppleMods 2 ScriptFactory.
Each directory, and its children can support only one loader system. (But every system can contain call to the level 0 system.)
I would like to add a whole sub section to your property list which held collections of functionality, both files and directories. It would really be best if all those informations are stored in 1 property list.
There is possibilities of having a property for holding hardcoded paths to complex libraries.
How about that?
On 7 Aug 2010, at 10:40, Philip Aker wrote:
> On 2010-08-06, at 08:01:29, Philip Aker wrote:
>
>> It will be to the benefit of users that each loader implements a few consistent behaviors so they can assess the capabilities of different loaders without having to shuffle their libraries around.
>
>> I will post a sketch much later on today and take comments.
>
> Sorry if I missed a cc to any other library loader developers. As a user, what I'd appreciate is that loader developers consider AppleScript's lack of namespaces and devise their own for handler names. For example, instead of 'import' it would be something like: "AM import …", "KT load library …", or "TB set recursive search for library "…" to …".
>
>
> User Centric Design:
>
> The basic idea is to have a property list which each library loader uses to retrieve the user's preferences for library locations and other details like priority and recursive folder searching.
>
> KISS:
>
> The plist will have a few required keys for which the loader applications may change their values but only by asking the user. Otherwise, the plist is open-ended with an option for additional top-level keys being specified by the loader application's bundle identifier. Typically, if it wishes to extend the plist, the loader app will add a dictionary or array under its bundle id key and specify other key/value pairs according to its needs.
>
> What isn't accounted for so far are Tommy's versioning concerns and (I think) the idea that the the format for libraries be a bundle. Discussion about these items, perceived flaws in the spec, sins of omission, etc. are welcome.
>
> Name:
>
> The name of the plist is "info.libraries.osascript.plist" (i.e. 'defaults <command> info.libraries.osascript […]').
>
> XML Specification:
>
> For easier discussion I'm listing an xml version (easily transformed to plist with xsl).
>
> <info name="info.libraries.osascript" version="0.1">
> <array name="DisabledSuffixes">
> <string>(Disabled)</string>
> </array>
> <array name="OtherLibraries">
> <string></string>
> </array>
> <array name="SearchOrder">
> <string>UserLibrary</string>
> <string>LocalLibrary</string>
> <string>NetworkLibrary</string>
> </array>
> <library name="UserLibrary" reserved="yes">
> <property type="uri" name="URI" value="Library/Preferences/Scripts/Modules"/>
> <property type="bool" name="SearchRecursively" value="yes"/>
> <property type="bool" name="AllowOverrides" value="no"/>
> </library>
> <library name="LocalLibrary" reserved="yes">
> <property type="uri" name="URI" value="/Library/Preferences/Scripts/Modules"/>
> <property type="bool" name="SearchRecursively" value="yes"/>
> <property type="bool" name="AllowOverrides" value="yes"/>
> </library>
> <library name="NetworkLibrary" reserved="yes">
> <property type="uri" name="URI" value="/Network/Library/Preferences/Scripts/Modules"/>
> <property type="bool" name="SearchRecursively" value="yes"/>
> <property type="bool" name="AllowOverrides" value="yes"/>
> </library>
> </info>
>
> Details:
>
> DisabledSuffixes: An array of string. The suffixes of subfolder names in any enabled library path which loaders should not search or load.
>
> OtherLibraries: Array of string of library names. Specifies the names of other "library" elements (in addition to the required 3). The additional locations specified in the named library property will be observed by all library loaders.
>
> SearchOrder: Array of string of library names. This element specifies which libraries the loader should actually use. Effectively, this disables libraries not in this list. In the common case, I believe "NetworkLibrary" will not need be be searched because most users don't have one. This element must have at least one entry.
>
> 'library' element: "UserLibrary", "LocalLibrary", and "NetworkLibrary" are required library elements. Otherwise the 'name' attribute must match one of the names specified in "OtherLibraries". The "reserved" attribute is only set on the 3 required libraries. The property values of any library entry may be changed by user choice (i.e. …/Scripts/Modules is only the default).
>
> 'property' element 'type' attribute: Used by loaders to determine what kind of value to expect. "uri" specifies the path (POSIX path or URL) of the library. It is up to the library loader to check for transfer protocols, and, in the case of UserLibrary, assume the path is relative to the user's home directory. "bool" = simple boolean value.
>
> 'property' element 'name' attribute: Translated to the 'key' element in property lists.
>
> 'property' element 'value' attribute: Loaders will use the value as appropriate.
>
>
> Philip Aker
> echo email@hidden@nl | tr a-z@. p-za-o.@
>
> Democracy: Two wolves and a sheep voting on lunch.
>
Best regards
Tommy Bollman
--------------------------------------------------------------------------------------------------
Mollison's Bureaucracy Hypothesis:
If an idea can survive a bureaucratic review
and be implemented it wasn't worth doing.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden