Tim Lesher <[EMAIL PROTECTED]> writes: > Pardon me for jumping in, but I think that retaining two widgets for > the sample feature is a very bad idea.
I think that there's a very interesting amount of features on the actual calendar system BUT the other one works on Safari as well as the other browsers, even though it has less features. Feature-wise, I prefer the first. Here in .br the amount of Macs is very small to "worry" with them on a public site to abdicate of certain things. On the other hand, I prefer having this audience as well. So, I'd really like the first one fixed to work with Safari -- or having Safari fixed, what would be much better since I believe this will not be the only place where that will happen. > 1. It makes maintenance more difficult--if we add features to or fix > bugs in one, we'll certainly have to do the same thing again. Both are external code, so it depends on their authors... We just have an integration layer through the calendarpickerwidget. At least, that's what I've seen so far... > 2. It causes confusion among users--"which of the two should I use" > will be a very frequently asked question. Not if the calendarpicker can detect the browser and enable the one with more features for browsers other than Safari and use the one with less features just to workaroung this bug. The decision is not on the user's (developer's, in this case) hands. > 3. It shows indecision on the part of the library designer--not good > for instilling confidence in potential users. I see that as a good decision to keep both and wrap them until the one with more features or Safari gets fixed... -- Jorge Godoy <[EMAIL PROTECTED]>
