BTW: Take a look at the Style Guide for Python Code (PEP-8) for lots
of really helpful tips.
The empty collections (of which list is one) can be found under
Programming Recommendations of PEP-8:
http://www.python.org/dev/peps/pep-0008/#programming-recommendations
--Doug
On Wed, May 30, 20
I'm getting ready to deploy my first web2py application.
First off: THANK YOU!
I couldn't have pulled this off (I'm a systems programmer, not a web
programmer).
While I have only one application to deploy, I am hoping there are others.
As such, I want to use welcome as the 'landing page' which wil
Ok, I've entered an issue for it:
http://code.google.com/p/web2py/issues/detail?id=841
Thanks!
---Doug
On Wed, Jun 6, 2012 at 9:49 AM, Anthony wrote:
> Good catch -- we should make that change. In your case, you can just remove
> that line.
Hello all, again,
(I'm guessing the answer to this is in 'the book' , but that's down
right now and when I went looking last night I couldn't seem to figure
out where.)
For the app I'm deploying which does require users to authenticate
(login), I want to use the verification facility.
I have the
, but more importantly it means not
having to keep the code in synch between the gluon code and the admin
application. Not a big deal though.
On Wed, Jun 6, 2012 at 11:28 AM, Doug Philips wrote:
> Hello all, again,
>
> (I'm guessing the answer to this is in 'the book' , but
I know that SQLFORM.grid is marked experimental and thus I shouldn't
expect it to be as refined as some of the other parts of web2py, but
I'm hoping that also means it is still a bit open to adjustment?
SQLFORM.grid has saved me a ton of work, but there are few things I
wish it did slightly better
On 6/7/12, Richard Vézina wrote:
> I am almost sure I saw a email were Massimo explain how to set a different
> text for "submit" button, can't find it back...
>
> Have you try with SQLFORM attribute ? Or SQLFORM attribute with "_" before
> : _submit_button = 'Submit'
Well, I looked at the code i
On Thu, Jun 7, 2012 at 2:12 PM, Anthony wrote:
> I'm not sure if this is in stable, but in trunk you can specify dictionaries
> of args to pass to SQLFORM, including separate dictionaries for create,
> edit, and view
> forms: http://code.google.com/p/web2py/source/browse/gluon/sqlhtml.py#1500.
I'
I can only find one mention of symbolic links in the book, under:
http://web2py.com/books/default/chapter/29/4#Application-init
That seems to imply that symbolic links at the applications directory
level are ok.
Specifically, if I have the following applications:
ProjectX2010
ProjectX2
On Fri, Jun 8, 2012 at 8:12 PM, pbreit wrote:
> You can certainly symlink to an application. Having two applications access
> the same database is a different story. In theory it should work fine (but I
> would never do it).
Thanks. I guess I don't understand how web2py can tell the difference.
W
On Sat, Jun 9, 2012 at 12:01 AM, pbreit wrote:
> Hard to say how URL rewriting would affect all this. Maybe I don't
> understand what you are doing or trying to do.
Isn't a matter of effecting this, it is a matter of presenting one
application under several names, which, I thought, URL rewriting
On Sat, Jun 9, 2012 at 11:50 PM, pbreit wrote:
> Hmmm...I still don't totally understand what you are trying to do and what
> your setup looks like.
I have a series of applications:
ProjectX2012, ProjectX2011, ProjectX2010, etc
I want to provide a short-cut URL:
ProjectX
that resolve
On Sun, Jun 10, 2012 at 10:38 AM, Anthony wrote:
> Reloading routes does not restart the server -- it just re-reads the routes
> file.
OK... just checked the code for the stable release... but, unless the
docs say so, I can't really rely on that behaviour not changing...
>> Both of those option
On Sun, Jun 10, 2012 at 11:20 AM, Anthony wrote:
> Aside from the built-in Rocket server (which is primarily intended for
> development), web2py doesn't have any control over the server so can't
> generally restart your server -- so you should be able to rely on the fact
> that reloading routes wi
On Sun, Jun 10, 2012 at 2:26 PM, Anthony wrote:
>> But I think if you have users in mid-session and you switch apps on them,
>> it could present problems no matter how you try to solve it.
>
> That's true. Although using routes is probably the safer method (should be
> no problems within a single
On Tue, Jun 12, 2012 at 4:49 AM, Alec Taylor wrote:
> o.O - Just found this: "web2py Application Development Cookbook" -
> http://www.packtpub.com/web2py-application-development-recipes-to-master-python-web-framework-cookbook/book
>
> Looks quite useful, I think I will get that instead :)
>
> [I w
On Tue, Jun 12, 2012 at 9:17 AM, Massimo Di Pierro
wrote:
> The official web2py book is now free for everybody:
>
> https://dl.dropbox.com/u/18065445/web2py/web2py_manual_4th.1.pdf
Thank you!
-=Doug
isup.me says its not just a few of us. :-(
On Tue, Jun 12, 2012 at 3:57 PM, Anthony wrote:
> Same here.
>
>
> On Tuesday, June 12, 2012 3:49:40 PM UTC-4, pbreit wrote:
>>
>> The Book is down for me since 12:45 PT.
Hey all,
I'm looking at deploying a web2py app in an environment where any
client side scripting is forbidden. Is web2py usable in that case?
There seems to be a lot of scripting going on in the default
layout.html. As a systems programmer with no web experience, I have no
idea what will stop wor
On Fri, Jun 15, 2012 at 6:10 PM, Anthony wrote:
> Note, web2py will have the same limitations as any framework in this case.
Right. I just didn't know how much of the Web2py forms "magic"
depended-on/required client-side scripting.
> Most things should work fine, except of course anything Ajax
I'm looking to potentially use background task(s) to offload sending
of emails and updating of other offline resources, and I'm trying to
sort out what the implications are.
In the PDF of the book (just released for free, thank you!), page 389,
section 8.5 "Sending messages using a background task
On Sat, Jun 16, 2012 at 2:38 PM, Niphlod wrote:
> if you're familiar with database transactions, web2py istantiate a new
> transaction every request and commit (if no exceptions are thrown
> automatically) at the end of the request.
Yup, that part makes sense. And I assume it is true regardless o
On Sat, Jun 16, 2012 at 5:56 PM, Niphlod wrote:
> The bit of magic that I forgot to tell explicitely is that db.commit()
> commits every opened transaction and starts a new one :D
Ok, just to double check, that is for all DB back-ends or just for SQLite?
> Note, if your site does mostly reading
On Mon, Jun 18, 2012 at 2:07 AM, Anthony wrote:
> I don't think web2py is doing any magic -- I think it just relies on the
> standard database and database driver behavior.
"There in lies the rub" - the problem is that The Book isn't really
very easy to use to find out just what the DAL does for
On Mon, Jun 18, 2012 at 4:02 AM, Niphlod wrote:
>> Ok, just to double check, that is for all DB back-ends or just for SQLite?
>>
> This is true for every backend.
Thanks!
> Web2py is not blocked, and again, it's only with SQLite that there is the
> problem. From the first update on the queue to
On Tue, Jun 19, 2012 at 1:33 PM, Anthony wrote:
> I'm not sure it's feasible or desirable for the DAL to try to normalize
> every last behavior across all database backends. What exactly would you
> have the DAL do differently in this case?
Actually what I'm looking for is in the documentation, n
On Tue, Jun 19, 2012 at 3:31 PM, Niphlod wrote:
> Yep, I don't know exactly the defaults, but I happen to see some major
> differences against various systems with standard python distribution.
Ugh, at least, for the most part, it still all 'just works'. :-/
> Moreover, it's just for this kind
On Wed, Jun 20, 2012 at 5:53 PM, Anthony wrote:
> Can you explain how whether SQLite autocommits or not matters in this case?
> The DAL documentation recommends doing a db.commit() in scripts and
> background tasks like this precisely because it doesn't want to assume any
> autocommitting is happe
On Wed, Jun 20, 2012 at 7:04 PM, Niphlod wrote:
> You're forgetting another "layer". DAL leverages on DBAPI implementation of
> sql drivers.
Well, that's not exactly good news for transparency and ease of documentation.
> A little more complicated: get on an infinite loop inserting 10 rows,
> w
On Wed, Jun 20, 2012 at 9:06 PM, Anthony wrote:
>> Sooo Have I misunderstood the SQLite locking description?
>
>
> I believe so. The shared lock does not last forever -- only as long as it
> takes to execute the select. Once the data have been read, the shared lock
> (for that particular selec
On Sat, Jun 23, 2012 at 1:54 PM, Anthony wrote:
>> > You're forgetting another "layer". DAL leverages on DBAPI
>> > implementation of sql drivers.
>>
>> Well, that's not exactly good news for transparency and ease of
>> documentation.
>
> DB API is just a specification for Python database drivers
On Sat, Jun 23, 2012 at 1:24 PM, Anthony wrote:
> No, when autocommit is disabled, that doesn't immediately result in a shared
> lock being acquired and held indefinitely. A shared lock is acquired when a
> select is made, but only held as long as it takes to actually do the reading
> for that sel
On Wed, Jun 27, 2012 at 10:13 AM, Anthony wrote:
>> Again, with autocommit off:
>> The server process does a query/select to see if there is any work to
>> do. This provokes SQLite to acquire a SHARED lock. Then the server
>> process decides "oops, no work to do, let's go to sleep for a minute".
>
On Wed, Jun 27, 2012 at 11:53 AM, Anthony wrote:
>> > Yes, it does release the lock, as soon as the select is complete. You do
>> > not
>> > have to do db.commit() after a select.
>> Please show me where that is documented.
>> Section 7 of http://www.sqlite.org/lockingv3.html says that ONLY
>> hap
On Thu, Jun 28, 2012 at 12:08 AM, Anthony wrote:
> SQLite is a file-based database, so has to have more course locking than a
> typical client/server database. Other databases have "select for update"
> functionality, which allows you to select a set of records and lock them.
> web2py actually sup
On Thu, Jun 28, 2012 at 1:02 AM, Jonathan Lundell wrote:
> The SQLite adapter simulates select for update by wrapping the select+update
> in a transaction. Not too efficient, since it has to lock the entire
> database, but it'll do it.
Thanks, I wish it worked in the released version, and I'm hop
On Thu, Jun 28, 2012 at 8:04 AM, Anthony wrote:
>> > Anyway, you might be better off looking into using the scheduler, or a
>> > third-party task queue like Celery (a web2py Celery plugin was started
>> > at
>> > some point, though not sure it is complete).
>>
>> I don't understand, how will that
I've been customizing how registration works for my app as a few of my
app's users are getting confused by the registration verification
email.
Ok, so I will just have my app send them to a nice hand-holding
explanatory page after they've submitted their registration
information.
According to The
On Sat, Jun 30, 2012 at 2:37 AM, I wrote:
> and that _next seems to override anything I set in my model for
> auth.settings.registration_next.
Typo, I should have written:
and that _next parameter seems to override anything I set in my model
for auth.settings.register_next
-=D
u can remove _next from request.vars:
>>
>> request.vars._next = None
>> auth = Auth(...)
>>
>> You can also pass a "next" argument directly to the auth.register()
>> function (and other Auth functions):
>>
>> def user():
>> if request
On Sat, Jun 30, 2012 at 11:11 AM, Anthony wrote:
> I don't think it's a bug, per se, but the behavior (and documentation) could
> be improved.
??? The documentation is quite direct and clear that you can set
auth.settings.register_next to control where the user goes next. It
doesn't work. It's no
>From my 'search engine' results, it looks as if the last this was
discussed was back in Sept of last year.
Including a very intriguing comment from Massimo on Sept 9, 2011:
> This is really nice. I can see this integrated with markmin in a
> simple web app that we can all use... I need such a thin
On Sun, Jul 1, 2012 at 11:14 PM, Massimo Di Pierro
wrote:
> In the end I preferred reveal.js to deck.js
>
> This integrates reveal.js with markmin.
> https://github.com/mdipierro/markmin-reveal-slides
...
> Hope this is useful. It would be nice to make a web app for it where the
> source is stored
On Mon, Jul 2, 2012 at 1:03 AM, Anthony wrote:
> Here's what the book says:
> These must point to the URL you want to redirect your users to after the
> various possible auth actions (in case there is no referrer):
>
> Notice the highlighted text. The _next URLs are default redirect URLs when
> th
On Mon, Jul 2, 2012 at 11:03 AM, Anthony wrote:
> Seems to me this has precisely the same meaning (though in a different
> context). In the context of Auth, register_next is the URL after you
> register, and in the context of Crud, create_next is the URL after
> submission of a create form. What's
45 matches
Mail list logo
