Custom properties broken?

Dick Scherpenzeel

Vote:

Custom properties do not work. The CMS UI just gives an empty text-input field without the [...] button next to it.

Steps to reproduce.

01. Create a custom property

    [Serializable]
    [PropertyDefinitionTypePlugIn]
    public class CustomDropDownListProperty : PropertyDropDownList
    {
        public override IPropertyControl CreatePropertyControl()
        {
            return new CustomDropDownListControl();
        }
    }
    public class CustomDropDownListControl : PropertyDropDownListControl
    {
        // not overriding anything
    }

02. assign it to a pagetype:

        [BackingType(typeof(CustomDropDownListProperty))]
        [Display(GroupName = Global.GroupNames.SiteSettings, Name = "Custom dropdown")]
        public virtual string CustomDropdown { get; set; }

03. Check out the property in Edit mode..

PS: I have also filed an incident report for this issue.

#62715

Nov 01, 2012 14:30

Ted

Vote:

Does it work in the "legacy" edit mode?

#62724

Nov 01, 2012 15:04

Dick Scherpenzeel

Vote:

Yes.

It also worked in the Preview release in normal edit mode.

#62728

Edited, Nov 01, 2012 15:32

Ben McKernan

Vote:

The EditorHintAttribute is not inherited so you will need to add one to your custom property.

[Serializable]
[PropertyDefinitionTypePlugIn]
[EditorHint("DropDownList")]
public class CustomDropDownListProperty : PropertyDropDownList

#62733

Nov 01, 2012 17:17

Dick Scherpenzeel

Vote:

So it's not a bug, good :)

But, now a dropdownlist is created for me. So how do I access this dropdown to load items?

#62735

Nov 01, 2012 18:03

Ben McKernan

Vote:

You'll need to create a SelectionFactory to handle the logic for selecting the items, then you'll need a EditorDescriptor to associate the custom property with it. It will mean you need to have a custom EditorHint/UIHint name.

Here is a blog post from Linus which I think is pretty similar to what you are doing http://world.episerver.com/Blogs/Linus-Ekstrom/Dates/2012/9/EPiServer-7-Configuring-editors-for-your-properties/

Let us know if you get stuck :)

#62750

Nov 02, 2012 9:49

Linus Ekström

Vote:

If you just have a "regular" drop down with a custom set of values I recomend implementing this using the EPiServer 7 way instead of trying to get your legacy property working. Not much code required and you can read how to do it here:

http://world.episerver.com/Blogs/Linus-Ekstrom/Dates/2012/9/EPiServer-7-Configuring-editors-for-your-properties/

#62751

Nov 02, 2012 9:50

kayvan shaabani

Vote:

I have the same problem. I have some complex custom properties which don't render any more in Epi7. Can you please advise what is the way forward in EpiServer 7 to create custom properties based on complex objects? (possibly using mvc)

Thanks

#63898

Dec 04, 2012 14:42

Ben McKernan

Vote:

Hey Kayvan, I'm not quite sure what you're after. Are you having issues creating the custom property in the backend or are you having problems creating an editor for the front end? Linus has several blog posts regarding these topics that should hopefully help you: http://world.episerver.com/Blogs/Linus-Ekstrom/Dates/2012/

#63914

Dec 04, 2012 16:18

kayvan shaabani

Vote:

Hi Ben

I can create the propety as I did in CMS6. I normally created them as a subclass of PropertyData and then overrided the CreatePropertyControl() method to create controls for Edit, and View mode. Something like Joel's example of creating a custom property.

What I am looking for is to find out the best practices for creating custom property types in Episerver 7 to be used in PageTypes and BlockTypes. I haven't seen any example for Epi7 about how to create custom properties inheriting from PropertyData or PropertyString etc.

My current implemebtation in Epi7 works for edit mode, but for some reason doesn't work in View mode.

Here is a piece of code representing a sample PropertyControl:

public class PropertyTabControl : PropertyLongStringControl
    {
        /*
        Override CreateXXXControls to control the appearance of the property data in different rendering conditions.

        public override void CreateDefaultControls()        - Used when rendering the view mode.
        public override void CreateEditControls()           - Used when rendering the property in edit mode.
        public override void CreateOnPageEditControls()     - used when rendering the property for "On Page Edit".

        */
      
        public override void CreateDefaultControls()
        {
            var ctrl = new HtmlGenericControl { InnerHtml = "<p>some content..</p>" };
            Controls.Add(ctrl);
        }

        public override void CreateEditControls()
        {
            Controls.Add(new TextBox { Text = "some content.." });
        }

    }

#63917

Dec 04, 2012 18:17

Linus Ekström

Vote:

I wrote a blog post to summarize the diffrences for properties in EPiServer 6 and 7: http://world.episerver.com/Blogs/Linus-Ekstrom/Dates/2012/12/Changes-for-properties-between-EPiServer-6-and-7/

#63924

Dec 05, 2012 8:47

Duong Nguyen

Vote:

Kayvan, when you meant a custom property based on a complex object, was it something block can help? Having it as a block you don't have to care about editors anymore, since EPiserver will automatically scaffold.

If you still want to write your own custom property editor based on a typed model, you can use FormContainer to automatically create the input UI. Here is a quick guide: Object editing guide

#63966

Edited, Dec 05, 2012 15:56

kayvan shaabani

Vote:

Thank you Duong,

I need to clarify a bit what I mean by custom complex property. Yes, I can get the same functionality using Blocks for peoperties which are made up of simple episerver types such as xhtmlstring, String, Url, etc. But, what if I need a full flexibility of editing a property value and rendering it in the view mode. Please look at the following picture which is an snapshot of one of the complex properties I have in EpiServer 6.

http://i48.tinypic.com/f4g2vs.png

Here, I had a custom object called Tag, which has different properties and I had full flexebility of adding items to a lits, re-ordering items using drag n drop, deleting, etc. Then, I needed to take care of saving and loading the property value by overriding Save and Load methods in Property class.

But, I'm still not sure what is the best way to do complex object properties in EpiServer 7.

Thanks

#63968

Dec 05, 2012 16:29

Ben McKernan

Vote:

I would suggest a ContentArea property and a Tag block. The block would only need an XHTML property and a boolean property. Then that way you get the adding, removing, drag and drop sorting all for free from the ContentArea!

You would just have to handle the data differently on the server side (however I imagine this would be easier than what you currently have).

#63970

Dec 05, 2012 17:00

kayvan shaabani

Vote:

There are problems with that. We need to create a new instance of the Tag block every time we want to add a new tag to a page. So, we will end up with hundreds of instances of this block type (for all pages). And also, on the child pages, we need to query the blocks of type Tag on the parent page and see which one has the boolean tag selected to be cascaded and so on.

However, this is only an example of one of the complex properties we have. Others also may have properties relying on complex C# objects.

Thanks

#63971

Edited, Dec 05, 2012 17:10

kayvan shaabani

Vote:

Previously, you would be able to define your complex C# object class having any type of properties you need and then just subclass from PropertyData class and create your controls for view/edit modes. As you know you needed to override Save and Load methods of your propety and EpiServer would serialize/deserialize your complex object for persistence/loading purposes.

I know we can imlement 90% of custom properties in EpiServer 7 using blocks and we are converting most of them to blocks now. However, does this mean that we won't be able to create properties based on List of Complex objects any more in the new version?

#63972

Dec 05, 2012 17:17

Ben McKernan

Vote:

Oh wow, ok in that case a content area wouldn't work for you. You can definitely implement lists of complex objects in EPiServer 7. The main difference would be that you would need to build the UI for it with JavaScript using dojo/dijit and have a EditorDescriptor that maps that property type to the front-end control.

#63976

Dec 05, 2012 17:38

Duong Nguyen

Vote:

Kayan, I have tried to create a generic editor for "list of object"-like properties you mention. It is quite easy with the support we have had from EPiServer Object editing framework. But there is one issue which makes it not working on RTM version. I will try if I can find a nice work around, then I will write a blog post about that.

#64020

Dec 07, 2012 11:23

kayvan shaabani

Vote:

Hi Duong

Thanks for the help. But, bear in mind that Editing is not a problem in this case as you mentioned EpiServer 7 provided ways to enrich editing. The main problem I see here is Persisting and Loading custom C# objects (i.e. Person) in Episerever. I achieved this in EpiServer 6 by creating customProperty and a propertyControl and managing view and edit modes together with saving and loading my custom (complex) object.

Not sure if we need to go that way in EpiServer 7.

Thanks

Kayvan

#64021

Dec 07, 2012 11:31

Linus Ekström

Vote:

There is not much changed regarding creating custom properties to store complex values in EPiSerer 7 compared to EPiServer 6. The only difference I see is that you need to return the value type in PropertyValueType with the type that matches your typed model. There is a sample in the new Alloy Samples Templates that show how to create a custom property that has a custom value type (PropertyStringList).

Of course it's still a bit of work to get a custom property containing a list working, but we hope to be able to add support for both editing and storage soon to remove the need for partner developers to write this code.

#64023

Dec 07, 2012 11:45

kayvan shaabani

Vote:

But this example in Alloy, doesnt use PropertyControl. (CreatePropertyControl()) is written to return null. So, its using the default editor.

I tried to port one of my custom properties to EpiServer 7. However, EpiServer 7 doesn't call my customPropertyControl method called: CreateEditControls().

This is why I cannot use my custom editor.

Thanks

#64030

Dec 07, 2012 17:27

Linus Ekström

Vote:

The example in Alloy shows the following:

PropertyStringList - Custom property responsible for converting the internal string to a String[] that you can use on your model classes.

StringList - Editor descriptor responsible to assign an editor (alloy.editors.StringList) and potentially any additional values.

alloy.editors.StringList - Client side editor that is responsible to edit the item.

[Template] - There is no custom template for this type but you can check for instance ContactDetailsByPageReference to see how a template is registered.

And yes, CreateEditControls will never be called in this scenario. If you want to have the legacy edit support you can add an EditorHint attribute to your property class and the legacy editing (inside a dialog) should kick in for your type.

[EditorHint("whatever")]
public class YouPropertyClass : PropertySomething

#64033

Dec 07, 2012 18:00