Given a composition container that holds a nested composition container, how do I access the nested container?
By default you cannot directly access the nested containers you passed to a container. However you could look at the Providers property which will list all the ExportProviders that are currently being used by a given CompositionContainer (CompositionContainer is just a special ExportProvider) and find the ones that are CompositionContainers.
Related
I have to implement one API where the API should export the JSON data. For example, there is one container component and many child components. Lets suppose, container component is holding the country and child component is strong different states and its population etc.
So the responsibility of the API is to search the population based on the state name or other query parameter.
One of the option I am thinking about using Sling model exporter because I do not have to write Sling servlet and it is easy to export the child components as json but the problem is, I could not find an option to pass request parameter to Sling model.
For example http://some.com/country/jcr:content/parent-component.model.json will give the result of child components but here how can I pass request parameter to this model endpoint for a specific state?
I know its possible to create a sling servlet but is it possible to do it using Sling model exporter?
You can inject the SlingHttpServletRequest in your model, and get the request parameter there from. Either in the getters or in your #PostConstruct method.
But there are no injectors available for the RequestParameters. This was for security reasons. So if you just use #Inject, then it just cannot happen that unwanted values are injected.
PS: The #RequestAttribute injector is for request-attributes, which are NOT query parameters.
I did face exactly the same issue and looks like the sling model exporter is dropping the parameters however I was able to solve this using request.getHeader("referrer") which gives us the complete URL including the parameters from which we can extract parameters.
Say I have an instance of a class which i need access to in many different places of my app. I have come up with three solutions so far
Passing the instance as an argument in every class of the app
Making a top level Provider above the MaterialApp-widget that exposes the instance to every method that has access to the app's context
Storing the instance in a static field
Which way is the best performance wise? Will the Flutter-framework ever discard the instance stored in the static field?
Which way is the best performance wise? Will the Flutter-framework ever discard the instance stored in the static field?
In this case, I like to use the DI framework like get_it
With the DI you can specify what is the object that you want and you can have it in your Wiget or Component, without coupled it with the specific implementation.
Use the get started guide to see how it is simple to use and what are the benefits.
Get Started
Suggestion
I suggest wrapping the library in one component inside your app, with the only motivation that with your own wrapper around the DI library you avoid to coupled all the app with the get_it, and you can change it easily in the future if you want.
Not sure about the performance, but the second option (Provider way) is what I am using in my projects and that's even a recommended approach (https://flutter.dev/docs/development/data-and-backend/state-mgmt/options#provider).
Passing the instance as an argument in every class of the app
This could lead to a very cumbersome code, every constructor would be cluttered by the same property passing all the way down to the Widget tree - not a Flutter way at all, that's why InheritedWidget was introduced some time ago, and later - Provider.
Storing the instance in a static field
It depends. E.g. it is ok to store all the colour constants inside a class having static fields - that's just convenient to access them everywhere. This option could also work in your case (not sure about the size and the amount of information stored in that class instance), but implementing your class as a Singleton would probably make more sense than storing the whole instance in a static field.
I'm confusing about this point since almost all DOM nodes are some sub-interface of the Node interface, but I can't find the precise definition that can prove this. Is there anybody know more about this? thanks.
Yes, all nodes inherit from the DOM Node interface:
The following interfaces all inherit from Node’s methods and properties: Document, Element, CharacterData (which Text, Comment, and CDATASection inherit), ProcessingInstruction, DocumentFragment, DocumentType, Notation, Entity, EntityReference
And also, according to W3:
The Node interface is the primary datatype for the entire Document Object Model. It represents a single node in the document tree. While all objects implementing the Node interface expose methods for dealing with children, not all objects implementing the Node interface may have children. For example, Text nodes may not have children, and adding children to such nodes results in a DOMException being raised.
I would like to use a common data structure of kubernetes to represent objects including services, replication controller, deployments, statefulset, daemonsets, etc. Now kubernetes api already provides individual data structures for each of them and the data structure that i could find the closest to representing a common structure are
type ObjectMeta
type ObjectReference
reference : https://github.com/kubernetes/api/blob/master/core/v1/types.go
The reason I do not select one of the above two structures is because I need to use the status field of most objects so that I can check if
`replicas==readyreplicas==Availablereplicas`
or to check for most things
Desired==Current==Available
There is no common structure which can describe each object in Kubernetes, except using some dynamic one, but it will be hard to validate the structure of objects based on dynamic objects inside it.
Each type has a different set of objects inside. If you want to work with Kubernetes objects, just use proper structures from core.
Is there a way to modify a JCR node, but keep its jcr:lastModified and jcr:lastModifiedBy properties unchanged?
And by modifying, I mean via the JCR API. For example:
aNode.setProperty("propName", aValue);
It is possible for the most cases. There are basically two options how a node retrieves both properties and get's them updated.
Either through some higher level API like CQ's PageManager, which is applying it on the jcr:content node or by the repo if the node has the mixin type mix:lastModified in it's type hierarchy.
[mix:lastModified]
mixin
- jcr:lastModified (DATE) autocreated
- jcr:lastModifiedBy (STRING) autocreated
In this case the properties are automatically managed through the repository.
So you should be fine, as long as you avoid to create nodes with the mentioned mixin in it's type hierarchy e.g. nt:resource.