[turbogears-commits] [1395] trunk/turbogears/widgets/forms.py: Merging [1394] into trunk
Title: [1395] trunk/turbogears/widgets/forms.py: Merging [1394] into trunk Revision 1395 Author alberto Date 2006-05-06 06:05:56 -0500 (Sat, 06 May 2006) Log Message Merging [1394] into trunk Modified Paths trunk/turbogears/widgets/forms.py Diff Modified: trunk/turbogears/widgets/forms.py (1394 => 1395) --- trunk/turbogears/widgets/forms.py 2006-05-06 11:05:13 UTC (rev 1394) +++ trunk/turbogears/widgets/forms.py 2006-05-06 11:05:56 UTC (rev 1395) @@ -1,6 +1,6 @@ from cherrypy import request from turbogears import validators -from turbogears.util import setlike, DictWrapper, Bunch, request_available +from turbogears.util import setlike, Bunch, request_available from turbogears.widgets.base import Widget, CompoundWidget, WidgetsList, \ WidgetDescription @@ -86,8 +86,7 @@ returnval = value for name, index in path: if isinstance(returnval, dict): -returnval = DictWrapper(returnval) -returnval = getattr(returnval, name, None) +returnval = returnval.get(name, None) if index is not None: if isinstance(returnval, list): try: --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Repository Commits group. To post to this group, send email to turbogears-commits@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-commits -~--~~~~--~~--~--~---
[turbogears-commits] [1398] branches/1.0/newdocs/docs/gs/validation.html: Removed an equal character from the validate decorator
Title: [1398] branches/1.0/newdocs/docs/gs/validation.html: Removed an equal character from the validate decorator
Revision 1398
Author ronald
Date 2006-05-06 14:31:08 -0500 (Sat, 06 May 2006)
Log Message
Removed an equal character from the validate decorator
Modified Paths
branches/1.0/newdocs/docs/gs/validation.html
Diff
Modified: branches/1.0/newdocs/docs/gs/validation.html (1397 => 1398)
--- branches/1.0/newdocs/docs/gs/validation.html 2006-05-06 11:20:02 UTC (rev 1397)
+++ branches/1.0/newdocs/docs/gs/validation.html 2006-05-06 19:31:08 UTC (rev 1398)
@@ -16,7 +16,7 @@
class Root:
@expose(html=gs.templates.welcome)
- @validate=(validators={value : validators.Int()})
+ @validate(validators={value : validators.Int()})
def index(self, value=0, tg_errors=None):
if tg_errors:
# handle the error however you want!
@@ -32,4 +32,4 @@
pAll of the validators are imported into the turbogears.validators module. You can see the validators that are available by looking at the FormEncode validators module and the TurboGears validators module (TODO: need links)./p
pYou can do more advanced validation using a FormEncode validation schema. The validators parameter to expose allows you to pass either a schema or a dictionary as in the example above. For more information about schemas, refer to the a href="" target=_blankFormEncode Validator/a documentation./p
-/body/html
\ No newline at end of file
+/body/html
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups TurboGears Repository Commits group. To post to this group, send email to turbogears-commits@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-commits -~--~~~~--~~--~--~---
[tg-tickets] Re: [TurboGears] #831: Add form validation for identity_from_login
#831: Add form validation for identity_from_login +--- Reporter: [EMAIL PROTECTED] |Owner: anonymous Type: enhancement | Status: new Priority: normal |Milestone: 1.0b1 Component: Identity| Version: 0.9a5 Severity: normal | Resolution: Keywords: | +--- Comment (by alberto): Correction to my comment: You *can* show helpful messages informing why the checks failed in case you really need to, it's rather hacky and prone to break if TG internaals change implementation details, but.. a previous comment explains how. -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/831 TurboGears http://www.turbogears.org/ TurboGears front-to-back web development --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Tickets group. To post to this group, send email to turbogears-tickets@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-tickets -~--~~~~--~~--~--~---
[tg-tickets] Re: [TurboGears] #835: Installation (and Update) of RuleDispatch-0.5a0.dev-r2115 fails on Mac OS X 10.4.6
#835: Installation (and Update) of RuleDispatch-0.5a0.dev-r2115 fails on Mac OS X 10.4.6 --+- Reporter: anonymous |Owner: anonymous Type: defect| Status: new Priority: normal|Milestone: 1.0b1 Component: Installation | Version: 0.9a5 Severity: normal| Resolution: Keywords:| --+- Comment (by anonymous): I tried with both gcc versions (3.3 and 4.0) ... same error ... The binary *is* in the egg ... Now I'm searching the answers to 4 questions: 1. Why is the binary file not found ? 2. Where does the compile error come from ? 3. Is there a way to install !RuleDispatch manually ? 4. How can I debug the installation of an egg ? (The answer to question 3 could be a workaround ... The answer to question 4 could help to find an answer to questions 1 and 2 ...) -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/835 TurboGears http://www.turbogears.org/ TurboGears front-to-back web development --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Tickets group. To post to this group, send email to turbogears-tickets@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-tickets -~--~~~~--~~--~--~---
[tg-tickets] [TurboGears] #837: Alternative Py2.3 compatible quickstart templates
#837: Alternative Py2.3 compatible quickstart templates +--- Reporter: simon | Owner: anonymous Type: defect | Status: new Priority: normal | Milestone: 1.0b1 Component: TurboGears | Version: 0.9a5 Severity: normal |Keywords: template, quickstart, 2.3 +--- [http://groups.google.com/group/turbogears/browse_thread/thread/dd3927ee72062d8e/1fc75b5e1c675685 Discussion]. -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/837 TurboGears http://www.turbogears.org/ TurboGears front-to-back web development --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Tickets group. To post to this group, send email to turbogears-tickets@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-tickets -~--~~~~--~~--~--~---
[tg-tickets] Re: [TurboGears] #727: [PATCH] All widgets provided by TG should have a corresponding WidgetDescription
#727: [PATCH] All widgets provided by TG should have a corresponding WidgetDescription -+-- Reporter: michele |Owner: roger.demetrescu Type: enhancement | Status: assigned Priority: normal |Milestone: Component: Widgets | Version: 0.9a4 Severity: normal | Resolution: Keywords: | -+-- Changes (by roger.demetrescu): * summary: All widgets provided by TG should have a corresponding WidgetDescription = [PATCH] All widgets provided by TG should have a corresponding WidgetDescription -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/727 TurboGears http://www.turbogears.org/ TurboGears front-to-back web development --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Tickets group. To post to this group, send email to turbogears-tickets@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-tickets -~--~~~~--~~--~--~---
[tg-tickets] Re: [TurboGears] #831: Add form validation for identity_from_login
#831: Add form validation for identity_from_login +--- Reporter: [EMAIL PROTECTED] |Owner: anonymous Type: enhancement | Status: new Priority: normal |Milestone: 1.0b1 Component: Identity| Version: 0.9a5 Severity: normal | Resolution: Keywords: | +--- Comment (by [EMAIL PROTECTED]): what if we provide a hook function for validation in validate_identity that a user can define if wanted. i never give errors like 'this password doesn't match this account' - it allows for email harvesting. but i think saying 'you didn't enter anything in here' , 'these characters are invalid for accountnames' , and 'this is way too short' is requisite for a webapp - most general internet users are exceedingly stupid and need to be pushed a bit towards providing the right info. -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/831 TurboGears http://www.turbogears.org/ TurboGears front-to-back web development --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Tickets group. To post to this group, send email to turbogears-tickets@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-tickets -~--~~~~--~~--~--~---
[tg-tickets] Re: [TurboGears] #831: Add form validation for identity_from_login
#831: Add form validation for identity_from_login +--- Reporter: [EMAIL PROTECTED] |Owner: anonymous Type: enhancement | Status: new Priority: normal |Milestone: 1.0b1 Component: Identity| Version: 0.9a5 Severity: normal | Resolution: Keywords: | +--- Comment (by godoy): I dunno... I prefer doing that on my own code, using some mean to also verify how strong / weak is the password. There are lots of JavaScript functions available. After all, having a minimum of 8 chars and accepting 12345678 or abcdefgh or even is not better than accepting a minimum of four and using @!çã... And I *always* loved sites that demand a minimum of n digits but doesn't say that in the login form -- they already said that in the registration form or invitation or welcome message... -- so that somebody doesn't have a clue on how many chars they should start attacking passwords and usernames. The minimum that is said about password length, valid usernames, etc. the better. GMail, for example, just says Username and password do not match. (You provided jgodoy). Orkut, one of the most used web applications today, also have the same message and doesn't provide the username I tried logging in with. So, the requisite for a web app doesn't seem to apply. Yahoo! Groups and MSN do almost the same here, again contradicting your requisites. One must clearly separate login interface from user creation interface, password setting interface, etc. I also have a hidden div with a help message explaining some details -- not too much -- labeled Help on all of my forms, including the login form. This might also be a better solution to the problem. I always tell people to not trying to solve user education/conscientization problems with technical workarounds. It will fail sometime and users will be deceived because they weren't told how to do it the right way before. -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/831 TurboGears http://www.turbogears.org/ TurboGears front-to-back web development --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Tickets group. To post to this group, send email to turbogears-tickets@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-tickets -~--~~~~--~~--~--~---
[tg-tickets] Re: [TurboGears] #825: [PATCH] fix saprovider + finalize abstraction
#825: [PATCH] fix saprovider + finalize abstraction
+---
Reporter: [EMAIL PROTECTED] |Owner: anonymous
Type: defect | Status: new
Priority: normal |Milestone: 1.0b1
Component: TurboGears | Version: 0.9a5
Severity: normal | Resolution:
Keywords: |
+---
Comment (by [EMAIL PROTECTED]):
instead of giving patches, i'll just comment what i did, as some of this
may have been taken care of by recent patches:
soprovider / saprovider
* rename 'visit_class' to visit2identity_class as it is a lookup table
for visit2identity
soprovider / saprovider / app.cfg / model.py
* i renamed visit_identity to visit2identity. i also changed the
namespace to be part of so/sa provider instead of visit. this is because
there is no standard naming scheme in tg for database tables. association
tables tend to either be named CamelCase classa_classb or classa2classb.
We can't do camelcase in the db as there are different backends, and
either several of the legacy tables have _ in them already or there are
the 'tg_' prepended tables that kind of suggest joins, so i opted for the
explict description
soprovider
on a successful validation, there was no logging of the link. saprovider
had it in this spot, so i added it:
{{{
+log.info( associating user (%s) with visit (%s),
user.user_name,
+ visit_key )
}}}
saprovider
* the imports on the top of the file were way out of sync. i made them
more in line with soprovider
* i also added from turbogears.util import load_class as in
soprovider, removed the _load_class function within the class, and
replaced calls to _load_class with load_class
* the SqlAlchemyIdentity class has this: ( note, its in there 2x )
{{{
visit= TG_VisitIdentity.get_by( visit_key= self.visit_key )
}}}
that should really be importing the dynamic class as in soprovider
{{{
visit= visit2identity_class.get_by( visit_key= self.visit_key )
}}}
* the SqlAlchemyIdentityProvider class has the same issue
* create_provider_model
* this depends on activemapper. activemapper doesn't work right
now. i just made the class return early - otherwise the app will break
* this also calls TG_VisitIdentity.table.create() directly, it
should be calling the global class
{{{
-TG_VisitIdentity.table.create()
+visit2identity_class.table.create()
}}}
* the linking of the user to the visit on successful validation also
has this issue
* this class also has a ton of TG_ tables defined in it. i deleted them
all , as they're alread in model.py
savisit.py
this is pretty straightforward -- i took out the activemapper
functionality, and replaced it with the monkeypatch
{{{
-class TG_Visit(ActiveMapper):
-class mapping:
-visit_key= column( String(40), primary_key=True )
-created= column( DateTime, default=datetime.now )
-expiry= column( DateTime )
+tbl__tgvisit = Table('tg_visit', __engine__,
+Column('visit_key', String(40) , primary_key=True),
+Column('created', DateTime , nullable = False ),
+Column('expiry', DateTime ),
+)
+class TG_Visit(object):
+table = tbl__tgvisit
def lookup_visit( cls, visit_key ):
return TG_Visit.get( visit_key );
lookup_visit= classmethod(lookup_visit)
+
+assign_mapper( TG_Visit , tbl__tgvisit )
}}}
model.py
i fixed the imports for the database store that is chosen - it gives you
the right stuff for sqlobject, but its broke for sqlalchemy
{{{
+
+#if $identity != sqlalchemy
from sqlobject import *
from turbogears.database import PackageHub
+#end if
#if $identity == sqlobject
from turbogears import identity
#end if
+#if $identity != sqlalchemy
hub = PackageHub(${package})
__connection__ = hub
# class YourDataClass(SQLObject):
# pass
+#end if
+#if $identity == sqlalchemy
+from sqlalchemy import *
+from sqlalchemy.ext.activemapper import *
+from turbogears.database import PackageEngine
+engine = __engine__ = PackageEngine(${package})
+#end if
}}}
app.cfg
* i removed visit.soprovider.model , and renamed it
identity.soprovider.model.visit2identity -- as its not part of visit, its
part of identity. The namespace was misleading.
* # identity.provider='${identity}' is a commented line, showing the
default provider -- i set it to not be a comment line if sqlalchemy is
chosen, as tg will use sqlobject if sqlalchemy is commented out
* i set 'identity.on=False' for /static and /favicon by default, as that
just kills the server with superfluous db calls
The big this was this -- abstracting the login form:
i'm not showing all of the code here, as you will
[tg-tickets] Re: [TurboGears] #825: [PATCH] fix saprovider + finalize abstraction
#825: [PATCH] fix saprovider + finalize abstraction +--- Reporter: [EMAIL PROTECTED] |Owner: anonymous Type: defect | Status: new Priority: normal |Milestone: 1.0b1 Component: TurboGears | Version: 0.9a5 Severity: normal | Resolution: Keywords: | +--- Comment (by godoy): Too many things for me again, so I'll just comment a few of them. - Class naming convention - We are pursuing PEP8 recommendations, so there is the rule that should apply to our code in TG. Independente code (widgets, plugins, etc.) aren't tied to this commitment, but code written for TG should be changing and being written following these rules. - Using _ gives the idea of a JOIN -- Not to me. Neither in the naming scheme I and other developers and DBAs here use, so this is really subjective. - Changing class names -- I don't see why it needs to be done, specially with things that aren't exposed (visit and identity are tied internally, you don't have to have visit to have identity -- just if you use it as one of the means to find if a user is authenticated or not). - Removing classes because they are available in the model -- What about backwards compatibility? People who started their projects earlier should do what? You've removed something that they didn't have to care before, but now they need to look in the old version's code, find where what they need is defined, copy it to their model.py and then they'll be able to have their functionality back. - Making the same functionality available for SO and SA -- I'm +1 for patches that do that and only that, i.e., no renaming, no relocation. This is a first step. Renaming, relocation, etc. is a second step and should be done thinking about existent applications. - Factoring code and reusing already existing code -- I'm +1 for patches for that as well. Specially if all tests passes and there's no drawback on that approach (sometimes code reuse bring collateral effects and code duplication is intentional). - Fixing table creation -- I'm +1 for a patch for that and only that, without any renaming. Renamings should be done later, in a separate batch of changes. - Using __ as in tbl__tgvisit -- I don't like and don't see a reason for it. What is the meaning of __ here? Python has special meanings for __ prefixing a name, making it private, _ making it non-public. Those are conventions widely used in Python code and I believe it is a good thing to stick to them, since this is widely documented. But it is just my opinion, I don't speak officially for TG or for the other developers. - identity.on = False for static -- I'm against that, at least another person on the mailing list was as well. This prevent people from direct linking to your static resources. A patch for the docs talking about this possibility is welcome, but I don't believe that it should be changed in the configuration files. - Too many things to read and comment on a web interface is a really bad and annoying thing. Discussions like that would be much more productive at the trunk mailing list with an hyperlink here pointing to the discussion. Decisions should be placed back here either as patches, commit notes or even some text, just for feedback. - These are mine and mine only opinions. Other people might agree or not with this... -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/825 TurboGears http://www.turbogears.org/ TurboGears front-to-back web development --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Tickets group. To post to this group, send email to turbogears-tickets@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-tickets -~--~~~~--~~--~--~---
[tg-tickets] Re: [TurboGears] #727: [PATCH] All widgets provided by TG should have a corresponding WidgetDescription
#727: [PATCH] All widgets provided by TG should have a corresponding WidgetDescription -+-- Reporter: michele |Owner: roger.demetrescu Type: enhancement | Status: assigned Priority: normal |Milestone: Component: Widgets | Version: 0.9a4 Severity: normal | Resolution: Keywords: | -+-- Comment (by roger.demetrescu): That's ready to go... there's still one widget missing: PaginateDataGrid... I've got some errors running a WidgetDescription for PaginateDataGrid... :( And I'd like to thanks: * Max: for writing a cool example Using DataGrid without a 'model' in http://trac.turbogears.org/turbogears/wiki/DataGridWidget. * Godoy: for the idea of Range fieldset and the help with TableForm/ListForm save actions... Cheers Roger -- Ticket URL: http://trac.turbogears.org/turbogears/ticket/727 TurboGears http://www.turbogears.org/ TurboGears front-to-back web development --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Tickets group. To post to this group, send email to turbogears-tickets@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-tickets -~--~~~~--~~--~--~---
[tg-trunk] Re: fastdata-incompatible change in widgets?
On 05/05/2006, at 16:09, Jorge Godoy wrote: Em Sexta 05 Maio 2006 10:59, Alberto Valverde escreveu: I agree with Michele on this, it's really better to have Just One Way of passing values to compound widgets: a dict. Amen! I've committed the fix for this issue at [1390] (1.0) and [1391] (fastdata). The change should be invisible to users unless they override DataController.edit() In, this case, the value sent to the form should be converted explicitly by database.so_to_dict(). Bottom line: CompoundWidgets (which Forms are a descendant of) *always* receive a dict as value. Question: In which changelog should I mention this? Is there a changelog for FastData or should I mention in TG's? Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Changes in CalendarDatePicker
On 05/05/2006, at 23:31, Jorge Godoy wrote: I can't tell exactly what or when it happened, but not I can't access pages with a CalendarDatePicker where there's a date filled in. If it is empty, it opens fine, but if I put some value in it then it fails. This should be fixed since r1391. Can you please update both trunk/ 1.0 *and* TGFastData to confirm? Thanks, Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Small change to how params (a dict in particular) are managed
Alberto Valverde wrote: Yep, that automatic updating of dicts (and extending for lists) is rather magical an unintuitive, however, I'm not sure of the consequences it will have for existing code. I can bet I'll need to tweak some of my widgets (TinyMCE with 'mce_options' pops to mind). I'm not sure... :/ For example, updating attrs makes sense as it reduces boilerplate (you would normally want to keep other default attrs) Yes, updating attrs makes sense indeed. :-/ So i'd say go for it, even do it for lists too (no extending) It was probably a bad decision to update them back a long time ago. However, I wouldn't call it a small change ;) We aren't extending list AFAIK, and yes it was a bad decision and it was mine... :-( Anyway I'm not going to do this today but I've finished the patch to add group support to SingleSelectField and Multiple (we can do the same for Radio and ChecBox lists but I haven't yet done it as I'm not sure about the best markup to use). The final patch is here: http://trac.turbogears.org/turbogears/attachment/ticket/490/optsupport.patch It's ***totally*** backward compatible with old templates also (that are still used by RadioButtonList and CheckBoxList infact), if you want to group things you use this syntax that is the best beat after a dict IMHO: op1 = [(1, python), (2, ruby)] op2 = [(3, java), (4, c)] options = [(Dynamic Languages, op1), (Others, op2)] you can also use group and non groups mixed: op0 = [(1, python), (2, ruby)] op1 = [(3, python), (4, ruby)] op2 = [(5, java), (6, c)] options = [(None, op0), (Dynamic Languages, op1), (Others, op2)] The patch also contains a small fix for the FormField since in an older commit I had made label and help_text variable at display, this shouldn't happen since they are accessed as attributes usually. All tests are running fine, please guys check it and if you want it in for 0.9a6 commit it as I'm going offline now. Regarding the dict issue if you want to do it, ok for me or we can wait for the next release here. Ciao Michele --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: Small change to how params (a dict in particular) are managed
On 06/05/2006, at 12:19, Michele Cella wrote: Alberto Valverde wrote: Yep, that automatic updating of dicts (and extending for lists) is rather magical an unintuitive, however, I'm not sure of the consequences it will have for existing code. I can bet I'll need to tweak some of my widgets (TinyMCE with 'mce_options' pops to mind). I'm not sure... :/ For example, updating attrs makes sense as it reduces boilerplate (you would normally want to keep other default attrs) Yes, updating attrs makes sense indeed. :-/ So i'd say go for it, even do it for lists too (no extending) It was probably a bad decision to update them back a long time ago. However, I wouldn't call it a small change ;) We aren't extending list AFAIK, and yes it was a bad decision and it was mine... :-( Ooops, I expressed myself wrong here... we aren't extending, but copying, anyway, it probably wasn't that bad of a decision because it makes a lot of sense for attrs :) Regarding the dict issue if you want to do it, ok for me or we can wait for the next release here. I think it would be better to wait because the change will most probably have some side effects (in TinyMCE, for example, I'm sure in other cases too...) which I think it's better for us to see and gauge in 1.0 branch before freezing them in a release. Just my opinion though, maybe it's better to release it and see how it affects in the wild :) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: fastdata-incompatible change in widgets?
On 06/05/2006, at 12:08, Alberto Valverde wrote: Question: In which changelog should I mention this? Is there a changelog for FastData or should I mention in TG's? [1384] answered my question. Be mentioning it in a second. Sorry for forgetting to add the get_*_url changes (and thanks for adding it :) Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[tg-trunk] Re: fastdata-incompatible change in widgets?
On 5/6/06, Alberto Valverde [EMAIL PROTECTED] wrote: On 06/05/2006, at 12:08, Alberto Valverde wrote: Question: In which changelog should I mention this? Is there a changelog for FastData or should I mention in TG's? [1384] answered my question. Be mentioning it in a second. Sorry for forgetting to add the get_*_url changes (and thanks for adding it :) The one bit of mail I'm good about reading is the commit log :) Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears Trunk group. To post to this group, send email to turbogears-trunk@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears-trunk -~--~~~~--~~--~--~---
[TurboGears] Re: New logging is killing me :)
Ah, I see. I changed the dev.cfg and now I get this: File start-soup.py, line 23, in ? modulename=soup.config.app) File /usr/lib/python2.4/site-packages/TurboGears-0.9a5-py2.4.egg/turbogears/config.py, line 181, in update_config configure_loggers(configdict) File /usr/lib/python2.4/site-packages/TurboGears-0.9a5-py2.4.egg/turbogears/config.py, line 132, in configure_loggers _get_loggers(loggers, handlers) File /usr/lib/python2.4/site-packages/TurboGears-0.9a5-py2.4.egg/turbogears/config.py, line 84, in _get_loggers raise ConfigError(Logger %s references unknown turbogears.config.ConfigError: Logger soup references unknown handler debug_out Must I tell him that log.cfg is in config folder or anything like that? Thanks, Sebastjan On 5/6/06, Kevin Dangoor [EMAIL PROTECTED] wrote: On 5/5/06, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: This is my dev.cfg: server.log_to_screen = False cache_filter.on = False server.environment = development server.thread_pool = 5 # Some server parameters that you may want to tweak server.socket_port=8080 # Disable the debug output at the end on pages. log_debug_info_filter.on = False autoreload.on = True autoreload.package=soup It looks like you're missing [logging] here It's nice that you add so many features and all but please, before adding anything, create some basic examples of usage or at least have more explicit error messages. Blank screen can't really help me. It *is* mysterious that logging stopped working in a dev config where you weren't logging to a file. (I believe Patrick Lewis offered to write up some docs. In the meantime, the new logging is pretty much the same as the Python stdlib logging, so you can look at the stdlib docs. They're somewhat inscrutible, but better than nothing... That's what I had to work with when making this config work.) Btw, [[[blah]]] is really ugly :) If you look at the logging docs, I think you'll find that it's better than what stdlib logging does! (I won't dispute that [[[]]] is a bit much.) PS: I noticed that application doesn't restart anymore after changes to def.cfg. Is that a bug or a feature? AFAIK, config changes have never triggered a restart (and I've definitely looked at the autoreload code from time to time). That code specifically looks through sys.modules for things that have changed. Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: KID got error while process javascript operator
On 06/05/2006, at 3:19, Wenjie He wrote: Anybody have occur such situation? While using javascript operator in KID template, KID can't parse template to html, and raise ExpatError: not well-formed (invalid token) How can I do a logic and operation in a kid template, instead? Changing to amp;amp should do the trick. HTH, Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] ANN: CherryPy book
Hello all, I am pleased to announce that I will be writing a book on CherryPy which will published by Packt Publishing [1]. Packt is a fairly recent publishing company based in the United Kingdom which has focused since the beginning in providing the developer community with books specific to their day to day tasks. I have been dealing with the guys at Packt for a bit more than a month and I can tell you that they are really excited by a book on CherryPy as I am. In fact if you are looking for a friendly and ready to support publisher, go and contact them [2]. The approach taken for the book is to go through the design of an application and see how CherryPy can be a great choice for rapid web application development. Throughout the book I will explain concepts behind CherryPy itself as well as third-party products such as ORMs and template engines. At the end of the book as an application developer you will understand how CherryPy can benefit you for web development while having a good overview of the CherryPy's design. Even though it will be a standalone book, I also believe that the book might be a good extension to the TurboGears book [3]. I cannot deny I am really thrilled by the project and I hope being able to finish it in a not far future for you guys. Stay tuned. - Sylvain http://www.defuze.org [1] http://www.packtpub.com/ [2] https://www.packtpub.com/article/aboutus [3] http://groups.google.com/group/turbogears-announce/browse_frm/thread/b960a318531cb9a0 --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: Time running out for Summer of Code!
We are under PSF (Python Software Fundation). Cheers, Simon Petro Verkhogliad wrote: i would like to submit an application. however, i dont see TurboGears as one of the organizations. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: 0.9a5 on python2.3 - anyone have working?
Although we could be nice and make quickstart gnostic about Python versions. Cheers, Simon Kevin Dangoor wrote: Hi Hal, The official stance is that 2.3 is supported, but it's not the encouraged platform. By that, I mean that all code in the turbogears.* package is 2.3 compatible, but the examples and the quickstart templates are geared toward 2.4 users. Luckily, 0.9a5 includes a convenient syntax for decorators, which should make changing a quickstart project a piece of cake. @expose(template=...) becomes [expose(template=...)] We have Phillip Eby and Simon Belak to thank for that little bit of magic. The standard 2.3 way to use a decorator is: index = expose(template=...)(index) which is far less pleasant, and that's the reason why it's not the default for quickstart. Kevin On 5/5/06, hal [EMAIL PROTECTED] wrote: I'm not seeing traffic on this issue, or open trac issues. However, there's at least one obvious bug in a 0.9a5 quickstart generated project (2.4. decorator, rather than 2.3 compatible syntax) which hasn't been reported, so it doesn't feel like anyone is using it. Before I start going through lots of issues - can anyone report success? Is there still demand for this? (My shop is stuck on py2.3 for a while yet) -- Simon Belak vodja projektnih skupin e: [EMAIL PROTECTED] - Hruska d.o.o., agencija za nove medije Ilirska 21, SI-1000 Ljubljana t: +386 1 430 25 86 f: +386 1 430 25 87 s: http://www.hruska.si s: http://akademija.hruska.si (izobrazevalni portal) s: http://www.elor.si (kadrovski sistem letnih razgovorov) Hruska.si - socne resitve To elektronsko sporocilo in vse morebitne priloge so poslovna skrivnost in namenjene izkljucno naslovniku. Ce ste sporocilo prejeli pomotoma, Vas prosimo, da obvestite posiljatelja, sporocilo pa takoj unicite. Kakrsnokoli razkritje, distribucija ali kopiranje vsebine sporocila je strogo prepovedano. This e-mail and any attachments may contain confidential and/or privileged information and is intended solely for the addressee. If you are not the intended recipient (or have received this e-mail in error) please notify the sender immediately and destroy this e-mail. Any unauthorized copying, disclosure or distribution of the material in this e-mail, or any action taken or omitted to be taken in reliance on it, is strictly prohibited. --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: 0.9a5 on python2.3 - anyone have working?
On 06/05/2006, at 12:55, Simon Belak wrote: Although we could be nice and make quickstart gnostic about Python versions. You mean generating different content for each version? In this case I think it'd be better to templatize the [] syntax to make sure quickstarted apps work in both versions. my .2€ Alberto --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: New logging is killing me :)
AFAIK, config changes have never triggered a restart (and I've definitely looked at the autoreload code from time to time). That code specifically looks through sys.modules for things that have changed. Kevin Weren't the config files in .9a1 or .9a2 written in Python? They may have been imported as modules. -Rob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: KID got error while process javascript operator
On May 6, 2006, at 2:41 AM, Alberto Valverde wrote: On 06/05/2006, at 3:19, Wenjie He wrote: Anybody have occur such situation? While using javascript operator in KID template, KID can't parse template to html, and raise ExpatError: not well-formed (invalid token) How can I do a logic and operation in a kid template, instead? Changing to amp;amp should do the trick. Alternatively, keep your JavaScript out of the template. You really shouldn't put anything dynamic in there anyway. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: mysql server has gone away, again
I was able to fix this -- unfortunately the fix is in MySQLdb. You need to set an option to auto-reconnect on the C-layer MYSQL object, and as far as I can tell MySQLdb does not expose an interface into python to do this. The essential part of the solution is to make the following call after the mysql_real_connect() in _mysql.c:_mysql_ConnectionObject_Initialize(): my_bool bool = 1; mysql_options(conn, MYSQL_OPT_RECONNECT, bool); I'll submit a patch to MySQLdb at sourceforge that exposes an interface for this, so that the behavior may be controlled by SQLObject/TG. If anyone wants this patch (which is a bit long to post due to all the C/python API stuff), just send an email. Paul -- Paul Eastham [EMAIL PROTECTED] http://pauleastham.com --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: 0.9a5 on python2.3 - anyone have working?
On 06/05/2006, at 12:55, Simon Belak wrote: Although we could be nice and make quickstart gnostic about Python versions. You mean generating different content for each version? In this case I think it'd be better to templatize the [] syntax to make sure quickstarted apps work in both versions. Ick. As cool a hack as it is, I wouldn't want to put the non-standard [] syntax into a Python 2.4 project. Simon's point is valid, though: we can easily make the template wise to the Python version in use. It's worth opening a ticket on. Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: New logging is killing me :)
On 5/6/06, Sebastjan Trepca [EMAIL PROTECTED] wrote: Ah, I see. I changed the dev.cfg and now I get this: File start-soup.py, line 23, in ? modulename=soup.config.app) File /usr/lib/python2.4/site-packages/TurboGears-0.9a5-py2.4.egg/turbogears/config.py, line 181, in update_config configure_loggers(configdict) File /usr/lib/python2.4/site-packages/TurboGears-0.9a5-py2.4.egg/turbogears/config.py, line 132, in configure_loggers _get_loggers(loggers, handlers) File /usr/lib/python2.4/site-packages/TurboGears-0.9a5-py2.4.egg/turbogears/config.py, line 84, in _get_loggers raise ConfigError(Logger %s references unknown turbogears.config.ConfigError: Logger soup references unknown handler debug_out Must I tell him that log.cfg is in config folder or anything like that? You probably need to alter your start script to point to yourproject.config rather than yourproject.config.app. Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: New logging is killing me :)
On 5/6/06, Robin Haswell [EMAIL PROTECTED] wrote: AFAIK, config changes have never triggered a restart (and I've definitely looked at the autoreload code from time to time). That code specifically looks through sys.modules for things that have changed. Kevin Weren't the config files in .9a1 or .9a2 written in Python? They may have been imported as modules. They were basically Python, but they weren't imported... they were exec'ed in a special namespace. Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: KID got error while process javascript operator
Nah Javascript is fine in templates. All you need to do is place it in !-- -- comments for non-javascript-aware browsers. That includes Kid. -Rob Bob Ippolito wrote: On May 6, 2006, at 2:41 AM, Alberto Valverde wrote: On 06/05/2006, at 3:19, Wenjie He wrote: Anybody have occur such situation? While using javascript operator in KID template, KID can't parse template to html, and raise ExpatError: not well-formed (invalid token) How can I do a logic and operation in a kid template, instead? Changing to amp;amp should do the trick. Alternatively, keep your JavaScript out of the template. You really shouldn't put anything dynamic in there anyway. -bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: New logging is killing me :)
You probably need to alter your start script to point to yourproject.config rather than yourproject.config.app. Yep, that was it. Thanks a lot. Sebastjan On 5/6/06, Kevin Dangoor [EMAIL PROTECTED] wrote: On 5/6/06, Robin Haswell [EMAIL PROTECTED] wrote: AFAIK, config changes have never triggered a restart (and I've definitely looked at the autoreload code from time to time). That code specifically looks through sys.modules for things that have changed. Kevin Weren't the config files in .9a1 or .9a2 written in Python? They may have been imported as modules. They were basically Python, but they weren't imported... they were exec'ed in a special namespace. Kevin --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: sqllite script to 0.9a5 [ was Re: [TurboGears] Re: TurboGears 0.9a5 released!]
Em Sábado 06 Maio 2006 02:22, Olli Wang escreveu: hi, could you tell me how to use the identity-migrate-09a4-to-09a5-sqlite.sql? i'm new and totally have no idea For the PostgreSQL version there are instructions on the ticket where you found the file. It is basically to run it through psql in your database. For MySQL you'd have to grab the other file and then use it. But note that this fixes it for the standard SQL Object provider. I haven't checked if it updates the tables to work with a default quickstarted project using the model inside the project instead of the old style where it was defined in TG itself... -- Jorge Godoy [EMAIL PROTECTED] --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: 0.9a5 on python2.3 - anyone have working?
Kevin Dangoor wrote: On 06/05/2006, at 12:55, Simon Belak wrote: Although we could be nice and make quickstart gnostic about Python versions. You mean generating different content for each version? In this case I think it'd be better to templatize the [] syntax to make sure quickstarted apps work in both versions. Ick. As cool a hack as it is, I wouldn't want to put the non-standard [] syntax into a Python 2.4 project. Simon's point is valid, though: we can easily make the template wise to the Python version in use. It's worth opening a ticket on. Opened as #837. Cheers, Simon --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: KID got error while process javascript operator
On 5/6/06, Robin Haswell [EMAIL PROTECTED] wrote: Nah _javascript_ is fine in templates. All you need to do is place it in !-- -- comments fornon-_javascript_-aware browsers. That includes Kid.I usually use XML comments to hide my _javascript_. It seems like a more natural solution than ![CDATA ]]. On the other hand, I agree with Bob. Putting your _javascript_ into a .js file is a better solution for _javascript_ that is not dynamically created. -- Davidhttp://www.traceback.org --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: KID got error while process javascript operator
On May 6, 2006, at 4:19 PM, David Stanek wrote:On 5/6/06, Robin Haswell [EMAIL PROTECTED] wrote: Nah _javascript_ is fine in templates. All you need to do is place it in !-- -- comments fornon-_javascript_-aware browsers. That includes Kid.I usually use XML comments to hide my _javascript_. It seems like a more natural solution than ![CDATA ]]. On the other hand, I agree with Bob. Putting your _javascript_ into a .js file is a better solution for _javascript_ that is not dynamically created. Using comments to wrap something that you want to keep in the document is a bad idea. Sure, it might happen to work with Kid, but I still wouldn't do it or recommend it.-bob --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups TurboGears group. To post to this group, send email to turbogears@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/turbogears -~--~~~~--~~--~--~---
[TurboGears] Re: couldn't load static dir with scgi/wsgi
I just found if I change setting to:
$HTTP[url] !~ ^/project-name/static/ {
scgi.server = (
/ =
( 127.0.0.1 =
(
host = 127.0.0.1,
port = 4000,
check-local = disable
)
)
)
}
then I could open static file at /project-name/static/*, but it shold
be /static/*, may someone help me?
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
TurboGears group.
To post to this group, send email to turbogears@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at http://groups.google.com/group/turbogears
-~--~~~~--~~--~--~---
