Ok. Since the universe is in a giving mood, and answers are coming out of the sky...here's another one that I would love to get an answer for.
AnteScriptum: the opposite of PostScriptum?
Even if you're not an ASP.NET guy (Kirk :-) ) maybe after reading this you might know of the right person to forward the moan onto...
Preamble
Creating ASP.NET server controls is mostly ok stuff. Its not as clean an architecture as WinForms (cough! by a long shot!) but I can wrap my mind around most of it. I like playing around with adding Callback capabilities, ClientSide scripting, and trying to make it Templateable so that others can lay it the crucial pieces out any other way they see fit.
In fact, I've spent quite a lot of time trying to hone the steps down so that the time to make a compiled server control assembly is not horribly more than simply making a ascx file.
But I've never been satisfied with them. It's really the layout part that lets me down. Let me explain.
Tables, CSS, and ...the IDE
Consider a control that is a form of some kind, with 3 labels, one for each of a combo, a text input , and finally a TextBox. ie, Maybe a simple Comments form with an expandable rich text area, hopefully that will resize with the page so that it doesn't cramp the commenter to write long essays in a tiny box...
In my PHP days, when IE was king, I would have done all that in some kind of popup window, filled with a table that was full width/height, and made the TextBox width='100%' height='100%', so that it filled the whole (2,3) cell...
Ah...then table-less layouts came out... But IE still was king supremo at 98% of market...and at first you could safely ignore whatever those Germans and their 2% of the market were doing :-)
And then ASP.NET came out...just as those Germans became west-coast as well, and Peru and Russia and china,..and well...much more percentage...so even I was converted slowly to table-less layouts (well..for the most part).
Only to find that...yikes...via Reflector...MS's controls were using....table layouts!
Ok. Hum.
Hell ever since
So this is where I got...stumped, and have never found a GOOD answer...
You can see others noticing the problem (surprisingly few!!!) such as here.
The problem with designing server control's layouts is ...in several parts...
a) it is just a control...and has no idea of the page's level of compliance. Contrary to designing WinForm controls, a WebForm control...is a control that could totally change appearance depending on the html mode the page is in. And can cause havoc. If you want a child control to be 100% high to fill cell [2,3] it will work in older modes, but collapse to 0 height in XHTML pages because the cell has no position:relative on it...
so...
"So? what's the big deal? Put 'position:relative' on the cell containing the control you want to % size..."
If it were my ascx control, sure...do what I want.
But if someone else is going to drag/drop this control on their page, the control should be clean as much as possible...and they can apply what they want to the control...
Eg. If they want to mark cell [2,3] with a class that has position:absolute, it would not work as they intended if I've applied directly a position:absolute inline, which would always take precedence...
"So? Just remove all styling from the control!"
Yes...that's just about where it brings me back to...controls with absolute no styling applied. None.
Clean as a whistle for an end-programmer to start adding their class def's to...
The only thing I should have in the control is....have them positioned...
"Great! We're done?"
Not really...because here I was trying to get away from tables...but without CSS being applied in any way, the only positioning tool I have at my disposal is....a table.
If I create a composite control that had only 3 labels and 3 child controls, the first time they place the control on the page, with CSS controlling the layout, they would go 'yikes! What is this ugly mess?!' as they look at a whole string of labels jammed up in the upper left side, and some controls flowing weirdly after it...
"Never going to use that mish-mash!"
How many people read instructions/help docs before using something? Nobody...so sales of whatever xxx control designed without tables?...zero.
"Ok...so use tables"
It's what I'm doing...and I hate it. I really really really hate it.
"Or don't..."
Offer a "SkinType" to the control such as "Corporate" "Funky" and apply styling directly, inline.
For "Custom" they're on their own, sorting out the layout....
Yes...that sounds like just about the cleanest way to go. Far more work, grumble..but clean....
Except one more problem: The control doesn't know what mode the page is in, and just about any CSS I apply will fail in some circumstances...
And ...in (hopefully) a very cases it will actually fail completely because old browsers will have no idea how to work with out a table.
"So use tables!"
Agh! (Screaming as I go looking for a cliff to jump off from...)
I go through this dialog every single time I design a control. And I'm sick of it. I wish I had a definite path to follow that works, and is future proof.
So ...anyone (of if you think you know someone who might know the answer to the above conundrum, please point them at this blog bleat for help... I would be so grateful...)
And even if you're wrong, I don't care, I just would love to hear what others think about the issue, whether I'm making a mountain out of a molehill, whether they think they've read something that might have answers, whether they have the direct home phone number for Scott Guthrie so I can call him and ask him directly, ...anything...
thank you. In advance.
[LATER EDIT]
I didn't mention...Control Adapters and there's a reason. a) I forgot about them for a second. b) even if I hadn't:
...the development cost!
Making Server controls is an expensive process in general, with all the compiling time needed, unit testing being virtually impossible, writing templates, etc.... To Add yet another layer of work ...sort of takes it over the top. I may be wrong about that (I'm open to feedback).
But what I never clicked for me was the basic fact that it just...about...sinks any pretense of composite WebControls...
...Contrary to RAD direction of WebControls/CompositeControls
The whole point of composite controls was to approach the RAD capabilities of WinForms...to abstract away and hide the underlying html in favor of an IDE.
To then turn around and make an adapter that ignores all the child controls, and writes directly to the outgoing stream is..... I don't know what to call it.
If its the case, one should never be designing composite controls, and everything should be derived from as close to bare-metal as possible, and implement IPostBackHandlers and IPostBackEventHandlers manually in all cases.
Its....depressing.
It just seems to be an extremely tortuous route to go nowhere: in the time it takes someone to make a server control, its designer, its templates, its default appearance types (see above), and now control adapters just to bring it back into compliance...someone has build 3 websites in PHP. Heck. 10 websites!
So you can sort of see why I was trying to make server controls, while doing them faster and cheaper, in order to get back to actually producing websites...