Forum: Rails Engines DRY and engines

Announcement (2017-05-07): is now read-only since I unfortunately do not have the time to support and maintain the forum any more. Please see and for other Rails- und Ruby-related community platforms.
Bart M. (Guest)
on 2006-02-28 23:28
(Received via mailing list)

I'm using the UserEngine in my Rails application, in casu Riki. In the
page to create a new book, the administrator can select the book
administrator for that book, or create a new one if it does not exists.
In that case I link_to /user/new, but in the normal case I get
redirected to /user/list, whereas I would like to be redirected back to
the /book/create page. I solved this in the following way:

1) I added at the top of my create.rhtml (or in the create action)
    session['return-to'] = '/books/create'
2) And I changed the new action in the user controller to

              if session['return-to']
                redirect_to session['return-to']
                redirect_to :action => 'list'

In that case I get redirected back to the create book page. This is one
way, but I have the feeling that it is not the most elegant. I could of
course copy the complete new action, but this goes against the DRY
principle, and against the reusability of Engines. In the end, I might
have copied all code inside my rails application. This follows a
discussion I had with Jay:

 >Another thing to think about: You want the engine to be easily
extensible without folks having to modify the actual engine files, or
cut-and-paste >huge swaths of code.  So keeping subroutines short (and
thus keeping overrides granular) is even more important than it is in
"normal" code.  >UserEngine does a good job of keeping the "core" code
under lib, but I still found I had to copy an entire action from
user_controller just to change >one string.  I'm not sure I can think of
specific patterns to encourage for extensibility, but it's something
that should be kept in mind.

Or there other ways to solve this, I mean, reusing engine code

By the way, I still have then another problem in this way. When the
administrator has already filled in some fields of the form, they get
lost when he gets back to the create page. I know this is probably more
a Rails question in general, but does anybody has some ideas on how to
keep the field data? My gutfeeling is that it is lost, unless I
integrate it all together, by integrating the new user partial into the
create form, and duplicating the user/new code.

How could this be rewritten, so the new action of the user controller
could be reused? Or is this not the purpose of Engines, and maybe more
of plug-ins, where Engines are meant to be more complete applications?


James A. (Guest)
on 2006-02-28 23:32
(Received via mailing list)
Both the User and Login engines could do with serious refactoring with
a view to making them much cleaner in terms of overriding behaviour. A
big part of this is probably going to be establishing a clear API for
both. Let the discussion commence!

- james

On 2/28/06, Bart M. <removed_email_address@domain.invalid> wrote:
>     session['return-to'] = '/books/create'
> course copy the complete new action, but this goes against the DRY
> user_controller just to change >one string.  I'm not sure I can think of
> integrate it all together, by integrating the new user partial into the
> Bart
> _______________________________________________
> engine-users mailing list
> removed_email_address@domain.invalid

* J *
Bart M. (Guest)
on 2006-03-01 00:02
(Received via mailing list)

Ok, I will try a bit more how far I can go with this
session['return-to'] idea, which is already used nicely in the
LoginEngine, and see how it can be usefull for this process.

And I had to reread Chapter 8 of the pragmatic programmer book to
realize that sessions will also solve my other, non-engine related

Bart M. (Guest)
on 2006-03-01 20:20
(Received via mailing list)

I found a solution for my problem, and even better then I thought. It
should be general enough for other uses. It works in two directions:

1) you can say where the user/new has to return to, after completion (in
my case, back to the book creation)

2) In my book/create, I get immediately the id of the newly created
user, so I can use it in my book/create form. The administrator does not
have to select it again.

For doing this I changed the following lines in the user_controller of
the UserEngine:

redirect_to :action => 'list'

changed to

              if session['return-to']
                session['return-to'][:new_user_id] =
                redirect_to( session['return-to'] )
                redirect_to :action => 'list'

My book/create action, looks like this:

  def create
    case request.method
      when :get
        @book = partially_created_book
        @all_users_mapped = { |c| ["#{c.fullname}",] }
        if !params[:new_user_id].nil?      # retrieve the newly created
          @admin = User.find(params[:new_user_id])
      when :post
        if params[:commit]=="Create new user"
          session[:partially_created_book] =[:book])
          session['return-to'] = {:controller => 'books', :action =>
'create'}  # to set the action where to return to
          redirect_to :controller => 'user', :action => 'new'
        elsif params[:commit]=="Create"
          redirect_to '/' + params[:book][:url_name]

It works, and seems general enough. For the full code, you'll have to
wait for Riki 0.3.1, coming soon...

Any ideas to improve this?

Mauro C. (Guest)
on 2006-03-01 20:40
> Any ideas to improve this?
> Bart
Hi Bart!

I was writing an answer while you have added yours.
I can still publish it as a general suggestion. Here it is:

I don't have a final solution there, but rather a small suggestion:

avoid the if/else construct and just set the
  session['return-to'] ||= '/your_controller/list'
as default.

In this way you just
redirect_to session['return-to']
whenever you need it. It scales better, doesn't
matter how many new spacial cases you want to introduce.

About the DRYness I create a new POST so that we don't confuse the Riki
specific issue to the genear problem.

See you in the new post ;-)

Bart M. (Guest)
on 2006-03-01 21:25
(Received via mailing list)

In attendance of the new post, I can already say that indeed that was
the first way I did it, but it did not give me back the newly created
user. And that was something which I found quite user-friendly, putting
this newly created information directly in the form of creating the

Just extending the general usage a bit...

This topic is locked and can not be replied to.