« Return to Thread: A question on code quality

RE: Re: A question on code quality

by mikewse :: Rate this Message:

Hi Jose,

My feedback on the general question is that, as DWR is a framework, I think users have a high expectation on correctness. So for me, that would favor correctness over performance in an initial version and then let the performance tweaks be done over time, rather than the other way around.

But then I would also be open for letting new parts of DWR be marked as "experimental" for a suitable amount of versions, to have them mature in place, as long as this is clearly stated in the docs. A bit like Dojo's dojox features but probably with a clearer indication on the current "quality" of the code.

Does this sound reasonable?

Best regards

Mike

From: Jose Noheda [mailto:jose.noheda@...]
Sent: den 25 juni 2009 17:17
To: users@...
Subject: [dwr-user] Re: A question on code quality

I've had a clever idea and got the cache working but I'm still interested on your opinions about minimum code quality and when good enough suffices.

Regards

On Thu, Jun 25, 2009 at 4:11 PM, Jose Noheda <jose.noheda@...> wrote:

Hi,

Currently the dojo store is heavy on the server. For example, each time a user opens a combo and selects one value the store launches two requests, even though they always return the same values. I've compiled a cache solution based on dojo's ClientFilter but it's, well, far from perfect. It works fine as long as the client has all the items. Unfortunately that's not the way some widgets work as they download data in chunks. If more data is required later dojo fires another petition. Things go well until you start to mix different types of queries and sub-queries in the same store. The store knows the max number of results the query can retrieve but doesn't know if the records currently there match this specific query or were downloaded by another one.

So, for example, the store knows that:

  * The current query has already been executed or is a sub-query of an already cached query

  * This query can only return X records

  * The store has already Y records in memory

  * X < Y

But it lacks the (important) knowledge of if those Y records were actually obtained from the cached query or something completely unrelated.

The solution here is to call the server anyway or redesign the store to keep track of each query sent and the results it contained.

The other posibility is to assume that a sub-query of a cached query with a max number of records lower than the store totals has all its items right there. I know it's not technically correct but my guts say I'm going to complicate the final solution just to solve a theoretical problem that just won't happen easily (at least inside dojo widgets). On the other hand, I'm very reluctant to committ a code with such a flaw.

Opinions?

Regards

PS.- Use case that highlights the problem:

1.- Create a store

2.- Query with "m*"

3.- Query with "j*"

4.- Query with "ma*"

This last query is a sub-query of a cached query but the record count is unreliable as it may include some obtained from 3)

« Return to Thread: A question on code quality