will move pointer item editor to JavaScript make it impossible to edit pointers with js off?

right, you can't use the pointer interfaces with it off. But that's always been the case. It used to rely on ajax stuff, so it was still js dependent. Now the js is unobtrusive and server calls are only made for autocomplete.

  --Ethan McCutchen.....Sun Dec 18 21:11:17 -0800 2011

there will definitely be things that still don't work (or work oddly) with js off. I don't suspect we'll decide all the work in this arena is done. We'll just have to see whether it makes more sense to leave this open or close it and spin off other issues. My guess is that they'll mostly be small and we'll want to keep this ticket. Let's make sure we're harvesting the actual issues into the +issue card above.

  --Ethan McCutchen.....Sun Dec 18 21:15:51 -0800 2011

"add another" link does not work. Ticket allow adding Pointer items with JavaScript off?

  --John Abbe.....Wed Feb 01 13:40:55 -0800 2012

no, we can't support that one. any functionality within an editor will be javascript only

  --Ethan McCutchen.....Wed Feb 01 13:46:11 -0800 2012

(but good catch!)

  --Ethan McCutchen.....Wed Feb 01 13:46:37 -0800 2012

To explain the rationale a bit, the thing to keep in mind is that any solution that does not involve javascript means that any time something on the page much change, the entire page must be reloaded. So for this case, we'd have to reload the entire page to add a single field. That restriction is the nature of the beast -- it's a constraint of the medium, not of Wagn.

So, in general, the kinds of actions that involve changes in the middle of a page (eg opening and closing cards, adding pointer fields, going into edit mode in the sidebar...) could only be accomplished without javascript if we build a sophisticated state-management infrastructure that would allow wagn to submit and recreate the state of an entire page. We can add that as an Idea, but we'd really need to make the business / strategy / purpose / impact case for tackling a challenge like that; I suspect it would be quite difficult to build, test, and maintain, but not impossible.

I can imagine this might be a little confusing, since this release includes a move to convert the main pointer editor to javascript. If it's impossible to do without javascript, then what was it before?

The answer is that it's actually always used javascript, but before it used AJAX (meaning it made server calls via javascript, but the server-side work was done in ruby), whereas now it all happens locally in javascript only. There are various reasons why the new model is stronger, but the key point here is that the old model wouldn't work with javascript turned off either.

So as we test this ticket, I would ask this question whenever we find something that doesn't work well without javascript: would it be possible to implement this without a sophisticated state management system? If so, we should track it elsewhere, perhaps on the state-management idea mentioned above. If not, then it might be worth saying this ticket is not yet ready to close.

In other words, our goal for this ticket should be to pick all the low-hanging fruit of stateless requests (like searches, new edit form page loads, new subtab page loads, etc), but to leave the higher-hanging stuff alone.

  --Ethan McCutchen.....Thu Feb 02 10:52:24 -0800 2012

Well, I clicked around for a while with javascript off, and I think it's fair to say that "basic" functionality is working. I was able to edit name, and (with a quick patch) type, to see all the tabs, navigate changes, etc. The above mentioned stuff can get wonky, and some advanced functionality (like the options tab) is not really usable, but that fits with the above and makes sense. If we find problems not covered by the above let's ticket them, but I think this is ready to close.

  --Ethan McCutchen.....Fri Feb 03 15:42:13 -0800 2012