Nolgthorn posted:

I too, would suggest a date field and a second field that describes the accuracy of the date. Then you could construct a method that puts the two together.

prom candy posted:

Simple idea would be to flag whether they're month specific and day specific. If something is 2013 you could just save it as 01-01-2013. Then you could use a little class or method to determine how to display it.

Daynab posted:

Maybe it's because this is the third language I learn the basics of and it's started clicking much faster, but regardless, this is awesome.

Physical posted:

Here is a convenience I find lacking:

Ruby code:

MyModel.where( :some_criteria => my_var)

When my_var is nil, the SQL turns into "some_criteria = 0", but I don't want that, I want 'some_criteria is NULL' do I have to do it on my own or is there something I am missing?

Physical posted:

Here is a convenience I find lacking:

Ruby code:

MyModel.where( :some_criteria => my_var)

When my_var is nil, the SQL turns into "some_criteria = 0", but I don't want that, I want 'some_criteria is NULL' do I have to do it on my own or is there something I am missing?

Physical posted:

Here is a convenience I find lacking:

Ruby code:

MyModel.where( :some_criteria => my_var)

When my_var is nil, the SQL turns into "some_criteria = 0", but I don't want that, I want 'some_criteria is NULL' do I have to do it on my own or is there something I am missing?

Physical posted:

I'm using MySQL and my where clauses is changed to

Ruby code:

:criteria => 'NULL' 

and it is still substituting it with 0. The db column is a integer type.
Doing this

Ruby code:

where('criteria is NULL')

Get's the results I want, but then I have to build my own string before hand which is what I wanted to avoid.

e: It looks like it should work, I just have to examine what I have a little bit more. Thanks for confirming that it should work err'body.

ee: Oh god it was because the value was being set to "", my numerous .nil? check's did nothing to prevent that, I am now using 'blank?'

Physical posted:

I still don't get what went wrong with

Ruby code:

:criteria => 'NULL' 

but maybe I just couldn't find it sifting through my console output for webrick since there is alot.

The Journey Fraternity posted:

Lexicon posted:

This should be super easy, but I can't quite work it out: I want to create a simple form in rails that's not coupled to an ActiveRecord model. I simply want to hit a controller, and then I'll deal with the posted params from there. However, when I click my button, nothing happens - my controller never gets hit. The route is properly set up.

Ruby code:

%form{:class => "form-inline", :action => "/blar", :method => "post"}
  %label
    From:
  %input{:type => "text", :placeholder => "yyyy-mm-dd", :class => "input-small datepicker"}
  %label
    To:
  %input{:type => "text", :placeholder => "yyyy-mm-dd", :class => "input-small datepicker"}
  %button{:type => "button", :class => "btn btn-primary"}
    Display

What am I missing here?

Physical posted:

Is it the difference between button and submit_tag? Or is your form tag crossing any div tags?

Smol posted:

You realize that you can put inline html inside haml, right? For example,

code:

#my
  .cool
    #haml
      .hierarchy
        <script type="text/template"><%= foo %></script>

http://chriseppstein.github.com/blog/2010/02/08/haml-sucks-for-content/

A MIRACLE posted:

yes but you still can't indent, correct?

chumpchous posted:

I had this exact question earlier today. I didn't from inputs from the user, but I did want some parameters forwarded.

code:

<%= form_tag(:controller => "seasons", :action => 'create',:method => 'post',:params => {id: @series.id}) do %>	
	<%= submit_tag("Add a season") %>
<% end %>

I'm on week .5 of rails, so take this with a grain of salt -- only posting because I was struggling with this today.

chumpchous posted:

I had this exact question earlier today. I didn't from inputs from the user, but I did want some parameters forwarded.

code:

<%= form_tag(:controller => "seasons", :action => 'create',:method => 'post',:params => {id: @series.id}) do %>	
	<%= submit_tag("Add a season") %>
<% end %>

I'm on week .5 of rails, so take this with a grain of salt -- only posting because I was struggling with this today.

chumpchous posted:

Yeah, this is something I was aware of, but couldn't make work at the time. I'm really liking rails, but dear god the emphasis on convention is frustrating when you're starting out. I generally gain a lot of understanding by looking at various examples and establishing a cause => effect relationship between things. In rails, the relationship is there, but it is rarely stated explicitly.

Smol posted:

For example, create_season_path is equivalent to your :controller => "seasons", :action => 'create',:method => 'post' definition.

Civil Twilight posted:

Take a look at the API Driven Example part of the RubyMotion tutorial, specifically "Color.find". It looks like they're accomplishing what you want to do by passing a block into the method that uses BubbleWrap, using block.call in the callback, and setting the instance variable in that block.

Smol posted:

That really doesn't help him, as the API is clearly asynchronous. That said, welcome to the wonderful world of asynchronous programming. Many things, like expecting to get useful return values from methods often don't exist in this world (especially in the node.js-esque callback hell side of things, which this API seems to be part of as well).

Smol posted:

Yep, event-driven programming can be quite complex. That said, it's a shame the Rubymotion devs didn't choose to use Fibers, using them can really help make event-driven programming more manageable.