Adding a generic internal attribute map to XDOM blocks

Development
#1

For improving footnote rendering (see the design page) I’ve discussed with @tmortagne and @mleduc that it would be very helpful to be able to store attributes of arbitrary type on XDOM Blocks (in particular on MacroMarkerBlocks). This would also be helpful for the compiled XDOM.

The proposal is to duplicate on the Block interface what we have for parameters (getParameters(), getParameter(String), setParameter(String, String), setParameters(Map<String, String>)), just with a different name and Object as value type. These attributes should be ignored by renderers, they are just supposed to be used by transformations/macros internally. An implementation would also be provided in AbstractBlock such that these new attributes would be usable on all blocks.

Now the main question is the name. Some ideas:

  1. internalAttribute
  2. annotation
  3. property
  4. internalProperty

I think my favorite is 4 (internalProperty) but I’m open to other suggestions.

API breakage on Block to add attributes
#2

Here are some other ideas:

  1. transientProperty (related to the transient keyword used in java for fields which should not be taken into account by serialization frameworks)
  2. blockProperty (as in only applying to the block and not to events produced from the event, but I’m afraid it’s still too ambiguous)

I don’t really have an obvious choice yet, but I think my favorite so far is transientProperty.

#3

I like the idea

#4

Why not simply attribute? ServletRequest for instance has both attributes (Object) and parameters (String). I’d keep it simple, without any “internal” or “transient” prefix.

#5

That’s a good argument and example. +1 then for using attribute.

#6

Is it a known usage in java libs to have this kind of scheme (parameters for String and attributes for Object)? I have never noticed such thing but maybe I just missed it.
I’m asking because at first sight, with just the name, I think it’s not so obvious that the attributes will contain objects and won’t be rendered.

Now I agree it’s simple and it seems to fit. So I’d be +0 for it.

#7

I mentioned in the call that led to this proposal from my compiler classes at university that I remembered that there was a term for this.
I think I finally found what I was looking for in the attribute grammar wikipedia page, and its attribute.

So +1 for attribute.

#8

The point was that it’s really not obvious from the names what is the difference between “attributes” and “parameters”.

But since there are two standard examples using this naming, I guess it’s good enough for me.

So +1 for attribute too.

#9

Whatever the option we choose at the end, we’ll need to be very explicit on the Javadoc to make a clear distinction with parameters.

1 Like
#10

Just for the record, it is possible to set (string) parameters on CompositeBlock that are fully ignored by all renderers as CompositeBlock doesn’t generate any events (and CompositeBlock itself is ignored, too). Similarly, it is probably easy to add custom blocks similar to CompositeBlock but with custom attributes.

#11

I decided not to implement this proposal as in my use case there were too many problems in particular when cloning blocks that I didn’t find them to be beneficial. Still, there might be other applications where they could be useful in which case this proposal could be revived.

The code can be found at XRENDERING-703: Add attributes to XDOM blocks by michitux · Pull Request #245 · xwiki/xwiki-rendering · GitHub, the Jira issue is XRENDERING-703.