If architecture and designs are being critiqued, here are a few thoughts from 50,000 feet:
Pyramid bills itself as a "framework for building frameworks" and others have successfully done exactly that. Traversal makes certain use cases easier (i.e. yours), but it is not a miracle solution that can auto-magically "give things URLs which currently do not". In essence, you stated that you want to have "inexperienced users" writing "untested code" that simply works. That is a very ambitious goal and you probably have a great deal of work to do beyond getting traversal to function, in order to have any hope of having system that can be stable and maintainable by inexperienced users. Are any exception messages going to be clear enough for them to know how to take corrective action to fix an unforeseen problem in their own code, without understanding the Pyramid internals? You probably need a whole layer of code checking/introspection with custom feedback to guide the users - *before* they deploy their code into the live system. I also think that handing them the Pyramid documentation, no matter how good it is, will not get you out of having to write your own custom documentation for your target audience. The Pyramid documentation is very good but it is written to a particular audience (application developers - not code-slinging users). If someone wants to select the color of their car at a dealership, they don't hand them the manual for the painting robot at the assembly plant, even if it is "the best painting robot manual ever written". If you don't handle all the possible problems in your code, it seems you are simply delaying the point where your users must become Pyramid developers, to when they experience their first bug and have to crack open the Pyramid documentation to figure out how to fix it. For most people building stuff on top of Pyramid, the fact that it is simple, stable, and thoroughly tested is of greater importance then the ease of integrating it into every conceivable use case. I really do not need or want a bunch of framework-specific exceptions thrust upon me to add to my learning curve. And if I someday want some, I will override what I need to in order to add them. I think that is probably what you are going too need to do. Best of luck in your endeavor, Steve On Wed, Mar 6, 2013 at 5:01 AM, Peter Waller <[email protected]> wrote: > On 6 March 2013 10:51, Arndt Droullier <[email protected]> wrote: > >> I thought about this point some time ago but I don't think it is a >> problem in general: >> > - if you write a unit test you are likely to test your code without >> traverser so you will get plain Key errors >> > > Since it's my users writing code I can't enforce that they write unit > tests. I know that they won't, they're an inexperienced audience. > > >> - __getitem__ is not the place to put your application logic >> > > .. I don't understand this statement at all. Then why have traversal at > all?! The basic premise of my application is to give things URLs which > currently do not, so I'm pretty heavily invested in using traversal for > complex purposes. > > >> If you want to extend pyramid or create a new framework on top you need >> to provide some code >> to be used by users. Either as base classes, decorators or pyramid level >> replacements. This doesn't >> mean users cannot use __getitem__. >> > > I already do this heavily. I have several decorators which allow you to > modify the behaviour significantly. > > The problem is that I want my users *to use pyramid*, i.e, I want to take > advantage of the wonderful documentation and framework of Pyramid. That > means that I want to build my application on top of it. The way I see it, > there is a fundamental conflation of KeyError and "no resource" here which > leads to an unresolvable decision - "is it an error, or a resource which > doesn't exist?". > > In my application it's not necessarily clear when a resource doesn't exist > (which should, but there is an error), because it could just be one thing > on a page of hundreds of things not showing up. This can lead to very > problematic and hard to debug cases for the user. > > This is very unfortunate for me, because other than this one horrible edge > case (and user trap), I'm really pleased with the application and I want to > share it (and pyramid) with the world. > > -- > 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 post to this group, send email to [email protected]. > 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/pylons-discuss?hl=en. For more options, visit https://groups.google.com/groups/opt_out.
