Drop down menu for String values in Hybris Management Console - sap-commerce-cloud

I have a requirement to display a drop down menu for a String type in Hybris Management Console, restricting the value to some specific values.
As suggested in several forums, I tried to create this entry as an enumeration type but characters like '-' are to be allowed in the enumeration values, as this column receives some specific values which comprise of '-'.
How do I solve this issue?

The people advising you probably didn't understand your requirements. As such, an enumeration type is clearly not appropriate in this case. Consider the alternatives. Is there a Map Type available? What other type might allow you to achieve your goal?

Actually, you could use the hybris Enumeration. In hybris Enum Types have a code and a name. The code is the unique representation for this enum and cannot contain a "-". The name however is a localized representation of that value and can include every character your database is able to store. Have a look here:
https://help.hybris.com/6.5.0/hcd/8c895989866910148d6a802f06651702.html
Additionally, hybris enables you to dynamically create new enumeration values, which is kind of nice.

Related

Valid xsd:DateTimeStamp Literal value in owl

I have included into my ontology a specific data property which is of type xsd:DateTimeStamp as I am looking into this website which provides examples of supposedly acceptable literal values of that format http://www.datypic.com/sc/xsd11/t-xsd_dateTimeStamp.html
I copy pasted both those literal values suggested into my data property separately :
2004-04-12T13:20:00-05:00
2004-04-12T13:20:00Z
But unfortunately both the hermit and the pellet reasoner whine about an inconsistency there.
Can someone explain to me why this is wrong and provide a valid literal value example that would pass the reasoners ?
I am using the OWLTime ontology and this is the 'in XSD Date-Time-Stamp' data property to be more precise, and the tool I use is protege 5.5.0
Both Data properties are correct, what was needed upon insertion in the box was to select from the drop down type list the "xsd:dateTimeStamp" then the reasoner stopped complaining. Although it is weird because in other custom occasions I did not deal with the same problem

Is it possible to add a collection of strings directly into the Sitecore Content Editor?

here's a really quick question...
Is there a type of Sitecore Editor control that I can use in the Template Builder to enable the product owners to add a free collection of strings in the CMS Editor?
I know that I can add a simple data object that has a single string field, add a number of these data objects and then add a Multilist to the Editor with that group of data objects as the Source, but that would mean that the product owners would have to add all of their strings as these data objects and then select them from the Multilist.
I'm trying to make it simpler for them, but I can't seem to find a Sitecore Editor control that enables them to enter a collection of strings directly in the Editor... is there one?
The short answer is no, there is no way to do this in Sitecore.
All hope is not lost, however. You can always create your own field type for something like this, but doing so does require a significant level of effort.

why I don't always get ItemElementName in wsdl+xsd code generation from choice-element with WSCF blue?

I use WSCF blue to generate web service code from wsdl. Sometimes choice-element in xsd is generated to Item and ItemElementName. Sometimes just Item. Couldn't find any logic in this.
The answer it that there must be choice-elements of same type in schema. E.g. 2 int choices or 2 string choices so it can't be known anymore only by type. In my example had three different types in choice -> no ItemElementName enumeration and property.

What is the difference between `ID` and `Internal ID` for NetSuite records?

According to the help pop up:
ID
This field's value represents the script ID, used to identify this
record for scripting purposes. It is a text field.
Internal ID
This field's value is a read-only system-generated unique identifier.
It is an integer field.
Both fields seem to uniquely identity a record type.
One is a string, one a integer.
The string ID is used for searches and
loading of records, but I've also seen Internal ID used when
referring to a record type from a lists point of view.
Can anyone provide the reasoning behind having two identifiers and when to use one versus the other when scripting?
The major difference is that you (as the creator of a custom record or script) are in complete control of the text ID. You can establish patterns and best practices for defining these IDs, and it will make it very easy for developers to identify record types just by looking at the string ID. You have no control over the numeric ID. When looking at code, it is much easier for me to determine what records I am referring to if it looks like:
nlapiSearchRecord('customrecord_product', null, filters, columns);
nlapiResolveURL('SUITELET', 'customscript_sl_orderservice', 'customdeploy_sl_orderservice')
as opposed to looking at:
nlapiSearchRecord(118, null, filters, columns);
nlapiResolveURL('SUITELET', 13, 1)
I'm not even sure the second nlapiSearchRecord actually works, but I know that nlapiResolveURL can be written that way.
That said, if you simply let NetSuite generate the text ID, you'll end up with generic IDs like customrecord1, which I find no more useful than the numeric ID. It is a good practice to explicitly specify your own IDs.
Furthermore, the numeric ID can vary between environments (e.g. Sandbox could be different than Production, until a subsequent refresh occurs). If you are following good migration practices, then the text ID should never vary between environments, so your code would not have to make any kind of decision on which ID to use based on environment.
Rarely have I found myself referencing any record, whether native or custom, by its numeric ID; scripts are always using the text ID to reference a record type.

Difference between FieldLinks and Field in Sharepoint

I'm in the middle of trying to copy a custom content type from one web to another. I've googled around and found some examples that use FieldLinks and Fields. I'm kind of lost as to which one to use, since when I get the FieldLinks from my source web, I get 3 fields; while retrieving from Fields only returned me 2 fields... the custom field is missing. I'm pretty darn sure that I've added the fields at the proper level since I did it via the interface. But when retrieving it using code... the numbers just don't add up.
So besides from that strange problem, I want to know what is the difference between FieldLinks and Fields, and when dealing with them in Content Types (programmatically) which one should I use?
Thanks.
SPFields are fields themselves, while SPFieldLinks are references to the fields. This is a good read that will explain things in detail. In general practice, it is safer to use SPFieldLinks when you are working on the actual content type definition. However, I'll give a quick summary here.
Lists and Webs contain the actual fields with field data. A content type, on the other hand, only holds Field Reference, which simply points at the corresponding field in the list or web. This gets a bit confusing, because content types have both an SPFieldLinkCollection and an SPFieldCollection.
The SPFieldLinkCollection is used in the actual definition of the content type, and is what you would want to use in your situation of copying a content type from one web to another. SPFieldLinks correspond to the actual elements in the XML Schema for a content type.
Comparatively, when you call on a content type's SPFieldCollection and retrieve a Field from it, what is actually happening is that the content type is checking the corresponding field reference, and then looking up in the list/web to get the actual field. Basically, think of the SPFieldCollection in the same way a lookup works: it is worthless without both the lookup value and the lookup source.

Resources