Hello all,

Thank you for the suggestions, those helped to begin.
Recently we started working on it and some questions popped up.

1. The pylons project uses this middleware <https://pastebin.com/MUCHndsj> 
wrapper 
with:

   - routes.middleware - I suppose the routes are handled by pyramid and we 
   don't need this
   - paste - if I understand this correctly, this is obsolete in pyramid?
   - beaker.middleware - Is there a point to use beaker as WSGI middleware 
   in pyramid? 
      - I currently set it up per documentation when setting up the config 
      with session factory:
      - from pyramid_beaker import session_factory_from_settings
      session_factory = session_factory_from_settings(settings)
      config.set_session_factory(session_factory)
      
2. We have some variables that were set in Pylons as globals and are used 
almost in all templates.
What is the best way to add these variables to all views or a subset of 
views without explicitly adding them to every view ? I was looking at 
tweens or just creating a base class from which the view classes would 
descend and would inject the variables in returned dictionary.
Maybe there is a better way?

On Wednesday, April 2, 2025 at 9:47:16 PM UTC+2 Jonathan Vanasco wrote:

> ah. I wrote this package to adapt the @validate decorator and form reprint 
> concepts from pylons into pyramid 
> https://github.com/jvanasco/pyramid_formencode_classic
>
> it helped me migrate apps fairly quickly. 
> On Wednesday, April 2, 2025 at 2:22:31 PM UTC-4 Mike Orr wrote:
>
>> I just use the regular Formencode library in Pyramid in case that 
>> wasn't clear. I didn't know about 'pyramid_formencode'. 
>>
>> For the settings I have a Schema. Since setting names have dots in 
>> them I can't use attribute-based definitions, so I do it in init, 
>> setting `self.fields[name] = myvalidator`. My `main()` routine calls a 
>> function `process_settings(settings)` that instantiates the schema, 
>> validates them and coerces their types, and returns the resulting 
>> dict. If they're invalid I get a formencode.Invalid exception. Then I 
>> think I do something to display the invalid settings. I originally had 
>> several settings required, but I'm now moving away from that gradually 
>> to allow an incomplete configuration file, with deployment-specific 
>> values of some "required" settings coming from environment variables. 
>>
>> On Wed, Apr 2, 2025 at 10:22 AM Jonathan Vanasco <[email protected]> 
>> wrote: 
>> > 
>> > I'm actually in the process of new release to fix some issues and 
>> simplify the API; I've been dealing with testing and regressions across a 
>> handful of deployments for the past week. I'm nearly there and will finally 
>> hit a 1.0 release once this looks good. There are some breaking changes but 
>> the API is significantly simpler and more consistent. I'm just dealing with 
>> small issues about handling "special errors" correctly (like controlling 
>> how "nothing submitted" is handled). 
>> > 
>> > I just pushed a 0.9.2 release out for testing across some CI systems, 
>> and that seems to be the direction things are going in. I tried a few other 
>> minor releases with slightly different breaking changes. 
>> > On Tuesday, April 1, 2025 at 6:36:15 PM UTC-4 Mike Orr wrote: 
>> >> 
>> >> I've been using Formencode throughout for both form validation and 
>> >> config settings validation. Thanks for porting it to Pyramid and 
>> >> Python 3 and dealing with changes within Python 3: I remember all of 
>> >> those broke functionality until Formencode was patched. 
>> >> 
>> >> On Tue, Apr 1, 2025 at 2:20 PM Jonathan Vanasco <[email protected]> 
>> wrote: 
>> >> > 
>> >> > i forgot to mention - if your app uses formencode for validation, I 
>> ported the pylons validation to pyramid a long time ago and still actively 
>> use and maintain it - 
>> https://github.com/jvanasco/pyramid_formencode_classic 
>> >> > 
>> >> > 
>> >> > On Tuesday, April 1, 2025 at 1:14:08 PM UTC-4 Jonathan Vanasco 
>> wrote: 
>> >> >> 
>> >> >> Pyramid offers a few ways to implement the routes/controllers. 
>> >> >> 
>> >> >> The easiest when porting from Pylons is to use classes with 
>> @viewconfig, that can mimic the pylons handler classes. 
>> >> >> 
>> >> >> This is a good example of that approach in the regular pyramid 
>> docs: 
>> https://docs.pylonsproject.org/projects/pyramid_cookbook/en/latest/pylons/views.html
>>  
>> >> >> 
>> >> >> Pretty much everything can be supported and migrated with not too 
>> much work, except for the globals. IIRC Pylons did some weird stuff with 
>> globals that wasn't necessarily threadsafe. When moving to pyramid you can 
>> use events to define/translate "globals" into templates. For the python 
>> code, you can also update code to not use globals and take a context object 
>> as the first argument. The context object could be a request, or an object 
>> that wraps a request. 
>> >> >> 
>> >> >> In terms of templating - if there isn't a genshi package you could 
>> probably model one after pyramid_mako and port the pylons package over. It 
>> might be much faster to do that, and then lightly adapt the templates, then 
>> reinvent everything. 
>> >> >> 
>> >> >> 
>> >> >> On Tuesday, April 1, 2025 at 6:48:01 AM UTC-4 Milan Kelesi wrote: 
>> >> >>> 
>> >> >>> Hello, 
>> >> >>> 
>> >> >>> We are planning to migrate an existing project from Pylons 1.0.2 
>> to Pyramid 2.x. 
>> >> >>> What would be the best approach to start? 
>> >> >>> I understand we need to rewrite all the controllers. 
>> >> >>> We are using Genshi templates and this does not seem to be 
>> supported in Pyramid 2. What would be the easiest template engine to 
>> migrate to from Genshi (Mako, Jinja2, Chameleon, ..) 
>> >> >>> Is there an easy way to reuse the existing routes, globals, 
>> application setup? 
>> >> >>> I am currently a bit overwhelmed and not sure where to start. 
>> >> >>> I would like to get a quick win and get one simple 
>> route/controller without authentication to work under pyramid. 
>> >> >>> 
>> >> >>> Thanks for any advice. 
>> >> > 
>> >> > -- 
>> >> > 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 [email protected]. 
>> >> > To view this discussion visit 
>> https://groups.google.com/d/msgid/pylons-discuss/7411399e-9ec1-4411-9e45-5b53fcc823ebn%40googlegroups.com.
>>  
>>
>> >> 
>> >> 
>> >> 
>> >> -- 
>> >> Mike Orr <[email protected]> 
>> > 
>> > -- 
>> > 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 [email protected]. 
>> > To view this discussion visit 
>> https://groups.google.com/d/msgid/pylons-discuss/6223811b-7edd-44ad-b5c6-ce92fb135a61n%40googlegroups.com.
>>  
>>
>>
>>
>>
>> -- 
>> Mike Orr <[email protected]> 
>>
>

-- 
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 [email protected].
To view this discussion visit 
https://groups.google.com/d/msgid/pylons-discuss/72f15fff-8144-4577-a5c4-91abb4f0ed73n%40googlegroups.com.

Reply via email to