Where does it end?
-
*** DISCLAIMER *** This isn't a programming question, because I've solved the programming problem myself. Rather, I'm interested in your opinion regarding the solution, clever or 'clever'? So today I had a nice little challenge. My application has a grid which can be sorted on various columns, asc and desc. Now the sorting isn't applied by clicking the column header, but by selecting a value from a drop down (Name, Name (descending), Title, Title (descending) etc.). I was thinking I could just have a switch statement where I check which ordering the user chose (which would make me extend the switch for each new ordering), or... I could abstract this away. Of course I went for the second option. Now to make this work (and it works nicely, adding a new ordering is a piece of cake) I had to write the following function:
SomeFunction(string caption, Func, Expression>, IQueryable> linqFunction, Expression> expression) { ... }
Since this is a WinForms application though, and WinForms and generics don't go well together I'm more or less forced to use a
dynamiclater on as it's quite impossible to get the values ofTElementandTKeyfromobject. I'm thinking this isn't ideal in terms of complexity and readability, but it is pretty neat because adding a new ordering is really simple (one line of simple code) and guaranteed to work on the first try (you'll never forget to change that switch statement again). And the solution is even re-usable for the filter functionality I need as well (which, of course, becomes a breeze as well)! So judging from that, clever or 'clever'? And where do you draw the line for cleverness vs. readability/simplicity?Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Sander Rossel wrote:
And where do you draw the line for cleverness vs. readability/simplicity?
The latter would be considered clever. Anyone can write complex code, but it is hard to reduce complexity to smaller and simpeler tasks.
Sander Rossel wrote:
I was thinking I could just have a switch statement where I check which ordering the user chose (which would make me extend the switch for each new ordering),
I'd be using inheritance to do so. Requires a complete class if you want another switch option. I'd be doing the same for the columns; write a single column and inherit from there, and simply call "sort" on the column. If it works, then it works. If everyone in your team accepts it, keep it. I would recommend to create a special class (yes, another) to keep all the arguments you're passing to the method. That way you'd pass a specialized object instead of a (rather lengty) parameter-list. Has the added advantage (besides the obvious readability) that you can loop your arguments using reflection, log them if desired, and inherit them when creating a newer version. Similar to the EventArgs principle :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
I can't read that code. Do you actually sort the grid? Or sort the data that is then displayed by the grid? A standard DataGridView generally displays a DataView (based on a DataTable) and you control the sorting with the Sort property. Does your solution allow multi-level sorting? E.g. first by X, then by Y ? I can't stand grids that allow sorting on only one column at a time X| . I'm unclear on the details of what you have, but I would consider having each Item in the DropDown know what it is supposed to do -- perhaps a class with a Name and a Delegate -- so all you need do is add a new Item to the DropDown.
I'm sorting the data that is then displayed by the grid. The DataGridView works pretty well when you have a DataView, but all I'm having is a List<T> which I haven't been able to sort in the past if my life depended on it. So it's easier to just take your original list, sort it (using OrderBy and OrderByDescending) and bind to the result. The same goes for filtering with Where.
PIEBALDconsult wrote:
Does your solution allow multi-level sorting?
Nope, should be a new value in the drop down, like "name then title".
PIEBALDconsult wrote:
I'm unclear on the details of what you have, but I would consider having each Item in the DropDown know what it is supposed to do -- perhaps a class with a Name and a Delegate -- so all you need do is add a new Item to the DropDown.
That's exactly what I have :laugh: The code I posted above could be called as follows:
comboBoxOrdering.Items.Add(SomeFunction("Name", Queryable.OrderBy, q => q.Name));
I need all the generics so my IntelliSense (and compiler) knows that
qis actually some type that has aNameproperty :) And I'm having something similar for the filter functionality (which is also a dropdown).comboBoxFilters.Items.Add(SomeFunction("Active only", Queryable.Where, q => q.Active));
So even if you couldn't read the code above, I'm pretty sure you could use it ;)
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
*** DISCLAIMER *** This isn't a programming question, because I've solved the programming problem myself. Rather, I'm interested in your opinion regarding the solution, clever or 'clever'? So today I had a nice little challenge. My application has a grid which can be sorted on various columns, asc and desc. Now the sorting isn't applied by clicking the column header, but by selecting a value from a drop down (Name, Name (descending), Title, Title (descending) etc.). I was thinking I could just have a switch statement where I check which ordering the user chose (which would make me extend the switch for each new ordering), or... I could abstract this away. Of course I went for the second option. Now to make this work (and it works nicely, adding a new ordering is a piece of cake) I had to write the following function:
SomeFunction(string caption, Func, Expression>, IQueryable> linqFunction, Expression> expression) { ... }
Since this is a WinForms application though, and WinForms and generics don't go well together I'm more or less forced to use a
dynamiclater on as it's quite impossible to get the values ofTElementandTKeyfromobject. I'm thinking this isn't ideal in terms of complexity and readability, but it is pretty neat because adding a new ordering is really simple (one line of simple code) and guaranteed to work on the first try (you'll never forget to change that switch statement again). And the solution is even re-usable for the filter functionality I need as well (which, of course, becomes a breeze as well)! So judging from that, clever or 'clever'? And where do you draw the line for cleverness vs. readability/simplicity?Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Sander Rossel wrote:
I'm thinking this isn't ideal in terms of complexity and readability,
IMO any generic solution beats writing endless switch-statements or having to update code in multiple places when introducing a new field or whatever. Even if it's bordering on your personal definition of complexity and readability. The other solution probably wouldn't win a prize either :)
Sander Rossel wrote:
I'm more or less forced to use a
dynamiclater on as it's quite impossible to get the values ofTElementandTKeyfromobject.Can you elaborate?
-
Sander Rossel wrote:
And where do you draw the line for cleverness vs. readability/simplicity?
The latter would be considered clever. Anyone can write complex code, but it is hard to reduce complexity to smaller and simpeler tasks.
Sander Rossel wrote:
I was thinking I could just have a switch statement where I check which ordering the user chose (which would make me extend the switch for each new ordering),
I'd be using inheritance to do so. Requires a complete class if you want another switch option. I'd be doing the same for the columns; write a single column and inherit from there, and simply call "sort" on the column. If it works, then it works. If everyone in your team accepts it, keep it. I would recommend to create a special class (yes, another) to keep all the arguments you're passing to the method. That way you'd pass a specialized object instead of a (rather lengty) parameter-list. Has the added advantage (besides the obvious readability) that you can loop your arguments using reflection, log them if desired, and inherit them when creating a newer version. Similar to the EventArgs principle :)
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
I'd be using inheritance to do so. Requires a complete class if you want another switch option.
Actually, what you're looking at is the constructor of that function :laugh:
Eddy Vluggen wrote:
I'd be doing the same for the columns; write a single column and inherit from there, and simply call "sort" on the column
Have you ever worked with the WinForms DataGridView? It's a beast and if you're going to inherit anything from it you're in for a rough ride :sigh:
Eddy Vluggen wrote:
I would recommend to create a special class (yes, another) to keep all the arguments you're passing to the method.
It already is, but what's the difference between having a function that takes these arguments or a constructor that takes them? Or did you want to pass them to the class someway else? Fun fact, in my code you're mostly looking at the signature of common LINQ functions like OrderBy and Where ;)
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Sander Rossel wrote:
I'm thinking this isn't ideal in terms of complexity and readability,
IMO any generic solution beats writing endless switch-statements or having to update code in multiple places when introducing a new field or whatever. Even if it's bordering on your personal definition of complexity and readability. The other solution probably wouldn't win a prize either :)
Sander Rossel wrote:
I'm more or less forced to use a
dynamiclater on as it's quite impossible to get the values ofTElementandTKeyfromobject.Can you elaborate?
Sascha Lefévre wrote:
Can you elaborate?
Sure. Consider this :)
// Everything typed with IntelliSense support.
MyClass result = SomeFunction("Name", Queryable.OrderBy, q => q.Name); // string
comboBox.Items.Add(result);
comboBox.Items.Add(SomeFunction("Date", Queryable.OrderBy, q => q.Date)); // DateTime
comboBox.Items.Add(SomeFunction("Age", Queryable.OrderBy, q => q.Age)); // int// later...
object ordering = comboBox.SelectedItem;
// How to cast this?
MyClass result = (MyClass)ordering;// This works fine though!
dynamic ordering = comboBox.SelectedItem;
// Pseudo-code.
ordering.LinqFunction(ordering.Predicate);Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
*** DISCLAIMER *** This isn't a programming question, because I've solved the programming problem myself. Rather, I'm interested in your opinion regarding the solution, clever or 'clever'? So today I had a nice little challenge. My application has a grid which can be sorted on various columns, asc and desc. Now the sorting isn't applied by clicking the column header, but by selecting a value from a drop down (Name, Name (descending), Title, Title (descending) etc.). I was thinking I could just have a switch statement where I check which ordering the user chose (which would make me extend the switch for each new ordering), or... I could abstract this away. Of course I went for the second option. Now to make this work (and it works nicely, adding a new ordering is a piece of cake) I had to write the following function:
SomeFunction(string caption, Func, Expression>, IQueryable> linqFunction, Expression> expression) { ... }
Since this is a WinForms application though, and WinForms and generics don't go well together I'm more or less forced to use a
dynamiclater on as it's quite impossible to get the values ofTElementandTKeyfromobject. I'm thinking this isn't ideal in terms of complexity and readability, but it is pretty neat because adding a new ordering is really simple (one line of simple code) and guaranteed to work on the first try (you'll never forget to change that switch statement again). And the solution is even re-usable for the filter functionality I need as well (which, of course, becomes a breeze as well)! So judging from that, clever or 'clever'? And where do you draw the line for cleverness vs. readability/simplicity?Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
I say kudos for cleverness! Your solution is hard to read/understand (at least for me) but I like it since it makes me break it apart. If I still don't understand it, I'd have to run it in a debugger. Just leave decent documentation for the next guy. :)
"Go forth into the source" - Neal Morse
-
I'm sorting the data that is then displayed by the grid. The DataGridView works pretty well when you have a DataView, but all I'm having is a List<T> which I haven't been able to sort in the past if my life depended on it. So it's easier to just take your original list, sort it (using OrderBy and OrderByDescending) and bind to the result. The same goes for filtering with Where.
PIEBALDconsult wrote:
Does your solution allow multi-level sorting?
Nope, should be a new value in the drop down, like "name then title".
PIEBALDconsult wrote:
I'm unclear on the details of what you have, but I would consider having each Item in the DropDown know what it is supposed to do -- perhaps a class with a Name and a Delegate -- so all you need do is add a new Item to the DropDown.
That's exactly what I have :laugh: The code I posted above could be called as follows:
comboBoxOrdering.Items.Add(SomeFunction("Name", Queryable.OrderBy, q => q.Name));
I need all the generics so my IntelliSense (and compiler) knows that
qis actually some type that has aNameproperty :) And I'm having something similar for the filter functionality (which is also a dropdown).comboBoxFilters.Items.Add(SomeFunction("Active only", Queryable.Where, q => q.Active));
So even if you couldn't read the code above, I'm pretty sure you could use it ;)
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Eddy Vluggen wrote:
I'd be using inheritance to do so. Requires a complete class if you want another switch option.
Actually, what you're looking at is the constructor of that function :laugh:
Eddy Vluggen wrote:
I'd be doing the same for the columns; write a single column and inherit from there, and simply call "sort" on the column
Have you ever worked with the WinForms DataGridView? It's a beast and if you're going to inherit anything from it you're in for a rough ride :sigh:
Eddy Vluggen wrote:
I would recommend to create a special class (yes, another) to keep all the arguments you're passing to the method.
It already is, but what's the difference between having a function that takes these arguments or a constructor that takes them? Or did you want to pass them to the class someway else? Fun fact, in my code you're mostly looking at the signature of common LINQ functions like OrderBy and Where ;)
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Sander Rossel wrote:
Actually, what you're looking at is the constructor of that function :laugh:
The fact that you have to explain that is an indication of the readability.
Sander Rossel wrote:
Have you ever worked with the WinForms DataGridView?
Yes, and I love it. Cannot say the same for the XtraGrid or the MSFlexGrid. Which would you recommend, if not the DataGridView?
Sander Rossel wrote:
It already is, but what's the difference between having a function that takes these arguments or a constructor that takes them?
It would work the same for a constructor as well as a method; it is a simply way of reducing the amount of arguments.
public static Process Start(
ProcessStartInfo startInfo
)That's a factory-method, with a single argument. I think that is a bit more readable than having all the options listed. There's another advantage in this idea if you're planning to inherit the Process-class; your inherited class could easily extend the parameter list without changing the method-signature.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Sander Rossel wrote:
Actually, what you're looking at is the constructor of that function :laugh:
The fact that you have to explain that is an indication of the readability.
Sander Rossel wrote:
Have you ever worked with the WinForms DataGridView?
Yes, and I love it. Cannot say the same for the XtraGrid or the MSFlexGrid. Which would you recommend, if not the DataGridView?
Sander Rossel wrote:
It already is, but what's the difference between having a function that takes these arguments or a constructor that takes them?
It would work the same for a constructor as well as a method; it is a simply way of reducing the amount of arguments.
public static Process Start(
ProcessStartInfo startInfo
)That's a factory-method, with a single argument. I think that is a bit more readable than having all the options listed. There's another advantage in this idea if you're planning to inherit the Process-class; your inherited class could easily extend the parameter list without changing the method-signature.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
The fact that you have to explain that is an indication of the readability.
Actually, I shouldn't have called it SomeFunction :)
Eddy Vluggen wrote:
Which would you recommend, if not the DataGridView?
Definitely XtraGrid, all sorting and filtering capabilities you need right out of the box!. Sure, steep learning curve, but it's worth it :)
Eddy Vluggen wrote:
That's a factory-method, with a single argument.
But somewhere there's a class constructor for ProcessStartInfo that has all those parameters, right? ;)
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Sander Rossel wrote:
That's exactly what I have
Oh. Well, alright then.
A shame you didn't recognize it. It's an indication that my code is, indeed, 'clever'... Not sure how to make it more readable though (I guess this is the part where it becomes a programming question :laugh: ).
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
I say kudos for cleverness! Your solution is hard to read/understand (at least for me) but I like it since it makes me break it apart. If I still don't understand it, I'd have to run it in a debugger. Just leave decent documentation for the next guy. :)
"Go forth into the source" - Neal Morse
kmoorevs wrote:
Just leave decent documentation for the next guy
If I told you you could call it like this, would you know enough? :)
SomeFunction("Name", Queryable.OrderBy, q => q.Name);
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Sascha Lefévre wrote:
Can you elaborate?
Sure. Consider this :)
// Everything typed with IntelliSense support.
MyClass result = SomeFunction("Name", Queryable.OrderBy, q => q.Name); // string
comboBox.Items.Add(result);
comboBox.Items.Add(SomeFunction("Date", Queryable.OrderBy, q => q.Date)); // DateTime
comboBox.Items.Add(SomeFunction("Age", Queryable.OrderBy, q => q.Age)); // int// later...
object ordering = comboBox.SelectedItem;
// How to cast this?
MyClass result = (MyClass)ordering;// This works fine though!
dynamic ordering = comboBox.SelectedItem;
// Pseudo-code.
ordering.LinqFunction(ordering.Predicate);Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Makes sense. But is there a specific reason why you didn't use a signature like this:
MyClass ordering = SomeFunction(string caption, Func, IQueryable> applyPredicate) { ... }
And then use it like this:
comboBox.Items.Add(SomeFunction("Date", source => source.OrderBy(q => q.Date)));
MyClass ordering = (MyClass)comboBox.SelectedItem;
// Pseudo-code:
ordering.ApplyPredicate(); -
Makes sense. But is there a specific reason why you didn't use a signature like this:
MyClass ordering = SomeFunction(string caption, Func, IQueryable> applyPredicate) { ... }
And then use it like this:
comboBox.Items.Add(SomeFunction("Date", source => source.OrderBy(q => q.Date)));
MyClass ordering = (MyClass)comboBox.SelectedItem;
// Pseudo-code:
ordering.ApplyPredicate();Yep, I need the
q => q.Datepart seperately :) Although you do make a good point. I'll see if I can change the code tomorrow so it would work as you propose. It would certainly make that easier.Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
Eddy Vluggen wrote:
The fact that you have to explain that is an indication of the readability.
Actually, I shouldn't have called it SomeFunction :)
Eddy Vluggen wrote:
Which would you recommend, if not the DataGridView?
Definitely XtraGrid, all sorting and filtering capabilities you need right out of the box!. Sure, steep learning curve, but it's worth it :)
Eddy Vluggen wrote:
That's a factory-method, with a single argument.
But somewhere there's a class constructor for ProcessStartInfo that has all those parameters, right? ;)
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Sander Rossel wrote:
Actually, I shouldn't have called it SomeFunction :)
I admit I have used the prefix "some" in production code.
Sander Rossel wrote:
Definitely XtraGrid, all sorting and filtering capabilities you need right out of the box!. Sure, steep learning curve, but it's worth it :)
I keep hearing that, yet personally I keep preferring speed and simplicity.
Sander Rossel wrote:
But somewhere there's a class constructor for ProcessStartInfo that has all those parameters, right? ;)
Check for yourself[^]. You'd probably not need them ALL at once, so it would make no sense to provide an overload that lists them all as real arguments. I also do not see any benefit in the extra overload, only a higher LOC - you'd loose aforementioned benefits that bundlig the arguments has. If they are part of the method-signature, then it will be harder to log (instead of simply serializing the arguments-object), and the signature would change if a parameter needs to be added.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
-
Sander Rossel wrote:
Actually, I shouldn't have called it SomeFunction :)
I admit I have used the prefix "some" in production code.
Sander Rossel wrote:
Definitely XtraGrid, all sorting and filtering capabilities you need right out of the box!. Sure, steep learning curve, but it's worth it :)
I keep hearing that, yet personally I keep preferring speed and simplicity.
Sander Rossel wrote:
But somewhere there's a class constructor for ProcessStartInfo that has all those parameters, right? ;)
Check for yourself[^]. You'd probably not need them ALL at once, so it would make no sense to provide an overload that lists them all as real arguments. I also do not see any benefit in the extra overload, only a higher LOC - you'd loose aforementioned benefits that bundlig the arguments has. If they are part of the method-signature, then it will be harder to log (instead of simply serializing the arguments-object), and the signature would change if a parameter needs to be added.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^][](X-Clacks-Overhead: GNU Terry Pratchett)
Eddy Vluggen wrote:
You'd probably not need them ALL at once
True for the ProcessStartInfo, but my method only has three and I always need all of them. I can see how such a class would make sense though (I probably don't use it far enough).
Eddy Vluggen wrote:
I admit I have used the prefix "some" in production code.
I'll pretend I didn't see that! :laugh:
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
-
*** DISCLAIMER *** This isn't a programming question, because I've solved the programming problem myself. Rather, I'm interested in your opinion regarding the solution, clever or 'clever'? So today I had a nice little challenge. My application has a grid which can be sorted on various columns, asc and desc. Now the sorting isn't applied by clicking the column header, but by selecting a value from a drop down (Name, Name (descending), Title, Title (descending) etc.). I was thinking I could just have a switch statement where I check which ordering the user chose (which would make me extend the switch for each new ordering), or... I could abstract this away. Of course I went for the second option. Now to make this work (and it works nicely, adding a new ordering is a piece of cake) I had to write the following function:
SomeFunction(string caption, Func, Expression>, IQueryable> linqFunction, Expression> expression) { ... }
Since this is a WinForms application though, and WinForms and generics don't go well together I'm more or less forced to use a
dynamiclater on as it's quite impossible to get the values ofTElementandTKeyfromobject. I'm thinking this isn't ideal in terms of complexity and readability, but it is pretty neat because adding a new ordering is really simple (one line of simple code) and guaranteed to work on the first try (you'll never forget to change that switch statement again). And the solution is even re-usable for the filter functionality I need as well (which, of course, becomes a breeze as well)! So judging from that, clever or 'clever'? And where do you draw the line for cleverness vs. readability/simplicity?Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
"Maxthon has found dangerous code on this page. Click OK to stop loading the page, or Ignore if you're an idiot."
I wanna be a eunuchs developer! Pass me a bread knife!
-
*** DISCLAIMER *** This isn't a programming question, because I've solved the programming problem myself. Rather, I'm interested in your opinion regarding the solution, clever or 'clever'? So today I had a nice little challenge. My application has a grid which can be sorted on various columns, asc and desc. Now the sorting isn't applied by clicking the column header, but by selecting a value from a drop down (Name, Name (descending), Title, Title (descending) etc.). I was thinking I could just have a switch statement where I check which ordering the user chose (which would make me extend the switch for each new ordering), or... I could abstract this away. Of course I went for the second option. Now to make this work (and it works nicely, adding a new ordering is a piece of cake) I had to write the following function:
SomeFunction(string caption, Func, Expression>, IQueryable> linqFunction, Expression> expression) { ... }
Since this is a WinForms application though, and WinForms and generics don't go well together I'm more or less forced to use a
dynamiclater on as it's quite impossible to get the values ofTElementandTKeyfromobject. I'm thinking this isn't ideal in terms of complexity and readability, but it is pretty neat because adding a new ordering is really simple (one line of simple code) and guaranteed to work on the first try (you'll never forget to change that switch statement again). And the solution is even re-usable for the filter functionality I need as well (which, of course, becomes a breeze as well)! So judging from that, clever or 'clever'? And where do you draw the line for cleverness vs. readability/simplicity?Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Descending Given that I am not familiar with WHY your UI is the way it is, I am not qualified to recreate it. But I do prefer naturally adaptive code (reading the columns from the dataview). No need to remember anything... -
*** DISCLAIMER *** This isn't a programming question, because I've solved the programming problem myself. Rather, I'm interested in your opinion regarding the solution, clever or 'clever'? So today I had a nice little challenge. My application has a grid which can be sorted on various columns, asc and desc. Now the sorting isn't applied by clicking the column header, but by selecting a value from a drop down (Name, Name (descending), Title, Title (descending) etc.). I was thinking I could just have a switch statement where I check which ordering the user chose (which would make me extend the switch for each new ordering), or... I could abstract this away. Of course I went for the second option. Now to make this work (and it works nicely, adding a new ordering is a piece of cake) I had to write the following function:
SomeFunction(string caption, Func, Expression>, IQueryable> linqFunction, Expression> expression) { ... }
Since this is a WinForms application though, and WinForms and generics don't go well together I'm more or less forced to use a
dynamiclater on as it's quite impossible to get the values ofTElementandTKeyfromobject. I'm thinking this isn't ideal in terms of complexity and readability, but it is pretty neat because adding a new ordering is really simple (one line of simple code) and guaranteed to work on the first try (you'll never forget to change that switch statement again). And the solution is even re-usable for the filter functionality I need as well (which, of course, becomes a breeze as well)! So judging from that, clever or 'clever'? And where do you draw the line for cleverness vs. readability/simplicity?Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Looking at your code my subconscious started hearing the song "Simply Irresistible," starting at the verse: "methods are inscrutable" :) cheers, Bill
«To kill an error's as good a service, sometimes better than, establishing new truth or fact.» Charles Darwin in "Prospero's Precepts"
-
*** DISCLAIMER *** This isn't a programming question, because I've solved the programming problem myself. Rather, I'm interested in your opinion regarding the solution, clever or 'clever'? So today I had a nice little challenge. My application has a grid which can be sorted on various columns, asc and desc. Now the sorting isn't applied by clicking the column header, but by selecting a value from a drop down (Name, Name (descending), Title, Title (descending) etc.). I was thinking I could just have a switch statement where I check which ordering the user chose (which would make me extend the switch for each new ordering), or... I could abstract this away. Of course I went for the second option. Now to make this work (and it works nicely, adding a new ordering is a piece of cake) I had to write the following function:
SomeFunction(string caption, Func, Expression>, IQueryable> linqFunction, Expression> expression) { ... }
Since this is a WinForms application though, and WinForms and generics don't go well together I'm more or less forced to use a
dynamiclater on as it's quite impossible to get the values ofTElementandTKeyfromobject. I'm thinking this isn't ideal in terms of complexity and readability, but it is pretty neat because adding a new ordering is really simple (one line of simple code) and guaranteed to work on the first try (you'll never forget to change that switch statement again). And the solution is even re-usable for the filter functionality I need as well (which, of course, becomes a breeze as well)! So judging from that, clever or 'clever'? And where do you draw the line for cleverness vs. readability/simplicity?Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
Seems like you are trying to rewrite Dynamic Linq which has been around since 2008. Just pass a field name and do a % 2 to figure out if you call OrderBy or OrderByDescending. http://weblogs.asp.net/scottgu/dynamic-linq-part-1-using-the-linq-dynamic-query-library
-
Seems like you are trying to rewrite Dynamic Linq which has been around since 2008. Just pass a field name and do a % 2 to figure out if you call OrderBy or OrderByDescending. http://weblogs.asp.net/scottgu/dynamic-linq-part-1-using-the-linq-dynamic-query-library
How's that the same? My solution is type safe and has design time error checking ;) I simplified it a bit by the way.
Visit my blog at Sander's bits - Writing the code you need. Or read my articles at my CodeProject profile.
Simplicity is prerequisite for reliability. — Edsger W. Dijkstra
Regards, Sander
