[furcas-discussion] Reference Re-Evaluation Algorithm

[Stephan Erb]

Hey Axel,

I have no clue. Your proposal sounds reasonable to me but I wouldn't bet
on it, given the fact that sometimes TextBlocks are merged if they don't
contribute to the concrete syntax.

This discussion somewhat implies to me that we are wasting our energy:
Our second-most important data structure, the TextBlocks model, is so
complex and underspecified that we constantly struggle with it.

I would suggest that we try to redesign the TextBlocks model so that it
is easier to handle. For example, each TextBlock could have exactly one
corresponding ModelElement. If TextBlocks contain no concrete syntax,
then they would simply have no subnodes.  I guess we can think of even
more simplifications.

This is additional short term effort, but I am very sure it is a
worthwhile investment.


Best Regards,
Stephan


On Fri, 2011-02-11 at 17:19 +0100, Uhl, Axel wrote:
> Stephan,
> 
> thinking about this again suggest something else. I don't think we want to rely on the token's referencedElements to be set in order to determine whether the token is the one that belongs to the update notification received. The token may be stale anyway because it was in some remote resource that didn't get updated upon an earlier change.
> 
> Instead, we should be looking for the token's parent text blocks. They should lead to a text block, ultimately, whose corresponding model element is the one to be updated with the resolution of the token, shoulnd't it?
> 
> I'm just uncertain again how the LexedToken may be nested inside TextBlocks. Can I assume that the LexedToken's getParent() is the template that has in its correspondingModelElements the element to be updated with the property?
> 
> -- Axel
> 
> > -----Original Message-----
> > From: furcas-discussion-bounces at lists.furcas.org [mailto:furcas-
> > discussion-bounces at lists.furcas.org] On Behalf Of Stephan Erb
> > Sent: Friday, February 11, 2011 3:12 PM
> > To: furcas-discussion
> > Subject: Re: [furcas-discussion] Reference Re-Evaluation Algorithm
> > 
> > > > PS: Thomas, we might need your help with all this textblocks magic
> > > > (e.g.
> > > > find out if a reference is still bound). Expect some questions on
> > the
> > > > mailing list rather soon :-)
> > >
> > > I found that out myself. In this case it was an easy reverse lookup
> > on DocumentNode_SequenceElement using the OppositeEndFinder API.
> > 
> > Hi Axel,
> > 
> > I just had a (very) short look at the OCLQueryPropertyUpdate. Is there
> > a
> > reason why the 'referencedElements' aren't checked anywhere? I always
> > thought that those entail the crucial information whether a token is
> > bound to something or not.
> > 
> > Example from the MOIN code base where used them:
> > 
> >     private Collection<?> findCurrentlySetElements(DelayedReference
> > unresolvedRef, ModelInjector modelInjector,
> > 	    LexedToken tokenInCurrentConnection) throws
> > ModelAdapterException {
> > 
> > 	Collection<?> valueCollection =
> > modelInjector.getModelAdapter().get(unresolvedRef.getModelElement(),
> > unresolvedRef.getPropertyName());
> > 	if (tokenInCurrentConnection != null) {
> > 
> > valueCollection.retainAll(tokenInCurrentConnection.getReferencedElement
> > s());
> > 	}
> > 	return valueCollection;
> >     }
> > 
> > Best,
> > Stephan
> > 
> > 
> > 
> > _______________________________________________
> > Furcas-discussion mailing list
> > Furcas-discussion at lists.furcas.org
> > http://lists.furcas.org/cgi-bin/mailman/listinfo/furcas-discussion