dokuwiki-plugin-struct
dokuwiki-plugin-struct copied to clipboard
cosmocode
Search in lookup / page data?
Searching for data in lookup / page does not work with the dokuwiki search field. Is there some alternative way to search for data with struct?
As mentioned in #322 searching for data attached to a page (via a pageschema) is already implemented. I'm not sure how searching for lookup data could/should be integrated. Would that even make sense?
Our usecase: We manage a list of software packages in a lookup schema on a private page in the "IT" section of the wiki. For the users we show some of the columns of this software database on a "public" page. Many users don't find a specific software, because they use the global site search to look for a software package. Having this data searchable would make very much sense in our case, but I also see the not-so-trivial implications....
For the described usecase I would expect that the dokuwiki search takes into account the contents of struct's aggregation table as it is visible on the public pages. That is, not just searching the raw page source. Thus, just the publicly visible information is searched.
But how does this interact with pagination and modifications in the struct database?
For the described usecase I would expect that the dokuwiki search takes into account the contents of struct's aggregation table as it is visible on the public pages. That is, not just searching the raw page source. Thus, just the publicly visible information is searched.
exactly
Can we contribute more information for the needed discussion? What information would be needed?
In contrast to page schemes, lookup (aggregations) are page-independent. In your case, you want to bind such data back to pages. In my opinion, this is illogical, and certainly not desirable in many other use cases.
A clean implementation would also be complex and performance hungry:
- For the search index, after every change in a lookup scheme, all pages that use this scheme would have to be re-rendered.
- With a full-text search, all lookup queries would have to be carried out each time.
- The limits would have to be ignored in both cases, so that all data records are taken into account, and not just those of the first hit page.
In contrast to page schemes, aggregations are page-independent. In your case, you want to bind such data back to pages. In my opinion, this is illogical, and certainly not desirable in many other use cases.
We pages with overview tables which aggregates the page schemas of complete namespaces in tabular form (services, hosts). I'd like these pages to be returned when I search for a string which appears in the aggregations. That doesn't seem illogical to me :-). From a user's point of view, these are just regular wiki pages/tables.
I understand it is not simple to implement, but I was referring to the "discussion needed" tag of this soon three year old issue. I would also accept (have to accept) a "no", but currently there is no decision at all.
I'm not the one who decides. I just wanted to express my opinion and have given my argument for it. Important: My arguments only related to lookup schemes. I emphasized this more clearly in my post. For page schemes I am completely with you.
Let's ignore the lookup use case for a second.
Let me see if I understand the page context correctly. You have pages computer:a and computer:b which both have a field ip address. And you have a page network where you aggregate all computers and their IP addresses:
| Computer | IP Address |
|---|---|
| a | 192.168.1.1 |
| b | 192.168.1.2 |
And now you expect users to find the network page instead of computer:a when searching for 192.168.1.1? To me that doesn't make much sense.
Lookup schemas are somewhat more complicated as @moz0817 pointed out.
But first of all I would like to discuss if it makes sense to index the result of an aggregation instead (or in addition to) the source of the aggregated data.
Oh also aggregations on page data are dependent on the ACLs for the current user for the referenced pages - we probably can not index aggregation results without starting to leak information from protected pages.
Not instead, but in addition to. Finding the pages computer:a and computer:balready works and from user's perspective it is not understandable - but I absolutely recognize the complexity of a possible implementation - why network isn't also returned in the search.
Our specific use case is maybe somewhat special in that computer:a and computer:b are internal pages to the IT department and not accessible by the other users (they contain additional, sensible information), while network is a public page. Hence network is the only place where users can find this information. But - answering your ACL comment - I must admit, that to allow that, I am patching the plugin code manually after each upgrade. See also the related issue #321. Only the struct data is publicly viewable, not the page content itself.
Yes, you might see this as an edge or very special case. But for me it was one of the primary reasons to introduce the struct plugin. We have several such aggregations and they constitute some of the most important public information in our Wiki.
(I still think that it would be nice to have #321 implemented, maybe on a per-schema basis :-)
I'm afraid to have an uggly idea, so I will introduce it shortly to avoid you loss of time: May it be possible to have a mechanism that will convert struct table content into kind of "static text" into pages to make it searchable?
-
This mechanism would be applied on explicit demand / button-click action.
-
This mechanism can be applied on page edition directly (with a tick box near Save button): once page edition having"struct table" query is saved, the page source is enriched by the addition of the data converted into text, and the "struct table" query put into double "~" like a MACRO to be stored but not used.
-
This mechanism can be applied also on data edition even by a raw and slow process after clicking on "apply into pages" button (querying all pages having concerned struct table query into it).
[I'm absolutely unaware of the implications on the ACL side]
My use case is a lookup schema called "models" for template documents linked to one or more "themes". Depending on wiki pages, I filter the displayed models with the theme of the page "Human resources" / "External communication" ... Currently, searching for "CV" will not provide any result although "Human resources" page, listing this model, exists.
Hi, I have the same issue... Don't know if you finally found a solution for this.
Eventually, wouldn't it be possible to add attributes to the generated html page so that javascript would allow us to perform searches ?
