Update tags popup to jQuery

[mjy]

The Tag model uses a polymorphic relationship to allow for the association of Keyword, Ref, notes, with any object in mx that has a primary key id.

The popup is found throughout the application, it is accessed by clicking the 'tag' links.

To generate baseline data quickly create a new Keyword, and several new OTUs, and other new records of choice, to test that cross-model functionality is working.

Pertinent files are in all the standard Rails places.

The t_cell_obj_actions method in app/helpers/app/display_helper.rb show how a Tag link is rendered in list context. See also the tag_link_for_show method in the Tag helper.

The same functionality is needed in mx3 with the following exceptions;

• The popup should be modal (http://jqueryui.com/demos/dialog/#modal), with the background 50% opaque
• The popup should be centered in the display window

Notes

• Native mx javascript in jQuery is preferred rather than bringing in a modal/dialog library that already exists.
• Near identical functionality is required for the Figure and Sensu popups, so a baseline modal popup that we can inject forms into would be good (see Fig links, to be a future task). The figure popup has a nested form inside it, it's a little more complicated.

[caryfitzhugh]

In regard to your comment about the native mx javascript in jQuery --

I have found that modal dialogs are usually crazy complicated for what we are usually doing. I wrote a simple modal dialog for ziplist. an example is shown here: http://i.imgur.com/uzHke.png Go to white-label.ziplist.com, sign up, and then click 'Email' to email the list. You'll see the little ajax spinner, then the modal pops up.

If you like that design - I can whip some stuff up pretty quickly.

The cool part about that modal is that there is very little JS involved, just divs and background images, and CSS3.
So it's real quick and light.

Can write a library which handles simple modal workflows and we drop it into mx.

My rough guess about 3 hours to package up the JS for a modal plugin which shows / hides modals and then attaches to anchors in the HTML. I'll have to look at the content for an estimate on the rest.

Gotta head to bed. I'll look at this more in a bit.

[caryfitzhugh]

Thoughts:

Attach to

a[data-modal]

content which has 'close-modal' classes will close the modal when pressed.

[mjy]

The plan sounds good and I like the ziplist example, it is right on (I assume we can style it differently). At present we don't really have multi-modal (popup->popup->popup resolve in stack order) except in one place- and that's about to be redone by our other programmer, so don't worry about that quite yet. So while this case is "modal"- it really is simple like you noted.

[caryfitzhugh]

I have something working for now: http://i.imgur.com/ZU7b4.png

you add 'data-basic-modal' to any anchor, and it's HREF will be retrieved with AJAX, and then put into the modal. You add 'data-basic-modal-width' to give the width of the resulting modal.

I'm pushing it now... will document it more tmw, and look at hooking it into the system as well...

[mjy]

Just pulled. Looks good. A modal like this greatly simplifies the requests- before I was doing some hiding of the link, then showing it again, so that it couldn't be clicked on- now that can just go away when the form is submitted or closed.

[caryfitzhugh]

Question:

http://i.imgur.com/nK82s.png

On this page, on the left, it looks like a list of 'show' pages. which just show some extra info about the OTU. Would you want just to have a modal dialog for each of those? Or just put them all in the page, and use an accordian display?

[caryfitzhugh]

I've spent a bit of time -- but don't know for sure about all these estimates...

I think to recreate (there is no tag#new partial anymore?) the new page is probably about 1 hour, incl a few tests written. I have a feeling I'll need to add a few bits of logic to the modal dialog page - or something, so that when you click ok on the modal, it updates the page.

I can see the OTU needs to be tagged, I'm a bit more hesitant on this part, b/c it's more controller stuff... maybe conservative estimate is 2 hours for the first one... might be sooner.
Maybe 0.5 hour for each other things to tag. By the end it's probably going to be pretty quick.

What is the list of things that can be tagged? OTU, 1 Characters 1 Matrices 1 Material / * all the sub parts. (7) Refs, Serials Data Sources

I looked through and it seems there are about 15 things that need to be tagged.

So - conservative estimate would be about 10 hours to put the tag modal on each of these records.

Let me know what you think... Maybe I'm misunderstanding something or missing something. I think each one of these Tag links will just call the tag controller, do the 'new' action - and then save it to the db.

How do you edit a tag? Do we need to have a tag edit modal as well?

Lastly, sorry I've been out of touch this week - had a big release to finish before friday.. But it's done now. :)

[mjy]

Let's keep questions like this: Question:

http://i.imgur.com/nK82s.png

On this page, on the left, it looks like a list of 'show' pages. which just show some extra info about the OTU. Would you want just to have a modal dialog for each of those? Or just put them all in the page, and use an accordian display?

as new issues so we can keep the discussion focused there.

[mjy]

Back to tags. Like the picker code the tag code is universal, we don't have to fix it in all those places, we just create one general purpose form (/tag/_popup in edge, serves as the "new") that serves any model that can be tagged (and that's any model that has a primary key of "id"). If you follow the example calls in the first post you'll see what is going on.

I'm going to spend some time this weekend messing with what you've provided and will ping you if I hit a wall- I think what you've provide gets us 85% there.

Another task coming shortly.

[mjy]

Some new code available (realize I need to make my commit messages contain info that I'm putting here). Just need you to work on submitting the form, and dealing with either sucessfull creation of a new tag, or updating the modal when the save fails.

[caryfitzhugh]

I am not familiar with this particular referece:

  # TODO: replicate the edge include_js that checks for google cs. local

Does that simply check if we are in dev mode and serve the local file vs serving the CDN file?

[mjy]

https://github.com/ratbeard/include_google_js

On the edge/production branch, see vendor/plugins/include_google_js, and statements like this in the layout- <%= javascript_include_tag(:defaults, :include_google_js => true, :versions => {:scriptaculous => "1.8.1", :prototype => "1.6.1"}, :type => 'text/javascript') -%>

Not sure if this is relevant or not in the new setup- particularly if we run with jammit (sp?).

On Tue, Sep 6, 2011 at 10:27 PM, caryfitzhugh reply@reply.github.com wrote:

I am not familiar with this particular referece:

     # TODO: replicate the edge include_js that checks for google cs. local

Does that simply check if we are in dev mode and serve the local file vs serving the CDN file?

Reply to this email directly or view it on GitHub: https://github.com/mx3/mx/issues/5#issuecomment-2024833

[caryfitzhugh]

In jammit, I'd recommend we just go with one asset bundle, minify and gzip it, and the 1st time they come it takes a tad longer, but then it's always zippy after that.

If we do that, then a lot of these alternative optimizations kindof aren't worth it. At least that's what we're doing on Ziplist. We tried being fancy with asset bundles, but when it came down to it - it seemed simplest, and in general the best decision for performance, to just bundle it once, let them download it, and be done with all the complexity (and bugs).

But we have the luxury of looking fine w/o javascript, so we load our bundle at the end of the DOM loading - so the page loads up, looks fine, people can see what it's all about, and then - while they are reading content, we're loading the slightly less-optimized bundle in parallel.

Anyway...

On Tue, Sep 6, 2011 at 10:42 PM, Matt < reply@reply.github.com>wrote:

https://github.com/ratbeard/include_google_js

On the edge/production branch, see vendor/plugins/include_google_js, and statements like this in the layout- <%= javascript_include_tag(:defaults, :include_google_js => true, :versions => {:scriptaculous => "1.8.1", :prototype => "1.6.1"}, :type => 'text/javascript') -%>

Not sure if this is relevant or not in the new setup- particularly if we run with jammit (sp?).

On Tue, Sep 6, 2011 at 10:27 PM, caryfitzhugh reply@reply.github.com wrote:

I am not familiar with this particular referece:

 # TODO: replicate the edge include_js that checks for google cs.

local

Does that simply check if we are in dev mode and serve the local file vs serving the CDN file?

Reply to this email directly or view it on GitHub: https://github.com/mx3/mx/issues/5#issuecomment-2024833

Reply to this email directly or view it on GitHub: https://github.com/mx3/mx/issues/5#issuecomment-2024928

[mjy]

Sounds good to me. Bugs definitely are an issue with third party stuff- I had to spend time working them out on the include package several times. It definitely sped things up though for us- but then again pretty much anything would based on vanilla.

We might ultimately (way down the road) consider two packages- one for "private", and one for "public". I don't mind at all if private is slow to to hit at first. The public stuff should all really be a completely different app, with caching etc., but that's a story for another day.

On Tue, Sep 6, 2011 at 11:05 PM, caryfitzhugh reply@reply.github.com wrote:

In jammit, I'd recommend we just go with one asset bundle, minify and gzip it, and the 1st time they come it takes a tad longer, but then it's always zippy after that.

If we do that, then a lot of these alternative optimizations kindof aren't worth it.  At least that's what we're doing on Ziplist.  We tried being fancy with asset bundles, but when it came down to it - it seemed simplest, and in general the best decision for performance, to just bundle it once, let them download it, and be done with all the complexity (and bugs).

But we have the luxury of looking fine w/o javascript, so we load our bundle at the end of the DOM loading - so the page loads up, looks fine, people can see what it's all about, and then  - while they are reading content, we're loading the slightly less-optimized bundle in parallel.

Anyway...

On Tue, Sep 6, 2011 at 10:42 PM, Matt < reply@reply.github.com>wrote:

https://github.com/ratbeard/include_google_js

On the edge/production branch, see vendor/plugins/include_google_js, and statements like this in the layout-  <%= javascript_include_tag(:defaults, :include_google_js => true, :versions => {:scriptaculous => "1.8.1", :prototype => "1.6.1"}, :type => 'text/javascript') -%>

Not sure if this is relevant or not in the new setup- particularly if we run with jammit (sp?).

On Tue, Sep 6, 2011 at 10:27 PM, caryfitzhugh reply@reply.github.com wrote:

I am not familiar with this particular referece:

     # TODO: replicate the edge include_js that checks for google cs. local

Does that simply check if we are in dev mode and serve the local file vs serving the CDN file?

Reply to this email directly or view it on GitHub: https://github.com/mx3/mx/issues/5#issuecomment-2024833

Reply to this email directly or view it on GitHub: https://github.com/mx3/mx/issues/5#issuecomment-2024928

Reply to this email directly or view it on GitHub: https://github.com/mx3/mx/issues/5#issuecomment-2025031

[caryfitzhugh]

Status update:

Almost done with JS to open the modal, and attach to any elements inside the modal. Ajaxify plugin is going - the create buttons are now submitting with AJAX, but the response is not being handled correctly. The response also needs to have the 'shake' / 'error' messages shown clearer.
Hope to get to those tmw and have the "Tag" modal working.

[mjy]

Excellent, nice work.

On Wed, Sep 7, 2011 at 12:02 AM, caryfitzhugh reply@reply.github.com wrote:

Status update:

Almost done with JS to open the modal, and attach to any elements inside the modal. Ajaxify plugin is going - the create buttons are now submitting with AJAX, but the response is not being handled correctly. The response also needs to have the 'shake' / 'error' messages shown clearer. Hope to get to those tmw and have the "Tag" modal working.

Reply to this email directly or view it on GitHub: https://github.com/mx3/mx/issues/5#issuecomment-2025339

[caryfitzhugh]

Ok - so I got the JS going for the modal. The AJAX create action is good. Got the response correct when you do something wrong.

Added a jquery notification plugin so that when you have flash messages they are automatically displayed. And added the flash data in x-JSON header whenever you are doing XHR. And a few flash helpers.

What it means is that you can just do :

def action_name notice "we're just doing a flash message here" end

and if you request action_name with XHR, that flash message will be slapped into the response headers, pulled out by the JS and pushed into the jquery notification at the top of the page. This is really useful, since the flash messages are not shown in xhr requests, b/c they don't have a layout. It lets you avoid having to write code which is always checking 'request.xhr?' everywhere... anyway. hopefully it turns out well.

I'll try to do a bit more tmw. I still haven't completed a 'successful' tag workflow.

I guess I'll start on the easy one (for me) - tagging an OTU from the index page - with all the OTUs there. I'm going to try to put all the parameters into the new_tag_tag helper, so that the tag controller is not looking for all sorts of classes and page elements to manipulate. Don't know yet if we can.. but.. :) We'll see.

Thanks

[mjy]

Updated the keyword dropdown and #create method so that tags successfully create now. Still some issues, see todo in tag controller.

[caryfitzhugh]

I saw the commits. :)

Not sure about the tag cloud just yet. I think I have a plan for that but haven't gotten to it.

Going to bed now. Pushed up some more stuff...

Last thing I found and stopped at was the delete_tag_link. Link_to_remote is no longer a function? Regardless, I tend to do them as a small html form.

But should that be another ticket, or this current one?

Thanks, Cary

On Sat, Sep 10, 2011 at 11:14 PM, Matt < reply@reply.github.com>wrote:

Updated the keyword dropdown and #create method so that tags successfully create now. Still some issues, see todo in tag controller.

Reply to this email directly or view it on GitHub: https://github.com/mx3/mx/issues/5#issuecomment-2062321

[caryfitzhugh]

THen again... maybe we should do something where the tag clouds 'listen' to the ajax events. and when one fires like 'ajax:success' or something -- we can have the tag cloud reload itself with ajax... dunno...

just an alternative to passing a bunch of complicated stuff throguh the tag system.

might be a better approach... we'll see.

On Sat, Sep 10, 2011 at 11:45 PM, Cary FitzHugh cary.fitzhugh@gmail.comwrote:

I saw the commits. :)

Not sure about the tag cloud just yet. I think I have a plan for that but haven't gotten to it.

Going to bed now. Pushed up some more stuff...

Last thing I found and stopped at was the delete_tag_link. Link_to_remote is no longer a function? Regardless, I tend to do them as a small html form.

But should that be another ticket, or this current one?

Thanks, Cary

On Sat, Sep 10, 2011 at 11:14 PM, Matt < reply@reply.github.com>wrote:

Updated the keyword dropdown and #create method so that tags successfully create now. Still some issues, see todo in tag controller.

Reply to this email directly or view it on GitHub: https://github.com/mx3/mx/issues/5#issuecomment-2062321

[mjy]

Looking good. I like the top fading notice. Go ahead and fix the delete link here, but let's open a new issue for the tag clouds and "metatags" functionality. The image figuring popup is very similar to the tag, but a little trickier, I'll add an issue and we'll tackle it or the ajax pagination, next.

[caryfitzhugh]

ok. will do. when I get working on this again I'll knock out the delete link and close out the issue.

Thanks.

On Sat, Sep 10, 2011 at 11:51 PM, Matt < reply@reply.github.com>wrote:

Looking good. I like the top fading notice. Go ahead and fix the delete link here, but let's open a new issue for the tag clouds and "metatags" functionality. The image figuring popup is very similar to the tag, but a little trickier, I'll add an issue and we'll tackle it or the ajax pagination, next.

Reply to this email directly or view it on GitHub: https://github.com/mx3/mx/issues/5#issuecomment-2062403

[mjy]

I like the listening idea a lot- can envision a number of other uses for similar functionality.

[caryfitzhugh]

Ok - so I got delete's done. Ajaxy. :)