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)
Related
Hi once again :) My next question about Orchard CMS looks trivial but..
I have my custom NewsModule with NewsItem type which consists of TitlePart, BodyPrt, and my custom NewsPart. NewsPart is based on NewsPartRecord.
Now I have to extend my NewsItem document type with Image. So far I found that there are ImagePart and MediaLibraryPickerField.
ImagePart stores width and heihgt of image, so I think it is something for internal use.
The next one is MediaLibraryPickerField. After googling for a while, I found that I can extend my NewsPart using WithField() method.
But! First question here: when I'm configuring Page type with Admin UI, I can add field to the type. But using Migrations I can't add field to NewsItem, only to NewsPart.
The second question here. MediaLibraryPicker allows me to select any type of file from library, image, text, zip or any other. And this is not what I actually need.
So, what are the best practices in Orchard to extend Items with icons?
thanks.
You can add fields to NewsItem, it just requires a different type of definition. It confused me too as it's not as intuitive as you'd like it to be.
To add parts you are using AlterTypeDefinition.
this.ContentDefinitionManager.AlterTypeDefinition(
"NewsItem",
cfg => cfg.WithPart("NewsPart"));
But to add fields you have to also use AlterPartDefinition and specify the NewsItem not the NewsPart.
this.ContentDefinitionManager.AlterPartDefinition(
"NewsItem",
builder =>
builder.WithField(
"NewsImages",
fieldBuilder =>
fieldBuilder.OfType("MediaLibraryPickerField")
.WithDisplayName("News Images")
// Allow multiple images
.WithSetting("MediaLibraryPickerFieldSettings.Multiple", "true"))
Considering second question, MediaLibraryPickerField has option to display only selected types/parts.
.WithSetting(MediaLibraryPickerFieldSettings.DisplayedContentTypes="Document,Video")
If you need new media type you have to create new ContentType with Stereotype "Media", it also needs "MediaPart" and part that defines metadata for that type. You can look at how Document or Video is defined for sample code.
Is it possible to associate a view with different documents (not simultaneously of course)?
What I want to achieve: the application can have multiple documents of the same type, that can be added during runtime, and set of suitable views, the main of which is CFormview-based. The user can choose the number of the document to show per combobox in the toolbar. The views then associate themselves with this document and update with data from it.
Is it possible to achieve with CMultiDocTemplate?
If yes, how? especially is it possible to retrieve a document by it order number?
If not I'll probably have to abstain from using the templates altogether, which of course means more coding (and more questions to friendly community), but it will do what I want it to do and not Microsoft thought I should be doing
Yes, you could but not out of the 'box'. Instead I'd recommend a different strategy. Rather than trying to attach a View to an existing CDocument derived class LOAD the Views CDocument with the information you want. That could done by adding a simple Copy method to the CDocument or you could move your actual data into a separate class then just point the CDocument to 'data' you want.
Trying to change the CDocument instance for a CView is going against the MFC grain which normally means lot of ASSERTS.
I'm trying to figure out the best way to handle a requirement I have for an Orchard module I'm building.
I have a ContentPart that has a few fields. One field is a ContentPicker that allows for multiple items to be associated to the part. The rest are descriptive information.
The issue I have is that I actually need to be able to include more than one of this ContentPart into a ContentType. I need to create a ContentType that has exactly 3 of this part.
Should I be making this into a field instead of a part? Is it even possible to have a ContentField that has other fields in it?
Or, should I somehow use all the same models and data structures, but somehow define it as 3 distinct parts?
Just wondering what the best practice to do something like this would be.
You can only have one part of each kind on a given type. You can't have fields that have other fields in it (instead - take an existing field and extend it with custom stuff).
As I understand, the actual problem is "how to make groups of fields with some metadata for each group", right? If so, there are a few approaches to solve the problem:
Create a custom field based on Content Picker (basically - take existing Content Picker and extend it with your metadata) and use this without the need for a separate part
Create one part to hold only the metadata for each field attached to it and attach 1 or more fields to it
Create 3 distinct parts. Parts should be thought of as extensions that add some unique features to an item. If you think it's logically ok to have 3 parts then go for 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.
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.