Re: I look for a standalone hash and check password library which follow « Password Storage» of Mozilla Security Guilines
I use passlib for password hashing. http://pythonhosted.org/passlib/ The documentation is quite good. See here for bcrypt hashing: http://pythonhosted.org/passlib/lib/passlib.hash.bcrypt.html?highlight=bcrypt#passlib.hash.bcrypt On Tue, Sep 17, 2013 at 5:34 AM, Stéphane Klein wrote: > Le 17/09/13 11:27, Jesaja Everling a écrit : >> Hi Stephane, >> >> I'm not familiar with the Mozilla password hashing guidelines or the >> two libraries you found, but have used this package for bcrypt: >> >> https://pypi.python.org/pypi/py-bcrypt >> >> hmac is part of the standard library, so you should be able to do >> "import hmac" without having to install anything. >> > > Thanks but I look for a "complete" library with hash password et check > password > functions. > > Best regards, > Stephane > -- > Stéphane Klein > blog: http://stephane-klein.info > Twitter: http://twitter.com/klein_stephane > cv: http://cv.stephane-klein.info > > -- > 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. > Visit this group at http://groups.google.com/group/pylons-discuss. > For more options, visit https://groups.google.com/groups/opt_out. -- Ian Marcinkowski ianmarcinkow...@gmail.com -- 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. Visit this group at http://groups.google.com/group/pylons-discuss. For more options, visit https://groups.google.com/groups/opt_out.
Re: Trouble storing Suds SOAP client in Configurator registry
Thanks!
I will take a look at that.
On Tue, May 28, 2013 at 4:50 PM, Michael Merickel wrote:
> FWIW, if you need a threadsafe connection pool and are already using
> SQLAlchemy for something else, the QueuePool is not db-api specific at all
> and can be reused for arbitrary connection pooling.
>
>
> On Tue, May 28, 2013 at 2:47 PM, ian marcinkowski
> wrote:
>>
>> I know how difficult things are without the traceback; I was mostly
>> looking for a suggestion exactly like yours in the hopes that it would
>> push me in the right direction. I actually didn't even get a
>> traceback, as my application crashed hard enough that it did not
>> output an error.
>>
>> According to a few locations online, the Suds Client object is not
>> threadsafe, so that could have something to do with it. I am
>> reimplementing this with a threadsafe connection pool instead.
>>
>> On Mon, May 27, 2013 at 12:37 PM, Michael Merickel
>> wrote:
>> > It's *really* difficult for the internet to help debug your problems
>> > without
>> > a full traceback. You're basically asking if anyone has seen this exact
>> > problem before because they have no other context to help them out.
>> >
>> > Anyway, Pyramid does not copy anything that is in the settings or the
>> > registry. Are you sure your client is threadsafe? If you're touching a
>> > non-threadsafe object from multiple request threads then anything could
>> > happen.
>> >
>> >
>> > On Mon, May 27, 2013 at 8:47 AM, ian marcinkowski
>> > wrote:
>> >>
>> >> Attaching my Suds Client to the registry did not help, but I will keep
>> >> that pattern in mind.
>> >>
>> >> Thanks!
>> >>
>> >>
>> >>
>> >> On Thu, May 23, 2013 at 3:35 PM, Michael Merickel
>> >> wrote:
>> >>>
>> >>> The settings dictionary is copied once when you pass it into the
>> >>> configurator, and it is supposed to be a shallow copy.
>> >>>
>> >>> new_settings = {}
>> >>> new_settings.update(settings)
>> >>>
>> >>> That doesn't explain your issue though.
>> >>>
>> >>> A likely fix is just to follow the pattern I use, which is to leave
>> >>> the
>> >>> settings dictionary for primitive types. Services and utilities are
>> >>> things I
>> >>> attach to the registry itself (it's a dict too).
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Thu, May 23, 2013 at 2:19 PM, ian marcinkowski
>> >>> wrote:
>> >>>>
>> >>>> Are objects modified when they are saved in the Configurator
>> >>>> registry.settings dictionary?
>> >>>>
>> >>>> I am trying to store a Suds SOAP Client in the registry which can be
>> >>>> cloned in my view-callables so I can avoid re-parsing that WSDL
>> >>>> document.
>> >>>> When I am trying to clone the Suds Client that has been stored in the
>> >>>> registry, my app is crashing horribly due to a maximum recursion
>> >>>> limit
>> >>>> reached exception.
>> >>>>
>> >>>> Some code:
>> >>>>
>> >>>> In my app __init__.py:
>> >>>> def main(global_config, **app_settings):
>> >>>> settings = {}
>> >>>> ...
>> >>>> settings['soap_client'] =
>> >>>> suds.client.Client('file:///service.wsdl',
>> >>>> username='foo', password='bar')
>> >>>>
>> >>>> config = Configurator(settings=settings, ...)
>> >>>> return config.make_wsgi_app()
>> >>>>
>> >>>> view-callable.py
>> >>>> def view(request):
>> >>>> cloned_soap_client =
>> >>>> request.registry.settings['soap_client'].clone()
>> >>>> <-- Induces Max. Recursion exception
>> >>>> return cloned_soap_client.service.SomeMethod()
>> >>>>
>> >>>> If I drop in to a PDB terminal inside of my application's main()
>> >>>> function and try cloneing settings['soap_client'] I do not encount
Re: Trouble storing Suds SOAP client in Configurator registry
I know how difficult things are without the traceback; I was mostly
looking for a suggestion exactly like yours in the hopes that it would
push me in the right direction. I actually didn't even get a
traceback, as my application crashed hard enough that it did not
output an error.
According to a few locations online, the Suds Client object is not
threadsafe, so that could have something to do with it. I am
reimplementing this with a threadsafe connection pool instead.
On Mon, May 27, 2013 at 12:37 PM, Michael Merickel wrote:
> It's *really* difficult for the internet to help debug your problems without
> a full traceback. You're basically asking if anyone has seen this exact
> problem before because they have no other context to help them out.
>
> Anyway, Pyramid does not copy anything that is in the settings or the
> registry. Are you sure your client is threadsafe? If you're touching a
> non-threadsafe object from multiple request threads then anything could
> happen.
>
>
> On Mon, May 27, 2013 at 8:47 AM, ian marcinkowski
> wrote:
>>
>> Attaching my Suds Client to the registry did not help, but I will keep
>> that pattern in mind.
>>
>> Thanks!
>>
>>
>>
>> On Thu, May 23, 2013 at 3:35 PM, Michael Merickel
>> wrote:
>>>
>>> The settings dictionary is copied once when you pass it into the
>>> configurator, and it is supposed to be a shallow copy.
>>>
>>> new_settings = {}
>>> new_settings.update(settings)
>>>
>>> That doesn't explain your issue though.
>>>
>>> A likely fix is just to follow the pattern I use, which is to leave the
>>> settings dictionary for primitive types. Services and utilities are things I
>>> attach to the registry itself (it's a dict too).
>>>
>>>
>>>
>>>
>>>
>>> On Thu, May 23, 2013 at 2:19 PM, ian marcinkowski
>>> wrote:
>>>>
>>>> Are objects modified when they are saved in the Configurator
>>>> registry.settings dictionary?
>>>>
>>>> I am trying to store a Suds SOAP Client in the registry which can be
>>>> cloned in my view-callables so I can avoid re-parsing that WSDL document.
>>>> When I am trying to clone the Suds Client that has been stored in the
>>>> registry, my app is crashing horribly due to a maximum recursion limit
>>>> reached exception.
>>>>
>>>> Some code:
>>>>
>>>> In my app __init__.py:
>>>> def main(global_config, **app_settings):
>>>> settings = {}
>>>> ...
>>>> settings['soap_client'] = suds.client.Client('file:///service.wsdl',
>>>> username='foo', password='bar')
>>>>
>>>> config = Configurator(settings=settings, ...)
>>>> return config.make_wsgi_app()
>>>>
>>>> view-callable.py
>>>> def view(request):
>>>> cloned_soap_client = request.registry.settings['soap_client'].clone()
>>>> <-- Induces Max. Recursion exception
>>>> return cloned_soap_client.service.SomeMethod()
>>>>
>>>> If I drop in to a PDB terminal inside of my application's main()
>>>> function and try cloneing settings['soap_client'] I do not encounter this
>>>> recursion limit.
>>>>
>>>> Sure, this is probably an bug with the Suds client, but I'm not sure how
>>>> toreproduce it outside of my application.
>>>>
>>>> Thoughts?
>>>>
>>>> --
>>>> Ian Marcinkowski
>>>> ianmarcinkow...@gmail.com
>>>>
>>>> --
>>>> 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.
>>>> Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
>>>> For more options, visit https://groups.google.com/groups/opt_out.
>>>>
>>>>
>>>
>>>
>>> --
>>> 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
Re: Trouble storing Suds SOAP client in Configurator registry
Attaching my Suds Client to the registry did not help, but I will keep that
pattern in mind.
Thanks!
On Thu, May 23, 2013 at 3:35 PM, Michael Merickel wrote:
> The settings dictionary is copied once when you pass it into the
> configurator, and it is supposed to be a shallow copy.
>
> new_settings = {}
> new_settings.update(settings)
>
> That doesn't explain your issue though.
>
> A likely fix is just to follow the pattern I use, which is to leave the
> settings dictionary for primitive types. Services and utilities are things
> I attach to the registry itself (it's a dict too).
>
>
>
>
>
> On Thu, May 23, 2013 at 2:19 PM, ian marcinkowski <
> ianmarcinkow...@gmail.com> wrote:
>
>> Are objects modified when they are saved in the Configurator
>> registry.settings dictionary?
>>
>> I am trying to store a Suds SOAP Client in the registry which can be
>> cloned in my view-callables so I can avoid re-parsing that WSDL document.
>> When I am trying to clone the Suds Client that has been stored in the
>> registry, my app is crashing horribly due to a maximum recursion limit
>> reached exception.
>>
>> Some code:
>>
>> In my app __init__.py:
>> def main(global_config, **app_settings):
>> settings = {}
>> ...
>> settings['soap_client'] = suds.client.Client('file:///service.wsdl',
>> username='foo', password='bar')
>>
>> config = Configurator(settings=settings, ...)
>> return config.make_wsgi_app()
>>
>> view-callable.py
>> def view(request):
>> cloned_soap_client = request.registry.settings['soap_client'].clone()
>> <-- Induces Max. Recursion exception
>> return cloned_soap_client.service.SomeMethod()
>>
>> If I drop in to a PDB terminal inside of my application's main() function
>> and try cloneing settings['soap_client'] I do not encounter this recursion
>> limit.
>>
>> Sure, this is probably an bug with the Suds client, but I'm not sure how
>> toreproduce it outside of my application.
>>
>> Thoughts?
>>
>> --
>> Ian Marcinkowski
>> ianmarcinkow...@gmail.com
>>
>> --
>> 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.
>> Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
>> For more options, visit https://groups.google.com/groups/opt_out.
>>
>>
>>
>
> --
> 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.
> Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
--
Ian Marcinkowski
ianmarcinkow...@gmail.com
--
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.
Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Trouble storing Suds SOAP client in Configurator registry
Are objects modified when they are saved in the Configurator
registry.settings dictionary?
I am trying to store a Suds SOAP Client in the registry which can be cloned
in my view-callables so I can avoid re-parsing that WSDL document. When I
am trying to clone the Suds Client that has been stored in the registry, my
app is crashing horribly due to a maximum recursion limit reached exception.
Some code:
In my app __init__.py:
def main(global_config, **app_settings):
settings = {}
...
settings['soap_client'] = suds.client.Client('file:///service.wsdl',
username='foo', password='bar')
config = Configurator(settings=settings, ...)
return config.make_wsgi_app()
view-callable.py
def view(request):
cloned_soap_client = request.registry.settings['soap_client'].clone() <--
Induces Max. Recursion exception
return cloned_soap_client.service.SomeMethod()
If I drop in to a PDB terminal inside of my application's main() function
and try cloneing settings['soap_client'] I do not encounter this recursion
limit.
Sure, this is probably an bug with the Suds client, but I'm not sure how
toreproduce it outside of my application.
Thoughts?
--
Ian Marcinkowski
ianmarcinkow...@gmail.com
--
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.
Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Re: Anti-spam packages
A mature service like Akismet is probably going to be your best bet. You could also use a CAPTCHA and force people to be logged in and authenticated to post comments. On Thu, Apr 25, 2013 at 12:29 AM, Biswas, Pinakee wrote: > Hi, > > ** ** > > Could you please let me know if there is any anti web spam or comment spam > package that can be used for Pylons based application? > > ** ** > > I searched on the net and found few python based packages like SpamBayes > (looks like for mails), akismet python api (akismet is not free), defensio > etc. > > ** ** > > Would really appreciate if you could suggest any solution that we could > use. > > ** ** > > Looking forward to your response and help… > > ** ** > > Thanks, > > Pinakee Biswas > > Director & CTO > > ** ** > > [image: cid:E95B8D36-1F36-4B11-B91A-CF8977B83894] > > * * > > *7*E- Mail: pina...@vvidiacom.com *I **8*Web: http://www.vvidiacom.com *** > * > > > > ** ** > > -- > 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. > Visit this group at http://groups.google.com/group/pylons-discuss?hl=en. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- Ian Marcinkowski ianmarcinkow...@gmail.com -- 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. Visit this group at http://groups.google.com/group/pylons-discuss?hl=en. For more options, visit https://groups.google.com/groups/opt_out. <><>
Exception raised in template not caught by exception view
Hi everyone,
I have an exception view configured with the view_config decorator
that is not catching my exception when it is raised while rendering my
template.
I am wondering if this is desired behaviour.
Here is a simplified example of what I'm doing.
The Exception View:
@view_config(context=ConnectionError, permission=NO_PERMISSION_REQUIRED)
def error_view(context, request):
""" Catch connection errors. """
request.flash('Could not connect. Please verify connection
settings. Error: {0}'.format(context)) # custom flash implementation
return HTTPFound(request.current_route_path(action='edit')) # Go
back to the edit page to modify server settings
The ConnectionError is raised in the view context:
class ServerFactory(RootFactory):
...
def client(self):
""" Connect to server. """
server = db.query(Server).get(self.server_id)
try:
return make_client(server.ip, server.port)
except:
raise ConnectionError('Could not connect.')
def model_number(self):
""" Get the model number of the server. """
client = self.client
return client.model_number()
If I make a call to ServerFactory.model_number inside of my Mako
templates, the ConnectionError not caught by error_view; however, if I
raise the ConnectionError in another view-callable it is caught.
Ideas?
--
Ian Marcinkowski
ianmarcinkow...@gmail.com
--
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.
Visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
Response.content_type issues with json renderer in render_to_response
I have a view-callable that is decorated with view_config to use a
mako template renderer. This view-callable will be called both
directly by the browser and via XHR requests. The following examples
illustrate my point.
Example A:
@view_config(renderer='json', xhr=True)
@view_config(renderer='template.mako', xhr=False)
def edit(self):
template_vars = {}
if self.request.is_xhr:
return {'form': render('template-form.mako', render_vars)}
return template_vars
Example B:
@view_config(renderer='template.mako')
def edit(self):
template_vars = {}
if self.request.is_xhr:
return render_to_response('json', {'form':
render('template-form.mako', render_vars)})
return template_vars
In Example A, any ajax requests will be returned a Response object
with a content_type of 'application/json.' In Example B ajax will
receive a Response object from render_to_response with a content_type
set of 'text/html' instead of 'application/json' as would be expected.
Is this an issue with view_config?
I have dug in to the code in pyramid.renderers from the current trunk.
The JSON renderer is being used for my request. In
pyramid.renderers.JSON.__call__, lines 248-261, I see the response
object having its content_type set to application/json, but when the
response comes back to me from render_to_response, it is set to
text/html again.
Using pdb.set_trace():
> HOMEDIR/pyramid/pyramid/renderers.py(254)_render()
-> request = system.get('request')
(Pdb) l
249 """ Returns a plain JSON-encoded string with content-type
250 ``application/json``. The content-type may be overridden by
251 setting ``request.response.content_type``."""
252 def _render(value, system):
253 import pdb; pdb.set_trace()
254 -> request = system.get('request')
255 if request is not None:
256 response = request.response
257 ct = response.content_type
258 if ct == response.default_content_type:
259 response.content_type = 'application/json'
(Pdb) n
> HOMEDIR/pyramid/pyramid/renderers.py(255)_render()
-> if request is not None:
(Pdb)
> HOMEDIR/pyramid/pyramid/renderers.py(256)_render()
-> response = request.response
(Pdb)
> HOMEDIR/pyramid/pyramid/renderers.py(257)_render()
-> ct = response.content_type
(Pdb) response.content_type
'text/html'
(Pdb) response.default_content_type
'text/html'
(Pdb) l
252 def _render(value, system):
253 import pdb; pdb.set_trace()
254 request = system.get('request')
255 if request is not None:
256 response = request.response
257 -> ct = response.content_type
258 if ct == response.default_content_type:
259 response.content_type = 'application/json'
260 default = self._make_default(request)
261 return self.serializer(value, default=default, **self.kw)
262
(Pdb) n
> HOMEDIR/pyramid/pyramid/renderers.py(258)_render()
-> if ct == response.default_content_type:
(Pdb)
> HOMEDIR/pyramid/pyramid/renderers.py(259)_render()
-> response.content_type = 'application/json'
(Pdb)
> HOMEDIR/pyramid/pyramid/renderers.py(260)_render()
-> default = self._make_default(request)
(Pdb) response.content_type
'application/json'
(Pdb) r
--Return--
> HOMEDIR/pyramid/pyramid/renderers.py(261)_render()->'{"form":
> "\\...ript>\\n\\n"}'
-> return self.serializer(value, default=default, **self.kw)
(Pdb)
> HOMEDIR/pyramid/pyramid/renderers.py(559)render()
-> return result
(Pdb)
--Return--
> HOMEDIR/pyramid/pyramid/renderers.py(559)render()->'{"form":
> "\\...ript>\\n\\n"}'
-> return result
(Pdb)
> HOMEDIR/pyramid/pyramid/renderers.py(563)render_to_response()
-> return self._make_response(result, request)
(Pdb)
--Return--
> HOMEDIR/pyramid/pyramid/renderers.py(563)render_to_response()-> 200 OK>
-> return self._make_response(result, request)
(Pdb)
--Return--
> HOMEDIR/pyramid/pyramid/renderers.py(134)render_to_response()-> 200 OK>
-> return helper.render_to_response(value, None, request=request)
(Pdb)
** Returning a rendered response to my app **
> MY_APP/handlers/VIEW.py(185)edit()
-> response.content_type = 'application/json'
(Pdb) l
182 if self.request.is_xhr:
183 response = render_to_response('json',
184 {'form': render(self.form_template, template_vars)})
185 -> response.content_type = &#
Re: Good form library for pyramid ? Better doing it by hand ?
re the possible parameters for TW2 widgets), and not having >> exactly what I want, I ask to the list, do you know about a form generation >> and validation lib, with support for i18n, easy error customization, and >> ability to use all (or almost all) html attributes (i.e. the title attribute >> to have tooltips in recent browsers). >> >> If some of you don't use at all such a library, do you have a good pointer >> to resources to validate input in a safe and clean way by hand ? >> >> Thank a lot for your comments and ideas. >> >> Have a nice day, >> >> Nicolas >> >> PS: maybe I missed the features of deform and tw2 (and WTForms), I'm sorry >> if I offense the different authors of those libs and even if what I >> want/need is not in their libs, I want to say thanks for each bit of the >> open-source ecosystem. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "pylons-discuss" group. >> To view this discussion on the web visit >> https://groups.google.com/d/msg/pylons-discuss/-/sXm8e2r1R-IJ. >> To post to this group, send email to pylons-discuss@googlegroups.com. >> To unsubscribe from this group, send email to >> pylons-discuss+unsubscr...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/pylons-discuss?hl=en. > > > > -- > Au revoir, et tous mes voeux pour un avenir plein de succès et de bonheur –– > > Malthe Borch > mbo...@gmail.com > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to pylons-discuss@googlegroups.com. > To unsubscribe from this group, send email to > pylons-discuss+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en. > -- Ian Marcinkowski ianmarcinkow...@gmail.com -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Re: Conflicting configuration actions error when using view_config decorator and config.scan
This turned out to be a stupid mistake on my part. The ContactHandler
was being subclassed and the inherited methods which were decorated
were being registered multiple times.
Thanks for the quick response.
On Thu, Dec 6, 2012 at 2:35 PM, Michael Merickel wrote:
> Without being able to see the implementation of action_config this is just a
> guess/check exercise. My first guess is that you're calling scan() multiple
> times with overlapping options that are possibly scanning that module
> multiple times.
>
> You said you tried using view_defaults and removing action_config, which of
> course does nothing if you didn't replace the action_config calls with the
> appropriate view_config calls.
>
> Also if action_config is using view_config directly, instead of implementing
> its own venusian callback, there will be issues here unless you are using
> 1.4 and overriding the depth argument to view_config.
>
>
> On Thu, Dec 6, 2012 at 11:54 AM, ian marcinkowski
> wrote:
>>
>> I am having a problem using the view_config decorator.
>>
>> We have extended the view_config decorator to automatically include
>> the match_param
>> attribute. This new decorator is called action_config. I have
>> already eliminated
>> this as the source of my troubles, as the stock view_config decorator
>> raises
>> the same errors.
>>
>> I have 2 routes, 'contact' and 'contact id' that are being used by 4
>> view callables on a ContactHandler class. Only 1 of the view callables is
>> using
>> the 'contact id' route while the other 3 use the 'contact' route.
>>
>> (Note: Our project is using namespace packages, so application.lib is
>> located at application.lib/application/lib on disk, for example)
>>
>> Routes
>> application/module/__init__.py:
>> ...
>> config.add_route('contact',
>> '/contact/{action}',
>> factory='application.lib.contexts:ContactFactory')
>>
>> config.add_route('contact id',
>> '/contact/{action}/{contact_id}',
>> factory='application.lib.contexts:ContactFactory')
>>
>> config.scan('application.lib.handlers')
>> ...
>>
>>
>> Callables
>> application.lib/application/lib/handlers/contact.py:
>>
>> class ContactHandler(Handler):
>>
>> @action_config(route_name='contact id')
>> def edit(self):
>> """ Add or edit a contact """
>> ...
>>
>> @action_config(route_name='contact')
>> def index(self):
>> """ Return list of contacts. """
>> ...
>>
>>
>> @action_config(route_name='contact')
>> def search(self):
>> """ Return a list of contacts matching search parameters """
>> ...
>>
>> @action_config(route_name='contact')
>> def find(self):
>> """ Find a contacts """
>> ...
>>
>> I can't figure out how or why these route is conflicting. My application
>> is
>> only scanning application.lib/application/lib/handlers/contact.py in one
>> place
>> and each view/callable method is only decorated once, each for a specific
>> route
>> as defined in my __init__.py.
>>
>> If I decorate the ContactHandler class with
>> @view_defaults(route_name='contact')
>> and remove all of the @action_config decorators from my class methods, no
>> errors
>> are raised. However, this is not ideal as I one route requires an ID
>> parameter
>> and one does not.
>>
>> When using pdb.set_trace() inside of the our extended action_config
>> __call__ method
>> inside of the callback passed to view_config.venusian.attach(),
>> I find that the callback is being called 3 times for each of these routes.
>> I don't know if that is related to the problem.
>>
>> Stragely, I am using this same action_config decorator in another module
>> inside of my application with no problems.
>>
>> The error:
>> Traceback (most recent call last):
>> File "~/.virtualenvs/application/bin/paster", line 8, in
>> load_entry_point('PasteScript==1.7.5', 'console_scripts', 'paster')()
>> File
>> "~/.virtualenvs/application/lib/python2.7/site-packages/PasteScript-1.7.5-py2.7.egg/paste/script
Conflicting configuration actions error when using view_config decorator and config.scan
settings['app'] = loader.get_app(key, global_conf=global_conf)
File
"~/.virtualenvs/application/lib/python2.7/site-packages/PasteDeploy-1.5.0-py2.7.egg/paste/deploy/loadwsgi.py",
line 350, in get_app
name=name, global_conf=global_conf).create()
File
"~/.virtualenvs/application/lib/python2.7/site-packages/PasteDeploy-1.5.0-py2.7.egg/paste/deploy/loadwsgi.py",
line 710, in create
return self.object_type.invoke(self)
File
"~/.virtualenvs/application/lib/python2.7/site-packages/PasteDeploy-1.5.0-py2.7.egg/paste/deploy/loadwsgi.py",
line 146, in invoke
return fix_call(context.object, context.global_conf, **context.local_conf)
File
"~/.virtualenvs/application/lib/python2.7/site-packages/PasteDeploy-1.5.0-py2.7.egg/paste/deploy/util.py",
line 56, in fix_call
val = callable(*args, **kw)
File
"~/code/src/application/BRANCH/application/application/module/__init__.py",
line 137, in main
return config.make_wsgi_app()
File
"~/.virtualenvs/application/lib/python2.7/site-packages/pyramid-1.3.2-py2.7.egg/pyramid/config/__init__.py",
line 921, in make_wsgi_app
self.commit()
File
"~/.virtualenvs/application/lib/python2.7/site-packages/pyramid-1.3.2-py2.7.egg/pyramid/config/__init__.py",
line 594, in commit
self.action_state.execute_actions(introspector=self.introspector)
File
"~/.virtualenvs/application/lib/python2.7/site-packages/pyramid-1.3.2-py2.7.egg/pyramid/config/__init__.py",
line 1030, in execute_actions
for action in resolveConflicts(self.actions):
File
"~/.virtualenvs/application/lib/python2.7/site-packages/pyramid-1.3.2-py2.7.egg/pyramid/config/__init__.py",
line 1136, in resolveConflicts
raise ConfigurationConflictError(conflicts)
pyramid.exceptions.ConfigurationConflictError: Conflicting configuration actions
For: ('view', None, '', None, , None, None, None, 'contact', 'add', False,
None, None, None, 'action=add')
Line 184 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact')
Line 184 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact')
Line 184 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact')
For: ('view', None, '', None, , None, None, None, 'contact', 'find', False,
None, None, None, 'action=find')
Line 137 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact')
Line 137 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact')
Line 137 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact')
For: ('view', None, '', None, , None, None, None, 'contact', 'index',
False, None, None, None, 'action=index')
Line 94 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact')
Line 94 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact')
Line 94 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact')
For: ('view', None, '', None, , None, None, None, 'contact', 'search',
False, None, None, None, 'action=search')
Line 133 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact')
Line 133 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact')
Line 133 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact')
For: ('view', None, '', None, , None, None, None, 'contact id', 'edit',
False, None, None, None, 'action=edit')
Line 37 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact id')
Line 37 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact id')
Line 37 of file
~/code/src/application/BRANCH/application.lib/application/lib/handlers/contact.py:
@action_config(route_name='contact id')
--
Ian Marcinkowski
ianmarcinkow...@gmail.com
--
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googlegroups.com.
To unsubscribe from this group, send email to
pylons-discuss+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/pylons-discuss?hl=en.
