On Tue, Mar 14, 2017 at 14:41, Vincent Massol <[email protected]> wrote:
> On 14 Mar 2017, at 11:37, Denis Gervalle <[email protected]> wrote: > > On Tue, Mar 14, 2017 at 11:21, Vincent Massol <[email protected]> wrote: > >> On 14 Mar 2017, at 10:55, Denis Gervalle <[email protected]> wrote: >> >> On Tue, Mar 14, 2017 at 9:15, Vincent Massol <[email protected]> wrote: Hi >> Denis, >> >>> On 13 Mar 2017, at 19:21, Denis Gervalle <[email protected]> wrote: >>> >>> Hi Edy, Vincent, >>> Based on your concerns and our findings, I have finally crafts a design >>> document here: >>> http://design.xwiki.org/xwiki/bin/view/Proposal/BlogImprovemultiblogsupport >>> You were right Edy about the need to better support existing sharing of >>> categories and we have therefore improve our proposal in that regard. It >>> now covers mostly all features of the existing blogs like before, with one >>> small difference: the uncategorised posts from other blog spaces than the >>> Blog space will not be displayed outside of that local blog space. >>> After further thought, we noticed that the actual Blog space will be >>> slightly special because it will stay the only blog space to store both >>> blog post and blog categories in the same space. Which has the consequences >>> of having the Categories WebHome and the blog WebHome at the same location. >>> The general intend is to properly slip set of categories and blogs, so that >>> the home of a set of categories display posts from all blog posts using any >>> of the categories of the set, while the home of the blog will display only >>> post of that given blog. For the special Blog.WebHome we have finally >>> decided to do a mix, which is all blog posts using any of the categories in >>> Blog + all posts in Blogs. This is the closest to the actual behaviour and >>> the best compromise in our opinion to move forward. Regarding the >>> categories themselves, these will continue to work as before, and display >>> all blog posts of that particular categories, whatever the blog there are >>> from is. >>> All that said, in this first version, we will not support the creation of >>> new blogs that share a set of categories from the UI. All new blogs will be >>> created with its own set of categories stored in a subspace of the blog >>> space names Categories. >>> I hope the linked design document will respond to all your remaining >>> questions. Don’t hesitate to ask if you still have concerns about the >>> proposed change. >> >> Thanks for this design page and the precision it brings. >> >> FYI I’ve added some questions/comments in annotations on that document. >> >> My main question is how do you configure a new blog to display all blog >> posts using the same categories that it’s using, i.e. to make it behave >> similarly to the Blog.WebHome blog? I was thinking that this could be done >> without UI and by introducing an “aggregate” boolean xproperty in the >> BlogClass (it would be “false” by default). > > You said: > >> Currently the only reason why Blog.WebHome got that special feature is >> because it is mixed with the WebHome of the Blog space categories. In a >> normal situation, the WebHome of the category space will display the >> aggregation except for uncategorised post. Do you really feel there is a >> great value to have uncategorised post of a given blog aggregated with posts >> that use the same categories as that blog ? My feeling is that it looks >> complex and not easy understandable. > > I was not referring only to uncategorised posts. I was talking about a blog > listing all blog posts (even if they come from other blogs) sharing the same > categories. Basically the blog aggregation use case. > So, for categorised posts, you will get them aggregated in the categories > themselves like it is already the case now. And we will keep the “All” link > that will point to the WebHome of the space holding the categories and that > will display all posts sharing that set of categories. What we are unable to > do is finding uncategorised post from blogs that are using that set of > categories to list them as well. And the why is related to the lazy link > between the post and its blog, see my comments on the design page. I’m talking about the home page of blogs, not the Categories home page. Here’s the use case: * I Have blog1 using categoriesA * I have blog2 using categoriesA * When I go to blog1.WebHome I want to see only blog posts from blog1 * When I go to blog2.WeBhome I want to see only blog posts from blog2 This last two cases are what we propose for now. * I create blog3 that uses categoriesA but when I go to blog3.WebHome I want to see all blog posts from all blogs using categoriesA (even uncategorised ones), i.e. all blog posts from blog1, blog2 and blog3 (if any). This last case (apart from the uncategorised ones) is precisely what the categories space WebHome will be, and accessible through the “All” link in the category panel of all three blogs. And the way all blog lists are managed will be through the same BlogPostList macro that will be therefore usable by the end user in a different context if need be. Displaying them including the uncategorised posts of all three blog is much harder to achieve as I have explained, since there is currently no direct link between the posts and their blog. So, I see this as an advanced use case, that would need much more work. Is it a blocker for you ? >> BTW, you didn’t mention introducing the {{blogPost}} macro on that design >> page. I’d envision it as a simple macro used to display the posts of a given >> blog: {{blog reference=“Space1…SpaceN.WebHome”/}} (where the reference would >> be a reference to a document having an xobject of type BlogClass). > > You said: > >> You means to have a macro that do the same as {{display >> reference=“Space1…SpaceN.WebHome” /}} ? > > Yes, a macro that an end-user can use, for ex using the WYSIWYG editor, to > decide to display blog posts wherever he/she wants in his/her content. If the > implementation is as simple as using the display macro then it’s great ;) > > Now it’s not as simple since, the user should be able to control whether to > also display the ability to add new blog posts or not (the form). By default > it shouldn’t be displayed IMO. > This is not the case, the form is only displayed on the page listing multiple > blog posts that will be covered by the planned macros. This is why I > currently do not see the value of having a separate macro, since the display > macro already fulfil the need. >From a simple user POV, it’s a world apart :) And the cost is so small that I >really don’t see the issue. In general we’re lacking tons of ready-to-use >macros that end users (not developers) can use. > That said, we can think about packaging the BlogPostSheet into a macro with > some useful parameters to customise the display of the post. Even without parameters, it makes the feature discoverable by users. > That needs to be designed, it is currently out of scope, but feel free to > participate on the design page. ;) Sure but I was surprised you didn’t put it since we discussed and I thought it was agreed and that you had already included it in your work. With the evolution of the design we discussed today regarding the macros, we are closer to it anyway. So let’s say that it will happen in a custom way. -- Denis Thanks -Vincent > -- Denis > > > Thanks > -Vincent > >> Now replying to your comments on the design documents... >> -- Denis >> >> WDYT? >> >> Thanks >> -Vincent >> >> [snip]
