On Sun, Jul 1, 2012 at 11:14 PM, Massimo Di Pierro
massimo.dipie...@gmail.com 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
On Mon, Jul 2, 2012 at 1:03 AM, Anthony abasta...@gmail.com 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
On Mon, Jul 2, 2012 at 11:03 AM, Anthony abasta...@gmail.com 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
On Sat, Jun 30, 2012 at 11:11 AM, Anthony abasta...@gmail.com 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
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 thing
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
():
if request.args(0) == 'register':
form = auth.register(next=auth.settings.register_next)
else:
form = auth()
return dict(form=form)
Anthony
On Saturday, June 30, 2012 2:37:36 AM UTC-4, Doug Philips wrote:
I've been customizing how registration works for my app
On Thu, Jun 28, 2012 at 8:04 AM, Anthony abasta...@gmail.com 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
On Thu, Jun 28, 2012 at 1:02 AM, Jonathan Lundell jlund...@pobox.com 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
On Sat, Jun 23, 2012 at 1:54 PM, Anthony abasta...@gmail.com 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
On Sat, Jun 23, 2012 at 1:24 PM, Anthony abasta...@gmail.com 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
On Wed, Jun 27, 2012 at 10:13 AM, Anthony abasta...@gmail.com 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
On Wed, Jun 20, 2012 at 7:04 PM, Niphlod niph...@gmail.com 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
On Wed, Jun 20, 2012 at 9:06 PM, Anthony abasta...@gmail.com 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
On Tue, Jun 19, 2012 at 1:33 PM, Anthony abasta...@gmail.com 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
On Tue, Jun 19, 2012 at 3:31 PM, Niphlod niph...@gmail.com 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
On Wed, Jun 20, 2012 at 5:53 PM, Anthony abasta...@gmail.com 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
On Mon, Jun 18, 2012 at 2:07 AM, Anthony abasta...@gmail.com 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
On Mon, Jun 18, 2012 at 4:02 AM, Niphlod niph...@gmail.com 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
On Sat, Jun 16, 2012 at 5:56 PM, Niphlod niph...@gmail.com 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
On Fri, Jun 15, 2012 at 6:10 PM, Anthony abasta...@gmail.com 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
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 niph...@gmail.com 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
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
On Tue, Jun 12, 2012 at 4:49 AM, Alec Taylor alec.tayl...@gmail.com 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
On Tue, Jun 12, 2012 at 9:17 AM, Massimo Di Pierro
massimo.dipie...@gmail.com 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 abasta...@gmail.com 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.
On Sat, Jun 9, 2012 at 11:50 PM, pbreit pbreitenb...@gmail.com 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:
On Sun, Jun 10, 2012 at 10:38 AM, Anthony abasta...@gmail.com 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
On Sun, Jun 10, 2012 at 11:20 AM, Anthony abasta...@gmail.com 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
On Sun, Jun 10, 2012 at 2:26 PM, Anthony abasta...@gmail.com 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
On Sat, Jun 9, 2012 at 12:01 AM, pbreit pbreitenb...@gmail.com 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
On Fri, Jun 8, 2012 at 8:12 PM, pbreit pbreitenb...@gmail.com 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
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
On 6/7/12, Richard Vézina ml.richard.vez...@gmail.com 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
On Thu, Jun 7, 2012 at 2:12 PM, Anthony abasta...@gmail.com 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:
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
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
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 abasta...@gmail.com 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
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 douglas.phil...@gmail.com wrote:
Hello all, again,
(I'm guessing the answer to this is in 'the book' , but that's down
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,
43 matches
Mail list logo
