Rendering parameters are stored in Sitecore as a query string eg:
param1=value1¶m2=value2 etc....
And this query string is stored as an attribute on an XML node in the __Renderings
or __Final Renderings
field on the context item, like this:
<r uid="{91C058E4-4307-4391-98B2-A7629FF9C729}"
p:before="r[@uid='{6717EAA7-0931-46D9-8E89-21678756C012}']"
s:id="{2152C804-3AD4-44B4-BC3E-9215018C8B17}"
s:par="Advert Placement=%7B6F568FE1-FBD3-4685-B133-4EFACC0192FE%7D"
s:ph="main" />
Because of this, it makes it not a good place for fields like a Rich Text field. It really should be limited to simple fields/links etc...
It is not a good idea to store page or module content in those fields either. You will not be able to reuse the content anywhere else. It would only be available to that one component. Also if you removed the component, the content would get removed also.
You can already edit the rendering parameters via the Edit Component Properties
dialog - so your fall back is in place.
To be able to edit the parameters in line, you would have to add elements to your markup when PageMode.IsExperienceEditor
is true.
You would then also need to hook into the save button in the Experience Editor and use the values in your custom fields to build a query string and store that in the __Final Renderings
field of the current context item against the correct component XML node.
From a content editors POV, I would say it makes more sense keeping the rendering parameters on the component properties dialog and not using many at all. For me, rendering parameters should only be used to define unique presentation variants for the component being added to the page and not have anything to do with the content being rendered.