> I think the problem is that you are thinking too abstractly without >> considering what the actual code would look like. If you think about the >> code, you would realize that what you say above makes no sense. I leave the >> following to you as an exercise: assume the installer has access to the >> application folder and wants to "pass the configuration information" to the >> application. Please write the actual code to do that. Whatever code you >> write, that is exactly what I call the "wrapper" (as the code must run >> before the rest of the application, making available the relevant data in >> some object available to the application). >> >> > > In what I have in mind, the installer has no code to write. He passes the > info by creating a file path/to/location.ini > , which contains > > configFileLocation = /path/to/config/file > > The author uses configparser to read the file and get the location of the > config file: > > config = configparser.ConfigParser() > config.read(['path/to/location.ini']) > > It's simple and there is no wrapper, but we see the location > path/to/location.ini in the code written by the author. This means that > the author needs to know the location. Had I used a wrapper, the author > would not need to know any location to obtain the location of the config > file. The code would read the passed value, say in request.env. The > situation is fundamentally different in the simple solution with no > wrapper, because the code needs to know one location to learn another > location. I am not sure why I explain this, because I think we already > share this kind of understanding. So, I was just saying, if the installer > can use a file in the application folder, why not use this simple solution > that needs no wrapper. >
This seems nonsensical. Why make the application know the path to one configuration file just to learn the path to another? Anyway, this is not what I asked you to do. You made the claim that if the installer has access to the application folder, the installer could do something to provide information to the application that was not equivalent to my proposal of the __wrapper.py file. I contest that claim and request that you write the code that you claim is different. Your example above does not do this, as it involves no code written by the installer in the application folder. I don't understand why you have written the code that you have or what point you are trying to make with it, but it has nothing to do with anything I was saying. Also, note that the idea of putting "wrapper" code inside the application folder is a more general solution for when you need to do real pre (and possibly post) processing. I would *not* suggest using that method merely to communicate the location of a configuration file (as in your example above), as very early in this discussion I proposed several simpler alternatives. Anyway, don't worry about it -- it seems unlikely we're going to straighten this out. > This is where you go in circles. I have explicitly acknowledge multiple >> times that I know your ideal solution involves the "wrapper" code being >> outside the application folder, and I proposed the WSGI middleware solution >> as the closest you can get to what you want. I *separately* offered the >> idea of a "wrapper" file *inside* the application as a reasonable >> alternative that would work in almost any conceivable circumstance. If you >> somehow encounter a scenario where that won't work, of course, don't use it. >> >> > > Yes, but this is not the part that we discuss. > No, it is exactly what was under discussion. Here is your exact quote to which my above paragraph is a response: *The wrapper does not have to be a web2py application, but the wrapped object must be the folder that contains the controller, the views, the models, etc. designed by the author. The whole idea here is to have a clean separation between the wrapper and the wrapped application. I believe that you might have misunderstood the concept and perhaps you are going to give up, but it does not mean the concept is not important.* You were clearly claiming that I misunderstood your requirement to have the wrapper reside outside of the application folder. > Just want to make sure we understand each other. I agree that we are doing > great, but there was this point. Also, I still do not agree about the > "unimportant". I suspect you meant not important for someone that uses > web2py in a real practical scenario. However, this is the thing that is not > important for someone that is interested in creating a different framework. > I understand that you disagree about the importance of the nature of the wrapping that you propose. Yet you have still made no argument whatsoever about why it is important, other than simply to state that it is self-evident. So, I think we understand each other. If you want to wrap at the application level, the best you can do is put >> the wrapper code inside the application folder. If you are willing to wrap >> at the framework level, you can use WSGI middleware. >> > > I thought we agreed that it was possible at the application level using > middleware. The initial code that handle the requests, which is a kind of > wrapper, needs only to map these requests to different application wrappers > in view of the application. These wrappers will then call > gluon.main.wsgibase as usual. This does not seem so complicated. > That still does not wrap the code at the application level. Wrapping at the application level means executing code in the same web2py environment where the application code is executed (so, for example, you can access and manipulate the same web2py request object that gets passed to the application itself). Using WSGI middleware, you are wrapping at the framework level in the sense that you can only intercept the incoming WSGI environment (before the web2py framework does anything with it) and the outgoing WSGI string/iterable response (after web2py has serialized the response object). > If you want to somehow write two separate web2py applications, one of >> which transparently "wraps" the other (without requiring any cooperation >> from the wrapped application and without redirects), >> > > I agreed that this is not useful. I am happy with a wrapper that is not a > web2py application. > But you weren't quite happy with the way to achieve that in web2py, which requires manipulating the various handlers used with different web servers (or forking the framework). The only way to avoid that is to wrap at the application level via a file in the application folder, which you also don't like, leaving something like the third (non-existent) option above. But if you say you are happy with the available options, great. > However, just step back a bit. There is a use case, which was used to >>> define the concept of application wrapper. It's important that this >>> definition takes into account all requirements of the use case. One of the >>> requirements is that the installer does not use the application folder. >>> >> >> A *requirement* is different from a *use case*. >> > > Sure, but we extract requirements from use cases. This is the common > notion of use cases. > Yes, that is my exact point. But just because *some* requirements are extracted from use cases does not mean *all *requirements come from use cases. A use case implies a real world scenario where the requirement is really a >> requirement. >> > > That would make use cases only useful to state requirements in systems > that currently exist in the real world. It is not the commonly accepted > notion of use cases. It is important to do that, but it is not enough. We > need also (abstract) use cases to define where we want to go in the future. > Typically, use cases for future developments are abstract. > I did not argue that a use case must currently exist, only that we shouldn't necessarily strain ourselves to meet random requirements unless we think we will have some *use* for them (now or in the future). Of course, if it is trivially easy to provide some extra flexibility by meeting a particular requirement, go for it. But note that this is all in the context of web2py. Doing *exactly* what you want is not quite possible out of the box. I'm just arguing that in the context of web2py, doing *exactly* what you want also isn't that important, as we can implement alternative solutions that should meet all your needs. In other words, in the context of web2py, it wouldn't be worth making any great efforts to give you exactly what you want, because those efforts would buy you very little. > What I have in mind is that the code of the application directly reads >>> this location, which is under the control of the installer and by looking >>> at the code you know the location relative to the application folder. This >>> is not what happens when the information is passed by a wrapper. So, you >>> must have an intermediary "wrapper" in your proposal. >>> >> >> Again, take some time and write the code. Hopefully that will help you >> see where you are going wrong here. >> > > Why do you assume that I am wrong? Maybe you don't grasp what I have in > mind. > I've explained it multiple times. If you'd like to discuss the above issue any further, please show some code. Basically, you are saying implement the solution in each case. It's fine, > just thought that maybe there was more. I might prefer to implement your > proposal by hacking the core. I rename gluon.main.wsgibase to > gluon.main.wsgibase_wrapped and then gluon.main.wsgibase becomes the > wrapper, In this way, it works for all servers, no need to implement the > solution for each server. > Sure, but it's generally not a good idea to fork the framework (you might break something important, and then you have to bother with merging all future changes, or give up on upgrading in the future). In fact, as long as you're going to fork the framework, using WSGI middleware is probably not the simplest option. Instead, you could probably hack gluon.main.wsgibase directly to wrap applications at a higher level (i.e., within the web2py environment). Anthony -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
