Hi,

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 
problem...

Bart

James Adam wrote:

>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 Masschelein <[EMAIL PROTECTED]> wrote:
>  
>
>>Hello,
>>
>>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']
>>              else
>>                redirect_to :action => 'list'
>>              end
>>
>>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 efficiently?
>>
>>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?
>>
>>
>>
>>enjoy!
>>
>>Bart
>>_______________________________________________
>>engine-users mailing list
>>[email protected]
>>http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
>>
>>    
>>
>
>
>--
>* J *
>  ~
>_______________________________________________
>engine-users mailing list
>[email protected]
>http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org
>
>
>
>  
>
_______________________________________________
engine-users mailing list
[email protected]
http://lists.rails-engines.org/listinfo.cgi/engine-users-rails-engines.org

Reply via email to