Re: [pylons-discuss] How do I "forward" requests and switch their contexts?

['Torsten Irländer' via pylons-discuss]

 Hi Jens,

I would try to factor out as many code as possible which is common to both
views into a separate function and use this function both  context. I
assume the validation and setting values in the profile work in the same
way and does not rely on its context.

This way you can implement context specific logic in the views an than call
common logic within the methods mentioned above.

Torsten

On Di., 19. Sep. 2017, 08:50  wrote:

> Hello everybody,
>
> I could need a bit of help with a more architectural question. I'm using
> Cornice  to build a REST server on
> top of Pyramid/SQLAlchemy. Now I've got two main "domains" in my endpoints,
> which are accessed by the two different user roles in the system:
>
>  - Normal users have endpoints like /api/user/profile, etc
>  - Administrator users have endpoints like /api/admin/user/profile, etc.
>
> Obviously, each "domain" has its own set of endpoints; however, sometimes
> the endpoints overlap. For example, assume the two endpoints above. A
> normal user may POST her name to /api/user/profile to change the name in
> her own profile. An administrator, in contrast, has to specify both the
> user *and* the name of the user in their POST request to change the name
> for a given user.
>
> This is essentially duplicated functionality, where the only difference is
> the context.
>
> How would I best go about implementing such a scenario without duplicating
> code for the two requests?
>
> It would make sense to "forward" the normal user request to the view
> handler of the admin, unless this elevation of rights would be frowned
> upon. Alternatively, one could "forward" the admin request to the view
> function of the normal user. Either way, the context data would have to be
> adjusted but that is a small effort compared to the duplicated code. Or
> should I uses common helper functions, which would still mean to duplicate
> code that validates incoming request data?
>
> So what is the recommended way of going about such scenarios?
>
> Thanks!
> Jens
>
> --
> You received this message because you are subscribed to the Google Groups
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/pylons-discuss/fec47c51-6f57-4608-8ec6-239eccfaedd1%40googlegroups.com
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/CADhb7teXrrxkdF803B6cPfh5MxZQRfFmQ_GVLTv69gkqyjTD1A%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [pylons-discuss] Porting a ZOPE (2.13) application into PYRAMID

[Christian Ledermann]

may be a little OT here, still worth a read in this context
https://www.martinfowler.com/bliki/StranglerApplication.html

On 19 September 2017 at 15:10, Brian Sutherland  wrote:
> On Thu, Sep 14, 2017 at 11:05:17PM +0300, Mikko Ohtamaa wrote:
>> Hi Roberty,
>>
>> You are right; Pyramid is your best bet. Pyramid community knows ho to
>> interact with ZODB and Chameleon is prettty close to ZPT.  I would suggest
>> continuous migration approach, where you start moving views to a Pyramid
>> server URL by URL, using some kind URL map on the front end web server
>> (nginx?)
>
> We are just finishing something like this and took a slightly different
> approach:
>
> * Serve Zope and pyramid via WSGI within one process
> * Use something like the paste.cascade middleware to first attempt
>   pyramid and on a 404 fallback to Zope.
> * Stash the pyramid request inside the WSGI environment to make it
>   available from within Zope. That way you can change helper
>   functions slowly to use the pyramid request and not need 2
>   implementations.
>
> Having the "use Zope if pyramid returns a 404" is probably the best part
> of that, you can replace urls with equivalent implementations slowly
> without breaking links.
>
>> -Mikko
>>
>> On 14 September 2017 at 19:12,  wrote:
>>
>> > Hello to everybody,
>> > I have an alive application running in (on) ZOPE 2.13.
>> > We are maintaining the application with linux virtual machines running
>> > python 2.7 and ZOPE 2.13.
>> >
>> > Here are a summary description of the objects present in ZODB:
>> > - 335 pages are written in *ZPT *(Zope Page Template)
>> > - 230 pages are still written in *DTML *=> we are (slowly) rewriting them
>> > in *ZPT*
>> > - 123 javascript (*DTML *Document type) scripts
>> > - 919 python scripts
>> > - 421 *ZSQL *scripts => we are (slowly) moving SQL queries on server side
>> >
>> > Moreover, we use *ZOPE Extensions* to call *external *services that are
>> > - called through XML/RPC protocol
>> > - 80% provided by a python business application server
>> > - 20% provided by a java-tomcat business application server
>> >
>> > Since ZOPE is dead, or so it seems (at least as own product),
>> > I'm looking for a little-painful-solution to run away from ZOPE.
>> >
>> > My idea was keeping the 2 business server python and java and porting only
>> > the ZOPE stuff in another python framework.
>> >
>> > I thought that PYRAMID could do the job, expecially if I could port easily
>> > the *ZPT *pages to CAMELEON.
>> >
>> > Can anybody give any suggestion?
>> >
>> > Thank you very much,
>> > Roberto Vivarelli
>> >
>> > --
>> > You received this message because you are subscribed to the Google Groups
>> > "pylons-discuss" group.
>> > To unsubscribe from this group and stop receiving emails from it, send an
>> > email to pylons-discuss+unsubscr...@googlegroups.com.
>> > To post to this group, send email to pylons-discuss@googlegroups.com.
>> > To view this discussion on the web visit https://groups.google.com/d/
>> > msgid/pylons-discuss/1483d157-bcca-4530-95e6-f886845d9e6f%
>> > 40googlegroups.com
>> > 
>> > .
>> > For more options, visit https://groups.google.com/d/optout.
>> >
>>
>>
>>
>> --
>> Mikko Ohtamaa
>> http://opensourcehacker.com
>> http://twitter.com/moo9000
>>
>> --
>> You received this message because you are subscribed to the Google Groups 
>> "pylons-discuss" group.
>> To unsubscribe from this group and stop receiving emails from it, send an 
>> email to pylons-discuss+unsubscr...@googlegroups.com.
>> To post to this group, send email to pylons-discuss@googlegroups.com.
>> To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/pylons-discuss/CAK8RCUv8okEsC7_YBBw8kceuzYCy6P7m7X8x2_soBKRy7ky-_Q%40mail.gmail.com.
>> For more options, visit https://groups.google.com/d/optout.
>
> --
> Brian Sutherland
>
> --
> You received this message because you are subscribed to the Google Groups 
> "pylons-discuss" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to pylons-discuss+unsubscr...@googlegroups.com.
> To post to this group, send email to pylons-discuss@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pylons-discuss/20170919141011.gdhmxqhqs2fzylcf%40mobilista.local.
> For more options, visit https://groups.google.com/d/optout.



-- 
Best Regards,

Christian Ledermann

Newark-on-Trent - UK
Mobile : +44 7474997517

https://uk.linkedin.com/in/christianledermann
https://github.com/cleder/


<*)))>{

If you save the living environment, the biodiversity that we have left,
you will also automatically save the physical environment, too. But If
you only save the physical environment, you will ultimately lose both.

1) Don’t drive species to extinction

2) Don’t destroy a habitat that spe

[pylons-discuss] Re: Porting a ZOPE (2.13) application into PYRAMID

[Jonathan Vanasco]

+1 to the advice above on a gradual migration via failovers or  "strangler"

One method that once worked well for me in the past: viewing everything as 
a Service Oriented Architecture and extending the old system with new 
routes that enabled it to be the Auth/Login component for the new system. 
That let the old system act as-is with no change.  When everything got 
migrated over to the new system, the auth endpoints were switched over to 
the new system too.

An example flow:

* User visits NEW page.  NEW redirects to OLD for auth.
* User logs in on OLD, which now has an auth callback info (e.g. oauth).
* * OLD handles login and sets it's own cookies/session.
* * OLD redirects to NEW auth-in endpoint
* NEW sets it's own sessions/info based on the auth-in token and background 
data exchange.





-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/pylons-discuss/cff20da8-82c4-473d-9c9b-d55026f7357c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.