> 2. It causes confusion among users--"which of the two should I use" > will be a very frequently asked question.
It's not the users who have to pick, it's the developers. If each option has pros and cons (ie. one isn't way better than the other), having the choice means that the developer doesn't have to write their own widget to wrap this other calendar when the widget could be so generic. > 3. It shows indecision on the part of the library designer--not good > for instilling confidence in potential users. > > > TurboGears doesn't come with multiple database mapping layers, > templating engines, or application servers, even though there are > others out there as good as SQLObject, Kid, and CherryPy. There's a > reason that the Zen of Python says "There should be one--and > preferably only one--obvious way to do it." We're talking interface here, not programming methodology. If every application looked the same and had the same interface, I'd have no problem agreeing with you. But, I believe, one of the reasons we're all using turbogears is because we want to easily have access to a "new" interface methodology, AJAX. AJAX gives you way more interface options than regular HTML, but each interface option follows slightly different interface ideas, so why wouldn't you include more than one option, if each one does things differently? Jason -- If you understand, things are just as they are. If you do not understand, things are just as they are.
pgpUfa7krELwg.pgp
Description: PGP signature
