Re: [xwiki-devs] [PROPOSAL] Execution context property declarations and property metadata attributes

Hi, 2012-10-16 11:03, Vincent Massol skrev: I want to put authorization information in the execution context, and I want to trust that this information is carried over to any new execution context that is activated in the scope of the current request. It is also great if the object that holds the information cannot be replaced. So, if you look at the code you will see that I have implemented a rather aggressive enforcment of the combination of the attributes read-only and inherited. But also, the need for the inherited property already exists for managing the properties "xwikicontext" and "velocityContext". Just look at the TODO and FIXME in DefaultExecutionContextManager in the master branch. But the general idea is just to be able to associate any kind of metadata with each property. It can be compared to how interpreted languages handle variables. Take for instance bash, where you can just set a variable to a value, wich implicitly declares the variable. But you can also explicitly declare a variable, and in the declaration you can provide flags that sets various attributes of the variable. (e.g, declare -r variable='readonly value'.) Setting and declaring a property are completely different concepts. In a purely declarative model, properties would have to be declared before being set. But what I'm proposing is more in line with what bash does with variables. Setting a value on an undefined property will implicitly declare it with default values for all attributes. You can also provide an initial value when declaring the property (which of course is required for read-only properties). Yes, getProperty returns the value of the property. I have not added any method to obtain the declared ECP instance as I don't see any need for it right now. Of course, it is only the reference to the value that is guaranteed to be read-only by the execution context. Depending on the application, it may be desirable to make the object immutable, but that is not up to the execution context to enforce. A property may only be declared once in an execution context, so it will be refused if the property is already declared. It doesn't matter if it was an explicit or implicit declaration. Attempting to declare an already existing property is an indication that something is wrong, so raising an exception seems appropriate. If the property is read-only, then also setProperty will refuse to replace the value. No, you are mistaken. We allow the creation and activation of several execution contexts per request. That's why we have the kludges in DefaultExecutionContextManager for copying and cloning "xwikicontext" and "velocityContext". I do not want to clone my authorization data. It wouldn't hurt cloning it, but it would serve no purpose. But I can also imagine that some applications might want to put objects that are expensive to clone in the execution context. No, it just means that we can perform run-time type checking when setting the value of a declared property. It would catch some errors earlier, but not as early as compile time. You can let the execution context provide some basic validation when setting it. If you mark a value read-only, you will not need to worry about if any component suddenly replaces or remove it in the middle of the request. Yes it is. ;) The proposal adds two methods and one class, while beeing backwards compliant with current code. To me it seems that we have plenty of time to change our minds before releasing 4.3-rc1 if I were to merge this with master right now. Or is our policy that we have to commit to any API that we have added in a milestone release? I will propose a vote for it later in any event. Best Regards, /Andreas