Instantiate Accordion content

Hi,

I have an accordion with some panes that have custom controls in their content templates.

The accordion is NOT databound ... the contents are static, though viewstate is helping keep track of the values in the custom controls.

When the page is created for the very first time, NOT postback, the accordion panes do not instantiate the user controls until sometime during the OnPreRender stage in the lifecycle.

On subsequent postbacks however, the accordion panes do instantiate their controls during the LoadState stage, due to their presence in ViewState.

How can I make the accordion panes instantiate their content templates earlier than OnPreRender when the page is created for the first time?

The accordion pane's content templates are not dynamic. They are coded into the page markup.

I have tried calling something like Accordion.Panes[0].Content.InstantiateIn(Accordion.Panes[0]) and various combinations at various stages, but I usually ended up just getting duplicate versions of the controls in the wrong places in the page!

I could not find any "EnsureControls()" methods available in the accordion.

Many thanks in advance for your helpful suggestions,

Ben

Hi,
Accordion.Panes[0].FindControl('nothing') will make pane 0 to instantiate its templates. FindControl is an indirect way to call EnsureChildControls.

-yuriy
http://couldbedone.blogspot.com

Yuriy! Thank you so much! I'm relieved!

Is anybody testing these controls to be valid HTML?

I am using the accordion pane control and the output rendered out is falling over on validation. There is block level elements being created inside of inline elements which is against the spec. What is the reason for doing this as apposed to using a div but still have well formed HTML?

1<div id="ctl00_SampleContent_MyAccordion">
2 <input type="hidden" name="ctl00$SampleContent$MyAccordion_AccordionExtender_ClientState" id="ctl00_SampleContent_MyAccordion_AccordionExtender_ClientState" value="0" />
3 <span id="ctl00_SampleContent_AccordionPane1">
4 <div>
5 <div class="accordionHeader">
6 <a href="http://links.10026.com/?link=" onclick="return false;" class="accordionLink">1. Accordion</a>
7 </div>
8 </div>
9 <div>
10 <div class="accordionContent">
11 The Accordion is a web control that allows you to provide multiple panes and display them one at a time.
12 It is like having several <a href="../CollapsiblePanel/CollapsiblePanel.aspx">CollapsiblePanels</a>
13
14 where only one can be expanded at a time. The Accordion is implemented as a web control that contains
15 AccordionPane web controls. Each AccordionPane control has a template for its Header and its Content.
16 We keep track of the selected pane so it stays visible across postbacks.
17 </div>
18 </div>
19 </span>
20</div>

The above code should out output like

1 <div id="ctl00_SampleContent_MyAccordion">2 <input type="hidden" name="ctl00$SampleContent$MyAccordion_AccordionExtender_ClientState" id="ctl00_SampleContent_MyAccordion_AccordionExtender_ClientState" value="0" />3 <div id="ctl00_SampleContent_AccordionPane1">4 <div>5 <div class="accordionHeader">6 <a href="http://links.10026.com/?link=" onclick="return false;" class="accordionLink">1. Accordion</a>7 </div>8 </div>9 <div>10 <div class="accordionContent">11 The Accordion is a web control that allows you to provide multiple panes and display them one at a time.12 It is like having several <a href="../CollapsiblePanel/CollapsiblePanel.aspx">CollapsiblePanels</a>1314 where only one can be expanded at a time. The Accordion is implemented as a web control that contains15 AccordionPane web controls. Each AccordionPane control has a template for its Header and its Content.16 We keep track of the selected pane so it stays visible across postbacks.17 </div>18 </div>19 </div>20 </div>

With a complete lack of spans.Is it actually creating a problem for you?

Jonathan Allen:

Is it actually creating a problem for you?

It is not valid HTML. It is that cut and dry. To me not passing validation is the same to me as if the control had another bug and failed to work at all. The only difference between it and other bugs is that browsers have become too lax with what they should consider valid and renderable code.

I see your point but it is not a critical factor and I wouldn't classify it as a bug or anything unless it does strange stuff which I don't believe it is. At least I haven't had any troubles with it. I'd rather get something working correctly than worry about whether it follows some ideaology and then think about minor things as validity. You know, the source code is available so you are welcomed to edit it yourself until you are satisfied or you could submit an issue about it. I don't see anything happening here as it isn't the correct place.

Well it really is a shame that browsers are so lenient on incorrectly written code, and thats what it is plain and simple. Just because a browser does not fall over on it it does not mean the code is correct. Do you let other bugs just go in your logic layer just because a browser doesn't fall over on them even though it gives back an incorrect result? What if i said that 1+1=5 and I can justify that by saying that my browser still runs if I feed it some data like that?

I need to look into the code as there is some other things that the accordion pane is falling over on for me too when it comes to rendering content in the content area.

You are being silly. For all practial purposes, valid HTML is that which is accepted by the browsers that you are targeting. The spec doesn't really mean a whole lot to app developers, as no browser actually implements it 100%. Obsessing over it just wastes time.

I agree with Custa, Its adherence to standards will only improve the toolkit.

If the accordian control is outputting incorrectly formatted HTML, it should be flagged as a bug. It seems that, there are many problems with the accordion control, the causes of which are not all known. Ignoring html that fails validation seems pretty backwards to me.

But then I guess thats the difference between professionals and amateurs. Sure, if you are designing a online shopping list for your grandma, then who cares... I take pride in my work, and if I am to put my name next to any system, and proudly say that I engineered it, I would not knowingly ignore a potential problem.

-Steve

Jonathan Allen:

You are being silly. For all practial purposes, valid HTML is that which is accepted by the browsers that you are targeting. The spec doesn't really mean a whole lot to app developers, as no browser actually implements it 100%. Obsessing over it just wastes time.

That really is a poor attitude and probably the reason why I cringe whenever I'd look at somebody like your code. If you are an "app developer" maybe you should stay off the web platform and leave it to the people earning a real living in it. Those that car about having correct code. I am guessing as you claim to be an "app developer" than you probably target only IE as a platform too. Very sad.

Note this issue has been addressed and will be included in our next release (hopefully done by next week).

Open discussion and sharing different points of view are definitely some of the main purposes for the forums but please let's all make sure it's done in a respectful and professional way.

We are tracking this and will be making sure that our sample web site pages and in turn the toolkit controls are xhtml compliant.

http://www.codeplex.com/AtlasControlToolkit/WorkItem/View.aspx?WorkItemId=8156

Thanx sburke. Good to see those that are putting the controls together do care. I know there was a rush to get them out but I am glad you are taking the time to go back and get them spot on.

Thanx for that. I guess everybody keeps harping about XHTML and thats what I do target but even targeting HTML it was still an issue of having block elements inside of inline ones.

I am not sure if you have seen my other post in relation to the accordion pane. I am having issues with having content inside them that extend outside of the pane with overflow: hidden; causing my flyout menus to be cut off. Is this something that you think could be fixed at all?

Cool, this has been bugging me as well.

Those that don't care about standard's compliance immeidately identifythemselves as Visual Basic developers creating intranet apps againstInternet Explorer :)

I'm PARTIALLY kidding but seriouslyguys, standards compliance is important and makes the web as a wholebetter. The more technologies that adhere to this concept thebetter, and the better and easier coding for the web, buildingbrowsers, etc. will be.

FYI, this has been fixed in the Development branch and will be included with the next Toolkit release.

I completely agree with this strong push for standards compliance. I don't care if I'm developing an IE-only intranet application, I want it to be standards compliant. Ask all the IE6-only app developers how they felt once IE7 was released and they had to rewrite all their code that was suddenly revealed to be broken.

Is it a problem for Accordion Contents to Dynamically Change upon postbacks

I want to ensure that what I am trying to do is possible with an accordion control. I want to dynamically change the contents of panels during the life of a page in response to a postbacks. Do all of the controls have to exist upon initial creation in the page load? I am getting view state errors from time to time and don't know the cause. I have tried creating a large number of controls initially and then just making visible the ones that I want to display and making invisible the ones I want to stop displaying upon the postback. I also move the objects around within the html and within htmltables. Should what I am describing here work?

Follow-up to my own post: I've concluded that it is NOT OK to move the dynamically created controls around on an accordian panel during a postback. So what I am doing as a solution is to create all possible controls needed in advance and then making the ones needed be visible=true and not needed be visible=false. This seems to work from initial testing. Feel free to comment on this, thanks, but this is probably resolved.