9:58 p.m.
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.
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
11:19 p.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
1:04 a.m.
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)
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.
~Lincoln
On Wed, Jun 25, 2014 at 12:19 AM, Ondrej Zizka <ozizka(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list
windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
--
Lincoln Baxter, III
http://ocpsoft.org
"Simpler is better."
8:39 p.m.
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(a)redhat.com
<mailto:ozizka@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(a)lists.jboss.org <mailto:windup-dev@lists.jboss.org>
> https://lists.jboss.org/mailman/listinfo/windup-dev
_______________________________________________
windup-dev mailing list
windup-dev(a)lists.jboss.org <mailto:windup-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
9:20 p.m.
It seems that the interface could be reduced from
public interface IterationSelectionManager {
Iterable<WindupVertexFrame> getFrames(GraphRewrite event, VarStack
varStack);
}
to just
public interface FramesSelector {
Iterable<WindupVertexFrame> getFrames();
}
Because:
1) Has not much to do with iteration
2) the stack and the event do not necessarily have to be needed /
available at the time of calling getFrames(),
3) event is used just to get the context, which may be set in impl's
constructor (or injected?),
4) The variables stack should be accessible from the context, i.e.
somehow from the event. and if not, 3) applies here too.
WDYT?
Ondra
On 26.6.2014 03:39, Ondrej Zizka wrote:
On 25.6.2014 08:04, Lincoln Baxter, III wrote:
> 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?
4:09 p.m.
Let's move this discussion to
https://issues.jboss.org/browse/WINDUP-97?jql=project%20%3D%20WINDUP
Ondra
On 26.6.2014 04:20, Ondrej Zizka wrote:
It seems that the interface could be reduced from
public interface IterationSelectionManager {
Iterable<WindupVertexFrame> getFrames(GraphRewrite event, VarStack
varStack);
}
to just
public interface FramesSelector {
Iterable<WindupVertexFrame> getFrames();
}
Because:
1) Has not much to do with iteration
2) the stack and the event do not necessarily have to be needed /
available at the time of calling getFrames(),
3) event is used just to get the context, which may be set in impl's
constructor (or injected?),
4) The variables stack should be accessible from the context, i.e.
somehow from the event. and if not, 3) applies here too.
WDYT?
Ondra
On 26.6.2014 03:39, Ondrej Zizka wrote:
> On 25.6.2014 08:04, Lincoln Baxter, III wrote:
>> 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?
_______________________________________________
windup-dev mailing list
windup-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/windup-dev
3836
days inactive
3837
days old
5 comments
2 participants
participants (2)
-
Lincoln Baxter, III -
Ondrej Zizka