On Thursday, 23 June 2016 15:41:35 UTC-4, Anthony wrote:
>
> On Thursday, June 23, 2016 at 1:26:38 PM UTC-4, Dominic Mayers wrote:
>>
>> It is also important that the installer does not have to use the
>> application folder.
>>
>
> Unless you can identify common scenarios in which there is an installer
> who is responsible for setting up web2py but somehow does not have access
> to the application folder, I disagree that this is important.
>
That is one point of disagreement. I don't think it is a valid criteria. I
agree that use cases are important, but they are not useful to determine
what is important. What we view as important is very relative. I will stop
to react to this point of disagreement.
>
>
>> However, if your objective is to be able to pass the configuration
>> information and the installer can use the application folder, I don't see
>> why they would not use it to achieve this objective, no need for a wrapper.
>> So, I include in the definition of an application wrapper the requirement
>> that the installer does not need to edit the application folder. I think
>> it makes sense to do that.
>>
>
> 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/location
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 of
configlocation.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.
> Perhaps the confusion is that I agreed that the wrapper does not have to
>> be a web2py application, but this is different. 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.
>>
>
> No, there is no confusion.
>
OK, I was just trying to see why you seem to not understand.
> 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. We discuss why not use a
simple solution with no wrapper when the installer can use the application
folder.
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.
>>
>
> At this point, it is not clear what you hope to achieve with further
> discussion.
>
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.
> 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.
> 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.
> then you would have to write some very specialized code to achieve that
> (and it might be difficult to ensure all edge cases are well handled). The
> *exact* thing you are asking for,
>
I am not asking for that.
> therefore, simply isn't available out of the box. You can continue going
> on about how important it is, but that won't summon it into existence. So,
> what are you trying to accomplish here?
>
As I said, I already implemented the solution you provided and the next
step would be to make it at the application level, still without using the
application folder. The wrapper in your solution needs only be a bit more
complicated to call other wrappers in view of the application, which can be
found in the request. Perhaps, there should be a default wrapper when one
does not exist.
>
>
>> 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.
> 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.
> You have not described a real world situation in which someone who is
> responsible for setting up the framework does not have access to the
> application folder. But again, even if there is such a case, we are still
> left with the options previously articulated -- so, choose one and move on.
>
I already implemented the solution that you proposed, right at the
beginning.
>
>> Specifically, in your case, why it is not easy to have a wrapper where
>> the installer does not need to use the application folder? If it is not
>> easy, is there some fundamental explanation related to the web2py
>> architecture?
>>
>
> Yes, this has already been explained.
>
I missed that. Where was it explained?
> But as I said, if you would like to explore these ideas further, I suggest
> you spend more time learning web2py, maybe study some of its source code.
> Try building what you want and see what you end up with.
>
>
Sure. This is what I am doing. As I said, I already implemented your
solution.
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.
>
>
>> Perhaps what you are saying is that you only care about the concrete
>> proposals in terms of code and you don't feel the concepts are important.
>> Therefore, as long as you do not see any progress in terms of proposals,
>> actual code, you feel you are turning into circles. That would be OK. I
>> would consider this as a rule, at the least with you.
>>
>
> I have no such rule and think I have demonstrated I am happy to discuss
> concepts.
>
Yes, it is the "unimportant" that seems to say the opposite. There are two
concepts. One where the author does not have to know the location of the
config file, so not as in the simple solution where the code uses info
stored in one location to find another location. Another one where we have
the extra requirement that the installer does not need to use space in the
application folder.
> However, I think we have covered everything conceptually, and you should
> now be aware of the various implementation possibilities. So all that is
> left to do is actually implement the solution you seek.
>
>
>> I might still have a question regarding code. How do you make sure that
>> the edit of wsgihandler.py, without hacking the names for
>> gluon.main.wsgibase, is seen irrespective of the web server?
>>
>
> Well, any deployment setup will ultimately require providing a WSGI
> application. So, just write a WSGI compliant callable (which itself will
> ultimately call gluon.main.wsgibase), and make sure you point the web
> server to that callable by whatever means are appropriate for the
> particular web server. The logging option in wsgihandler.py using
> gluon.main.appfactory is an example of this approach, so study that as a
> starting point.
>
> Basically, you are saying implement the solution in each case. It's fine,
just thought that maybe there was more.
--
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 [email protected].
For more options, visit https://groups.google.com/d/optout.
