You can now use operator=and to make the macro AND labels. This is documented in the 2.5 notation guide.

Hi David,

Thanks for that. I'll keep an eye on this so!

cheers,
Damian.

I have a library I'm currently working on to address these issues. It's a little in flux, and in order to get it into contentbylabel it would have to be integrated by Atlassian...

I'll post more when my library has stablised a bit...

Hi,

Is there any updatre on this feature? It's something we've come across a need for ourselves!

cheers,
Damian.

Is this could be plannified for 2.2.9 ?

I have updated http://confluence.atlassian.com/display/DISC/Unified+Page+Searching+Tags with some further thoughts.

Kelsey

Hi Mark,

I've run into the same issue as you here - and completely agree that the most important thing is that they should all use the same parameters.

The real challenges then that we face are that each macro has grown up with a different set of parameters, and they tend to follow a natural trajectory (such as the metadata plugin which went from a list with commas to using that comma as an OR operator).

I think that there are some guiding principles to make it possible for non-developers to create a macro:

• It's got to be easy to do simple things - like give me a list of everything with this label. The hard stuff can be harder.
• It should build on existing knowledge of building filters and such - unfortunately I think that the only place people encounter such things are in places like Excel (autofilter) where there are UIs to guide you through. We don't have that luxury.
• The plugins should be backwards compatible - but there might be places where this is impossible

Perhaps to answer these questions we need to actually flesh out some scenarios - without that it's pretty much useless to decide what's more important. We use it extensively so I will update the confluence link with some of the examples we have used and would like to use. We can then compare different syntaxes openly and objectively.

Hello Kelsey,

just one thing to start with: We really love the metadata-plugin here and the label-mechanism works better than for the contentbylabelmacro (see CONF-6240). I also (as developer) like the more complex syntax better which Kelsey supposed. But I currently experience a lot of problems with users who are no developer's and don't like too complex wiki-markup. With those users keeping in mind I constructed the alternative syntax to your metadata-plugin.

I also like your discussion about making the syntax more unique. As soon as I have some time I will take part in the discussion. I think it is very important that the plugins behave comparable. Otherwise learning how to handle them is very hard and again will stop some people from adding content to the wiki. It is already close to getting to hard with e. g. alternatives like space, spaceKey, key and such to specify the space to use (I hope I remember the alternatives correctly...). Providing a common utility-class would be very useful.

Kind Regards,
Mark

Hmmmmmm,

I must confess I don't find the ~ syntax intuitive, but maybe that's me. For the metadata plugin I implemented it by using "," for OR (since it used to be a list of labels - ANY of which could be used). So I added "" for AND, and in the process made it a bit more general - so you can have A(B,C) or any complexity of parentheses.

I guess the difference is that for what I have done + and , are binary operators whereas Mark's syntax are unary. That would mean we could extend the metadata macro syntax to either include a NOT unary operator "-", or maybe have a separate parameter e.g. excludeLabels=A+B - which would exclude if the page had A AND B.

One of the challenges to deal with is that if you ONLY have exclusions, then you have to start with all pages and then filter one-by-one. That strikes me as very slow - our corporate wiki has hundreds of pages. I can't see how you could implement the unary NOT syntax without resorting to something like that, but using an excludeLabels=A,B would apply as a filter after fetching other pages. Actually the framework is already in place since the parser in the metadata plugin can be reused (visitor) and it has a filter-chain.

+10

These things definately need to be unified from a core Confluence API call (which ideally needs awesome caching built in as it'll get hammered) and they should also extend to news.

What do you think to Mark's syntax? I quite like it as it's nice and compact.