Re: REST and confirmation of DELETE operation
On 01/30/2010 03:10 AM, Mike Orr wrote: Beware of the RESTafarians. REST solves a certain set of problems, and its best realization seems to be ATOM. But the don't use cookies or sessions argument fails to provide alternatives for logging in or restricted access, and makes result sets needlessly cumbersome. You end up putting the result ID (which is really a kind of session ID) in the URL. Or you transmit the whole data to the client and back through request variables, which is unfeasable with large data sets. And it's impossible if the client shouldn't actually see the raw data. And having random result IDs still doesn't answer the question of whether the current request should have access to that result set. So complete statelessness is impossible or at least unreasonably cumbersome. The sessions argument is often misunderstood, imho. The way I see it, Fielding proposed it as a guide primarily to allow scalability. Conveying as much information as possible into the HTTP protocol itself -- as opposed to application protocol present in the request content -- is actually beneficial on many levels, for example it allows data partitioning on the HTTP layer, before the request even reaches the application for processing. Which, in turn, facilitates scalability. However cookies are part of HTTP. They do not necessarily contain application state. A session, for that matter, need not contain application state, but client state validated server-side. Or temporary state of data behind regular URIs. In short: it's a matter of how you observe it. Traditionally, session data is kept in files local to the server. That is not scalable, I agree. But move it to a memcached cluster and it becomes scalable. And at that point, it becomes no different than the regular data behind URIs, which is, in order to be scalable, also in a distributed storage container, a.k.a a database cluster. If scalability is the only concern, then, the session data observed as temporary resources which only particular clients should interact with is fully RESTful. If purism and strict following of Fielding's rules is of concern, then RESTful application can never be anything other than simple public services where security is not an issue. I also notice that all of the most popular social networks abuse query strings horribly, worse than any of us would ever do, yet that hasn't caused the sites to crash or their users to boycott them because their URLs are bad. So REST is not necessary to make the world go round and the sun come up. In REST the URIs are opaque, as they say. That means that the URI has no meaning to the client other than being a unique ID for a resource. It can be called /page/view/123, or /asdkjh45kua8kr. The theory here states that resources should link between themselves. A pure RESTful client should not have to know how to construct the URI, but the result set should contain enough URIs for it to function properly. When the client creates a resource, the RESTful response should say 201 and provide a link to it, not just the primary key for client to construct the link. And that satisfies the self-descriptiveness requirement of REST. With that, any client that understands HTTP can come along, create a resource and will understand what 201 + Location means, because it is inherent to HTTP. REST makes a point here that apps should not reinvent the wheel with a protocol built additionally to the HTTP itself, if HTTP itself can carry out the action. I agree with the not inventing the wheel thing, but I also understand there are situations where you can't just follow pure REST. Still, REST is a good ideal, and it's worth moving closer to it when feasable. But its biggest advantage is for noninteractive clients which don't want to know the particular site's idiosyncracies. Its benefit to interactive sites is less certain, especially those that are heavy on user accounts, result sets, and shopping carts. Agreed. :) Vlad -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@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: REST and confirmation of DELETE operation
The new stuff in dev Routes will make the addition of new subresources
easier. In this case, link(confirm_delete) on the SubMapper object
returned by submapper() or collection() would do nicely. Not everyone
will want it in quite the same way so I wouldn't necessarily make it a
standard action though.
I feel compelled to say after reading this entire thread that this
doesn't have to be unRESTful. REST doesn't mean sticking slavishly to
ATOM - isn't workflow via hyperlinks what HATEOAS is all about?
Regards,
Mike
m...@asplake.co.uk
http://positiveincline.com
On Jan 29, 9:33 pm, Mike Orr sluggos...@gmail.com wrote:
On Fri, Jan 29, 2010 at 10:18 AM, Vladimir Dronnikov
dronni...@gmail.com wrote:
Thanks for feedback. My appoach is similar.
I appended an additional member for resource mapper in config/routing.py:
...
map.resource('model', 'models', path_prefix='/admin/{model_name}',
controller='admin', member={'confirm':'GET'})
That's what I did, only I used:
member={ask_delete: GET}
I think this should be added to Routes. Delete confirmation is
necessary in many interactive applications.
and redirected my 'Delete' links to this method.
But wonder if the same effect can be achieved more reliably (and
elegantly) by means of some kind of guarding decorators applied to
potentially dangerous (mostly destructive) methods?
We have such decorators for authentication/authorization purpose. Have
anyone seen such for confirmation problem?
Interactive users won't get to the delete action except through the
form. They can't enter it directly into the URL box because that
always produces a GET. Non-interactive agents are accustomed to
producing 'DELETE' requests directly, and wouldn't know what to do
with a form anyway.
You can undoubtedly simulate a confirmation with a decorator, but just
adding a GET URL with a form seems more straightforward.
You can't double up the confirmation form and the delete action on the
same URL, at least not with REST, because GET'ting the same URL
displays the record. So you have to use a different URL for the
confirmation form.
Or you can use Javascript to display a confirmation alert dialog.
That's a kind of decorator. But it would be bypassed in non-visual
browsers or if Javascript is disabled.
I don't understand Vlad's point:
Confirmation is a process that is not fully compatible with (pure) REST,
because requests must not be dependent of previous ones.
But if you need one, think of it as a Deletion resource. POST to
create a deletion resource. The response is a form containing a nonce
token, ...
A pure REST client would not use the confirmation, it would just
DELETE the resource directly. The confirmation step, if any, would be
built into the client itself. But there's nothing wrong with adding
additional GET URLs to resources. That's just asking the resource to
show a different view of itself. And if the view happens to contain
a form that submits a delete action, so what?
--
Mike Orr sluggos...@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-disc...@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: REST and confirmation of DELETE operation
On Sat, Jan 30, 2010 at 4:06 AM, Haron Media i...@haronmedia.com wrote: On 01/30/2010 03:10 AM, Mike Orr wrote: Beware of the RESTafarians. REST solves a certain set of problems, and its best realization seems to be ATOM. But the don't use cookies or sessions argument fails to provide alternatives for logging in or restricted access, and makes result sets needlessly cumbersome. You end up putting the result ID (which is really a kind of session ID) in the URL. Or you transmit the whole data to the client and back through request variables, which is unfeasable with large data sets. And it's impossible if the client shouldn't actually see the raw data. And having random result IDs still doesn't answer the question of whether the current request should have access to that result set. So complete statelessness is impossible or at least unreasonably cumbersome. The sessions argument is often misunderstood, imho. The way I see it, Fielding proposed it as a guide primarily to allow scalability. Conveying as much information as possible into the HTTP protocol itself -- as opposed to application protocol present in the request content -- is actually beneficial on many levels, for example it allows data partitioning on the HTTP layer, before the request even reaches the application for processing. Which, in turn, facilitates scalability. I agree with putting resource IDs into the URL rather than query parameters as much as possible. That's what I meant about social networks abusing query parameters. /photos.php?imageid=123friendid=456someotherid=789sort=alphastart=144 In REST the URIs are opaque, as they say. That means that the URI has no meaning to the client other than being a unique ID for a resource. It can be called /page/view/123, or /asdkjh45kua8kr. Well, from a machine point of view, OK. But I also think URLs should be human readable, and each component should contain the one on its right. I got those ideas from the REST literature. -- Mike Orr sluggos...@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-disc...@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: REST and confirmation of DELETE operation
On Sat, Jan 30, 2010 at 7:09 AM, Vladimir Dronnikov dronni...@gmail.com wrote: I don't quite understand what you mean by the real world not cascading? Suppose A buys B manufactured by C. When A or C go out of scope (die, e.g.), it doesn't mean the end of B, right? It all depends on what the resource is. Often with /A/B/C, C is a logical subcategory of B, and B of A. So if B ceases to exist, all C's disappear too. I would not necessarily assume that database cascading is related to URL cascading. It's up to the client to determine whether to delete that particular resource. It's up to the server to determine whether it should also cascade to delete some other resources too. I have applications where the client is never allowed to delete anything because it's meant to be a permanent record. And others where the client can't create or delete, but only edit, because all creation is done offline. map.resources (and I guess REST/Atom) assume you can always create and delete anything at any time, unless you get a forbidden error. So that's another thing I'd like to add to it, suppressing certain actions. -- Mike Orr sluggos...@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-disc...@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: REST and confirmation of DELETE operation
On Sat, Jan 30, 2010 at 7:43 AM, Vladimir Dronnikov dronni...@gmail.com wrote: Suppose A buys B manufactured by C. When A or C go out of scope (die, e.g.), it doesn't mean the end of B, right? It all depends on what the resource is. Often with /A/B/C, C is a logical subcategory of B, and B of A. So if B ceases to exist, all C's disappear too. Hmm. Consider Toyota has manufactured a dozen of certain cars. I _hardly_ imagine if Toyota drops (ever:) those dozen of cars will _immediately_ disappear too. Consider a site of incidents (i.e., situations you're responding to or have responded to) containing entries (reports of specific things you've done, photos, etc). Deleting an entry should not affect the incident. But deleting the incident should delete all entries because they refer to an incident which doesn't exist, one which you've specifically said you don't care about. -- Mike Orr sluggos...@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-disc...@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: REST and confirmation of DELETE operation
On 01/30/2010 04:43 PM, Vladimir Dronnikov wrote: Personally, I think cascade-on-deletion is just a convenient way to simplify sql queries which otherwise should constantly be aware of possible NULL dereferences. So cascade-on-deletion is totally due to sql misfeature in this area. It's not a misfeature, it's a requirement for normalized datasets where orphans should not exist. Note the keyword here is normalized dataset, which requires relations between tables. So it is a consequence of a set rules in a given system: B should exist only if A exists. And in order for the system to work properly, cascades should occur. The system here is a database, and the rule is Informational Integrity. All this, however, is perhaps specific to information technologies and hardly translated into macro world of physical, or in your example with the cars. Though there is cascade on certain levels even on physical world. Your car will die (in time) if the buyer disappears so there's no one to take care of it, or the manufacturer disappears and there's no more support (no spare parts). But if you say that other manufacturers and auto shops can pick up the support, so can database rows, if rules require or allow it. On the quantum level, there is cascade with entangled pairs. Update or delete one, the other will respond equally. However your analogy is wrong because the system of ABC does not require the same set of rules. If it did require, let's say in form of a law that said all cars should be destroyed if their manufacturer disappeared, then it would cascade also, because the rule of the system says so. Another example: DRM. If the certificate issuer disappears, you can't view DRM'ed content. Vlad -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@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: REST and confirmation of DELETE operation
Consider a site of incidents (i.e., situations you're responding to or have responded to) containing entries (reports of specific things you've done, photos, etc). Deleting an entry should not affect the incident. But deleting the incident should delete all entries because they refer to an incident which doesn't exist, one which you've specifically said you don't care about. Again, deleting an incident has no sense (in applied world) since the incident _has_ _physically_ occured! In your example the incident with all related stuff should be marked 'archived' and thus go out of scope. Of course, in _sql world_ the above technique is best implemented as DELETE ... CASCADE. That's the point, IMHO. -- Vladimir -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@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: REST and confirmation of DELETE operation
It's not a misfeature, it's a requirement for normalized datasets where orphans should not exist. Note the keyword here is normalized dataset, which requires relations between tables. So it is a consequence of a set rules in a given system: B should exist only if A exists. And in order for the system to work properly, cascades should occur. The system here is a database, and the rule is Informational Integrity. And all the above is theory. Humans just need to stick to Aristotle' logic, or they start to melt. All this, however, is perhaps specific to information technologies and hardly translated into macro world of physical, or in your example with the cars. Though there is cascade on certain levels even on physical world. Your car will die (in time) if the buyer disappears so there's no one to take care of it, or the manufacturer disappears and there's no more support (no spare parts). But if you say that other manufacturers and auto shops can pick up the support, so can database rows, if rules require or allow it. On the quantum level, there is cascade with entangled pairs. Update or delete one, the other will respond equally. So states the _proven_ physical law. No artificial cascading here just for convenience. (However, who knows, may be the higher ratio thinks in sql terms? :) However your analogy is wrong because the system of ABC does not require the same set of rules. If it did require, let's say in form of a law that said all cars should be destroyed if their manufacturer disappeared, then it would cascade also, because the rule of the system says so. Of course, if it did require. But it didn't. So here we again try to impose a pure artificial constraint just to keep dataset normalized and thus to stick to a convenient model. Another example: DRM. If the certificate issuer disappears, you can't view DRM'ed content. ... which pretty certainly doesn't mean the content itself _does_ disappear too. . I'd like to ask you what exact response codes which CRUD operations should return in REST? How good the codes other than 200 is supported (in sense of considering them as success) by jQuery? TIA, -- Vladimir -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@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: REST and confirmation of DELETE operation
On 01/30/2010 05:35 PM, Vladimir Dronnikov wrote: And all the above is theory. Humans just need to stick to Aristotle' logic, or they start to melt. It's not just theory. It is a consequence of a system with rules. Humans also live in a system with rules and must obey them, like it or not. Even the greatest anarchist will eventually succumb to the rules imposed by Entropy. So if a rule says B should disappear when A does, it is a normal state for the system obeying those rules. The rules, however, may be imposed by nature or man, the principle remains. So states the _proven_ physical law. No artificial cascading here just for convenience. (However, who knows, may be the higher ratio thinks in sql terms? :) Cascading on a foreign key is not a convenience, it is a rule of normalized relational dataset that requires informational integrity. Whether it is artificial or not depends on the interpretation of artificial. If you do not require informational integrity then you will design your system with no foreign keys. You can also bunch everything in a single table and forget normalization. And therefore no relations and no cascades. It all depends on the desires of the programmer or DBA. Similarly with a file system. You can have indices that point where files and corresponding sectors are. They are convenience because without them the application would have to scan entire disc to find its files. But a FAT table is not a convenience. It is a relation between position of a file and its data on disc. Without it, the application cannot find its data because there is no pointer to it. This is a relation not unlike foreign keys. That the data is not deleted when the file (pointer) is is just a matter of performance. Secure systems that require deletion of data will delete both the pointer and the data because it is normal operation within the rules of the system. Nothing artificial there, just the requirements of a system. Of course, if it did require. But it didn't. So here we again try to impose a pure artificial constraint just to keep dataset normalized and thus to stick to a convenient model. You can build tables with no foreign keys and therefore no cascades. The cascades are only there if you impose a set of rules on your tables. And it is only as artificial as the entire IT concept: namely, nature didn't build them, we did. Machines understand only binary. It is the dev who gives meaning to the data and hence imposes rules so the machine can understand the relations. It all boils down to the rules saying: I have two tables, their rows are related. If a row in table A is gone, the corresponding row in table B should too. Why? Because the designer of the system sees a meaning that the machine does not. If the machine were an AI it would probably delete row B without the program telling it to cascade, because the machine understood the relation (after learning of one). Machines of nature work similarly. A simple rule says that the cell needs power. So it happens that in the evolutionary dataset one important relation emerged: that between mitochondria (A) and the cell (B). It says that A provides power for B. Another rule says if there's no A, B dies. The underlaying hardware (pure atoms and molecules) couldn't care less and see the relation as artificial, from their point of view, because they don't understand the relation. And if you really want to get philosophical (and I see I've gone that way already, heh), I recommend: http://arxiv.org/abs/0801.0337 :))) ... which pretty certainly doesn't mean the content itself _does_ disappear too. Given strong enough encryption it is as good as dead. A file with random bits, for all that anyone without the key cares. Vlad -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@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: Fastcgi and performance
Hi guys
Here is what I have manged to get working:
=HelloWorld.fcgiworking, OK
#!$HOME/html/Others/PVE/bin/python
import sys
sys.path.insert(0, '$HOME/html/Others/PVE/lib/python2.5')
def myapp(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return ['Hello World!\n']
if __name__ == '__main__':
from flup.server.fcgi import WSGIServer
WSGIServer(myapp).run()
==
=HelloWorld.cgiworking, OK=
#!$HOME/Others/PVE/bin/python
import sys
from paste.deploy import loadapp
import wsgiref.handlers
sys.path = ['$HOME/html/Others/HelloWorld'] + sys.path
wsgi_app = loadapp('config:$HOME/html/Others/HelloWorld/
development.ini')
wsgiref.handlers.CGIHandler().run(wsgi_app)
==
=MyApp.cgiworking, with errors, see
below=
#!$HOME/html/Others/PVE/bin/python
import sys
from paste.deploy import loadapp
import wsgiref.handlers
#os.chdir($HOME/html/Others/Anki/MyAppweb)
sys.path = ['$HOME/html/Others/PVE/lib/'] + sys.path
sys.path = ['$HOME/html/Others/MyApp/MyAppweb'] + sys.path
sys.path.insert(0, $HOME/html/Others/MyApp/libMyApp)
wsgi_app = loadapp('config:$HOME/html/Others/MyApp/MyAppweb/
production.ini')
wsgiref.handlers.CGIHandler().run(wsgi_app)
==
Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/css/app.css
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/study/getCSS
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/jquery-1.2.6.min.js
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/jquery.hotkeys-0.7.8-packed.js
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/MochiKit/MochiKit.js
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/MochiKit/MochiKit.js
[Sat Jan 30 09:29:07 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/activity.gif
These files are all rooted in the public folder of the application.
How can I fix this please?
However the my application is slow, so is the HelloWorld aplication
athough this one has no errors in the log.
I believe this is because of the cgi approach.
==Myapp.fcgi ==Lightning fast===BUT WITH ERRORS see
below=
#!/home/content/c/r/i/cristip/html/Others/PVE/bin/python
import os, sys
sys.path = ['$HOME/html/Others/PVE/lib/'] + sys.path
sys.path = ['$HOME/html/Others/MyApp/MyAppweb'] + sys.path
sys.path.insert(0, $HOME/html/Others/MyApp/libMyApp)
from paste.deploy import loadapp
wsgi_app = loadapp('config:$HOME/html/Others/MyApp/MyAppweb/
development.ini')
# Deploy it using FastCGI
if __name__ == '__main__':
from flup.server.fcgi import WSGIServer
WSGIServer(wsgi_app).run()
The problems that I have with FCGI
On top of the errors listed above (the app is not able to find
javascript files, css files and gif files I also have
the following problem:
The address of the application is:
http://www.mydomain.com/cgi/MyApp.fcgi/ (doesn't work without / at
the end, I found that out accidentally)
The application has some menus which are all pointed to a shortest
path, see below:
Login should be
http://www.mydomain.com/cgi/MyApp.fcgi/account/login
but the application is pointing to
http://www.mydomain.com/cgi/account/login
ans so on. As you can see MyApp.fcgi seems to be eliminated
automatically and I believe that is because the application
was not designed to work this way. How can I fix this?
Thank you all
PF
On Jan 28, 11:28 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
On Jan 29, 2:02 pm, PF4Pylons ultimulunic...@gmail.com wrote:
The provider is Godaddy
Here is all they say about fastcgi in their help section
http://help.godaddy.com/search?q=fastcgix=0y=0
Quite cryptic sometimes.
I will get back to this after I configure the HelloWorld app.
I did mention the provider in the other thread I started here, I had
the impression you replied there too.
I will also update that thread, I have made some progress there but I
run into an other roadblock.
Under their Perl FAQ entry they say:
NOTE: This will need to be done in any directory outside of /cgi in
which you want to run .fcgi scripts.
So, they mention .fcgi files.
It would be quite silly if they were using .fcgi files and the only
thing you can stick in it is Perl. If that were the case they should
have used a specific Perl extension.
As such, it looks a good bet that if you can get flup installed into
your account and can set up sys.path to reference where flup is, it
may work.
Thus, install flup under lib/python in your home directory.
Re: Beginner questions:Pylons and fastCGI -performance issue and some errors
These have all been solved, please see http://groups.google.com/group/pylons-discuss/browse_thread/thread/9a50d5bcf10f640a/840c7f9fc482d573#840c7f9fc482d573 I insist to use Godaddy because the website is in beta testing, I just paid the hosting and the domain for one year ahead and I don't want to waste that money. If the idea is taking off I will switch instantly to a virtual server or better. Thanks all for everything On Jan 27, 12:06 am, Mike Orr sluggos...@gmail.com wrote: I took a closer look at your original messages since the problem is more than just FastCGI. But I'm not sure we'll be able to solve your problem definitively for reasons described below. On Tue, Jan 26, 2010 at 11:34 AM, PF4Pylons ultimulunic...@gmail.com wrote: Hi all I am beginner with pylons and Python and I am trying to move an Appweblication from a server to a shared host environment. The Appweblication was developed by somebody else, I am not programmer and I am trying to learn what it takes to just do the move. Well first, what's an Appweblication? Is this something specific to GoDaddy or your previous server? Or do you just mean a web application. Here is what I am running: -Python 2.5 installed in a virutal environment because I needed to add some more modules that were not allowed by the hosting company. They also run a older version. The provider is Godaddy so if anyone managed to install Pylons Appweblication there I would be glad to hear about their experiences. I can't understand why when I run the aplication using paster via command line everythig is fine but when I try to start it as CGI there are some dependencies missing. I'm pasting in parts of two messages here. It's possible that the webserver is not running the Python in your virtualenv but the system Python. In that case, it won't have access to the modules in your virtualenv. If you can get a simple Pylons application running in debug mode, you can insert raise RuntimeError and look through the variables in the interactive traceback. If that doesn't work, just make a simple CGI script that prints the Python path: import sys, pprint print Content-type: text/plain print print sys.executable pprint.pprint(sys.path) import somemodule print somemodule That'll show which Python is running and where it can load modules from. Printing a module object shows which directory it was imported from. Python is the ActivePerl version because this version comes with all the modules that I needed included. I take it you meant ActivePython. I needed sqlite2 but ActivePerl has sqlite3 I hope that is good. I've always used 3. I haven't heard of any compatibility problems between the versions. I haven't reach the point to run the Appweblication -Pylons 0.9.6.2 So it's a pretty old application, more than a year old I guess. -I had to remove Routes Routes-1.10.3-py2.5.egg and to install routes==1.9 Routes has some new defaults, so it's possible these are incompatible with your older application. Older apps often depend on minimization and implicit defaults. (Not that that means anything to you, but it would be the first place to look if you wanted to upgrade the app.) /myhomedirhtml/Others/PVE/lib/python2.5/site-packages/Pylons-0.9.6.2- py2.5.egg/pylons/middleware.py:11: DeprecationWarning: The webhelpers.rails package is deprecated. - Please begin migrating to the new helpers in webhelpers.html, webhelpers.text, webhelpers.number, etc. - Import url_for() directly from routes, and redirect_to() from pylons.controllers.util (if using Pylons) or from routes. - All Javascript support has been deprecated. You can write link_to_remote() yourself or use one of the third-party Javascript libraries. from webhelpers.rails.asset_tag import javascript_path These are due to version changes in WebHelpers. You can ignore these, or downgrade WebHelpers until they disappear. I think the rails warning was added in version 0.6. WebHelpers 0.3.4 is still on PyPI but it's hidden so you'll have to go to the exact URL:http://pypi.python.org/pypi/WebHelpers/0.3.4. Otherwise you can use 0.6.4 and ignore the messages. Don't use any of the WebHelpers 1.0 betas, because they don't have the deprecated code. File /home/resolve/Lib/code/Appweb/Appweb/config/middleware.py, line 34, in make_Appweb File /home/resolve/Lib/code/Appweb/Appweb/config/environment.py, line 27, in load_environment File /home/resolve/Lib/code/Appweb/Appweb/lib/Appweb_globals.py, line 17, in __init__ ImportError: No module named fonts I don't think there's a 'fonts' module among Pylons' dependencies, so it must be something the application is using. I'm also surprised at those 'make_appweb' and 'Appweb_globals.py' names, and 'Appweb/Appweb' (instead of 'Appweb/appweb'). Current Pylons applications have a 'make_app' function and a 'myapp/lib/app_globals.py' file. Perhaps
Re: two routes / dispatch questions
On Jan 30, 2:06 am, Mike Orr sluggos...@gmail.com wrote: I consider such slash manipulation to be highly unorthodox and undesirable, but that's how you can do it if you want to. Thanks Mike! I find the slash manipulation to be standard. The default behavior for static webservers has been: filesystem: /folder/index.html urls: /folder/index.html /folder/ /folder ( redirects to /folder/ ) -- You received this message because you are subscribed to the Google Groups pylons-discuss group. To post to this group, send email to pylons-disc...@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: Fastcgi and performance
On Jan 31, 4:46 am, PF4Pylons ultimulunic...@gmail.com wrote:
Hi guys
Here is what I have manged to get working:
=HelloWorld.fcgiworking, OK
#!$HOME/html/Others/PVE/bin/python
import sys
sys.path.insert(0, '$HOME/html/Others/PVE/lib/python2.5')
You cannot use '$HOME' in Python variable strings like that. List the
path explicitly.
def myapp(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return ['Hello World!\n']
if __name__ == '__main__':
from flup.server.fcgi import WSGIServer
WSGIServer(myapp).run()
If this work when you had $HOME above, they must already have flup
installed.
==
=HelloWorld.cgiworking, OK=
#!$HOME/Others/PVE/bin/python
import sys
from paste.deploy import loadapp
import wsgiref.handlers
sys.path = ['$HOME/html/Others/HelloWorld'] + sys.path
wsgi_app = loadapp('config:$HOME/html/Others/HelloWorld/
development.ini')
wsgiref.handlers.CGIHandler().run(wsgi_app)
==
=MyApp.cgiworking, with errors, see
below=
#!$HOME/html/Others/PVE/bin/python
import sys
from paste.deploy import loadapp
import wsgiref.handlers
#os.chdir($HOME/html/Others/Anki/MyAppweb)
sys.path = ['$HOME/html/Others/PVE/lib/'] + sys.path
sys.path = ['$HOME/html/Others/MyApp/MyAppweb'] + sys.path
sys.path.insert(0, $HOME/html/Others/MyApp/libMyApp)
wsgi_app = loadapp('config:$HOME/html/Others/MyApp/MyAppweb/
production.ini')
wsgiref.handlers.CGIHandler().run(wsgi_app)
==
Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/css/app.css
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/study/getCSS
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/jquery-1.2.6.min.js
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/jquery.hotkeys-0.7.8-packed.js
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/MochiKit/MochiKit.js
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/MochiKit/MochiKit.js
[Sat Jan 30 09:29:07 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/activity.gif
These files are all rooted in the public folder of the application.
How can I fix this please?
However the my application is slow, so is the HelloWorld aplication
athough this one has no errors in the log.
I believe this is because of the cgi approach.
==Myapp.fcgi ==Lightning fast===BUT WITH ERRORS see
below=
#!/home/content/c/r/i/cristip/html/Others/PVE/bin/python
import os, sys
sys.path = ['$HOME/html/Others/PVE/lib/'] + sys.path
sys.path = ['$HOME/html/Others/MyApp/MyAppweb'] + sys.path
sys.path.insert(0, $HOME/html/Others/MyApp/libMyApp)
from paste.deploy import loadapp
wsgi_app = loadapp('config:$HOME/html/Others/MyApp/MyAppweb/
development.ini')
# Deploy it using FastCGI
if __name__ == '__main__':
from flup.server.fcgi import WSGIServer
WSGIServer(wsgi_app).run()
The problems that I have with FCGI
On top of the errors listed above (the app is not able to find
javascript files, css files and gif files I also have
the following problem:
The address of the application is:
http://www.mydomain.com/cgi/MyApp.fcgi/ (doesn't work without / at
the end, I found that out accidentally)
You need some mod_rewrite magic, but they have to have
allowed .htaccess file usage and required overrides to allow you to
use mod_rewrite directives.
Do you have that access?
Graham
The application has some menus which are all pointed to a shortest
path, see below:
Login should be
http://www.mydomain.com/cgi/MyApp.fcgi/account/login
but the application is pointing to
http://www.mydomain.com/cgi/account/login
ans so on. As you can see MyApp.fcgi seems to be eliminated
automatically and I believe that is because the application
was not designed to work this way. How can I fix this?
Thank you all
PF
On Jan 28, 11:28 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
On Jan 29, 2:02 pm, PF4Pylons ultimulunic...@gmail.com wrote:
The provider is Godaddy
Here is all they say about fastcgi in their help section
http://help.godaddy.com/search?q=fastcgix=0y=0
Quite cryptic sometimes.
I will get back to this after I configure the HelloWorld app.
I did mention the provider in the other thread I started here, I had
the impression you replied there too.
I will also update that thread, I have made some progress there but I
run into an other roadblock.
Under their Perl FAQ entry they say:
NOTE: This will need to be
Re: Fastcgi and performance
That's true I just used $HOME to replace the too long string I had
there.
Yes they allow .htaccess and modrewrite
I am squzingmy brains to get the right rewrite rule and I can't.
I move the MyApp.fcgi in the application folder and right now I have
www.mydomain.com/Others/MyApp/account/login
instead of
www.mydomain.com/Others/MyApp/MyApp.fcgi/account/login
How do I Rewrite this string? I am using the following .htaccess in
the web folder /Others/MyApp/
Options ExecCGI
Options +FollowSymLinks
RewriteEngine On
RewriteRule ^/Others/MyApp/(\[-_a-zA-Z0-9/\.]+)$ /Others/MyApp/
MyApp.fcgi/$1
and this is not doing anything
Thanks
PF
On Jan 30, 7:23 pm, Graham Dumpleton graham.dumple...@gmail.com
wrote:
On Jan 31, 4:46 am, PF4Pylons ultimulunic...@gmail.com wrote:
Hi guys
Here is what I have manged to get working:
=HelloWorld.fcgiworking, OK
#!$HOME/html/Others/PVE/bin/python
import sys
sys.path.insert(0, '$HOME/html/Others/PVE/lib/python2.5')
You cannot use '$HOME' in Python variable strings like that. List the
path explicitly.
def myapp(environ, start_response):
start_response('200 OK', [('Content-Type', 'text/plain')])
return ['Hello World!\n']
if __name__ == '__main__':
from flup.server.fcgi import WSGIServer
WSGIServer(myapp).run()
If this work when you had $HOME above, they must already have flup
installed.
==
=HelloWorld.cgiworking, OK=
#!$HOME/Others/PVE/bin/python
import sys
from paste.deploy import loadapp
import wsgiref.handlers
sys.path = ['$HOME/html/Others/HelloWorld'] + sys.path
wsgi_app = loadapp('config:$HOME/html/Others/HelloWorld/
development.ini')
wsgiref.handlers.CGIHandler().run(wsgi_app)
==
=MyApp.cgiworking, with errors, see
below=
#!$HOME/html/Others/PVE/bin/python
import sys
from paste.deploy import loadapp
import wsgiref.handlers
#os.chdir($HOME/html/Others/Anki/MyAppweb)
sys.path = ['$HOME/html/Others/PVE/lib/'] + sys.path
sys.path = ['$HOME/html/Others/MyApp/MyAppweb'] + sys.path
sys.path.insert(0, $HOME/html/Others/MyApp/libMyApp)
wsgi_app = loadapp('config:$HOME/html/Others/MyApp/MyAppweb/
production.ini')
wsgiref.handlers.CGIHandler().run(wsgi_app)
==
Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/css/app.css
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/study/getCSS
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/jquery-1.2.6.min.js
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/jquery.hotkeys-0.7.8-packed.js
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/MochiKit/MochiKit.js
[Sat Jan 30 09:29:06 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/js/other/MochiKit/MochiKit.js
[Sat Jan 30 09:29:07 2010] [error] [client 121.1.1.1] File does not
exist: $HOME/html/activity.gif
These files are all rooted in the public folder of the application.
How can I fix this please?
However the my application is slow, so is the HelloWorld aplication
athough this one has no errors in the log.
I believe this is because of the cgi approach.
==Myapp.fcgi ==Lightning fast===BUT WITH ERRORS see
below=
#!/home/content/c/r/i/cristip/html/Others/PVE/bin/python
import os, sys
sys.path = ['$HOME/html/Others/PVE/lib/'] + sys.path
sys.path = ['$HOME/html/Others/MyApp/MyAppweb'] + sys.path
sys.path.insert(0, $HOME/html/Others/MyApp/libMyApp)
from paste.deploy import loadapp
wsgi_app = loadapp('config:$HOME/html/Others/MyApp/MyAppweb/
development.ini')
# Deploy it using FastCGI
if __name__ == '__main__':
from flup.server.fcgi import WSGIServer
WSGIServer(wsgi_app).run()
The problems that I have with FCGI
On top of the errors listed above (the app is not able to find
javascript files, css files and gif files I also have
the following problem:
The address of the application is:
http://www.mydomain.com/cgi/MyApp.fcgi/ (doesn't work without / at
the end, I found that out accidentally)
You need some mod_rewrite magic, but they have to have
allowed .htaccess file usage and required overrides to allow you to
use mod_rewrite directives.
Do you have that access?
Graham
The application has some menus which are all pointed to a shortest
path, see below:
Login should be
http://www.mydomain.com/cgi/MyApp.fcgi/account/login
but the application is pointing to
http://www.mydomain.com/cgi/account/login
ans so on. As you can see MyApp.fcgi seems to be
Re: REST and confirmation of DELETE operation
On Sat, Jan 30, 2010 at 8:09 AM, Vladimir Dronnikov dronni...@gmail.com wrote: Consider a site of incidents (i.e., situations you're responding to or have responded to) containing entries (reports of specific things you've done, photos, etc). Deleting an entry should not affect the incident. But deleting the incident should delete all entries because they refer to an incident which doesn't exist, one which you've specifically said you don't care about. Again, deleting an incident has no sense (in applied world) since the incident _has_ _physically_ occured! In your example the incident with all related stuff should be marked 'archived' and thus go out of scope. Well, the only case where deletions occur is when the incident should not have been there in the first place or is a duplicate of another record. -- Mike Orr sluggos...@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-disc...@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: two routes / dispatch questions
On Sat, Jan 30, 2010 at 2:11 PM, Jonathan Vanasco jonat...@findmeon.com wrote: On Jan 30, 2:06 am, Mike Orr sluggos...@gmail.com wrote: I consider such slash manipulation to be highly unorthodox and undesirable, but that's how you can do it if you want to. Thanks Mike! I find the slash manipulation to be standard. The default behavior for static webservers has been: filesystem: /folder/index.html urls: /folder/index.html /folder/ /folder ( redirects to /folder/ ) By slash manipulation I meant capturing the slash in a variable and stripping it out in a route function. What you have here is the tradition of a static server, where /folder/ is shorthand for /folder/index.html, and /folder redirects to it so that any relative links in the document will work. You can do this with Pylons, but it seems more common to treat trailing / like .html -- unnecessary cruft from the world of static servers. The corollary is that Pylons pages normally don't have relative URLs -- they generally have root URLs generated by url(). If you want to use relative URLs, you may have to go with the trailing slash syntax. One reason the trailing slash isn't common is that it can be hard to tell what's a directory in a dynamic application. The page may be perfectly fine as a standalone page (file-like), but also have an optional something below it. For instance, /about and /about/subpage1. And a naive user is going to type the URL without the trailing slash anyway because he may not know there's something below it. And maybe a later version of the site will change its mind about whether the URL is a file (with no children) or a directory (with children). The main thing to avoid is serving the same content for /folder and /folder/ without a redirect, because that means there's two URLs for the same item. So proxies will cache both URLs separately, and different users may bookmark one or the other, and if you ever reorganize your URL scheme you'll have to put redirects for both. -- Mike Orr sluggos...@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-disc...@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.
