AjaxToolKit: Dynamic Service Path / CalendarExtendar
Rant:
Even though I have blogged and Shawn Burke acknowledged and stated this issue would be resolved with the official release of the Toolkit - the ToolKit is still referencing FilePath instead of RawUrl. Again as previously blogged, and posted on Asp.Net Forums - it wrecks havoc for those of us whom use custom IHTTP Handlers and dynamically generate URLs as resources being requested may not be found. Secondly, it is simply the wrong syntax to be using. This is a rant mainly because each time a new version comes out or I review revision changes:
1. I always have to change the code and recompile as some AjaxToolKit features simply will not work.
2. I believe it was once implemented but someone determined because their code broke that it needed to be reverted back to the FilePath - there was a reason that their code broke and that is because they are designing the toolkit based on physical file paths instead of allowing the actual raw url be used.
FUN FACTIOD: If you use RawUrl - it will still give the FilePath if that is what is intended. However, using FilePath will not return the dynamic url generated by an application. I thoroughly tested that change with the Sample Ajax Website myself...
Not everyone uses the static file structure for application design purposes. Images may be served up from the database instead of file system for example.
Observation on the CalendarExtender...
The use of embedded resources and the lack of actual customizable parameters is distressing. The icons for the the prev next are used as back ground images. A no-no in UI design. You never make a UI that utilizes background images as the 'event selection' as it violates any proper use of Accessibility options within the control.
Secondly - no provision is made for overriding the images. What if you you have a dynamically generated site where the images are in the db instead of on a static file system? With the calendar control there is no efficient way to denote the images and here is my gripe:
Most of the toolkit provides public properties for assigning an image that can at be set in code-behind. The CollapsibleExtender is a great example. The calendar control only loads images from a stylesheet which just like the dynamic path property - invalidates using the control in scenarios where IHTTP handlers are used. Secondly, because it is an embedded resource, if you do not set the ScriptManager localization properties - you will not get the images. Most importantly, the not providing a public property for setting the image url + name - goes against the overall design of features incorporated in 90% of the ToolKit and more importantly, to override the stylesheet settings means having to hack the CSS to do programmic calculations. A hack that can be done but makes maintence and troubleshooting a major issue. Not to mention - it is unnecessary code...
To date I have not been able to use the calendar control properly as the embedded resources for the images fails to actually find the images. Secondly - I am not willing to set all of the globalization settings for the scriptmanager as my application currently doesn't utilize localization..
I am working on revamping the control to use a PrevImageUrl or NextImageUrl to alow the flexibility desired. Additionally getting rid of the requirement this be used as background image as it is sheer misuse of UI design principles... There is no actual use of 'alt' tags either for when images are not found which again go against Accessibility guidelines...
This control should be more closely modeled against the dropdownlistextender as it does provide the mechanisms for the images etc...
Just my two cents...BTW - if you have had a hard time tryinh to adapt styles to the Calendar control the author of the control himself provides great instructions for handling overriding the behaviors via CSS: article here: http://community.bennettadelson.com/blogs/rbuckton/archive/2007/02/02/Skinning-model-for-Calendar-and-Tabs-in-Ajax-Control-Toolkit.aspx