Hi Dean!

As you say, control adapters would probably be the natural place to do this. Other from that I see two options. If you just need to tweek some properties you can remap some properties to use you custom property controls that inherit from the default property controls. This can be done in a class called PropertyClassFactory. Then you can probably override some method and change the behaviour.

If you need to change the markup from every single property then perhaps you can create an overload of the Property.Render method, create your own string writer and call base.Render, tweek the string and then rewrite the string to the normal stream. I have no idea how this would work in reality and how this will affect performance, just giving you some hints if your stuck :)

Happy hacking!
Linus Ekström
EPiServer Development Team

You can use the method PropertyControlClassFactory.Instance.RegisterClass to register a replacement control for the property type you want to change the behaviour of (sort of like a control adapter). Just create a property control like you would for a custom property type by inheriting the control you want to change the behaviour of. Override the CreateDefaultControls method to return a different rendering control in which you can do your processing. Make your call to RegisterClass in Application_Start in global.asax.

This is of course on a per-property type basis so I don't know if it will work for you or if it will be any better than a control adapter.

Guys:

Thanks for your input.

However, forgive my ignorance here, but once I extend from the Property control, how do I affect its rendering?  Like I mentioned in the original post, I extended from it once before, but I need a way to attach to the VERY end of its lifecycle, after its corrected all its internal links and processed Dynamic Content.

There's no "Text" or "InnerHtml" property I can grab and process -- that would be the simplest way, if I could just grab the text from some property in PreRender, process it, and write it back.  However, this doesn't seem to be possible.

Instead, I needed to override the Render method, and, like I mentioned, I had problems getting it to process Dynamic Controls that way.

Deane

Perhaps this thread can help you work around the Dynamic Content problem.

Do you mind describing more in detail what you want to do with the property content and why? 

We have some template-ish code in the HTML.  Our client has some very specific/odd requirements, and we're actually processing XHTML properties as templates at run time -- they're using the Spark View Engine to add template tags which execute when we render the property.  (There's a blog post coming on this.... :-)

Consequently, I need to grab the finished XHTML (post link-fixing and dynamic content rendering) from the property, run a method on it, then write it back.  As near as I can tell, this is not possible by extending the control.

Hi

Take a look at these posts:

http://labs.episerver.com/en/Blogs/Anders-Hattestad/Dates/2009/4/New-module-HattisPropertyAdapters/

http://labs.episerver.com/en/Blogs/Anders-Hattestad/Dates/2009/4/PropertyAdapters-updated/

http://labs.episerver.com/en/Blogs/Anders-Hattestad/Dates/2008/11/ltEPiServerProperty-on-steroidsgt/

http://world.episerver.com/Templates/Forum/Pages/Thread.aspx?epslanguage=en&id=27947

Thanks for this, Anders.  They look great, but they won't solve my problem.  Here's why --

Originally, I was doing the template execution in a Control Adapter, and it was working great.  But then we tested in Chrome and Safari, and the Control Adapter didn't execute.  We've tested it, and in my client's environment, Control Adapters do not execute for Chrome and Safari, no matter how they're mapped -- to the "Default" browser or to "safari1plus" (which both browser identify as).

I do not know why this is.  I have a question open at Stack Overflow, but no one there seems to know either.  I've debugged this for days now, and I can't find ANY reason why this wouldn't work.  I even went so far to copy all new .browser files from the Framework directory on a server that does work.  Still no luck.  And we're getting closer to launch here, so I need to either get it fixed or find some workaround.

So, my idea of extending the EPiServer:Property control was an attempt to workaround my Control Adapter problem.  And while your Property Adapters look great, they still use the Control Adapter architecture which is not working for me.  If Control Adapters worked, I wouldn't have the problem in the first place.

Thank you anyway.  I'll no-doubt use these in other projects, but for this one, it's not an option right now.

Deane

Anders, Magnus, Linus -- we managed to resolve the underlying Control Adapter problem, which has fixed our original issue.  Thanks so much for your help on this.

Was it configuration?(the control adaptor)

If it still is there I was thinking you could replace EPiServer:Property with your own like Itera:Property.
Since it inherit from EPiServer:Property you could do this on the markup file without recompling (I think)

Good to hear that you got it fixed

Anders

You're really going to love this.

We finally found some code way down in a buried class that looked like this:

if (Request.UserAgent.IndexOf("AppleWebKit") > 0)
{
     Request.Browser.Adapters.Clear();
}

Frankly, we hadn't been looking for something this obvious.  SVN "blame" told us who added the code (it's a big company, with a lot of developers).  We found that developer, and this was his response.

I found this code on Internet and it seems to be fixing issues with menu control.

Which leads me to this:

http://dontworrysir.ytmnd.com/

Sorry, everyone, for all the trouble.