Yup, to me that sounds like a good approach.
On 22/07/2011 8:55 PM, Heiko Braun wrote:
I do generally like this idea. But if would require some kind of unification across
subsystems.
Please see my other email about key/value pairs.
We would need at least a way to distinguish properties of the kind you are asking for
from
regular model attributes.
The sub resource approach I described in my other email could do the job.
On Jul 22, 2011, at 12:46 PM, Vimal Kansal wrote:
> See other problem that I see with allowing user to configure only the frequently used
properties from GUI, it can lead to a false assumption on part of the user that only these
are the properties that are available on the datasource. I wonder, if it is possible to
have a dynamic "property sheet" kind of user interface which displays the list
of writeable properties of a resource by querying it; I mean the kind of which we
generally see in IDE's.
>
> On 22/07/2011 8:13 PM, Heiko Braun wrote:
>>
>>
>> The CLI offers low level DMR operation, which offer a lot more possibilities
>> then the CLI's it's high level commands.
>>
>> If compare the web interface and the CLI, compare the CLI high level commands to
the
>> web interface. On this level they should remain synced as much as possible.
>>
>> I am not objecting to implement any nitty gritty dada source configuration
option,
>> but we need to get the priorities straight. Therefore I'd say let's focus
on the frequently used
>> features for sysadmins and developers.
>>
>> IMO it's fine with to point users to the the CLI for more fine grained
configuration options.
>> ("the good of the many outweighs the good of the few").
>>
>> Ike
>>
>> On Jul 22, 2011, at 12:01 PM, Vimal Kansal wrote:
>>
>>> However, this may lead to an inconsistency of sorts, as using CLI when you
execute :read-resource, you get to see all the configured properties, but when you use UI,
you will see only a subset. I am not sure, how appropriate it would be to have this
inconsistency.