Good catch. But I would do the session bit in resetCaches instead of
resetContextCache. I'll update this on integration tonight now that I've got my
internet back.
Ramsey
On Oct 27, 2012, at 1:09 PM, Fabian Peters wrote:
> I finally found out what's going on. From ERD2WSwitchComponent:
>
> //FIXME restting the caches breaks the context in the embedded component
> public void resetCaches() {
> //log.debug("Resetting caches");
> //takeValueForKey(null,"_task"); // this will break in 5.0 :-)
> //takeValueForKey(null,"_entityName");
> // Finalizing a context is a protected method, hence the utiltiy.
>
> //ERD2WUtilities.finalizeContext((D2WContext)valueForKey("subContext"));
> //takeValueForKey(null,"_context");
>
> //HACK HACK HACK ak: When you have several embedded list components in
> // a tab page
> // D2W gets very confused about the keys. It will assume that the
> // objects on the second tab somehow belong to the first
> // resetting the cache when setting a new page configuration prevents
> // this
> D2WContext subContext = (D2WContext) valueForKey("subContext");
> ERD2WUtilities.resetContextCache(subContext);
> subContext.setDynamicPage((String) valueForBinding("_dynamicPage"));
> subContext.takeValueForKey(D2WModel.One, "frame");
> }
>
> I changed ERD2WUtilities.resetContextCache to preserve the session:
>
> public static void resetContextCache(D2WContext context) {
> if (context != null) {
> WOSession s = (WOSession) context.valueForKey("session");
> context._localValues.clear();
> if (s != null) {
> context.takeValueForKey(s, "session");
> }
> }
> }
>
>
> And everything works as expected. As I understand it, the problem only occurs
> when an existing context is getting reused. Which explains why my rule worked
> as expected most of the time, but not in the special case of object creation
> followed immediately by an attempt to edit the newly created object.
>
> Does anybody see how preserving the session could have unwanted side effects?
>
> Thanks everybody for your help in figuring this out! I'm off to enjoy the
> weekend...
>
> Am 27.10.2012 um 06:38 schrieb Ramsey Gurley:
>
>> That tells you it's null, but not how it got that way. When you set the
>> breakpoint there, is your context an instance of ERD2WContext? It should be.
>> Assuming that is the case, then put breakpoints in ERD2WContext's
>> constructors and see where it's getting created and what is creating it
>> without a session.
>>
>> On Oct 26, 2012, at 3:37 PM, Fabian Peters wrote:
>>
>>> It's line 50 in the original ERD2WUtilities, but line 59 in my screenshot.
>>> So, i == 7 and the null result is returned by:
>>>
>>>>>> result = c.valueForKeyNoInference(first);
>>>
>>>
>>> Am 26.10.2012 um 23:53 schrieb Chuck Hill:
>>>
>>>> For the keypath you are showing, how can i == -1? Does that keypath have
>>>> some character other character than .? Looks like a period, but isn't?
>>>>
>>>>
>>>> On 2012-10-26, at 2:48 PM, Fabian Peters wrote:
>>>>
>>>>> Well, I've been able to find where it returns null for the session, but I
>>>>> have no idea why. It's line 50 of ERD2WUtilities:
>>>>>
>>>>>> // This prevents the dreaded KeyValueCoding null object exception, for
>>>>>> say key paths: object.entityName
>>>>>> // Should just return null instead of throwing.
>>>>>> public static Object contextValueForKeyNoInferenceNoException(D2WContext
>>>>>> c, String keyPath) {
>>>>>> Object result = null;
>>>>>> int i = keyPath.indexOf(".");
>>>>>> if (i == -1) {
>>>>>> result = c.valueForKeyNoInference(keyPath);
>>>>>> } else {
>>>>>> String first = keyPath.substring(0, i);
>>>>>> String second = keyPath.substring(i + 1);
>>>>>> result = c.valueForKeyNoInference(first);
>>>>>
>>>>>
>>>>>
>>>>> <http://www.e-lumo.com/tmp/d2wdebug2.png>
>>>>> <http://www.e-lumo.com/tmp/d2wdebug3.png>
>>>>>
>>>>> The line numbers in my screenshots don't match as I had to add the
>>>>> keyPaths array as a debugging aid. The null result occurs exactly once
>>>>> when the edit button is clicked, never when the "New" button is clicked.
>>>>>
>>>>> Any input much appreciated!
>>>>>
>>>>> Am 26.10.2012 um 22:32 schrieb David LeBer:
>>>>>
>>>>>> Fabian,
>>>>>>
>>>>>> If you cannot access the session from within any part of the D2W system
>>>>>> that is just whacked.
>>>>>>
>>>>>> D2W is heavily dependent on a session.
>>>>>>
>>>>>> Yes, you need to dig deeper, I for one, am scratching my head.
>>>>>>
>>>>>> D
>>>>>>
>>>>>> On 2012-10-26, at 4:26 PM, Fabian Peters <[email protected]> wrote:
>>>>>>
>>>>>>> Unfortunately, yes. I had already tried another key on session. I'm now
>>>>>>> using a conditional breakpoint for the keypath in ERD2WUtilities'
>>>>>>> contextValueForKeyNoInferenceNoException method. When the creation page
>>>>>>> is generated, everything's fine. But when the edit page is generated, I
>>>>>>> get a null result for the key path at times - other times it returns
>>>>>>> the expected value. Looks like a longer debugging session...
>>>>>>>
>>>>>>> Am 26.10.2012 um 22:19 schrieb Ramsey Gurley:
>>>>>>>
>>>>>>>> Are you sure there's no session? What do you get when you enter
>>>>>>>> session.sessionID?
>>>>>>>>
>>>>>>>> On Oct 26, 2012, at 12:05 PM, Fabian Peters wrote:
>>>>>>>>
>>>>>>>>> Thanks Ramsey, just tried this but to no avail. I've tried both
>>>>>>>>>
>>>>>>>>> session.context.page.d2wContext.entity.name
>>>>>>>>> session.context.page.d2wContext.pageConfiguration
>>>>>>>>>
>>>>>>>>> in the "D2W Key" field of the ERDDebuggingHelp. The problem seems to
>>>>>>>>> be that the session cannot be reached, unless the call is made from
>>>>>>>>> within the property level repetition:
>>>>>>>>>
>>>>>>>>> <http://www.e-lumo.com/tmp/d2wdebug.png>
>>>>>>>>>
>>>>>>>>>
>>>>>>>>> Am 26.10.2012 um 20:37 schrieb Ramsey Gurley:
>>>>>>>>>
>>>>>>>>>> You may not necessarily have a page configuration depending on how
>>>>>>>>>> the page is instantiated. Have you tried a rule with a LHS like
>>>>>>>>>>
>>>>>>>>>> session.context.page.d2wContext.entity.name = 'EntityA' and
>>>>>>>>>> session.context.page.d2wContext.task = 'edit'
>>>>>>>>>>
>>>>>>>>>> ?
>>>>>>>>>>
>>>>>>>>>> Ramsey
>>>>>>>>>>
>>>>>>>>>> On Oct 26, 2012, at 11:18 AM, Fabian Peters wrote:
>>>>>>>>>>
>>>>>>>>>>> Sorry, sent too fast and mixed up my mock entities. This seems to
>>>>>>>>>>> be (more) correct:
>>>>>>>>>>>
>>>>>>>>>>> Unfortunately parentPageConfiguration doesn't help, as there's an
>>>>>>>>>>> additional level of nesting due to the
>>>>>>>>>>> "EditRelationshipEmbeddedEntityC". It will always just return
>>>>>>>>>>> "EditRelationshipEmbeddedEntityC", when the embedded page is
>>>>>>>>>>> "EditEmbeddedEntityC" and the "root" pageConfiguration is
>>>>>>>>>>> "EditEntityA" or "EditEntityB".
>>>>>>>>>>>
>>>>>>>>>>> My rule works fine when the pageConfiguration is
>>>>>>>>>>> "CreateEmbeddedEntityC":
>>>>>>>>>>>
>>>>>>>>>>> 333 : ((pageConfiguration = 'CreateEmbeddedEntityC' or
>>>>>>>>>>> pageConfiguration = 'EditEmbeddedEntityC') and
>>>>>>>>>>> session.context.page.d2wContext.pageConfiguration like '*EntityC')
>>>>>>>>>>> => displayPropertyKeys = ("foo", "bar", "baz")
>>>>>>>>>>> [com.webobjects.directtoweb.Assignment]
>>>>>>>>>>>
>>>>>>>>>>> But the same rule fails when the task is "edit". Tracing the rules
>>>>>>>>>>> shows that "session.context.page.d2wContext.pageConfiguration"
>>>>>>>>>>> evaluates to null then.
>>>>>>>>>>>
>>>>>>>>>>> Am 26.10.2012 um 20:00 schrieb David Holt:
>>>>>>>>>>>
>>>>>>>>>>>> Sorry those should have been: editEmbeddedRelationshipEntityC
>>>>>>>>>>>>
>>>>>>>>>>>>
>>>>>>>>>>>> On 2012-10-26, at 10:57 AM, David Holt wrote:
>>>>>>>>>>>>
>>>>>>>>>>>>> If you're using embedded configurations, wouldn't you just have a
>>>>>>>>>>>>> couple of rules like:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 20 : (pageConfiguration = 'editRelationshipEntityC' and
>>>>>>>>>>>>> parentPageConfiguration = 'EditEntityA') => displayPropertyKeys =
>>>>>>>>>>>>> ("name", "description") [com.webobjects.directtoweb.Assignment]
>>>>>>>>>>>>>
>>>>>>>>>>>>> 20 : (pageConfiguration = 'editRelationshipEntityC' and
>>>>>>>>>>>>> parentPageConfiguration = 'EditEntityB') => displayPropertyKeys =
>>>>>>>>>>>>> ("name") [com.webobjects.directtoweb.Assignment]
>>>>>>>>>>>>>
>>>>>>>>>>>>> Unless I'm missing what you're trying to do.
>>>>>>>>>>>>>
>>>>>>>>>>>>> d
>>>>>>>>>>>>>
>>>>>>>>>>>>>
>>>>>>>>>>>>> On 2012-10-26, at 10:09 AM, Fabian Peters wrote:
>>>>>>>>>>>>>
>>>>>>>>>>>>>> Yes, this is with ModernLook.
>>>>>>>>>>>>>>
>>>>>>>>>>>>>> Am 26.10.2012 um 17:56 schrieb David Holt:
>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> Are you using ModernLook with actual embedded page
>>>>>>>>>>>>>>> configurations?
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> David
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>> On 2012-10-26, at 6:40 AM, Fabian Peters wrote:
>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Hi all,
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> An entity that's being edited (EntityC) has relationships to
>>>>>>>>>>>>>>>> two different entities (EntityA, EntityB) and different keys
>>>>>>>>>>>>>>>> should be shown depending on the context (root
>>>>>>>>>>>>>>>> pageConfiguration being "EditEntityA" or "EditEntityB"). In
>>>>>>>>>>>>>>>> order to display the right properties on an embedded page, I
>>>>>>>>>>>>>>>> need to look at the root pageConfiguration,
>>>>>>>>>>>>>>>> "parentPageConfiguration" is the same in both contexts.
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Calling "session.context.page.d2wContext.pageConfiguration"
>>>>>>>>>>>>>>>> works when used at the property level, but (mostly) fails when
>>>>>>>>>>>>>>>> used in a rule acting on "displayPropertyKeys". Apparently,
>>>>>>>>>>>>>>>> it's impossible to get to the session from there. Is there an
>>>>>>>>>>>>>>>> alternative approach to get the root page configuration in a
>>>>>>>>>>>>>>>> D2W app?
>>>>>>>>>>>>>>>>
>>>>>>>>>>>>>>>> Fabian
>>>>>>>>>>>>>>>> _______________________________________________
>>>>>>>>>>>>>>>> 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/programmingosx%40mac.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/programmingosx%40mac.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/lists.fabian%40e-lumo.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/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/dleber_wodev%40codeferous.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/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/gvc/practical_webobjects
>>>>
>>>> Global Village Consulting ranks 13th in 2012 in BIV's Top 100 Fastest
>>>> Growing Companies in B.C!
>>>> Global Village Consulting ranks 76th in 24th annual PROFIT 200 ranking of
>>>> Canada’s Fastest-Growing Companies by PROFIT Magazine!
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>
>>>
>>> _______________________________________________
>>> 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/ramseygurley%40gmail.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/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/archive%40mail-archive.com
This email sent to [email protected]
