It is possible to share the same ACL between parent and child of a specific relation?
I defined on D2 client a dynamic ACL on parent object, based on some specific object attributes. I also defined a relation with another document object as child.
Now I'm trying to propagate the ACL value from parent to child object. I've done it by code in the following way:
IDfACL acl=sProtocollo.getACL();
idfdocument.setACL(acl);
idfdocument.setACLDomain(acl.getDomain());
where sProtocollo object is parent and idfdocument is child.
It works like a charm, but each time I modify parent object attributes responsible of acl modification, this modification is not propagated to its childs.
Is there an automatic way to let the parent acl be applied to its childs on each property modification?
If your parent objects are of the same object type write TBO (Typed Based Object) for your parent type. It is Java code and acts like some sort of trigger for objects of specific type.
Related
I have a parent component where the view model contains a property prop1.
In its view, a custom element has a view-model.ref="prop1".
export class Parent {
public prop1;
}
<template>
<custom-element view-model.ref="prop1"></custom-element>
</template>
This works like a charm and I get a reference to the view model of my custom element in my parent.
Now, I add a child router to parent with a child component. In child's view model, I add a property prop1. and in its view, a custom element has a view-model.ref="prop1". So exactly like I did in parent...
As soon as I navigate to parent/child, the parent's container prop1 stops referencing the custom element of parent and starts referencing the one from child.
If I name the properties differently, there is no problem.
Any idea why this happens? And how could I avoid this behavior without worrying about the naming of the properties?
EDIT
I chanced upon some more information! If the properties are initialized in the view model, I seem to be able to retain the references in the view models. Note that I'm using Typescript so I think the compiled code for an unassigned class property doesn't mention the property at all until it is assigned.
I still don't really understand where the problem comes from exactly...
And I remain with the same problem if I use a view-model.ref directly in the template without mapping it to an explicit property from the view model like this:
<template>
<custom-element view-model.ref="custom"></custom-element>
<custom-element2 opened.call="custom.opened()"></custom-element2>
</template>
when you create a property in a class and don't assign anything to it, babel/typescript will remove that property as if it was not even declared.. because it's really not doing anything.
typescript is interested in your definitions in compile time only.
now that your property in the child is emitted, you have a binding in the child to an undeclared property.
in that case, aurelia creates a property for you and bind to it..
but in your case, aurelia finds this property in the parent scope (just like regular JS scoping rules), and therefor do not create a "new property" in the child scope but rather binds to the parent property.
this is why when you initialize the property in the child (even with undefined) it "works". because you have 2 properties in 2 scopes.
and when you change the name, aurelia will create a new property for you..
and here come another rule - wen aurelia create a property for you - it creates it in the lowest scope available.. in your case - the child scope. and everything works again.
you can notice this behavior a lot with repeate.for, because the repeater creates an invisible scope for each repeate loop..
if you bind anything in the repeate to a property that dont exists, you will have that property in each child, and not once in the parent.
I'm trying to understand host and target (and element) in the following context taken from the Polymer Path and Polymer Data Flow documentation.
Consider the following diagram:
Now consider the following statement (from the same documentation):
"When two elements in the local DOM are bound to the same property data appears to flow from one element to the other, but this flow is mediated by the host."
So far, so good. Then it goes on to say:
"A change made by one element propagates up to the host, then the host propagates the change down to the second element."
The first part: "A change made by one element propagates up to the host..." Does this mean that a change to the first element propagates to its own host first? And does "element" actually mean the element's data properties?
The second part "then the host propagates the change down to the second element." Are we propagating down to the second element's data properties? It's extra confusing here as there is only one element or data object that is shared between the two ehhh elements??
I'm thinking that the change made in the first element's data property goes to its own host first and then the first host propagates the change back down to the second element's data element (which so happens to be the first element's data object as well).
<parent-el>
<user-profile primary-address="{{addr}}"></user-profile>
<address-card address="{{addr}}"></address-card>
</parent-el>
If either element changes addr (the child elements can use whatever name they want), the change will be propagated to the parent and then to the other element.
If either binding used [[addr]] instead, changes would only propagate from parent to child.
Note that both child elements should have notify: true set on the relevant property (primaryAddress or address) so that the parent is notified of changes and the two-way binding is fully setup.
Also note that this listens for the object to change as a whole only. To listen for changes to sub-properties e.g. addr.street the parent should add an observer. For more info on that see complex observers.
I have two polymer elements like
<moviegrep-element></moviegrep-element>
<custom-card-element></custom-card-element>
In moviegrep-element I got an array of objects called results. I want to use the results in my custom-card-element. How does it work?
Use Polymers data-binding:
<moviegrep-element results="{{sharedResults}}"></moviegrep-element>
<custom-card-element results="{{sharedResults}}"></custom-card-element>
This assumes that both of your elements publish the results property as an attribute. Changes to the results property in one element are then propagated to the results property in the other element.
This also assumes that your elements are itself inside a Polymer element. Otherwise you need an auto-binding template element
I want to access an element using a DOM hierarchy Node structure, through its parent nodes.I am trying to find the DOM hierarchy through firebug; want something like, <parent_node1>.<child_node1>.<child_node2> (not by document.getElementByID, getElementbyname) to access an element.
I want to automate a scenario like, I have column headers and corresponding values. Want to test, whether the values present under each column header, is correct...
I am thinking of using DOM as a method of automating this case...But, how can I find the DOM hierarchy...?
What I see through Inspect Element in Firebug is something like, list of events, elements and is not looking like a hierarchy node structure...Can somebody help in this regard please?
As discussed, you probably mean the DOM Element properties like element.childNodes, element.firstChild or similar.
Have a look at the DOM Element property reference over at JavaScriptKit, you'll get a good overview there how to access the hierarchy.
var currentTD = document.getElementsByTagName("td")[0];
var currentTable = document.getElementsByTagName("table")[0];
currentTD.parentNode // contains the TR element the TD resides in.
currentTable.childNodes // contains THEAD TBODY and TFOOT if present.
DOM Tables even have more properties like a rows collection and a cells collection.
A reminder of caution: Beware that these collections are live collections, so iterating over them and accessing collection.length in each iteration can be really slow because to get the length, the DOM has to be queried each time.
document.getElementById and document.getElementByTagname are using the DOM. They take an object within the DOM (specifically the document object, though you can also call both of those on elements) and return an object which is a single element or a collection of zero or more elements, respectively. That's a DOM operation. From there you can do other DOM operations on the results like getting children, parents or siblings, changing values etc.
All DOM operations come down to:
Take a starting point. This is often document though it's so often that the first thing we do is call document.getElementById or document.getElementByTagname and then work from the result that we could really consider that the starting point.
Find the element or elements we are interested in, relative to the starting point whether through startingPoint.getElementById* or startingPoing.getElementByTagname perhaps combined with some test (e.g. only working on those with a particular classname, if they have children of particular types, etc.
Read and/or change certain values, add new child nodes and/or delete nodes.
In a case like yours the starting point will be one or more tables found by document.getElementById(someID), document.getElementById(someID).getElementsByTagname('table')[0], or similar. From that table, myTable.getElementsByTagname('th') will get you the column headings. Depending on the structure, and what you are doing with it, you could just select corresponding elements from myTable.getElementsByTagname('td') or go through each row and then work on curRow.getElementsByTagname('td').
You could also just use firstChild, childNodes etc. though it's normally more convenient to have elements you don't care about filtered out by tagname.
*Since there can only be one element with a given id in a document, this will return the same if called on any element higher in the document hierarchy, so we normally just call this on document. It can be useful to call it on an element if we want to do something if the element is a descendant of our current element, and not otherwise.
Say I have an entity Parent, and an entity Child, such that Parent has a virtual ICollection Children property. In the db this is a simple foreign key from the Child table to the Parent table.
Now say I have a scalar string property on Parent called Text. During the set method of the Text property, I want to access instances in the Children collection property.
When EF 4.1 reconstitutes the Parent entity from the db (because of a ToList() call for example), it calls the set method on the Text property, and it always seems to do so before populating the Children collection.
Is there a way to tell EF to call set on the Children virutal collection property before calling set on the Text scalar string property?
You should follow #Slauma's advice from comment and change the code because this is wrong behavior for persisted properties. Even if following description works it will be highly error prone because you will always have to query data in specific way.
Your problem can be divided into multiple parts based on the way how you load entities.
Lazy loading:
If you load Parent andChild` are lazy loaded you cannot achieve reverse loading.
// Now parent is loaded
var parent = context.Parent.First();
// Even with lazy loading enabled and your setter accessing nav. property it
// should not load child collection because lazy loading should be temporarily
// turned off during entity materialization to avoid unexpected lazy loads
(untested) You can try manually load all child first and request parent after that:
// Now all child for given parent are loaded
var child = context.Child.Where(c => c.Parent.Id == ...).ToList();
// Now parent is loaded and if you are lucky it configures navigation property
// to loaded child prior to evaluating your setter - I guess setter will be
// evaluated prior to fixing navigation properties so it will not work
var parent = child[0].Parent;
The explicit loading will suffer the same issue.
Eager loading:
The problem is the same and it is based on the way how Include works.
So if you include child to parent the parent will be materialized first.
var parent = context.Parent.Include("Child").First();
Reverse operation in this case most probably doesn't help because calling
var childs = context.Child.Include("Parent").Where(...).ToList();
will evaluate records one by one and each record will contain single child and parent so I think the first time you access the parent you will have only single child and again you will be dependent on the order of operation EF does (the same problem as with lazy loading).