I add one customer field called WrapperSuppressed into a widget content part. I can add and remove the wrapper for any widget. This boolean field is for management purpose, not for content. I'm trying to hide this filed in front end.
I put one line in placement.info, like this, which is working.:
<Place Fields_Boolean-WrapperSuppressed="-"/>
I need to add more condition, like the content part, which this field belong to, like this
<Place Fields_Boolean-WidgetPart-WrapperSuppressed="-"/>
This does not work.
Anyone can help me on this issue?
This is not how it works: you can't just make up shape names like that. The first part of the attribute name has to be the shape name as emitted by the driver of the field (Fields_Boolean in your case), and the second is the name of the field. Do you have more than one field named WrapperSuppressed on any content type? If so, that's probably not such a good idea. There are other conditions that you can put into a Match tag surrounding the Place. You can match on content type, display type, and path. I recommend you read http://docs.orchardproject.net/Documentation/Understanding-placement-info for all the details.
Related
MediaLibraryPickerField has a seeting named "DisplayedContentTypes". I think it is used to provide only required content types that I want my picker field to select and render. But somehow it is not working.
E.g: I want to select only Image,OEmbed types. I put it in the settings area's text box:
Content Types and Parts
[Image,OEmbed]
A comma separated value of all the content types or content parts to
display.
and saved it. But it is still picking all kind of media and rendering them.
Any thing I might be missing here??
There is an open issue here https://orchard.codeplex.com/workitem/21051
There is no fix yet although.
Indeed, the property exists but is not used.
We should try to implement a filter, as it is done for the content picker field.
I have created a custom content type (via the admin UI) that consists mostly of text fields. I know how to position the fields using zones and Placement.info but for simplicity I would like to use a single view template and to just arrange the fields by name instead of having to use Placement.info. Is there a good way to reference the fields by name from the content item in my MVC view?
So for example, I have a template named Content-MyContentType-Detail.cshtml. Instead of the generic
#Display(Model.Content)
I would like to be able to do something like
#Display(...MyField...)
#Display(...MyOtherField...)
Is there a way to explicitly render a field by name that is associated with my content item?
You can use Shape Tracing module to view model properties and how to get access to content parts.
Then in your template you can use something like this:
<h3>#Model.ContentItem.TitlePart.Title - £#Model.ContentItem.Product.Fields[1].Value</h3>
<p>#Model.ContentItem.BodyPart.Text</p>
If you don't just want to access the field's properties, but rather would like its shape rendered in-place, but like it would be when using placement (i.e. using the existing template), then read this article, which describes how to do direct rendering without placement: http://weblogs.asp.net/bleroy/archive/2013/02/13/easy-content-templates-for-orchard-take-2.aspx
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.
I am trying to create a Custom Field Type in SharePoint.
This control has it's value set based on another field in the same list.
Because of this requirement, this field should be displayed only in the Display Mode, and not in the Edit or Create mode.
How do I ensure this?
If I just code the ASCX control to not render a field, the field will show up like this in the Edit and Create mode.
alt text http://www.mannsoftware.com/blog/Lists/Photos/121308_0204_CrossSiteLo6.png
Generally you set the SPField.ReadOnlyField property to True to achieve the desired behaviour for any field. (Don't forget to SPField.Update accordingly!) There is an equivalent CAML attribute for list definitions, I believe.
That said, in your control class deriving from BaseFieldControl, you might just override the RenderFieldForInput() method and not call the base implementation to ensure nothing is rendered during Create or Edit. However, this would still render the field's table row in the form, which is probably not what you want. So to enforce the desired behaviour, use ReadOnlyField and override Update() in your SPField (not field control) class to always have it set to True.
It might be easier to just change this on a list-by-list basis by going to the Advanced section of the List Settings, setting Allow management of content types? to Yes, and then editing your content type to change the value of your field to 'hidden'.
Take a look at this blog post. I think it will give you some ideas. The concept uses different rendering templates based on the mode.
http://sharepoint.nailhead.net/2008/04/creating-rendering-template-that.html
Did you try and set the field as hidden?
http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.spfield.hidden.aspx
Custom FORMS pages for new item and edit item (NewForm.aspx and EditForm.aspx) would be another way to achieve this.
Setting the ShowInEditForm and ShowInNewForm properties solved this for me.
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();