Behavior of required, read-only properties in plugin descriptor

Jay Shaughnessy jshaughn at redhat.com
Tue Dec 4 18:51:43 UTC 2012


The property should likely be required="false" readOnly="true".  The 
semantics there being that if the discovery code doesn't set the value 
then it's unnecessary.

But, for the situation you present I think we should change the way the 
GUI is working.  It is useless and annoying to tell the user to fill in 
a value they can't set, whether it's needed or not.  If it is needed 
it's maybe a bug in the discovery code that could be fixed in the 
discovery code.  Logging a warning somewhere could be useful.  But in 
the situation you describe, if for some reason the plugin dev thinks 
required="true" is a necessity, I agree that we should leave it alone.

On 12/4/2012 5:41 AM, Heiko W.Rupp wrote:
> Hi,
>
> tl;dr: shouldn't we not bother the user when a r/o value is not set by the managed resource?
>
> ( this is related to https://bugzilla.redhat.com/show_bug.cgi?id=857063 but applies to much more places)
>
> in the as7 plugin we have a plugin descriptor entry like this:
>
>        <c:simple-property name="persistent" required="true" type="boolean" readOnly="true" .../>
>
> Note that this is required and read-only.
>
> * Read-only indicates that the user should not need to enter this value, but that this is informal.
> * required means that the property may not be 'unset', so in this boolean case it must be true or false.
>
> Now we run into the situation, that the configuration that uses the property is used in different resource types on as7, where on one type the server supplies the property and on the other it does not.
>
> On the resource type where the server does not deliver that value, the UI displays the red bar and asks to fix the value. But then the property
> is marked as read-only so fixing it makes no sense.
>
> Shouldn't the UI (and the CLI ?) in this case not just mark the property as unset and leave the user alone?
>
> One could set a default value that is just silently filled in to satisfy the "required" condition, but that would be the wrong semantics either.
>
> Workaround could be to define two different resource types, but this blows up the plugin descriptor even more, but that is a different story (see https://docs.jboss.org/author/display/RHQ/Needed+-+Modular+resource+type+entries )
>
>
>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.fedorahosted.org/pipermail/rhq-devel/attachments/20121204/349cf1cf/attachment.html>


More information about the rhq-devel mailing list