RE: Pylon with Apache

2007-04-27 Thread Orr, Steve

RE 
 5. mod_python works, but it's nicer to use Apache (listening on port
 80) to proxy to another Web server running your Pylons app.  

Okay, can please elaborate on the meaning of that highly technical term 
nicer? :-) What are the advantages/disadvantages pros/cons to doing a proxy 
instead of just using mod_python? 

AtDhVaAnNkCsE !!



-Original Message-
From: pylons-discuss@googlegroups.com [mailto:[EMAIL PROTECTED] On Behalf Of 
Shannon -jj Behrens
Sent: Tuesday, April 17, 2007 6:58 PM
To: pylons-discuss@googlegroups.com
Subject: Re: Pylon with Apache


On 4/17/07, durumdara [EMAIL PROTECTED] wrote:

 Hi!

 Jose Galvez írta:
  as fare as odbc is concerned, pylons or any other web framework really
  has nothing to do with it, thats up to python and DB2 support.  If your
  on the windows platform ODBC can be done with the win32all package and
  there is also the mxODBC package.  On linux I'm not sure.  As for
  Apache, I use pylons with apache all the time and use the mod_proxy to
  get the urls to work
  Jose
 

 Hmmm...
 As I read the Pylons and Django is supports the ActiveRecord
 (TurboGears' foo), and some of the predefined views are based on this
 idea (SQLObject, SQLAlchemy).

 Or these special functions are based on Python's DB2?

 I'm not sure because I'm lama in this makewebframework theme... :-(

 I read these things here:
 http://jesusphreak.infogami.com/blog/vrp1

Unless I myself am confused, it seems like this conversation is a bit
confused.  Let me try to clear things up:

1. You can use any DBAPI adaptor with Pylons in order to talk to a
database without using an ORM.  I've used one before on Linux to talk
to SQLServer.

2. Some ORMs may not support ODBC.  I do know that SQLAlchemy works
with both SQLServer and Oracle, though.

3. Pylons does work under mod_python.

4. To deal with the reload problem, *in development* I like to set
Apache's MaxRequestsPerChild to 1.

5. mod_python works, but it's nicer to use Apache (listening on port
80) to proxy to another Web server running your Pylons app.  I do this
in production.  Each of my apps has its own server (from Paste), but
they're all proxied behind Apache.

Best Regards,
-jj

-- 
'Software Engineering' is something of an oxymoron.  It's very
difficult to have real engineering before you have physics, and there
isn't anything even close to a physics for software. -- L. Peter
Deutsch




--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Preview of New Admin App

2007-04-27 Thread Gregory W. Bond



On Apr 27, 12:38 pm, __wyatt [EMAIL PROTECTED] wrote:
 I've been working on a new admin app that I'm calling Restin (for
 RESTful admin). It's pretty basic right now and has some issues that
 need working out, but it does provide some useful functionality
 already.

 ...snip

this souds great - is this intended to be the Pylons answer to
Django's admin interface generator? i hope so - i almost chose Django
over Pylons based on this capability (but Pylons' support for Routes,
Ajax, SqlAlchemy, Elixir convinced me to choose Pylons)


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: RESTful Pylons

2007-04-27 Thread __wyatt

(and now I see that Ben already replied)

On Apr 27, 1:13 pm, __wyatt [EMAIL PROTECTED] wrote:
 On Apr 27, 11:48 am, Gregory W. Bond [EMAIL PROTECTED] wrote:



  i'm trying to implement a RESTful Pylons controller and i can't figure
  out how to support client-side DELETE and PUT requests - the only
  suggestions i can find in the context of Pylons are

 http://pylonshq.com/pasties/12

  and

 http://groups.google.com/group/pylons-discuss/browse_frm/thread/3463c...

  (both from Ben)

  here's an example of this approach for a client side DELETE request

  # Forms posted to this method should contain a hidden field:
  #input type=hidden name=_method value=DELETE /
  # Or using helpers:
  #h.form(h.url_for('${singularname}', id=ID), method='delete')

  the aforementioned approach doesn't actually use DELETE and PUT
  requests - instead it uses hidden form fields - why? is there no
  support for DELETE/PUT in the Pylons webhelpers?

 It's not about the webhelpers, it's about browser support. They don't
 all know about DELETE and PUT, so POST is used with the hidden field
 for compatibility.



  secondly, it looks like the RESTful extensions to Routes (http://
  routes.groovie.org/manual.html#restful-services) can't be used with
  this approach since they are expect true http PUT/DELETE requests so
  what should the Routes config look like for this approach?

 map.resource does work with the hidden form field approach.

 Instead of implementing your own RESTful controller, you might want to
 check this out:

 http://code.google.com/p/restler/

 Even if you don't use it, it might be a useful reference. There's an
 example app that shows how to use it (MyProject). It also includes
 templates that use the hidden field approach.

 __wyatt


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Preview of New Admin App

2007-04-27 Thread __wyatt

On Apr 27, 12:08 pm, Gregory W. Bond [EMAIL PROTECTED] wrote:
 On Apr 27, 12:38 pm, __wyatt [EMAIL PROTECTED] wrote:

  I've been working on a new admin app that I'm calling Restin (for
  RESTful admin). It's pretty basic right now and has some issues that
  need working out, but it does provide some useful functionality
  already.

  ...snip

 this souds great - is this intended to be the Pylons answer to
 Django's admin interface generator? i hope so - i almost chose Django
 over Pylons based on this capability (but Pylons' support for Routes,
 Ajax, SqlAlchemy, Elixir convinced me to choose Pylons)

It's supposed to be *an* answer; I don't know if it will end up being
*the* answer, but I wouldn't mind if it does. ;-)

__wyatt


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



RE: Pylon with Apache

2007-04-27 Thread Cliff Wells

On Fri, 2007-04-27 at 07:36 -0600, Orr, Steve wrote:

 What are the advantages/disadvantages pros/cons to doing a proxy instead of 
 just using mod_python? 

Typically, proxying is:

1. easier to setup than mod_python
2. easier to upgrade Python (no mod_python/python version issues)
3. doesn't require restarting Apache as often 
4. just as fast
5. frees you from having to use Apache at all (other proxy solutions are
available that are usually faster and lighter than Apache)

Regards,
Cliff


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: AJAX how to replace DOM object's value from controller

2007-04-27 Thread Shannon -jj Behrens

On 4/27/07, Dan [EMAIL PROTECTED] wrote:
 Would someone give an example how I could replace a DOM object from the
 controller?

 For example, I have an onChange for a select that calls a function
 within the controller.  The controller function is receiving the
 this[this.selectedIndex].value (an integer).  I can pass the int value
 from the select onChange into the controller, storing it as c.value.
 I want the controller to take c.value and update the 'value' of a text
 field on the same page without a refresh.

 All I can figure out is how to replace an entire element, such as, a
 div or the entire input by return render_response('some_template')

This sounds more like a JavaScript library question.  It depends on a)
which JavaScript library you're using b) how you're doing your AJAX.
I'm going to take a guess that you're using Prototype with the Rails
Helpers.  If that's the case, I don't know, sorry ;)

Hmm, maybe this wasn't such a helpful response after all!

Good Luck!
-jj

-- 
http://jjinux.blogspot.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-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Session store

2007-04-27 Thread Shannon -jj Behrens

On 4/24/07, Damjan [EMAIL PROTECTED] wrote:

 You can store sessions (or the needed info) in just cookies, a
 database (MySQL, Postgresql, etc) or memcached. It's not neccesseary
 to store the session in files.

Agreed.  memcached is very popular for scalable session servers, not
just in the Pylons world.  Cookies are a good option if you can keep
the sessions really small.  You may want to sign and/or encrypt them
to prevent tampering.  At my company, we're trying our hardest to
simply not use sessions in order to avoid the problem.  An ugly
solution is to have your load balancer implement session stickiness
so that you can use Pylons normal session mechanism.  However, that's
ugly because you can't just pull servers out of production anytime you
want.

This topic is covered very nicely in Building Scalable Web Sites and
Scalable Internet Architectures.

Happy Hacking!
-jj

-- 
http://jjinux.blogspot.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-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Pylons docs [was: Hold my hand, please]

2007-04-27 Thread Shannon -jj Behrens

On 4/22/07, Graham Higgins [EMAIL PROTECTED] wrote:

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1


 On 20 Apr 2007, at 02:28, Heather wrote:

  So, any takers?

 Okay, I'll give it a shot. See http://bel-epa.com/wiki/
 AnOverviewOfPylons

 Dunno about acting as groundwork but if it helps you put a couple of
 the pieces into place, that's good enough.

 Do let me know if any of it appears especially inarticulate or
 confusing.

It looks nice, but I fear so many people have written overviews of
Pylons that I'm completely losing track.  I have copies of Concepts
of Pylons and Pylons Quick Site on my desktop.  I have a bookmark
for all of Mike's stuff.  There's the old wiki and the new wiki, not
to mention the actual Pylons Web site.

I know programmers love to complain about lack of documentation.
However, in some cases, I don't think it has to do with lack of volume
as much as lack of organization.  There's *tons* of good documentation
for Pylons.  It's just hard to know how to approach it all.  I wonder
how it might be possible to unify all this documentation and make sure
it stays both up to date and easy to find.

Of course, the instant reaction to unifying documentation is to write
more documentation, which just compounds the issue ;) We need to
unify, *delete*, and make a plan for maintaining it.

Ok, sorry for the rant :-/

-jj

-- 
http://jjinux.blogspot.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-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: RESTful Pylons

2007-04-27 Thread Gregory W. Bond

i just gave this a try and it sort of worked as expected - let me
explain:

for my example i tried to emulate a DELETE using

h.button_to(Delete, h.url_for(id=num.number), method=delete)

which translated to

form method=POST action=/users/john/numbers?id=681212
class=button-todivinput id=_method name=_method
type=hidden value=delete /input type=submit value=Delete //
div/form

all as expected so far

now pressing the Delete button generates a POST request of the form:

http://localhost:5000/users/john/numbers?id=681212

my DELETE routing rule matches (!):

map.connect('users/:user/numbers', controller='users/numbers/numbers',
action='delete', conditions=dict(method=['DELETE']))

however, note that the 'id' is provided as a request parameter, not as
part of the request URL - for this reason i can't use the conventional
RESTful routing rule for DELETE which would be:

map.connect('users/:user/numbers/:number', controller='users/numbers/
numbers', action='delete', conditions=dict(method=['DELETE']))

so the 'delete' function of my controller has to extract the 'id' to
delete from the request params, it's not provided as a function
argument

am i doing things correctly here or am i missing something?



On Apr 27, 4:11 pm, Gregory W. Bond [EMAIL PROTECTED] wrote:
 thanks for the prompt reply ben - i suspected that browsers might not
 support PUT/DELETE and that made me sad since i could envision the big
 mess that my routes would have to be to accommodate browsers along
 with web-services clients that do support PUT/DELETE

 but if what you're saying really works (and i imagine it will ;-) )
 i'll be super-impressed with pylons/routes for it's ability to hide
 this complexity for me


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: RESTful Pylons

2007-04-27 Thread Shannon -jj Behrens

On 4/27/07, Gregory W. Bond [EMAIL PROTECTED] wrote:

 i just gave this a try and it sort of worked as expected - let me
 explain:

 for my example i tried to emulate a DELETE using

 h.button_to(Delete, h.url_for(id=num.number), method=delete)

 which translated to

 form method=POST action=/users/john/numbers?id=681212
 class=button-todivinput id=_method name=_method
 type=hidden value=delete /input type=submit value=Delete //
 div/form

 all as expected so far

 now pressing the Delete button generates a POST request of the form:

 http://localhost:5000/users/john/numbers?id=681212

 my DELETE routing rule matches (!):

 map.connect('users/:user/numbers', controller='users/numbers/numbers',
 action='delete', conditions=dict(method=['DELETE']))

 however, note that the 'id' is provided as a request parameter, not as
 part of the request URL - for this reason i can't use the conventional
 RESTful routing rule for DELETE which would be:

 map.connect('users/:user/numbers/:number', controller='users/numbers/
 numbers', action='delete', conditions=dict(method=['DELETE']))

 so the 'delete' function of my controller has to extract the 'id' to
 delete from the request params, it's not provided as a function
 argument

 am i doing things correctly here or am i missing something?



 On Apr 27, 4:11 pm, Gregory W. Bond [EMAIL PROTECTED] wrote:
  thanks for the prompt reply ben - i suspected that browsers might not
  support PUT/DELETE and that made me sad since i could envision the big
  mess that my routes would have to be to accommodate browsers along
  with web-services clients that do support PUT/DELETE
 
  but if what you're saying really works (and i imagine it will ;-) )
  i'll be super-impressed with pylons/routes for it's ability to hide
  this complexity for me

I don't know anything about this REST stuff, but I do note that you called:

h.url_for(id=num.number)  # id

but setup the map:

map.connect('users/:user/numbers/:number', controller='users/numbers/
  numbers', action='delete',
conditions=dict(method=['DELETE']))

You used :number instead of :id.

I would guess that that is the problem.

Happy Hacking!
-jj

-- 
http://jjinux.blogspot.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-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: RESTful Pylons

2007-04-27 Thread Gregory W. Bond

i looked at restler but unfortunately it doesn't meet my requirements
(namely, nested resources, as shown in one of my posts in this thread)
- i also took a look at the restler source but i couldn't figure out
how you were handling DELETE/PUT in your templates (i'm still new to
this pylons thing :-) )

On Apr 27, 4:13 pm, __wyatt [EMAIL PROTECTED] wrote:
 On Apr 27, 11:48 am, Gregory W. Bond [EMAIL PROTECTED] wrote:



  i'm trying to implement a RESTful Pylons controller and i can't figure
  out how to support client-side DELETE and PUT requests - the only
  suggestions i can find in the context of Pylons are

 http://pylonshq.com/pasties/12

  and

 http://groups.google.com/group/pylons-discuss/browse_frm/thread/3463c...

  (both from Ben)

  here's an example of this approach for a client side DELETE request

  # Forms posted to this method should contain a hidden field:
  #input type=hidden name=_method value=DELETE /
  # Or using helpers:
  #h.form(h.url_for('${singularname}', id=ID), method='delete')

  the aforementioned approach doesn't actually use DELETE and PUT
  requests - instead it uses hidden form fields - why? is there no
  support for DELETE/PUT in the Pylons webhelpers?

 It's not about the webhelpers, it's about browser support. They don't
 all know about DELETE and PUT, so POST is used with the hidden field
 for compatibility.



  secondly, it looks like the RESTful extensions to Routes (http://
  routes.groovie.org/manual.html#restful-services) can't be used with
  this approach since they are expect true http PUT/DELETE requests so
  what should the Routes config look like for this approach?

 map.resource does work with the hidden form field approach.

 Instead of implementing your own RESTful controller, you might want to
 check this out:

 http://code.google.com/p/restler/

 Even if you don't use it, it might be a useful reference. There's an
 example app that shows how to use it (MyProject). It also includes
 templates that use the hidden field approach.

 __wyatt


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Pylons Evaluation -Questions

2007-04-27 Thread voltron

Thanks for the heads up


On Apr 28, 1:50 am, Shannon -jj Behrens [EMAIL PROTECTED] wrote:
 On 4/27/07, voltron [EMAIL PROTECTED] wrote:

  Hi all!

  I shopping around for a Python based web framework for a potentially
  large site, I have narrowed my choice to Django and Pylons. I have a
  few questions to ask about Pylons if I may.

 Pylons is better at:
 * Being a hacker's framework.
 * Mixing and matching your components.
 * Not getting in your way.
 * Developing custom *applications*.

 Django is better at:
 * Being accessible by newbies.
 * Letting developers quickly throw together something and start
 inserting content.
 * Developing custom *web sites*.

  How are Pylon projects structured? Does a Pylon project map directly
  to a complete Web application and the modules that make up the
  application the controllers?

 Pretty much.  Take a look at the QuickWiki tutorial.  That's enough to
 know what's going on.

  What is the favored, most stable Web server/ Pylon configuration?

 Many of us prefer using Paster (the Web server in Paste), proxied behind 
 Apache.

  How does Pylons scale? Do I throw more hardware at it or just add more
  servers and a load balancer?

 It's the same as everything else.  You can add more Web servers.  If
 you use sessions, you'll need to either a) use session stickiness
 (ugly) or b) use a session server (less ugly).  Pylons doesn't have
 any inherent scaling problems.  I can say this with conviction because
 I just finished reading Scalable Internet Architectures and
 Building Scalable Web Sites :)

  Is there a way to short-circuit all requests to pylons and carry out
  certain actions based on this? For example, I intend to log page
  impressions based on different types of requests

 Yes.  You have two ways 1) by using middleware 2) by using a
 controller superclass.

 Best Regards,
 -jj

 --http://jjinux.blogspot.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-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---



Re: Session store

2007-04-27 Thread Cliff Wells

On Fri, 2007-04-27 at 17:24 -0700, Shannon -jj Behrens wrote:

 This topic is covered very nicely in Building Scalable Web Sites and
 Scalable Internet Architectures.

Okay, one more plug for these books and there's going to be a demand for
full disclosure ;-)

Cliff


--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups 
pylons-discuss group.
To post to this group, send email to pylons-discuss@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en
-~--~~~~--~~--~--~---