braidiano wrote:
Hi,
I have the same issue with DevExpress ASPxGridView
I also opened a support request, and they replied me that -this behavior is by design- and provided me some links to the Wrapper Soltion (that doesn't support all the features, like filtering, grouping, etc..)
so.. there is any other "workaround" way, that we can suggest to DevExpress support to solve this problem and will make the grid works properly using LLBLGenPro2 DataSource controls? (like an event to handle pagination and setting the pagination params?)
I sent them a new Request letting them know I was possibly going to invoke my 60 Day Money back guarantee and switch to Telerik. Explained in great detail that I thought their wrapper idea was half-baked... and that there were many threads in the forums, and in the support area regarding true DataSource control integration with their grid. I also reiterated how it seems they are trying to force their customers to use the XPO product, which is no where near the caliber of LLBLGen.
Here is an excerpt from my last support message:
I think you seem to ignore most of my posting here, it seems that there needs to be a more open implementation of your grid. I have been suggested to look at Telerik, and some of my examples in this post point to those, and it seems you say you want feedback, but from many messages about IListServer, being a sole-propriety class, it does not bode well as a true implementation for all DataSource controls out there, LLBLGen included.
It seems that while you have a great grid, I almost think y ou have put too much into it... It seems to me that the reporting functionality of summaries is your main stumbling block in saying you support a DataSource control that does not implement IListServer.
It seems you should offer a developer an event such as GetData and create some EventArgs that pass in like a FilterExpression, SummaryExpress, GroupExpression, Paging, etc... Leave it up to the developer to parse out that information and return to correct data.
If a Developer has a method of getting that data better than LinqToSql, or XPO or whatever, leave the ability for the developer to take control and write code.
If DevExpress wants to truly offer the best controls, I think you are a bit behind Telerik in this realm... and the pricing is identical, for a much more robust interface for a developer. As stated here and in other threads in the forums and support center that I have seen, it seems there is a bit of conflict of interest in pushing your XPO product. The reason behind that, is whenever there is something not quite working, the response from Support, "use our XPO product and it will work" ... not let's talk it through and see what we can do to make our grid more universally supported by all the other DataSource control builders out there...
So can we get real here and work through this, and not a "yeah, we'll consider this... and never implement" ... I know there have been articles written by Julian about whether or not the controls work for what we need, etc. and an article about work-arounds, etc... But I think if you sit back and think about this, this is a real problem. Trying to solve the entire world by a Read Only LinqServerModeDataSource is not the answer. While it many instances that is more than sufficient, the problem lies in large datasets in which you boast the great performance. It would be nice to boast that performance without boxing your customers into a limited direction.
I think Telerik does something like the part where I say "It seems you should offer a developer an event such as GetData and create some EventArgs that pass in like a FilterExpression, SummaryExpress, GroupExpression, Paging, etc... Leave it up to the developer to parse out that information and return to correct data."
Of course, no response.