for designers, they could care less whether templates are served directly or not. and really, developers should not care either as long as it’s easy to know how the templates are connected to the behavior that powers them.

@nick: addressing the historical reasons are important because it addresses how things got to be less than desirable and allows inspection of how such a condition may be remedied or avoided. I am pointing a finger at the almanac… if it’s something to be set up as an example of problematic practices (or is difficult for new developers to work in), then you guys need to be fixing that.

“In any web framework, there’s a request coming in. Some where down the code chain, decision are made based on what this request is all about, perhaps foremost based on its path and query string.

“However, it may also depend on such things as language, method and the type of data the request is looking for in a response. We’re talking about intrinsic qualities of the request, not details like which theme to apply, or other application-specific qualities.”

I don’t think the framework has to handle all these cases. Dispatch should not be at the sole discretion of the framework — it should always be possible to add dispatch to your application. Abstraction can happen at any layer. If you have these needs, writing a dozen lines of code to handle that is the simplest and easiest to maintain method (and really none of these use cases call for more than 10-20 lines of code).

Brandon: I suspect for most cases (maybe all non-diabolical cases) that the constant factor in the O(n) vs. O(log n) cases overwhelms n, and that the simpler solution will be faster. In a dispatching system like Routes the n will almost always be small, because most potential routes will be eliminated due to path matching (which is quite fast), and the functions are only run on a handful of routes. If you have a system resistant to path matching then it’s often quite reasonable to do some other kind of dispatching in code, e.g., route different requests through a single “view” that then does some dictionary lookups and function calls to dispatch to a real view. Anyone can make a dictionary of functions, you don’t need to be a framework wizard to do so.

As to generality: In Routes the matchers are ordered, so if you have a more specific match then you must order that before the less specific match. If you have the code in hand (which in Pylons you do have) then this is trivial (though admittedly it’s easy to get the ordering wrong, it’s something I do fairly often). Otherwise you don’t have that code then you do have to figure out some way of indicating priority. ZCA provides one way of doing that through the specificity implicit in inheritance — but that doesn’t make it *easy*. Does IPDFDocument subclass IGETRequest? Probably not, and then you are in just as annoying a place. Again, when things get complicated, writing your own dispatch using dictionaries and functions is easy: do more of that!

Anyway, I’m just hoping to raise some awareness about this to we can try and keep things as easy as possible in the future.

1. resources used to be in /src/resource (with all the other editable code). this change when someone decided to work around a broken piece of the build rather than fix it.

2. pylons layout is that of a single application, whereas the almanac is a build dealing with multiple applications. In almanace “/path/to/application/” == “/src/CommunityAlmanac/opengeo/almanac/”

The resources are served entirely by nginx (rather than by zope or some python app-server). There was a practical reason for this in the beginning; it allowed our javascript guys to start work in parallel to the server application. Much of the css + js layout is that of default OpenLayers.

3. you can/should change this to be simpler. the layout evolved over time (generally under time pressure) and like anything evolving occasionally requires some refactoring. Doing so require two things: understanding what the old layout was doing, and how to use buildout: writing recipes, making existing ones do what you want. nginx could point directly to /src/CommunityAlmanac/opengeo/almanac/resources/*, you could flatten the resource directory (provided you reset the javascript compression config) etc.

so yeah, this can be fixed, but there has to be an adequate time and effort and communication dedicated to doing it. and if that time isn’t available, new developers should not just be thrown blindly into something as complex as the almanac in mid-development. with robianski and ethan, I took alot of time explaining the layout and structure, how things could be improved, etc.

so go make it better.

I feel strongly that it’s important to keep all view-related content (templates, CSS, and JS) within a single checkout. To the extent that our various platforms allow it, I would also really like to see a sane, consistent structure for our view-related content. I’m partial to the Pylons / Rails approach, but would be happy with any kind of consistency which minimizes the amount of time spent on “where do I need to go to make this change” questions. Having to grep for specific strings to find a desired file is a fairly good indication that an application structure could use improving.

The actual mechanism that repoze is using, by contrast lets the framework “see” the decision you are trying to make — that it has to be a certain request type combined with a certain class of content, say. The framework can take all hundred registrations it might be offered and compose them into a decision tree that descends right down in roughly O(log n) time (or even less, if schemes based on Python dictionaries are in play) to the view that needs to be selected.

So, efficiency is problem #1; but there’s an even deeper problem #2 in which your scheme is simply an *impossible* solution: where the developer wants to write a “general view” that handles all Documents, but then wants to override that with a *special view* that specifically handles PDFDocuments differently since, say, he does not render those to HTML. With your scheme, the distinction is simply impossible to make! When a PDFDocument gets a GET, then *both* lambdas will fire, and since all the framework will get are two True values, there will be NO WAY that the framework can even POSSIBLY determine that the PDFDocument match “binds more tightly” than the Document match and should override it.

By contrast, the ZCA is built specifically to take registrations on classes and return the “most specific” one. It might be more complicated than it needs to be, I’m not sure; and I certainly have not learned all of the rules about what is a “more tight” binding when doing things like multi-adaptation. But it at least is making things possible which your supposedly “completely general” solution completely disallows! Your solution, in other words, is not general at all, because — in its current implementation — Python does not allow a framework to “look inside” boolean lambdas to compare matching booleans to see which is more specific.

In any web framework, there’s a request coming in. Some where down the code chain, decision are made based on what this request is all about, perhaps foremost based on its path and query string.

However, it may also depend on such things as language, method and the type of data the request is looking for in a response. We’re talking about intrinsic qualities of the request, not details like which theme to apply, or other application-specific qualities.

Now, in Zope 3, besides writing a long list of if-elif-else statements to multiplex on these, for any given object and request, to find a function that will actually render the response, there is the possibility of using marker interfaces and use the ZCA to multiplex.

This may seem like needless complexity for some, but developers who routinely use the ZCA will find it easy to understand and further, they’ll have a complete registry for these components, which may be queried in any way they like. It’s fast, too, being mostly written in C. That’s not good for the GAE, but that’s another matter.

I agree that marker-interfaces are often an anti-pattern and their binary quality is too simple to handle any but the most rudimentary use-cases. But consider this example (in the context of a “repoze.bfg“ app):

A request comes in; it’s an ajax request, which may readily be seen from the value of the HTTP header “http_x_requested_with”, which is “xmlhttprequest”. To register a view “show” for such requests, one would register a generic view function for this view and multiplex to two other views, “show_full” and “show_ajax”.

Alternatively, we just register our ajax-view for an interface which matches the corresponding HTTP header. If we use “repoze.bfg.httprequest“ to create this interface, it’s automatically applied to the request when it comes in. No setup needed. It’s even quite readable, as long as the interface as properly named, e.g. IAjaxRequest.

In conclusion, programming with Python is about having fun and not working too much; this means writing good code and being able to reuse that code often. The test of time will prove whether this package was a fluke or not. I’m still using it