Re: Weird problem with D2W rules
Re: Weird problem with D2W rules
- Subject: Re: Weird problem with D2W rules
- From: Dan Beatty <email@hidden>
- Date: Mon, 01 Apr 2013 11:52:01 -0700
- Thread-topic: Weird problem with D2W rules
So Pascal, Ramsey, and fellow members of the Wonder gang,
If I were to teach a course and should need recommendations for the way to
teach and learn Git; what packages, books, online references, etc would you
recommend as a kind of training wheels for said students? Also, if I were
to produce an iBook and its Android equivalent form of our WO book with
clips from the the tutorials, what all would I need to do it?
V/R,
Daniel Beatty, Ph.D.
Computer Scientist, Detonation Sciences Branch
Code 474300D
1 Administration Circle M/S 1109
China Lake, CA 93555
email@hidden
(LandLine) (760)939-7097
(iPhone) (806)438-6620
On 4/1/13 11:27 AM, "Pascal Robert" <email@hidden> wrote:
>
Le 2013-04-01 à 13:02, Ramsey Gurley <email@hidden> a écrit :
> I
> merged the fix to the master and integration branches. As far as I can tell,
> I've got everything done except pushing the tag on master. It just wasn't in
> my push configuration. I can try again when I get home tonight.
>
> As for
> releasing other integration changes, I tend to use eGit for everything. Is
> there anything in that command line magic which wouldn't happen if I just make
> a local branch at a9426 and merged that into master?
I don't use eGit anymore
> for commits or branching, I use it only to check the history in Eclipse or to
> see the status of the files. For preparing a release of Wonder, I always did
> it by command line. For everything else, I use SourceTree.
> Ramsey
>
> On
> Apr 1, 2013, at 9:44 AM, Pascal Robert wrote:
>
>> In that case, do a real
> 6.0.3 release
>>
>> Switch into the master branch
>>
>> Check the Git
> history of the integration branch and note the last commit that should be
> integrated into master (a9426b5ed8a806b6a7292209f8783416bce1a046 is a good
> candidate for 6.0.3).
>>
>> Do a merge with the commit id of the previous
> step: git merge -s recursive -Xpatience -Xtheirs XXXXXX
>>
>> Push the
> release candidate to GitHub: git push origin master
>>
>> Tag the merge
> with a "wonder-6.x.x" tag:
>>
>> git tag -a wonder-6.x.x
>> git push
> --tags
>>
>>> And evidently, I didn't configure my push to push the new 6.0.3
> tag :P
>>>
>>> Anyway, try the latest master Freddie and see if your problem
> goes away.
>>>
>>> Ramsey
>>>
>>> On Mar 30, 2013, at 3:17 PM, Ramsey Gurley
> wrote:
>>>
>>>>
>>>> On Mar 30, 2013, at 11:18 AM, Ramsey Gurley wrote:
>>>>
>
>>>>>
>>>>> On Mar 29, 2013, at 3:37 PM, Ramsey Gurley wrote:
>>>>>
>>>>>>
> On Mar 29, 2013, at 2:27 PM, Freddie Tilley wrote:
>>>>>>
>>>>>>> at
> er.modern.directtoweb.components.header.ERMD2WSimpleHeader.headerString(ERMD2W
> SimpleHeader.java:25)
>>>>>>>
>>>>>>
>>>>>> My wonder says that line
> is:
>>>>>>
>>>>>> return
> stringValueForBinding(Keys.displayNameForPageConfiguration);
>>>>>>
>>>>>>
> What is your rule for displayNameForPageConfiguration? It doesn't look like
> your stack trace goes through ERDDefaultDisplayNameAssignment.
>>>>>>
>>>>>>
> Kieran,
>>>>>>
>>>>>> This also looks like a bug in wonder. ERXGenericRecord
> doesn't handle a null editingContext() in handleQueryForUnboundKey(). That's
> going to be the case on deleted objects.
>>>>>>
>>>>>> I think that should
> just check entity().primaryKeyAttributeNames().contains(key) first. That
> method is called a lot and there's no reason to be building pk dictionaries
> every time. This shouldn't wait for the next integration merge.
>>>>>>
>>>>>>
> Ramsey
>>>>>
>>>>> Hmm, even calling entity() repeatedly is going to add
> overhead. Adding a private static
>>>>
>>>> er.. transient :P Can't be static
> since every eo would share the same entity.
>>>>
>>>>> entity var may be
> needed to cache the EOEntity and prevent constantly searching through the
> models :-/ The other problem I see is that entity() may result in null when
> there's no ec and the entity is not in the default model group. Not sure how
> often that happens.
>>>>>
>>>>> I'm thinking this method should look
> something like to prevent the NPE:
>>>>>
>>>>> public Object
> handleQueryWithUnboundKey(String key) {
>>>>> // Handles primary key
> attribute values
>>>>> if(entity().primaryKeyAttributeNames().contains(key))
> {
>>>>> // Deleted object. Return null.
>>>>> if(editingContext() == null)
> {
>>>>> return null;
>>>>> }
>>>>> NSDictionary pkDict =
> EOUtilities.primaryKeyForObject(editingContext(), this);
>>>>> // New
> object. Return null.
>>>>> if(pkDict == null) {
>>>>> return null;
>>>>>
> }
>>>>> // Return value for key
>>>>> return
> pkDict.objectForKey(key);
>>>>> }
>>>>> return
> super.handleQueryWithUnboundKey(key);
>>>>> }
>>>>>
>>>>> Alternately, is
> this something that we could simply remove and put into an eogen template for
> anyone who needs this? The more I look at this the less I like it. This method
> is going to get called a ton for any ERD2W app that uses object.someKey in
> rules.
>>>>>
>>>>> In my ERUsers framework I have
>>>>>
>>>>> 55 :
> (pageConfiguration = 'CreateERUser' and propertyKey = 'clearPassword' and
> object.password.length > 0) => componentName = "R2D2WPropertyMessage"
> [com.webobjects.directtoweb.Assignment]
>>>>>
>>>>> Which means the current
> method is called and creating a pkDict for every single property level
> component on every single page that isn't an ERUser. I just tested it on a
> ListMovie page. On a ten item page, handleQueryWithUnboundKey is called 960
> times.
>>>>
>>>> Also, I obviously need to change the way I'm doing
> componentName here because even creating 960 UnknownKeyExceptions is just
> excessive.
>>>>
>>>>> This is not good. This method needs to be very fast or
> it needs to be removed.
>>>>>
>>>>> Ramsey
>>>>>
>>>>
>>>>
> _______________________________________________
>>>> Do not post admin
> requests to the list. They will be ignored.
>>>> Webobjects-dev mailing list
> (email@hidden)
>>>> Help/Unsubscribe/Update your
> Subscription:
>>>>
> om
>>>>
>>>> This email sent to email@hidden
>>>
>>>
> _______________________________________________
>>> 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
>>
>
> _______________________________________________
Do not post admin requests to
> the list. They will be ignored.
Webobjects-dev mailing list
> (email@hidden)
Help/Unsubscribe/Update your
> Subscription:
> email@hidden
This email sent to email@hidden
_______________________________________________
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