Re: [web2py:36972] Re: Unable to install application application name
On Dec 10, 2009, at 10:33 AM, Thadeus Burgess wrote:
I am able to install .w2p.gz apps using the latest devel version.
Also, when he says application_name the brackets mean insert a real
app name. He just decided to not include his app name to be more
understandable for us.
The problem could be anything (see thats why using catchall exceptions
don't benefit!). For debugging, personally I would edit the admin app
and disable the try:catch statements, to determine the real error.
app_install() should probably return a message along with its failure flag.
It doesn't seem to me that .w2p.gz should work, given the app_install logic:
if filename[-4:] == '.w2p':
extension = 'w2p'
elif filename[-7:] == '.tar.gz':
extension = 'tar.gz'
else:
extension = 'tar'
upname = apath('../deposit/%s.%s' % (app, extension), request)
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py:36983] Re: Unable to install application application name
On Dec 10, 2009, at 11:51 AM, mdipierro wrote: Yes this has been fixed in trunk. If what I'm looking at is the trunk (I'm still a little fuzzy on hg updates), there's a problem between app_install() and w2p_update(). The former can deliver a filename: name.tar.gz. The latter converts this to name.tar.tar, if I'm reading it right. (Also, wouldn't it be good to handle name.tgz?) On Dec 10, 1:05 pm, Thadeus Burgess thade...@thadeusb.com wrote: The extension should have been fixed? I remember a making a patch for this. Also web2py should be allowing a .gz extension, as that was part of the patch. -Thadeus On Thu, Dec 10, 2009 at 1:01 PM, jonfroehlich jonfroehl...@gmail.com wrote: ks to all for your responses. It looks like we should mark the code that Jonathan found as a bug, given that web2py generated the *.w2p.gz file that I us -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:36986] Re: Unable to install application application name
On Dec 10, 2009, at 2:27 PM, Yarko Tymciurak wrote: On Dec 10, 2:12 pm, Thadeus Burgess thade...@thadeusb.com wrote: I see, Massmo, I checked my emails and I had sent you the wrong patch, it only included the fix for content-type of the admin application, instead of the logic that allows you to install an app with a .gz extension as well just in case. When I get home, I will send you this second part of the patch . -Thadeus This is an excellent example of why web2py process would benefit from the code-review cycle (extra eyes - even your own - are useful; we are all busy, so things get missed; also the community is generally smarter than any one of us, so additional eyes can be beneficial, although limiting reviews to a small number of people has benefit). It's also an excellent example of why intentional comments are desirable. I'd be happy to submit a patch to clean up the extension handling. The logic is simple, and easy to fix. But I don't completely understand the intent. Why were the particular extensions chosen for support? Are we really likely to see an uncompressed tar file? Why does app_install() unlink everything but tar files? Is it just making assumptions about what gets left around in what circumstances, or is something else going on? Another problem: elif filename[-7:] == '.tar.gz': will raise an exception for short file names, like ab.w2p. Should be using endswith(). -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:36990] Re: Unable to install application application name
On Dec 10, 2009, at 2:46 PM, mdipierro wrote: We may see .tar files because that is what we used before .w2p was introduced. We should only gerenate .w2p but we want to read .tar, .tar.gz, .tgz, .w2p This filename[-7:] == '.tar.gz' will not cause an exception for short filenames but endswith is a better solution. I see; the : saves us. And the .tar unlink? On Dec 10, 4:37 pm, Jonathan Lundell jlund...@pobox.com wrote: On Dec 10, 2009, at 2:27 PM, Yarko Tymciurak wrote: On Dec 10, 2:12 pm, Thadeus Burgess thade...@thadeusb.com wrote: I see, Massmo, I checked my emails and I had sent you the wrong patch, it only included the fix for content-type of the admin application, instead of the logic that allows you to install an app with a .gz extension as well just in case. When I get home, I will send you this second part of the patch . -Thadeus This is an excellent example of why web2py process would benefit from the code-review cycle (extra eyes - even your own - are useful; we are all busy, so things get missed; also the community is generally smarter than any one of us, so additional eyes can be beneficial, although limiting reviews to a small number of people has benefit). It's also an excellent example of why intentional comments are desirable. I'd be happy to submit a patch to clean up the extension handling. The logic is simple, and easy to fix. But I don't completely understand the intent. Why were the particular extensions chosen for support? Are we really likely to see an uncompressed tar file? Why does app_install() unlink everything but tar files? Is it just making assumptions about what gets left around in what circumstances, or is something else going on? Another problem: elif filename[-7:] == '.tar.gz': will raise an exception for short file names, like ab.w2p. Should be using endswith(). -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:36992] Re: Unable to install application application name
On Dec 10, 2009, at 3:26 PM, mdipierro wrote: According to the docs you can generate a tar.gz using mode='w:g' but I tried and it does not work on 2.5. So the process of making the w2p involves a tmp step of creating a tar file that is then removed. Somehow the unlink does not work on window. I do not know why. One solution may be to create the tar in a temp file. This unlink is happening on the upload-and-install side, not w2p generation: try: upfile = open(upname, 'wb') upfile.write(fobj.read()) upfile.close() path = apath(app, request) os.mkdir(path) did_mkdir = True w2p_unpack(upname, path) if extension != 'tar': os.unlink(upname) fix_newlines(path) return upname except Exception: On Dec 10, 4:52 pm, Jonathan Lundell jlund...@pobox.com wrote: On Dec 10, 2009, at 2:46 PM, mdipierro wrote: We may see .tar files because that is what we used before .w2p was introduced. We should only gerenate .w2p but we want to read .tar, .tar.gz, .tgz, .w2p This filename[-7:] == '.tar.gz' will not cause an exception for short filenames but endswith is a better solution. I see; the : saves us. And the .tar unlink? On Dec 10, 4:37 pm, Jonathan Lundell jlund...@pobox.com wrote: On Dec 10, 2009, at 2:27 PM, Yarko Tymciurak wrote: On Dec 10, 2:12 pm, Thadeus Burgess thade...@thadeusb.com wrote: I see, Massmo, I checked my emails and I had sent you the wrong patch, it only included the fix for content-type of the admin application, instead of the logic that allows you to install an app with a .gz extension as well just in case. When I get home, I will send you this second part of the patch . -Thadeus This is an excellent example of why web2py process would benefit from the code-review cycle (extra eyes - even your own - are useful; we are all busy, so things get missed; also the community is generally smarter than any one of us, so additional eyes can be beneficial, although limiting reviews to a small number of people has benefit). It's also an excellent example of why intentional comments are desirable. I'd be happy to submit a patch to clean up the extension handling. The logic is simple, and easy to fix. But I don't completely understand the intent. Why were the particular extensions chosen for support? Are we really likely to see an uncompressed tar file? Why does app_install() unlink everything but tar files? Is it just making assumptions about what gets left around in what circumstances, or is something else going on? Another problem: elif filename[-7:] == '.tar.gz': will raise an exception for short file names, like ab.w2p. Should be using endswith(). -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37008] Re: Unable to install application application name
On Dec 10, 2009, at 6:36 PM, mdipierro wrote: I think it removes the uploaded file execpt if tar because in case of tar it is remoevd by unpack. you may want to check it. Alvaro wrote this function. That's right. I'm not sure about the compressed files, though. I'd do some cleanup, but at the moment I don't have time to do the testing, so I'll pass for now. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37033] Re: Unsubscribe is not working
On Dec 11, 2009, at 9:42 AM, mr.freeze wrote: Did you already go to http://groups.google.com/group/web2py/subscribe and select 'No Email'? I took care of it. On Dec 11, 6:36 am, Offray Vladimir Luna Cárdenas off...@riseup.net wrote: Hi all, First, thanks for all the learning. I think that web2py is a wonderful web application framework, but now my endeavors are oriented back to Zope + Plone, because of the Cyn.in web app. So I'm not reading actively this mailing list. I have tried unsubscribing following the instructions for google groups but I still get mails and this is a traffic I can not manage for a project where I'm not active. Could someone with admin privileges please unsubscribe me? Thanks, Offray -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
[web2py:37143] Murky
It's not yet to beta, per the developer, but I'm finding Murky a very nice, lightweight hg GUI for OS X. http://jens.mooseyard.com/2009/04/murky-a-mercurial-client-app/ -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
[web2py:37180] updated update script
Trivial change: remove update logic. #!/bin/bash # # update-web2py.sh # 2009-12-14 # # install as update-web2py.sh and make executable: # chmod +x web2py.sh # # save a snapshot of current web2py/ as web2py-version.zip # download the current released version of web2py # unzip downloaded version over web2py/ # TARGET=web2py-vpeps read a VERSION c $TARGET/VERSION SAVE=$TARGET-$VERSION URL=http://www.web2py.com/examples/static/web2py_src.zip ZIP=`basename $URL` SAVED= # Save a zip archive of the current version, # but don't overwrite a previous save of the same version. # if [ -f $SAVE.zip ]; then echo Remove or rename $SAVE.zip first 2 exit 1 fi if [ -d $TARGET ]; then echo -n Save old version: 2 cat $TARGET/VERSION 2 zip -q -r $SAVE.zip $TARGET SAVED=$SAVE.zip fi # # Download the new version. # echo Download latest web2py release: 2 curl -O $URL # # Unzip into web2py/ # unzip -q -o $ZIP rm $ZIP echo -n New version: 2 cat $TARGET/VERSION 2 if [ $SAVED != ]; then echo Old version saved as $SAVED fi -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37188] Re: updated update script
On Dec 14, 2009, at 9:22 AM, mdipierro wrote: email it to me. Please thank you. Here you are. I changed the comments to indicate that it should live in the parent of web2py/. I could change it to run as web2py/update-web2py.sh, but that means that it gets overwritten while executing, and in my experience that can confuse the shell (though I'm not sure exactly why, or under what circumstances, and maybe it's not a real problem for a simple script). I'm thinking of changing it so that it checks to see whether it's running from web2py/ or web2py/.. and work regardless. What do you think? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. update-web2py.sh Description: Binary data
Re: [web2py:37217] Re: Excess whitespace in html
On Dec 14, 2009, at 8:39 PM, Alex Fanjul wrote: But... what about pages size? Doing some very basic test with Denes Example show us that including blank lines increase the output page size by *x2 factor* at least (ie. 67KB vs 130KB). Maybe I'm wrong, but, forgetting server deflating (which not everybody use), there are a double size in store and transmit bandwidth, that is money. If it isn't too dificult to implement I would prefer to see it legible in 'design' and 'running' time, because many times people review and debug webpages over generated code (I guess) 2x seems like an awful lot, since a newline is only one byte. Are you sure? You could try slimmer: http://pypi.python.org/pypi/slimmer/ -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37236] Re: Excess whitespace in html
On Dec 15, 2009, at 8:13 AM, kbochert wrote: Jonathon wrote: 2x seems like an awful lot, since a newline is only one byte. Are you sure? The output typically has multiple leading spaces on those blank lines, presumably driven by the indenting of the original html. I finally noticed the attachments. It does seem like a pathological case, though (v. short lines and lots of whitespace). DenesL wrote: Do you want you view or your final output to be legible and aesthetically pleasing according to some subjective human standard?. Absolutely! For instance, I'm currently looking for a designer to style my site. The first thing I do is surf to their home page and look at its source code! If I'm evangelizing web2py to colleagues, clean output helps. (makes me prouder of my work, at least) I agree that good-looking output is a plus. It doesn't seem unreasonable to ask developers to understand how web2py templates work, and design accordingly. It's not a mystery where the white space is coming from, and the developer has complete control. One problem, though, is that there *is* a conflict between good-looking (and readable, and maintainable) template source, and the appearance of the output. We use (and should use) white space liberally to make our code readable. If that same white space leaks into the output, it generally looks pretty random. Those of us that write straight html are doing both at the same time. Our html needs to be maintainable *as source*. A different standard needs to be applied to generated html, since it won't be (directly) maintained. What I like about using a filter (slimmer or the like) is that it leaves you free to write readable source, and end up with decent output. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37263] Re: Excess whitespace in html
On Dec 15, 2009, at 12:08 PM, Alex Fanjul wrote:
Hello Kbochert, it seems you found out a way to make cleaner output, do
you get it working automatically? (ie. with out manual action for output
clean process)
I'm thinking in alway pass dictionaris throught filter function so
instead of return dict we'd return filter(dict) but I'm not sure if it
would be right.
Could you give me the steps or snippet example to achieve this?
Finally, did you find any disadventages doing this? errors, slower
speed, etc...
I think it might be most useful to filter the entire page content, after it's
composed, but before it's delivered. Say a filter function, by default None, in
response, that gets called just before delivering the page, if the content-type
is appropriate.
Thanks a lot,
Alex F
El 15/12/2009 17:13, kbochert escribió:
Jonathon wrote:
2x seems like an awful lot, since a newline is only one byte. Are you sure?
The output typically has multiple leading spaces on those blank
lines, presumably driven by the indenting of the original html.
DenesL wrote:
Do you want you view or your final output to be legible and
aesthetically pleasing according to some subjective human standard?.
Absolutely!
For instance, I'm currently looking for a designer to style my site.
The first thing I do is surf to their home page and look at its source
code!
If I'm evangelizing web2py to colleagues, clean output helps. (makes
me prouder of my work, at least)
I tried massimos' code snippet
def filter(d):
import re
if isinstance(d,dict):
return re.compile('\n\n').sub('\n',response.render(d))
return d
response._caller=filter
It failed, generating pages with a single line of html function
index at 0x01A04C70
-- but --
def filter(d):
import re
if isinstance(d,dict):
return re.compile('\n\s\s+\n').sub('\n',response.render(d))
return re.compile('\n\s\s+\n').sub('\n',response.render(d()))
response._caller=filter
worked !beautifully! When I take care to write the template cleanly,
the rendering is also clean.
This makes a distinction between empty lines (with no characters), and
blank lines (containing only whitespace chars).
blank lines are removed, empty lines are not. (whitespace matters!)
It would be nice if web2py could make this its default rendering
behavior.
Are there other issues thanpre blocks?
Karl
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
Alejandro Fanjul Fdez.
alex.fan...@gmail.com
www.mhproject.org
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37304] Re: Excess whitespace in html
On Dec 15, 2009, at 5:11 PM, kbochert wrote:
Amazingly enough, the following snippet appears to filter excess lines
while leaving pre blocks unchanged!!
You might want pre.*?/pre
import re
def remove_line(mo):
s = mo.group()
if s.startswith('pre'): return s
return '\n'
def filter(d):
if not isinstance(d,dict): d = d()
pat = re.compile(r'(\n\s\s+\n|(?s)pre.*/pre)')
return pat.sub(remove_line,response.render(d))
response._caller=filter
??
Karl
On Dec 15, 4:14 pm, Thadeus Burgess thade...@thadeusb.com wrote:
My pre tags are generated by a WYSIWYG editor. It would be highly
inconvenient to edit the source it generates, just for pre tags to render
correctly
-Thadeus
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37332] Re: Select DISTINCT ON Field Name bug?
On Dec 15, 2009, at 9:30 PM, mdipierro wrote:
Good catch! Uploading fix in trunk.
Would you explain the fix, please, to those of us who don't understand the
subtlety of it? Thanks.
Massimo
On Dec 15, 11:13 pm, jonfroehlich jonfroehl...@gmail.com wrote:
Although the web2py documentation (page 165) appears to imply that the
argument distinct can only be set to True or False, the gluon/sql.py
file reveals otherwise. From line 2871 of sql.py:
distinct = attributes.get('distinct', False)
if distinct == True:
sql_s += ' DISTINCT'
elif distinct:
sql_s += ' DISTINCT ON %s' % distinct
So, it appears as though the code is trying to support providing
specific field names with which to execute the DISTINCT ON expression
upon (the elif distinct part). I found a post about this from June
when it looks like the above code was first
proposed:http://groups.google.com/group/web2py/browse_thread/thread/cc6180d335
The code, however, does not appear to be executing properly. Whether
distinct is set to True or, more importantly, whether it is set to a
field name, the distinct == True branch is still taken and the elif
distinct branch is never executed (unfortunately in my case). I could
be doing something wrong, so let me try to include the relevant
information.
I have the following table:
db.define_table('sensor_health',
Field('deployment_site', 'string'),
Field('sensor_name', 'string'),
Field('sensor_started', 'datetime'),
Field('last_heard_from', 'datetime'),
Field('sampling_rate', 'double'),
Field('sensor_event_count', 'integer')
)
When executing this query:
sensorHealthRows= db(db.sensor_health.deployment_site ==
deploymentSite).select(
db.sensor_health.sensor_name, db.sensor_health.sensor_started,
db.sensor_health.last_heard_from,
db.sensor_health.sampling_rate,
db.sensor_health.sensor_event_count,
orderby=(db.sensor_health.sensor_name|
~db.sensor_health.sensor_started),
distinct=db.sensor_health.sensor_name)
Which should be equivalent to this in PostgresSQL:
SELECT DISTINCT ON (sensor_health.sensor_name)
sensor_health.sensor_name, sensor_health.sensor_started,
sensor_health.last_heard_from, sensor_health.sampling_rate,
sensor_health.sensor_event_count
FROM sensor_health
ORDER BY sensor_health.sensor_name, sensor_health.sensor_started
DESC;
I set a breakpoint in sql.py at line 2872 in Wing IDE and the code
does indeed follow the distinct == True branch even though I clearly
set distinct = db.sensor_health.sensor_name in my query. Here's the
even stranger part: using Wing IDE's Debug Probe, I could actually
play around with this a bit (a direct copy/paste from the output is
below). Notice that the type(distinct) is class 'gluon.sql.Field' and,
perhaps even more interesting, it appears as though distinct evaluates
to both True and False. What's going on here?
print distinct
sensor_health.sensor_name distinct == True
gluon.sql.Query object at 0x0393E510 if distinct == True: print
distinct is True
...
distinct is True if distinct == False: print distinct is False
...
distinct is False type(distinct)
class 'gluon.sql.Field'
Thanks for your help!
j
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
[web2py:37374] welcome/appadmin plugin
I was updating a small web2py app this morning, after moving to 1.74.2, and in doing so I diffed some of its files against the current welcome app, and noticed that a lot of the appadmin code (that I hadn't modified) had been updated (primarykey support, for example). Likewise, web2py_ajax.html was considerably changed. I haven't been following the plugin discussion very closely, so I'm not sure that it's quite the right mechanism, but it seems to me that it might make sense for appadmin, and perhaps web2py_ajax, to be implemented/named as plugins, to make it more obvious that it's generic web2py functionality that might want to be updated along with the rest of the framework. Along those lines, another thing that would have come in handy would have been a virgin copy of the template (welcome) app that I used to build my own app. If I had that, it'd be easier to diff the current template app against the one I used, and to distinguish between changes made to the web2py distribution from the changes I had made. I could do that manually, of course, but it didn't occur to me at the time. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37399] Re: welcome/appadmin plugin
On Dec 16, 2009, at 12:28 PM, mdipierro wrote: On the one side it may be a good idea to have some of the generic views and appadmin be implemented as a plugin. And this will happen in the future. On the other side we do not guarantee backward compatibility for those since they become part of your application. We only guarantee that the framwork continues to work with them. In fact as you change the layout you may need to edit web2py_ajax and or appadmin. In general if your app works you do not want to upgrade those files. Of course, just because it's a plugin (if it/they were) doesn't mean that I'd have to update them; it would just make it easier. And it's likely that they wouldn't have been edited, so upgrading would be straightforward. As for wanting to upgrade them, it might well be unnecessary, of course, but if I wanted my app to take advantage of new features (primarykey in the recent case), I'd need to. And personally, I prefer to keep that kind of stuff up to date on (admittedly vague) general principles. In any event, I'll wait for the future to show up... Massimo On Dec 16, 12:30 pm, Jonathan Lundell jlund...@pobox.com wrote: I was updating a small web2py app this morning, after moving to 1.74.2, and in doing so I diffed some of its files against the current welcome app, and noticed that a lot of the appadmin code (that I hadn't modified) had been updated (primarykey support, for example). Likewise, web2py_ajax.html was considerably changed. I haven't been following the plugin discussion very closely, so I'm not sure that it's quite the right mechanism, but it seems to me that it might make sense for appadmin, and perhaps web2py_ajax, to be implemented/named as plugins, to make it more obvious that it's generic web2py functionality that might want to be updated along with the rest of the framework. Along those lines, another thing that would have come in handy would have been a virgin copy of the template (welcome) app that I used to build my own app. If I had that, it'd be easier to diff the current template app against the one I used, and to distinguish between changes made to the web2py distribution from the changes I had made. I could do that manually, of course, but it didn't occur to me at the time. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37405] Re: welcome/appadmin plugin
On Dec 16, 2009, at 2:32 PM, mdipierro wrote: I agree. We could make a plugin for distribution without renaming the files inside. web2py admin would be able to unpack the plugin over the existing app thus updating the files but it would not recognize the content as plugin files (because appadmin does not start with plugin_*) therefore the content would not be listed under the plugin section. Is this the same that you have in mind? Something like that, yes. Though I was thinking it might make sense for appadmin to *be* a plugin, formally, since it's functionality that one might well remove from an app, too. I'm not pushing the idea too hard; it was just slightly more than an idle thought I had while doing the update manually. Massimo On Dec 16, 4:17 pm, Jonathan Lundell jlund...@pobox.com wrote: On Dec 16, 2009, at 12:28 PM, mdipierro wrote: On the one side it may be a good idea to have some of the generic views and appadmin be implemented as a plugin. And this will happen in the future. On the other side we do not guarantee backward compatibility for those since they become part of your application. We only guarantee that the framwork continues to work with them. In fact as you change the layout you may need to edit web2py_ajax and or appadmin. In general if your app works you do not want to upgrade those files. Of course, just because it's a plugin (if it/they were) doesn't mean that I'd have to update them; it would just make it easier. And it's likely that they wouldn't have been edited, so upgrading would be straightforward. As for wanting to upgrade them, it might well be unnecessary, of course, but if I wanted my app to take advantage of new features (primarykey in the recent case), I'd need to. And personally, I prefer to keep that kind of stuff up to date on (admittedly vague) general principles. In any event, I'll wait for the future to show up... Massimo On Dec 16, 12:30 pm, Jonathan Lundell jlund...@pobox.com wrote: I was updating a small web2py app this morning, after moving to 1.74.2, and in doing so I diffed some of its files against the current welcome app, and noticed that a lot of the appadmin code (that I hadn't modified) had been updated (primarykey support, for example). Likewise, web2py_ajax.html was considerably changed. I haven't been following the plugin discussion very closely, so I'm not sure that it's quite the right mechanism, but it seems to me that it might make sense for appadmin, and perhaps web2py_ajax, to be implemented/named as plugins, to make it more obvious that it's generic web2py functionality that might want to be updated along with the rest of the framework. Along those lines, another thing that would have come in handy would have been a virgin copy of the template (welcome) app that I used to build my own app. If I had that, it'd be easier to diff the current template app against the one I used, and to distinguish between changes made to the web2py distribution from the changes I had made. I could do that manually, of course, but it didn't occur to me at the time. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37425] Re: Switch from http to https within app
On Dec 16, 2009, at 6:58 PM, Álvaro Justen [Turicas] wrote:
On Thu, Dec 10, 2009 at 20:50, mdipierro mdipie...@cs.depaul.edu wrote:
I would suggest creating a model 0_redefine_url.py that contains:
_URL=URL
def URL(*a,**b):
if not 'secure' in b:
return _URL(*a,**b)
elif b['secure']:
del b['secure']
return 'https://'+request.env.http_host + _URL(*a,**b)
else:
del b['secure']
return 'http://'+request.env.http_host + _URL(*a,**b)
and use URL(,secure=True), URL(...secure=False) as required
I think this is very useful. Can we add this in trunk?
It *would* be useful, I think. If URL() defaults secure=None ...
Massimo
'https://'+request.env.http_host +'/app/default/logon')
On Dec 10, 2:11 pm, Wes James compte...@gmail.com wrote:
Actually, I don't think it would matter if there were a proxy or not??
On Thu, Dec 10, 2009 at 1:06 PM, Wes James compte...@gmail.com wrote:
As long as you don't have a proxy between your users and the server
something with request.env could be used
def login():
if request.env.port != 443:
redirect('https://'+request.env.http_host +'/app/default/logon')
-wes
On Thu, Dec 10, 2009 at 11:42 AM, Jay j...@unclehenrys.com wrote:
I am new to web2py and Apache w/mod_ssl and I have been searching
for
a solution related to this topic but I must be missing a basic
understanding of the necessary pieces in order to accomplish this.
Our web2py apache setup seems to be fine. I can access our app's
pages using both http and https if I manually add the 's' to the url.
What we are trying to do is smoothly transition from one controller/
function using http to another using https.
Example, a user arrives athttp://init/default/indexand then the
user
selects ‘Login’ and they are sent to https:/init/default/login. We
need some controller functions to use http and some https. Can this
be done from within the controller/function? If not, what is the
‘best practice’ approach to accomplishing this?
- Jay
--
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37456] Re: Switch from http to https within app
On Dec 17, 2009, at 6:38 AM, Jay wrote:
I cant seem to make this work. I created the file in models
and modified a url helper to use it and received the following error:
TypeError: URL() got an unexpected keyword argument 'secure'
It might help to see the entire traceback.
A few follow up questions:
1. Did you intend to say 'model' rather than module?
'models'
2. How do I integrate 0_redefine_url.py into my app such that the
URL
helper will accept the keyword argument 'secure'?
The idea is to stick it in applications/yourapp/models/, which makes it visible
to the entire app. The prepended '0' makes it sort to the beginning, so it's
also available to the other model files.
Thanks
- Jay
On Dec 17, 1:20 am, mdipierro mdipie...@cs.depaul.edu wrote:
I do not think it is a idea because would encourage people to use it
and build non-portable applications.
If users were doing that, the applications may break when running on
port 8000 or would break when being a proxy if it where to detect the
port. There is no definitive way for the app to know the public URL.
Moreover it would only form when called with URL(r=request,...) but
not when called with URL(app,...) because it would have no knowledge
of the request object.
I think whether to use https and/or https should be handled outside
the application.
Massimo
On Dec 16, 10:52 pm, Jonathan Lundell jlund...@pobox.com wrote:
On Dec 16, 2009, at 6:58 PM, Álvaro Justen [Turicas] wrote:
On Thu, Dec 10, 2009 at 20:50, mdipierro mdipie...@cs.depaul.edu wrote:
I would suggest creating a model 0_redefine_url.py that contains:
_URL=URL
def URL(*a,**b):
if not 'secure' in b:
return _URL(*a,**b)
elif b['secure']:
del b['secure']
return 'https://'+request.env.http_host + _URL(*a,**b)
else:
del b['secure']
return 'http://'+request.env.http_host + _URL(*a,**b)
and use URL(,secure=True), URL(...secure=False) as required
I think this is very useful. Can we add this in trunk?
It *would* be useful, I think. If URL() defaults secure=None ...
Massimo
'https://'+request.env.http_host +'/app/default/logon')
On Dec 10, 2:11 pm, Wes James compte...@gmail.com wrote:
Actually, I don't think it would matter if there were a proxy or not??
On Thu, Dec 10, 2009 at 1:06 PM, Wes James compte...@gmail.com wrote:
As long as you don't have a proxy between your users and the server
something with request.env could be used
def login():
if request.env.port != 443:
redirect('https://'+request.env.http_host +'/app/default/logon')
-wes
On Thu, Dec 10, 2009 at 11:42 AM, Jay j...@unclehenrys.com wrote:
I am new to web2py and Apache w/mod_ssl and I have been searching
for
a solution related to this topic but I must be missing a basic
understanding of the necessary pieces in order to accomplish this.
Our web2py apache setup seems to be fine. I can access our app's
pages using both http and https if I manually add the 's' to the url.
What we are trying to do is smoothly transition from one controller/
function using http to another using https.
Example, a user arrives athttp://init/default/indexandthenthe
user
selects ‘Login’ and they are sent to https:/init/default/login. We
need some controller functions to use http and some https. Can this
be done from within the controller/function? If not, what is the
‘best practice’ approach to accomplishing this?
- Jay
--- Hide quoted text -
- Show quoted text -
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37460] Re: web2py blog screencast (Re-Encoded)
On Dec 17, 2009, at 4:51 AM, Daniel Antonio Aguayo Catalán wrote: I have re-encoded video mengu's screencast video with Theora and now have 3 versions for you: * 135 MiB (1280x928): http://omploader.org/vMzBoeg * 57,5 MiB (800x580): http://omploader.org/vMzBrZg * 37.5 MiB (640x462): http://omploader.org/vMzBpbg If you're wondering how to watch these in OS X: use Firefox. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37469] Re: Switch from http to https within app
On Dec 17, 2009, at 10:48 AM, Jay wrote:
The file is named 0_redefine_url.py and is in my applications/init/
models folder. It contains:
Massimo may know what's going on, but the new URL() isn't getting called. In
the meantime, how about trying this to make an https URL; seems simpler:
def SURL(*a, **b):
return 'https://' + request.env.http_host + URL(*a,**b)
_URL=URL
def URL(*a,**b):
if not 'secure' in b:
return _URL(*a,**b)
elif b['secure']:
del b['secure']
return 'https://'+request.env.http_host + _URL(*a,**b)
else:
del b['secure']
return 'http://'+request.env.http_host + _URL(*a,**b)
Here is the complete traceback:
Error traceback
Traceback (most recent call last):
File /home/jayr/workspace/newsite/app/gluon/restricted.py, line
178, in restricted
exec ccode in environment
File /home/jayr/workspace/newsite/app/applications/init/controllers/
profile.py, line 248, in module
File /home/jayr/workspace/newsite/app/gluon/globals.py, line 102,
in lambda
self._caller = lambda f: f()
File /home/jayr/workspace/newsite/app/gluon/tools.py, line 1418,
in f
return action(*a, **b)
File /home/jayr/workspace/newsite/app/applications/init/controllers/
profile.py, line 199, in notes
print_notes = URL(r=request, a=request.application, c='profile',
f='notes_print', secure='True')
TypeError: URL() got an unexpected keyword argument 'secure'
Thanks,
- Jay
On Dec 17, 10:58 am, Jonathan Lundell jlund...@pobox.com wrote:
On Dec 17, 2009, at 6:38 AM, Jay wrote:
I cant seem to make this work. I created the file in models
and modified a url helper to use it and received the following error:
TypeError: URL() got an unexpected keyword argument 'secure'
It might help to see the entire traceback.
A few follow up questions:
1. Did you intend to say 'model' rather than module?
'models'
2. How do I integrate 0_redefine_url.py into my app such that the
URL
helper will accept the keyword argument 'secure'?
The idea is to stick it in applications/yourapp/models/, which makes it
visible to the entire app. The prepended '0' makes it sort to the beginning,
so it's also available to the other model files.
Thanks
- Jay
On Dec 17, 1:20 am, mdipierro mdipie...@cs.depaul.edu wrote:
I do not think it is a idea because would encourage people to use it
and build non-portable applications.
If users were doing that, the applications may break when running on
port 8000 or would break when being a proxy if it where to detect the
port. There is no definitive way for the app to know the public URL.
Moreover it would only form when called with URL(r=request,...) but
not when called with URL(app,...) because it would have no knowledge
of the request object.
I think whether to use https and/or https should be handled outside
the application.
Massimo
On Dec 16, 10:52 pm, Jonathan Lundell jlund...@pobox.com wrote:
On Dec 16, 2009, at 6:58 PM, Álvaro Justen [Turicas] wrote:
On Thu, Dec 10, 2009 at 20:50, mdipierro mdipie...@cs.depaul.edu wrote:
I would suggest creating a model 0_redefine_url.py that contains:
_URL=URL
def URL(*a,**b):
if not 'secure' in b:
return _URL(*a,**b)
elif b['secure']:
del b['secure']
return 'https://'+request.env.http_host + _URL(*a,**b)
else:
del b['secure']
return 'http://'+request.env.http_host + _URL(*a,**b)
and use URL(,secure=True), URL(...secure=False) as required
I think this is very useful. Can we add this in trunk?
It *would* be useful, I think. If URL() defaults secure=None ...
Massimo
'https://'+request.env.http_host +'/app/default/logon')
On Dec 10, 2:11 pm, Wes James compte...@gmail.com wrote:
Actually, I don't think it would matter if there were a proxy or not??
On Thu, Dec 10, 2009 at 1:06 PM, Wes James compte...@gmail.com wrote:
As long as you don't have a proxy between your users and the server
something with request.env could be used
def login():
if request.env.port != 443:
redirect('https://'+request.env.http_host +'/app/default/logon')
-wes
On Thu, Dec 10, 2009 at 11:42 AM, Jay j...@unclehenrys.com wrote:
I am new to web2py and Apache w/mod_ssl and I have been searching
for
a solution related to this topic but I must be missing a basic
understanding of the necessary pieces in order to accomplish this.
Our web2py apache setup seems to be fine. I can access our app's
pages using both http and https if I manually add the 's' to the
url.
What we are trying to do is smoothly transition from one controller/
function using http to another using https.
Example, a user arrives athttp://init/default/indexandthenthe
user
selects ‘Login’ and they are sent to https:/init/default/login. We
need some controller functions to use http and some https. Can this
be done from within the controller/function? If not, what
Re: [web2py:37476] bug in tools.py class Mail
On Dec 17, 2009, at 12:55 PM, Bob_in_Comox wrote: There is a typo error in line 257 of tools.py (latest version 1.74.3): 256.if reply_to != None: 257.payload['Reply-To'] = reply_to.encode(ecoding) should be: 257.payload['Reply-To'] = reply_to.encode(encoding) Web2py is such a great framework this is the only bug I've found in a year of use! Line 128 as well. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37544] Re: Control MIME type for static download
On Dec 18, 2009, at 11:48 AM, mdipierro wrote: How is it served? via default/download or via static? Which web2py version? There's no w2p entry in CONTENT_TYPE. On Dec 18, 1:24 pm, mr.freeze nat...@freezable.com wrote: When I host a .w2p file on Dreamhost, it tries to open in the browser with Firefox, displaying garbled binary data on the screen. I have tried this in my .htaccess file: Files *.w2p ForceType application/octet-stream Header set Content-Disposition attachment /Files ...and... AddType application/octet-stream .w2p ...with no luck. Can I control this through web2py? Sorry if this has been discussed already. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37545] Control MIME type for static download
On Dec 18, 2009, at 11:24 AM, mr.freeze wrote: When I host a .w2p file on Dreamhost, it tries to open in the browser with Firefox, displaying garbled binary data on the screen. I have tried this in my .htaccess file: Files *.w2p ForceType application/octet-stream Header set Content-Disposition attachment /Files ...and... AddType application/octet-stream .w2p ...with no luck. Can I control this through web2py? Sorry if this has been discussed already. Assuming that the file is being served by web2py, I don't think that .htaccess is going to have any effect. If you're serving the file dynamically (through a controller), you could try: response.headers['Content-Type'] = 'application/x-compressed-tar' Or you could add this to CONTENT_TYPE in contenttype.py. '.w2p': 'application/x-compressed-tar', (I think octet-stream is fine, too, but x-compressed-tar is how web2py serves .tgz files.) -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37711] Re: mercurial HELP!
On Dec 22, 2009, at 4:41 PM, mdipierro wrote: does not work gives me an error because the username is my email address and contains @. What if you encode it as %40? On Dec 22, 5:59 pm, Thadeus Burgess thade...@thadeusb.com wrote: You need to include the username/password as an in-line to the URL. default = https://username:password@web2py.googlecode.com/hg/ so... https://mdipierro:s343...@web2py.googlecode.com/hg/ -Thadeus On Tue, Dec 22, 2009 at 5:46 PM, mdipierro mdipie...@cs.depaul.edu wrote: I have this in my .hg/hgrc [paths] default =https://web2py.googlecode.com/hg/ default-push https://web2py.googlecode.com/hg/%0Adefault-push = https://web2py.googlecode.com/hg/ [auth] default.prefix =https://web2py.googlecode.com/hg/ default.username = mdipie...@cs.depaul.edu default.password = my password default-push.prefix =https://web2py.googlecode.com/hg/ default-push.usernamehttps://web2py.googlecode.com/hg/%0Adefault-push.username= mdipie...@cs.depaul.edu default-push.password = my password It still asks me for username and password every time I do Why? What am I doing wrong? Massimo -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.comweb2py%2bunsubscr...@googlegroups.com . For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37713] Re: mercurial HELP!
On Dec 22, 2009, at 4:59 PM, mdipierro wrote:
hg push
Now *that's* unfriendly.
** unknown exception encountered, details follow
** report bug details to http://www.selenic.com/mercurial/bts
** or mercur...@selenic.com
** Mercurial Distributed SCM (version 1.2.1)
** Extensions loaded:
Traceback (most recent call last):
File /usr/local/bin/hg, line 5, in module
pkg_resources.run_script('mercurial==unknown', 'hg')
File /System/Library/Frameworks/Python.framework/Versions/2.5/
Extras/lib/python/pkg_resources.py, line 442, in run_script
self.require(requires)[0].run_script(script_name, ns)
File /System/Library/Frameworks/Python.framework/Versions/2.5/
Extras/lib/python/pkg_resources.py, line 1160, in run_script
execfile(script_filename, namespace, namespace)
File /Library/Python/2.5/site-packages/mercurial-unknown-py2.5-
macosx-10.5-i386.egg/EGG-INFO/scripts/hg, line 27, in module
mercurial.dispatch.run()
File /Library/Python/2.5/site-packages/mercurial-unknown-py2.5-
macosx-10.5-i386.egg/mercurial/dispatch.py, line 16, in run
sys.exit(dispatch(sys.argv[1:]))
File /Library/Python/2.5/site-packages/mercurial-unknown-py2.5-
macosx-10.5-i386.egg/mercurial/dispatch.py, line 25, in dispatch
return _runcatch(u, args)
File /Library/Python/2.5/site-packages/mercurial-unknown-py2.5-
macosx-10.5-i386.egg/mercurial/dispatch.py, line 41, in _runcatch
return _dispatch(ui, args)
File /Library/Python/2.5/site-packages/mercurial-unknown-py2.5-
macosx-10.5-i386.egg/mercurial/dispatch.py, line 273, in _dispatch
lui.readconfig(os.path.join(path, .hg, hgrc))
File /Library/Python/2.5/site-packages/mercurial-unknown-py2.5-
macosx-10.5-i386.egg/mercurial/ui.py, line 166, in readconfig
self.fixconfig(root=root)
File /Library/Python/2.5/site-packages/mercurial-unknown-py2.5-
macosx-10.5-i386.egg/mercurial/ui.py, line 207, in fixconfig
pathsitems = cdata.items('paths')
File /System/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/ConfigParser.py, line 557, in items
for option in options]
File /Library/Python/2.5/site-packages/mercurial-unknown-py2.5-
macosx-10.5-i386.egg/mercurial/util.py, line 207, in _interpolate
option, rawval, vars)
File /System/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/ConfigParser.py, line 593, in _interpolate
self._interpolate_some(option, L, rawval, section, vars, 1)
File /System/Library/Frameworks/Python.framework/Versions/2.5/lib/
python2.5/ConfigParser.py, line 634, in _interpolate_some
'%%' must be followed by '%%' or '(', found: %r % (rest,))
ConfigParser.InterpolationSyntaxError: '%' must be followed by '%' or
'(', found: '%40cs.depaul.edu:passw...@web2py.googlecode.com/hg/'
make: *** [push] Error 1
On Dec 22, 6:50 pm, Jonathan Lundell jlund...@pobox.com wrote:
On Dec 22, 2009, at 4:41 PM, mdipierro wrote:
does not work gives me an error because the username is my email
address and contains @.
What if you encode it as %40?
On Dec 22, 5:59 pm, Thadeus Burgess thade...@thadeusb.com wrote:
You need to include the username/password as an in-line to the URL.
default = https://username:password@web2py.googlecode.com/hg/
so...
https://mdipierro:s343...@web2py.googlecode.com/hg/
-Thadeus
On Tue, Dec 22, 2009 at 5:46 PM, mdipierro mdipie...@cs.depaul.edu wrote:
I have this in my .hg/hgrc
[paths]
default =https://web2py.googlecode.com/hg/
default-push https://web2py.googlecode.com/hg/%0Adefault-push =
https://web2py.googlecode.com/hg/
[auth]
default.prefix =https://web2py.googlecode.com/hg/
default.username = mdipie...@cs.depaul.edu
default.password = my password
default-push.prefix =https://web2py.googlecode.com/hg/
default-push.usernamehttps://web2py.googlecode.com/hg/%0Adefault-push.username=
mdipie...@cs.depaul.edu
default-push.password = my password
It still asks me for username and password every time I do
Why? What am I doing wrong?
Massimo
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.comweb2py%2bunsubscr...@googlegroups.com
.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com
Re: [web2py:37761] a onclick=javascript: ... problem
On Dec 23, 2009, at 7:52 AM, annet wrote:
a class=adiv onmouseover=this.style.cursor='pointer';
onclick=javascript:demo('%s')%URL(r=request,c='demo',f='index')
h2Fitwise Demo Applicatie/h2
pIn de Demo Applicatie .../p
/a !-- adiv --
... and in the _ajax.html file:
function demo(url) {
demowindow=window.open
(url,'name','toolbar=no,location=no,directories=no,status=no,menubar=no,scrollbars=yes,resizable=no,width=800,height=700');
if (window.focus) demowindow.focus();
return false;
}
When I click the div, a new window opens, however, the url reads like:
http://127.0.0.1/frame/default/%s
whereas, it should read like:
http://127.0.0.1:8000/frame/demo/index
Why doesn't this work?
Maybe because you never escape your Python code?
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37769] Re: a onclick=javascript: ... problem
On Dec 23, 2009, at 9:52 AM, annet wrote:
By escaping my Python code you mean escaping this line:
onclick=javascript:demo('%s')%URL(r=request,c='demo',f='index')
... how would I do that?
I'm not quite sure of the syntax, but something more like this:
onclick=javascript:demo({{='%s'%URL(r=request,c='demo',f='index')}})
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py:37771] Re: a onclick=javascript: ... problem
On Dec 23, 2009, at 10:06 AM, Thadeus Burgess wrote:
a class=adiv onmouseover=this.style.cursor='pointer';
onclick=javascript:demo('%s')%URL(r=request,c='demo',f='index')
You need the template python brackets.
a class=adiv onmouseover=this.style.cursor='pointer';
onclick={{=javascript:demo('%s')%URL(r=request,c='demo',f='index')}}
This is a slightly tricky case because of the nested quotes. The solution above
loses the double quotes around the onclick value. (There are multiple
solutions, of course.)
-Thadeus
On Wed, Dec 23, 2009 at 11:52 AM, annet annet.verm...@gmail.com wrote:
Massimo and Jonathan,
I do not why but why not just
a class=adiv href={{=URL(r=request,c='demo',f='index')}}
target=demo
Thanks, that solves my problem in this case, because I don't need to
re-size the window.
Maybe because you never escape your Python code?
td
{{=A
(club.bedrijf.bedrijfsnaam,_onmouseover=this.style.cursor='pointer';,
\
_onclick=javascript:clublocatordetails('%s')%URL
(r=request,f='details',args=[club.bedrijf.id]))}}
/td
I based my code on the lines of code above. However, since I don't
think I could replace:
club.bedrijf.bedrijfsnaam
with:
h2Fitwise Demo Applicatie/h2
pIn de Demo Applicatie .../p
I gave this a try:
a class=adiv onmouseover=this.style.cursor='pointer';
onclick=javascript:demo('%s')%URL(r=request,c='demo',f='index')
h2Fitwise Demo Applicatie/h2
pIn de Demo Applicatie .../p
/a !-- adiv --
By escaping my Python code you mean escaping this line:
onclick=javascript:demo('%s')%URL(r=request,c='demo',f='index')
... how would I do that?
Kind regards,
Annet.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py:38036] Re: Excess whitespace in html
On Dec 15, 2009, at 3:23 PM, mdipierro wrote: You may also want to look into scripts/cleanhtml.py and scripts/ cleancss.py. cleanhtml.py would benefit from some comments -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:38489] Can you please turn off the message counter in the subject?
On Jan 6, 2010, at 2:25 PM, s...@pobox.com wrote: All web2py emails include both the list name and (apparently) the message counter in the subject. As the message counter auto-increments, no subjects are truly the same and thus my 'k' key in Emacs's VM doesn't kill the entire subject. Any chance you can get rid of the counter? I can't see that it actually serves any useful purpose anyway. ==skip-- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py:38499] Re: SQLFORM without tables
On Jan 5, 2010, at 3:13 PM, Thadeus Burgess wrote: I think what he really wants is the same thing I have been discussing for quite a while :) For now, sqlform.custom is the way to go http://web2py.com/AlterEgo/default/show/205 A side note: this page (and I suppose others) refer to what I assume is an svn version: SQLFORM (starting with rev.726) now keeps the values retrieved from the DB in custom objects that can be referenced by field name and used directly in custom forms without the need to re-access the DB. ...no longer very helpful. A stable release number would be better.-- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] settting two vars to same text
On Jan 15, 2010, at 2:26 PM, Wes James wrote: This seems to work, but is there a better way to set some vars to the same value? auth.settings.verify_email_next = auth.settings.request_reset_password_next ='/app/default/login' Is this a good technique or keep vars=value on the same line? I think your instinct that this isn't quite right (at least stylistically) is sound. I don't think you really gain anything over just assigning it twice: auth.settings.verify_email_next = '/app/default/login' auth.settings.request_reset_password_next = '/app/default/login' Or, if that doesn't satisfy: auth.settings.verify_email_next = '/app/default/login' auth.settings.request_reset_password_next = auth.settings.verify_email_next Or even loginpage = '/app/default/login' auth.settings.verify_email_next = loginpage auth.settings.request_reset_password_next = loginpage (BTW, don't you want to use URL() here?) -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] settting two vars to same text
On Jan 15, 2010, at 2:42 PM, Wes James wrote: hmm - yes... maybe: login_page = URL(r=request,c='default',f='login') auth.settings.verify_email_next = login_page auth.settings.request_reset_password_next = login_page Right. That has the additional advantage that routes.py gets to see it. thx, -wes On Fri, Jan 15, 2010 at 3:37 PM, Jonathan Lundell jlund...@pobox.com wrote: On Jan 15, 2010, at 2:26 PM, Wes James wrote: This seems to work, but is there a better way to set some vars to the same value? auth.settings.verify_email_next = auth.settings.request_reset_password_next ='/app/default/login' Is this a good technique or keep vars=value on the same line? I think your instinct that this isn't quite right (at least stylistically) is sound. I don't think you really gain anything over just assigning it twice: auth.settings.verify_email_next = '/app/default/login' auth.settings.request_reset_password_next = '/app/default/login' Or, if that doesn't satisfy: auth.settings.verify_email_next = '/app/default/login' auth.settings.request_reset_password_next = auth.settings.verify_email_next Or even loginpage = '/app/default/login' auth.settings.verify_email_next = loginpage auth.settings.request_reset_password_next = loginpage (BTW, don't you want to use URL() here?) -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
[web2py] jQuery to Zoho
Some of you may have gotten a message like this today. I pass it along a) because the subject of GGroups has been a topic here, and b) because of the note about their having moved all their old discussions to the new system, a big plus. OTOH, I have no experience at all with Zoho The jQuery Project is finally moving away from Google Groups for having general jQuery-related discussions. You can read a bit more about our decision to move away from Google Groups here: http://ejohn.org/blog/google-groups-is-dead Over many months of analysis of existing solutions we've set up a a brand new discussion and question-answer forum, using Zoho Discussions: http://forum.jquery.com With help from the Zoho team we've imported all of the existing Google Groups discussions and the old jQueryHelp.com forum posts. We've also set up an account for you in the new system so that you can get started right away. -- You received this message because you are subscribed to the Google Groups "web2py-users" group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
[web2py] urlify
urlify needs a comment to say explicitly what its intention is. That's partly
because it suppresses quite a few characters that are normally legal in URLs,
which is confusing.
Also,
def urlify(s, max_length=80):
s = s.lower()
# string normalization, eg è = e, ñ = n
s = unicodedata.normalize('NFKD', s.decode('utf-8')).encode('ASCII',
'ignore')
# strip entities
s = re.sub('\w+;', '', s)
this should be '\w+?;' (that is, non-greedy). Otherwise, a string like
'amp;whateveramp;' will be completely eliminated.
# strip everything but letters, numbers, dashes and spaces
s = re.sub('[^a-z0-9\-\s]', '', s)
# replace spaces with dashes
s = s.replace(' ', '-')
# strip multiple contiguous dashes
s = re.sub('-{2,}', '-', s)
# strip dashes at the beginning and end of the string
s = s.strip('-')
# ensure the maximum length
s = s[:max_length-1]
return s
(Stylistically, I think it'd be more readable if the comments were appended to
the relevant code lines.)
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: urlify
On Jan 24, 2010, at 8:30 AM, mdipierro wrote:
I will take a patch. ;-)
I'll contribute one. Any objection to changing the name to slugify, since
it's not really urlifying its input?
On Jan 23, 7:03 pm, Jonathan Lundell jlund...@pobox.com wrote:
urlify needs a comment to say explicitly what its intention is. That's
partly because it suppresses quite a few characters that are normally legal
in URLs, which is confusing.
Also,
def urlify(s, max_length=80):
s = s.lower()
# string normalization, eg è = e, ñ = n
s = unicodedata.normalize('NFKD', s.decode('utf-8')).encode('ASCII',
'ignore')
# strip entities
s = re.sub('\w+;', '', s)
this should be '\w+?;' (that is, non-greedy). Otherwise, a string like
'amp;whateveramp;' will be completely eliminated.
# strip everything but letters, numbers, dashes and spaces
s = re.sub('[^a-z0-9\-\s]', '', s)
# replace spaces with dashes
s = s.replace(' ', '-')
# strip multiple contiguous dashes
s = re.sub('-{2,}', '-', s)
# strip dashes at the beginning and end of the string
s = s.strip('-')
# ensure the maximum length
s = s[:max_length-1]
return s
(Stylistically, I think it'd be more readable if the comments were appended
to the relevant code lines.)
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: urlify
On Jan 24, 2010, at 9:14 AM, mdipierro wrote:
Since you are at it. We may want to consider a IS_SLUG validator and
make the function a staticmethod of IS_SLUG (instead of a function in
contrib) so it can be called without any import from contrib.
OK.
On Jan 24, 11:12 am, mdipierro mdipie...@cs.depaul.edu wrote:
No objection. It is not in stable it.
On Jan 24, 10:55 am, Jonathan Lundell jlund...@pobox.com wrote:
On Jan 24, 2010, at 8:30 AM, mdipierro wrote:
I will take a patch. ;-)
I'll contribute one. Any objection to changing the name to slugify, since
it's not really urlifying its input?
On Jan 23, 7:03 pm, Jonathan Lundell jlund...@pobox.com wrote:
urlify needs a comment to say explicitly what its intention is. That's
partly because it suppresses quite a few characters that are normally
legal in URLs, which is confusing.
Also,
def urlify(s, max_length=80):
s = s.lower()
# string normalization, eg è = e, ñ = n
s = unicodedata.normalize('NFKD', s.decode('utf-8')).encode('ASCII',
'ignore')
# strip entities
s = re.sub('\w+;', '', s)
this should be '\w+?;' (that is, non-greedy). Otherwise, a string like
'amp;whateveramp;' will be completely eliminated.
# strip everything but letters, numbers, dashes and spaces
s = re.sub('[^a-z0-9\-\s]', '', s)
# replace spaces with dashes
s = s.replace(' ', '-')
# strip multiple contiguous dashes
s = re.sub('-{2,}', '-', s)
# strip dashes at the beginning and end of the string
s = s.strip('-')
# ensure the maximum length
s = s[:max_length-1]
return s
(Stylistically, I think it'd be more readable if the comments were
appended to the relevant code lines.)
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: urlify
On Jan 24, 2010, at 9:53 AM, mdipierro wrote:
I do not know about this. What do other people think?
I do not have a strong opinion either way.
I think that slug is a fairly common term. WordPress uses it, for example.
And if we make it a validator (I'm about to submit a patch), it definitely
can't be IS_URL().
On Jan 24, 11:34 am, pistacchio pistacc...@gmail.com wrote:
I'm ok with slugify, but the reason i chose urlify is that slug is
not really a mvc term. It comes from the journalistic jargon and it's
been adopted by the original Django developers that were working on a
framework to build a newspaper site on.
I don't think that slug, outside the Django community, is a standard
term to name such url-friendly strings. More often they're referred to
as pretty urls.
On 24 Gen, 17:55, Jonathan Lundell jlund...@pobox.com wrote:
On Jan 24, 2010, at 8:30 AM, mdipierro wrote:
I will take a patch. ;-)
I'll contribute one. Any objection to changing the name to slugify, since
it's not really urlifying its input?
On Jan 23, 7:03 pm, Jonathan Lundell jlund...@pobox.com wrote:
urlify needs a comment to say explicitly what its intention is. That's
partly because it suppresses quite a few characters that are normally
legal in URLs, which is confusing.
Also,
def urlify(s, max_length=80):
s = s.lower()
# string normalization, eg è = e, ñ = n
s = unicodedata.normalize('NFKD', s.decode('utf-8')).encode('ASCII',
'ignore')
# strip entities
s = re.sub('\w+;', '', s)
this should be '\w+?;' (that is, non-greedy). Otherwise, a string like
'amp;whateveramp;' will be completely eliminated.
# strip everything but letters, numbers, dashes and spaces
s = re.sub('[^a-z0-9\-\s]', '', s)
# replace spaces with dashes
s = s.replace(' ', '-')
# strip multiple contiguous dashes
s = re.sub('-{2,}', '-', s)
# strip dashes at the beginning and end of the string
s = s.strip('-')
# ensure the maximum length
s = s[:max_length-1]
return s
(Stylistically, I think it'd be more readable if the comments were
appended to the relevant code lines.)
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group
athttp://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: urlify
On Jan 24, 2010, at 11:05 AM, mdipierro wrote:
That's a good point.
I also think the IS_SLUG should not do validation, just filtering. Or
perhaps have an option to
The patch I sent is filtering-only, sort of a super IS_LOWER().
The main use for it in a form, I think, is to combine IS_SLUG with
IS_NOT_IN_DB, since slugs want to be unique.
def IS_SLUG():
def __init__(check=False,error_message=):
self.check=check
self.error_message=error_message
@staticmethod
def slugify(value):
...
def __call__(self,value):
if check and not value==self.sugify(value):
return (value,self.error_message)
return (self.slugify(value),None)
On Jan 24, 12:39 pm, Jonathan Lundell jlund...@pobox.com wrote:
On Jan 24, 2010, at 9:53 AM, mdipierro wrote:
I do not know about this. What do other people think?
I do not have a strong opinion either way.
I think that slug is a fairly common term. WordPress uses it, for example.
And if we make it a validator (I'm about to submit a patch), it definitely
can't be IS_URL().
On Jan 24, 11:34 am, pistacchio pistacc...@gmail.com wrote:
I'm ok with slugify, but the reason i chose urlify is that slug is
not really a mvc term. It comes from the journalistic jargon and it's
been adopted by the original Django developers that were working on a
framework to build a newspaper site on.
I don't think that slug, outside the Django community, is a standard
term to name such url-friendly strings. More often they're referred to
as pretty urls.
On 24 Gen, 17:55, Jonathan Lundell jlund...@pobox.com wrote:
On Jan 24, 2010, at 8:30 AM, mdipierro wrote:
I will take a patch. ;-)
I'll contribute one. Any objection to changing the name to slugify,
since it's not really urlifying its input?
On Jan 23, 7:03 pm, Jonathan Lundell jlund...@pobox.com wrote:
urlify needs a comment to say explicitly what its intention is. That's
partly because it suppresses quite a few characters that are normally
legal in URLs, which is confusing.
Also,
def urlify(s, max_length=80):
s = s.lower()
# string normalization, eg è = e, ñ = n
s = unicodedata.normalize('NFKD',
s.decode('utf-8')).encode('ASCII', 'ignore')
# strip entities
s = re.sub('\w+;', '', s)
this should be '\w+?;' (that is, non-greedy). Otherwise, a string like
'amp;whateveramp;' will be completely eliminated.
# strip everything but letters, numbers, dashes and spaces
s = re.sub('[^a-z0-9\-\s]', '', s)
# replace spaces with dashes
s = s.replace(' ', '-')
# strip multiple contiguous dashes
s = re.sub('-{2,}', '-', s)
# strip dashes at the beginning and end of the string
s = s.strip('-')
# ensure the maximum length
s = s[:max_length-1]
return s
(Stylistically, I think it'd be more readable if the comments were
appended to the relevant code lines.)
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: Serious issue with upgrading to latest version
On Jan 26, 2010, at 10:19 AM, mdipierro wrote: Than it bust be an application bug. I think you may have a IS_DATE validator on a 'string' field instead of a 'date' field. You also need to move over the new appadmin(s) into your app. Normally this is not required during upgrades since they become part of your app. Nevertheless there was an issue with very early appadmin that was fixed and may be causing the last one of your problems. I'm probably repeating myself here, but is appadmin a plugin candidate? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: SQLFORM generating duplicate ids in HTML
On Jan 27, 2010, at 11:45 AM, mdipierro wrote: I agree it is a bug that ids may not be unique. Yet fixing this will break backward compatibility. Perhaps we can add the same strings to the class attribute without breaking backward compatibility but we should not remove them from id. What do people think? It's better than not doing it. But duplicate IDs is bad. If you serve an xhtml page as xhtml (rather than as html), and it has duplicate IDs, the browser will not display it. Period. I question whether backward compatibility needs to extend to propagating bugs. On Jan 27, 1:36 pm, Jeremy Dillworth jdillwo...@gmail.com wrote: Thanks. But I wasn't too concerned about ambiguity in the CSS. I was more concerned about there being duplicate IDs in the DOM. The w3c HTML validator flags this kind of thing as a problem. As far as I know it doesn't create a problem in any current browser (other than making document.getElementById useless), but since these IDs are only used for CSS, wouldn't it be safer to move these labels into the class attributes and modify the default stylesheets as needed? Thanks Jeremy -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: SQLFORM generating duplicate ids in HTML
On Jan 27, 2010, at 2:30 PM, Thadeus Burgess wrote: if it was defaulted to None we could go if _id == None then id = tablename else id = _id Id accept that, just set a unique id for each of my forms and nothing will conflict and it will still keep good with old apps. And _id = False for no id at all. It's not that it isn't useful to put all of them into the same class; it's that class is the right way to do it, rather than id. -Thadeus On Wed, Jan 27, 2010 at 4:27 PM, Wes James compte...@gmail.com wrote: Why not: form1=SQLFORM(..., _id=what_you_want) -wes On Wed, Jan 27, 2010 at 7:31 AM, mdipierro mdipie...@cs.depaul.edu wrote: The ids are only used for CSS. you can do form1=SQLFORM(...,_class='form1') form1.accepts(request.post_vars,formname=None) form2=SQLFORM(...,_class='form2') form2.accepts(request.post_vars,formname=None) return dict(form1=form1,form2=form2) and you can use the class to refer to the id of the first or the second in CSS. There should be no ambiguity. Massimo snip -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: SQLFORM generating duplicate ids in HTML
On Jan 27, 2010, at 5:07 PM, Thadeus Burgess wrote:
Doesn't javascript input serialization expect to look the field up by id?
There's nothing *wrong* with having an id; it just needs to be unique on the
page.
it should be
form = id = formname class=formname:
input:
class = formname
id = formname_field
#formname input { ... }
#formname #formname_users_email { ... }
#formname .formname { ... }
This would give a lot more flexibility from both a CSS design and a UI
design using jquery selection.
-Thadeus
On Wed, Jan 27, 2010 at 5:12 PM, Jonathan Lundell jlund...@pobox.com wrote:
On Jan 27, 2010, at 2:30 PM, Thadeus Burgess wrote:
if it was defaulted to None we could go
if _id == None then id = tablename else id = _id
Id accept that, just set a unique id for each of my forms and nothing
will conflict and it will still keep good with old apps.
And _id = False for no id at all.
It's not that it isn't useful to put all of them into the same class; it's
that class is the right way to do it, rather than id.
-Thadeus
On Wed, Jan 27, 2010 at 4:27 PM, Wes James compte...@gmail.com wrote:
Why not:
form1=SQLFORM(..., _id=what_you_want)
-wes
On Wed, Jan 27, 2010 at 7:31 AM, mdipierro mdipie...@cs.depaul.edu wrote:
The ids are only used for CSS. you can do
form1=SQLFORM(...,_class='form1')
form1.accepts(request.post_vars,formname=None)
form2=SQLFORM(...,_class='form2')
form2.accepts(request.post_vars,formname=None)
return dict(form1=form1,form2=form2)
and you can use the class to refer to the id of the first or the
second in CSS. There should be no ambiguity.
Massimo
snip
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: format zero IS_IN_DB
Yes, the option is important. But the case for a default of None is
pretty convincing.
On 1/29/10, mdipierro mdipie...@cs.depaul.edu wrote:
Let's hear a few more opinions. I don't just want to say no. The
problem is that we had this discussion already and people insisted
such option should be there.
Massimo
On Jan 29, 9:31 am, DenesL denes1...@yahoo.ca wrote:
I must insist.
The point is that IS_IN_DB and IS_IN_SET now show a spurious empty
option by default.
The keyword here is default.
If you want to introduce a 'choose a value option you should do it
explicitly and 'at your own risk', the risk being that it creates an
option that when selected will cause an error.
An empty option is plainly wrong, it is not part of the IS_IN_DB or
IS_IN_SET options. It is completely artificial.
How many times the option has been changed should not matter, getting
it right should.
Denes.
On Jan 29, 10:06 am, mdipierro mdipie...@cs.depaul.edu wrote:
There is no way to please everybody here. some people ask for
zero=None, some for zero='', some for zero='Please choose a value'.
There is no right or wrong. I think we should leave the default as is
('', we changed it twice already) and you configure it as needed.
Massimo
On Jan 29, 9:00 am, DenesL denes1...@yahoo.ca wrote:
bump
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py] routes.py SUCKS
On Jan 29, 2010, at 9:17 AM, Tamas wrote: I would like to tackle the simple task of running web2py on a folder of the website, say http://example.org/w2p/ So that an application will be like http://example.org/w2p/example/default/index Setting up the WSGI handler is easy, however routes.py gives me a hard time. I tried a bunch of versions, but none seemed to work. Can someone help out? This should be really easy, but it isn't! One thing that might help: I added a doctest section to routes.example.py. The intention is that you can use it to see what your modified routes.py is actually doing (you need to edit the doctest accordingly, of course). -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] response.postprocessing
On Jan 29, 2010, at 1:16 PM, Thadeus Burgess wrote: Maybe its just me and I need to look harder but I can't find where web2py calls this... at all run_controller_in() (in compileapp.py) -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: has anybody check the the cron in trunk?
On Jan 30, 2010, at 1:40 PM, mdipierro wrote:
The problem is when paths contain spaces.
I thought even in windows in this case one should esacpe spaces with
'\ ' and use either \\ ('' in python) or / ('/') to separate
folders. For example:
'C:/windows/Documents\ and\ Settings/'
or
'C:\\windows\\Documents\ and\ Settings\\'
Am I wrong?
I think so, but I'm no expert on the subject.
Consider that if 'c:\\abc' makes Windows see 'c:\abc', then escaping the space
isn't going to have any effect.
You can quote a command on the command line, so possibly something like:
'C:\\windows\\Documents and Settings\\'
might work. Forward slashes are permitted in system calls, but IIRC not on the
command line, where (at least back in the DOS days) they denoted command
options (equivalent to - in Unix). I'd expect cron entries to be more like
command-line or batch-file content.
But as I say, I'm no expert.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py] jquery tools
On Jan 30, 2010, at 2:57 PM, mdipierro wrote: This could be useful. Perhaps we should consider rewriting examples using this http://flowplayer.org/tools/index.html It looks very, very nice. One concern, though, is this from their front page: Let's face it: do you really need drag-and-drop, resizable windows or sortable lists in your web applications? Websites are not desktop applications. They are different. It seems to me that sortable lists (or tables) is exactly the kind of thing a web2py application is likely to need, and drag drop could be useful as well. It'd be nice to see a good table widget integrated into web2py, I think, since it's a natural complement to database work. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: has anybody check the the cron in trunk?
On Jan 31, 2010, at 11:20 AM, Brian M wrote: Yes, that mostly fixes things. However, you still need an explicit test for the @reboot or it won't ever run, check won't have a -1 minute in it. I am testing out a modified cron.py with all of the fixes we've covered in this thread plus the checks for whether or not a task should be run split into its own function for a bit better clarity. I will send you a diff after I've had a chance to test everything on linux. Right now Windows seems to be working pretty well. A cosmetic matter (for now, anyway). cron.py says # crontype can be 'soft', 'hard', 'external', None but widget.py says contrib.cron.crontype = 'External' For now, anyway, it appears that crontype is either 'soft' or not, as far as the logic is concerned. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] CMS content upload
On Jan 31, 2010, at 1:17 PM, weheh wrote: Anybody know of such a markup language and its associated python module? (I know python has an html parser and I could block all tags other than a select few, but thought I'd ask in case there's a better answer out there.) How about markdown (in gluon/contrib)? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: DAL migration problem
On Feb 2, 2010, at 9:31 AM, Thadeus Burgess wrote: Actually, we can use the Adaptors to hold specific keywords. So in DAL.__init__ can have for fields if fieldname in self._adapter.KEYWORDS then raise SyntaxError It's be nice to have a way to take advantage of the keyword lists in Adapters that you're not necessarily using. Say I'm developing with SQLite with the intention of moving to MySQL in production; I'd like to be testing against MySQL keywords from the beginning, to avoid nasty surprises later. I'm not sure what it'd look like; I'd settle for a strict name check that used the union of all the keywords. I assume that's not practical, though, if the lists are in unused Adapters? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: DAL migration problem
On Feb 2, 2010, at 12:48 PM, Thadeus Burgess wrote: You can view a proposed change, I have sent this to Massimo to look at. http://code.google.com/r/thadeusburgess-web2py/source/detail?r=e875496cc5978200fb6c0aa0f85a8df1a945df21 I'm not sure what keywords we really want to use or not, but this is a starting point. I added two lists to BaseAdapter global. KEYWORDS_ALL and KEYWORDS_COMMON. My thought is that no tablename or column name should pass through KEYWORDS_COMMON, then KEYWORDS_ALL can be used to check integration with other database types. So if it is in KEYWORDS_ALL just log a warning. Then each adapter will have their own set of reserved words that will be stored in a list named KEYWORDS. So a tablename or column name will fail if it is in either KEYWORDS_COMMON or KEYWORDS, and will send a warning if it is in KEYWORDS_ALL. I think this could go into sql.py as just fail on KEYWORDS_COMMON and warn on KEYWORDS_ALL, and then the new dal will break it down by database specifics. What do you think? I think it's a pretty good start. A couple of nits, though. 1. The test ought to be encapsulated somewhere, presumably in dal.py, so you're not repeating the logic so many places. 2. I'm not so sure about logging a warning; seems like it'd be noisy. Could it maybe be a property of a table that defaults to COMMON but can be set to ALL at table-creation time? Or something like that? I probably don't care about making the test in production, after all. 3. KEYWORDS_COMMON as a name: I assume you mean keywords that are commonly reserved? It also suggests keywords that are common to all adapters. Regardless, it's ambiguous; at the very least the criteria for inclusion should be documented in comments with the lists. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: DAL migration problem
On Feb 2, 2010, at 1:19 PM, Thadeus Burgess wrote:
1. Its only in two places. Once for tablename, and once for fieldname.
And then this needs to be done for sql.py just in case
DRY
2. Yes very chatty. What about the following?
DAL('sqlite', pool_size=1, check_reserve=None)
DAL('sqlite', pool_size=1, check_reserve='common')
DAL('sqlite', pool_size=1, check_reserve='all')
DAL('sqlite', pool_size=1, check_reserve='postgres')
DAL('sqlite', pool_size=1, check_reserve='mssql')
This way we can define the level of check. Then the check will be
placed in a function of db. db._verify_reserved_keyword(keyword) which
will perform the checks based on the self.check_reserve.
None would be no name checking, to keep backwards compatibility and
for production systems. comments?
Makes sense. How about accepting a list?
3. How is it ambiguous, you hit the definition right on target. Its
common SQL commands that without these commands you don't have SQL,
and if you use one of these terms in the current system you get an
OperationalError anyways.
OK...
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
[web2py] Lulu sale
In case anyone is about to buy a copy of the manual from Lulu, there's a 15% discount through tomorrow. Coupon code SHADOW. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: how to restore corrupted .table files?
On Feb 2, 2010, at 3:09 PM, Richard wrote:
hmm, can't find make_migrate anywhere, even in trunk...although I
saw it discussed in another thread.
It's fake_migrate.
On Feb 3, 1:42 am, mdipierro mdipie...@cs.depaul.edu wrote:
Do you have a custom auth_table?
If so you can do:
db.define_table('auth_table',,migarte=False,make_migrate=True)
Then you have to check in SQL that all columns you expect are there.
massimo
On Feb 2, 2:56 am, Richard richar...@gmail.com wrote:
Some of my .table files have become corrupted, so that I get this
error:
Traceback (most recent call last):
File web2py/gluon/restricted.py, line 178, in restricted
exec ccode in environment
File web2py/applications/studio09/models/db.py, line 165, in
module
Field('video', db.media),
File web2py/gluon/sql.py, line 1033, in define_table
query = t._create(migrate=migrate)
File web2py/gluon/sql.py, line 1393, in _create
sql_fields_old = cPickle.load(tfile)
EOFError
However if I remove the .table files then I get this error:
Traceback (most recent call last):
File web2py/gluon/restricted.py, line 178, in restricted
exec ccode in environment
File web2py/applications/studio09/models/db.py, line 28, in
module
Field('registration_key', length=128, readable=False,
writable=False, default=''),
File web2py/gluon/sql.py, line 1033, in define_table
query = t._create(migrate=migrate)
File web2py/gluon/sql.py, line 1368, in _create
self._db._execute(query)
File web2py/gluon/sql.py, line 704, in lambda
self._execute = lambda *a, **b: self._cursor.execute(*a, **b)
OperationalError: table auth_user already exists
Is there a way to restore my .table files without having to export my
data, drop the tables, and then reimport later?
thanks,
Richard
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py] making changes in web2py
On Feb 3, 2010, at 9:09 AM, Thadeus Burgess wrote: if you already have a clone, make your changes, then commit them to your local copy. When you want updates do hg pull web2py hg merge It should update and leave your changes, unless there is a conflict which you will need a program such as MELD to solve. It'd be nice to have a slice or wiki page or something on hg+web2py. Commands, workflow, hints--since most of us are relatively new to hg. Ideally, not just the commands, but some explanation of what's going on. -Thadeus On Wed, Feb 3, 2010 at 11:02 AM, Wes James compte...@gmail.com wrote: Say I do: hg clone web2py I make changes to the code, then later another update comes out for web2py and I want my changes added to the update. Can someone help me with this process? thx, -wes -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] making changes in web2py
On Feb 3, 2010, at 9:19 AM, Thadeus Burgess wrote: What is wrong with http://mercurial.selenic.com/guide/ There is nothing special about hg+web2py together. I was hoping for something a little more concise, and also some guidance for how to use my own clones (or whatever) on Google Code. We've talked a little about code review, and it seems to me that making use of personal repositories on GCode would facilitate that. But when I tried to do it a few weeks ago, I got confused and messed it up. The use cases I'm thinking of: * a developer (you, me, whoever) pushes a proposed change to their public repository and posts a link (whatever) here for review * Massimo pulls the change from that repository, rather than our having to try to pass around patches by email. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] making changes in web2py
On Feb 3, 2010, at 9:38 AM, Thadeus Burgess wrote: Massimo seems to prefer emailing patches rather than pulling from our cloned repositories. Since he wants exact specific control over what gets pulled in. Kind of like quality control until he trusts the developer I suppose :) Linus Torvalds also prefers this approach of diffs instead of clones for these very same reasons, so its understandable. Web2py is his baby and nothing should come to harm it :) Aren't diffs available as well, under that scenario? (Actually, Linus does take pulls, but he doesn't integrate them blindly.) -Thadeus On Wed, Feb 3, 2010 at 11:29 AM, Jonathan Lundell jlund...@pobox.com wrote: ssimo pulls the change from that repository, rather than our having to try to pass around patches by em -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: DAL migration problem
On Feb 3, 2010, at 9:43 AM, Thadeus Burgess wrote: Ok take a look at the following proposed changes I'll try to look at it later today; I'm off to work now. Is the check made every time, or only when a table is actually being created (or migrated)? The latter should be adequate, at least by default, and would have less impact on performance. A side thought: the lists probably ought to be frozensets, not arrays, for performance. And KEYWORDS_ALL ought to be a union (calculated once) of the other sets. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: making changes in web2py
On Feb 3, 2010, at 9:38 PM, Thadeus Burgess wrote: -1 for admin username +1 for anti-brute-forcing. If incorrect password typed 3 times, ban the IP permanently until you log into ssh and edit a pickled file. We had a longish thread on this general subject a while back. I could probably find it, but I recall that the other alternative that was discussed was a rate limiter for password attempts. Any reason why something like that couldn't apply to regular logins as well? I don't think you'd want to use IP banning for user logins. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: admin app misses symlinked directories
On Feb 4, 2010, at 7:01 AM, mdipierro wrote: Could be that isdir returns false on symlinked directories? form admin/ controller/default.py if os.path.exists(aviewpath): if os.path.isdir(aviewpath): viewlist = glob(os.path.join(aviewpath,'*.html')) http://docs.python.org/library/os.path.html os.path.isdir(path) Return True if path is an existing directory. This follows symbolic links, so both islink() and isdir() can be true for the same path. On Feb 4, 7:37 am, selecta gr...@delarue-berlin.de wrote: you can test this for yourself with thishttp://groups.google.com/group/web2py/browse_thread/thread/d10bf589cc... click on a plugin to manage it, test the plugin, it will still work but e.g. the views will not be visible in the admin design interface On Feb 4, 1:13 pm, selecta gr...@delarue-berlin.de wrote: Ubuntu 9.10 \n \l web2py Version 1.74.11 (2010-02-03 10:53:34) yes i made sure the case is correct and it must be since the application works just to be clear, symlinked files are not a problem (app works, and displayed in admin app designer) symlinked directories have problems (app works, not displayed in admin app designer) On Feb 4, 2:04 am, mdipierro mdipie...@cs.depaul.edu wrote: what os? make sure the case is correct On Feb 3, 3:17 pm, selecta gr...@delarue-berlin.de wrote: If i replace a directory with a symlink the application works fine buthttp://127.0.0.1:8000/admin/default/design/testisnotshowingthe symlinked directory e.g. in application test I symlinked the views/default directory inhttp://127.0.0.1:8000/admin/default/design/testitislookinglike there are no views for the default controller at all the good news is that the application is running just fine with the symlinked directory It is important that this works for the current application that I am writing. It is a PluginMangerhttp://jaguar.biologie.hu-berlin.de/~fkrause/PluginManager.png -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: format zero IS_IN_DB
On Feb 4, 2010, at 7:08 AM, mdipierro wrote: I do not really have an opinion on this. I am only reluctant to changes in behavior. Anyway, I am prepared to make this change (zero=None by default). I would like to know that all major contributors are on board so that you can answer the emails when users complain instead of me. ;-) Anybody who has an opinion about this should post here or email me personally. I prefer zero=None as the default, on the grounds that it seems more logical for the default case to not include items that aren't actually in the database. Least surprise. OTOH, it's not a high priority for me, since it's easy enough to override either way. Executive Summery: There is a proposal to default IS_IN_SET(zero=None) and IS_IN_DB(zero=None) so that dropdown select option NO LONGER will have a default black option. Currently, by default, when you create a new record the blank option is selected and, if you do not change it and if you do not allow IS_NULL, you get an error message. With the proposed change, when you create a new record all select/options will - by default - select the first alphabetical value unless you change it. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: DAL migration problem
On Feb 3, 2010, at 9:43 AM, Thadeus Burgess wrote:
Ok take a look at the following proposed changes
Comments.
* Could we use 'check_reserved' instead of 'check_reserve'? It sounds more
natural to me.
* Capitalize SQL in the error message strings
* dal.py is already much too long. Could the wordlists live somewhere else?
* Is 'print' the most appropriate way to show the warning message? How about at
least sending it to stderr, or see the next point:
* I don't entirely get the rationale for the distinction between the warning
message and raising a syntax error, at least not based on the selected list.
Since this is intended for development, not production, why not just make it a
syntax error and be done with it? Or if it's important, make it a separate
option.
* I remain uneasy about the idea of doing this on every call (vs calls that
make actual changes in the db). I don't know what the performance overhead is
of the lookup (I suspect that frozenset would be faster--at the very least
something immutable), so maybe it's a non-concern. I'm also uneasy about
proliferating flags that you have to remember to turn off for production; it's
too easy to forget about once it's working.
http://code.google.com/r/thadeusburgess-web2py/source/detail?r=c416459252755abde998e923021188335924e02c
I made it DRY. Also you pass a list of options. Here is example usage
db = DAL('sqlite', pool_size, check_reserve=['common',
'postgres', 'mysql'])
check_reserve is a list of backends to use, with two extra terms 'all'
and 'common'. It defaults to None, which performs no check.
If you set common, it will check the KEYWORDS_COMMON list, and throw a
SyntaxError.
If you set all, it will check the KEYWORDS_ALL list, and print a
warning message.
If you set an adapter name, it will check the adapters KEYWORDS and
throw a SyntaxError.
This only effects the new dal, (dal.py) since i do not have time to
implement this for sql.py.
As Jonathan Lundell suggests in his mercurial post, you can code
review this change. Once we are happy, Massimo can pull the changes
in.
-Thadeus
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: format zero IS_IN_DB
On Feb 4, 2010, at 7:34 AM, mdipierro wrote: Mind that currently zero='' should be interpreted as zero='(please choose a value)'. the value '' is not in the db and will not pass validation. It s just a place holder. Only if IS_NULL_OR(IS_IN_DB(...zero='')) then the value '' can pass validation. Right, and it's a very useful mode. I think I see (vaguely) the source of the tension. zero='' is the most natural behavior for many (most?) forms, from a UI logic point of view. zero=None is the most natural logic from the POV of data access: it gives us the list that actually is in the set/db, and nothing more. I don't think that either flavor of naturalness is most natural. Which is why I don't care that much how it goes; I'll probably adopt a practice of coding it explicitly regardless. So you can count me as neutral if you like. BTW, an off-topic question: is there a straightforward way to prepopulate a form with an existing database row? I know, I should RTFM On Feb 4, 9:25 am, Jonathan Lundell jlund...@pobox.com wrote: On Feb 4, 2010, at 7:08 AM, mdipierro wrote: I do not really have an opinion on this. I am only reluctant to changes in behavior. Anyway, I am prepared to make this change (zero=None by default). I would like to know that all major contributors are on board so that you can answer the emails when users complain instead of me. ;-) Anybody who has an opinion about this should post here or email me personally. I prefer zero=None as the default, on the grounds that it seems more logical for the default case to not include items that aren't actually in the database. Least surprise. OTOH, it's not a high priority for me, since it's easy enough to override either way. Executive Summery: There is a proposal to default IS_IN_SET(zero=None) and IS_IN_DB(zero=None) so that dropdown select option NO LONGER will have a default black option. Currently, by default, when you create a new record the blank option is selected and, if you do not change it and if you do not allow IS_NULL, you get an error message. With the proposed change, when you create a new record all select/options will - by default - select the first alphabetical value unless you change it. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: DAL migration problem
On Feb 4, 2010, at 8:19 AM, Thadeus Burgess wrote: * Could we use 'check_reserved' instead of 'check_reserve'? It sounds more natural to me. Why not. * Capitalize SQL in the error message strings It is capitalized. raise SyntaxError, 'invalid name \'%s\': is a \'common\' reserved sql keyword' % name * dal.py is already much too long. Could the wordlists live somewhere else? No, they belong with their relative adapters. Object Oriented devel at its best. I was thinking of COMMON ALL. * Is 'print' the most appropriate way to show the warning message? How about at least sending it to stderr, or see the next point: * I don't entirely get the rationale for the distinction between the warning message and raising a syntax error, at least not based on the selected list. Since this is intended for development, not production, why not just make it a syntax error and be done with it? Or if it's important, make it a separate option. here is my rational. the reason for displaying an error is because the KEYWORDS_ALL contains all known sql keywords. Therefore it contains keywords that might not necessarily effect your deployment, so it shouldn't stop the software from running, but at least log a warning letting you know so that you can change it if you want. Sure we can print to stderr. KEYWORDS_ALL is a placeholder until we devote the time to creating adapter specific lists. In fact once each adapter has their own list KEYWORDS_ALL probably won't exist any more, and the `all` option will use a union of all the lists. You said it yourself, you don't want more proliferating flags, so no separate option. However if anyone else has an opinion on the matter? Here's my argument for always a syntax error: why not stop it from running? Once I get the error, I'm either going to turn off the check, or fix the error. I'm not going to leave it logging any more than I'll leave it raising an exception, since it's going to log on every request. (BTW, if I'm developing through the GUI, where do I see the prints?) * I remain uneasy about the idea of doing this on every call (vs calls that make actual changes in the db). I don't know what the performance overhead is of the lookup (I suspect that frozenset would be faster--at the very least something immutable), so maybe it's a non-concern. I'm also uneasy about proliferating flags that you have to remember to turn off for production; it's too easy to forget about once it's working. I don't understand what you are so concerned about the performance overhead (like a fraction of a fraction of a fraction of a tiny fraction of a nanosecond that it takes?) If it takes less than a nanosecond, then I have no concern at all. (You must have a very fast Python interpreter.) Let me qoute you again Since this is intended for development, not production... ...I made my case, as long as check_reserved is set to None it won't do the check. (None is the default) And about the flags... you have to change many other options when moving into deployment (such as db connection string to the DAL... which ill be damned if its not in the same constructor as this flag). So let me get this straight, you want the option to target multiple database types that YOU want... but what..., web2py is supposed to play God and read your mind? How else would web2py determine what target backends you are looking for. I don't think I follow you here. Then you raise a good point, there is no sense in adding a flag just for one option, perhaps a better name such as ``target_adapters=[]`` instead of check_reserve. That way the list could be used for multiple purposes that might arise in the future. such as higher compatibility layers that check joins vs. pagination etc. Sure. A nit: our target isn't an adapter, it's the database variant. Adapters don't have keywords; databases do. If you take my meaning. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: DAL migration problem
On Feb 4, 2010, at 9:02 AM, Thadeus Burgess wrote: 1. I do not capitalize name because this is actually what you are attempting to call your column, it could be 'select', 'Select', 'SELect'. It just seemed more logical to display the name that you wrote. Though it can be capitalized. I thought you were referring to the name of the database it was part of. I'm not sure what you're replying to here. I was suggesting changing the literal string 'sql' to 'SQL'. 2. Yes, but then you wouldn't be able to do self._adapter.KEYWORDS_COMMON or db._adapter.KEY I don't see a reason for the following either, adding yet another import to web2py... (though I agree, I don't like how long dal/sql.py is either) # pseudocode class BaseAdapter(..): KEYWORDS_COMMON = from keywords import KEYWORDS_COMMON Perhaps the long-term solution is to look at how dal.py could be modularized. 3. Good point, I agree, SyntaxError it is. 4. Its no different than the if if hasattr(self,tablename) or tablename[0] == '_': and if tablename in self.tables: checks that already exist there. I'm conjecturing that testing against a long mutable array is expensive. I could be wrong, of course. 5. You say that you don't want to proliferate more flags into the web2py environment. I ask, how then would you know what database you want to check against? Ah, I see. No, that's not my point. My point is not proliferation of options in general; it's proliferation of options that need to be changed for production. It's not that hard to work around, of course; I can always define a global production flag. 6. So all in support for target_databases for the name instead of check_reserved? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: DAL migration problem
On Feb 4, 2010, at 11:08 AM, Thadeus Burgess wrote: Ok I get what you mean on changing sql to SQL. Misunderstanding, I thought you ment the keyword that was being thrown off. It will be an immutable array (tuple). The bracket just slipped in there :P Any ideas you could share on modularizing dal.py that could allow this to be in another file? Sadly, no. Where it really jumps out at me is looking at the diffs on Google Code; it ends up being a very long page. And I didn't notice a way to find the next diff except for scrolling (not that I looked very hard). -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: Updating contents of plugin_datatable via Ajax?
Speaking of plugin_datatable, the example at http://www.web2py.com/plugins/default/datatable looks v. messed up via Safari and Firefox (I haven't tried anything else). Is that expected? I get something similar when I use it in my own app. FWIW, the CSS doesn't validate. (Among other things, // is not a comment delimiter in CSS.) http://jigsaw.w3.org/css-validator/validator?uri=http://www.web2py.com/plugins/default/datatable -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: DAL migration problem
On Feb 3, 2010, at 9:45 AM, Thadeus Burgess wrote: As an added note, I could use some help in creating the database specific keywords lists. http://drupal.org/node/141051 (I might have sent this before?) -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: Updating contents of plugin_datatable via Ajax?
On Feb 4, 2010, at 6:55 PM, Stefan wrote:
Hi Jonathan,
I noticed the same thing. To fix it, you need to modify the CSS file:
PluginsdatatableStatic filesplugin_datatable*.css
Update it with the following configuration:
I ended up using dataTables directly, instead of the plugin, and it's working
OK.
BTW, // isn't a comment delimiter in CSS; you want to use /* this */.
.dataTables_wrapper {
// position: relative;
// min-height: 100px;
// _height: 302px;
// clear: both;
float: left;
}
On Feb 4, 5:04 pm, Jonathan Lundell jlund...@pobox.com wrote:
Speaking of plugin_datatable, the example
athttp://www.web2py.com/plugins/default/datatablelooks v. messed up via
Safari and Firefox (I haven't tried anything else). Is that expected? I get
something similar when I use it in my own app.
FWIW, the CSS doesn't validate. (Among other things, // is not a comment
delimiter in CSS.)
http://jigsaw.w3.org/css-validator/validator?uri=http://www.web2py.co...
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: DAL migration problem
On Feb 4, 2010, at 7:03 PM, Thadeus Burgess wrote: Yes, there is much work to be done formatting each one of those lists into a python tuple object. That part isn't so bad. I need to know which ones you want. Here's MySQL 5.5: 'ACCESSIBLE', 'ADD', 'ALL', 'ALTER', 'ANALYZE', 'AND', 'AS', 'ASC', 'ASENSITIVE', 'BEFORE', 'BETWEEN', 'BIGINT', 'BINARY', 'BLOB', 'BOTH', 'BY', 'CALL', 'CASCADE', 'CASE', 'CHANGE', 'CHAR', 'CHARACTER', 'CHECK', 'COLLATE', 'COLUMN', 'CONDITION', 'CONSTRAINT', 'CONTINUE', 'CONVERT', 'CREATE', 'CROSS', 'CURRENT_DATE', 'CURRENT_TIME', 'CURRENT_TIMESTAMP', 'CURRENT_USER', 'CURSOR', 'DATABASE', 'DATABASES', 'DAY_HOUR', 'DAY_MICROSECOND', 'DAY_MINUTE', 'DAY_SECOND', 'DEC', 'DECIMAL', 'DECLARE', 'DEFAULT', 'DELAYED', 'DELETE', 'DESC', 'DESCRIBE', 'DETERMINISTIC', 'DISTINCT', 'DISTINCTROW', 'DIV', 'DOUBLE', 'DROP', 'DUAL', 'EACH', 'ELSE', 'ELSEIF', 'ENCLOSED', 'ESCAPED', 'EXISTS', 'EXIT', 'EXPLAIN', 'FALSE', 'FETCH', 'FLOAT', 'FLOAT4', 'FLOAT8', 'FOR', 'FORCE', 'FOREIGN', 'FROM', 'FULLTEXT', 'GRANT', 'GROUP', 'HAVING', 'HIGH_PRIORITY', 'HOUR_MICROSECOND', 'HOUR_MINUTE', 'HOUR_SECOND', 'IF', 'IGNORE', 'IGNORE_SERVER_IDS', 'IGNORE_SERVER_IDS', 'IN', 'INDEX', 'INFILE', 'INNER', 'INOUT', 'INSENSITIVE', 'INSERT', 'INT', 'INT1', 'INT2', 'INT3', 'INT4', 'INT8', 'INTEGER', 'INTERVAL', 'INTO', 'IS', 'ITERATE', 'JOIN', 'KEY', 'KEYS', 'KILL', 'LEADING', 'LEAVE', 'LEFT', 'LIKE', 'LIMIT', 'LINEAR', 'LINES', 'LOAD', 'LOCALTIME', 'LOCALTIMESTAMP', 'LOCK', 'LONG', 'LONGBLOB', 'LONGTEXT', 'LOOP', 'LOW_PRIORITY', 'MASTER_HEARTBEAT_PERIOD', 'MASTER_HEARTBEAT_PERIOD', 'MASTER_SSL_VERIFY_SERVER_CERT', 'MATCH', 'MAXVALUE', 'MAXVALUE', 'MEDIUMBLOB', 'MEDIUMINT', 'MEDIUMTEXT', 'MIDDLEINT', 'MINUTE_MICROSECOND', 'MINUTE_SECOND', 'MOD', 'MODIFIES', 'NATURAL', 'NO_WRITE_TO_BINLOG', 'NOT', 'NULL', 'NUMERIC', 'ON', 'OPTIMIZE', 'OPTION', 'OPTIONALLY', 'OR', 'ORDER', 'OUT', 'OUTER', 'OUTFILE', 'PRECISION', 'PRIMARY', 'PROCEDURE', 'PURGE', 'RANGE', 'READ', 'READ_WRITE', 'READS', 'REAL', 'REFERENCES', 'REGEXP', 'RELEASE', 'RENAME', 'REPEAT', 'REPLACE', 'REQUIRE', 'RESIGNAL', 'RESIGNAL', 'RESTRICT', 'RETURN', 'REVOKE', 'RIGHT', 'RLIKE', 'SCHEMA', 'SCHEMAS', 'SECOND_MICROSECOND', 'SELECT', 'SENSITIVE', 'SEPARATOR', 'SET', 'SHOW', 'SIGNAL', 'SIGNAL', 'SMALLINT', 'SPATIAL', 'SPECIFIC', 'SQL', 'SQL_BIG_RESULT', 'SQL_CALC_FOUND_ROWS', 'SQL_SMALL_RESULT', 'SQLEXCEPTION', 'SQLSTATE', 'SQLWARNING', 'SSL', 'STARTING', 'STRAIGHT_JOIN', 'TABLE', 'TERMINATED', 'THEN', 'TINYBLOB', 'TINYINT', 'TINYTEXT', 'TO', 'TRAILING', 'TRIGGER', 'TRUE', 'UNDO', 'UNION', 'UNIQUE', 'UNLOCK', 'UNSIGNED', 'UPDATE', 'USAGE', 'USE', 'USING', 'UTC_DATE', 'UTC_TIME', 'UTC_TIMESTAMP', 'VALUES', 'VARBINARY', 'VARCHAR', 'VARCHARACTER', 'VARYING', 'WHEN', 'WHERE', 'WHILE', 'WITH', 'WRITE', 'XOR', 'YEAR_MONTH', 'ZEROFILL', -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at
Re: [web2py] Re: DAL migration problem
On Feb 4, 2010, at 7:19 PM, Thadeus Burgess wrote: A quick question, what is your opinion on non-reserved keywords ? Should they be included, excluded, separated ? non-reserved words are acceptable and do not get in the way of your queries. I don't know enough to have an opinion, but if they're not reserved, what the heck? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] proposal for online documentation
On Feb 5, 2010, at 8:11 AM, mdipierro wrote: I got a private email from David and we have an idea: 1) organize a wiki with the same table of content as the book. Each page will have an errata and a a faq. I'd been thinking of that myself (so it must be a good idea!). It will include some parts of the book (when possible) and link the scribd book chapters when not possible. Perhaps each wiki page could always link to the appropriate chapter/section, so it's always available for reference. 2) integrate the above with a small web2py app that turns web2py docstrings into wiki pages. When users edit the wiki, the docstrings get updated, and I get a patch. Interesting thought. I'm slightly skeptical (about editing docstrings outside the context of the source code itself, and about doctests), but at the very least the underlying goal is great: a way to quickly edit docstrings without going through a formal patch process. What do people think? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
[web2py] SQLFORM: string field length, user id-email
A couple of SQLFORM-related questions. 1. I'd like a wider string input field, and I'm not sure how to get it. Unless there's an easier way, I was thinking I'd extend the string widget to embed a size maxlength. The manual mentions widget extension, but there's no example (only an example of writing a new one). So: how to extend the string widget? And how to invoke the existing string widget from FIELD with size/maxlength attributes? (And is there yet another method I'm overlooking?) 2. I have a table with a user ID, writable=False. In the SQLFORM, I'd like to display it as the user's name or email address instead of the bare ID. How? Thanks. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: SQLFORM: string field length, user id-email
On Feb 5, 2010, at 4:40 PM, mdipierro wrote:
On Feb 5, 4:24 pm, Jonathan Lundell jlund...@pobox.com wrote:
A couple of SQLFORM-related questions.
1. I'd like a wider string input field, and I'm not sure how to get it.
Unless there's an easier way, I was thinking I'd extend the string widget to
embed a size maxlength. The manual mentions widget extension, but there's
no example (only an example of writing a new one).
So: how to extend the string widget? And how to invoke the existing string
widget from FIELD with size/maxlength attributes? (And is there yet another
method I'm overlooking?)
in css
#table_field {
width: 400px;
}
Well, yeah, but that's semantically different from setting size/maxlength on a
text field. Can I pass the attributes to INPUT somehow?
And how do you extend an existing widget?
2. I have a table with a user ID, writable=False. In the SQLFORM, I'd like
to display it as the user's name or email address instead of the bare ID.
How?
This should be automatica if the referenced table has a format
attribute. Else set something like
I don't find format attribute in the manual. Should I be looking for
something else?
db.referenced_table.id.represent=lambda id: db.referenced_table.
[id].name
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
[web2py] IS_HTTP_URL() with user:password
IS_URL() fails when a userinfo field is present in the URL. Examples: http://u...@domain.com http://user:passw...@domain.com See http://tools.ietf.org/html/rfc3986 3.2.1. (The password portion is deprecated as insecure, but it's still legal.) Also http://www.faqs.org/rfcs/rfc2396.html This ought to be fixed in IS_GENERIC_URL(), perhaps under control of an option flag. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: IS_HTTP_URL() with user:password
On Feb 5, 2010, at 8:19 PM, mdipierro wrote: Yes. This is important. Can you send me a patch? I may have some time for it this weekend. Do you think it needs a switch? On Feb 5, 10:06 pm, Jonathan Lundell jlund...@pobox.com wrote: IS_URL() fails when a userinfo field is present in the URL. Examples: http://u...@domain.com http://user:passw...@domain.com Seehttp://tools.ietf.org/html/rfc39863.2.1. (The password portion is deprecated as insecure, but it's still legal.) Alsohttp://www.faqs.org/rfcs/rfc2396.html This ought to be fixed in IS_GENERIC_URL(), perhaps under control of an option flag. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: SQLFORM: string field length, user id-email
On Feb 5, 2010, at 8:13 PM, mdipierro wrote:
On Feb 5, 7:53 pm, Jonathan Lundell jlund...@pobox.com wrote:
On Feb 5, 2010, at 4:40 PM, mdipierro wrote:
On Feb 5, 4:24 pm, Jonathan Lundell jlund...@pobox.com wrote:
A couple of SQLFORM-related questions.
1. I'd like a wider string input field, and I'm not sure how to get it.
Unless there's an easier way, I was thinking I'd extend the string widget
to embed a size maxlength. The manual mentions widget extension, but
there's no example (only an example of writing a new one).
So: how to extend the string widget? And how to invoke the existing string
widget from FIELD with size/maxlength attributes? (And is there yet
another method I'm overlooking?)
in css
#table_field {
width: 400px;
}
Well, yeah, but that's semantically different from setting size/maxlength on
a text field. Can I pass the attributes to INPUT somehow?
You are wight.
form.element(_name='field')['size']=200
form.element(_name='field')['_size']=200
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
[web2py] cancel button
I seem to be full of elementary questions this week. I've got a simple SQLFORM to add a row to a database, and I want to have a cancel button along with the submit button. How? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: cancel button
On Feb 6, 2010, at 12:38 PM, mdipierro wrote: form[0][-1][1].append(BUTTON(_onclick=)) Thanks. Ideally, I'd like to return to the form.accepts call in such a way that the accepts return test can recognize the cancelation and then redirect as necessary. Somewhat parallel to testing form.error, I'd test (say) form.cancel. Does that make sense? It seems to me that it might be a useful general capability for form processing. One angle I was thinking of, but haven't investigated, is having multiple submit buttons, with accepts() making available the name and/or value of the button that was clicked. That seems more in keeping with the self-submit philosophy, don't you think? On Feb 6, 12:09 pm, Jonathan Lundell jlund...@pobox.com wrote: I seem to be full of elementary questions this week. I've got a simple SQLFORM to add a row to a database, and I want to have a cancel button along with the submit button. How? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: cancel button
On Feb 6, 2010, at 12:58 PM, Jonathan Lundell wrote: On Feb 6, 2010, at 12:38 PM, mdipierro wrote: form[0][-1][1].append(BUTTON(_onclick=)) Thanks. Ideally, I'd like to return to the form.accepts call in such a way that the accepts return test can recognize the cancelation and then redirect as necessary. Somewhat parallel to testing form.error, I'd test (say) form.cancel. Does that make sense? It seems to me that it might be a useful general capability for form processing. One angle I was thinking of, but haven't investigated, is having multiple submit buttons, with accepts() making available the name and/or value of the button that was clicked. That seems more in keeping with the self-submit philosophy, don't you think? I think I got it to work. form[0][-1][1].append(INPUT(_type=submit, _name=button, _value=Cancel)) and then after calling accepts: if request.vars.button == Cancel: session.flash = 'edit canceled' else: session.flash = edit accepted redirect(URL(r=request, f='servers')) ...or something similar in the form.error case. (I find that I'm a little fuzzy on the various return cases for accepts, though.) Question: what exactly is form[0][-1][1].append appending to? Can I append more than once to that same object? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Why is first element in IS_IN_SET pull-down always blank?
On Feb 6, 2010, at 7:53 PM, weheh wrote: In a crud form (or other form) where I have a field declared as a string that requires=IS_IN_SET(['A','B','C']), the first item in the automatically-generated pull-down for that enumerated field is a blank. Why is that, if there is no blank in my set, and especially, since a blank setting on that field will fail validation? How to get rid of the first blank entry? Try specifying zero=None in the validator. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: how to disable field access if not authorized
On Feb 7, 2010, at 7:32 AM, weheh wrote:
These are readable, but not writable. What I want is for widget to
get
grayed-out and not be usable when user doesn't have permission to
fill in the field.
Ideally, I think it would make sense to be able to do this as a
requirement to a field, something like:
requires=HAS_MEMBERSHIP(auth.id_group('admin'),auth.user.id),
or
requires=HAS_PERMISSION(...)
or maybe clearer yet, have a permission authenticator:
permission=HAS_MEMBERSHIP(...)
or permission=HAS_PERMISSION(...)
I like this a lot, at least as a general idea. Graying out would need to be
done with the html disabled attribute. Using permissions seems quite natural.
I'm not sure what the right logic would be, though. Perhaps 'disabled' is
parallel to readable and writable, though that may not be the best way of
putting it. At any rate, an input element would have four possible states: the
three we have now (visible and enabled, text-only (what is now readable but not
writable), and not visible), and visible but disabled. With the state a
function of permissions of the current user.
On Feb 7, 4:24 am, mdipierro mdipie...@cs.depaul.edu wrote:
I am not sure non-writable fields have widgets. I will check. Most
likely they do not if they are not writable and not readable.
On Feb 7, 2:02 am, weheh richard_gor...@verizon.net wrote:
I'm using crud and want to disable access to certain fields if user is
not a member of the admin group. For instance, content can only be
approved by admin. I want to register the id of the user who approved
the content, too. So I'd like to say:
if not auth.has_membership(auth.id_group('Admin'),auth.user.id):
db.content.approved.writable=False
db.content.signature.writable=False
form = crud.update(db.content,...)
so that even if the view has this:
{{=form.custom.widget.approved}}
{{=form.custom.widget.signature}}
the fields shouldn't be fillable by an unauthorized user. Problem is,
this doesn't work and I get this ticket:
Traceback (most recent call last):
File C:\web2py\gluon\restricted.py, line 173, in restricted
exec ccode in environment
File C:/web2py/applications/myapp/controllers/admin.py, line 187,
in module
File C:\web2py\gluon\globals.py, line 96, in lambda
self._caller = lambda f: f()
File C:\web2py\gluon\tools.py, line 1873, in f
return action(*a, **b)
File C:/web2py/applications/myapp/controllers/admin.py, line 59,
in marketing
form = crud.update(db.content,request.args(2),message=T('Updated
content'))
File C:\web2py\gluon\tools.py, line 2270, in update
keepvalues=self.settings.keepvalues):
File C:\web2py\gluon\sqlhtml.py, line 755, in accepts
onvalidation,
File C:\web2py\gluon\html.py, line 1267, in accepts
status = self._traverse(status)
File C:\web2py\gluon\html.py, line 449, in _traverse
newstatus = c._traverse(status) and newstatus
File C:\web2py\gluon\html.py, line 449, in _traverse
newstatus = c._traverse(status) and newstatus
File C:\web2py\gluon\html.py, line 449, in _traverse
newstatus = c._traverse(status) and newstatus
File C:\web2py\gluon\html.py, line 449, in _traverse
newstatus = c._traverse(status) and newstatus
TypeError: 'NoneType' object is not callable
Anybody know what's going on here?- Hide quoted text -
- Show quoted text -
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
--
You received this message because you are subscribed to the Google Groups
web2py-users group.
To post to this group, send email to web...@googlegroups.com.
To unsubscribe from this group, send email to
web2py+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/web2py?hl=en.
[web2py] password hash problems
I've got this (where the key is a text string): from gluon.tools import * auth=Auth(globals(),db) # authentication/authorization auth.settings.hmac_key = vpepm_hmac_key auth.define_tables() # creates all needed tables # invoke IS_STRONG only for password creation, not password checking if login not in request.args: auth.settings.table_user.password.requires += [IS_STRONG(min=8, max=0, upper=1, lower=1, number=1, special=1)] All my logins are failing with a bad password. I've got a sha512 hash in my user database (manually initialized), but the login form is returning an md5 hash, presumably because digest_alg is set to md5. The manual says, If a key is specified it uses the HMAC+SHA512 with the provided key, but I don't see where digest_alg is ever set to sha512. Is there a bug, or am I doing something wrong? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: password hash problems
On Feb 7, 2010, at 12:10 PM, mr.freeze wrote: Looking at CRYPT, if you provide a key but not a digest algorithm, it will try to get the digest alg by splitting the key between a colon. So you could say: auth.settings.hmac_key = 'sha512:%s' % vpepm_hmac_key That did the trick. Thanks, I hadn't noticed the split. Massimo, that's contrary to the documentation. On Feb 7, 1:44 pm, Jonathan Lundell jlund...@pobox.com wrote: I've got this (where the key is a text string): from gluon.tools import * auth=Auth(globals(),db) # authentication/authorization auth.settings.hmac_key = vpepm_hmac_key auth.define_tables() # creates all needed tables # invoke IS_STRONG only for password creation, not password checking if login not in request.args: auth.settings.table_user.password.requires += [IS_STRONG(min=8, max=0, upper=1, lower=1, number=1, special=1)] All my logins are failing with a bad password. I've got a sha512 hash in my user database (manually initialized), but the login form is returning an md5 hash, presumably because digest_alg is set to md5. The manual says, If a key is specified it uses the HMAC+SHA512 with the provided key, but I don't see where digest_alg is ever set to sha512. Is there a bug, or am I doing something wrong? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: password hash problems
On Feb 7, 2010, at 12:07 PM, mdipierro wrote: remember that validators are filters. You need to check that a password is strong BEFORE it is hashed. So instead of this: auth.settings.table_user.password.requires += [IS_STRONG(min=8, max=0, upper=1, lower=1, number=1, special=1)] Do this auth.settings.table_user.password.insert(0,IS_STRONG(min=8, max=0, upper=1, lower=1, number=1, special=1)) Not sure this is your problem but try again after this fix. Good point, thanks. But it wasn't my problem; the problem is that digest_alg defaults to md5, even in the presence of a key, which isn't what the manual says. I think that the best course of action might be to change the manual, since fixing the code now would break backward compatibility (I think). OTOH, if anyone is relying on the docs and expecting a sha512 hash, they're not getting one. The only reason I noticed the problem was that I was manually initializing the database with a sha512 hash, rather than relying on the form. On Feb 7, 1:44 pm, Jonathan Lundell jlund...@pobox.com wrote: I've got this (where the key is a text string): from gluon.tools import * auth=Auth(globals(),db) # authentication/authorization auth.settings.hmac_key = vpepm_hmac_key auth.define_tables() # creates all needed tables # invoke IS_STRONG only for password creation, not password checking if login not in request.args: auth.settings.table_user.password.requires += [IS_STRONG(min=8, max=0, upper=1, lower=1, number=1, special=1)] All my logins are failing with a bad password. I've got a sha512 hash in my user database (manually initialized), but the login form is returning an md5 hash, presumably because digest_alg is set to md5. The manual says, If a key is specified it uses the HMAC+SHA512 with the provided key, but I don't see where digest_alg is ever set to sha512. Is there a bug, or am I doing something wrong? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: password hash problems
On Feb 7, 2010, at 12:07 PM, mdipierro wrote: remember that validators are filters. You need to check that a password is strong BEFORE it is hashed. So instead of this: auth.settings.table_user.password.requires += [IS_STRONG(min=8, max=0, upper=1, lower=1, number=1, special=1)] Do this auth.settings.table_user.password.insert(0,IS_STRONG(min=8, max=0, upper=1, lower=1, number=1, special=1)) Not sure this is your problem but try again after this fix. Shouldn't that be auth.settings.table_user.password.requires.insert(0,IS_STRONG(min=8, max=0, upper=1, lower=1, number=1, special=1)) ? On Feb 7, 1:44 pm, Jonathan Lundell jlund...@pobox.com wrote: I've got this (where the key is a text string): from gluon.tools import * auth=Auth(globals(),db) # authentication/authorization auth.settings.hmac_key = vpepm_hmac_key auth.define_tables() # creates all needed tables # invoke IS_STRONG only for password creation, not password checking if login not in request.args: auth.settings.table_user.password.requires += [IS_STRONG(min=8, max=0, upper=1, lower=1, number=1, special=1)] All my logins are failing with a bad password. I've got a sha512 hash in my user database (manually initialized), but the login form is returning an md5 hash, presumably because digest_alg is set to md5. The manual says, If a key is specified it uses the HMAC+SHA512 with the provided key, but I don't see where digest_alg is ever set to sha512. Is there a bug, or am I doing something wrong? -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: cancel button
On Feb 6, 2010, at 9:33 PM, Iceberg wrote: On Feb7, 8:01am, Jonathan Lundell jlund...@pobox.com wrote: On Feb 6, 2010, at 12:58 PM, Jonathan Lundell wrote: On Feb 6, 2010, at 12:38 PM, mdipierro wrote: form[0][-1][1].append(BUTTON(_onclick=)) Thanks. Ideally, I'd like to return to the form.accepts call in such a way that the accepts return test can recognize the cancelation and then redirect as necessary. Somewhat parallel to testing form.error, I'd test (say) form.cancel. Does that make sense? It seems to me that it might be a useful general capability for form processing. One angle I was thinking of, but haven't investigated, is having multiple submit buttons, with accepts() making available the name and/or value of the button that was clicked. That seems more in keeping with the self-submit philosophy, don't you think? Yes, but be careful of multiple submit buttons. See this post: https://groups.google.com/group/web2py/browse_frm/thread/f44b6f95b058df5 I'll need to look at that more closely. Thanks. Perhaps I can use button and JavaScript. I think I got it to work. form[0][-1][1].append(INPUT(_type=submit, _name=button, _value=Cancel)) and then after calling accepts: if request.vars.button == Cancel: session.flash = 'edit canceled' else: session.flash = edit accepted redirect(URL(r=request, f='servers')) ...or something similar in the form.error case. (I find that I'm a little fuzzy on the various return cases for accepts, though.) That is inevitable since you need to handle two different situations in one action. So I would suggest just use a normal html reset button at most. Reset doesn't do it for me; I need an actual cancel function that can do a specified page load. Question: what exactly is form[0][-1][1].append appending to? Can I append more than once to that same object? Yes. FORM is a container for many components. You can change it if you want to. But a more readable style should be: form = FORM( ... # all the normal stuff INPUT(_type='submit'), INPUT(_type='reset'), ) Except it's an SQLFORM, which won't accept INPUT arguments. The big problem with form[0][-1][1].append is that it knows too much about the internal structure of form. I can't expect the guarantee of backward compatibility to include constructs like that. So I'm left with two problems. The IE with multiple submits, and adding a button to the SQLFORM. Both are semi-solved, I think, but not in an ideal way. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: cancel button
On Feb 7, 2010, at 2:06 PM, mr.freeze wrote: I hate this too: form[0][-1][1]. I have a pending patch that will allow you to grab parent and sibling elements so you can do: form = SQLFORM(db.whatever) submit = form.element(_type='submit') submit.parent.append(INPUT(_type='submit',_value='Cancel')) A little more verbose but human readable and appending the button will stay relative to where the submit button is. Massimo, have you had a chance to look at this? That would be a big improvement, yes. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
[web2py] wiki formatting
While adding a note to the book errata about hash selection, I noticed that the vertical white space (line to line, graf to graf) on that page appears to be mostly random. Or if there's a method to it, I can't tell what it is. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: cancel button
On Feb 6, 2010, at 9:33 PM, Iceberg wrote: Yes, but be careful of multiple submit buttons. See this post: https://groups.google.com/group/web2py/browse_frm/thread/f44b6f95b058df5 I think I've solved the multiple-submit problem, at the cost of a bit of scripting (but not much): form[0][-1][1].append(INPUT(_type=button, _value=Cancel, _onclick=location='%s';%URL(r=request, f='addserver', vars=dict(button='Cancel' -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: wrong decisions and backward compatibility
On Feb 7, 2010, at 6:32 PM, mdipierro wrote: We could add an option like strict=False that if true does what you ask. What's the use case? I'm having trouble seeing what such an option would do for you. Sure, IS_UPPER() should probably have been named TO_UPPER(). But at this point On Feb 7, 8:22 pm, Iceberg iceb...@21cn.com wrote: But in this case (provided that we really change IS_UPPER() as Pihentagy suggested), you can rely on the human, because they can not input lower case. Your app still need not to edit a single line. :) Well, sounds like I support changing IS_UPPER() 's behavior. But actually I am neutral to this proposal. On Feb7, 3:24pm, Thadeus Burgess thade...@thadeusb.com wrote: It will break backwards compatibility. I have apps that rely on the functionality of IS_UPPER applying .upper() to the incoming variables. Anything that requires me to edit a single line of code on my app to just upgrade web2py breaks backwards compatibility, unless it was a bug to begin with. -Thadeus On Sat, Feb 6, 2010 at 11:33 PM, Iceberg iceb...@21cn.com wrote: @Pihentagy: Besides, the current IS_UPPER() (and IS_LOWER()) is not that bad, IMHO. What is the real difference between alarm end user to change his input into upper case, or just silently change his input into upper case? To say the least, we can really change IS_UPPER() to just warning, and perhaps another UPPERCASE() to uppercase. As long as the old apps do not really break, but just sightly change its behavior in acceptable range, I consider web2py is still backward compatible. About web3py, Renato says all. :) On Feb6, 8:24pm, Renato-ES-Brazil renatoa...@gmail.com wrote: Web3py is an alternative, check this: When GAE moves to 3.0 and the database drivers for all supported backends become available we will release something like web3py (TM). Since we are going to break language backward compatibility that will also be a good time to include other non-backward compatible changes. 2010-2011 are reasonable dates but just a guess. URL:http://www.mail-archive.com/web2py@googlegroups.com/msg09344.html On 6 fev, 08:12, pihentagy pihent...@gmail.com wrote: Hi! Looking into the code of IS_UPPER I realized, that this function does not do, what I expect to do. I thought it only allows strings, which does not have lowercase letters, but it actually converts the string to uppercase. Since web2py promises backwards compatibility, and here IMHO this method is mis-named, how would you solve the situation? BTW when I come across the fact, that web2py will be always backwards compatible, a loud alarm began to horn in my head: then how would you maintain the code in 2, 3, 10 years? It will blow up. Or, when it becomes hard to maintain, you began a new project named web3py? :) Gergo -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group athttp://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: cancel button
On Feb 7, 2010, at 6:31 PM, mdipierro wrote: The patch by Mr Freeze is in. Thanks. I'll wait for a stable release, but I'll definitely use it. Some documentary comments would be nice. (BTW, the patch added trailing white space to a few lines. Bogus, I assume.) On Feb 7, 4:27 pm, mdipierro mdipie...@cs.depaul.edu wrote: The patch will be in soon. ;-) On Feb 7, 4:18 pm, Jonathan Lundell jlund...@pobox.com wrote: On Feb 7, 2010, at 2:06 PM, mr.freeze wrote: I hate this too: form[0][-1][1]. I have a pending patch that will allow you to grab parent and sibling elements so you can do: form = SQLFORM(db.whatever) submit = form.element(_type='submit') submit.parent.append(INPUT(_type='submit',_value='Cancel')) A little more verbose but human readable and appending the button will stay relative to where the submit button is. Massimo, have you had a chance to look at this? That would be a big improvement, yes. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] validators, min and max
On Feb 8, 2010, at 1:15 AM, KONTRA, Gergely wrote: Hi! I found another inconsistency in validators: IS_INT_IN_RANGE: IS_INT_IN_RANGE(0,10) does not accepts 10. Notice that the default error message for this test is, enter a number between 0 and 9, so the user gets a relatively clear message. The programmer's view, OTOH, is consistent with the Python range convention. Yes, this is in the docs, but using using args minimum and maximum, how would one know, that it includes the start/end point? Similarly, IS_LENGTH, IS_DECIMAL_IN_RANGE and so on...? OTOH: IS_FLOAT_IN_RANGE(0,10) will accept 10, and will accept 0. BTW equality comparision between floating points can be tricky, if the endpoints are not represented exactly. One, who worked with floating points may know this,but... So: being backward compatible, what about new possibilities: minInclusive, minExclusive, maxInclusive and maxExclusive, like in the xsd definition? And does it makes sense to make all min and max values optional, so you can have: enter an integer, which is larger than 2 (witout upper limit)? Consider that the purpose of the validator functions is to process user input, not general computation. It's always possible to write a custom validator if the stock ones don't suffice. +-[ Gergely Kontra pihent...@gmail.com ]--+ | | | Mobile:(+36 20)356 9656 | | | +- Olyan lángész vagyok, hogy poroltóval kellene járnom! -+ -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: wrong decisions and backward compatibility
On Feb 8, 2010, at 12:59 AM, KONTRA, Gergely wrote: Hi! Yes, I must admit it, that a validator like IS_UPPER(), which checks only whether the input is uppercase is less useful, than an another, which actually converts to uppercase. OTOH if you haven't used the function, you expect the former. It might be appropriate to provide aliases for filter-only validators along the lines of TO_UPPER(), change the docs, and deprecate IS_UPPER() on the grounds of ambiguity. But I don't see a motivation for changing the semantics of IS_UPPER(), since there's no real benefit to be had, and it would break a lot of existing code. Notice that some validators do both. That is, they validate their input, and also transform it. This is one of those cases where it's advisable for a developer to read the docs. +-[ Gergely Kontra pihent...@gmail.com ]--+ | | | Mobile:(+36 20)356 9656 | | | +- Olyan lángész vagyok, hogy poroltóval kellene járnom! -+ On Mon, Feb 8, 2010 at 04:17, Jonathan Lundell jlund...@pobox.com wrote: On Feb 7, 2010, at 6:32 PM, mdipierro wrote: We could add an option like strict=False that if true does what you ask. What's the use case? I'm having trouble seeing what such an option would do for you. Sure, IS_UPPER() should probably have been named TO_UPPER(). But at this point On Feb 7, 8:22 pm, Iceberg iceb...@21cn.com wrote: But in this case (provided that we really change IS_UPPER() as Pihentagy suggested), you can rely on the human, because they can not input lower case. Your app still need not to edit a single line. :) Well, sounds like I support changing IS_UPPER() 's behavior. But actually I am neutral to this proposal. On Feb7, 3:24pm, Thadeus Burgess thade...@thadeusb.com wrote: It will break backwards compatibility. I have apps that rely on the functionality of IS_UPPER applying .upper() to the incoming variables. Anything that requires me to edit a single line of code on my app to just upgrade web2py breaks backwards compatibility, unless it was a bug to begin with. -Thadeus On Sat, Feb 6, 2010 at 11:33 PM, Iceberg iceb...@21cn.com wrote: @Pihentagy: Besides, the current IS_UPPER() (and IS_LOWER()) is not that bad, IMHO. What is the real difference between alarm end user to change his input into upper case, or just silently change his input into upper case? To say the least, we can really change IS_UPPER() to just warning, and perhaps another UPPERCASE() to uppercase. As long as the old apps do not really break, but just sightly change its behavior in acceptable range, I consider web2py is still backward compatible. About web3py, Renato says all. :) On Feb6, 8:24pm, Renato-ES-Brazil renatoa...@gmail.com wrote: Web3py is an alternative, check this: When GAE moves to 3.0 and the database drivers for all supported backends become available we will release something like web3py (TM). Since we are going to break language backward compatibility that will also be a good time to include other non-backward compatible changes. 2010-2011 are reasonable dates but just a guess. URL:http://www.mail-archive.com/web2py@googlegroups.com/msg09344.html On 6 fev, 08:12, pihentagy pihent...@gmail.com wrote: Hi! Looking into the code of IS_UPPER I realized, that this function does not do, what I expect to do. I thought it only allows strings, which does not have lowercase letters, but it actually converts the string to uppercase. Since web2py promises backwards compatibility, and here IMHO this method is mis-named, how would you solve the situation? BTW when I come across the fact, that web2py will be always backwards compatible, a loud alarm began to horn in my head: then how would you maintain the code in 2, 3, 10 years? It will blow up. Or, when it becomes hard to maintain, you began a new project named web3py? :) Gergo -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: for your info
On Feb 8, 2010, at 2:46 AM, Beerc wrote: I ***LOVE*** the tight integration of web2py components. I ***LOVE*** the compactness of web2py. These are by far the two biggest reasons I started using web2py, mainly over Django and its kin. Now that I have a little more experience, I'd add this mailing list to my list of reasons. My biggest complaint is what has been referred to as magic behavior, and in particular the relative opaqueness of some of that magic. Documentation could help there by making more clear what's going on inside; there's a little too much do this and it just works right now. But that's true of (say) RoR, too, so web2py isn't alone. I like the idea of a wiki that parallels the structure of the book. I'd also like to see a page each for all (or at least the important) classes, linked to their mentions in the mainline docs, where among other things magic behavior is explained. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: validators, min and max
On Feb 8, 2010, at 8:13 AM, DenesL wrote: Having had the need recently, I would like to see: IS_INT_IN_RANGE(1) # any integer0 (up to sys.maxint) IS_INT_IN_RANGE(max=10) # any integer less than 10 and similarly for IS_FLOAT_IN_RANGE(). Suggestion: interpret None as no limit. So your two examples would be: IS_INT_IN_RANGE(1, None) IS_INT_IN_RANGE(None, 10) The error message would have to adjust, of course. Similarly for float. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
Re: [web2py] Re: validators, min and max
On Feb 8, 2010, at 8:34 AM, mdipierro wrote: send me a patch! I'd suggest otherwise--in particular interpreting None as no limit in the min or max direction. Interpreting (4) as (0,4) saves the developer two characters of typing. But interpreting (4, None) or (None, 4) as no limit extends the functionality of the validator. On Feb 8, 10:24 am, KONTRA, Gergely pihent...@gmail.com wrote: And does it makes sense to make all min and max values optional, so you can have: enter an integer, which is larger than 2 (witout upper limit)? Having had the need recently, I would like to see: IS_INT_IN_RANGE(1) # any integer0 (up to sys.maxint) IS_INT_IN_RANGE(max=10) # any integer less than 10 and similarly for IS_FLOAT_IN_RANGE(). Following python's range() conventions, IS_INT_IN_RANGE(4) should accept ints between 0 and 3. -- You received this message because you are subscribed to the Google Groups web2py-users group. To post to this group, send email to web...@googlegroups.com. To unsubscribe from this group, send email to web2py+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/web2py?hl=en.
