Hello,

I can successfully use CSSFriendly adapters for stock controls, but if I want to add custom html to my control, following the usual "Convert To Template" approach results in the standard table output in my source. Obviously the div'd results I see on a rendered page are generated by ASP.NET, but is there a way to use converted templates with CSSFriendly adapters, or do I have to resort to tables (or hand-cut divs) for customized controls?

Which control are you trying to use? Several of the adapters in the kit allow you to use templates. Convert-to-template will not produce the adapted HTML in the new template instances. However, as I said, you can use templates of your own creation in several of the adapted controls.

Russ Helfand:

Which control are you trying to use? Several of the adapters in the kit allow you to use templates. Convert-to-template will not produce the adapted HTML in the new template instances. However, as I said, you can use templates of your own creation in several of the adapted controls.

Hi Russ,

The control I was using was the Login control. I may not be using it correctly but I can see the properly div'd source when viewed as a rendered page, but converting to a template creates a LayoutTemplate with tables. When you say "Convert-to-template will not produce the adapted HTML in the new template instances", do you mean that I will see table tags in the markup, but the code itself will render as divs as per stock controls? I think I was hoping to see the same sort of div-based markup at design-time so I could easily style with CSS and see the results in the designer for controls using my customized template.

Daniel

Hi Daniel,

Now I understand your uber-goal better. Frankly, I've not spent much time trying to get the adapters to play with the design surface in VS. So you are on uncharted ground!!! That's always fun.

Personally, I suspect that the union of the adapters and the design surface is going to be problematic. I think that the design surface uses the various IDesign* interfaces provided by the control to determine behavior of the control in the surface. The adapters make no attempt to modify those interfaces in the control. In fact, I don't know that the apadpter architecture even provides a hook to do that sort of design-related modification to the control. So I'm not sure whether or not it is possible. I can tell you for sure, though, that the adapters in the kit do not have any code that was specifically written to accomodate the design surface interfaces in the API.

You might be able to "trick" the design surface into showing the right stuff by using templates but I suspect you don't really want to do that because then you've sort of short-circuited the adapters' native ability to generate the HTML on-the-fly. When you convert-to-template you effectively freeze-in-time the HTML being rendered for that control. If you improve the control in the future you won't see those improvements since you're no longer generating the HTML for that control on-the-fly. So, frankly, I use templates somewhat sparingly for things like Menus or Trees because I feel as though they should always render heuristically as simple nested unordered lists (UL tags). But that's just my perspective.

Good luck working out the kinks in the design surface as it relates to the adapters. I've be really interested to read about your experience in that regard, if you decide to pursue your investigation.

Hi Russ,

I share your sentiment about Menus and Trees, and it's only with the LoginControl and SignUp control that I see the need to leverage the dynamic HTML generated by the adapter in addition to adding customized template-based elements, otherwise designs using these controls are relegated to displaying custom elements, even if they are only additional imagery or text for marketing messages and the like, outside of the control itself. It's an interesting challenge and it's not trivial, but if I do take this on I'll be sure to share the experience.