From: Max M. <Max...@ma...> - 2002-07-15 22:07:59
|
Hi Anjo, >> Also I have removed all of the D2W references from ERExtensions, except >> for one ERXValidation. ERXValidation uses the d2wContext to make pretty >> display names for a given propertyKey and a given entity. My suggestion >> for getting rid of the D2W reference in this case is instead use the >> method displayNameForKey off of EOClassDescription to create the pretty >> name. We already have a custom EOEntityClassDescription subclass, so we >> can use the same logic for creating the pretty name (move >> displayNameForPropertyKey from ERD2WUtilities down to >> ERXStringUtiliites >> or some such place). I know that ERXValidation isn't being used as much >> now that we have the validation factory in place (or is it?), so maybe >> in the future to simplify things a bit we can drop ERXValidation >> altogether. Any thoughts? > > Yes, please stop my head from hurting :) > > - I'm all for moving stuff from ERXUtilities to the respective > foundation > Utilities. I have some fixes for Array and Dictionary scheduled myself, > but > only after things cool down a bit. > > ERXValidation has to stay for now because as far as I recall the > validation > mechanism depends on it. That's what I thought, I am sure though that the format of validation messages is now handled via the validation template strings and not by ERXValidation, so the change I proposed (using the class description) should effect any of the regular validation message generation (I'll play around with this before actually committing it) >> On Monday, July 15, 2002, at 10:06 AM, Patrice Gautier wrote: > >>> mystery solved: you were actually hitting a bug in the way ERD2WModel >>> which was affecting not qualifiers (the rule that you listed had a not >>> qualifier). > > Sorry, but I'm not sure what you mean? From what Max wrote, it's not a > good > idea to have object.somekey in my LHS, so doing it with the > ERDDelayedBooleanAssignment seems like the best solution to me > regardless > whether it should have worked or not. It isn't a good idea to have object.someKey in the LHS, all Patrice was stating is that with the correct traversal of the qualifiers in place you wouldn't get the caching behavior that you were seeing. >>> The fix is simple and Max will be submitting it shortly. >>> Also, we are going to move ERXQualifierTraversal and >>> ERXQualifierTraversalCallback to ERDirectToWeb. After this is done, >>> you >>> should be able to revert to the old rule (without the delayed >>> assignment) and it should work.. > > I have my app's "final" revision scheduled on Friday, so you forgive me > if > I'm reluctant to try new fixes that involve checking out the odd 30 > classes > Max has changed today:) Next time say something and we can perform a tag and/or branch so that you can continue to maintain a production app while the frameworks move forward. With respect to the changed files most of those were removing the import com.webobjects.directtoweb.*; The actual fix for the caching bug was two lines of code, basically the qualifier keys from an EONotQualifier were not being counted when constructing the significant keys at runtime like EOAnd and EOOr qualifiers. To see the fix have a look at the last diff of ERDQualifierTraversal.java in ERDirectToWeb. Regards, Max |