> 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
* 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).
>> 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.
Thanks
-Vincent
> -- Denis
>
>
> Thanks
> -Vincent
>
>> Now replying to your comments on the design documents...
>> -- Denis
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>> [snip]
