Hello:

Feeling a bit like Winnie the Pooh here, and need the Brains of Rabbit... :-)

I'm struggling around trying to get the best of two worlds...

Styles...
Ok. If you have a composite control, or a data bound repeater control that has several Style objects, the way to decrease the load on the ViewState sent is a) override the Load and Save viewstate, build the controls in CreateChildControls like always -- but hold off to Styling all the Cells that have identical decoration till during Render. That way only one or two style objects (base.ControlStyle , CellTextStyle, CellImageStyle) are saved rather than [n] cells of it...

versus Templates...
Ok. Here, the idea is that you don't offer Styles, but offer Templates -- fair enough. Except one thing is that the DataBinding() happens before Render -- so (I may be wrong here) it appears to me that in the case of a Table with 3 rows x 3 cells, each one with a Template layout (something like the Calendar Control) we are ViewStating 9 Style objects...
Is this correct?


The reason I ask all this, is obviously Templates offer more flexibility to a webdesigner, in many ways, but Styles appear to be a lot cheaper on the ViewState...

I've even played around with mixing the two -- where I offer a couple of Style objects (eg: called CellTextStyle and CellImageStyle), and then the template refers to it via DataItem.Parent.CellStyle... Of course, that's not what I want because it styles it before Render (loads the viewstate)...and I can only defer and apply it after Render() IF it the template is the generic builtin Template (the structure of which I know hence can style), but won't work if the user creates a custom template -- as now I don't know what/how to style within it... (Did anybody understand that convoluted path??? Sorry!)


Anyway -- my two huge questions are -- does anybody have a way of offering Templates -- yet somehow binding the DATA in the template before the Render, but somehow leaving the application of its style info till later? Or any idea to decrease the size of ViewState.
Or can it work by simply making EnableViewState of the TemplateContainer=false? What side effects would this have? Would it fall apart in the case of a DataBound control since when it repopulates its children, it would have the TemplateContainers...but no longer its contents?

The second question is ...has anybody successfully mixed and matched Style based control and Template controls? I know they are generally thought of as one OR the other -- just was wondering if anybody have done an AND, and liked what they saw -- or did try it and found it a waste of time...

Any thoughts on all this is greatly appreciated...!

Thank you,
Sky

You can always force them to marriage :-) . Just analyze the DataGrid (or GridView) controls to see how they managed it. In my opinion (a short and sweet one!), templates should be used to template the output whilst styles should determine the style of the output (also including the styles orientates templates).

It is not a good method of forcing structure into templates. Templates should be independent of structure and format -- it can be very easy to get a loosely coupled structure wrong because we are all humans :-) .

And oh -- templates should be the last thing to enter into viewstate. Template's "state" should not change from post back to post back so it will be completely useless to place that into state.

---

-- Justin Lovell

Hi Master =:-):

So so glad you answered!

First, I wil look at the DataGrid to see what they do - probably via a look at the Mono code.

Secondly, I am not sure what you are implying by your last statement -- but I am intrigued. Could you expand on this part?
I agree that it would be great to ensure templates dont pack up the ViewState, but if one set EnableViewState=False on a templateContainer, it will work for all non data-bound countrols. It will work the first time, but when the CreateChildControls() comes around again, and recreats the rows...they would contain no styling, great, but also no Text value either, bummer... Could you expand on what you meant on this part some more?




In the meantime, until you get back to me on the above, I'm going to pick at this scab one more time...

BTW: I do understand the concept of using Templates for structure, and Styel for styling... Just that in real life, I find the lines a bit blurred ...

For example, taking the "superduper calendar" (Day/Month/Quarter/Year) that I've been toiling on for a while... It's the Year view that gets me to sweat as it we are talking about 12 months * 31+ cells... which if handled stupidly will load up the ViewState monstrously...

Design principle I "Keep the Styling to the very last moment to not load up the viewstate":
In this case, for the year view, I would lay out 12 month tables of 31+ cells in CreateChildControls, override the LoadViewState, and SaveViewState that manages a set of Style objects, and apply Styling in the Render event.
This means we are saving about 4-5 Style objects in ViewState, and the Table Cells are each saving in ViewState the mininum load possible (which is only their Text value i guess)...

Design principle II: Allow modification by user...
Here we can think about offering templates. It's not costly to create a template container, and a default template.
But it is specifically this is the part that makes me realize that I am missing something: I CAN Style at the end if we are talking about applying one Style to the whole Template container-- eg: DayCellStyle.
But if we get more tricking and are talking about multi-styling bits and pieces within it (eg: DayCellNumberStyle, DayCellSubjectStyle, DayCellBarchartStyle) then we can only apply them if we know what the user is putting into the template -- which is only the case if the user is using the default template whose structure we know -- which defeats the purpose of offering templates.

In other words, offering both is possible - but only on very simplistic layouts.

Design theory III: Event driven rendering
There is an alternate approach that I have seen -- which is demonstrated by the ASP:Calendar control -- which I assume is late-styled, but offers no templates -- but gets around this by offering a DayRendering event (sorry if I got the exact names wrong, but you get the point).... As long as the user hooks into the names of the Styles offered, then all works...But he is loading up the ViewState since this hooking up/overriding is happening Before SaveViewState.


Design theory IV: Lunatics in control...
The next option I am considering is to NOT use the recommended solution of keeping ViewState on in the table cells, but actually work on ViewStating the DataSource... I don't mean the whole 10000 records, but only the same visible columns/data that the html would have viewstated)... This would allow a marriage of late styling, templating, and databinding.
But...as you can see...It means I am totally disregarding most of MS's work, and taking on the burden myself... and once again I am trying to rewrite the way 'things are done', and that usually (unfortunatly!) is so often a dumb direction...Hence my cry out for guidance before I go too far off into the woods and loose myself...



AGRRR! I swear I feel like I am caught in between the mariage of two design principles designed by two different people at microsoft....somethin' just ain't 'smmooooth' about it all.
(I am also thinking too much rather than just gettin' on with coding!!! :-) ).



Very best,
Sky