Is there a way to iterate over all CfnResources in a CfnInclude? - aws-cdk

I'm trying to get a list of all resources of type AWS::SSM::Parameter defined in a Cloudformation template, using the Java AWSCDK. The template file is being loaded and parsed as a CfInclude object. Am I overlooking something, or is there really no way to iterate over all resources in CfInclude? All I see in the documentation for software.amazon.awscdk.cloudformation.include.CfnInclude is getResource, which requires the logical ID to be known.

You can reference all resources with getNode().findAll().
For example to list all IAM Roles defined in the included file:
List<IConstruct> roles = include.getNode()
.findAll()
.stream().filter(n -> n instanceof CfnRole)
.collect(Collectors.toList())

Related

How to access object field in qaf step from stored variable

In my previous question I was looking for a way to access and store return value of the function in qaf step. I was provided with the following:
When create new user using "{'name':'user1','password':'user123'}"
And store into 'newUser'
Then system should have user '${newUser}'
Now, I'd like to know how to get value from object/collection stored.
If it is a simple object named newUser which has field Id. How would I pass Id on next step?
And, if return is List, how to get by index from stored list?
Resolved issue on my own. If anyone faces same unknowns, here is how I solved it.
For requirements to work around response data, parsing same stored objects in properties by specific fields or collecting data from other structures such as Maps or Lists, create common functions with #QAFTestStep annotation to get data for class member name, map by key or list by index and so on... Add those in common steps and then write stepname text in gherkin format with parameters specified. Let me know if someone needs help, always ready to help out...

Get child node by name in Umbraco 7.8.1

My Content structure is:
-Home (the site root node)
-About Us
-Our Sevice1
-Our Sevice2
-Our Sevice3
I created a macro for Our Services.
In macro, I want Our Sevice1, Our Sevice2, Our Sevice3...
But in the list variable About Us also come but I don't want it
I want only our service name of the child node
var list= CurrentPage.Children();
About Us also come on the list but I don't want it.
The reason that you see the About Us page in the collection is because you use the Children method.
With the Children method you ask for the direct child nodes of a parent node traversing one level down. So in this case you ask for all direct children of the home page so this works like expected.
What you are trying to achieve is a collection of of all Service nodes. To accomplish this you could do something like this.
Make sure that you have a seperated Document Type for your service nodes ( like for example doc type Service Page ).
Then you can do the following:
var servicePages = CurrentPage.ServicePages;
You can view the docs about it here:
https://our.umbraco.org/documentation/reference/querying/dynamicpublishedcontent/collections
But all of this is using dynamic syntax, this will be removed in future versions of Umbraco. So I suggest you go and use the strongly type syntax.
Then this can be changed by:
var servicePages = Model.Content.Children.Where(x => x.DocmentTypeAlias == "servicePage");
What this does is take the IPublishedContent object of the current page you are on, which is the Home Page then you take all children which has a document type alias of type servicePage.
Like #Mivaweb mentioned, it's better to not use dynamics (I think for performance in addition to being removed in the future).
However, I don't think you have to create a separate doc type, although that will work too. The predicate for the Where method should handle other expressions such as:
var servicePages = Model.Content.Children.Where(x => x.Name.StartsWith("Our Sevice"));

Can I manually apply Grails routing logic to a String containing a URL?

At runtime, my app will be provided receive a String that may be a valid URL that my app serves (per UrlMappings.groovy), or it may not. I'd like to determine which is the case.
Is there a way for me to apply Grails routing logic manually to a URL, and see what controller/params (if any) it maps to?
Just to be clear, let's say my UrlMappings are:
"/path/one" (controller:"api", action:"one")
"/path/two" (controller:"api", action:"two")
"/variable/$segment/1" (controller:"api", action:"var")
Now my app receives a string at runtime with the value "/path/fake" -- can I test "/path/fake" against the list of all known routes to determine that it's not a match? (Or alternatively, can I test "/variable/segA/1" and determine that it's associated with the "var" action of my API controller?"
Note: I'm looking for a solution that will work for paths with variables, etc -- and will populate a params array with those variables.
Check whether the mapping is present from the list of mappings available in UrlMappings using grailsApplication which can be injected easily in artefacts like controller/service.
def allMappings = grailsApplication.allClasses
.find{it.name == "UrlMappings"}.mappings.urlMappings
assert '/path/one' == allMappings.find{it.toString() == "/path/one"}?.toString()
assert !allMappings.find{it.toString() == "/path/fake"}?.toString()

Breeze manage NODB EntityTypes with DB EntityTypes

i´m using the Papa's course CCJS code to investigate Breeze.js and SPA. Using this code i´m trying to manage aditional information that cames from server but that is not an Entity contained in the Metadata that cames from EntityFramework.
So i created a NO-DB class called Esto and a Server method like Lookups:
[HttpGet]
public object Informacion()
{
var a = new Esto(....);
var b = new Esto(.....);
var c = new Esto(......);
return new {a,b,c};
}
then in model.js inside configureMetadataStore i call:
metadataStore.addEntityType({
shortName: "Esto",
namespace:"CodeCamper",
dataProperties:{
id: {dataType: breeze.DataType.Int32,isPartOfKey: true},
name: {dataType: breeze.DataType.String}
}
};
and also define in the model entityNames array: esto:'Esto' as an Entity
now in the context.js i load this creating a server side method like getLookups but called getInformacion:
function getInformacion(){
return EntityQuery.from('Informacion')
.using(manager).execute()
}
and then inside primeData in the success method call this:
datacontext.informacion = {
esto: getLocal('Esto',nombre)};
where getLocal is:
function getLocal(resource, ordering)
{
var query = EntityQuery.from(resource).orderBy(ordering);
return manager.executeQueryLocally(query);
}
I get an error in the query contained in the getLocal that states that Can not find EntityType for either entityTypeName: 'undefined' or resourceName:'Esto'.
What i´m doing wrong?
Thanks
You were almost there! :-) Had you specified the target EntityType in the query I think it would have worked.
Try this:
var query = EntityQuery.from(resource).orderBy(ordering).toType('Esto');
The toType() method tells Breeze that the top-level objects returned by this query will be of type Esto.
Why?
Let's think about how Breeze interprets a query specification.
Notice that you began your query, as we usually do, by naming the resource which will supply the data. This resource is typically a path segment to a remote service endpoint, perhaps the name of a Web API controller method ... a method named "Foos".
It's critical to understand that the query resource name is rarely the same as the EntityType name! They may be similar - "Foos" (plural) is similar to the type name "Foo" (singular). But the resource name could be something else. It could be "GetFoos" or "GreatFoos" or anything at all. What matters is that the service method returns "Foo" entities.
Breeze needs a way to correlate the resource name with the EntityType name. Breeze doesn't know the correlation on its own. The toType() method is one way to tell Breeze about it.
Why do remote queries work without toType()?
You generally don't add toType() to your queries. Why now?
Most of the time [1], Breeze doesn't need to know the EntityType until after the data arrive from the server. When the JSON query results includes the type name (as they do when they come from a Breeze Web API controller for example), Breeze can map the arriving JSON data into entities without our help ... assuming that these type names are in metadata.
Local cache queries are different
When you query the cache ... say with executeQueryLocally ... Breeze must know which cached entity-set to search before it can query locally.
It "knows" if you specify the type with toType(). But if you omit toType(), Breeze has to make do with the query's resource name.
Breeze doesn't guess. Instead, it looks in an EntityType/ResourceName map for the entity-set that matches the query resource name.
The resource name refers to a service endpoint, not a cached entity-set. There is no entity-set named "Informacion", for example. So Breeze uses an EntityType/ResourceName map to find the entity type associated with the query resource name.
EntityType/ResourceName
The EntityType/ResourceName map is one of the items in the Breeze MetadataStore. You've probably never heard of it. That's good; you shouldn't have to think about it ... unless you do something unusual like define your own types.
The map of a new MetadataStore starts empty. Breeze populates it from server metadata if those metadata contain EntityType/Resource mappings.
For example, the Breeze EFContextProvider generates metadata with mappings derived from DbSet names. When you define a Foo class and exposed it from a DbContext as a DbSet named "Foos", the EFContextProvider metadata generator adds a mapping from the "Foos" resource name to the Foo entity type.
Controller developers tend to use DbSet names for method names. The conventional Breeze Web API controller "Foo" query method looks like this:
[Get]
public IQueryable<Foo> Foos() {...}
Now if you take a query such as this:
var query = EntityQuery.from('Foos').where(...);
and apply it to the cache
manager.query.executeLocally(query).then(...);
it just works.
Why? Because
"Foos" is the name of a DbSet on the server
The EFContextProvider generated metadata mapping ["Foos" to Model.Foo]
The Web API Controller offers a Foos action method.
The BreezeJS query specifies "Foos"
The executeLocally method finds the ["Foos"-to-Model.Foo] mapping in metadata and applies the query to the entity-set for Foo.
The end-to-end conventions work silently in your favor.
... until you mention a resource name that is not in the EntityType/ResourceName map!
Register the resource name
No problem!
You can add your own resource-to-entity-type mappings as follows:
var metadataStore = manager.metadataStore;
var typeName = 'some-type-name';
var entityType = metadataStore.getEntityType(typeName);
metadataStore.setEntityTypeForResourceName(resource, entityType);
Breeze is also happy with just the name of the type:
metadataStore.setEntityTypeForResourceName(resource, typeName);
In your case, somewhere near the top of your DataContext, you could write:
var metadataStore = manager.metadataStore;
// map two resource names to Esto
metadataStore.setEntityTypeForResourceName('Esto', 'Esto');
metadataStore.setEntityTypeForResourceName('Informacion', 'Esto');
Don't over-use toType()
The toType() method is a good short-cut solution when you need to map the top-level objects in the query result to an EntityType. You don't have to mess around with registering resource names.
However, you must remember to add toType() to every query that needs it. Configure Breeze metadata with the resource-to-entity-type mapping and you'll get the desired behavior every time.
Notes
[1] "Most of the time, Breeze doesn't need to know the EntityType until after the data arrive from the server." One important exception - out of scope for this discussion - is when the query filter involves a Date/Time.
I think that the problem here is that you are assuming that entity type names and resource names are the same thing. A resource name is what is used to execute a query
var q = EntityQuery.from(resourceName);
In your case the "resourceName" is "Informacion" and the entityType is actually "Esto". Breeze is able to make this connection on a remote query because it can examine the results returned from the server as a result of querying "Informacion" and seeing that they are actually "Esto" instances. This is not possible for a local query because Breeze doesn't know what local collection to start from.
In this case you need to give Breeze a little more information via the MetadataStore.setEntityTypeForResourceName method. Something like this:
var estoType = manager.metadataStore.getEntityType("Esto");
manager.metadataStore.setEntityTypeForResourceName("Informacion", estoType);
Note that this is not actually necessary if the resource was defined via Entity Framework metadata, because Breeze automatically associates all EF EntitySet names to resource names, but this information isn't available for DTO's.
Note also that a single entity type can have as many resourceNames as you like. Just make sure to register the resourceNames before you attempt a local query.

Jena throwing ConversionException when trying to cast to OntClass

I have a particular Class URI for which I am trying to get an OntClass. The model is a regular model.
I wrote some code to find out whether the right statements were in the model, and it seems that they are so I can't understand why it won't let me view this as an OntClass. (tblURI is a String passed as a method parameter)
Resource tblR = m.createResource(tblURI);
List<Statement> prp = tblR.listProperties().toList();
for(Statement s : prp)
System.out.println(s);
System.out.println(tblR.canAs(OntClass.class));
OntClass tbl = tblR.as(OntClass.class);
This is the output:
[kps:datasource/EnsembleMS#translation_stable_id, http://www.w3.org/1999/02/22-rdf-syntax-ns#type, http://www.w3.org/2002/07/owl#Class]
[kps:datasource/EnsembleMS#translation_stable_id, http://www.w3.org/1999/02/22-rdf-syntax-ns#type, http://www.w3.org/2000/01/rdf-schema#Class]
[kps:datasource/EnsembleMS#translation_stable_id, http://www.w3.org/2000/01/rdf-schema#isDefinedBy, kps:datasource/EnsembleMS]
[kps:datasource/EnsembleMS#translation_stable_id, http://www.w3.org/2000/01/rdf-schema#label, "translation_stable_id"]
false
com.hp.hpl.jena.ontology.ConversionException: Cannot convert node kps:datasource/EnsembleMS#translation_stable_id to OntClass: it does not have rdf:type owl:Class or equivalent
at com.hp.hpl.jena.ontology.impl.OntClassImpl$1.wrap(OntClassImpl.java:81)
at com.hp.hpl.jena.enhanced.EnhNode.convertTo(EnhNode.java:155)
at com.hp.hpl.jena.enhanced.EnhNode.convertTo(EnhNode.java:34)
at com.hp.hpl.jena.enhanced.Polymorphic.asInternal(Polymorphic.java:66)
at com.hp.hpl.jena.enhanced.EnhNode.as(EnhNode.java:110)
at com.KPS.myApp.exampleMethod(myApp.java:123)
Why is it throwing an exception and how can I get an OntClass for the resource with uri tblURI?
Thanks for any pointers
You don't say what kind of model m is. In particular, if m was created with the RDFS language profile, the OntModel will be looking for an rdf:type of rdfs:Class, not owl:Class. If that's not the issue, then a complete minimal (i.e. runnable) example would help.
By the way, there's another problem I can see: resource URI's in the model should be in absolute form, not abbreviated form. The fact that you've got q-name URI's in your model, like kps:datasource/EnsembleMS#translation_stable_id, suggest that something is going wrong with your prefix handling. That won't by itself cause the problem you've reported, but it's a red flag to investigate.
Update
Responding to questions:
yes, you need to be using an OntModel, otherwise it's not possible for the OntClass to know which langauge profile to use. Either create the model as OntModel in the first place:
OntModel m = modelFactory.createOntologyModel( OntModelSpec.OWL_MEM );
or wrap your plain model as an OntModel:
OntModel om = modelFactory.createOntologyModel( OntModelSpec.OWM_MEM, m );
Of course, you many use any of the model specifications, as you please, OWL_MEM is just one option.
createResource will not expand prefixes for you. So, you should expand them yourself before creating the resource:
m.createResource( m.expandPrefix( "foo:bar" ) );
Of course, this requires the prefix "foo" to be registered as a prefix. This happens automatically if you read an RDF document that defines the prefix in its syntax, but otherwise can be done manually with setNsPrefix.

Resources