On 12/12/2011 05:26 PM, Endi Sukma Dewata wrote:
On 12/12/2011 7:32 AM, Petr Vobornik wrote:
The first option is we could modify this page to use a table for each
type, similar to HBAC/sudo rule. For example:

SRV Records

x | Priority | Weight | Port | Target [Delete] [Add]
-------------------------------------------------------
x | 0 | 100 | 88 | test

I like this option better than the second one. It seems clearer to me.

Just from UI perspective (no change in commands): I would show only the
the tables which have some values - to let the page be shorter and
clearer. This will require an add button in the facet header - similar
dialog with type selection as in add in search facet except that the
idnsname would be implied.

The thing with this is that suppose you are looking for a certain type
and that type doesn't exist in that particular record, you would have to
look at the entire page before you know it doesn't exist. But if we show
empty tables, once you see the table you know the record doesn't have
the type you're looking for.

My assumption was that there wouldn't be many values of different types for one record so it wouldn't be a problem. Probably not a correct assumption...

Maybe we can hide the table but still show the table title (i.e. the
type) and an Add button next to it?

Sounds like a reasonable compromise.

Note, regardless of these options when you open the details page the UI
could execute up to 20 dnsrecord<RRTYPE>-show operations since there are
20 possible record types currently listed in the UI.

To avoid this it would be nice to have a method like dnsrecord-find ZONE
NAME (ie this one with new option) which would return the record with
data structure similar to dnsrecord<RR>-show. For example (content of
result):
[ //record array
{
idnsname: 'foo', //name
arecord: [
{
arecord: '10.10.10.10', //raw
ip_address: '10.10.10.10'
}
],
cnamerecord: [
{
cnamerecord: 'bar.example.com.', //raw
hostname: 'bar.example.com.'
},
{
cnamerecord: 'bar2.example.com.', //raw
hostname: 'bar2.example.com.'
},
]
}
]

This way we would get all info we need without calling batch with 20
commands or calling dnsrecord-find and then batch with 1-20 commands.

Yes, it would be great to have something like that. But the extra NAME
argument above could be confused with search filter for dnsrecord-find.

My bad, I accidentally wrote dnsrecord-find instead of dnsrecord-find. But the idea of the structure remains and it could be beneficial in find command (search facet) too. In the case if we decide to show formatted values in the table.

It might be better to use an additional flag to determine the output
format (like --raw), something like this:

ipa dnsrecord-find ZONE --structured
ipa dnsrecord-show ZONE NAME --structured

Yes, this I had in mind by the "new option".

The structure could also look like this (but either way will work):

[
{
idnsname: 'foo',
records: [
{
type: 'a',
data: '10.10.10.10',
ip_address: '10.10.10.10'
},
{
type: 'cname',
data: 'bar.example.com.',
hostname: 'bar.example.com.'
},
{
type: 'cname',
data: 'bar2.example.com.',
hostname: 'bar2.example.com.'
},
]
}
]

In this case the UI won't use the dnsrecord-<RRTYPE>-show/find command,
but it might still be useful for people using CLI. Or instead of that we
could have another option to specify which types you want to get.

ipa dnsrecord-show ZONE NAME --types=a,cname --structured



--
Petr Vobornik

_______________________________________________
Freeipa-devel mailing list
Freeipa-devel@redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel

Reply via email to