Konva shapes have both "id" and "name" properties. Presumably these are intended to serve different needs, but how should they be used in Konva? Are either used by Konva itself, or are they just holders for user-defined data?
OK, found elsewhere in documentation:
id is meant to be unique (like HTML id)
name is multi-valued like HTML class
Both are user defined.
Related
I have several times come across a want to have a Django model field that comprises multiple database columns, and am wondering what the most Django way to do it would be.
Three use cases come specifically to mind.
I want to provide a field that wraps another field, keeping record of whether the wrapped field has been set or not. A use case for this particular field would be for dynamic configuration. A new configuration value is introduced, and a view marks itself as dependent upon a configuration value, redirecting if the value isn't set. Storing whether it's been set yet or not allows for easy indefinite caching of the state. This also lets the configuration value itself be not-nullable, and the application can ignore any value it might have when unset.
I want to provide a money field that combines a decimal (or integer) value, and a currency.
I want to provide a file field with a link to some manner of access rule to determine whether the request should include it/a request for it should succeed.
For each of the use cases, there exists a workaround, that in each case seems less elegant.
Define the configuration fields as nullable. This is undesirable for a few reasons: it removes the validity of NULL as a value for the configuration itself, so tristates and other use valid cases for NULL have to become a pair of fields or a different data type, or an edge case; null=True on the fields allows them to be set back to None in modelforms and the admin without writing a custom FormField for them every time; and every nullable column in a database is arguably bad design.
Define the field as a subclass of DecimalField with an argument accepting a string, and use that to contribute another field to the model. (This is what django-money does). Again, this is undesirable: fields are appearing "as if by magic" on the model; and configuring the currency field becomes not obvious.
Define the combined file+rule field instead as an entire model, and one-to-one to it from the model where you want to have the field. This is a solution to all use cases, but again comes with downsides: there's an extra JOIN required for every instance of the field - one can imagine a User with profile_picture, cv, passport, private_key etc.; there's an implicit requirement to .select_related(*fields) on every query that would ever want to access the fields; and the layout of the related model is going to have cold data interleaved with hot data all over the place given that it's reused everywhere.
In addition to solution 3., there's also the option to define a mixin factory that produces the multiple fields with matching names and whatever desired properties and methods. Again this isn't perfect because the user ends up with fields being defined in the model body, but also above that in the inheritance list.
I think the main reason this keeps sending me in circles is because custom Django model fields are always defined in terms of a single base field, because it's done by inheritance.
What is the accepted way to achieve this end?
I have a situation where I would like to conditionally exclude a field from a query selection before I hit that query's resolver.
The use case being that my underlying API only exposes certain 'fields' based on the user's locale, and calls made to this API will throw errors if fields are requested that are not included of that locale.
I have tried an approach with directives,
type Person {
id: Int!
name: String!
medicare: String #locale(locales: ["AU"])
}
type query {
person(id: Int!): Person
}
And using the SchemaDirectiveVisitor.visitFieldDefinition, I override field.resolve for the medicare field to return null when the user locale doesn't match any of the locales defined on the directive.
However, when a client with a non "AU" locale executes the following
query {
person(id: 111) {
name
medicareNumber
}
}
}
the field resolver for medicare is never called and the query resolver makes a request to the underlying API, appending the fields in the selection set (including the invalid medicareNumber) as query parameters. The API call returns an error object at this point.
I believe this makes sense as it seems that the directive resolver is on the FieldDefinition and would only be called when the person resolver returns a valid result.
Is there a way to achieve this sort of functionality, with or without directives?
In general, I would caution against this kind of schema design. As a client, if I include a field in the selection set, I expect to see that field in the response -- removing the field from the selection set server-side goes against the spec and can cause unnecessary confusion (especially on a larger team or with a public API).
If you are examining the requested fields in order to determine the parameters to pass to your API call, then forcing a certain field to resolve to null won't do anything -- that field will still be included in the selection set. In fact, there's really no way to create a schema directive that will impact the selection set of a request.
The best approach here would be to 1) ensure any potentially-null fields are nullable in the schema and 2) explicitly filter the selection set wherever your selection-set-to-parameters logic is.
EDIT:
Schema directives won't show up as part of the schema object returned in the info, so they can't be used as flags. My suggestion would be to maintain a separate in-memory map. For example:
const fieldsByLocale = {
US: {
Person: ['name', 'medicareNumber'],
},
AU: {
Person: ['name'],
},
}
then you could just access the appropriate list to filter with fieldsByLocale[context.locale][info.returnType]. This filtering logic is specific to your data source (in this case, the external API), so this is a bit cleaner than "polluting" the schema with information that pertains to the storage layer. If the APIs change, or you switch to a different source for this information altogether (like a database), you can update the resolvers without touching your type definitions. In fact, this way, the filtering logic can easily live inside a domain/service layer instead of your resolvers.
I am using the Dynamic Placeholders from Fortis, but need to setup a page template where the Dynamic Placeholders contains renderings. I am setting the page template up, by setting layout detail on the standard values of the page template.
I have been unable to succeed in this, since the dynamic placeholder is postfixed by a GUID which is generated. Is there a way to predict this GUID? According to the documentation, the GUID is generated using the following logic:
Dynamic Placeholders simply use the rendering ID to create a unique placeholder name. If more than one dynamic placeholder with the same name is in a rendering it will also append on an incrementing number
I tried another approach, by using a home brewed dynamic placeholder library, which just prepended the dynamic placeholder with a sequential number, e.g. row1, row2, row3. But this approach makes the content editors unable to move rows in the experience editor, since the content inside the row is tied to a fixed number, which changes when the rows are moved.
As this question have been answered on sitecore.stackexchange.com, I want to bring the answer here as well. Big credit to Richard Seal and Thomas D.
Thomas D:
You can try to open the standard values item with the Experience Editor and add the renderings you like.
Richard Seal:
This is an alternative to the method mentioned by Thomas D.
The Fortis solution uses the UID for the rendering attached to the placeholder key that you enter. You can get this by changing to Raw Values view and copying the xml out of the renderings or final renderings field.
Find the rendering that contains your placeholder. There will be an xml element like this:
<r id="{CA76EB6F-2934-4B8A-BB6A-508A8E44A7C5}"
ph="body"
uid="{0FD41EBD-43CF-4647-8A0F-F1F1D2E00CCD}" />
There may be other fields too. The 2 that are important are id, which is the item id of your rendering item and uid, this is the unique rendering id that is added to your placeholder key.
The key is built like this: string.Format("{0}_{1}", placeholderName, renderingId);
So if you have a placeholder key called title, the key for the above xml snippet would be: title_{0FD41EBD-43CF-4647-8A0F-F1F1D2E00CCD}
I am trying to display field titles above the appropriate columns in a name value list in Sitecore.
e.g. So instead of this
The name value list would look like this
Is there an easy method of achieving this apart from writing a custom control?
There is no out of the box support for applying a label to the values in a name value list, as #jammykam mentioned.
Since what you are storing would not typically be handled as key/value data, the name value list type might not be the best fit for what you are doing - think what you would have to do if you needed to add extra information e.g. title. I would suggest creating a simple template for 'person details' and then add 'people' items as sub-items of your existing item.
Seems like you want to give the authors a hint regarding the input fields and the best way to do that is using the "Short Description" field in "Help" section of the template under Standard Values. You can possibly enter something like as a hint.
A less optimal option would be to set up standard values for that field so the authors always have a value that suggests the type of input value for key and value.
Preface
I need to have objects (Object model) with an individual set of fields (Field model). It contains name and type (see the diagram). Each connection between Object and Field stores the field's value. Datatype of value depends on the Field type property and physically the value will be stored in one of the predefined db columns (value_number, value_text, ...).
How I want it to work:
field = Field.objects.get(pk=1)
sought_for = Object.fields.filter(field=field, value='test')
Is there a way to create such a field that can be put to QuerySet just as simple as in the example but it actually, depending on the field's type, uses different db column or even columns as I suppose that in the future there will types that involve more than one column to store its value.
P.S. I tried some EAV applications but they seemed to be too complicated for my case.
The diagram:
Field model, it stores name and type of fields
FieldValue, the model the values for the fields are stored.
UPD: Eventually I came to a thought that the very approach to use Postgres (or any relational database) is not the best choice. I got this implemented easily in MongoDB.