<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 11/12/14 2:19 PM, Cantor, Scott
wrote:<br>
</div>
<blockquote cite="mid:A2744D04-83F3-4745-BB4F-671A46D44A86@osu.edu"
type="cite">
<pre wrap="">On 11/12/14, 7:09 PM, "Brent Putman" <a class="moz-txt-link-rfc2396E" href="mailto:putmanb@georgetown.edu"><putmanb@georgetown.edu></a> wrote:
</pre>
<blockquote type="cite">
<pre wrap="">
Have to think more - maybe there's a way to solve - like just overriding
and making the setParent(BaseContext) public on MessageContext. Then
wherever we set the MC's on the PRC, just also set the parent explicitly.
</pre>
</blockquote>
<pre wrap="">
Well, the problem sort of was that the navigation model is class-based,
and I didn't think you could set two child contexts of the same type on
the parent.
</pre>
</blockquote>
<br>
Right, but this wouldn't fall into that case. It would be a special
case, as the MessageContexts vis-a-vis IOOC/PRC already are.
They're not really "child contexts", they're context data, and
wouldn't be accessible/addressable using the *Subcontext() methods.
I wasn't implying that - you still only get/set them via the
explicit property getters/setters.<br>
<br>
I can't immediately see a practical or (in)validity reason not to
have MessageContext getParent() point to its IOOC parent. The only
slightly conceptually messy thing is that the IOOC/PRC would be a
parent of the MCs, but the MC's wouldn't really be children in the
*Subcontext() sense. As long as it's clear that these are "special
data children" and not "subcontexts", then I think we'd be ok. Does
that sound too objectionable? <br>
<br>
<br>
<blockquote cite="mid:A2744D04-83F3-4745-BB4F-671A46D44A86@osu.edu"
type="cite">
<pre wrap="">
It is true that if getParent() worked, the way back down could be via the
message context properties and not with getSubcontext(), </pre>
</blockquote>
<br>
Right, it's implied that crosswalking code would have to check and
cast getParent() to IOOC/PRC and then access via
get(Inbound|Outbound)MessageContext, not via subcontext methods. No
access via the latter.<br>
<br>
<br>
<blockquote cite="mid:A2744D04-83F3-4745-BB4F-671A46D44A86@osu.edu"
type="cite">
<pre wrap="">but I just didn't
think it was a good idea to call setParent() if you end up with a messy
situation due to the class duplication.
</pre>
</blockquote>
<br>
<br>
Right, the duplication and Class literal indexing was (one of) the
reason(s) they aren't subcontexts. With the above, though, I don't
think there's any duplication issues. BaseContext setParent just
sets that reference, it doesn't try and manage the link in the other
direction by calling addSubcontext, etc. That's intentional - it
has 'protected' access and not meant to be called externally. We
can do it here, however, since MC and IOOC are in the same package.<br>
<br>
<blockquote cite="mid:A2744D04-83F3-4745-BB4F-671A46D44A86@osu.edu"
type="cite">
<pre wrap="">
It hasn't come up because we were careful to avoid factoring functionality
in ways that required getting up to the root and back down from the
message handlers.</pre>
</blockquote>
<br>
Yeah, we consciously decided I think we didn't in general want to do
that (we instead have external code copy stuff from inbound to
outbound, etc). I didn't yet get all the details from this thread
about why Rod was proposing the crosswalk, but if we want to support
it, I think we can.<br>
<br>
I'll hold off checking anything in pending further discussion. The
changes are trivial if we decide to support it.<br>
<br>
<br>
<br>
<br>
</body>
</html>