GitHub wiki obsolete
by Ondrej Zizka
Hi all,
the github wiki in windup/windup is obsolete. It belongs to windup-legacy.
I'll try to move it there, and I'd like to start writing some info about
the current implementation.
Any tips on how to move? I thought it's a branch, but it's not. And I
don't see any "export wiki" option.
Ondra
12 years
Iterations generalization?
by Ondrej Zizka
I think users will also need to iterate over other sets than frames.
They might get some results from external services, or even just a list
of strings in the rule, e.g. to create 5 datasources hard-coded in their
rule - why not.
We might want to generalize the iteration code. In the future.
WDYT?
Ondra
12 years
XML config -> extension?
by Ondrej Zizka
Hi,
there's a lot of XML config related code in the core.
I suggest to put that to an extension, next to groovy. That's the exact
place it should be.
Ondra
12 years
Iteration*Managers
by Ondrej Zizka
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
12 years
Nested rules alternative?
by Ondrej Zizka
Nested iterations create verbose rules with a lot of boilerplate.
Maybe the iteration could be over tuples of vertices.
Eg. in DiscoverJavaFilesCP, instead of
forEach( windupConf )
...
...
............
.....
forEach( javaFile )
we could query to get
[ { windupConf, javaFile },
{ windupConf, javaFile }
... ]
And iterate over that.
Anyone investigated this? IIRC from the Gremlin tutorial, this is possible.
Ondra
12 years
Indexes
by Ondrej Zizka
Hi,
few things about indexing:
1) We add "archiveEntry" and "type" to the "search" index. Why those two?
2) Should each ruleset and its Model classes have separate index(es)? I
think so - could speed up looking up in different data domains.
3) The docs says the index has to be configured a priori. Where is it
configured?
4) I'll try to make the indexes discovered dynamically from the Model
classes metadata.
Ondra
PS: I don't like non-systemic plural "indices".
12 years
Forge module deps?
by Ondrej Zizka
Hi Lincoln,
could you please go through the dependencies and check if everything is ok,
and explain what are the correct ways to set up the deps?
E.g., there are some forge-addon deps, but not declared as provided.
Also, what to do if some other module only depends on an API? Should it
depend on the whole module?
Isn't it wrong to add the implementation to classpath too?
If it is, should API be a standalone module?
If not, is there a way to limit the exported classes? AS uses
module.xml, can that be used in Forge too?
Not the top priority thing, but I'd like to have this clear, can spare
me of some CL troubles in the future.
Thanks,
Ondra
12 years
Eclipse API
by Ing. Ondrej Zizka
I've looked at the legacy API.
It's based on legacy Windup types tree, namely FileMetadata.
We could replace these subtypes in the existing API with
WindupVertexFrame subtypes.
Or restrict it on FileModel.
This approach could speed up morphing the Eclipse plugin to new Windup.
On the other hand, I belive that we will want the plugin to show also
non-file-based data, so some API like Ian described in WINDUP-91 would
be more appropriate - more general, and detached from the Model types.
Which is good, IMO.
We would need either manual conversion from graph content to that, or,
better, some mechanism for that.
Maybe some annotation based could do the work sufficiently - i.e.
provide some mapping from Frames to that RuleMatch API.
The question is, is the first approach worth creating as intermediate step?
Regads,
Ondra
12 years
SelectionStack?
by Ondrej Zizka
Hi, shouldn't SelectionFactory be renamed to SelectionStack?
12 years
