One controller for two views (revisited)

[Julio F. Schwarzbeck]

Hi again Folks,

I just wanted to get your take on an approach that has not been suggested for this question, even though the question, in one form another, has been asked previously.

I have more than one application, or potentially one or more applications + some services that roughly has the same information requirements.

Both my mobile app and my desktop app (no bootstrap here, as both are first-class apps) call the same controller, I know I can change the view name dynamically and still call the same controller, but what if I add a service endpoint, for example, that ultimately calls the "default/index" controller, but with no view, and so on..

So the solution that I'd like you guys to comment on is the following..

Creating a class (or first class functions) as a Module, and put all the business logic in that module(s), and now we can have as many controllers as we need (if needed) and they all call the same business logic module but represent the data in different ways (JSON, XML, etc).

So the question is, do you see a problem offsetting "controller" code to a module instead, and having the controller (or multiple different controllers or applications) call the business rule in the module? - This could potentially eliminate the need to change views or other "trickery" to technically execute the same code for a specific controller..

Thanks!

--sb

[Jim S]

That is exactly what I'm doing with a new application we rolled out earlier this month.  Controller instantiates the object, does the necessary processing and then returns the object to the view.  Works well for me.  I'm doing some tricky (well, tricky for me) things to pass the object around between pages, but it is all working quite well.

-Jim

[Julio F. Schwarzbeck]

Good to hear that Jim, are you by any chance using the current object in your class to control state? - is this even advisable by the core devs?

[Jim Steil]

I am not. Actually didn't even think of that, but maybe that would work better than what I'm doing. Basically, I'm pickling my object (saving the instance variables to a dictionary first) and saving it to redis using a unique key that I then pass to my views.  Any url's or redirects in the page then pass the unique key to each controller function that then retrieves the pickle from redis, unpickles, instantiates a new instance of my class and read's the dict back into the instance variables.

But, didn't even think about using current.  I will investigate that tomorrow.  Will it keep unique sessions even between tabs open in the same browser?

-Jim

--
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
---
You received this message because you are subscribed to a topic in the Google Groups "web2py-users" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/web2py/3Ei2Q9ayyIQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to web2py+un...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Julio F. Schwarzbeck]

I guess that as long as you don't (re)assign the object as a class attribute you'll be fine, it seems like the current is context-safe, so on multiple tabs, it uses the same auth token (not sure if I am correct, would need to peek in the code to be sure I guess), that may simplify things for you, I will work on a pending app this way, and come back once I ran some tess, good luck..

[Anthony]

On Wednesday, June 29, 2016 at 5:36:04 PM UTC-4, Julio F. Schwarzbeck wrote:

Good to hear that Jim, are you by any chance using the current object in your class to control state? - is this even advisable by the core devs?

If your controller code needs access to parts of the web2py environment, use of current is the recommended approach and should work. Note, current.globalenv is a dictionary containing the entire web2py global environment. Of course, you can instead explicitly pass the request, response, session, cache, and/or T objects to your code, and you can explicitly import other parts of the web2py API, such as HTML helpers, validators, etc.

I think your approach should work -- you just need a way to route to your module code from either a model file or a standard controller. But there's no reason you can't keep most of your request handling code in modules.

Anthony