When you have auto-filename as the content type’s "Component ID", I remember when creating a new instance from that type, the "internal-name" is auto populated with the generated uuid by default. That behavior seems to have been removed in Crafter Studio 3.1, leaving "internal-name" blank and force the author to give it a name.
How do I get Studio to also automatically set 'internal-name' to the same generated uuid value?
I got it. I can uncheck “Required” for "internal-name" in the content type, and Studio will fall back to the value in the XML, which is the uuid. I just didn't realize that "internal-name" is optional. The resulting XML looks like this:
<component>
...
<objectId>db99f900-a57f-7b32-eb7f-ddc6e5565423</objectId>
<file-name>db99f900-a57f-7b32-eb7f-ddc6e5565423.xml</file-name>
<internal-name/>
Related
Is it possible to pass data into UI extensions assignments (meaning UI Extension X assigned to Field Y), in order to alter their functionality slightly for different situations, without having to reimplement the entire extension?
For example, CodeMirror is a really neat embedded editor, but it has a bunch of "modes," depending on what language you're working with. If we could even pass in a string to represent the desired mode when the extension is assigned to a field, that would remove the need to do a different extension just to use different syntax highlighting.
With this, there could now be a generic "CodeMirror Editor" UI extension which is then just configured a runtime.
On the other end of the extreme, we could specify entire JSON objects when the extension is assigned to a field, to further specify configuration options.
This would make UI extensions so much more...useful. Does this functionality exist now, or is there some way to reasonably make it work? Is there some place on the field specification where I can "park" a JSON string, then access it from inside the extension?
Contentful has launched something called "Configuration parameters" for UI extensions that could be used to solve this issue.
They have two types of parameters, installation and instance parameters. Installation parameters are set when installing the UI extension, and instance parameters are set when configuring a field on a content type to use the extension. The latter would be perfect for your use case.
To use this feature you need to:
Create a parameter definition for the UI extension in the extension.json file. E.g. a new instance parameter called "codeMirrorSettings" of type Symbol with name "CodeMirror Settings".
Within the extension, fetch the current parameters using extensionsApi.parameters.instance.codeMirrorSettings.
Documentation for configuration parameters can be found in Contentful's docs:
https://www.contentful.com/developers/docs/references/content-management-api/#/reference/ui-extensions/configuration-parameters
https://github.com/contentful/ui-extensions-sdk/blob/master/docs/ui-extensions-sdk-frontend.md#extensionparameters
What you could do is just read this setting from another field, be that a string or a json object.
For example the slug generator automatically generates its value from the title field.
You could perhaps do something like this:
const cfExt = window.contentfulExtension || window.contentfulWidget
cfExt.init(api => {
var langField = api.entry.fields.mirrorLang || 'default'
//Rest of implementation
})
Well, I wrote something for this, specific to my situation, but generalizable to others. This is an example if a UI extension that retrieves settings from another entry in the space, and uses it to dynamically configure itself.
https://github.com/deanebarker/contentful-code-editor
I am new to Hybris and was following the Commerce trail given in Hybris wiki. I can see that they perform "Update" under "Platform" tag. What does this operation do ?
From the above link. for people who do not have wiki access or if page moves.
Update
During an update, type system definitions are modified to match the new type system definition in the items.xml files.
First and foremost, the update mechanism makes sure that all data that existed in the system before the update is still accessible after the update.
Therefore:
•Update preserves the table name, to which a type was mapped, even if it was changed in items.xml
•Update preserves the column name, to which an attribute was mapped, even if it was changed in items.xml
•Update preserves the column type for an attribute, even if it was changed in items.xml
•Update does not drop any tables and columns
•Update does not delete any item data, including type instances and type system data (composed types etc.)
•Update drops and recreate indices, if they are added or changed in items.xml
•Update does NOT change the attribute from optional to mandatory, even if it was changed in items.xml
This is what the process looks like:
1.The type system definitions from all extensions items.xml files are read in.
2.The hybris Commerce Suite type system in the database is modified according to the type definitions of all extensions items.xml files.
A. Adding newly defined types to the type system definition in the database.
Type definitions and attribute definitions that are not part of the type system definition in the database are added.
B. Modifying existing types to match the type system definition in the database.
Type definitions and attribute definitions that are changed compared to the type system definition in the database are modified.
C. Again, like in the init process, the old update logic (prior to hybris Commerce Suite 5.1) iterates through extensions and uses extension manager methods to create and modify types. Whereas, in the new update (since hybris Commerce Suite 5.1), ddl and dml scripts are also generated here.
D. Update then continues with creating essential and project data, optionally, if selected.
As you have access to the hybris wiki you should check the following URL: https://wiki.hybris.com/display/release5/Initializing+and+Updating+the+hybris+Commerce+Suite
Here you will find everything about the initialize and update functionality in the hAC of hybris.
By default, jhipster create entity with id as long/int. I would like to use "String" for id. How to do that?
There are two steps:
Of course the property type in the Java class must be changed to String (and also update the getter and setter for that property).
Then create a Liquibase changeset that modifies the data type to String. See: http://www.liquibase.org/documentation/changes/modify_data_type.html
If there are foreign keys that depend on this id, then makes it a bit more complicated because the fk's will need to be dropped and recreated after the columns have been changed to String.
Take a look at src/main/resources/config/liquibase/changelog to see how to set up a changeset consistent with the jhipster. I usually copy an existing changeset, give it a new file name so that it is the last file in the directory (so you can see a chronological sequence of changes), and update the changeset id.
Then, the changeset must also be added to src/main/resources/config/liquibase/master.xml so that it is activated on the next app start.
For some reason, a row named "rowguid" with a "uniqueidentifier" parameter was added to some tables on an already existing project. While regenerating the code, I found out that a method named "Insert(string Key)" was used, but doesn't exists anymore (it's now Insert(string Key, Guid varRowguid).
Is there a way to "ignore" a column while generating the code?
Note : The default of this new "rowguid" column is the Sql server method newsequentialid()
UPDATE : I added a "new System.GUId()" as a second parameter but I'd like to not have to modify the code...
With subsonic 2.1, you can edit the templates that are used to generate the code. I've added a "IF" and checked the "rowguid"... if it's the case, just ignore it.
When beginning to develop against SharePoint I did not fully understand all the ins and outs initially. I created a list definition (for a document library) and associated various custom actions to it. Unfortunately, I used the following for the list definition itself:
<ListTemplate...
...
Type="101"
...
And to register the CustomActions against the list:
<CustomAction...
...
RegistrationType="List"
RegistrationId="101"
...
Of course, this means that the custom actions are visible for all document libraries where the feature is activated which is undesirable behaviour. Also, there are lots of these document libraries that have been created from the above list definition in production.
What is the best way to fix this problem? My assumption is that I somehow need to change the "Type" attribute of the already existing lists, but I do not know how to do that. Can it be done via some direct SQL manipulation perhaps? Or is there a better way?
Note: I can see that the AllLists table has a column tp_ServerTemplate, is that the right thing to change?
Modifying the SharePoint database is completely unsupported by Microsoft. Please do not do this on production!
Another option is to create a content type and associate the custom action with that. You may need to write a simple console application to iterate through your existing document libraries and add the content type so it is available for use. The existing documents that you'd like the custom action to apply to would need their content types changed as well.
From some quick initial testing it does look like changing the AllLists table does the trick.
So steps to resolve:
1) Change List Definition Type attribute to be a unique value (for example 11000)
2) Change the CustomAction RegistrationId attributes to be the same (11000)
3) Update the tp_servertemplate column in the AllLists table to be the new template Type (11000) for all the relevant lists.