Re: [web2py] Re: Can website visitors update my languages files?

[Michael Wolfe]

OK. So the framework is updating the languages files in my app based on
translations in other apps (e.g., admin and appadmin)?

But only if a website visitor requests a page in that language, correct?

So I'm imagining the following algorithm:

- website visitor with a 'pl' language preference visits my site
- goes to a page with T("Hello")
- web2py looks for /myapp/languages/pl.py
- web2py looks for "Hello" in that file
- can't find it, so it checks /appadmin/languages/pl.py
- finds a translation in that file
- updates /myapp/languages/pl.py with this translation
- shows visitor the translated text

Is that about right?
On Jan 14, 2016 5:34 PM, "Anthony"  wrote:

> web2py comes with many phrases already translated (e.g., those used in
> admin and appadmin):
>
>
> https://github.com/web2py/web2py/blob/master/applications/welcome/languages/ru.py#L13
>
> Anthony
>
> On Thursday, January 14, 2016 at 3:40:47 PM UTC-5, mwolfe02 wrote:
>>
>> That makes sense.  I guess my question is where do the translations
>> themselves come from?  For example, the following two lines were *added* to
>> the Russian translation file:
>>
>> '%s rows deleted': '%s строк удалено',
>> '%s rows updated': '%s строк изменено',
>>
>> I certainly did not add in the Cyrillic characters in the above lines.
>> So where did they come from?
>>
>> There are some lines that were just changed from their hex code to the
>> Unicode characters (e.g., "\xd0\x98\xd0\xb7\xd0\xbc" to "Изм").  That I can
>> understand.  It's the brand new translations that I was surprised by.
>> Could they be coming from the languages files in the example app?
>>
>> Thanks,
>> Mike
>>
>> On Thu, Jan 14, 2016 at 3:32 PM, Anthony  wrote:
>>
>>> The first time a visitor requesting a particular language hits the app,
>>> any T() items not yet in the associated translation file will be added
>>> automatically for later translation.
>>>
>>> Anthony
>>>
>>>
>>> On Thursday, January 14, 2016 at 2:41:04 PM UTC-5, mwolfe02 wrote:

 I've got a live web2py application under Mercurial version control.
 When I did my latest commit, I noticed there were several changes to the
 following two files (the Polish and Russian translation files):

 /languages/pl.py
 /languages/ru-ru.py

 I did not make these changes.  The changes look like they could be
 legitimate and perhaps automated.  For example, here are the first few
 lines of the ru-ru.py diff (I removed some characters and replaced them
 with {...} to limit the amount of noise:


 @@ -1,87 +1,91 @@
 -# coding: utf8
 +# -*- coding: utf-8 -*-
  {
 -'"update" is an optional expression like "field1=\'newvalue\'". You
 cannot update or delete the results of a JOIN':
 '"\xd0\x98\xd0{...}\xd1\x8c.',
 +'"update" is an optional expression like "field1=\'newvalue\'". You
 cannot update or delete the results of a JOIN': '"Изм{...}ть.',
 +'%s rows deleted': '%s строк удалено',
 +'%s rows updated': '%s строк изменено',
  '%Y-%m-%d': '%Y-%m-%d',
  '%Y-%m-%d %H:%M:%S': '%Y-%m-%d %H:%M:%S',


 So what could have caused these changes?  Does web2py itself do
 something that would cause this?  Google Translate?  Website visitors?
 Apache?

 Are there security considerations I should be aware of?

 As far as I know, I have not done anything to modify the default
 Translation behavior of my app.

 Thanks in advance to anyone who can enlighten me,
 Mike Wolfe

>>> --
>>> Resources:
>>> - http://web2py.com
>>> - http://web2py.com/book (Documentation)
>>> - http://github.com/web2py/web2py (Source code)
>>> - https://code.google.com/p/web2py/issues/list (Report Issues)
>>> ---
>>> You received this message because you are subscribed to a topic in the
>>> Google Groups "web2py-users" group.
>>> To unsubscribe from this topic, visit
>>> https://groups.google.com/d/topic/web2py/46XERxrdvts/unsubscribe.
>>> To unsubscribe from this group and all its topics, send an email to
>>> web2py+unsubscr...@googlegroups.com.
>>> For more options, visit https://groups.google.com/d/optout.
>>>
>>
>> --
> Resources:
> - http://web2py.com
> - http://web2py.com/book (Documentation)
> - http://github.com/web2py/web2py (Source code)
> - https://code.google.com/p/web2py/issues/list (Report Issues)
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "web2py-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/web2py/46XERxrdvts/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> web2py+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 

Re: [web2py] Re: Can website visitors update my languages files?

[Michael Wolfe]

That makes sense.  I guess my question is where do the translations
themselves come from?  For example, the following two lines were *added* to
the Russian translation file:

'%s rows deleted': '%s строк удалено',
'%s rows updated': '%s строк изменено',

I certainly did not add in the Cyrillic characters in the above lines.  So
where did they come from?

There are some lines that were just changed from their hex code to the
Unicode characters (e.g., "\xd0\x98\xd0\xb7\xd0\xbc" to "Изм").  That I can
understand.  It's the brand new translations that I was surprised by.
Could they be coming from the languages files in the example app?

Thanks,
Mike

On Thu, Jan 14, 2016 at 3:32 PM, Anthony  wrote:

> The first time a visitor requesting a particular language hits the app,
> any T() items not yet in the associated translation file will be added
> automatically for later translation.
>
> Anthony
>
>
> On Thursday, January 14, 2016 at 2:41:04 PM UTC-5, mwolfe02 wrote:
>>
>> I've got a live web2py application under Mercurial version control.  When
>> I did my latest commit, I noticed there were several changes to the
>> following two files (the Polish and Russian translation files):
>>
>> /languages/pl.py
>> /languages/ru-ru.py
>>
>> I did not make these changes.  The changes look like they could be
>> legitimate and perhaps automated.  For example, here are the first few
>> lines of the ru-ru.py diff (I removed some characters and replaced them
>> with {...} to limit the amount of noise:
>>
>>
>> @@ -1,87 +1,91 @@
>> -# coding: utf8
>> +# -*- coding: utf-8 -*-
>>  {
>> -'"update" is an optional expression like "field1=\'newvalue\'". You
>> cannot update or delete the results of a JOIN':
>> '"\xd0\x98\xd0{...}\xd1\x8c.',
>> +'"update" is an optional expression like "field1=\'newvalue\'". You
>> cannot update or delete the results of a JOIN': '"Изм{...}ть.',
>> +'%s rows deleted': '%s строк удалено',
>> +'%s rows updated': '%s строк изменено',
>>  '%Y-%m-%d': '%Y-%m-%d',
>>  '%Y-%m-%d %H:%M:%S': '%Y-%m-%d %H:%M:%S',
>>
>>
>> So what could have caused these changes?  Does web2py itself do something
>> that would cause this?  Google Translate?  Website visitors?  Apache?
>>
>> Are there security considerations I should be aware of?
>>
>> As far as I know, I have not done anything to modify the default
>> Translation behavior of my app.
>>
>> Thanks in advance to anyone who can enlighten me,
>> Mike Wolfe
>>
> --
> Resources:
> - http://web2py.com
> - http://web2py.com/book (Documentation)
> - http://github.com/web2py/web2py (Source code)
> - https://code.google.com/p/web2py/issues/list (Report Issues)
> ---
> You received this message because you are subscribed to a topic in the
> Google Groups "web2py-users" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/web2py/46XERxrdvts/unsubscribe.
> To unsubscribe from this group and all its topics, send an email to
> web2py+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

-- 
Resources:
- http://web2py.com
- http://web2py.com/book (Documentation)
- http://github.com/web2py/web2py (Source code)
- https://code.google.com/p/web2py/issues/list (Report Issues)
--- 
You received this message because you are subscribed to the Google Groups 
"web2py-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[web2py] fw:

[Michael Wolfe]

 http://mrcarinsurance.co.za/bbemolh/ljpnjralx









 Michael Wolfe










 7/23/2013 2:16:39 AM

-- 

--- 
You received this message because you are subscribed to the Google Groups 
web2py-users group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to web2py+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Re: [web2py] Re: Syntax to INNER JOIN table to itself

[Michael Wolfe]

I'm actually running off of trunk already (latest changeset is 1410
(feb4ddb2d659), committed 14 hours ago).

The book example only demonstrates using with_alias in LEFT JOINs.  Is this
a limitation?

If it makes any difference, I am running dal.py as a standalone module for a
non-web2py project.  (Speaking of using it as a standalone module, I almost
wet myself when I saw how easy it was to use it that way.  Nice work on the
re-write.)

Thanks,
Mike

On Tue, Dec 21, 2010 at 5:00 PM, mdipierro mdipie...@cs.depaul.edu wrote:

 there is a bug in 1.90.6 about with_alias. I think it is fixed in
 trunk. give it a try.

 On Dec 21, 3:46 pm, mwolfe02 michael.joseph.wo...@gmail.com wrote:
  I have a legacy table with a three-character primary key and a three-
  character self-referencing field.  I'm trying to implement the
  following sql using the DAL:
 
  SELECT District.Description, SchoolDistrict.Description
  FROM District.DistrictID
  INNER JOIN District AS SchoolDistrict
  ON District.SchoolDistrictID = SchoolDistrict.DistrictID
 
  I thought I could use with_alias to do this but it does not seem to be
  working.
 
  Thanks,
  Mike

Re: [web2py] Re: Syntax to INNER JOIN table to itself

[Michael Wolfe]

You're right, that should work.  I wonder if there would be a significant
performance hit running a LEFT JOIN in place of an INNER JOIN.  I'll have to
keep an eye on that to see if it makes much difference, but in my particular
case (less than 100 records) I think I'll be fine.

Thanks for the quick response,
Mike

On Tue, Dec 21, 2010 at 5:22 PM, mdipierro mdipie...@cs.depaul.edu wrote:

 yes alias only works with left joins. But you can mimic one with the
 other to I tried this which I think is equivalent to your query:

 db=DAL()
 District =

 db.define_table('district',Field('description'),Field('district_id','reference
 district'))

 SchoolDistrict = District.with_alias('school_district')
 rows= db(District.district_id!

 =None).select(District.description,SchoolDistrict.description,left=SchoolDistrict.on(SchoolDistrict.
 \
 id==District.district_id))
 print rows

 Makes this sql:

 SELECT  district.description, school_district.description FROM
 district LEFT JOIN district AS school_district ON (school_district.id
 = district.district_id) WHERE (district.district_id IS NOT NULL);





 On Dec 21, 4:09 pm, Michael Wolfe michael.joseph.wo...@gmail.com
 wrote:
  I'm actually running off of trunk already (latest changeset is 1410
  (feb4ddb2d659), committed 14 hours ago).
 
  The book example only demonstrates using with_alias in LEFT JOINs.  Is
 this
  a limitation?
 
  If it makes any difference, I am running dal.py as a standalone module
 for a
  non-web2py project.  (Speaking of using it as a standalone module, I
 almost
  wet myself when I saw how easy it was to use it that way.  Nice work on
 the
  re-write.)
 
  Thanks,
  Mike
 
 
 
 
 
  On Tue, Dec 21, 2010 at 5:00 PM, mdipierro mdipie...@cs.depaul.edu
 wrote:
   there is a bug in 1.90.6 about with_alias. I think it is fixed in
   trunk. give it a try.
 
   On Dec 21, 3:46 pm, mwolfe02 michael.joseph.wo...@gmail.com wrote:
I have a legacy table with a three-character primary key and a three-
character self-referencing field.  I'm trying to implement the
following sql using the DAL:
 
SELECT District.Description, SchoolDistrict.Description
FROM District.DistrictID
INNER JOIN District AS SchoolDistrict
ON District.SchoolDistrictID = SchoolDistrict.DistrictID
 
I thought I could use with_alias to do this but it does not seem to
 be
working.
 
Thanks,
Mike
 
 

Re: [web2py] Re: Remove link in MENU for current url

[Michael Wolfe]

Completely optional.

On Sat, Oct 30, 2010 at 3:02 AM, annet annet.verm...@gmail.com wrote:
 Does this mean that the current menu's behaviour will change, or is
 this patch optional?

 Currently, I just style active links differently, and that works fine.
 I have seen people who work with different browsers on different OS
 use the active menu link to refresh the current page. Basically
 because the menu link is closer to where the mouse pointer is, and
 because the menu link is always on the same position in the window.
 Safari has its refresh button to the right of the URL, in Firefox
 it's the first button in a row of three to the left of the URL.


 Kind regards,

 Annet.

Re: [web2py] Re: Remove link in MENU for current url

[Michael Wolfe]

Massimo,

I tried sending this patch directly to you, but I'm not sure if you
received it.  In any case, I re-exported the patch this morning so it
runs against trunk.

Let me know if I've missed something or if you've decided to hold this
out of the framework.  I won't be offended either way.

Thanks,
Mike

On Fri, Oct 22, 2010 at 4:38 PM, mdipierro mdipie...@cs.depaul.edu wrote:
 Can you please email me the patch? thanks.

 On Oct 22, 3:08 pm, Michael Wolfe michael.joseph.wo...@gmail.com
 wrote:
 Following the sage advice of Jakob Nielsen, I wanted a way to turn off
 links that point to the current page within the menu (see #10 
 here:http://www.useit.com/alertbox/20031110.html).  At the bottom of this
 e-mail, I'm including a proposed patch that would make this easier.

 I've added two optional parameters to the MENU helper: no_link_url and
 active_url.

 To illustrate how this works, I'll give three examples of what you
 would see for the Index link in the welcome scaffolding app by
 altering the MENU line from layout.html.

 1. Current behavior
 {{=MENU(response.menu,_class='sf-menu')}}
 lia href=/welcome/default/indexIndex/a/li

 2. Removing the link for the current page
 {{=MENU(response.menu,_class='sf-menu',no_link_url=request.url)}}
 lidivIndex/div/li

 3. Adding the class 'active' to the list item of the link to the current page
 {{=MENU(response.menu,_class='sf-menu',active_url=request.url,
 li_active='active')}}
 li class=activea href=/welcome/default/indexIndex/a/li

 And here's the patch.  Please let me know if I've missed something.

 diff -r 6608e0e6b4f3 -r badb5215df3f applications/welcome/static/base.css
 --- a/applications/welcome/static/base.css      Fri Oct 15 07:17:35 2010 
 -0500
 +++ b/applications/welcome/static/base.css      Fri Oct 22 15:11:06 2010 
 -0400
 @@ -216,9 +216,12 @@
  .sf-menu {
         float:  left;
  }
 -.sf-menu a {
 +.sf-menu a, .sf-menu div {
         padding: 5px 15px;
  }
 +.sf-menu div {
 +        color: white;
 +}
  .sf-menu li {
         background: #33;
  }
 diff -r 6608e0e6b4f3 -r badb5215df3f gluon/html.py
 --- a/gluon/html.py     Fri Oct 15 07:17:35 2010 -0500
 +++ b/gluon/html.py     Fri Oct 22 15:11:06 2010 -0400
 @@ -1699,14 +1699,16 @@
              ul = UL(_class=self['ul_class'])
          for item in data:
              (name, active, link) = item[:3]
 -            if link:
 +            if 'no_link_url' in self.attributes and 
 self['no_link_url']==link:
 +                li = LI(DIV(name))
 +            elif link:
                  li = LI(A(name, _href=link))
              else:
                  li = LI(A(name, _href='#null'))
              if len(item)  3 and item[3]:
                  li['_class'] = self['li_class']
                  li.append(self.serialize(item[3], level+1))
 -            if active:
 +            if active or 'active_url' in self.attributes and
 self['active_url']==link:
                  if li['_class']:
                      li['_class'] = li['_class']+' '+self['li_active']
                  else:


web2py_rev1091.patch
Description: Binary data

Re: [web2py] Re: web2py equivalent of Django's pluralize?

[Michael Wolfe]

Thanks for the link.  I can certainly write a function that will do
what I need.  I just wanted to make sure I wasn't reinventing the
wheel (at least with reference to web2py).

-Mike


On Wed, Oct 27, 2010 at 1:32 PM, Vidul Petrov vidul.r...@gmail.com wrote:
 You may want to see this recipe:
 http://code.activestate.com/recipes/413172-numbers-and-plural-words-as-spoken-english/

 The implementation with the help of a module can be easily done.


 On Oct 27, 4:47 pm, mwolfe02 michael.joseph.wo...@gmail.com wrote:
 How do you do this in web2py:

 http://docs.djangoproject.com/en/dev/ref/templates/builtins/?from=old...

 Thanks,
 Mike

[web2py] Remove link in MENU for current url

[Michael Wolfe]

Following the sage advice of Jakob Nielsen, I wanted a way to turn off
links that point to the current page within the menu (see #10 here:
http://www.useit.com/alertbox/20031110.html).  At the bottom of this
e-mail, I'm including a proposed patch that would make this easier.

I've added two optional parameters to the MENU helper: no_link_url and
active_url.

To illustrate how this works, I'll give three examples of what you
would see for the Index link in the welcome scaffolding app by
altering the MENU line from layout.html.

1. Current behavior
{{=MENU(response.menu,_class='sf-menu')}}
lia href=/welcome/default/indexIndex/a/li

2. Removing the link for the current page
{{=MENU(response.menu,_class='sf-menu',no_link_url=request.url)}}
lidivIndex/div/li

3. Adding the class 'active' to the list item of the link to the current page
{{=MENU(response.menu,_class='sf-menu',active_url=request.url,
li_active='active')}}
li class=activea href=/welcome/default/indexIndex/a/li


And here's the patch.  Please let me know if I've missed something.


diff -r 6608e0e6b4f3 -r badb5215df3f applications/welcome/static/base.css
--- a/applications/welcome/static/base.css  Fri Oct 15 07:17:35 2010 -0500
+++ b/applications/welcome/static/base.css  Fri Oct 22 15:11:06 2010 -0400
@@ -216,9 +216,12 @@
 .sf-menu {
float:  left;
 }
-.sf-menu a {
+.sf-menu a, .sf-menu div {
padding: 5px 15px;
 }
+.sf-menu div {
+color: white;
+}
 .sf-menu li {
background: #33;
 }
diff -r 6608e0e6b4f3 -r badb5215df3f gluon/html.py
--- a/gluon/html.py Fri Oct 15 07:17:35 2010 -0500
+++ b/gluon/html.py Fri Oct 22 15:11:06 2010 -0400
@@ -1699,14 +1699,16 @@
 ul = UL(_class=self['ul_class'])
 for item in data:
 (name, active, link) = item[:3]
-if link:
+if 'no_link_url' in self.attributes and self['no_link_url']==link:
+li = LI(DIV(name))
+elif link:
 li = LI(A(name, _href=link))
 else:
 li = LI(A(name, _href='#null'))
 if len(item)  3 and item[3]:
 li['_class'] = self['li_class']
 li.append(self.serialize(item[3], level+1))
-if active:
+if active or 'active_url' in self.attributes and
self['active_url']==link:
 if li['_class']:
 li['_class'] = li['_class']+' '+self['li_active']
 else:

Re: [web2py] Re: StackExchange for web2py community

[Michael Wolfe]

Even as I was writing my last reply, I was steadily coming up with
more reasons for sticking with Google Groups and not moving to Stack
Overflow.  It seems I find my own previous arguments a bit
underwhelming.

I'd still like to see something similar to SO written in web2py.  I'd
like to get around to doing that myself, but if someone wants to try
to beat me to it I'll give you a BIG head start ;).

My final thought on this subject is that I think it would be good if
more than just Massimo were to monitor the web2py tag on SO and answer
questions.  As it stands now, everywhere you look on the web outside
of the Google Group, web2py questions are answered almost exclusively
by Massimo.  To an outsider or newbie it gives the _impression_ that
web2py requires the desperate self promotion of its creator to
succeed.  I've since learned that is certainly not the case, but only
after I joined this mailing list.  Massimo deserves better support
outside the gated walls of this group.

That is all.

-Mike

On Sat, Sep 18, 2010 at 12:59 AM, bally boy ballybo...@gmail.com wrote:
 And yeah on second thoughts about what Michael said, while it can be argued
 that  sheer exclusivity, might stunt the growth of web2py(which even I was
 thinking), I guess there are other ways to spread the word too...

 On Sat, Sep 18, 2010 at 10:24 AM, bally boy ballybo...@gmail.com wrote:

 I am with Massimo on one thing, not to scatter information all around.As a
 platform although both Stack Overflow and Stack exchange are great and
 better than google mailing lists but it does invite a lot of uninvited
 guests who actually know nothing.
 For eg: - let us say someone puts up a post asking how to do this and some
 troll replies that it can never be done on web2py or no web2py is not for
 this etc, the signals that it sends to people who are newbies wont be right,
 and you might find yourself arguing most of the time rather than solving
 issues which is what is currently happening on forums like reddit.
 On the other hand one might argue that it would give a strong platform for
 the entire community to come forward and spread the word, which as of now is
 restricted to only the mailing lists.
 Although I am not in favour of moving out from mailing lists , I would be
 wherever people like Massimo and other core contributors are around.
 If you really want something like stack overflow to be used, guys build
 one... what the hell!.. you use web2py .. dont you!.. I read some post
 wherein someone was actually working on something like it.. 
 One more thing, let us leave the decision to Massimo, ultimately he is the
 one who is going to address most of the issues ...lol!.. let him decide
 where he wants to be!


 On Sat, Sep 18, 2010 at 12:43 AM, Michael Wolfe
 michael.joseph.wo...@gmail.com wrote:

 I understand your concern, Massimo.  However, I think the solution is
 not to ignore SO, but to try to get more knowledgeable web2py users
 answering questions there.  You will still have general knowledge
 folks answering web2py questions, but the voting system should leave
 their answers at the bottom of the page, while the focused answers get
 voted up.

 The biggest problem I currently see with a web2py-centric Stack
 Exchange site is I don't think it has even a tiny chance of getting
 through the ridiculous Area-51 approval process.  I remember seeing
 some posts about somebody working on a web2py-based SO clone.  That
 might be a better option.

 The other issue I have with a separate site just for web2py, whether
 it is Google Groups or web2py.stackexchange, is that some problems may
 not necessarily be web2py specific.  Especially for people new to
 programming and/or python and/or web frameworks it may not be clear
 what their problem really relates to.

 You should know that as I'm writing this I'm having quite a lively
 debate in my own head.  So I apologize if this post is disjointed or
 contradictory.  I guess I can't convince myself strongly one way or
 another of what the best solution is.  I'd hate to lose the community
 and focused knowledge of the Google Group, but I think the very
 exclusiveness of the group may be stunting the growth of web2py.



 On Fri, Sep 17, 2010 at 1:48 PM, spiffytech spiffyt...@gmail.com wrote:
  StackExchange is designed such that people who don't know what they're
  talking about get voted down, while those who have quality answers get
  voted up to the top. When I'm reading StackOverflow, the reading the
  highest-voted questions first makes the poor quality of the lower-
  voted questions very apparent to me, and I distrust them.
 
  Also, a web2py-centric StackExchange should only attract people who
  know about web2py. This is unlike StackOverflow, which caters to a
  general audience and thus gets many people with only general knowledge
  and general answers.
 
  The checks, balances, and filters seem sufficient to me. Do you
  disagree?
 
 
  On Sep 17, 12:30 pm, mdipierro mdipie

Re: [web2py] Re: StackExchange for web2py community

[Michael Wolfe]

I understand your concern, Massimo.  However, I think the solution is
not to ignore SO, but to try to get more knowledgeable web2py users
answering questions there.  You will still have general knowledge
folks answering web2py questions, but the voting system should leave
their answers at the bottom of the page, while the focused answers get
voted up.

The biggest problem I currently see with a web2py-centric Stack
Exchange site is I don't think it has even a tiny chance of getting
through the ridiculous Area-51 approval process.  I remember seeing
some posts about somebody working on a web2py-based SO clone.  That
might be a better option.

The other issue I have with a separate site just for web2py, whether
it is Google Groups or web2py.stackexchange, is that some problems may
not necessarily be web2py specific.  Especially for people new to
programming and/or python and/or web frameworks it may not be clear
what their problem really relates to.

You should know that as I'm writing this I'm having quite a lively
debate in my own head.  So I apologize if this post is disjointed or
contradictory.  I guess I can't convince myself strongly one way or
another of what the best solution is.  I'd hate to lose the community
and focused knowledge of the Google Group, but I think the very
exclusiveness of the group may be stunting the growth of web2py.



On Fri, Sep 17, 2010 at 1:48 PM, spiffytech spiffyt...@gmail.com wrote:
 StackExchange is designed such that people who don't know what they're
 talking about get voted down, while those who have quality answers get
 voted up to the top. When I'm reading StackOverflow, the reading the
 highest-voted questions first makes the poor quality of the lower-
 voted questions very apparent to me, and I distrust them.

 Also, a web2py-centric StackExchange should only attract people who
 know about web2py. This is unlike StackOverflow, which caters to a
 general audience and thus gets many people with only general knowledge
 and general answers.

 The checks, balances, and filters seem sufficient to me. Do you
 disagree?


 On Sep 17, 12:30 pm, mdipierro mdipie...@cs.depaul.edu wrote:
 I oppose and here is why. A few people have asked web2py related
 questions on stack overflow. Almost all of them have at least one
 generic answer by somebody who knows nothing about web2py. On Stack
 overflow there is no sense of community (other than the stack overflow
 community) and people try to answer even when they know nothing about
 the topic.

 Massimo

 On Sep 17, 10:58 am, mwolfe02 michael.joseph.wo...@gmail.com wrote:

  My vote:
  - ask questions on StackOverflow using the existing web2py tag
  - follow the questions using this RSS feed:  
  http://stackoverflow.com/feeds/tag/web2py

  I like StackOverflow a lot and I think it is a much better interface
  than Google Groups.  I asked my first few questions about web2py on SO
  and was a bit reluctant to have to join Google Groups just to get
  answers to my web2py questions.  That said, the user community here is
  second to none.  I've been amazed how quickly my questions have not
  only been answered, but in many cases answered by _core developers_!

  The problem, as I see it, is that like it or not, StackOverflow is
  quickly becoming a tool not only for getting technical questions
  answered, but also to gauge the popularity of various programming
  languages, web frameworks, etc.  When I was trying to decide what web
  framework to use for my most recent project I looked at the most
  popular questions for Django, ASP.NET, etc. as well as the number of
  questions, by tag name, for each of those frameworks.

  The relatively low number of questions (compared to Django, for
  example) and the apparent lack of knowledgeable users (web2py
  questions are answered almost exclusively by Massimo) was nearly
  enough to lead me away from web2py.  It was not until I finally
  relented to Massimo referring me to this Google Group that I was truly
  pleased with my decision to use web2py.

  I think Google Groups remains the proper place to discuss the
  direction of the web2py project.  However, I think we should start
  making an effort to ask and answer web2py technical questions on SO.

  On Sep 16, 10:40 am, cjrh caleb.hatti...@gmail.com wrote:

   On Sep 16, 1:31 pm, Narendran gunanar...@gmail.com wrote:

What does the community
think of having a stackexchange page for web2py?

   Good idea.  The StackOverflow model is the future of technical QA
   forums.   I joined and added some good and bad questions.    We need
   59 more users to join in support.

Re: [web2py] Re: per app routes

[Michael Wolfe]

Great info.  Thanks for taking the time to explain.

-Mike

On Thu, Sep 2, 2010 at 10:16 AM, Jonathan Lundell jlund...@pobox.com wrote:
 On Sep 2, 2010, at 6:40 AM, mwolfe02 wrote:

 Actually, I had commented out routes_app altogether.  When I restored
 it to this, things seemed to work again:

 routes_app = ((r'/(?Pappwelcome|admin|examples|app)\b.*',
 r'\gapp'),
              (r'(.*)', r'my_app'),
              (r'/?(.*)', r'my_app'))

 I was thinking that the logic would work as follows:

 1. if base routes_in exists check URL against base routes_in (if match
 found then rewrite else continue)
 2. if routes_app exists check URL against routes_app (if match found
 then load app-specific routes_in or app-specific default controller/
 function else continue)
 3. if default_app specified then load app-specific routes_in or app-
 specific default controller/function for the default_app
 4. if no default_app specified and URL does not match base routes_in
 or routes_app return error


 First of all, default_* doesn't really have anything to do with rewriting. I 
 added them to routes.py as a convenience, to be able to override the default 
 init/default/index logic that happens after all the routes_in is complete. I 
 would recommend using routes_*  or default_*, but not both.

 routes_app is the first thing we look at. It completely determines which 
 routes.py (base or app-specific) we'll use for the entire request and 
 response. If there's no routes_app, then we'll always use the base routes.py.

 So the rule is actually pretty simple:

 1. If routes_app produces an application name, and that application has its 
 own routes.py, then use that app-specific routes.py. In all other cases, use 
 the base routes.py. (This decision is final for the entire request.)

 2. Using the routes.py determined in (1), apply routes_in to the URL. The 
 best practice, in my view, is for routes_in to always product a complete URL 
 (a/c/f/...).

 3. If the URL does not have all three routing elements /a/c/f, complete it 
 with default_* from the selected routes.py (defaulting in the code to 
 /init/default/index if not overridden).

 4. All subsequent rewriting (routes_out, error rewriting, etc) uses the 
 routes.py selected in (1).

 Note that an app-specfic routes.py is all or nothing. If (1) selects an 
 app-specific routes.py and that routes.py does not contain (say) a 
 routes_out, we do *not* fall back on the base routes_out. Similarly for 
 default_*.




 Once URL rewriting has been redirected to a specific app (as in step 2
 or 3 above) do the following:

 1. if app-specific routes_in exists check URL against app-specific
 routes_in (if match found then rewrite else continue)
 2. if URL maps to an existing controller/function, then call that
 controller/function else continue
 3. if default_controller specified, prepend default_controller to URL
 and try step 2 else continue
 4. if default_controller and default_function specified, prepend
 default_controller/default_function to URL and try step 2 else
 continue
 5. if default_function specified, assume first part of URL is
 controller, insert default_function after assumed controller and
 before any potential function arguments
 6. if nothing matches, return error

 Obviously my assumptions were not entirely correct.  I'm wondering if
 you could pass along a brief overview of how the routes_app,
 default_app, default_controller, and default_function parameters all
 actually do interact in terms of URL rewriting.

 Thanks again,
 -Mike

 On Aug 31, 5:34 pm, Jonathan Lundell jlund...@pobox.com wrote:
 On Aug 31, 2010, at 2:20 PM, Michael Wolfe wrote:







 That didn't seem to quite do it.  Visitinghttp://domain.com/rewrites
 tohttp://domain.com/my_app/default/index/instead of
 http://domain.com/my_app/default/search/.  The URL is being
 substantively rewritten in the parse_url function (lines 802-807) of
 gluon/main.py:

    request.application = \
        regex_space.sub('_', match.group('a') or
 rewrite.params.default_application)
    request.controller = \
        regex_space.sub('_', match.group('c') or
 rewrite.params.default_controller)
    request.function = \
        regex_space.sub('_', match.group('f') or
 rewrite.params.default_function)

 The problem being that rewrite.params.default_function is not using
 the default_function specified in my app-specific routes.py.

 The parse_url function is being called from line 326 of gluon/main.py:

            # ##
            # invoke the legacy URL parser and serve static file
            # ##

            static_file = parse_url(request, environ)

 To be clear, /my_app/default/search/ is not a static file; parse_url
 appears to do double-duty identifying static files and performing
 simple URL re-writes.

 On a side note, I'll be heading home for the day soon and won't be
 working on this project again until

Re: [web2py] Re: per app routes

[Michael Wolfe]

Good to know.

On Thu, Sep 2, 2010 at 10:58 AM, Jonathan Lundell jlund...@pobox.com wrote:
 On Sep 2, 2010, at 7:40 AM, Michael Wolfe wrote:

 Great info.  Thanks for taking the time to explain.

 You're welcome.

 A caveat: I don't believe that the current logic is thread-safe. 
 Consequently, if you have simultaneous requests on different threads that use 
 different routes.py files, one of them could end up using the wrong logic for 
 some or all of its translations.

 I intend to fix it, but I haven't figured out how yet. So if you're using 
 multiple apps in production, I recommend sticking to the base routes.py for 
 now.


 -Mike

 On Thu, Sep 2, 2010 at 10:16 AM, Jonathan Lundell jlund...@pobox.com wrote:
 On Sep 2, 2010, at 6:40 AM, mwolfe02 wrote:

 Actually, I had commented out routes_app altogether.  When I restored
 it to this, things seemed to work again:

 routes_app = ((r'/(?Pappwelcome|admin|examples|app)\b.*',
 r'\gapp'),
              (r'(.*)', r'my_app'),
              (r'/?(.*)', r'my_app'))

 I was thinking that the logic would work as follows:

 1. if base routes_in exists check URL against base routes_in (if match
 found then rewrite else continue)
 2. if routes_app exists check URL against routes_app (if match found
 then load app-specific routes_in or app-specific default controller/
 function else continue)
 3. if default_app specified then load app-specific routes_in or app-
 specific default controller/function for the default_app
 4. if no default_app specified and URL does not match base routes_in
 or routes_app return error


 First of all, default_* doesn't really have anything to do with rewriting. 
 I added them to routes.py as a convenience, to be able to override the 
 default init/default/index logic that happens after all the routes_in is 
 complete. I would recommend using routes_*  or default_*, but not both.

 routes_app is the first thing we look at. It completely determines which 
 routes.py (base or app-specific) we'll use for the entire request and 
 response. If there's no routes_app, then we'll always use the base 
 routes.py.

 So the rule is actually pretty simple:

 1. If routes_app produces an application name, and that application has its 
 own routes.py, then use that app-specific routes.py. In all other cases, 
 use the base routes.py. (This decision is final for the entire request.)

 2. Using the routes.py determined in (1), apply routes_in to the URL. The 
 best practice, in my view, is for routes_in to always product a complete 
 URL (a/c/f/...).

 3. If the URL does not have all three routing elements /a/c/f, complete it 
 with default_* from the selected routes.py (defaulting in the code to 
 /init/default/index if not overridden).

 4. All subsequent rewriting (routes_out, error rewriting, etc) uses the 
 routes.py selected in (1).

 Note that an app-specfic routes.py is all or nothing. If (1) selects an 
 app-specific routes.py and that routes.py does not contain (say) a 
 routes_out, we do *not* fall back on the base routes_out. Similarly for 
 default_*.




 Once URL rewriting has been redirected to a specific app (as in step 2
 or 3 above) do the following:

 1. if app-specific routes_in exists check URL against app-specific
 routes_in (if match found then rewrite else continue)
 2. if URL maps to an existing controller/function, then call that
 controller/function else continue
 3. if default_controller specified, prepend default_controller to URL
 and try step 2 else continue
 4. if default_controller and default_function specified, prepend
 default_controller/default_function to URL and try step 2 else
 continue
 5. if default_function specified, assume first part of URL is
 controller, insert default_function after assumed controller and
 before any potential function arguments
 6. if nothing matches, return error

 Obviously my assumptions were not entirely correct.  I'm wondering if
 you could pass along a brief overview of how the routes_app,
 default_app, default_controller, and default_function parameters all
 actually do interact in terms of URL rewriting.

 Thanks again,
 -Mike

 On Aug 31, 5:34 pm, Jonathan Lundell jlund...@pobox.com wrote:
 On Aug 31, 2010, at 2:20 PM, Michael Wolfe wrote:







 That didn't seem to quite do it.  Visitinghttp://domain.com/rewrites
 tohttp://domain.com/my_app/default/index/instead of
 http://domain.com/my_app/default/search/.  The URL is being
 substantively rewritten in the parse_url function (lines 802-807) of
 gluon/main.py:

    request.application = \
        regex_space.sub('_', match.group('a') or
 rewrite.params.default_application)
    request.controller = \
        regex_space.sub('_', match.group('c') or
 rewrite.params.default_controller)
    request.function = \
        regex_space.sub('_', match.group('f') or
 rewrite.params.default_function)

 The problem being that rewrite.params.default_function is not using
 the default_function specified in my app-specific routes.py

Re: [web2py] Re: per app routes

[Michael Wolfe]

That didn't seem to quite do it.  Visiting http://domain.com/ rewrites
to http://domain.com/my_app/default/index/ instead of
http://domain.com/my_app/default/search/.  The URL is being
substantively rewritten in the parse_url function (lines 802-807) of
gluon/main.py:

request.application = \
regex_space.sub('_', match.group('a') or
rewrite.params.default_application)
request.controller = \
regex_space.sub('_', match.group('c') or
rewrite.params.default_controller)
request.function = \
regex_space.sub('_', match.group('f') or
rewrite.params.default_function)

The problem being that rewrite.params.default_function is not using
the default_function specified in my app-specific routes.py.


The parse_url function is being called from line 326 of gluon/main.py:

# ##
# invoke the legacy URL parser and serve static file
# ##

static_file = parse_url(request, environ)

To be clear, /my_app/default/search/ is not a static file; parse_url
appears to do double-duty identifying static files and performing
simple URL re-writes.


On a side note, I'll be heading home for the day soon and won't be
working on this project again until Thursday.  So if you don't get a
response from me for awhilethat's why.

-Mike


On Tue, Aug 31, 2010 at 4:09 PM, Jonathan Lundell jlund...@pobox.com wrote:
 On Aug 31, 2010, at 12:53 PM, mwolfe02 wrote:

 default_function does not seem to be recognized properly in app-
 specific routes.py.  I'm thinking default_controller may have a
 similar problem, but I'm not really redefining it.

 My base routes.py has default_application set to 'my_app' (and nothing
 set for default_controller or default_function).  In the routes.py
 file for my 'my_app' I have the following set:

 default_controller = 'default'  # ordinarily set in app-specific
 routes.py
 default_function = 'search'      # ordinarily set in app-specific
 routes.py

 When I visit http://domain.com/ I receive the 'invalid function' page
 instead of rewriting to http://domain.com/my_app/default/search/.  I'm
 debugging now and will post back when I learn more.

 OK, making the current app the default turned out to be pretty 
 straightforward, and even if that's not the problem you're having, I think it 
 makes sense to do. Here's the new rewrite.py:

 http://web.me.com/jlundell/filechute/rewrite.zip

[web2py] XML+URL continuing problem

[Michael Wolfe]

Look at revisions 804, 808, and 811 in web2py's hg repos.


R804:
URL+XML, and oauth1.0 from Michele

=== (+6,-3) gluon/html.py ===
@@ -201,8 +201,8 @@

 if regex_crlf.search(url):
 raise SyntaxError, 'CRLF Injection Detected'
-return rewrite.filter_out(url, env)
-
+return XML(rewrite.filter_out(url, env))
+


R808:
no more XML in URL, breaks scaffoling app

=== (+2,-2) gluon/html.py ===
@@ -201,7 +201,7 @@

 if regex_crlf.search(url):
 raise SyntaxError, 'CRLF Injection Detected'
-return XML(rewrite.filter_out(url, env))
+return rewrite.filter_out(url, env)


R811:
fixed problem with URL, thanks Jonathan

=== (+14,-2) gluon/html.py ===
@@ -201,7 +201,7 @@

 if regex_crlf.search(url):
 raise SyntaxError, 'CRLF Injection Detected'
-return rewrite.filter_out(url, env)
+return XML(rewrite.filter_out(url, env))


So which way is it?  I think this still needs to be sorted out.  I'm
going back to R803 for the time being.  It looks like more than just
that one line needs to be changed, since both versions apparently
cause problems in different areas.

-Mike

Re: [web2py] Re: ?code=400ticket=Nonerequested_uri=None

[Michael Wolfe]

Massimo,

I'm not sure anything can be done about it from within web2py (though
Jonathan could certainly answer that better than I).  It appears to be
a limitation of the rocket web server.  It may need to be taken up
with the development team working on Rocket.  Of course, if it's a
problem with Rocket it could be a problem with other web servers.

It seems like the safest thing would be to use one of the environment
variables required by the PEP.  PATH_INFO almost works, but it is
returning the URL _after_ it has been rewritten by routes.py.  Maybe
we can intercept and set the variable before the url is rewritten?
Maybe we would only do that if the web server did not define a
request_uri environment variable?

On Mon, Aug 16, 2010 at 2:56 PM, mdipierro mdipie...@cs.depaul.edu wrote:
 This is important and should be fixed. we will look into it. Perhaps
 Jonathan who has worked on routes extensively can look into this.

 Massimo

 On Aug 16, 1:54 pm, mwolfe02 michael.joseph.wo...@gmail.com wrote:
 Just tested this in my production environment (apache) and it works as
 expected.  I'm having the problem in my dev environment which is
 running the built-in rocket server on windows.  It looks like the
 Rocket server is not providing request_uri as apache with mod_wsgi
 does.

 If you just output the contents of request.env in the two different
 environments you will see the differences.  According to the WSGI PEP
 (http://www.python.org/dev/peps/pep-0333/#environ-variables),
 request_uri is not a required environment variable.  I don't think the
 'requested_uri' functionality for routes_onerror is mentioned in the
 documentation anywhere, but if and when it is a caveat about its
 limitations with respect to different web servers should be mentioned.

 Unfortunately, I spent several hours trying to figure out what I was
 doing wrong before realizing it was not something I had any control
 over.  I hope I can save someone else some trouble in the future.

 -Mike

 On Aug 16, 12:52 pm, mwolfe02 michael.joseph.wo...@gmail.com wrote:

  I'm trying to use routes_onerror, but requested_uri keeps coming
  through as None (subject of this e-mail is the query string from the
  redirect).  I searched through the source code and could not find
  where this is supposed to be set.  I stepped through using WinPDB and
  there is simply no entry in request.env for request_uri.  There is an
  entry for path_info which appears to be the re-written uri (ie, post
  routes.py processing).

  I'm running from trunk.  Please let me know what other info is needed
  to troubleshoot.

  Thanks,
  Mike

Re: [web2py] Re: ?code=400ticket=Nonerequested_uri=None

[Michael Wolfe]

I tried with the query string (?id=1) and I still got requested_uri=None.

In case I'm doing something non-standard that's contributing to the
problem, here is my routes.py file (with comments and doctests
removed):

routes_in = (
  ('/admin/$anything', '/admin/$anything'),
  ('/static/$anything', '/paytaxes/static/$anything'),
  ('/appadmin/$anything', '/paytaxes/appadmin/$anything'),
  ('/favicon.ico', '/paytaxes/static/favicon.ico'),
  ('/robots.txt', '/paytaxes/static/robots.txt'),
  ('/', '/paytaxes/default/search'),
  ('/$anything', '/paytaxes/default/$anything'),
)

routes_out = [(x, y) for (y, x) in routes_in[:-3]]
routes_out.append(('/paytaxes/default/$anything', '/$anything'))

routes_onerror = [
 ('*/400','/error'),
 ('*/*', '/error'),
]

On Mon, Aug 16, 2010 at 3:52 PM, Jonathan Lundell jlund...@pobox.com wrote:
 On Aug 16, 2010, at 11:56 AM, mdipierro wrote:

 This is important and should be fixed. we will look into it. Perhaps
 Jonathan who has worked on routes extensively can look into this.

 I'm a little in the dark on routes_onerror; I recall looking at it a while 
 back when I noticed that its doctest was failing, but I didn't figure it out.

 I looked at some of the logic now, though, and maybe there's a problem buried 
 inside.

 1. main.wsgibase populates request.env by lowercasing environ items (and 
 replacing dots with underscores).

 2. main.parse_url uses path_info in preference to request_uri. If path_info 
 is missing, it parses request_uri into path_info and query_string.

 3. If we're filtering routes_in, AND the rewritten path has a ? in it, we 
 rewrite REQUEST_URI. But otherwise, we never do.

 I wonder if we shouldn't rewrite request_uri in filter_in regardless of 
 whether there's a query string, and perhaps in parse_url, write something 
 into request_uri if it's empty.

 The non-standardization of these variables is a PITA, from what I can tell.

 Another workaround might be for Rocket to go ahead and initialize 
 request_uri, I suppose, but who knows what all the other web servers do? We 
 could also try to rationalize the environment very early in an incoming 
 request, perhaps just before filter_in.

 I hesitate to mess around in this logic, since it's so central to everybody's 
 operation, and I have no idea what accidental features people might be 
 depending on.

 Mike, on the basis of the above, and just as an experiment, you might try the 
 same test but with a query string as part of your URL. If you're rewriting 
 incoming URLs, that should cause request_uri to be initialized, and confirm 
 what I've written above, or at least part of it. In that case, I think it'd 
 be safe enough to write request_uri in the non-query-string case of filter_in.


 Massimo

 On Aug 16, 1:54 pm, mwolfe02 michael.joseph.wo...@gmail.com wrote:
 Just tested this in my production environment (apache) and it works as
 expected.  I'm having the problem in my dev environment which is
 running the built-in rocket server on windows.  It looks like the
 Rocket server is not providing request_uri as apache with mod_wsgi
 does.

 If you just output the contents of request.env in the two different
 environments you will see the differences.  According to the WSGI PEP
 (http://www.python.org/dev/peps/pep-0333/#environ-variables),
 request_uri is not a required environment variable.  I don't think the
 'requested_uri' functionality for routes_onerror is mentioned in the
 documentation anywhere, but if and when it is a caveat about its
 limitations with respect to different web servers should be mentioned.

 Unfortunately, I spent several hours trying to figure out what I was
 doing wrong before realizing it was not something I had any control
 over.  I hope I can save someone else some trouble in the future.

 -Mike

 On Aug 16, 12:52 pm, mwolfe02 michael.joseph.wo...@gmail.com wrote:

 I'm trying to use routes_onerror, but requested_uri keeps coming
 through as None (subject of this e-mail is the query string from the
 redirect).  I searched through the source code and could not find
 where this is supposed to be set.  I stepped through using WinPDB and
 there is simply no entry in request.env for request_uri.  There is an
 entry for path_info which appears to be the re-written uri (ie, post
 routes.py processing).

 I'm running from trunk.  Please let me know what other info is needed
 to troubleshoot.

 Thanks,
 Mike

Re: [web2py] Re: ?code=400ticket=Nonerequested_uri=None

[Michael Wolfe]

It seems like including both might make it easier to troubleshoot
routes.py errors.  It's hard to anticipate which might be more
valuable in error handling, but in debugging at least, more info =
better.

On Mon, Aug 16, 2010 at 3:57 PM, Jonathan Lundell jlund...@pobox.com wrote:
 On Aug 16, 2010, at 12:41 PM, Michael Wolfe wrote:

 I'm not sure anything can be done about it from within web2py (though
 Jonathan could certainly answer that better than I).  It appears to be
 a limitation of the rocket web server.  It may need to be taken up
 with the development team working on Rocket.  Of course, if it's a
 problem with Rocket it could be a problem with other web servers.

 It seems like the safest thing would be to use one of the environment
 variables required by the PEP.  PATH_INFO almost works, but it is
 returning the URL _after_ it has been rewritten by routes.py.  Maybe
 we can intercept and set the variable before the url is rewritten?
 Maybe we would only do that if the web server did not define a
 request_uri environment variable?

 Under certain circumstances, we write WEB2PY_ORIGINAL_URI into the 
 environment. But not always.

 And in error handling, it's not obvious (to me) that we necessarily want the 
 original (vs rewritten) URL. Maybe the query string (as in the current 
 subject line) ought to include them both.

Re: [web2py] Re: Error trying to run db queries from on-line shell

[Michael Wolfe]

Ok.  If it helps with the troubleshooting, I am getting the error when
connecting to SQL Server, not SQLite.  Not sure if the problem is db
backend-specific, but I thought I'd throw it out there.

Thanks for the quick response.

On Fri, Aug 13, 2010 at 10:03 AM, mdipierro mdipie...@cs.depaul.edu wrote:
 nothing. this is a known bug which we think is related to timeout in
 keeping the sqlite connection open. For now use the normal shell.

 On Aug 13, 8:59 am, mwolfe02 michael.joseph.wo...@gmail.com wrote:
 I'm trying to run a very simple select query from the built-in web-
 based shell, but I keep getting the following error:  The cursor's
 connection has been closed.

 Here is the full traceback:

 Traceback (most recent call last):
   File input, line 1, in module
   File ...\web2py\gluon\sql.py, line 3214, in select
     rows = response(query)
   File ...\web2py\gluon\sql.py, line 3209, in response
     db._execute(query)
   File ...\web2py\gluon\sql.py, line 1087, in lambda
     self._execute = lambda *a, **b: self._cursor.execute(*a, **b)
 ProgrammingError: The cursor's connection has been closed.

 What am I doing wrong?  It would be really hand to debug queries
 interactively.

 Thanks,
 Mike

Re: [web2py] Re: Managing routes.py with mercurial checkout

[Michael Wolfe]

Rob,

I haven't used the bookmark extension.  I'll go check that out.
Thanks for the tip.

-Mike

On Mon, Aug 9, 2010 at 10:00 PM, Rob r...@rmdashr.com wrote:
 You could use the hg bookmark extension and keep 2 local branches.
 One branch for upstream code and the other branch for your own
 changes.  Before you did a pull, you'd switch back to your upstream
 branch, pull, switch to local change branch, merge (or rebase) with
 upstream branch, etc...

 At least that's how I do it with git and it works great.

 On Aug 9, 8:20 am, mwolfe02 michael.joseph.wo...@gmail.com wrote:
 I'm just looking for a best practice here.  I am running web2py using
 a clone of the repositoryhttps://web2py.googlecode.com/hg/.  This has
 worked really well for me.  However, I just added a routes.py file.
 Clearly, I want to version control this file, but that requires
 committing the change to my local web2py repository.  That's not a
 problem, except that every time I update to the latest web2py version
 I'll have two heads and have to merge.  The merge should always be
 done without conflicts, but it would be an extra step I'd have to do
 each time.  Also, if I wanted to send patches in at some point in the
 future, would those extra changesets in my local repository cause
 problems?

 I'm pretty well versed in using Mercurial for my own projects, but
 web2py is the first open-source project I've been running from the
 repository.

 My approach would be: Pull -- Update  -- Merge -- Commit.  Is there
 a better way?

 (Note: I'm using TortoiseHg on Windows, so if anyone has specific
 experience with that I'd like to hear that, too.)

 Thanks,
 Mike

Re: [web2py] Re: Managing routes.py with mercurial checkout

[Michael Wolfe]

hg pull --rebase

When researching the bookmarks extension, I came across the rebase
extension (http://mercurial.selenic.com/wiki/RebaseExtension).  This
did exactly what I wanted.

I had committed my routes.py which went in as changeset 760 in my
local repository.  I then ran hg pull --rebase, which downloaded
changesets 760 to 769 from the main web2py repository.  I checked the
log and my routes.py changeset stayed at the head of the repository as
changeset 770.  Very cool.

There's additional info here
(http://mercurial.selenic.com/wiki/RebaseProject) for dealing with
conflicts and other more complicated use cases, but for handling
routes.py it's dead simple.

For those using TortoiseHg for Windows, go to Repository Settings then
click the Edit File button and paste the following lines into the text
file that gets opened:

[extensions]
rebase =

[tortoisehg]
postpull = rebase

Save and close the text file and you should be good to go.  Enjoy!

One final note.  I am keeping a copy of routes.py in my myapp/private
folder as Thadeus/Jonathan suggested.  Seems like a smart best
practice.

On Tue, Aug 10, 2010 at 9:10 AM, Michael Wolfe
michael.joseph.wo...@gmail.com wrote:
 Rob,

 I haven't used the bookmark extension.  I'll go check that out.
 Thanks for the tip.

 -Mike

 On Mon, Aug 9, 2010 at 10:00 PM, Rob r...@rmdashr.com wrote:
 You could use the hg bookmark extension and keep 2 local branches.
 One branch for upstream code and the other branch for your own
 changes.  Before you did a pull, you'd switch back to your upstream
 branch, pull, switch to local change branch, merge (or rebase) with
 upstream branch, etc...

 At least that's how I do it with git and it works great.

 On Aug 9, 8:20 am, mwolfe02 michael.joseph.wo...@gmail.com wrote:
 I'm just looking for a best practice here.  I am running web2py using
 a clone of the repositoryhttps://web2py.googlecode.com/hg/.  This has
 worked really well for me.  However, I just added a routes.py file.
 Clearly, I want to version control this file, but that requires
 committing the change to my local web2py repository.  That's not a
 problem, except that every time I update to the latest web2py version
 I'll have two heads and have to merge.  The merge should always be
 done without conflicts, but it would be an extra step I'd have to do
 each time.  Also, if I wanted to send patches in at some point in the
 future, would those extra changesets in my local repository cause
 problems?

 I'm pretty well versed in using Mercurial for my own projects, but
 web2py is the first open-source project I've been running from the
 repository.

 My approach would be: Pull -- Update  -- Merge -- Commit.  Is there
 a better way?

 (Note: I'm using TortoiseHg on Windows, so if anyone has specific
 experience with that I'd like to hear that, too.)

 Thanks,
 Mike

Re: [web2py] Managing routes.py with mercurial checkout

[Michael Wolfe]

OK, but that still leaves a link to routes.py in the web2py
repository.  Do you use the Pull -- Update -- Merge -- Commit
approach then when you update your web2py repository?

On Mon, Aug 9, 2010 at 11:40 AM, Jonathan Lundell jlund...@pobox.com wrote:
 On Aug 9, 2010, at 8:20 AM, mwolfe02 wrote:

 I'm just looking for a best practice here.  I am running web2py using
 a clone of the repository https://web2py.googlecode.com/hg/.  This has
 worked really well for me.  However, I just added a routes.py file.
 Clearly, I want to version control this file, but that requires
 committing the change to my local web2py repository.  That's not a
 problem, except that every time I update to the latest web2py version
 I'll have two heads and have to merge.  The merge should always be
 done without conflicts, but it would be an extra step I'd have to do
 each time.  Also, if I wanted to send patches in at some point in the
 future, would those extra changesets in my local repository cause
 problems?

 I can describe what I do. It would have to be elaborated a bit to handle 
 multiple applications.

 I keep a separate repository for my application, with a soft link from 
 applications/ to tie it into web2py. I keep my routes.py in 
 applications/myapp/private/, and move or link it to the web2py root as part 
 of installation.

 App-specific routes.py will change this a bit, but it won't completely 
 address the issue, since we still need a base routes.py at the web2py root.

Re: [web2py] Managing routes.py with mercurial checkout

[Michael Wolfe]

Got it.  I think that makes more sense than what I'm doing now.  I
probably outsmarted myself a bit trying to use mercurial to maintain
the copy of web2py that I'm using to run my app (in my defense, when
you've got a nice hammer (mercurial), everything looks like a nail). I
thought about .hgignore as well, but your point is exactly right.
It's a catch-22.

Thanks for sharing your setup.

On Mon, Aug 9, 2010 at 12:19 PM, Jonathan Lundell jlund...@pobox.com wrote:
 On Aug 9, 2010, at 9:06 AM, Michael Wolfe wrote:

 OK, but that still leaves a link to routes.py in the web2py
 repository.  Do you use the Pull -- Update -- Merge -- Commit
 approach then when you update your web2py repository?

 Actually, I misdescribed my configuration slightly.

 I run my app linked to a normally downloaded-and-installed web2py stable, not 
 the hg pull. I use the hg-pulled copy for working on web2py, and not my 
 application.

 If I had to keep the two projects (web2py and my app) in one tree, I think 
 I might use .hgignore in the web2py root to exclude routes.py and my app 
 folder. That's not a complete solution, because .hgignore is itself in 
 web2py's repository.


 On Mon, Aug 9, 2010 at 11:40 AM, Jonathan Lundell jlund...@pobox.com wrote:
 On Aug 9, 2010, at 8:20 AM, mwolfe02 wrote:

 I'm just looking for a best practice here.  I am running web2py using
 a clone of the repository https://web2py.googlecode.com/hg/.  This has
 worked really well for me.  However, I just added a routes.py file.
 Clearly, I want to version control this file, but that requires
 committing the change to my local web2py repository.  That's not a
 problem, except that every time I update to the latest web2py version
 I'll have two heads and have to merge.  The merge should always be
 done without conflicts, but it would be an extra step I'd have to do
 each time.  Also, if I wanted to send patches in at some point in the
 future, would those extra changesets in my local repository cause
 problems?

 I can describe what I do. It would have to be elaborated a bit to handle 
 multiple applications.

 I keep a separate repository for my application, with a soft link from 
 applications/ to tie it into web2py. I keep my routes.py in 
 applications/myapp/private/, and move or link it to the web2py root as part 
 of installation.

 App-specific routes.py will change this a bit, but it won't completely 
 address the issue, since we still need a base routes.py at the web2py root.

Re: [web2py] Managing routes.py with mercurial checkout

[Michael Wolfe]

Thanks, Thadeus.  I'd like to contribute at some point in the future
and I wanted to make sure my design decisions wouldn't make that more
difficult.

I know you are a regular contributor, do you use a similar approach to
what Jonathan uses?  ie, do you run your apps using an 'install' of a
web2py release with a separate clone of web2py for your web2py
development?

On Mon, Aug 9, 2010 at 12:44 PM, Thadeus Burgess thade...@thadeusb.com wrote:
 As far as contributions go, you will just be sending diff files in. As
 long as your diff is clean it should not matter what is in your
 repository. Massimo does not use the hg import/export commands so you
 don't even need to commit any contributions to your local version
 anyways.

 --
 Thadeus





 On Mon, Aug 9, 2010 at 11:19 AM, Jonathan Lundell jlund...@pobox.com wrote:
 On Aug 9, 2010, at 9:06 AM, Michael Wolfe wrote:

 OK, but that still leaves a link to routes.py in the web2py
 repository.  Do you use the Pull -- Update -- Merge -- Commit
 approach then when you update your web2py repository?

 Actually, I misdescribed my configuration slightly.

 I run my app linked to a normally downloaded-and-installed web2py stable, 
 not the hg pull. I use the hg-pulled copy for working on web2py, and not my 
 application.

 If I had to keep the two projects (web2py and my app) in one tree, I think 
 I might use .hgignore in the web2py root to exclude routes.py and my app 
 folder. That's not a complete solution, because .hgignore is itself in 
 web2py's repository.


 On Mon, Aug 9, 2010 at 11:40 AM, Jonathan Lundell jlund...@pobox.com 
 wrote:
 On Aug 9, 2010, at 8:20 AM, mwolfe02 wrote:

 I'm just looking for a best practice here.  I am running web2py using
 a clone of the repository https://web2py.googlecode.com/hg/.  This has
 worked really well for me.  However, I just added a routes.py file.
 Clearly, I want to version control this file, but that requires
 committing the change to my local web2py repository.  That's not a
 problem, except that every time I update to the latest web2py version
 I'll have two heads and have to merge.  The merge should always be
 done without conflicts, but it would be an extra step I'd have to do
 each time.  Also, if I wanted to send patches in at some point in the
 future, would those extra changesets in my local repository cause
 problems?

 I can describe what I do. It would have to be elaborated a bit to handle 
 multiple applications.

 I keep a separate repository for my application, with a soft link from 
 applications/ to tie it into web2py. I keep my routes.py in 
 applications/myapp/private/, and move or link it to the web2py root as 
 part of installation.

 App-specific routes.py will change this a bit, but it won't completely 
 address the issue, since we still need a base routes.py at the web2py root.

Re: [web2py] Re: FreeTDS returns MS SQL money type as Python float, not Decimal

[Michael Wolfe]

Touché!  Point taken on the commercial software :)

As a fall-back plan, there is an acceptable workaround.  I can
explicitly convert the floats I receive into Decimals.  Based on
Massimo's post, it looks like this will only be an issue for money
fields returned from a .executesql statement.  For all other queries
where I can leverage the DAL, I think web2py will handle things just
fine.

I'm going to post a message to the FreeTDS message board and see what
I can learn.


On Fri, Jul 30, 2010 at 11:08 AM, Michele Comitini
michele.comit...@gmail.com wrote:


 2010/7/30 mwolfe02 michael.joseph.wo...@gmail.com

 Ideally, I'd like to avoid having to purchase a commercial product.

 Alas you are using a commercial product.
 indeed this is what you should look at:
 http://www.egenix.com/products/python/mxODBCConnect/

 That said it could be just a problem with the python adapter of freetds
 pymssql.

 Plus, I don't think it would work.  mxODBC appears to be a replacement
 for pyodbc.  It looks like mxODBC uses FreeTDS just like pyodbc.  The
 problem appears to be with FreeTDS, so mxODBC doesn't look like it
 would be a fix for my particular problem.  In fact, mxODBC says as
 much itself:




 (From the mxODBC change log, Changes from 2.0.7 to 3.0.0:
 http://www.egenix.com/products/python/mxODBC/changelog.html)

 Added new experimental subpackage mx.ODBC.FreeTDS which allows
 connecting to MS SQL Server from Unix. This is still far from even
 being called alpha due to the current lack of implementation support
 of many important ODBC APIs in the FreeTDS ODBC driver.

 The problem still seems to be FreeTDS.

 On Jul 30, 9:42 am, Michele Comitini michele.comit...@gmail.com
 wrote:
  you can try with mxodbchttp://www.egenix.com/products/python/mxODBC/
 
  2010/7/30 mwolfe02 michael.joseph.wo...@gmail.com
 
 
 
   For background, refer to related questions on SO:
  http://stackoverflow.com/questions/3364699/
  http://stackoverflow.com/questions/3371795/
 
   I'm developing my app on Windows, but will be deploying it on a Linux
   server.  The following lines are from the top of my db.py:
 
   if os.name=='posix':  #Ubuntu
      db =
   DAL('mssql://user:p...@10.0.8.30/TaxDB?DRIVER={FreeTDS}http://user:p...@10.0.8.30/TaxDB?DRIVER=%7BFreeTDS%7D
   ',
   migrate=False)
   elif os.name=='nt':   #Windows
      db = DAL('mssql://u...@127.0.0.1/TaxDB_Dev?
   Trusted_Connection=Yes', migrate=False)
 
   The problem I am running into is that on Windows, my MS SQL money
   fields are returned as Python Decimals.  However, on Linux, those same
   fields are returned as floats.  I think the issue is with FreeTDS.
   The above lines are the _only_ lines that are different between my
   production and development versions.  Obviously, the environments
   themselves are vastly different.
 
   Is there an alternative to FreeTDS to connect to SQL Server from
   Linux?  Do I need to provide some additional info in my connection
   string?  Am I just stuck because I'm accessing SQL Server from Linux?
 
   Thanks in advance for any insight.

[web2py] LEFT JOIN query as object?

[Michael Wolfe]

I'm still learning web2py, so bear with me.  I am trying to write a
somewhat complex query and would like to build it as a series of
smaller, easier to understand queries.  web2py seems to support this
beautifully for INNER JOINs and WHERE clauses as explained here:
http://www.thadeusb.com/weblog/2010/3/19/increase_productivity_by_using_parameterized_queries_with_web2py

However, it appears that LEFT JOINs are not supported in the same way,
because they are only available from within the .select() method.  I
tried doing this and received the following error:

TypeError: 'SQLJoin' object is not callable

Is there any sort of workaround or am I stuck creating my left joins
when I call .select()?

Thanks,
Mike

[web2py] Can I specify an existing named field as the autonumber ID in a legacy database?

[Michael Wolfe]

I have dozens of tables in an existing MSSQL database all with
autonumber ID primary keys, but none that are named 'id'.  They are
instead named PropertyID, ClientID, etc.  The official documentation
seems to suggest renaming each of these fields to 'id'.  However, that
would require breaking hundreds of existing queries in other
applications that use this database.  Surely there must be some way to
specify a name for an existing autonumber field to be used instead of
'id'.

I'd really like to try web2py because it seems well thought-out, but
if this is not possible it is a deal-breaker for me and I'll have to
go back to Django (at least for this project...and any other future
project that must support legacy databases).

Thanks,
-Mike