<div dir="ltr"><div>IterationPayloadManager manages getting/setting of the current iteration payload (e.g. the current cursor as you called it.) </div><div><br></div><div>IterationSelectionManager provides access to the specified selection variable (e.g. something that was selected via GraphSearchConditionBuilder (this name was initially "Selection" and we probably need to think about changing the name to something else)</div>
<div><br></div><div>Regarding renaming SelectionFactory. I don't really like the name VarStack, but I am open to suggestions. I think in looking at it again, it might even need to be split into two types: "SelectionVariableStack" or "IterationPayloadContext", because SelectionFactory currently does both of those things, and they could actually be separate.</div>
<div><br></div><div>~Lincoln</div><div></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Wed, Jun 25, 2014 at 12:19 AM, Ondrej Zizka <span dir="ltr"><<a href="mailto:ozizka@redhat.com" target="_blank">ozizka@redhat.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class=""><br>
On 25.6.2014 04:58, Ondrej Zizka wrote:<br>
> Hi,<br>
><br>
> what's the purpose of having IterationSelectionManager and<br>
> IterationPayloadManager?<br>
> I can only see Named~ and TypedNamed.<br>
> Wouldn't a simple method overload in SelectionFactory be enough for just<br>
> giving the option of type checking?<br>
> Or do we assume some other use case for that?<br>
> Also, the names don't fit - it's not manager, rather some kind of<br>
> filter, or getter.<br>
</div>Regarding IterationSelectionManager, it looks like it was created for<br>
the Gremlin query API, which is based on Iteration as it assumes it<br>
needs some initial vertices.<br>
True?<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
> Also, how about splitting SelectionFactory to VarStack and<br>
> CurrentPayloadManager? The variable stack and "current payload" seem to<br>
> be related only indirectly, by concept - at least in the current<br>
> implementation.<br>
><br>
> And lastly, I'd rename "current payload" to something like "cursor"<br>
> (resembling DB result iteration) or "current item" or "current element"<br>
> (which is how XSLT refers to iterated nodes). Payload rather evokes that<br>
> there's some wrapper around it, which is not.<br>
><br>
> Thanks,<br>
> Ondra<br>
> _______________________________________________<br>
> windup-dev mailing list<br>
> <a href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a><br>
> <a href="https://lists.jboss.org/mailman/listinfo/windup-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/windup-dev</a><br>
<br>
_______________________________________________<br>
windup-dev mailing list<br>
<a href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a><br>
<a href="https://lists.jboss.org/mailman/listinfo/windup-dev" target="_blank">https://lists.jboss.org/mailman/listinfo/windup-dev</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br>Lincoln Baxter, III<br><a href="http://ocpsoft.org" target="_blank">http://ocpsoft.org</a><br>"Simpler is better."
</div>