[windup-dev] Iteration*Managers

[Ondrej Zizka]

On 25.6.2014 08:04, Lincoln Baxter, III wrote:
> IterationPayloadManager manages getting/setting of the current 
> iteration payload (e.g. the current  cursor as you called it.)
>
> 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)
It's rather some kind of view/projection than a manager - the 
SelectionFactory / VarStack actually manages both.
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?
>
> Regarding renaming SelectionFactory. I don't really like the name 
> VarStack, but I am open to suggestions.
Well, I already renamed it to VarStack :) I hope you like it more than 
SelectionFactory. More below.

> 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.
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.

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?
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.

That said, the structure could be:

<some clever name like>
      -- VarStack                  <------  nothing?
      -- PayloadKeeper      <------  PayloadProjector?

Ondra


>
> ~Lincoln
>
>
> On Wed, Jun 25, 2014 at 12:19 AM, Ondrej Zizka <ozizka at redhat.com 
> <mailto:ozizka at redhat.com>> wrote:
>
>
>     On 25.6.2014 04:58, Ondrej Zizka wrote:
>     > Hi,
>     >
>     > what's the purpose of having IterationSelectionManager and
>     > IterationPayloadManager?
>     > I can only see Named~ and TypedNamed.
>     > Wouldn't a simple method overload in SelectionFactory be enough
>     for just
>     > giving the option of type checking?
>     > Or do we assume some other use case for that?
>     > Also, the names don't fit - it's not manager, rather some kind of
>     > filter, or getter.
>     Regarding IterationSelectionManager, it looks like it was created for
>     the Gremlin query API, which is  based on Iteration as it assumes it
>     needs some initial vertices.
>     True?
>
>     >
>     > Also, how about splitting SelectionFactory to VarStack and
>     > CurrentPayloadManager? The variable stack and "current payload"
>     seem to
>     > be related only indirectly, by concept - at least in the current
>     > implementation.
>     >
>     > And lastly, I'd rename "current payload" to something like "cursor"
>     > (resembling DB result iteration) or "current item" or "current
>     element"
>     > (which is how XSLT refers to iterated nodes). Payload rather
>     evokes that
>     > there's some wrapper around it, which is not.
>     >
>     > Thanks,
>     > Ondra
>     > _______________________________________________
>     > windup-dev mailing list
>     > windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>     > https://lists.jboss.org/mailman/listinfo/windup-dev
>
>     _______________________________________________
>     windup-dev mailing list
>     windup-dev at lists.jboss.org <mailto:windup-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/windup-dev
>
>
>
>
> -- 
> Lincoln Baxter, III
> http://ocpsoft.org
> "Simpler is better."
>
>
> _______________________________________________
> windup-dev mailing list
> windup-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/windup-dev/attachments/20140626/5610e136/attachment.html