I follow guide http://guides.joosy.ws/guides/blog/forms.html and try to create forms for new and edit post
So I create templates/pages/posts/_form.jst.hamlc with form and add code in pages/posts/new.js.coffee:
Joosy.namespace 'Posts', ->
class #NewPage extends ApplicationPage
#layout ApplicationLayout
#view 'new'
elements:
'rawForm': 'form'
#fetch (complete) ->
#data.post = Post.build()
complete()
#afterLoad ->
#form = Joosy.Form.attach #rawForm,
resource: #data.post
success: (data) => #navigate '/'
But "inner magic" doesn't work for me.. When I follow http://localhost:3000/blog#!/posts/new I see form for new post. This form submits as usual form. I.e. if I type something and press Save, it opens new page http://localhost:3000/blog?post%5Btitle%5D=test&post%5Bbody%5D=test#!/posts
So, I've stopped on this step and have no ideas what to do with that..
P.S. If you can retag this question to 'joosy' please do it. Author promises to answer questions about joosy framework here by 'joosy' tag, but I can't create this tag due to lack of reputation
You should check three things:
Check console for overall errors. It may fail before afterLoad. And this is javascript which just dies silently unless you watch errors.
Try to add console.log #rawForm in your afterLoad to ensure you get the correct DOM element binded.
Try to compare your code with working example: https://github.com/roundlake/joosy-example
And if 1/2 didn't work and you don't have much time, show me your template either cause this pages looks like a copy of this one: https://github.com/roundlake/joosy-example/blob/master/app/assets/javascripts/blog/pages/posts/new.js.coffee. But the latter is known to work. So trouble is not here.
Related
In an effort to have everything translateable in our website ( including the error messages for the validations ), we switched almost all of our forms to remote forms. While this helps with the ability to translate error messages, we have encountered other problems, like:
if the user clicks on the submit button multiple times, the action gets called multiple times. If we have a remote form for creating a new record in the database, and assuming that the user's data is valid, each click will add a new object ( with the exact same contents ). Is there any way of making sure that such things cannot happen?
Is there somewhere I could read about remote forms best practices? How could I handle the multiple clicks problem? Is switching all the forms to remote forms a very big mistake?
There is a rails 3 option called :disable_with. Put this on input elements to disable and re-label them while a remote form is being submitted. It adds a data-disable-with tag to those inputs and rails.js can select and bind this functionality.
submit_tag "Complete sale", :disable_with => "Please wait..."
More info can be found here
Easy, and you can achieve that in many ways depending your preferences:
Post the form manually simply using an ajax request and while you wait for the response disable/hide (or whatever you need) the form to ensure the user can't keep doing posts as crazy. Once you get the response from the server, again you can allow the user to post again (cleaning the form first), or show something else or redirect it to another page or again whatever you need.
Use link_to :remote=>true to submit the form and add a callback function to handle the response and also to disable/hide (or whatever you need) the form when it's submitted
Add a js listener to the form to detect when it's submitted and then disable/hide/whatever the form
As you see, there are lots of different ways to achieve what you need.
EDIT: If you need info about binding or handling a form submit from js here you'll find very easy and interesting examples that may help you to do what I suggested you! jQuery Submit
I have remote forms extensively myself, and in most cases I would avoid them. But sometimes your layout or UX demands for on-the-fly drop-down forms, without reloading or refreshing the complete page.
So, let me tackle this in steps.
1. Preventing Normal form double-post
Even with a normal form, a user could double-click your button, or click multiple times, if the user does not get a clear indication that the click has been registered and the action has started.
There are a lot of ways (e.g. javascript) to make this visible, but the easiest in rails is this:
= f.button :submit, :disable_with => "Please wait..."
This will disable the button after the first click, clearly indicating the click has been registered and the action has started.
2. Handling the remote form
For a remote form it is not that much different, but the difference most likely is: what happens afterward ?
With a remote form you have a few options:
In case of error: you update the form with the errors.
you leave the form open, allowing users to keep on entering the data (I think this is your case?)
you redirect the users to some place.
Let me handle those cases. Please understand that those three cases are completely standard when doing a normal form. But not when doing a remote call.
2.1 In case of error
For a remote form to update correctly, you have to do a bit more magic. Not a lot, but a bit.
When using haml, you would have a view called edit.js.haml which would look something like
:plain
$('#your-form-id').replaceWith('#{j render(:partial => '_form') }');
What this does: replace the complete haml with only the form. You will have to structure your views accordingly, to make this work. That is not hard, but just necessary.
2.2 Clearing the form
You have two options:
* re-render the form completely, as with the errors. Only make sure you render the form from a new element, not the just posted one!!
* just send the following javascript instead:
$('#your-form-id').reset();
This will blank the form, and normally, that would effectively render any following clicking useless (some client validation could block posting until some fields are filled in).
2.3 Redirecting
Since you are using a remote form, you can't just redirect. This has to happen client-side, so that is a tad more complicated.
Using haml again this would be something like
:plain
document.location.href = '#{#redirect_uri}';
Conclusion
To prevent double (triple, quadruple, more) posts using remote forms you will have to
disable the button after first click (use :disable_with)
clear the form after succesful submission (reset the form or render with a new element)
Hope this helps.
The simplest solution would be to generate a token for each form. Then your create action could make sure it hasn't been used yet and determine whether the record should be created.
Here's how I would go about writing this feature. Note that I haven't actually tested this, but the concept should work.
1.
Inside the new action create a hash to identify the form request.
def new
#product = Product.new
#form_token = session["form_token"] = SecureRandom.hex(15)
end
2.
Add a hidden field to the form that stores the form token. This will be captured in the create action to make sure the form hasn't been submitted before.
<%= hidden_field_tag :form_token, #form_token %>
3.
In the create action you can make sure the form token matches between the session and params variables. This will give you a chance to see if this is the first or second submission.
def create
# delete the form token if it matches
if session[:form_token] == params[:form_token]
session[:form_token] = nil
else
# if it doesn't match then check if a record was created recently
product = Product.where('created_at > ?', 3.minutes.ago).where(title: params[:product][:title]).last
# if the product exists then show it
# or just return because it is a remote form
redirect_to product and return if product.present?
end
# normal create action here ...
end
Update: What I have described above has a name, it is called a Synchronizer (or Déjà vu) Token. As described in this article, is a proper method to prevent a double submit.
This strategy addresses the problem of duplicate form submissions. A synchronizer token is set in a user's session and included with each form returned to the client. When that form is submitted, the synchronizer token in the form is compared to the synchronizer token in the session. The tokens should match the first time the form is submitted. If the tokens do not match, then the form submission may be disallowed and an error returned to the user. Token mismatch may occur when the user submits a form, then clicks the Back button in the browser and attempts to resubmit the same form.
On the other hand, if the two token values match, then we are confident that the flow of control is exactly as expected. At this point, the token value in the session is modified to a new value and the form submission is accepted.
I hate to say it, but it sounds like you've come up with a cure that's worse than the disease.
Why not use i18n for translations? That certainly would be the 'Rails way'...
If you must continue down this route, you are going to have to start using Javascript. Remote forms are usually for small 'AJAXy things' like votes or comments. Creating whole objects without leaving the page is useful for when people might want to create lots of them in a row (the exact problem you're trying to solve).
As soon as you start using AJAX, you have to deal with the fact that you'll have to get into doing some JS. It's client-side stuff and therefore not Rail's speciality.
If you feel that you've gone so far down this road that you can't turn back, I would suggest that the AJAX response should at least reset the form. This would then stop people creating the same thing more than once by mistake.
From a UI/UX point of view, it should also bring up a flash message letting users know that they successfully created the object.
So in summary - if you can afford the time, git reset and start using i18n, if you can't, make the ajax callback reset the form and set a flash message.
Edit: it just occurred to me that you could even get the AJAX to redirect the page for you (but you'd have to handle the flash messages yourself). However, using a remote form that then redirects via javascript is FUGLY...
I've had similar issues with using a popup on mouseover, and not wanting to queue several requests. To get more control, you might find it easier to use javascript/coffeescript directly instead of UJS (as I did).
The way I resolved it was assigning the Ajax call to a variable and checking if the variable was assigned. In my situation, I'd abort the ajax call, but you would probably want to return from the function and set the variable to null once the ajax call is completed successfully.
This coffeescript example is from my popup which uses a "GET", but in theory it should be the same for a "POST" or "PUT".
e.g.
jQuery ->
ajaxCall = null
$("#popupContent").html " "
$("#popup").live "mouseover", ->
if ajaxCall
return
ajaxCall = $.ajax(
type: "GET"
url: "/whatever_url"
beforeSend: ->
$("#popupContent").prepend "<p class=\"loading-text\">Loading..please wait...</p>"
success: (data) ->
$("#popupContent").empty().append(data)
complete: ->
$"(.loading-text").remove()
ajaxCall = null
)
I've left out my mouseout, and timer handling for brevity.
You can try something like that for ajax requests.
Set block variable true for ajax requests
before_filter :xhr_blocker
def xhr_blocker
if request.xhr?
if session[:xhr_blocker]
respond_to do |format|
format.json, status: :unprocessable_entity
end
else
session[:xhr_blocker] = true
end
end
end
Clear xhr_blocker variable with an after filter method
after_filter :clear_xhr_blocker
def clear_xhr_blocker
session[:xhr_blocker] = nil
end
I would bind to ajax:complete, (or ajax:success and ajax:error) to redirect or update the DOM to remove/change the form as necessary when the request is complete.
I'm working on a Ruby on Rails web app, in which I've got several lists of posts. Each post will use Ajax to load their comments. In order of populating them in the right place, I'm doing the following:
Each post has a div with an id formatted as follows: <div id="my_div_<%= post.id %>"></div>. So, for example if the post.id is 12, the id will be "my_div_12".
My controller's action looks like this:
render :update do |page|
page.replace_html 'my_div_' + params[:post_id].to_s, :partial => 'my_comments_section_partial_path'
end
That works fine only if I have a post only once at the page. But in this site, each post might be listed more than once, because there are several lists (latest posts, popular, tops, etc). And all of them will have their Comments section to show.
The issue now is that, as the comments section functionality is inside a partial view, it will work the same for every type of list (as it's expected), and therefore, it doesn't make the difference between the divs (because they will have the same post.id, and thus, the same div's id).
My question now is: how could I solv this problem? Is there a better and different way for doing this?
Thanks in advance!
EDIT:
Just to clarify what I want, in few words:
I would like the code page.replace_html 'my_div_' + params[:post_id].to_s, :partial => 'my_comments_section_partial_path' to replace that partial in EVERY div called 'my_div' + params[:post_id].to_s (because there may be more than one div in the same page with the same id).
Note that having several elements with the same id on one page produces technically invalid html. Many browsers won't even render all those id attributes (leaving one and erasing the rest).
One simple solution is to switch to using classes instead of ids. There can be multiple elements with the same class and each element can have more than one class.
I don't work with built-in ajax helpers in Rails, but google suggests it's possible.
It seems like you have two sets of posts on the same page and are worried about putting the comments for the correct post in the correct spot. I think making two Ajax requests would be fine. The URLs would probably be something like /posts/1/comments and /posts/2/comments. Essentially what you want is "all the comments for a given post". You could have a comments action on your posts controller to use your has_many :comments association from Post. Using the URL ID parameter you can supply the post ID. You could get the Post ID out of the markup through a custom ID attribute, a custom class, or a custom data-* attribute.
It looks like you're using RJS but I'd recommend using Prototype or jQuery to make the Ajax request and specify JSON data or HTML as the response, then append the JSON or HTMl in the correct spot.
In jQuery I'd grab the post ID, make the ajax request, then append the comment HTML. This is not tested, but roughly the idea in code.
var comments_div = $('.post .comments'); /* need a diff. comments div for each */
var post_id = $('.post').attr('data-post_id');
$.get({'/posts/'+post_id+'/comments', function(data){ comments_div.append(data); } });
In learning ruby on rails I've created a blog site. When the user adds a post via AJAX, the following rjs gets called:
page.replace_html 'posts', :partial => #posts
page.visual_effect :Highlight, 'post_' + #post.id.to_s
However, the highlight isn't happening.. neither is any sort of effect even a hide.
Clues:
It works if I just do an insert_html
for just the new post (but I want
to update the whole list of posts
at this time)
If I hard code the id to the next id in the sequence, it doesn't work on the post, but it does work on the next post. { ex.. hardcode post_100... no highlight on submit 100, highlight 100 on submit 101 }
Alert shows that 'post_' + #post.id.to_s is what is expected ( post_100, etc )
Any ideas or debugging suggestions?
Thanks,
Orlando
Can you alert the innerHTML of the $("post_#{#post.id}") before the visual_effect.
Does firebug give you an error when it gets to the visual_effect?
Can you do something else, like an alert after the visual_effect line?
Have you got the required js files included?
It's not really an answer to the problem, but I have since done away with reliance on rjs. Instead I'm following the pattern outlined here
http://blog.solnic.eu/2007/10/30/why-javascript-helpers-in-rails-are-evil
And now all effects are working as expected. Note that I did get the effect working when comments were added using effectively the same code that should have been working here, so I'm fairly convinced there was just some sort of weird operator error going on.
i m using rails 2.3.3 and web browser Firefox i have added ajax and java script and it is working too but i have to reload the page every time when i press Add to Cart button to show item additionn in the side bar it don’t show it without reloading.
anyone please help me how can it show item addition in side bar when i press Add to Cart button with out reloading the page?
If you haven't already done so, install Firebug for Firefox, for these reasons:
it'll tell you if you have a Javascript error.
it'll show you if your Ajax request is being received and its contents.
you can inspect your page elements such as the cart to see if it's set to be shown, if the ID is correct, etc. in a much faster way than browsing through the source.
and more (CSS, etc).
If you can't figure it out by looking at the Firebug console, and since you're following a tutorial, why don't you download the Depot source code and compare it with your own to see what you're doing wrong.
If you have the book, the complete source is listed at the end of the book. You can also download the source from here.
The standard ajax helper methods are link_to_remote, form_remote_tag, form_remote_for, button_for_remote. (I might have missed a few.) If you're not using one of them, you could be doing something wrong.
If you're using one of the helper methods with remote as part of the name, you might be missing the update option or the update option is pointed to the wrong html element.
For a form_remote_tag helper:
form_remote_tag(:url => {:controller => controller_name, :action => action_name, :id => id},
:update => element_to_update)
The element_to_update should be the html element's id that you're updating.
The ActiveScaffold list view has a search form that is loaded via ajax when a user click the search link. I'd prefer to have the form show by default when a user opens a list page.
I've figured out a way to trigger the ajax call when the page loads, but I'm wondering if there's a way to get ActiveScaffold to render the form automatically. Is there a template or a method I can override? I've had a look through the code but there's nothing obvious, at least to me.
Update:
srboisvert's answer inspired me to have a better look.
The trick is to use Template overrides to refactor the following: list.rhtml, _list_header.rhtml, _search.rhtml so that the search form partial renders inline.
There is a way to get it rendered automatically:
active_scaffold :model do |config|
config.list.always_show_search = true
end
I don't currently have an active scaffold project handy but here is how I would figure it out.
I'd use firefox with firebug installed and take a look at what is called when the link is clicked. Then I would go look at that javascript and what it is generating. Then I would search the source for any part of the code or combination that would be fairly unique to the search box ajax. After that it should be easy to cut and past it in without the ajaxyness.
The option
config.list.always_show_search = true
works fine, but only on concrete controller. It throws an exception when used in AS set_default block. Somebody know better solution then to include it in every controller (apart from overriding the template which is handy but complicates version updates)