Hello @mleduc ,
finally got around to this, I have a couple of comments based on the proposals that were made here (unfortunately, I didn’t check the result in the PR to compare to what was actually implemented).
Naming:
I believe I can llive with records, but I think there is another discussion that we need to have here. The macro is called XObjects and the specs / proposal is talking about displaying XObjects. I didn’t check the implementation, but I suppose the objective, as for the home of the app within minutes, is to display pages that contain at least one object of the specified type. This means that if a page contains 2 objects of the chosen type, there will always be a single row in the table displayed by this macro for that page (with the data of the first object, I suppose).
At least this is how I see the usage of this macro. The display of multiple objects from a page is something that could be added, but later, as a bonus.
Because of this, the macro could also be called “pages” or “documents”, or something similar to the existing macro that lists pages - the one you mentioned on UC5.
As a nitpick: looking at your mockups, I’m not sure the UI should mention “pages”? The only reason we store entries in pages is for technical reasons, but what the user should be interested in is the structured data instead of the container.
actually, @pjeanjean , no, not really, the storage is not only technical. The classes and objects are a method of adding an extra layer of data on a page: a standard page has title, content and attachments list as “properties” (places where data can be stored), a class/object will allow you to add some additional things to those 3 properties, but they shouldn’t be seen as “replacing” the page. Even if we would store the objects differently, it would still be a good idea that that layer of extra data is “tied” to a page, added along with a page, like an “embellishment”, for the things it “inherits” from pages: access rights, history, authorship metadata, placement on the content tree of the wiki, the possibility to store a large rich text (the content), a smaller text that works as an identifier in listings (title) and associated attachments.
To me, I think we’re complicating too much the concept space of XWiki if we’re trying to hide, for all applications, that the entries are pages.
Indeed, some applications may have very specialized objects, for which we don’t want to promote necessarily this embellishment model (a base which is a page + an extra layer), such as diagrams, for example, or tasks. For these needs, I think the applications in question should / could also provide a specialized macro, that would hide away the concept of “page with extra things”.
@mleduc this made me think that we have a filter in the default search for type of object present in a page, and we should ensure to align the vocabulary we use here for the selected class with the vocabulary used there for that facet (as they’re basically select the same pages).
Whether the displayed livedata is editable or not should be a parameter of the macro (I tried to read the design page to understand whether it’s the case, it’s not clear to me).
For the edit options (Q2), 2.1 is perfectly fine, I am -1 for 3, for now at least, and 2.2 should be handled by a proposal that is larger than only this macro. Of course -1 for option 1, that can be a first version, but not the final one.
I know it’s late for these, but for the record.
Anca