> > Assume we're showing items 1-10 gathered from the CLSQL store;
> > then we will never filter the rest of the items at all (because
> > DATASEQ-DATA
> > will only work on the paginated set). This is not how the original
> > isearch
> > worked and messes with your expectations.
>
> Thanks for your explanation.
>
> I've made a completely rewritten version taking this into account.

I recently ran into this as our dataset grew, so thanks for doing
this!


> > That would be great. The current version would need some minor
> > beautification, a fix for the problem above and ideally some tests.
>
> One major issue is that if isearch box is marked dirty then when the
> ajax call comes back, it will overwrite any further user input. This is
> extremely annoying with slow AJAX.
>

Yes, we had this issue too. Since ours is an internal app the problem
wasn't too severe. The UI person actually insisted that for most
users, they would expect to press enter before the ajax went off and
did it's thing.

A version that does things this way is at http://paste.lisp.org/+1U15
with supporting annotations (but note it suffers from the earlier
problem of paginated data sets not being properly searched).

I haven't looked at your code yet, but fwiw, in our case moving the
searchbox to the top was handled by css absolute positioning.

Caveat: we've made a decision to go all desktoppy and so most of our
code requires JS. We also require JS because we're trying to make our
forms more dynamic and have a pressing need to have form elements
interact with each other. So if degradability is important the old
render-isearch with the Prototype timeout/delay would be more
suitable.

> I would like to fix this before tidying up. Maybe the mixin approach is wrong?

I had intended for this to be fairly easy to derive from if search
functionality was required; and to be ignored if not. But considering
the other issues that have been brought up I think it should be folded
into the gridedit hierarchy somewhere once the stores abstraction
takes shape. I still think that could be left to an advanced search
and the simple search should be almost like emacs C-s or vim /-search.




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"weblocks" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/weblocks?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to