Jun 24 2006
I did quite a lot of work yesterday, implementing the following elements: Title, Paragraphs, Frames. One feature I like in the control is that you can write big chunks of texts without having to care about formatting the text: the control will automatically insert <br /> and <div> elements to separate the text in smaller chunks. All you have to do is insert one carriage return, or two carriage returns. That will speed up text input.
By the way, what I used to call V1 will actually be V0.1. This first version will be too basic to be released, and I will only use it on my PhotoAlbum as a proof of concept. I'll make an effort to talk about V0.1 from now on.
Today I thought about how to demo the control. Since V0.1 won't allow the user to enter text in a webpage, but only render data entered in XML files directly, the demo will probably be pretty static. I am thinking of a page with a Tabbed control, one tab being the XML file and the other being the rendered HTML. That will underline one of the biggest advantages of the RealSimpleBlog control towards existing systems: since it's a custom control, you can integrate it in your own homepage, using your own design and placing it inside your own HTML elements.
I also thought about CSS customization by the user. The problem is as follows: The control has a CSS file embedded, with a default look&feel. The CSS file is extracted the first time the control is rendered. The CSS file is also versioned (if a new version of the control is made, the CSS will also receive a new version number for consistency).
If the user wants to change the look&feel, for the moment, the only way is to modify the extracted CSS file manually. However, when a newer version of the control is installed, thus a newer version of the CSS file, then the newer file must be manually modified again, which is not acceptable.
To change that, I thought of different possibilities:
Let the user specify a CSS prefix, which will be added in the control in front
of each class name (for example: gslbDivParagraph become myPrefixgslbDivParagraph).
The user is then responsible for specifying the corresponding CSS classes.
I used that solution already in other controls, but I find it cumbersome.
Let the user specify "style" properties for each element rendered by the custom control.
Since style has priority over classes, this allows the user to overwrite some or all
of the predefined CSS attributes.
It's a nice way of using the "cascading" in CSS, and allows great flexibility (some attributes can be left to default, other can be overwritten). However, it also means quite a lot of properties to set in the custom control.
Same as above, but instead of using properties of the custom control, use a
XML configuration block instead (for example, add a section in the Web.config,
or as a child node of the control itself).
Not a bad idea, but once again a bit cumbersome.
- Finally, I think I had the idea: Let the user specify a user-defined CSS file for the control. This user-defined CSS file can "complete" the default, embedded CSS file. For each class present in the default CSS file, the user can specify attributes which will be cascaded ("added") or which will replace the default attributes. If the user specifies that the user-defined CSS file must be used instead of the embedded file, then the default CSS attributes are simply not used at all.
Anyway, this won't be implemented in V0.1, so it will be food for thoughts during my holidays!