8:14 p.m.
----- Original Message -----
From: "Einav Cohen" <ecohen(a)redhat.com>
To: "Alon Bar-Lev" <alonbl(a)redhat.com>
Cc: engine-devel(a)ovirt.org
Sent: Friday, August 30, 2013 7:56:13 PM
Subject: Re: [Engine-devel] ok to sort login domains on backend?
> ----- Original Message -----
> From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> Sent: Friday, August 30, 2013 12:35:24 PM
>
>
>
> ----- Original Message -----
> > From: "Einav Cohen" <ecohen(a)redhat.com>
> > To: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > Cc: "Greg Sheremeta" <gshereme(a)redhat.com>,
engine-devel(a)ovirt.org
> > Sent: Friday, August 30, 2013 5:12:37 PM
> > Subject: Re: [Engine-devel] ok to sort login domains on backend?
> >
> > > ----- Original Message -----
> > > From: "Alon Bar-Lev" <alonbl(a)redhat.com>
> > > Sent: Friday, August 30, 2013 9:32:46 AM
> > >
> > >
> > >
> > > ----- Original Message -----
> > > > From: "Greg Sheremeta" <gshereme(a)redhat.com>
> > > > To: engine-devel(a)ovirt.org
> > > > Sent: Friday, August 30, 2013 3:26:48 PM
> > > > Subject: [Engine-devel] ok to sort login domains on backend?
> > > >
> > > > Hi,
> > > >
> > > > I'm working on https://bugzilla.redhat.com/785555 --
"domain
> > > > selection
> > > > list
> > > > in login screen should be sorted alphabetically"
> > > >
> > > > I was going to put the sort logic in the web apps, but it makes
sense
> > > > to
> > > > just
> > > > put it in the backend, specifically in GetDomainListQuery. (There is
> > > > already
> > > > a sort there, but it needs to be tweaked to put "internal"
always
> > > > last.)
> > > > This would affect non-webapp clients (REST API), so I want to make
> > > > sure
> > > > there are no objections. Unit tests pass and it seems to work fine
> > > > (screen
> > > > attached).
> > > >
> > > > Any objections?
> > >
> > > I think that sorting of visualization is presentation layer role.
> >
> > true in general, but I think that there is no harm in returning items
> > from the backend in some default order, especially if this is a list
> > of simple items that have only one possible order that makes sense.
>
> Even if that so, there is no reason to relay on it.
if this method will return a sorted list *by definition*, there would be
no reason to NOT relay on it.
for this particular case, I think that it would be a bit of waste if the
exact same sorting logic will be duplicated across the different clients'
code (including 3rd-party clients). If we can make it a little bit easier
on the clients, I don't see why not to do it.
> If sort is required at presentation, presentation layer should apply sort.
define "presentation"; looking at the xml response of a rest-api GET request
in a browser is also "presentation", but I can't really apply sort there;
yes,
I can change the rest-api code to sort the results, but why not simply make
it
a bit easier for *all* clients, and return the results from the backend
already
sorted in the way which is probably the most comfortable for everyone?
[again - you are generally correct, but in this particular case, of simple
business entities which have pretty much only one way of sorting that makes
sense, I don't see why not make an exception and apply the sort on the
backend]
Well, we can agree to disagree.
RestAPI is not presentation, the fact that browser has presentation layer to interact with
RestAPI does not mean that the server side is responsible on ordering etc. The RestAPI
presentation layer may allow sorting.
I do not think that API should have any sense of presentation ordering it only makes it
more complex without a reason.
Let's assume the API sort is based on plain text, and you have a bug to sort using
case insensitive, so API definition should be fixed? so you pass a parameter to request
specific casing?
Let's assume that each domain has value and description, you agree that sort should be
based on description, right? Now, let's say that description can be localized, which
sort can the server apply?
These are the reason why presentation layer was split out, ever since IBM Mainframe 3270
the layer is running on the client side.
Regards,
Alon Bar-Lev
>
> >
> > >
> > > >
> > > > Thanks,
> > > > Greg
> > > >
> > > >
> > > > Greg Sheremeta
> > > > Red Hat, Inc.
> > > > Sr. Software Engineer, RHEV
> > > > Cell: 919-807-1086
> > > > gshereme(a)redhat.com
> > > > _______________________________________________
> > > > Engine-devel mailing list
> > > > Engine-devel(a)ovirt.org
> > > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > > >
> > > _______________________________________________
> > > Engine-devel mailing list
> > > Engine-devel(a)ovirt.org
> > > http://lists.ovirt.org/mailman/listinfo/engine-devel
> > >
> > >
> > >
> >
> _______________________________________________
> Engine-devel mailing list
> Engine-devel(a)ovirt.org
> http://lists.ovirt.org/mailman/listinfo/engine-devel
>
>
>