Re: [SOLVED] D2W: getting the "root" pageConfiguration
Re: [SOLVED] D2W: getting the "root" pageConfiguration
- Subject: Re: [SOLVED] D2W: getting the "root" pageConfiguration
- From: Ramsey Gurley <email@hidden>
- Date: Mon, 29 Oct 2012 10:10:43 -0700
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@hidden> 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@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:
>>>>>>>>>>>>>
>>>>>>>>>>>>> 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:
>>>>>>>>>>>
>>>>>>>>>>> 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:
>>>>>
>>>>> This email sent to email@hidden
>>>>
>>>> --
>>>> 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@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:
>
> 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