Is it possible to translate the display name of choice list items defined for LightSwitch entity properties?
I would like to be able to show different users translated display names in their language when they are viewing the SAME record, and also show translated names in the autocomplete combo box when they are editing a record.
Not really, no. The values are stored in the LSML file & aren't able to be modified at runtime. If you need to translate the values, then you'll need to use a lookup table (possibly by using a custom RIA service) instead of a Choice List.
The advantage of a Choice List is that it's very quick & easy to set one up.
The down side of a Choice List is the lack of flexibility, or even reusability (you have to define the values for the list every time you want to use it somewhere).
Related
Default a submitter (uploader) of a document can add self chosen keywords to that document.
It is also possible to configure DSpace in a way that the submitter has to choose from one or more predefined keywords (controlled vocabulary).
The DSpace manual seems to suggest that you - when configuring - have to choose between free and predefined keywords.
I would like to give the submitter the possibility to choose between one or more predefined keywords. But also that he or she can add one or more self chosen keywords.
Is that possible?
The hierarchical taxonomy feature gives you exactly this:
https://wiki.duraspace.org/display/DSDOC5x/Authority+Control+of+Metadata+Values#AuthorityControlofMetadataValues-HierarchicalTaxonomiesandControlledVocabularies
You can see it in the demo installation on the "subject" field: you have a lookup feature that allows lookup in a tree of subjects, but manually entered values are possible as well.
screencast:
http://screencast.com/t/0Cth3mORwxd
I personally would set this up to use two different metadata fields.
Something like dc.subject.whateverdescribesyourlistoffixedterms -- or even localschema.subject.whateverdescribesyourlistoffixedterms -- for the list of terms the user should select from. Note, for "whateverdescribesyourlistoffixedterms" I would choose something related to the name of the list of terms if at all possible (see example below).
dc.subject for "standard" user-supplied keywords
Then just add both to your input forms, perhaps going with Bram's suggestion of a hierarchical taxonomy for the first.
To give you better advice on what's most appropriate, it would be great if you could give some more details about what you're trying to achieve. For example
Is your list of fixed keywords something that's used beyond your own organisation? If yes, this strongly points to having its own metadata field to me, with the qualifier something that's related to the name of the classification system -- eg, dc.subject.anzsrc for the Australia/New Zealand fields of research codes.
Do you want to mix the two types of keywords in browse/facet options? You can do this even when they're in two separate fields. Have a look at the Discovery search filters & sidebar facets documentation and see how that puts dc.contributor.author and dc.creator into the author facet. The documentation for browse indexes has a similar example in the author browse.
Are both types of subject keywords required for submission? Both optional? One type required, the other type optional? You say in a comment (if I read you correctly) that you want the fixed keywords to be mandatory during submission, while the free-text keywords should be optional. That means they must be in separate metadata fields because otherwise you wouldn't know, if the submitter gives keywords, whether they are from the fixed list of terms or not. If you use separate fields, you can make eg dc.subject.anzsrc a required field in the submission form and dc.subject an optional one.
Assuming in a Rails app connected to a Postgres database, you have a table called 'Party', which can have less than 5 well-defined party_types such as 'Person' or 'Organization'.
Would you store the party_type in the Party table (e.g. party.party_type = 'Person') or normalize it (e.g. party.party_type = 1 and party_type.id = 1 / party_type.name = 'Person')? And why?
If party type can be defined in code, I'll definitely go with the names "Person" etc.
If you expect such types will be dynamically added by admin/user, and have such GUI for it, then modelling it and set it like party.party_type = 1
Of course there will be a db storage/performance consideration between "1" VS "Person", but that's too minor to considerate when the app is not that big.
There are two issues here:
Are you treating these types generically or not?1
Do you display the type to the user?
If the answer to (1) is "yes", then just adding a row in the table is clearly preferable to changing a constraint and/or your application code.
If the answer to (2) is "yes", then storing a human-readable label in the database may be preferable to translating to human-readable text in the application code.
So in a nutshell, you'd probably want to have a separate table. On the other hand, if all types are known in advance and you just use them to drive specific paths of your application logic without directly displaying to user, then separate table may be superfluous - just define the appropriate CHECK to restrict the field to valid values and clearly document each value.
1 In other words, can you add a new type and the logic of your application will continue to work, or you also need to change the application logic?
I have a field "taxonomy" and I would like to pass it to Omniture. This Taxonomy field can have multiple values and I would like to calculate the count for each of the taxonomy separately. Let me explain my question with an example:
Item can be associated with multiple taxonomy. Letz say we are talking about an item called "Item1". This item can be associated with taxonomy "Tx1","Tx2","Tx3".
So the js code will be like,
s.prop1 = "Item1"
s.prop2 = "Tx1, Tx2, Tx3"
I was expecting omniture to store individual buckets/counters for "Tx1" "Tx2" and "Tx3". But Omniture created one bucket for "Tx1, Tx2, Tx3". I hope there is a way to treat them separately. Ideally I would not like to pass the taxonomies separately in separate prop variables.
I would appreciate if someone can point me in the right direction.
Thanks,
Rag
Actually Omniture does support list-style props, aptly called a list prop. You have to talk to Client Care to enable it for your prop, and you will need to specify a delimiter to use (like the comma). Then you would populate it exactly as you are doing, except without the space between the comma and value. ("a,b,c" not "a, b, c").
An alternative is the list eVar as Racheet mentioned. The difference is that a list prop sends in values and each value is within a prop variable scope, vs. the list eVar values are recorded with an eVar scope.
If you decide to do it w/ a list eVar instead of list prop, read up on how Omniture handles the allocation for them..there are some implications to consider with them only being able to be set to first or last allocation...
Omniture does have the functionality you're looking for from version 15 onwards. Unfortunately it won't do it in a prop. You need to use a slightly different variable type. The variable you're looking for is a list eVar.
Every implementation has three of these available:
s.list1
s.list2
s.list3
Here's the blog post where Omniture introduced them.
You can also find information on them in Knowledge Base article 10549 from inside the Adobe Marketing Cloud interface.
How can I create a form-only look up in Informix 4GL? I am using form painter plus the informix SE. Any help would be appreciated. I tried to create the form but the field is empty while selecting the choice. I think I am missing the relation or something.
FORMONLY is the equivalent of DISPLAYONLY in isql perform screens. Why not just define the database columns in the attributes section and use the NOUPDATE attribute for each column, or use BEFORE EDITUPDATE OF tabname, ABORT?
Since I4GL doesn't come with a form painter, the only ways to know what you can do with it is by reading the manual for your form painter, or by experimenting.
I'm also not entirely sure what you mean by a FORMONLY lookup? It could be any of a number of items. But the basics are that the field in the form is FORMONLY.fieldname TYPE xyz where xyz is the appropriate type. You use a CONSTRUCT or INPUT to get data into that field; you process the input to do the lookup. INPUT is more appropriate for an exact value lookup; CONSTRUCT will allow more flexible querying.
Since you've not shown what you've tried, nor indicated which form painter you're using, it is going to be hard to help further.
(And I note you've asked this question on the IIUG (International Informix Users Group) mailing list for 'classics' too.)
I'm using Delphi 6, and I want a database bound list box with multiselect. I found three types of List boxes: TListBox, TDBListBox and TDBLookupListBox.
As far as I can understand, TListbox is not bound to database. TDBListBox and TDBLookupListBox can't be multiselected.
Is there a way to get a multiselect listbox binded to database?
The problem with databinding components is that they rely on a datasource and a datasource has only a single cursor. That is probably the reason why.
By the way, do you need to change the data? Else you could fill a normal listbox from a dataset. Or even use an invisible data listbox and copy the contents to a normal listbox.
Not as far as I know.
The standard is that you offer with the list a bunch of values in which 1 represents the current record.
Unless you have a multivalued field (against best practices) I can't see how you could multiselect...
Or what you might want is actually a sub-table?
DevExpress TcxDBListBox supports multiselect. I use their multiselect drop down check box bound to a database, it's sweet.
The components have methods you can implement to convert to and from your list; EditValueToStates and StatesToEditValue. While the data I store is not normalized (I store a semi-colon delimited list of version numbers), I created a full text search index on the field, with a semi-colon as a delimiter, and now I can still perform optimized searches on that field.
You could create your own custom listbox component that descends from TCustomListBox and add a Datasource property for your list, and another property such as TStrings to be used as a container to hold selected values. You could then post changes to your database using a button click.
If you fiddle with some of the options of a TDBGrid and restrict the columns it displays, you can make something that looks a whole lot like a listbox. Try setting the Options property to [dgTitles,dgTabs,dgRowSelect,dgAlwaysShowSelection,dgCancelOnExit,dgMultiSelect] and work from there.
In a TDbLookupListBox you have the option to bind two different things to data; first you can bind the list to a dataset (ListSource/ListField/KeyField), second you can bind the selected item to a field in another dataset (DataSource, DataField). There is nothing conceptually wrong with wanting to bind the list of items to a dataset, and then manually manage multiple selections, however I don't think it is possible with the current implementation without subclassing and enabling the required control styles.
Based on your comment to François, I would use a normal TListbox and write code to insert all distinct values into the list, and then handle the multi-select values yourself. Jeremy's solution also works, and the DevExpress Express Quantum Grid has a nice filter system which might even save you some other programming.