When I declare elements in the .sdef file for my scriptable application, I have the option to declare various accessors, like this:
<accessor style="id"/>
<accessor style="index"/>
However, I wonder what consequence these declarations have. So far, I could not make out any changes of behavior in my test scripts whether I add or remove accessors for index and id as long as I implement the necessary methods.
So, how do these affect anything? Are they only for documentary purposes, such as what is shown in the dictionary of the Script Editor?
Or does the scripting engine actually behave differently in certain cases depending on these declarations?
So far, I only noticed one behavior that affects them: Script Debugger appears to use them to decide how to browse values in its Explorer. But I doubt Apple added these declarations only for the purpose of this application.
AppleScript does not validate against these settings in your SDEF. However, other tools may. For instance, my Script Debugger application uses this information to control the object access options presented to the user in its Explorer viewers. Various AppleEvent bridges may also use this information to control the kinds of object access they provide to their host scripting languages. An example from the distant past was my JavaScriptOSA project which bridged AppleEvent access into JavaScript. It used the key form settings to control the keys one could use when accessing element objects.
Related
Can I hide info.plist in a kext? or can I dynamic create info.plist for a kext?
I have a codeless kext where it only has info.plist, however, I dont want to expose info.plist to everybody so they can simply just copy my codes... so I was thinking either hide the info.plist or dynamically create info.plist while driver is loading or encrypt the entire kext?
You can't encrypt/obfuscate the Info.plist itself. It is part of the code signing process and requirement though, so it's not trivially modifiable.
You don't state it specifically, but I'm assuming there's some property in the I/O Kit Personality dictionary that you want to hide? Those properties can equivalently be set from code, specifically in the init() function of your driver class, unless they're required for matching. Note that any properties you've set are world-readable in the I/O Kit Registry at runtime though, so I suspect this isn't what you want.
If the information you're trying to hide is part of the matching conditions, for example you're attempting to hide product IDs of thus-far unreleased devices, you can, depending on your driver family's matching rules, probably implement this logic in code in the probe() function. I wouldn't make the matching rules in the Info.plist too broad though, or your kext will be loaded every time e.g. a provider with the given provider class turns up. This is unnecessarily inefficient.
Obviously, in both cases, your kext will no longer be codeless, but you can obfuscate to your heart's content in the C++/C/assembly code.
If you want a more specific answer than that, you'll need to be more specific in your question.
What I want to achieve
I want to evaluate which template and which component is used on which page and how often.
This functionality should allow dynamic evaluation.
What does that mean?
I want to be able to focus on special template or components and to select these easily from a graphical user interface.
As this functionality has clearly administrative purpose (to evaluate templates and componets before migrating to a new cq version) it should not be created as a specific page.
Thus I want to create an administrative tool, which can be installed separately.
Coding the functionality and creating a separate package is no problem for me, but I do not have any idea how to create an administrative tool to provide a fitting user interface.
My Question
How can I create an administrative tool in cq5?
Or more specific: How can I create a service with a graphical user interface, which is accessible as an administrative tool?
(a possible example for a tools graphical user interface, which I am thinking of, is the Blueprint Control Center accessible via 127.0.0.1:4502/etc/blueprints.html)
You could actually accomplish what you need using the Bulk Editor tool, located in Tools > Importers. It allows you to query your AEM/CQ instance based on property-based criteria and content types. You would be able to, for example, search for all pages with jcr:template set to a given template type. The tool produces a graphical table with the search results, which you can export to TSV.
One thing to note, though. The tool is buggy. I've had to fix some things, especially when it comes to using the (hidden by default) import from TSV feature. In terms of querying it works ok. You just occasionally have to hit the search button a few times before it works. I'm not sure why.
You could create this administration tool yourself, but see if the Bulk Editor will get you where you need. Could be quite a bit less work.
I am adding programs to autostart by adding files to ~/.config/autostart and everything is working fine but I would like to know what some of the properties mean. When I google this I just see many examples of desktop entries. I am interested in a technical definition. Where is this defined?
I am interested in the general question, but for example what does the following do?
Hidden=true
NoDisplay=true
Here is the formal specification: http://standards.freedesktop.org/desktop-entry-spec/latest/
Hidden=true means to treat the desktop entry as if it had been deleted. NoDisplay=true means not to show the application in any menus, but still treat it as if it is installed, for example to associate a MIME type with it. Setting both at once seems to be redundant, or perhaps undefined.
For simple UIs, IB is a great tool to edit controls and outlets.
If UIs get more complex and contain many bindings, things tend to get opaque. At one side, you edit source code, at the other side, you edit XIBs. Xcode's search feature finds certain names in XIB, but not all. For example, Xcode doesn't find properties of bindings in XIBs.
Thus, I wonder, if better ways to edit UIs exist.
If UIs could be - optionally - specified using XML, one could easily search and replace all occurrences of a given name [or even dynamically generate XML specifications].
I feel Adobe Flex' UI editor - either visual or using the nicely integrated XML-editor - combines both worlds in a good way: The XML-editor is fully aware of defined names and provides a helpful auto-completer.
How should complex UIs be managed using Xcode?
IB has a lot of problems. It's also still the best tool for the job in most cases. (The same can be said of Xcode generally.) As much as possible, keep your nib files simple and avoid really fancy or complex bindings.
If you find cases where Xcode's Refactor...Rename tool does not correctly modify nib files, you should open a bug at bugreport.apple.com.
You always have the option of examining/editing the nib files directly using the command line tools like ibtool. I use it at times to inspect complex bindings.
Beyond the graphical editors, Xcode and even Interface Builder are really just faces for a collection unix command line tools. You can always dig as far under the hood as you wish.
Nib files are just plist files which are just a specific xml schema so you can edit them directly if you wish. However, they are much more complex than Flex files for obvious reasons.
My coworkers and I were just discussing an annoyance we have in Visual Studio. If you're working with a class that's inherited from another large class, like Controller, you're going to have a huge list of inherited members in intellisense. Sometimes, you only want to see your own members that you defined yourself, instead of having to find things amongst a huge list of other things.
I suppose that if you're looking for something you defined, you should know what it's called. But I know I've run into this frustration when classes get a bit more complicated. Is there a built in way to have intellisense hide the inherited things, or maybe is there a plugin somewhere that provides this? Otherwise I guess one of us has to write it.
Visual Assist X has such a feature. It allows you to push inherited members to the end of the list and more:
Access non-inherited entries quickly by having them listed first.
Scroll to see entries from base classes.
Enable this feature in the options dialog. Use in combination with
bolding of non-inherited members and shrinking for optimal efficiency.
This feature can also be enabled or disabled dynamically from the
filtering toolbar.
You may try to use this: http://msdn.microsoft.com/en-us/library/system.componentmodel.editorbrowsableattribute.aspx