Possible to add to built-in Types?

Topics: Feature requests, Troubleshooting, Visual editor
Sep 16, 2011 at 8:15 AM

Two questions:

  1. Is it possible to add-on to the built-in C1 Image type? 
  2. Is there someway to implement the URL Link Widget as seen when you're adding a hyperlink in a C1 page?


I'm pretty sure the answer to #1 is no for now, but here's why I think it may be a good idea:

Many images end up being links, banner ads or calls to action which are "attached" the to image. Yes, one can create a LinkImage data type which has a link field and I have done so, but it seems so much more elegant to allow for an optional link field in the C1 Image. In addition, you have ONE location where the banner is stored... and not a place for the C1 Image and a place for the LinkImage  

Currently, the steps are:

  1. Upload Image to Media Gallery
  2. Go into Data Items (or Website Items if you've shown the Data Type there)
  3. Create new LinkImage
  4. Choose correct image from Media gallery
  5. Type in Hyperlink to a String field
  6. Publish

A few negatives...

  1. You can't just Add the LinkImage into the WYSIWYG editor. 
  2. You have to create a function to display a link image and add a function. 
  3. Functions don't show up in Content Tab as images (you don't know what the image looks like until you preview)

I'd love to be able to have an href on an image and have Composite render an image surrounded by an anchor in the Editor if you have entered something in your [optional] hyperlink field (either in ~/Page({GUID}) or http://link.to.external.page.com) that you can use to render anchors around your image.

It would work beautifully integrated into the Nivo Slider, for example... while Composite's default package implementation only currently only supports as images.

#2 is something that I'd LOVE to know how to do. Right now, my LinkImage datatype requires two fields, one for external links (String[512]) and one for internal links (C1 Page). If the user specifies both, I take the internal link by default. However, I the BEST way to do this would be to have a String field that had the ability to choose an internal link or paste in a hard-coded one, the same way the Insert HyperLink button works on the editor. I couldn't find this widget, but I'd LOVE to be able to use it. Any ideas?

Thanks as always...

Sep 19, 2011 at 12:34 PM

On #1, this is a no, sorry. And we are not working on enabling 'custom fields' on existing elements like media this at the moment.

You could write your own upload UI and then expose the uploaded media via a Media Provider. This is a bunch of code, workflows, forms, but the core elements can be copied from the existing Media Elements Provider (UI) and Media Provider (data).

You could also 'attach commands' to media elements, so the user would upload a file, and then execute an attached command on this file, invoking your custom form directly.

On #2 I'll see if Taras can come with some pointers here. Here is my take: Viewing the 'set link' dialog in the visual editor it looks like the following markup is sent to the client

    <ui:datainputdialog id="id_href" type="url" handle="Composite.Management.LinkableSelectorDialog" name="href" required="true"/>

(imagine this an an <input name="href" /> tag - the client javaScript sprinkle magic on the <ui:... /> tag and make it into what you see on screen).

You might be able to take this tag and have it emitted via a custom Form Control.

Sep 19, 2011 at 9:27 PM

#2  sounds interesting and I think it would be a really welcome widget addition to the Composite control tree. The ability to choose a C1 Page works in most cases, however this quickly breaks down when it comes to easily allowing the user to do things like link to a Blog Post, which adds PathInfo to the end of the URL. In short, it would need to return either to be truly useful. Otherwise, you're stuck needing two fields, one for hard-coded URLs and one for Internal Site Page Links. This can easily confuse the user.

  1. /blog/2011/01/01/some-blog-post-title
  2. ~/Page([PAGE_GUID_HERE])

Thanks for the direction mawtex, I'll give that a go and report my findings here.

Sep 19, 2011 at 9:32 PM

... which is why you should make sure to keep things page-based and not item-based for everything you need to be able to make editors link to.