August 2007 - cl-weblocks-ticket@common-lisp.net

[cl-weblocks-ticket] #22: Consider lazy session initialization
by cl-weblocks 16 Jun '08

16 Jun '08

#22: Consider lazy session initialization -----------------------------------------+---------------------------------- Reporter: sakhmechet | Owner: sakhmechet Type: enhancement | Status: new Priority: low | Milestone: 0.2 Component: weblocks | Version: pre-0.1 Keywords: lazy initialization session | -----------------------------------------+---------------------------------- Currently when a session is initialized in 'init-user-session', all widgets are instantiated at once. We should make this process lazy and instantiate widgets as necessary (perhaps via hooks from the navigation widget?) Additionally, we should consider freeing hidden widgets for garbage collecting. -- Ticket URL: <http://trac.common-lisp.net/cl-weblocks/ticket/22> cl-weblocks <http://common-lisp.net/project/cl-weblocks> cl-weblocks

1 5

[cl-weblocks-ticket] #6: Handling and reporting errors
by cl-weblocks 30 Apr '08

30 Apr '08

#6: Handling and reporting errors ------------------------------------+--------------------------------------- Reporter: sakhmechet | Owner: sakhmechet Type: enhancement | Status: new Priority: medium | Milestone: 0.1 Component: weblocks | Version: pre-0.1 Keywords: error handling failure | ------------------------------------+--------------------------------------- Currently when errors occur on AJAX requests (in both debug and release) there is a simple !JavaScript popup. When errors occur on regular requests (in release) there is a plain old error 500 page. We need to show debug information on AJAX requests in debug mode. Should we modify the popup (perhaps redirect to error page) when an error occurs on AJAX requests in release? For regular requests we need a prettier error page. We also need special handling of session timeout errors. When a session times out we should probably refresh the page and show a popup/flash saying a new session has been created. -- Ticket URL: <http://trac.common-lisp.net/cl-weblocks/ticket/6> cl-weblocks <http://common-lisp.net/project/cl-weblocks> cl-weblocks

1 3

[cl-weblocks-ticket] #21: Allow multiple search tokens in grid searchbar
by cl-weblocks 30 Apr '08

30 Apr '08

#21: Allow multiple search tokens in grid searchbar --------------------------------------------+------------------------------- Reporter: sakhmechet | Owner: sakhmechet Type: enhancement | Status: new Priority: low | Milestone: 0.2 Component: weblocks | Version: pre-0.1 Keywords: grid searchbar tokens multiple | --------------------------------------------+------------------------------- Currently it's possible to search for only one token in the searchbar. The search mechanism should be made more intelligent. It should be possible to separate tokens with delimiters, use quotes to turn off delimiting tokens, etc. -- Ticket URL: <http://trac.common-lisp.net/cl-weblocks/ticket/21> cl-weblocks <http://common-lisp.net/project/cl-weblocks> cl-weblocks

1 1

[cl-weblocks-ticket] #50: Automatically diff actual and expected output in deftest-html
by cl-weblocks 18 Apr '08

18 Apr '08

#50: Automatically diff actual and expected output in deftest-html -------------------------+-------------------------------------------------- Reporter: anonymous | Owner: sakhmechet Type: enhancement | Status: new Priority: low | Milestone: 0.1 Component: weblocks | Version: pre-0.1 Keywords: | -------------------------+-------------------------------------------------- Currently when unit tests that are defined with deftest-html macro fail, it's very hard to tell the difference between actual and expected HTML, especially if the output is long. It's usually necessary to invoke ediff- buffers in Emacs (or some other diff utility). Automatically diffing actual and expected output and presenting the diff as a result of a failed test would significantly ease debugging. This could be done with CL-HTML-DIFF or CL-DIFFLIB library. -- Ticket URL: <http://trac.common-lisp.net/cl-weblocks/ticket/50> cl-weblocks <http://common-lisp.net/project/cl-weblocks> cl-weblocks

1 4

[cl-weblocks-ticket] #28: Rename 'datagrid' widget to 'grid'
by cl-weblocks 18 Apr '08

18 Apr '08

#28: Rename 'datagrid' widget to 'grid' ----------------------------------+----------------------------------------- Reporter: sakhmechet | Owner: sakhmechet Type: defect | Status: new Priority: low | Milestone: 0.1 Component: weblocks | Version: pre-0.1 Keywords: rename datagrid grid | ----------------------------------+----------------------------------------- There is no reason to call datagrid widget 'datagrid'. 'Grid' is a much better name. We should rename the widget. -- Ticket URL: <http://trac.common-lisp.net/cl-weblocks/ticket/28> cl-weblocks <http://common-lisp.net/project/cl-weblocks> cl-weblocks

1 3

[cl-weblocks-ticket] #23: Create renderers for lists of items
by cl-weblocks 18 Apr '08

18 Apr '08

#23: Create renderers for lists of items --------------------------------------------+------------------------------- Reporter: sakhmechet | Owner: sakhmechet Type: enhancement | Status: new Priority: medium | Milestone: 0.2 Component: weblocks | Version: pre-0.1 Keywords: renderers snippets lists items | --------------------------------------------+------------------------------- We should create renderers (or snippets?) to render lists of items (ordered, unordered, etc.) as this is a fairly common operation. We should consider rewriting current widgets that use lists to take advantage of this functionality. -- Ticket URL: <http://trac.common-lisp.net/cl-weblocks/ticket/23> cl-weblocks <http://common-lisp.net/project/cl-weblocks> cl-weblocks

1 2

[cl-weblocks-ticket] #44: ajax isearch will sometimes drop a callback in Firefox.
by cl-weblocks 18 Apr '08

18 Apr '08

#44: ajax isearch will sometimes drop a callback in Firefox. -------------------------------+-------------------------------------------- Reporter: anonymous | Owner: sakhmechet Type: defect | Status: new Priority: critical | Milestone: Component: weblocks | Version: Keywords: prototype firefox | -------------------------------+-------------------------------------------- Sometimes, at least when a table is populated with more data than in the default example (try creating a table with 30 rows), an exception will be trown by Firefox because the "status" element in an nsIXMLHttpRequest is being accessed. How to reproduce: Add a longer list of employees to the grid1 in application.lisp: {{{ (list employee1 employee2 employee3 employee1 employee2 ...<30 more>) }}} Reduce the latency to 0.1 seconds in isearch.lisp, line 31. {{{ (with-javascript "~ new Form.Element.DelayedObserver('~A', 0.1, function(elem, value) {~ initiateFormAction('~A', $('~A'), '~A'); });" }}} Install firebug, and set a brakepoint at roughly line 1114 in prototype.js {{{ } catch (e) { 1114 this.dispatchException(e); <--- breakpoint on this line. 1115 } }}} After playing around with the isearch, you will see the following exception being thrown (really by the nearby success() function): {{{ [Exception... "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]" nsresult: "0x80040111 (NS_ERROR_NOT_AVAILABLE)" location: "JS frame :: http://foo.org:8090/pub/scripts/prototype.js :: anonymous :: line 1109" data: no] columnNumber 0 data null filename "http://foo.org:8090/pub/scripts/prototype.js" inner null lineNumber 1109 location JS frame :: http://foo.org:8090/pub/scripts/prototype.js :: anonymous :: line 1109 language=2 languageName=JavaScript message "Component returned failure code: 0x80040111 (NS_ERROR_NOT_AVAILABLE) [nsIXMLHttpRequest.status]" name "NS_ERROR_NOT_AVAILABLE" result 2147746065 QueryInterface QueryInterface() initialize initialize() }}} From what I understand from random readings on the web, this can be caused by reading the nxIXMLHttpRequest.status in an onError handler (which does not seem to happen in this case), or it can happen if the ajax request is being aborted. -- Ticket URL: <http://trac.common-lisp.net/cl-weblocks/ticket/44> cl-weblocks <http://common-lisp.net/project/cl-weblocks> cl-weblocks

1 3

[cl-weblocks-ticket] #42: Sorting and regex filtering should be refactored out of datagrid
by cl-weblocks 06 Feb '08

06 Feb '08

#42: Sorting and regex filtering should be refactored out of datagrid -----------------------------------------------------------------+---------- Reporter: sakhmechet | Owner: sakhmechet Type: enhancement | Status: new Priority: medium | Milestone: 0.2 Component: weblocks | Version: pre-0.1 Keywords: sorting filtering searching regex refactor datagrid | -----------------------------------------------------------------+---------- Currently sorting and regex filtering/searching mechanisms are specific to the datagrid. It seems like these mechanisms could be used in other widgets. We should refactor these components and make them generic for use by other widgets. -- Ticket URL: <http://trac.common-lisp.net/cl-weblocks/ticket/42> cl-weblocks <http://common-lisp.net/project/cl-weblocks> cl-weblocks

1 2

[cl-weblocks-ticket] #8: Back button rules should be respected
by cl-weblocks 27 Dec '07

27 Dec '07

#8: Back button rules should be respected ---------------------------------+------------------------------------------ Reporter: sakhmechet | Owner: sakhmechet Type: defect | Status: new Priority: low | Milestone: 0.1 Component: weblocks | Version: pre-0.1 Keywords: back button history | ---------------------------------+------------------------------------------ We should consider improving the consequences of hitting the back button. Currently only navigation control actions are recorded in the browser's history. We can get around this by updating AJAX actions with an anchor at the end of the URL and support proper back button this way. Is this the right thing to do? -- Ticket URL: <http://trac.common-lisp.net/cl-weblocks/ticket/8> cl-weblocks <http://common-lisp.net/project/cl-weblocks> cl-weblocks

1 2

[cl-weblocks-ticket] #7: Widgets should be able to optionally expose state on the URL
by cl-weblocks 27 Dec '07

27 Dec '07

#7: Widgets should be able to optionally expose state on the URL ----------------------------------+----------------------------------------- Reporter: sakhmechet | Owner: sakhmechet Type: enhancement | Status: new Priority: medium | Milestone: 0.1 Component: weblocks | Version: pre-0.1 Keywords: navigation state URL | ----------------------------------+----------------------------------------- Currently the only widget that can expose state on the URL is Navigation. Widgets like Grid cannot expose state. This makes the user run into very annoying issues similar to the ones common to Expedia/Travelocity - someone sends a link to a hotel to a friend, but the friend sees a completely different page. As an example, grid controls should be able to optionally expose which column they're sorted on. People should be able to navigate to a product page by product name/id on the URL. -- Ticket URL: <http://trac.common-lisp.net/cl-weblocks/ticket/7> cl-weblocks <http://common-lisp.net/project/cl-weblocks> cl-weblocks

1 5