Document structure : add localizable field? - liferay

I need to create a new document type with a localizable "Description" field.
I've added a textbox field, and i've set localizable = yes
But when i create a new document using this document type, i cannot give some translation for my field.
Did i miss something? (i'm on Liferay 6.2)
Thanks!

Liferay supports localized document fields, but GUI is not much helpful here. It hides the feature completely.
How to set the localized values:
Create document of your type and provide values in the default language (currently displayed language).
Save the document.
Change the language of the admin console by manipulating the url - Insert the language code before /group/control_panel/manage fragment. Example for changing the language to Czech ('cs' language code) - http://localhost:8080/cs/group/control_panel/manage?...
Edit the document and provide values in the new language.
Save the document.
You can verify the data in the database - the custom fields are stored in DDMCONTENT table (column XML). For example:
<root>
<dynamic-element default-language-id="en_US" name="localizedText">
<dynamic-content language-id="en_US"><![CDATA[cat]]></dynamic-content>
<dynamic-content language-id="cs_CZ"><![CDATA[kocka]]></dynamic-content>
</dynamic-element>
</root>
Answered for Liferay 6.2.

Related

Umbraco add custom Document Type

Is it possible to add a custom control to the Document Type? Suppose i couldn't create a multiselect or just a simple textfield control. How could i create a custom one and use that from the Document Type page in Umbraco?
If this is possible, then what steps need to be taken? Because i can add all sorts of config information in the Document Type controls that currently exist in there. Like, when i add a textfield i can gvie it a name, an alias and a validation message (and it has some others options).
Do i have to build the custom Document Type control in a specific way? And how is it saved to the database? How does Umbraco handle that?
Any information on this matter is more than welcome!
Since adding custom document types is native to Umbraco, and judging by the description in your question, I'm going to assume that you are talking about adding custom data types with user controls.
If so, check some of the following links on the subject, it's actually fairly simple:
Creating custom datatypes using the umbraco usercontrol wrapper (I personally used this one)
Custom DataTypes in Umbraco
Creating a custom datatype using the usercontrol wrapper (Video tutorial)

Sharepoint Document Library Schema.xml Customization

Hi I am trying to add a custom field to the Schema.xml of Document library in sharepoint
here is the code that I took from a blog
In the ID i have to put the guid to do so
do I have to add my own guid or do i have to query the sharepoint database and find the guid and paste it there...
If i have to get it from sharepoint database which database and in what table I will find this information....
any help will be greatly appreciated
Thanks,
srikrishna.
This is now a duplicate post from MSDN forms
http://social.technet.microsoft.com/Forums/en-US/sharepointcustomization/thread/72df8c80-9e58-4c09-b1a6-ddfe1fb96b0a
there is a sure and safe mean :
1 - create a list with the SharePoint UI
2 - add a column to the list within the SharePoint UI
Create an applicative page that gets the schema of the list and you are done :
SPList mylist=SPContext.Current.Web.Lists["myNewList"];
string schema = mylist.SchemaXml;
schema = schema.Replace("<", "<");
schema = schema.Replace(">", ">");
string myAddedColumnSchema = mylist.Fields["MyAddedColumn"].SchemaXml;
myAddedColumnSchema = myAddedColumnSchema .Replace("<", "<");
myAddedColumnSchema = myAddedColumnSchema .Replace(">", ">");
Response.Write(schema);
Response.Write("<br>");
Response.Write("<br>"); Response.Write(myAddedColumnSchema );
Response.Write("<br>");
Response.Write("<br>");
This gives you the schema of the list with the field, and also just the field row in the list schema (of course copy the result in Visual Studio and use "Format Document" because on the web page it is just unreadable.
You cannot use this list schema by copying and pasting it in a SharePoint 2010 list Schema but you can locate the place where put the XAML correponding to your custom field.
After that you have to create a custom Content Type just for your custom field.
With SharePoint 2007 you could put a local content type corresponding to the custom field within the list schema but IT IS OVER. (I think... if someone can do it I will be pleased to be wrong ;-))
Then install the list feature with the new schema, and activate it within a site.
Then install the Content Type feature and activate it.
Then create a list based on the new schema, allow content type gestion for that list and add the new content type.
All the items based on the new content type will be allowed to use the new field.

Cascaded ListBoxes using SPFieldMultiChoice - issue defaults to default Content type

I wound up modifying the source from a publically posted POC: http://datacogs.com/datablogs/archive/2007/08/26/641.aspx, which is a custom field definition for cascading drop downs. The modifications were to allow parent-child list boxes where a user can multiselect for filtering and selecting the values to be written back to a SharePoint list.
I got the parent-child cascading behavior working, but the save operation only takes the default Content Type value.
I changed the base type for the custom field control from "SPFieldText" to "SPFieldMultiChoice", along with changing the FLD_TYPES field definition values from: "Text" to "MultiChoice"
Steps Explained:
1. The custom field is created which is derived from ‘SPFieldMultiChoice’ class. The custom field allows multiple values to be selected.
2. The Field created using above custom field is added to custom content type created from GUI derived from ‘Document’ Content type.
3. The custom content type is added to the document library.
4. The document is uploaded and custom content type is selected and tagged to document.
A. The correct content type gets tagged with correct metadata if type of document is .xls,.doc,.txt etc
B. The default content type i.e. ‘Document Content Type’ gets tagged if type of document is .xlsx, .docx.
Issue Summary – Point#B: is an issue as correct content type is not tagged and default content type gets tagged if type of uploaded document is .xlsx or .docx.
However same content type , same custom field works if type of document is .xls or .doc.
Appreciate your inputs in this regard.
Thanks for taking the time to read through my post.
Cheers, ~Poonam
Not sure why this is happening, it might be a good idea to notify Microsoft of this behavior. The difference between .doc and .docx you describe is very, very strange. Could you try setting the content type in an itemeventreceiver, to force the ContentType or ContentTypeId field of the item to reflect the correct content type explicitly.
i.e.
item["ContentTypeId"] = new ContentTypeId("0x010100your_id_plus_the_part_added_by_list");
the_part_added_by_list is the extra guid that is added when a ctype is added to a list
this is because ctypes in a list are basically children of the actual ctype you added
i.e. 0x010100 YOURGUID 00 LIST SPECIFIC GUID,
you can get this full id using a tool like Stramit CAMLViewer, or progr. by looping through the SPLIst's ContentTypes collection.
(my guess would be to do this in the ItemUpdating / ItemUpdated event to see if there is a difference in ctype during those calls)

sharepoint lookup field how to programmatically filter to lookup only in current document library

I want the lookup field to be filtered to only display titles from the current document library (meaning the document library that the user is currently in). I cannot specify the document library b/c I don't want to have to define a new lookup column for each new document library...instead I'm hoping to do this as a custom content type that can be used in any document library.
It would ideally be deployed as a feature.
Look into http://msdn.microsoft.com/en-us/library/ms446361.aspx">SharePoint Custom Fields.
http://msdn.microsoft.com/en-us/library/ms446361.aspx
This kind of feature does not exist on SharePoint OTB.
Take look at this thread: http://social.technet.microsoft.com/forums/en-us/sharepointadmin/thread/722EE26B-EC33-4618-8041-FAA92E149DE8. It provides some solutions though.

How to create a lookup column that targets a Doc Lib and uses the 'Name' of the document?

How do you create a lookup column to a Document Library that uses the 'Name' of the document as the lookup value?
I found a blog post that recommends adding another custom field like "FileName" and then using a item reciever to populate the custom field with the value from the Name field but that seems cheesy.
Link to the blog in case people are interested:
http://blogs.msdn.com/pranab/archive/2008/01/08/sharepoint-2007-moss-wss-issue-with-lookup-column-to-doc-lib-name-field.aspx
I've got a bunch of custom document content types that I dont want to clutter with a work around that should really work anyway.
I created a one step workflow to set the title from the name, fired on modify and created. Seems to work and took seconds to create.
One way you can do this (although not the easiest way) is by creating a custom field type that extends the SPFieldLookup class. SharePoint's field editor for Lookup fields purposefully hides any columns types that aren't supported by Lookup fields, but you can create a field editor for your custom field type that shows them.
However, I have created a Lookup column that points to a Name column in a Document Library before, and it probably doesn't work like you'd expect. While the value stored in the lookup column is valid, it doesn't show up right in List view or on the View Properties form.
The solution you posted may actually be the best way to handle this. Lookup fields require some kludges if you want to handle more complex scenarios, but that's because they're not meant to provide the same functionality as a foreign key relationship in a database.
Coding in any form always scares me. So Here's what I did: I simply renamed the Stupid "Title" Field to something else, say "Keywords", since you cant do anything with that field: cant even make it mandatory.
Then I created another Single line field called "Title" and used this field for the Lookups
Well there is a simple solution to that and in might work in some case.
In the nutshell if you make the Title field Mandatory, this will force the user to enter a title. In that manner we can use title field as a lookup field.
Now How to do that?
One you are done create a document library go to the library setting. Select Advance Setting and Select Yes for the option "Allow management of content types?".
Then go back to the Library setting and Under content types select the "Document" Content type. THen Select Title Column and then Select "Required (Must contain information)" and say OK.
Now try uploading a document to this document library. You will see Title field in the form.
Hope this helps
Cheers
Vaqar
You have to add the field as XML with the ShowField as 'FileLeafRef'
var XmlFieldDefinition = "<Field DisplayName='myLookupColumn' Type='LookupMulti' StaticName='myLookupColumn' Name='myLookupColumn' Required='FALSE' List='THE LOOKUP ID HERE' WebId='THE WEB ID HERE' UnlimitedLengthInDocumentLibrary='TRUE' Mult='TRUE' Sortable='FALSE' ShowField='FileLeafRef' />"
Field fld = fieldCollection.AddFieldAsXml(XmlFieldDefinition, true, AddFieldOptions.DefaultValue);
ClientContext.Load(fld);
ClientContext.ExecuteQuery();

Resources