make *navbox work when included

Ticket

make *navbox work when included+status
make *navbox work when included+priority
make *navbox work when included+tag
make *navbox work when included+commit
 

 

 

make *navbox work when included+example

http://play.dwagn.org/play/navbox_testing - second inclusion is still horizontally narrower than how it appears in the top bar, offers no autocomplete, and when you hit return you now get a 404 error for the URL http://play.dwagn.org/*search?utf8=✓&_keyword=test ["test" intowas typed into the box.]

 

 


 

 

http://test.dwagn.org/wagn/search_bar_in_main - second inclusion of it is nonfunctional, nothing happens when you hit return, and no autocomplete.

 

http://test.dwagn.org/wagn/search_bar_in_sidebar - too narrow (horizontally).

 

Also, in either place it adds an extra line after unnecessarily, which begins with a thin vertical line.

 

I'm pretty sure I remember it working earlier. --John


my guess is that there can currently only be one per page.

  --Ethan McCutchen.....Thu Jan 20 21:19:55 -0800 2011


That may be it - perhaps I was playing with putting it in the sidebar instead of the header.

  --John Abbe.....Thu Jan 20 22:02:14 -0800 2011


Now there's no limit on the number per page, but it will only work if it's there on the initial load of the page. If it appears after an ajax load, it won't work yet.

  --Ethan McCutchen.....Mon Dec 05 12:42:42 -0800 2011


make navbox work when ajax loaded

  --Ethan McCutchen.....Mon Dec 05 12:43:21 -0800 2011


1. narrowness - this is CSS issue. Its width is set by default to 30% of its enclosing div (which is the full top bar for the regular menu, and the card-slot for others). That's another skin issue.

 

2. 404. good catch. this was a "non-root" bug, meaning that the address would have worked if it had the extra "/play" at the beginning. That's fixed.

 

3. no autocomplete. That's weird, I'm seeing it offer autocomplete just fine. I have seen autocomplete not work on various occasions when I'm clicking around a bunch, but I haven't figured out the pattern. maybe you tried it when it was just loaded by ajax (see previous comment)?

  --Ethan McCutchen.....Thu Dec 22 10:02:20 -0800 2011


1 - cool, added it to Make Wagn skinnable.

2 - great.

3 - It works for me when i first load the page. I played with it a bit and found two things you can do after which autocomplete fails:

Click on the "View" tab of "navbox testing"

Click anywhere in the white space to the right of the navbox.

 

4 - Now that I get search results, I see that the *search card is being included in open view - http://play.dwagn.org/play/*search?utf8=✓&_keyword=dog rather than content view as it has been - http://www.wagn.org/search/dog

 

5 - That URL is pretty arcane, any chance of getting stuff like http://play.dwagn.org/play/search/dog to work again? If not now, I will ticket...

  --John Abbe.....Thu Dec 22 16:01:44 -0800 2011


6 (& 3) - double-clicking in the included navbox at http://play.dwagn.org/play/navbox_testing offers to edit *navbox. If you click on view, then autocomplete reliably fails to work.

  --John Abbe.....Thu Dec 22 17:00:29 -0800 2011


7 - Another minor point - the right margin on the selected item in the autocomplete menu is too small:

  --John Abbe.....Thu Dec 22 17:21:25 -0800 2011


3 & 6. so far it looks to me like this is all part of the already-ticketed ajax issue. clicking view is an ajax call. I'm not as clear on the white space thing; I wasn't able to make that happen except when there had already been an ajax call.

 

4. re the open view, I saw that and tried to fix it. I think it worked when clicking the menu (which uses javascript) but not when just hitting enter before the autocomplete loads (which doesn't). I may have this fix coded, but this actually adds an arg to

 

5. this is the complicated one. the short answer is that I want to work towards a standard query that looks like this: /*search?term=whatever Let's look at the parts:

1. search -> *search. I think this is valuable, because *search is the card name. We're also switching to *recent

2. ? vs. /. In order to use the RESTful Web API, it really should be ?params. All the slash urls will be deprecated soon.

3. the utf8 is put there by rails to handle encoding weirdness in ie, but it really doesn't need to be there for GET forms like this one in which the data will never go into the db. I've coded around this.

4. _keyword= I think we should probably switch this to just term=; this will soon be easier; I've actually done a bunch of the coding for it but haven't yet merged it into the main develop branch yet. the value in having this versus nothing at all is that this is a pattern that will be generalized to searches with many variables

5. view=content. For now, I think this is going to have to be in the url.

 

More generally speaking, the great value in getting away from lots of custom special urls and using ONLY the simple patterns of our rest api is that we can move all of the design logic into our "pack system" and away from controllers. I'm going to be blogging somewhat extensively about the advantages of our new architecture over MVC, but for now the point is just that this is not a casual flip but part of a move to some very elegant reusable patterns.

 

7. yeah, that's annoying. I'll see what I can do about that.

  --Ethan McCutchen.....Sat Dec 24 12:43:25 -0800 2011


update:

 

3 (ticketed)

4 fixed?

5 for now it's going to be /*search?view=content&_keyword=<term>. I'm now thinking the short form of the final url should be /*search?content&term=<term> (though, of course, /*search?term=<term> would give open view). we can also ticket clean up default search url if we want to track this

6 ticketed

7 haven't looked yet.

  --Ethan McCutchen.....Sat Dec 24 14:24:30 -0800 2011


ok, I *sorta* fixed the margin thing. Or, at least, I made it the same on both sides -- very little padding. That's more like the default jquery behavior, which is probably good to use for our default wagn behavior.

  --Ethan McCutchen.....Sat Dec 24 14:35:25 -0800 2011


mostly sounds good (5 moved to clean up default search url ). On 4, you trailed off with, "I may have this fix coded, but this actually adds an arg to "

  --John Abbe.....Sat Dec 24 18:29:21 -0800 2011


I'm still able to disable automplete by going through a few iterations of clicking to the right of the navbox, then back in it, deleting and typing.

  --John Abbe.....Sat Dec 24 18:42:10 -0800 2011


"actually adds an arg to".. the url. the view=content part.

 

I can't reproduce the disabling. I typed a, clicked, back in, deleted, then b and repeated, then c. I got up to j or k and never had any issues. Is there something more to it?

  --Ethan McCutchen.....Tue Dec 27 13:22:41 -0800 2011


OK, I think I was misunderstanding.

 

On the issue of double clicking within the navbox, I just made a patch to fix that.

 

If you're talking about double clicking in the including card to the right of the actual navbox, and the including card is going to edit and back, then that's the same make navbox work when ajax loaded issue we've ticketed. So while we've got some work left, it looks like they're all ticketed elsewhere and we can close this.

  --Ethan McCutchen.....Fri Feb 03 12:00:38 -0800 2012