This seems like a good idea, amazingly good if you consider who it came from! :-P
On Sep 30, 2010, at 2:50 AM, David Avendasora wrote: > Hi all, > > I think that the way to handle this, along with other "If we make it right, > it's going to break existing code" issues is going to be 100% dependent upon > how the UI of the dev tools handles this. > > 1) Models/Entities/Attributes need to have a concept of deprecation. Maybe > use the UserInfo dictionary? (user info of the prototype has > "deprecated=true" and "deprecatedNote=reason" in it?) User info seems a reasonable place to start. > 2) Entity Modeler displays a validation warning on open and save if you are > using a deprecated prototype. Need to get Mr. Schrag to buy into that one. > 3) In Entity Modeler, when you switch a Prototype, it clears out all existing > attribute properties and sets them to the properties of the new prototype. Hmmm, all? That seems undesirable. I need to re-enter the column name? An auto generated migration would be cool. > 4) _Entity.java EOGenerator template needs to pick up that a given class > attribute is using a deprecated prototype and have it deprecate the > getter/setters (and include the depreationNote in the Javadoc) in the > _MyEntity class (1) and (4) we could do right now. (4) won't work for anyone using custom templates (unless they update those templates). > What this would mean for this situation is that we create 2 new Prototypes > DateOnly and DateWithTime and deprecate Date. The next time someone opens > their project that uses the deprecated Date prototype they'll get a warning > on their Model telling them that the Date prototype they are using has been > deprecated, and the next time they EOGenerate the getters/setters will be > deprecated as well. Any methods that use them will show as deprecated and > have the deprecationNote from the UserInfo in the mouse-over , e.g., > "mySetter uses a deprecated prototype in the model. You should use either > DateOnly or DateWithTime instead of Date as the Date prototype is horribly > broken and likely doesn't do what you think it does." > > I think this would allow for making changes without breaking anything, yet > encourage people to switch to the new prototypes. > > Dave I bet your kid just grabbed your laptop and typed this. No way you could come up with an idea like this. Chuck > On Sep 30, 2010, at 3:03 AM, Simon wrote: > >>> Calendar dates should not be represented by NSTimestamp. The Date >>> prototype is wrong for using it IMHO. >> >> i couldn't agree more. but where do we go from here ? >> >> 1) leave the mysql date prototype as it is now, broken and unusable >> >> 2) patch the mysql date prototype so that it works properly, but still >> mapped to NSTimestamp so that we don't break everyone in the world who >> is using it as an NSTimestamp >> >> 3) change the mysql date prototype completely (i'm a fan of plain old >> int's) and put up with the flack from the people we break! >> >> 4) alternatively i guess we could just add a new mysql prototype (e.g. >> intDate) .... ? >> >> simon >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list ([email protected]) >> Help/Unsubscribe/Update your Subscription: >> http://lists.apple.com/mailman/options/webobjects-dev/webobjects%40avendasora.com >> >> This email sent to [email protected] >> >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list ([email protected]) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/chill%40global-village.net > > This email sent to [email protected] -- Chuck Hill Senior Consultant / VP Development Practical WebObjects - for developers who want to increase their overall knowledge of WebObjects or who are trying to solve specific problems. http://www.global-village.net/products/practical_webobjects
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
