30 Aug
2008
30 Aug
'08
10:37 p.m.
Hi, Vincent.
Vincent Massol wrote:
I'd say it perfect for tasks like this (language preprocessors).
Look at
http://svn.xwiki.org/svnroot/xwiki/sandbox/xwiki-query/jpql-parser/src/main…
It contain no code, only EBNF with name labels.
And it generates a good AST and visitors for hook and rewrite some
interesting places with save all remain input.
This is hard to do in other parser generators.
It also have CST to AST feature for generate some custom AST, like other
parsers do.
According to use different parsers, SableCC and xwql has no affect on
other modules. SableCC has no runtime dependency (in contrast of antlr).
So I think it is ok for use SableCC for xwql.
I agree that antlr is most powerful.
But it requires much more hand work. (create and generate AST)
PS: Also, SableCC is LALR(k) parser, means it is more powerful in
grammar sense than LL(k) without lookahead.
"doc.XWiki.Class as obj" has the same sense as "object.list as
listitem"
in JPQL.
'XWiki.Class' is a part of document. It is not a single field, but a
virtual collection.
But I agree, there is conflict possible with objects and other parts of
document (attachments, class) so we need some prefix.
And you variant is quite good. It eliminates the problems with special
chars in document names.
so +1 to doc.objects(XWiki.Class).
"" is not needed IMO. Parser can take care of special chars in this case
too, i think.
WDOT?
PS: another variant:
from Document as doc, doc.objects as obj where obj.class='XWiki.Class'
more universal, but less readable and hierarchical.
I would like
to discuss about the new xwiki query language.
http://dev.xwiki.org/xwiki/bin/view/Design/XWikiQueryLanguage
We need to choose a syntax and data model of the query language
There are some examples in
http://dev.xwiki.org/xwiki/bin/view/Design/XWiki+Query+Language+Specificati…
I already have a prototype based on my JPQL parser (SableCC based
Is that a good parser generator? I know JavaCC and Antlr but have
never used SableCC. I'm just worried about us having different parser
generators so if we choose one we should try to continue using it
across our modules as much as possible. Right now my preference would
go to javacc or antlr since they're more well known. Ideally antlr is
by far the most powerful but I think it may also be the most complex
to use unfortunately. example:
"select doc.fullName
from Document as doc, doc.XWiki.XWikiUsers as user
where user.email like '%xwiki.com' and doc.author=:username"
"select doc.fullName from Document as doc" may be omitted. It will be
added if there is no Document in query statement. So "from
doc.XWiki.XWikiUsers as user" is correct query statement.
I don't like the mix of semantics between doc.fullName for example
(which represents a property of a document - a field in the DB) and
doc.XWiki.XWikiUsers which represents an object of a document. I don't
think they should be at the same level and the usage of "." in the
object name is confusing (and may also confuse the parser).
I'd prefer something like: doc.objects(XWiki.XWikiUsers) or
doc.objects("XWiki.XWikiUsers").
Then we can add: doc.attachment(attachmentName) and doc.class later on.
WDYT? > ...
--
Artem Melentyev