Le 2013-04-01 à 13:02, Ramsey Gurley <[email protected]> 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(ERMD2WSimpleHeader.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 protected])
>>>> Help/Unsubscribe/Update your Subscription:
>>>> https://lists.apple.com/mailman/options/webobjects-dev/rgurley%40smarthealth.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:
>>> https://lists.apple.com/mailman/options/webobjects-dev/probert%40macti.ca
>>>
>>> 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:
https://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to [email protected]
