Re: Patched MySQL plugin
Re: Patched MySQL plugin
- Subject: Re: Patched MySQL plugin
- From: David Avendasora <email@hidden>
- Date: Thu, 30 Sep 2010 15:26:40 -0400
On Sep 30, 2010, at 2:35 PM, Chuck Hill wrote:
> This seems like a good idea, amazingly good.
There. Fixed it for you.
> 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.
It's where everything goes.
>> 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.
Yup, but the basic validation functionality already is there, this is just adding to it. (everything is easy when you didn't actually write the code)
>
>> 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.
Oh, jeez. Obviously the attribute name and column name wouldn't change. But the things that you actually use a prototype for would.
>> 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).
Right. Custom templates would need to be updated, but we could even provide the Velocity code to do it so people could easily add it to their own 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.
I wrote it in my sleep. "at ***2:50 AM***, David Avendasora wrote"
Dave _______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden