5 Sep
2008
5 Sep
'08
1:17 a.m.
Hi devs,
The first proposal is about introducing two $xwiki.countDocuments
methods, one that accepts a simple hql query, and one that accepts a
parametrized query and a list of parameter values. These work like
searchDocuments, but instead of prefixing the query fragment with
'select doc.fullName from XWikiDocument as doc', it will prefix it with
'select count(*) from XWikiDOcument as doc'.
This will allow to count documents without using a programming-protected
query, and without retrieving all the documents and count the results.
Such a method is needed for paging results, for example.
The second proposal is a temporary hack for hiding documents. The idea
is to add a new field in the XWikiDocument class, 'hidden', which will
be automatically used in searchDocuments and countDocuments to filter
out special documents. This is a workaround until we will be able to tag
special documents or spaces, and will allow to create special documents
needed for an application inside the main application's space, instead
of the generic XWiki space. Such hidden pages won't appear in normal
search results, the index page or the navigation panel.
To show these documents (for admins, for example) we could add another
searchDocuments method which accepts a boolean parameter that enables or
disables the filter on the 'hidden' property.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
5 Sep
5 Sep
10:52 a.m.
New subject: [xwiki-devs] [proposal] Add countDocuments API method, add 'hidden' document property
Sergiu Dumitriu wrote:
Hi devs,
The first proposal is about introducing two $xwiki.countDocuments
methods, one that accepts a simple hql query, and one that accepts a
parametrized query and a list of parameter values. These work like
searchDocuments, but instead of prefixing the query fragment with
'select doc.fullName from XWikiDocument as doc', it will prefix it with
'select count(*) from XWikiDOcument as doc'.
This will allow to count documents without using a programming-protected
query, and without retrieving all the documents and count the results.
Such a method is needed for paging results, for example.
Definitely +1
The second proposal is a temporary hack for hiding documents. The idea
is to add a new field in the XWikiDocument class, 'hidden', which will
be automatically used in searchDocuments and countDocuments to filter
out special documents. This is a workaround until we will be able to tag
special documents or spaces, and will allow to create special documents
needed for an application inside the main application's space, instead
of the generic XWiki space. Such hidden pages won't appear in normal
search results, the index page or the navigation panel.
To show these documents (for admins, for example) we could add another
searchDocuments method which accepts a boolean parameter that enables or
disables the filter on the 'hidden' property.
+1 too
Jerome.
11:39 a.m.
On Fri, Sep 5, 2008 at 1:17 AM, Sergiu Dumitriu <sergiu(a)xwiki.com> wrote:
Hi devs,
The first proposal is about introducing two $xwiki.countDocuments
methods, one that accepts a simple hql query, and one that accepts a
parametrized query and a list of parameter values. These work like
searchDocuments, but instead of prefixing the query fragment with
'select doc.fullName from XWikiDocument as doc', it will prefix it with
'select count(*) from XWikiDOcument as doc'.
This will allow to count documents without using a programming-protected
query, and without retrieving all the documents and count the results.
Such a method is needed for paging results, for example.
+1, a very common need indeed.
The second proposal is a temporary hack for hiding
documents. The idea
is to add a new field in the XWikiDocument class, 'hidden', which will
be automatically used in searchDocuments and countDocuments to filter
out special documents. This is a workaround until we will be able to tag
special documents or spaces, and will allow to create special documents
needed for an application inside the main application's space, instead
of the generic XWiki space. Such hidden pages won't appear in normal
search results, the index page or the navigation panel.
+1.
You're talking about a temporary hack, do you have in mind any better
solution with our current model or are you refering to a new "system"
tagging feature that we could implement in the future model component
?
FYI I was planning to implement this and hidden spaces (as a
XWikiPreferences property, yep this one is a hack ;) in 1.7.
To show these documents (for admins, for example) we
could add another
searchDocuments method which accepts a boolean parameter that enables or
disables the filter on the 'hidden' property.
+1.
JV.
10 Sep
10 Sep
9:43 a.m.
New subject: [xwiki-devs] [proposal] Add countDocuments API method, add 'hidden' document property
Jean-Vincent Drean wrote:
On Fri, Sep 5, 2008 at 1:17 AM, Sergiu Dumitriu
<sergiu(a)xwiki.com> wrote:
A new system for the model component. It was discussed some time ago on
the list, the special meta tags that could be used to describe anything
about a document. See http://markmail.org/message/hwpigum6fc5ojdsw
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
The second proposal is a temporary hack for
hiding documents. The idea
is to add a new field in the XWikiDocument class, 'hidden', which will
be automatically used in searchDocuments and countDocuments to filter
out special documents. This is a workaround until we will be able to tag
special documents or spaces, and will allow to create special documents
needed for an application inside the main application's space, instead
of the generic XWiki space. Such hidden pages won't appear in normal
search results, the index page or the navigation panel.
+1.
You're talking about a temporary hack, do you have in mind any better
solution with our current model or are you refering to a new "system"
tagging feature that we could implement in the future model component
? 
5 Sep
5 Sep
11:58 a.m.
Hi Sergiu,
On Sep 5, 2008, at 1:17 AM, Sergiu Dumitriu wrote:
Hi devs,
The first proposal is about introducing two $xwiki.countDocuments
methods, one that accepts a simple hql query, and one that accepts a
parametrized query and a list of parameter values. These work like
searchDocuments, but instead of prefixing the query fragment with
'select doc.fullName from XWikiDocument as doc', it will prefix it
with
'select count(*) from XWikiDOcument as doc'.
This will allow to count documents without using a programming-
protected
query, and without retrieving all the documents and count the results.
Such a method is needed for paging results, for example.
Sounds good to me.
Artem, how will this be done with the Query manager?
The second proposal is a temporary hack for hiding
documents. The idea
is to add a new field in the XWikiDocument class, 'hidden', which will
be automatically used in searchDocuments and countDocuments to filter
out special documents. This is a workaround until we will be able to
tag
special documents or spaces, and will allow to create special
documents
needed for an application inside the main application's space, instead
of the generic XWiki space. Such hidden pages won't appear in normal
search results, the index page or the navigation panel.
-0 (close to -1) till you explain what is wrong with the solution
below :)
This could also be implemented using a special Tag (like:
"xwiki:hidden" for example).
I was going to say: "In general I think we need the ability to add
generic metadata to a document.". however this already exists: it's
called Objects! :)
So I think instead of adding more and more fixed metadata we might
instead want to use Objects. Either reuse the existing Tag or create a
new Visibility class/objects.
What are the cons of using Objects for this feature?
To show these documents (for admins, for example) we
could add another
searchDocuments method which accepts a boolean parameter that
enables or
disables the filter on the 'hidden' property.
If we use an Object then we don't need to add a new API since we
already have all the required APIs for manipulating objects.
Thanks
-Vincent
11:05 a.m.
New subject: [xwiki-devs] [proposal] Add countDocuments API method, add 'hidden' document property
Vincent Massol wrote:
Hi Sergiu,
On Sep 5, 2008, at 1:17 AM, Sergiu Dumitriu wrote:
Using existing Tag object is not the best solution IMHO, since it
implies filtering out those "technical" tags everywhere we query tags. A
new object would not interfere with existing code.
Jerome.
Hi devs,
The first proposal is about introducing two $xwiki.countDocuments
methods, one that accepts a simple hql query, and one that accepts a
parametrized query and a list of parameter values. These work like
searchDocuments, but instead of prefixing the query fragment with
'select doc.fullName from XWikiDocument as doc', it will prefix it
with
'select count(*) from XWikiDOcument as doc'.
This will allow to count documents without using a programming-
protected
query, and without retrieving all the documents and count the results.
Such a method is needed for paging results, for example.
Sounds good to me.
Artem, how will this be done with the Query manager?
The second proposal is a temporary hack for
hiding documents. The idea
is to add a new field in the XWikiDocument class, 'hidden', which will
be automatically used in searchDocuments and countDocuments to filter
out special documents. This is a workaround until we will be able to
tag
special documents or spaces, and will allow to create special
documents
needed for an application inside the main application's space, instead
of the generic XWiki space. Such hidden pages won't appear in normal
search results, the index page or the navigation panel.
-0 (close to -1) till you explain what is wrong with the solution
below :)
This could also be implemented using a special Tag (like:
"xwiki:hidden" for example).
I was going to say: "In general I think we need the ability to add
generic metadata to a document.". however this already exists: it's
called Objects! :)
So I think instead of adding more and more fixed metadata we might
instead want to use Objects. Either reuse the existing Tag or create a
new Visibility class/objects.
What are the cons of using Objects for this feature?
To show these documents (for admins, for example)
we could add another
searchDocuments method which accepts a boolean parameter that
enables or
disables the filter on the 'hidden' property.
If we use an Object then we don't need to add a new API since we
already have all the required APIs for manipulating objects.
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
12:21 p.m.
On Sep 5, 2008, at 11:05 AM, Jerome Velociter wrote:
Vincent Massol wrote:
Yes, I agree with you but not for the same reason. I agree because we
don't have permissions on tag values so a normal users would be
allowed to modify a technical tag that maybe should only be changed by
admins.
BTW even using a different objects, it would be ideal if the
modification of the "Visibility" object be restricted to some users
with appropriate rights but I don't think we have rights on objects
modifications yet, do we?
In any case I'm still in favor of using Objects even if we don't have
these permissions but they should be added later on.
Thanks
-Vincent
Hi Sergiu,
On Sep 5, 2008, at 1:17 AM, Sergiu Dumitriu wrote:
Using existing Tag object is not the best solution IMHO, since it
implies filtering out those "technical" tags everywhere we query tags. Hi devs,
The first proposal is about introducing two $xwiki.countDocuments
methods, one that accepts a simple hql query, and one that accepts a
parametrized query and a list of parameter values. These work like
searchDocuments, but instead of prefixing the query fragment with
'select doc.fullName from XWikiDocument as doc', it will prefix it
with
'select count(*) from XWikiDOcument as doc'.
This will allow to count documents without using a programming-
protected
query, and without retrieving all the documents and count the
results.
Such a method is needed for paging results, for example.
Sounds good to me.
Artem, how will this be done with the Query manager?
The second proposal is a temporary hack for
hiding documents. The
idea
is to add a new field in the XWikiDocument class, 'hidden', which
will
be automatically used in searchDocuments and countDocuments to
filter
out special documents. This is a workaround until we will be able to
tag
special documents or spaces, and will allow to create special
documents
needed for an application inside the main application's space,
instead
of the generic XWiki space. Such hidden pages won't appear in normal
search results, the index page or the navigation panel.
-0 (close to -1) till you explain what is wrong with the solution
below :)
This could also be implemented using a special Tag (like:
"xwiki:hidden" for example).
I was going to say: "In general I think we need the ability to add
generic metadata to a document.". however this already exists: it's
called Objects! :)
So I think instead of adding more and more fixed metadata we might
instead want to use Objects. Either reuse the existing Tag or
create a
new Visibility class/objects.
What are the cons of using Objects for this feature?
A
new object would not interfere with existing code.
Jerome.
>
>> To show these documents (for admins, for example) we could add
>> another
>> searchDocuments method which accepts a boolean parameter that
>> enables or
>> disables the filter on the 'hidden' property.
>>
>
> If we use an Object then we don't need to add a new API since we
> already have all the required APIs for manipulating objects.
>
> Thanks
> -Vincent
12:29 p.m.
On Fri, Sep 5, 2008 at 12:21 PM, Vincent Massol <vincent(a)massol.net> wrote:
Yes, I agree with you but not for the same reason. I agree because we
don't have permissions on tag values so a normal users would be
allowed to modify a technical tag that maybe should only be changed by
admins.
BTW even using a different objects, it would be ideal if the
modification of the "Visibility" object be restricted to some users
with appropriate rights but I don't think we have rights on objects
modifications yet, do we?
We don't (comments is an exception an it's only about addition and not
modification I think).
--
Jean-Vincent Drean
12:08 p.m.
On Fri, Sep 5, 2008 at 11:58 AM, Vincent Massol <vincent(a)massol.net> wrote:
At first sight I'd say that using objects (including current tag
feature) would lead to complex queries.
--
Jean-Vincent Drean
The second
proposal is a temporary hack for hiding documents. The idea
is to add a new field in the XWikiDocument class, 'hidden', which will
be automatically used in searchDocuments and countDocuments to filter
out special documents. This is a workaround until we will be able to
tag
special documents or spaces, and will allow to create special
documents
needed for an application inside the main application's space, instead
of the generic XWiki space. Such hidden pages won't appear in normal
search results, the index page or the navigation panel.
-0 (close to -1) till you explain what is wrong with the solution
below :)
This could also be implemented using a special Tag (like:
"xwiki:hidden" for example).
I was going to say: "In general I think we need the ability to add
generic metadata to a document.". however this already exists: it's
called Objects! :)
So I think instead of adding more and more fixed metadata we might
instead want to use Objects. Either reuse the existing Tag or create a
new Visibility class/objects.
What are the cons of using Objects for this feature?
12:17 p.m.
On Sep 5, 2008, at 12:08 PM, Jean-Vincent Drean wrote:
On Fri, Sep 5, 2008 at 11:58 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
At first sight I'd say that using objects (including current tag
feature) would lead to complex queries.
Yes but that's an API problem not a design one.
If our API makes it complex to do queries on objects then we should
fix it. Not do workarounds! Because if we do this then we acknowledge
that the whole foundation of XWiki is bad (i.e. Class/Objects don't
work). That would be a shame :)
Thanks
-Vincent
The
second proposal is a temporary hack for hiding documents. The
idea
is to add a new field in the XWikiDocument class, 'hidden', which
will
be automatically used in searchDocuments and countDocuments to
filter
out special documents. This is a workaround until we will be able to
tag
special documents or spaces, and will allow to create special
documents
needed for an application inside the main application's space,
instead
of the generic XWiki space. Such hidden pages won't appear in normal
search results, the index page or the navigation panel.
-0 (close to -1) till you explain what is wrong with the solution
below :)
This could also be implemented using a special Tag (like:
"xwiki:hidden" for example).
I was going to say: "In general I think we need the ability to add
generic metadata to a document.". however this already exists: it's
called Objects! :)
So I think instead of adding more and more fixed metadata we might
instead want to use Objects. Either reuse the existing Tag or
create a
new Visibility class/objects.
What are the cons of using Objects for this feature?
12:22 p.m.
On Fri, Sep 5, 2008 at 12:17 PM, Vincent Massol <vincent(a)massol.net> wrote:
I was thinking about performance too, I've added "at first sight"
because I'm not sure it would be noticeable.
JV.
At first sight I'd say that using objects (including current tag
feature) would lead to complex queries.
Yes but that's an API problem not a design one.
If our API makes it complex to do queries on objects then we should
fix it. Not do workarounds! Because if we do this then we acknowledge
that the whole foundation of XWiki is bad (i.e. Class/Objects don't
work). That would be a shame :)
12:30 p.m.
On Sep 5, 2008, at 12:22 PM, Jean-Vincent Drean wrote:
On Fri, Sep 5, 2008 at 12:17 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
I was thinking about performance too, I've added "at first sight"
because I'm not sure it would be noticeable.
Same comment as above... :)
We should check this since querying objects shouldn't cause any
performance hit or we'll have problems since xwiki is all about adding
objects.
But at least do we agree that the way to add metadata to document is
by using objects?
Question: I've also added a syntaxId field in XWikiDocument a while
back to support the different syntaxes. That should also be a good
candidate for an Object.
I think all that's left to do is clarify the relationship between
Objects and XWiki core (i.e. Objects used by xwiki core):
- should they be created automatically by xwiki core if they don't
exist (class + object),
- should they not be created by have default values configured in
xwiki's configuration
- should they be created on first query if not found?
Thanks
-Vincent
At first sight I'd say that using objects (including current tag
feature) would lead to complex queries.
Yes but that's an API problem not a design one.
If our API makes it complex to do queries on objects then we should
fix it. Not do workarounds! Because if we do this then we
acknowledge
that the whole foundation of XWiki is bad (i.e. Class/Objects don't
work). That would be a shame :)
12:36 p.m.
New subject: [xwiki-devs] XWiki and Objects (was Re: [proposal] Add countDocuments API method, add 'hidden' document property)
On Sep 5, 2008, at 12:30 PM, Vincent Massol wrote:
On Sep 5, 2008, at 12:22 PM, Jean-Vincent Drean wrote:
Note that if it were an object we would be able to use the object
viewer/editor to modify it's values. I think this would require a UI
change so that modifying objects could be done easily in edit mode (in
a panel on the right).
If we had this then maybe the notion of Language and Parent could be
reimplemented as Objects too.
So do we want to go in the full direction of Objects. I think it would
make a lot of sense and would lead to some very homogeneous design.
Now are there any drawbacks? So far I've heard those that I think are
fixable:
- performance hit
- complex queries
- no permissions on objects
Any others?
Thanks
-Vincent
On Fri, Sep 5, 2008 at 12:17 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
I was thinking about performance too, I've added "at first sight"
because I'm not sure it would be noticeable.
Same comment as above... :)
We should check this since querying objects shouldn't cause any
performance hit or we'll have problems since xwiki is all about adding
objects.
But at least do we agree that the way to add metadata to document is
by using objects?
Question: I've also added a syntaxId field in XWikiDocument a while
back to support the different syntaxes. That should also be a good
candidate for an Object.
At first sight I'd say that using objects (including current tag
feature) would lead to complex queries.
Yes but that's an API problem not a design one.
If our API makes it complex to do queries on objects then we should
fix it. Not do workarounds! Because if we do this then we
acknowledge
that the whole foundation of XWiki is bad (i.e. Class/Objects don't
work). That would be a shame :)
I think all that's left to do is clarify the relationship between
Objects and XWiki core (i.e. Objects used by xwiki core):
- should they be created automatically by xwiki core if they don't
exist (class + object),
- should they not be created by have default values configured in
xwiki's configuration
- should they be created on first query if not found?
Thanks
-Vincent
1 p.m.
New subject: [xwiki-devs] XWiki and Objects (was Re: [proposal] Add countDocuments API method, add 'hidden' document property)
I would definitely be in favor of objects too, just need to look
carefully on performance issues but I don't see any problem I can
think of right now.
On Fri, Sep 5, 2008 at 12:36 PM, Vincent Massol <vincent(a)massol.net> wrote:
On Sep 5, 2008, at 12:30 PM, Vincent Massol wrote:
--
Thomas Mortagne
On Sep 5, 2008, at 12:22 PM, Jean-Vincent Drean wrote:
Note that if it were an object we would be able to use the object
viewer/editor to modify it's values. I think this would require a UI
change so that modifying objects could be done easily in edit mode (in
a panel on the right).
If we had this then maybe the notion of Language and Parent could be
reimplemented as Objects too.
So do we want to go in the full direction of Objects. I think it would
make a lot of sense and would lead to some very homogeneous design.
Now are there any drawbacks? So far I've heard those that I think are
fixable:
- performance hit
- complex queries
- no permissions on objects
Any others?
Thanks
-Vincent
On Fri, Sep 5, 2008 at 12:17 PM, Vincent Massol
<vincent(a)massol.net>
wrote:
Same comment as above... :)
We should check this since querying objects shouldn't cause any
performance hit or we'll have problems since xwiki is all about adding
objects.
But at least do we agree that the way to add metadata to document is
by using objects?
Question: I've also added a syntaxId field in XWikiDocument a while
back to support the different syntaxes. That should also be a good
candidate for an Object. >
> At first sight I'd say that using objects (including current tag
> feature) would lead to complex queries.
Yes but that's an API problem not a design one.
If our API makes it complex to do queries on objects then we should
fix it. Not do workarounds! Because if we do this then we
acknowledge
that the whole foundation of XWiki is bad (i.e. Class/Objects don't
work). That would be a shame :)
I was thinking about performance too, I've added "at first sight"
because I'm not sure it would be noticeable.
I think all that's left to do is clarify the relationship between
Objects and XWiki core (i.e. Objects used by xwiki core):
- should they be created automatically by xwiki core if they don't
exist (class + object),
- should they not be created by have default values configured in
xwiki's configuration
- should they be created on first query if not found?
Thanks
-Vincent
_______________________________________________
devs mailing list
devs(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/devs
7 Sep
7 Sep
3:16 a.m.
New subject: [xwiki-devs] [proposal] Add countDocuments API method, add 'hidden' document property
Vincent Massol wrote:
On Sep 5, 2008, at 12:08 PM, Jean-Vincent Drean
wrote:
New XWiki Query Language is targets this problem.
There is easy to query objects on xwql.
example:
If XWiki.Hidden is just a document flag:
"from Document as doc, doc.object(XWiki.Hidden) as h"
If not:
"from Document as doc left join doc.object(XWiki.Visibility) as v
where v is null or v.hidden=false"
We can also introduce special syntax "doc.object?(XWiki.Visibility)" for
left joins:
"from Document as doc, doc.object?(XWiki.Visibility) as v
where v is null or v.hidden=false"
or even:
"where doc.object?(XWiki.Visibility).hidden=false"
--
Artem Melentyev
On Fri, Sep 5, 2008 at 11:58 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
At first sight I'd say that using objects (including current tag
feature) would lead to complex queries.
Yes but that's an API problem not a design one.
If our API makes it complex to do queries on objects then we should
fix it. Not do workarounds! Because if we do this then we acknowledge
that the whole foundation of XWiki is bad (i.e. Class/Objects don't
work). That would be a shame :) The
second proposal is a temporary hack for hiding documents. The
idea
is to add a new field in the XWikiDocument class, 'hidden', which
will
be automatically used in searchDocuments and countDocuments to
filter
out special documents. This is a workaround until we will be able to
tag
special documents or spaces, and will allow to create special
documents
needed for an application inside the main application's space,
instead
of the generic XWiki space. Such hidden pages won't appear in normal
search results, the index page or the navigation panel.
-0 (close to -1) till you
explain what is wrong with the solution
below :)
This could also be implemented using a special Tag (like:
"xwiki:hidden" for example).
I was going to say: "In general I think we need the ability to add
generic metadata to a document.". however this already exists: it's
called Objects! :)
So I think instead of adding more and more fixed metadata we might
instead want to use Objects. Either reuse the existing Tag or
create a
new Visibility class/objects.
What are the cons of using Objects for this feature?
9:50 a.m.
On Sep 7, 2008, at 3:16 AM, Artem Melentyev wrote:
Vincent Massol wrote:
Yes I think it would be nice if our query language supported
manipulating properties directly at the syntax level.
I like the notation: doc.object(MyObject).myproperty
Thanks
-Vincent
On Sep 5, 2008, at 12:08 PM, Jean-Vincent Drean
wrote:
New XWiki Query Language is targets this problem.
There is easy to query objects on xwql.
example:
If XWiki.Hidden is just a document flag:
"from Document as doc, doc.object(XWiki.Hidden) as h"
If not:
"from Document as doc left join doc.object(XWiki.Visibility) as v
where v is null or v.hidden=false"
We can also introduce special syntax "doc.object?(XWiki.Visibility)"
for
left joins:
"from Document as doc, doc.object?(XWiki.Visibility) as v
where v is null or v.hidden=false"
or even:
"where doc.object?(XWiki.Visibility).hidden=false" On Fri, Sep 5, 2008 at 11:58 AM, Vincent Massol
<vincent(a)massol.net>
wrote:
Yes but that's an API problem not a design one.
If our API makes it complex to do queries on objects then we should
fix it. Not do workarounds! Because if we do this then we
acknowledge
that the whole foundation of XWiki is bad (i.e. Class/Objects don't
work). That would be a shame :) > The second proposal is a temporary hack for
hiding documents. The
> idea
> is to add a new field in the XWikiDocument class, 'hidden', which
> will
> be automatically used in searchDocuments and countDocuments to
> filter
> out special documents. This is a workaround until we will be
> able to
> tag
> special documents or spaces, and will allow to create special
> documents
> needed for an application inside the main application's space,
> instead
> of the generic XWiki space. Such hidden pages won't appear in
> normal
> search results, the index page or the navigation panel.
-0 (close to -1) till you explain what is wrong with the solution
below :)
This could also be implemented using a special Tag (like:
"xwiki:hidden" for example).
I was going to say: "In general I think we need the ability to add
generic metadata to a document.". however this already exists: it's
called Objects! :)
So I think instead of adding more and more fixed metadata we might
instead want to use Objects. Either reuse the existing Tag or
create a
new Visibility class/objects.
What are the cons of using Objects for this feature?
At first sight I'd say that using objects (including current tag
feature) would lead to complex queries.
2:37 a.m.
New subject: [xwiki-devs] [proposal] Add countDocuments API method, add 'hidden' document property
Vincent Massol wrote:
getQueryManager().createQuery(anyhqlstatement, Query.HQL)
.bindValues(list).execute()
The only problem is positional parameters is not implemented (so there
is no bindValues(list) :) ).
There is no positional parameters in JCRv2 (only named) (and there is no
query parameters at all in JCRv1).
I thought we can emulate positional parameters via named. For example
write ":p1" instead of "?1" (":1" is incorrect named
parameter for many
jpql parsers). But it looks some weird and restrictive.
So I think we should support positional parameters in our Query
interface. Positional parameters will be handled by hibernate in
HibernateStore and will be emulated via named parameters in JCRStore.
I'll implement it. http://jira.xwiki.org/jira/browse/XWIKI-2641
about countDocuments:
+1
I think we should move all $xwiki.search* functions including this to
"$services.query." velocity bridge and use the new XWQL as a language
for it, but later, in 1.7.
-0. I agree with Vincent.
The first
proposal is about introducing two $xwiki.countDocuments
methods, one that accepts a simple hql query, and one that accepts a
parametrized query and a list of parameter values. These work like
searchDocuments, but instead of prefixing the query fragment with
'select doc.fullName from XWikiDocument as doc', it will prefix it
with
'select count(*) from XWikiDOcument as doc'.
This will allow to count documents without using a programming-
protected
query, and without retrieving all the documents and count the results.
Such a method is needed for paging results, for example.
Sounds good to me.
Artem, how will this be done with the Query manager? The second
proposal is a temporary hack for hiding documents. The idea
is to add a new field in the XWikiDocument class, 'hidden', which will
be automatically used in searchDocuments and countDocuments to filter
out special documents. This is a workaround until we will be able to
tag
special documents or spaces, and will allow to create special
documents
needed for an application inside the main application's space, instead
of the generic XWiki space. Such hidden pages won't appear in normal
search results, the index page or the navigation panel.
-0 (close to -1) till you explain what is wrong with the solution
below :) This could also be implemented using a special Tag
(like:
"xwiki:hidden" for example).
I was going to say: "In general I think we need the ability to add
generic metadata to a document.". however this already exists: it's
called Objects! :)
So I think instead of adding more and more fixed metadata we might
instead want to use Objects. Either reuse the existing Tag or create a
new Visibility class/objects.
What are the cons of using Objects for this feature?
--
Artem Melentyev
To show these documents (for admins, for example)
we could add another
searchDocuments method which accepts a boolean parameter that
enables or
disables the filter on the 'hidden' property.
If we use an Object then we don't need to add a new API since we
already have all the required APIs for manipulating objects.
8 Sep
8 Sep
8:40 p.m.
New subject: [xwiki-devs] [proposal] Add countDocuments API method, add 'hidden' document property
Vincent Massol wrote:
Hi Sergiu,
On Sep 5, 2008, at 1:17 AM, Sergiu Dumitriu wrote:
-0 (close to -1) till you explain what is wrong with the solution
below :)
This could also be implemented using a special Tag (like:
"xwiki:hidden" for example).
The problem is that we want to leave out the documents that are NOT
hidden, so a query that does that will have to use a subquery (either
NOT EXISTS or NOT IN), which increases the query complexity and
execution time. And, as Jerome said, we'd have to filter this tag when
displaying documents, and, as you said, this setting should not have the
same rights as normal tags.
I was going to say: "In general I think we need
the ability to add
generic metadata to a document.". however this already exists: it's
called Objects! :)
So I think instead of adding more and more fixed metadata we might
instead want to use Objects. Either reuse the existing Tag or create a
new Visibility class/objects.
What are the cons of using Objects for this feature?
Mostly query complexity and execution time, but also the fact that for
the moment this should be a "private" setting that should not be
accessible to normal users. As I said, this is a hack until we'll have
the new model in place. The hack is needed because I don't want to use
the 'XWiki' space for all support documents (macros, templates, style
and others). The extra document metadata field is not such a bad idea
IMHO because it is the least intrusive solution. Yes, I know it is the
most intrusive one (on the implementation level) because it changes lots
of things, but from the users' PoV it is invisible.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
10 Sep
10 Sep
8:24 a.m.
On Sep 8, 2008, at 8:40 PM, Sergiu Dumitriu wrote:
Vincent Massol wrote:
ok, +0 for now knowing it's a hack that we need to fix later on. Would
be good to document it in the javadoc as such.
Thanks
-Vincent
Hi Sergiu,
On Sep 5, 2008, at 1:17 AM, Sergiu Dumitriu wrote:
-0 (close to -1) till you explain what is wrong with the solution
below :)
This could also be implemented using a special Tag (like:
"xwiki:hidden" for example).
The problem is that we want to leave out the documents that are NOT
hidden, so a query that does that will have to use a subquery (either
NOT EXISTS or NOT IN), which increases the query complexity and
execution time. And, as Jerome said, we'd have to filter this tag when
displaying documents, and, as you said, this setting should not have
the
same rights as normal tags.
I was going to say: "In general I think we
need the ability to add
generic metadata to a document.". however this already exists: it's
called Objects! :)
So I think instead of adding more and more fixed metadata we might
instead want to use Objects. Either reuse the existing Tag or
create a
new Visibility class/objects.
What are the cons of using Objects for this feature?
Mostly query complexity and execution time, but also the fact that for
the moment this should be a "private" setting that should not be
accessible to normal users. As I said, this is a hack until we'll have
the new model in place. The hack is needed because I don't want to use
the 'XWiki' space for all support documents (macros, templates, style
and others). The extra document metadata field is not such a bad
idea
IMHO because it is the least intrusive solution. Yes, I know it is the
most intrusive one (on the implementation level) because it changes
lots
of things, but from the users' PoV it is invisible.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
16 Nov
16 Nov
8:18 a.m.
New subject: [xwiki-devs] [proposal] Add countDocuments API method, add 'hidden' document property
Sergiu Dumitriu wrote:
Hi devs,
The first proposal is about introducing two $xwiki.countDocuments
methods, one that accepts a simple hql query, and one that accepts a
parametrized query and a list of parameter values. These work like
searchDocuments, but instead of prefixing the query fragment with
'select doc.fullName from XWikiDocument as doc', it will prefix it with
'select count(*) from XWikiDOcument as doc'.
This will allow to count documents without using a programming-protected
query, and without retrieving all the documents and count the results.
Such a method is needed for paging results, for example.
The second proposal is a temporary hack for hiding documents. The idea
is to add a new field in the XWikiDocument class, 'hidden', which will
be automatically used in searchDocuments and countDocuments to filter
out special documents. This is a workaround until we will be able to tag
special documents or spaces, and will allow to create special documents
needed for an application inside the main application's space, instead
of the generic XWiki space. Such hidden pages won't appear in normal
search results, the index page or the navigation panel.
To show these documents (for admins, for example) we could add another
searchDocuments method which accepts a boolean parameter that enables or
disables the filter on the 'hidden' property.
Since there were no negative votes in the end, I committed both
proposals for the 1.7 release.
--
Sergiu Dumitriu
http://purl.org/net/sergiu/
5879
days inactive
5952
days old
19 comments
6 participants
participants (6)
-
Artem Melentyev -
Jean-Vincent Drean -
Jerome Velociter -
Sergiu Dumitriu -
Thomas Mortagne -
Vincent Massol