OK, let me get working on a reference implementation of WebHelpers, and then you can update the Paginator to match it. There will be a WebHelpers task during the Pylons/TurboGears sprint at PyCon, so I should have something ready after that.
On Mon, Mar 3, 2008 at 2:13 AM, Christoph Haas <[EMAIL PROTECTED]> wrote: > When we talked about JS support a while ago you considered creating an > abstract module or something that other parts of the webhelpers could > use. I can't really imagine how that would work because the JS libraries > work very differently. Did you get any results out of that idea yet? > If there were such a thing as a "Webhelpers Javascript API" then I could > use that. But I don't really expect that. :) That was left to be designed later. Ben is planning a few small Javascript functions which won't depend on any library. So something like link_to_remote. If there are any functions you think are particularly important, please let me know. I haven't used JS much so I don't know what's needed. h.url_for will exist but not in WebHelpers. It will proabably be imported from Routes directly into pylons.helpers. For now, please make your own shadow functions for framework-specific details (url_for, session use, GET params, etc). When we figure out how WebHelpers will access framework services,then you can update those portions. Is h.url() really needed? It "lazily evaluates url_for arguments". Um, why? It's not like Routes is overhead-intensive. I think h.url is just a Railsism that can go away. (The name may be used for the url_for function, but 'url' is a very common local variable name in user code, so I'm not sure it's a good idea.) > The only place in the module where JS is used is the "_pagerlink()" > function which consists of ~20 lines of code for 4 different JS > frameworks. Not really enough to create another module of it that I > would want to upload to PyPi. I wonder if I should rather provide a > callback hook so everybody can hook in their function that creates the > links. The documentation can provide examples for such functions > (perhaps ~5 lines of code) and the paginate module can do without any > JS. I'll leave you to figure this out. Certainly, providing standard implementations for the major JS libraries would be a good thing. > The main thing I'm scared of is breaking the API. But I assume that the > webhelpers have to face a 90% API breakage anyway. WebHelpers will be quite incompatible, so this is a good time to make any API changes. Those who want compatibility can use the older versions of WebHelpers and your module. -- Mike Orr <[EMAIL PROTECTED]> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en -~----------~----~----~----~------~----~------~--~---
