<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
<br>
<div class="moz-cite-prefix">On 25.6.2014 08:04, Lincoln Baxter, III
wrote:<br>
</div>
<blockquote
cite="mid:CAEp_U4FK0XxcSHfjSSeUO9wtfYQC9TzU-1p05Z3jyjQxTtPn0Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>IterationPayloadManager manages getting/setting of the
current iteration payload (e.g. the current cursor as you
called it.) <br>
</div>
</div>
</blockquote>
<blockquote
cite="mid:CAEp_U4FK0XxcSHfjSSeUO9wtfYQC9TzU-1p05Z3jyjQxTtPn0Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<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>
</blockquote>
It's rather some kind of view/projection than a manager - the
SelectionFactory / VarStack actually manages both.<br>
And I ponder how many ways to get the frames based on a name can
there be. Can one var name lead to different set frames? If not,
then that's my point - if there's just one, then this layer is not
necessary. Or do I miss something?<br>
<blockquote
cite="mid:CAEp_U4FK0XxcSHfjSSeUO9wtfYQC9TzU-1p05Z3jyjQxTtPn0Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>Regarding renaming SelectionFactory. I don't really like
the name VarStack, but I am open to suggestions.</div>
</div>
</blockquote>
Well, I already renamed it to VarStack :) I hope you like it more
than SelectionFactory. More below.<br>
<br>
<blockquote
cite="mid:CAEp_U4FK0XxcSHfjSSeUO9wtfYQC9TzU-1p05Z3jyjQxTtPn0Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div>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>
</blockquote>
Right. This would bring a need to drag 2 references around, so it
might need some object above it, but I think splitting it will be
worth it, to keep these two contracts decoupled.<br>
<br>
The variables stack doesn't necessarily have to keep just sets of
frames. I think later we will use the same storage to store both
list of frames and other values - or not?<br>
I can imagine users will need to store a string. Sure, they can
store it to the graph, too. Depends on how easy we make that.<br>
<br>
That said, the structure could be: <br>
<br>
<some clever name like><br>
-- VarStack <------ nothing?<br>
-- PayloadKeeper <------ PayloadProjector?<br>
<br>
Ondra<br>
<br>
<br>
<blockquote
cite="mid:CAEp_U4FK0XxcSHfjSSeUO9wtfYQC9TzU-1p05Z3jyjQxTtPn0Q@mail.gmail.com"
type="cite">
<div dir="ltr">
<div><br>
</div>
<div>~Lincoln</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 moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a><br>
> <a moz-do-not-send="true"
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 moz-do-not-send="true"
href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a><br>
<a moz-do-not-send="true"
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 moz-do-not-send="true" href="http://ocpsoft.org"
target="_blank">http://ocpsoft.org</a><br>
"Simpler is better."
</div>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">_______________________________________________
windup-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:windup-dev@lists.jboss.org">windup-dev@lists.jboss.org</a>
<a class="moz-txt-link-freetext" href="https://lists.jboss.org/mailman/listinfo/windup-dev">https://lists.jboss.org/mailman/listinfo/windup-dev</a></pre>
</blockquote>
<br>
</body>
</html>