I had some more time to wrestle with this tonight, and got stuck in Dryml
again. I really want to understand it. I wanted to have a link from my
recipe_request show page (I replaced the "request" model with "recipe_request")
that created a new recipe and passed in the id of the recipe_request. This
will allow me to destroy the recipe request after the recipe is saved. It
also allows the recipe_request title to appear pre-pasted in the new recipe
form.
I tried stuff like:
<a with="&Recipe" action="new" param="&this.id">I have it</a><br/>
in the show page Recipe Request, but this did not pass the id.
I did it with straight erb - my link is
<%= link_to "without dryml", :controller => :recipes, :action => :new, :id =>
@recipe_request.id %>
and my recipe new controller is:
def new
hobo_new
if params[:id] then
@recipe_request = RecipeRequest.find(params[:id])
@recipe.title = @recipe_request.title
end
end
I would love to learn the Dryml way to do this.
On Nov 14, 2010, at 4:09 PM, Matt Jones wrote:
>> I'm trying to use a lifecycle, because it seems like its probably the right
>> solution, but I can't really seem to get started. This project started
>> with the recipe tutorial in the book, but has moved on past it. I have two
>> models: recipe, and request. At the moment there is no relationship
>> between them, though both belong to user. I'd like to create a lifecycle
>> to start with a request and end up with a recipe. When a user responds to
>> a request, it should take them to a new recipe page. If that recipe is
>> saved (created), then the state of the request should change (:unfulfilled
>> => :fulfilled). I could make a one-to-one relationship between request and
>> recipe, though that seems strange because most requests do not yet have
>> recipes, and many recipes do not have requests.
>>
>> I could not find any examples of lifecycles in the docs where one model
>> contains the lifecycle, but another model responds to its controller events.
>> Any ideas would be welcome.
>
> I'm not sure the lifecycle mechanism can explicitly handle this, as it's
> mostly focused on things occurring within the context of a single model.
> Typically, one would model this with auto_actions_for and callbacks.
>
> in RecipeController:
>
> auto_actions_for :request, [:new, :create]
>
> and have Recipe belongs_to :request
>
> One important note: naming a model Request is going to cause "interesting"
> things to happen in the controller, as @request is already used (at least in
> Rails 2.3). It might be a good idea to name the model more specifically...
>
> --Matt Jones
--
You received this message because you are subscribed to the Google Groups "Hobo
Users" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/hobousers?hl=en.
