This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Hello, If you have used mac applications, you'll find that they support things like "Smart Mailboxes" or an equivalent. This is nothing but filtred views of data. More importantly, it is the user that specifies what that filter should be. I'd like to provide my users with the same ability. The first question is whether I can persist queries to XML (or another format) and back. And expressions? The second question would be how to deal with variables (like show me records for which I'm the owner, which is the only one I can think of). Thanks, Werner |
|
|
|
|
I'd actually advise against using a LightSpeed Query or QueryExpression as your serialisation format, because it would create headaches for your 'edit filter' UI (you would need to unpick a potentially arbitrary deserialised query and map it to your UI). A better bet is probably to create a user-defined filter class that reflects the kinds of queries you want users to be able to create, and a serialisation format specific to that class (e.g. XmlSerializer). You could then map filter objects to LightSpeed queries. The mapping from user-defined filter to LightSpeed query would be one-way so you wouldn't need to worry about unpicking LightSpeed queries; your filter type would always be the master. If you do want to use a LightSpeed Query object for serialisation, though, the Query and QueryExpression classes are both marked [Serializable], so can be serialised and deserialised using an IFormatter (e.g. BinaryFormatter, SoapFormatter). Haven't tried this though! Variables would be a bit tricky: you could easily put placeholders into the serialised query, but populating those placeholders would be a bit tricky as we don't expose methods for traversing and transforming the QueryExpression graph -- you would probably have to implement a visitor. Another possibility could be to use Dynamic LINQ fragments as these are plain text and should be reasonably simple to construct and parse; this would also take care of variable substitution. |
|
|
|
|
Point taken. I'll create custom serializable objects and map it to a query |
|
|
|
