1. 13 8月, 2010 1 次提交
  2. 12 8月, 2010 1 次提交
  3. 10 8月, 2010 1 次提交
  4. 02 8月, 2010 2 次提交
  5. 13 7月, 2010 1 次提交
  6. 30 6月, 2010 1 次提交
  7. 28 6月, 2010 1 次提交
    • W
      Fix several known web encoding issues: · 25215d72
      wycats 提交于
      * Specify accept-charset on all forms. All recent browsers,
        as well as IE5+, will use the encoding specified for form
        parameters
      * Unfortunately, IE5+ will not look at accept-charset unless
        at least one character in the form's values is not in the
        page's charset. Since the user can override the default
        charset (which Rails sets to UTF-8), we provide a hidden
        input containing a unicode character, forcing IE to look
        at the accept-charset.
      * Now that the vast majority of web input is UTF-8, we set
        the inbound parameters to UTF-8. This will eliminate many
        cases of incompatible encodings between ASCII-8BIT and
        UTF-8.
      * You can safely ignore params[:_snowman_]
      
      TODO:
      
      * Validate inbound text to confirm it is UTF-8
      * Combine the whole_form implementations in form_helper_test
        and form_tag_helper_test
      25215d72
  8. 23 6月, 2010 1 次提交
  9. 22 6月, 2010 1 次提交
  10. 19 6月, 2010 1 次提交
  11. 20 5月, 2010 1 次提交
  12. 16 5月, 2010 2 次提交
  13. 15 5月, 2010 1 次提交
  14. 03 5月, 2010 1 次提交
  15. 12 4月, 2010 1 次提交
  16. 10 4月, 2010 2 次提交
  17. 06 4月, 2010 4 次提交
  18. 03 4月, 2010 1 次提交
    • W
      Refactored url_for in AV to have its own instances of the helpers instead of... · 3eb97531
      wycats 提交于
      Refactored url_for in AV to have its own instances of the helpers instead of proxying back to the controller. This potentially allows for more standalone usage of AV. It also kicked up a lot of dust in the tests, which were mocking out controllers to get this behavior. By moving it to the view, it made a lot of the tests more standalone (a win) 
      3eb97531
  19. 10 3月, 2010 1 次提交
  20. 21 2月, 2010 1 次提交
  21. 07 2月, 2010 1 次提交
  22. 02 2月, 2010 1 次提交
  23. 01 2月, 2010 2 次提交
    • Y
      For performance reasons, you can no longer call html_safe! on Strings.... · 4cbb9db0
      Yehuda Katz 提交于
      For performance reasons, you can no longer call html_safe! on Strings. Instead, all Strings are always not html_safe?. Instead, you can get a SafeBuffer from a String by calling #html_safe, which will SafeBuffer.new(self).
      
        * Additionally, instead of doing concat("</form>".html_safe), you can do
          safe_concat("</form>"), which will skip both the flag set, and the flag
          check.
        * For the first pass, I converted virtually all #html_safe!s to #html_safe,
          and the tests pass. A further optimization would be to try to use
          #safe_concat as much as possible, reducing the performance impact if
          we know up front that a String is safe.
      4cbb9db0
    • S
  24. 31 1月, 2010 2 次提交
  25. 28 1月, 2010 1 次提交
  26. 15 1月, 2010 1 次提交
  27. 14 1月, 2010 4 次提交
  28. 07 1月, 2010 1 次提交
  29. 03 1月, 2010 1 次提交