What's the best way to filter/process the output of EPiServer:Property?

Vote:
 

I have some processing I need to do on the output of every EPiServer:Property control.  I need to filter the output and do some text processing on it at the moment it's requested.  What's the best way to do this?

I originally used a control adapter mapped to the "Default" browser, but ran into some odd problems not related to EPiServer.  The control adapters wouldn't run on Chrome and Safari for some reason, in my client's environment.  The whole thing made a little nervous.

Then I thought I'd attach to the LoadedPage event and alter the Value of the various properties, but this is overkill.  I don't need to alter this output when pages are loaded, just when properties are actually displayed.

I finally settled on extending the EPiServer:Property control, but this is a little more complicated than I thought.  I overrode the Render method, and wrote my filtered version of the PropertyValue into the HtmlTextWriter.  This sort of worked, but it didn't parse or execute dynamic content, and I wouldn't be surprised to find there were other systemic effects as well.

Writing to PropertyValue doesn't work either -- it's read-only.

Any input on the best way to do this?

#39604
May 25, 2010 6:11
Vote:
 

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

#39617
May 25, 2010 15:58
Vote:
 

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.

#39618
May 25, 2010 16:01
Vote:
 

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

#39619
May 25, 2010 16:04
Vote:
 

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? 

#39626
May 26, 2010 9:30
Vote:
 

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.

#39645
May 26, 2010 17:28
Vote:
 

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

#39648
May 26, 2010 20:48
Vote:
 

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.

#39649
May 27, 2010 4:00
Vote:
 

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

#39650
May 27, 2010 8:20
Vote:
 

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.

#39691
May 27, 2010 16:35