"Link name/text" for single links?

Vote:
 

When you add a link to a LinkItemCollection, you get the option to add "Link name/text" (box #1 in screenshot bellow). But when I use a property of the type Url, I cannot (box #2 in screenshot bellow). I do not want one property for the url, and another for the text, as this complicates the on page editing process.

See screenshot: https://s3-eu-west-1.amazonaws.com/uploads-eu.hipchat.com/27490/171745/g4j4s6D5DUrEX5O/linker.png

Is there away to get the second box for a single link? A single "LinkItem". Am I missing something?

#81569
Feb 19, 2014 15:44
Vote:
 

Ended up making a "LinkButtonBlock" like this. Not ideal, but it does the job.

    [ContentType(
        DisplayName = "Link Button Block",
        GUID = "31B4F4E4-3615-4242-A3E0-68E35DCDDD0B")]
    public class LinkButtonBlock : BaseBlock
    {
        [Display(
            Name = "Text",
            Description = "",
            GroupName = SystemTabNames.Content,
            Order = 110)]
        [CultureSpecific]
        public virtual string Text { get; set; }

        [Display(
            Name = "Link",
            Description = "",
            GroupName = SystemTabNames.Content,
            Order = 120)]
        [CultureSpecific]
        public virtual Url Link { get; set; }
    }

    

#81597
Feb 20, 2014 11:43
Vote:
 

Unfortunately, it's probably the best way to go right now. The link property has never had the ability to save additional parameters except for the URL. You could add a property that handles LinkItems but my hunch is that it would require some work since you need to create both a client editor (that uses the built in link dialog) as well as serializing the LinkItem.

#81609
Feb 20, 2014 12:26
Vote:
 

It's confusing and flicks do not have this problem, but it's not easy to tell ahead of time. DIRECTV Sign In Last night, I terminated up the application on my Android phone. 

#189666
Mar 22, 2018 12:59
Vote:
 

We have run into this architectureal question many times. Creating a block doesn't make sense. Imagine as an author you have to create a block for every single link you want to add to the Content Area.

We ended up using Property List that allows it to be more configurable and the authors can edit all links in one place. Refer to the explaination from Per here:

https://world.episerver.com/blogs/Per-Magne-Skuseth/Dates/2015/11/trying-out-propertylistt/

The only catch here is it is not very on Page editor friendly but it's a tradeoff that I am fine living with.

 [ContentType(DisplayName = "Career CTA Grid Block", GUID = "f0548176-65bb-4176-a34d-9cae5ea6aef0", Description = "Career CTA 3 Column Grid block")]
    public class CareerCTAGridBlock : SiteBlockData
    {
        [Display(
            Name = "Careers CTA Grid",
            Description = "Careers CTA Grid",
            GroupName = SystemTabNames.Content,
            Order = 200)]
        [EditorDescriptor(EditorDescriptorType = typeof(CollectionEditorDescriptor<CareersCTA>))]
        public virtual IList<CareersCTA> CareersCTAItems { get; set; }
    }

    public class CareersCTA
    {
        [UIHint(UIHint.Image)]
        public ContentReference Image { get; set; }
        
        [Display(Name = "Title")]
        [Required]
        [UIHint(UIHint.LongString)]
        public string Title { get; set; }

        [UIHint(UIHint.Textarea)]
        [Display(Name = "Teaser Text")]
        public string Teaser { get; set; }

        [Display(Name = "CTA Link Text")]
        public string CTALinkText { get; set; }

        [Display(Name = "CTA Link")]
        [Required]
        public Url CTALink { get; set; }

    }

    [PropertyDefinitionTypePlugIn]
    public class CareersCTAProperty : PropertyList<CareersCTA>
    {
        protected override CareersCTA ParseItem(string value)
        {
            return JsonConvert.DeserializeObject<CareersCTA>(value);
        }
        public override PropertyData ParseToObject(string value)
        {
            ParseToSelf(value);
            return this;
        }
    }
#189676
Edited, Mar 22, 2018 21:44
Vote:
 

Creating a block doesn't make sense

I guess Torjus solved it by a local block so need for a ContentArea.

#189677
Mar 22, 2018 23:18
Vote:
 

No need*? :) 

Local blocks in my experience is a bit confusing, feels like you're mixing two concepts. I'd use local blocks just Torjus does, simply grouping content properties for re use on different content types. But seeing as you can add block controllers and ultimately use this block in a contentarea, making it IContent, simply to me seems as a risk as the two ways of working with blocks are so different.

#189693
Mar 23, 2018 7:16
Vote:
 

I agree the best use case for local blocks is grouping properties.

In this case having a better A-element editor that was shared between TinyMCE and the link property type would be the best fit I think. Follow the HTML5 spec and be sure not to miss adding a REL-attribute field.

#189711
Mar 23, 2018 9:11