The plug-in org.eclipse.ui.navigator.resources declares a commonFilter element with the id org.eclipse.ui.navigator.resources.filters.startsWithDot to extend org.eclipse.ui.navigator.navigatorContent:
<commonFilter
id="org.eclipse.ui.navigator.resources.filters.startsWithDot"
name="%filters.startsWithDot.name"
description="%filters.startsWithDot.description"
activeByDefault="true"
>
<filterExpression>
<and>
<adapt type="org.eclipse.core.resources.IResource">
<test property="org.eclipse.core.resources.name" value=".*"/>
</adapt>
</and>
</filterExpression>
</commonFilter>
The element <test> has the property org.eclipse.core.resources.name. I browsed the view Plug-in Registry to find out what this property means (and why it's not simply named name) but all I could find are further property assignments.
Can someone explain me what org.eclipse.core.resources.name means, why it's not enough to just use name as a property, and which class actually processes this value?
The value specified in the test property attribute is a value defined using the org.eclipse.core.expressions.propertyTesters extension point.
In this particular case the declaration is in the org.eclipse.core.resources plugin:
<extension
point="org.eclipse.core.expressions.propertyTesters">
<propertyTester
id="org.eclipse.core.resources.resourcePropertyTester"
class="org.eclipse.core.internal.propertytester.ResourcePropertyTester"
namespace="org.eclipse.core.resources"
properties="name,path,extension,readOnly,projectNature,persistentProperty,projectPersistentProperty,sessionProperty,projectSessionProperty"
type="org.eclipse.core.resources.IResource"/>
which defines a number of tests include the name test.
When you reference a property tester you must always specify the full name including the namespace - so it must be org.eclipse.core.resources.name and not just name, org.eclipse.core.resources is the namespace declared in the extension point. This is because there may be multiple property testers defined for name but each tester has a unique namespace so the full name is also unique.
org.eclipse.core.resources.name tests the resource name against a pattern. Any name starting with . in this case.
Related
I have one property file linked both ways (using f:loadBundle and faces-config.xml) both with different var names. So it would look like the following:
datatypes.properties:
A=first
B=second
C=third
faces-config.xml:
<resource-bundle>
<base-name>datatypes</base-name>
<var>myProp</var>
</resource-bundle>
myPage.xhtml:
<f:loadBundle basename="datatypes" var="prop"/>
in myPage.xhtml I make a list of all the keys from the property file. What I can't seem to understand is that when I use #{prop} in the code below it works but when I replace it with #{myProp} the list no longer displays.
<h:form>
<h:selectManyListbox id="list">
<f:selectItems value="#{myProp}"></f:selectItems>
</h:selectManyListbox>
</h:form>
I figure this means the variables in both cases are not the same behind the scenes but I would appreciate it if someone could explain (or point me to an explaination) in what way they are different. I would ideally like to just use #{myProp} without having to pull the keys out in code and store them in a list.
Thanks.
Both <f:loadBundle> and <resource-bundle> are different ways to load properties with difference being in their access scopes. The latter has by the way the additional benefit that the bundle is also injectable in a managed bean by #ManagedProperty("#{myProp}")
Using <resource-bundle> in faces-config.xml creates a global resource bundle which can be accessed anywhere in your application. This is implemented through a java.util.ResourceBundle instance.
Using <f:loadBundle> in your view creates a view-specific resource bundle which is accessible only within that view. The tag handler implements this using an internal implementation of a Map. This is as specified in the VDL of the tag:
Load a resource bundle localized for the Locale of the current view,
and expose it as a java.util.Map in the request attributes of the
current request under the key specified by the value of the "var"
attribute of this tag.
Now since you're trying to use the values from datatypes.properties through <f:selectItems>, you'll get the said exception. This is because the value attribute for the tag should evaluate to a Collection or an array.
Value expression pointing at any Collection or array. The member
elements may be instances of SelectItem or any Java Object.
So in order to use the global bundle instance, you first have to convert the same into a List<SelectItem> inside your backing bean before using it.
NOTE: You can verify the above cases by setting a breakpoint in the initializeItems(Object) method in the com.sun.faces.renderkit.SelectItemsIterator class. This is, of course, assuming that you're using the Mojarra implementation.
This works
open System
let f = Action(fun () -> Unchecked.defaultof<_>)
But this
let f = System.Action(fun () -> Unchecked.defaultof<_>)
produces the compilation error
Multiple types exist called 'Action', taking different numbers of generic parameters. Provide a type instantiation to disambiguate the type resolution, e.g. 'Action<,,_,,,_,,,_>'.
I know I can fix it by adding a type parameter placeholder (System.Action<_>(...)), but any idea why they behave differently?
EDIT
Found this in the spec, section 14.1.9:
When a module or namespace declaration group F is opened, items are added to the name environment as follows:
Add the type to the TypeNames table. If the type has a CLI-mangled generic name such as List'1 then an entry is added under both List and List'1.
Is this behavior replicated for fully-qualified types (with omitted type parameters)? It doesn't appear so.
I agree with #James that this is related to the bug submitted on Connect, but I think it is a slightly different case. Anyway, I think this is not the intended behaviour. Could you report it to fsbugs at microsoft dot com?
Anyway - I did some debugging and here is what I found so far:
It seems that the compiler uses different code paths to resolve the name Action and the name System.Action. When resolving the other, it searches all loaded modules (i.e. assemblies) for a type named System.Action (see ResolveLongIndentAsModuleOrNamespaceThen function in the nameres.fs file of the open-source release).
This finds the two definitions of Action (one in mscorlib and another in System.Core). I think the issue comes from the fact that the name resolution simply iterates over the results - it finds the first one (from System.Core), which doesn't have a usable overload (because it ranges from Action<_,_,_,_,_> to a version with about 15 type parameters). After finding this type, it reports an error without even looking whether there is another type (in another assembly) that could be used.
If you don't reference system assemblies, then the F# compiler resolves the overload just fine. Running the compiler without parameters references the default assembly set, so this doesn't work:
fsc test.fs
but if I add the --noframework flag, then it compiles without issues:
fsc --noframework test.fs
i have two ant files
mainBuild.xml
subBuild.xml
subBuild.xml is imported in the mainBuild.xml. One of target from mainBuild depends on subBuild. I need to pass the argument to the dependent ant target. I dont want to use the <antcall> or the <ant> tags, as i need the some properties from the
You can define the arguments in the property files, and then read that property in ant like this.
<property file="build.start.properties"/>
All properties in the property file will be imported in ant, and will be available as ant properties, which you can use in both mainBuild.xml and subBuild.xml.
refer this for further reference
Macros are one way to have re-usable code in ant. You can call them with different argument. Re-using of targets (using property ) may not be desirable as the properties are immutable.
I'm writing a Groovy script (as part of a Grails plugin) and I want to get a list of properties for a GrailsDomainClass that a user of my plugin might define. I can do this using domainClass.properties (where domainClass is a GrailsDomainClass).
However, suppose a user has the grails domain class:
class Example {
String name
static constraints = {
}
def getSomeNonExistingProperty(){
return "Not-a-real-property"
}
}
In this case, domainClass.properties returns a list with both name and someNoneExistingProperty
I understand that this is because of Grails is generating a read-only property on-the-fly for use where someone has a getBlah() method. That's great, but in my script I want to perform some actions with the "real" properties only (or at least non read-only properties).
That is, I would like some way of distinguishing or identifying someNonExistingProperty as a read-only property, or, alternatively, as a property generated by Grails and not entered explicitly as a field in the domainClass by the user of my plugin.
I've looked at the GrailsDomainClassProperty Class and it has a range of methods providing information about the property. However, none of them appear to tell me whether a property is read-only or not, or to allow me to distinguish between a field defined in the domainClass and a field created on-the-fly by Grails as a result of a "getSomeNonExistingProperty()" method.
Am I missing something obvious here? Is there a way of getting a list of just the explicitly user-defined fields (eg name, in the above example)?
I believe transient properties are what you are trying to exclude
I've run into this problem a few times, and instead of trying to work around it I typically just end up renaming my getX() method. It's probably the easiest option.
Edit:
Alternatively, I wonder if you could use reflection to see which methods are defined on the class, and while iterating over your properties see if the property has an explicit getter defined, and omit it. I'm not very familiar with reflection when it comes to Groovy and Grails, especially with the dynamic methods, but it's a possible route of investigation.
I would like to store the properties I read from a Java type property file in a list. Is there any way I can do that in Ant?
Properties are maps rather than lists. You can read in a set of properties from a file using the property task.
For example:
<property file="${dir}/external.properties"/>
This property file has the format as defined by the file used in the class java.util.Properties, with the same rules about how non-ISO8859-1 characters must be escaped.
When the property file is read it allows for properties in the file to be expanded. Once the file has been read, they are accessed as normal. So if external.properties contains:
test.dir=/usr/test
test.file=foo
test.target=${test.dir}/${test.file}/
You could reference test.target directly in your task:
<!-- Will create the directory structure /usr/test/foo -->
<mkdir dir="${test.target}"/>
See Property.
<property file="foo.properties"/>