[web2py] More WebSocket inquiries
I see the websocket/comet discussion from December and the script in contrib. I was wondering if any further effort has gone into enabling this across more browsers using some of the available technologies which can be leveraged for that purpose. Unless the acceptance is broader than just the 10% of us who use Chrome, a technology like that is unlikely to reach the mainstream. While my knowledge on the client-side is better than the server-side for these technologies, I'd like to not just leverage the work once for myself if it can be avoided on further work integrating with client-side libraries (like socket.io or others) . --Greg
[web2py] Re: More WebSocket inquiries
On Mar 16, 4:06 pm, rochacbruno wrote: > There is a workaround using flash to enable cross browser support. Are any of those included presently? And, if so, which ones are compatible with the included tornado client? socket.io seems to claim it needs a special backend, but I would imagine there are different distinctions. I was just wondering if anyone knows which clients we can use if we want to operate on IE and FF as well. --Greg > > Enviado via iPhone > > Em 16/03/2011, às 17:43, Gregory Hellings escreveu: > > > > > > > > > I see the websocket/comet discussion from December and the script in > > contrib. I was wondering if any further effort has gone into enabling > > this across more browsers using some of the available technologies > > which can be leveraged for that purpose. Unless the acceptance is > > broader than just the 10% of us who use Chrome, a technology like that > > is unlikely to reach the mainstream. > > > While my knowledge on the client-side is better than the server-side > > for these technologies, I'd like to not just leverage the work once > > for myself if it can be avoided on further work integrating with > > client-side libraries (like socket.io or others) . > > > --Greg
[web2py] Re: web2py applications and version control systems
I was just getting ready to dump my newest project into VCS and was wondering the same question. For me, since I'm not anywhere near production yet, I am opting for just putting the application into VCS, then I can use web2py's autoupdate feature. Again, I'm only using this as a playground for putting ideas into code which might be used later on down the line. So the version of web2py upgrading and breaking things is not a concern for me. If you're dealing with a real, life application for a client and you're concerned about the extra files for GAE, I would start my VCS at the base of web2py and only add my application and those files I absolutely needed. The rest could be hg/bzr/git/svn ignore'd. Then you can update just those files and track them, without being bothered by changes to web2py. Again, since I'm only dealing with a sandbox for my own amusement and learning at this time, I'm not really concerned about tracking web2py's updates and matching it for compatibility nor the ability to rollback. --Greg On Mar 17, 1:13 pm, Dave Warnock wrote: > Hi, > > Do people generally start version control at web2py/applications/myapp or at > web2py? > > If an application is to be deployed on gae then shouldn't some files in > web2py be considered part of the project (index.yaml, app.yaml) and > therefore under version control? > > Yet I would prefer not to have the whole of web2py under version control so > that I can more quickly move between web2py versions for testing & > upgrading. > > Just wondering what you do? > > Dave > > -- > Dave Warnock:http://42.blogs.warnock.me.uk
[web2py] DAL format= functionality
I have defined a custom auth.settings.table_user_name implementation
that includes one extra field and specifies a value for the format
argument. In this case format is a callback function which displays
the user's name with extra formatting based on membership in certain
auth groups. This option works wonderfully with SQLFORM fields and
with appadmin displays of the auth_membership table, but I seem to be
missing something about its functionality elsewhere.
(This is in the context of a demo chat application utilizing the
web2py_comet functionality). I have another table which is defined
like this:
db.define_table('chat',
Field('speaker', db.auth_user, default=auth.user_id,
writable=False, readable=False),
Field('statement', 'text', requires=IS_NOT_EMPTY()),
Field('deleted', db.auth_user, writable=False, readable=False))
db.chat.speaker.requires = IS_IN_DB(db, db.auth_user.id)
db.chat.deleted.requires = IS_IN_DB(db, db,auth_user.id)
My controller for displaying the lines uses this logic
rawlines=db(db.chat.deleted==None).select(limitby=(0,10),orderby=~db.chat.id)
lines=[]
for line in rawlines:
lines.append(DIV(line.speaker, B("> "), line.statement,
_id=line.id))
However, when I do that, I get the user's ID instead of the user's
name as formatted by my format callback method. Thus the chat output
looks like
1> Hi there
1> How is everyone doing?
2> We're great, how about you?
1> Oh, I'm absolutely fantastic.
In order to get the properly formatted user's name, I have to
explicitly call my format method, making the last line of the above
controller instead read
lines.append(DIV(name_format(line.speaker), B("> "),
line.statement, _id=line.id))
This defeats most of the purpose I had in using the automatic
format=name_format argument to the define_table call. Am I missing
something here? What am I doing incorrectly? As I scale out of my
demo chatroom, I want to make sure user names are consistently
displayed throughout my application by means of the format argument to
the auth_user table, rather than trying to remember to call
name_format(user) everywhere. Any advice?
--Greg
[web2py] Re: DAL format= functionality
Ah, it looks like virtual fields is exactly what I'm looking for.
That way I can just call
line.speaker.name
and have that calculated off of the user's name, etc. Thanks! I knew
I had to be missing something obvious to save me the effort.
--Greg
On Mar 31, 9:26 pm, Anthony wrote:
> I think the format argument only alters the record representation in forms
> and SQLTABLE (which is used when a set or records is serialized in a view).
> If you're just doing a query and pulling an individual field value from a
> row, I don't think the format will be applied.
> Seehttp://web2py.com/book/default/chapter/06#Record-Representation.
>
> If you don't want to call the format function every time you display the
> speaker name, maybe you could use a virtual
> field:http://web2py.com/book/default/chapter/06#Virtual-Fields
> Anthony
>
>
>
>
>
>
>
> On Thursday, March 31, 2011 4:41:40 PM UTC-4, Gregory Hellings wrote:
> > I have defined a custom auth.settings.table_user_name implementation
> > that includes one extra field and specifies a value for the format
> > argument. In this case format is a callback function which displays
> > the user's name with extra formatting based on membership in certain
> > auth groups. This option works wonderfully with SQLFORM fields and
> > with appadmin displays of the auth_membership table, but I seem to be
> > missing something about its functionality elsewhere.
>
> > (This is in the context of a demo chat application utilizing the
> > web2py_comet functionality). I have another table which is defined
> > like this:
>
> > db.define_table('chat',
> > Field('speaker', db.auth_user, default=auth.user_id,
> > writable=False, readable=False),
> > Field('statement', 'text', requires=IS_NOT_EMPTY()),
> > Field('deleted', db.auth_user, writable=False, readable=False))
> > db.chat.speaker.requires = IS_IN_DB(db, db.auth_user.id)
> > db.chat.deleted.requires = IS_IN_DB(db, db,auth_user.id)
>
> > My controller for displaying the lines uses this logic
>
> > rawlines=db(db.chat.deleted==None).select(limitby=(0,10),orderby=~
> > db.chat.id)
> > lines=[]
> > for line in rawlines:
> > lines.append(DIV(line.speaker, B("> "), line.statement,
> > _id=line.id))
>
> > However, when I do that, I get the user's ID instead of the user's
> > name as formatted by my format callback method. Thus the chat output
> > looks like
>
> > 1> Hi there
> > 1> How is everyone doing?
> > 2> We're great, how about you?
> > 1> Oh, I'm absolutely fantastic.
>
> > In order to get the properly formatted user's name, I have to
> > explicitly call my format method, making the last line of the above
> > controller instead read
>
> > lines.append(DIV(name_format(line.speaker), B("> "),
> > line.statement, _id=line.id))
>
> > This defeats most of the purpose I had in using the automatic
> > format=name_format argument to the define_table call. Am I missing
> > something here? What am I doing incorrectly? As I scale out of my
> > demo chatroom, I want to make sure user names are consistently
> > displayed throughout my application by means of the format argument to
> > the auth_user table, rather than trying to remember to call
> > name_format(user) everywhere. Any advice?
>
> > --Greg
[web2py] Re: bulk insert form
It probably isn't helpful for multiple file uploads, but you can do bulk insert with the CSV interface. You might need to write a little JavaScript magic to convert multiple forms into a CSV format, but it shouldn't be terribly difficult. For multiple uploads, you could just put multiple forms on a page, hidden, and just unhide them with JavaScript when requested. Then use the standard SQLFORM and CRUD validation tools to handle multiple forms on a single page, but allow them to be optional instead of producing page errors when they are not filled in. There is a section in the web2py book about multiple forms on a single page. Of course, that necessitates setting a predetermined limit on the number of simultaneous bulk creations. --Greg On Apr 11, 11:31 pm, 黄祥 wrote: > hi, > > is it possible to insert several data simultanously (bulk insert) in > web2py using crud or sqlform? i mean, like select several image file > and then upload it, or maybe using jquery add or remove form field > any suggestion or reference for doing that? > > thank you so much
[web2py] Virtual Fields on auth_user
I have a virtual field attached to the auth_user table titled "name" that renders the user's name with certain formatting based on auth membership. I also have records in a second table that are linked to the auth_user table. When I fetch these rows I can access the virtual as expected: row.speaker.name However, when I access the "auth.user" variable to determine the current user, it lacks the appropriate virtual field. Thus calling "auth.user.name" returns the string '0' (when it is JSON-ified) instead of the user's name with formatting. I'm supposing that the framework does not bind the virtual fields until after the "auth" object has been initialized, since they are declared in my db_auth.py file after the auth object is instantiated. Is this missing virtual field intended behavior, a documented problem that is a shortcoming of needing to declare the auth object before binding the virtual fields, or a bug? --Greg
[web2py] Re: some new cool stuff in trunk under testing
On May 4, 4:09 pm, Massimo Di Pierro wrote: > Hello everybody > > Jonathan and I have been working on an internal web2py rewrite that while > keeping everything backward compatible will allow you to do this > > modules/mymodule.py > from gluon import * > def f(): return DIV(A(current.request.function,_href=URL())) > end > > default/controller.py > def index(): > from mymodule import f > return dict(div=f()) > end > > Thanks to Pierre we can now import modules from the app local folder without > local_import and thanks to Jonathan those modules only need to do "from gluon > import *" to see everything web2py has to offer. This should make life easier > for Eclipse users too. > > In models/db.py you no longer need to pass globals() to Auth > > auth=Auth(globals(),db) > or > auth=Auth(db) > > both work. > > Also error messages in validators (including default error messages) should > not be by T(...) by default. > > This is now in trunk but we are still working on it. This means trunk may not > very stable for the next day or two. > Meanwhile help us test it. In particular help us test if we are breaking your > apps. > > Massimo This sounds great! Very excited by that, as it should make code even more natural to an experienced Python user. --Greg
[web2py] Re: How hard it is to do Non-WebSocket Comet (Long Polling)
On Jun 13, 10:20 am, Anthony wrote: > On Monday, June 13, 2011 11:14:23 AM UTC-4, dspiteself wrote: > > > 1. You could modify massimo's commet_messaging.py to use > >https://github.com/kmike/tornadio. It also uses tornado but is based > > on socket.io and gives you the choice of the following transports: > > WebSocket > > Adobe® Flash® Socket > > AJAX long polling > > AJAX multipart streaming > > Forever Iframe > > JSONP Polling > > If you're interested in this option, > seehttp://greg.thehellings.com/2011/04/web2py-websockets-and-socket-io-p... You beat me to the punchline. The only trouble here is that the comet_messaging (including my adaptation to work with TornadIO) does not interface with web2py's input functionality. The _messaging suffix on both of them is used to indicate that web2py can send a message to the client but any message from the client to the server is still done via standard AJAX/REST calls to Apache/mod_wsgi running the main server functionality. If Massimo ever moves from rocket to tornado other possibilities will open up for people who do not want to run web2py behind Apache or lighttpd, etc but for everyone running behind one of these other servers, WebSocket connectivity will be running over a port other than 80/443. It sounds like Phyo's problem is solvable with the comet_messaging system, if I'm reading his post properly (you want to send a notice to the client(s) every time there is a new message, so it's only outgoing messages from the server). The problem lies with a limitation in the number of ports he can use. You _can_ use web2py's rocket server running on port 80 and the Tornado server running (unencrypted or encrypted) on 443 if you would like. It's just about the only method I can think of which will work properly with what you're trying to do. --Greg
[web2py] Re: How hard it is to do Non-WebSocket Comet (Long Polling)
Shouldn't take too much work. In my blog post you can see (and download) a version of comet_messaging.py that works with tornadio. If you want to read in from the Socket.io you'll need to modify it accordingly, but it sounds like it should be straightforward for what you're doing (receiving bursts from the server). Good luck, and I'm willing to maintain any further communications you need on the list or in private if you'd like. --Greg On Jun 18, 4:59 am, Phyo Arkar wrote: > Thanks a lot all. > > I am looking intohttps://github.com/kmike/tornadio, quite interesting . > > Main reason i dont want to use websocket due to not standardsized yet and > all browsers working (and i can't tell them not to use this browser only > this browser) . > > Yes the problem of only 2 ports can be solved by listening a daemon at 443 > but they may want https later. May be i will reverse proxy later. > > On Tue, Jun 14, 2011 at 4:47 AM, Gregory Hellings > wrote: > > > > > > > > > > > On Jun 13, 10:20 am, Anthony wrote: > > > On Monday, June 13, 2011 11:14:23 AM UTC-4, dspiteself wrote: > > > > > 1. You could modify massimo's commet_messaging.py to use > > > >https://github.com/kmike/tornadio. It also uses tornado but is based > > > > on socket.io and gives you the choice of the following transports: > > > > WebSocket > > > > Adobe® Flash® Socket > > > > AJAX long polling > > > > AJAX multipart streaming > > > > Forever Iframe > > > > JSONP Polling > > > > If you're interested in this option, seehttp:// > > greg.thehellings.com/2011/04/web2py-websockets-and-socket-io-p... > > > You beat me to the punchline. > > > The only trouble here is that the comet_messaging (including my > > adaptation to work with TornadIO) does not interface with web2py's > > input functionality. The _messaging suffix on both of them is used to > > indicate that web2py can send a message to the client but any message > > from the client to the server is still done via standard AJAX/REST > > calls to Apache/mod_wsgi running the main server functionality. If > > Massimo ever moves from rocket to tornado other possibilities will > > open up for people who do not want to run web2py behind Apache or > > lighttpd, etc but for everyone running behind one of these other > > servers, WebSocket connectivity will be running over a port other than > > 80/443. > > > It sounds like Phyo's problem is solvable with the comet_messaging > > system, if I'm reading his post properly (you want to send a notice to > > the client(s) every time there is a new message, so it's only outgoing > > messages from the server). The problem lies with a limitation in the > > number of ports he can use. You _can_ use web2py's rocket server > > running on port 80 and the Tornado server running (unencrypted or > > encrypted) on 443 if you would like. It's just about the only method I > > can think of which will work properly with what you're trying to do. > > > --Greg
[web2py] Re: new cool library to handle websockets
I'll have to see if my Socket.IO port of comet_messaging.py still works with the new version. --Greg On Jun 21, 12:08 pm, Massimo Di Pierro wrote: > http://socket.io/index.html#announcement
[web2py] auth_user customization
I was using the following db.py (http://pastie.textmate.org/2389614) and db_auth.py (http://pastie.textmate.org/2389616) files in a project successfully in 1.95.*. When I upgraded to 1.97 and now 1.98 I get the following error (http://dumpr.info/v/2kc) whenever I try to load a page in the application. If I add migrate=False to the declaration of the custom auth_user table, then the line where I invoke "auth.define_tables()" throws an error claiming that auth_group already exists. Has the declaration mechanism for auth changed since 1.95? Does anyone have an idea what might be going on? --Greg
[web2py] Re: in a db query, why the error: can't compare datetime.datetime to Field
If I understand what you're doing there it is a limitation of the
language. db.entry.DT > my_DT works because Field has defined a
special language construct for when the datetime is compared to the
Field. However, my_DT < db.entry.DT does not work, because there you
are comparing a Field to a datetime. Python (and C++, etc) allow you
to define a function to be called when your object is on the left side
of a comparison, but not if it is on the right (unless, of course, an
object of that class is on both sides of the operator).
This could be avoided if someone wanted to custom extend the datetime
object to define the comparison functions, but then a person would
have to use contrib.datetime instead of the built in datetime class.
It's just _The Way Things Are_ and is common for languages which allow
a custom override of comparison operators.
--Greg
On Aug 18, 6:43 pm, Luis Goncalves wrote:
> Let
>
> my_DT = datetime.datetime( 2011, 08, 16)
>
> db.define_table( 'entry', Field('DT' = 'datetime' ) )
>
> (and add data records to the database ...)
>
> In a db query, this works:
>
> db( db.entry.DT> my_DT).select()
>
> but this does not:
>
> db( my_DT< db.entry.DT).select()
>
> producing error : can't compare datetime.datetime to Field
>
> Why does that happen?
>
> Thanks,
> Luis.
[web2py] Re: auth_user customization
This is happening to ALL of my tables. What am I missing here? --Greg On Aug 18, 10:25 am, Gregory Hellings wrote: > I was using the following db.py (http://pastie.textmate.org/2389614) > and db_auth.py (http://pastie.textmate.org/2389616) files in a project > successfully in 1.95.*. When I upgraded to 1.97 and now 1.98 I get > the following error (http://dumpr.info/v/2kc) whenever I try to load a > page in the application. If I add migrate=False to the declaration of > the custom auth_user table, then the line where I invoke > "auth.define_tables()" throws an error claiming that auth_group > already exists. > > Has the declaration mechanism for auth changed since 1.95? Does anyone > have an idea what might be going on? > > --Greg
