[tg-trunk] Re: TG/Paster/Cheetah
Ian Bicking ha scritto: If someone can suggest a templating language that is really small and general (i.e., conditionals, loops, and arbitrary expressions like repr()) then I would be quite happy to include that directly in Paste Script. Maybe there's something in the Python Cookbook; I should probably check. The requirements here are much different from other situations; I don't think there's a lot to be won by keeping the same templating language as for other situations. The only problem with Cheetah is the installation problems. Never used it myself so I don't know if it's the right answer or not, anyway: http://www.reportlab.org/preppy.html Licensed under FreeBSD. 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?hl=en -~--~~~~--~~--~--~---
[TurboGears] Re: Startup/restart time
I don't think that CP is the problem but rather TG that imports a lot of things on startup even if usually you don't need *all* of them. CP itself is pretty fast, at least here... Ciao Michele Steve Holden wrote: Is it just me, or does CherryPy take a *really* long time to start up and restart? regards Steve -- Steve Holden +44 150 684 7255 +1 800 494 3119 Holden Web LLC/Ltd http://www.holdenweb.com Skype: holdenweb http://holdenweb.blogspot.com Recent Ramblings http://del.icio.us/steve.holden --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: how can I determine if a method is exposed programatically?
Jorge Vargas wrote: On 10/14/06, Kevin Dangoor [EMAIL PROTECTED] wrote: if not getattr(method[1], exposed, False) we do indeed set exposed on exposed methods (otherwise CP would ignore them) umm why it doesn't works? as method[1].exposed? I guess CP does something more then just setting a flag. CP just looks for the presence of exposed=True. I think you're getting problem by accessing directly method[1].exposed since *only* exposed method have this attribute (usually with a True value) that's why you should use a failsafe solution like getattr since you may find other methods that lacks it. 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Trying to understand widget code - request.tg_widgets_path
Gregor Horvath wrote: Hi, I am trying to understand the path creation of widgets. forms.py def append_to_path(widget, repetition): path = [] if request_available(): if hasattr(request, tg_widgets_path): path = request.tg_widgets_path if path: print requestpath: %s % path /forms.py Hi Gregor, The attribute is setted the first time a widget tries to append itself to the path: http://trac.turbogears.org/turbogears/browser/trunk/turbogears/widgets/forms.py#L60 60 else: 61 request.tg_widgets_path = path Hope this helps. ;-) Ciao Michele --~--~-~--~~~---~--~~ 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: Trying to understand widget code - request.tg_widgets_path
Gregor Horvath wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi Michele, Michele Cella schrieb: The attribute is setted the first time a widget tries to append itself to the path: http://trac.turbogears.org/turbogears/browser/trunk/turbogears/widgets/forms.py#L60 Thanks for your help, but actually this setting is always to []. Look at the function, line 61 could also be written as: request.tg_widgets_path = [] path is at line 61 always []. def append_to_path(widget, repetition): 56path = [] 57if request_available(): 58if hasattr(request, tg_widgets_path): 59path = request.tg_widgets_path 60else 61request.tg_widgets_path = path Yeah, that's just the initialization stuff to sync the path variable to what actually resides on tg_widgets_path, if tg_widgets_path it's not there it's initialized as an empty list, and just after that: 63 path.append(Bunch(widget=widget, 64repetition=repetition)) the widgets (if not already there) it's appended to the path. I'm the one to blame for this code, I know it's not so nice as today I wouldn't rewrite it in this way probably, I 'm also not happy with tg_widgets_path but at that time it seemed like the only viable solution to avoid the need for widgets users to pass explicitly the path as an argument upon display. BTW I'm really looking forward to Alberto improvements. ;-) Ciao Michele --~--~-~--~~~---~--~~ 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: Now if Google would just host SVN...
fumanchu wrote: http://groups-beta.google.com/group/turbogears/web Cool... and google host svn (along with an issue tracking): http://code.google.com/hosting/ ;-) Ciao Michele --~--~-~--~~~---~--~~ 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: i18n lazystring; how to submit a patch
Hi Gregor,
That's not a problem, I guess what you're trying to do is localizing
the field label, to do this you need to use the label argument to a
widget constructor.
text = widgets.TextArea(name=comment, label=_(Beschreibung),
validator=validators.NotEmpty())
Note that localizing the name itself is a very bad idea (that
fortunately doesn't even work) since your method will receive
parameters localized and I don't think you really want to work with
localized variables names or dictionary keys. ;-)
Hope this helps.
Ciao
Michele
Gregor Horvath wrote:
Hi,
My apologize that my first post with this subject had a wrong reference
to an unrelated thread.
I therefore repeat my problem now in a seperate thread:
this:
text = widgets.TextArea(name=_(Beschreibung),
validator=validators.NotEmpty())
produces error while starting start-project.py:
File
/usr/lib/python2.4/site-packages/TurboGears-1.0b1-py2.4.egg/turbogears/widgets/forms.py,
line 140, in __init__
if name is not None and ('-' in name or '.' in name):
TypeError: iterable argument required
this does work:
text = widgets.TextArea(name=_(Beschreibung).eval(),
validator=validators.NotEmpty())
I checked the sourcecode and the problem seems to be that lazystring
does not implement all requiered string attributes. (iterator, len etc.)
I am thinking of fixing this and supplying a patch for it.
I am new to TG development.
I searched the trac but couldn't find information to this.
What's the best procedure to do so?
Should I send the patch to the mailing list?
--
Greg
--~--~-~--~~~---~--~~
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 TurboGears installer, please test
Jorge Godoy wrote: Rezand [EMAIL PROTECTED] writes: Yet, it appears to have installed python to /usr/bin and /usr/lib. As a result, when I try to use any of the turbogears installers, I get an error (pasted at the end of this post) as it tries to install to the site-packages directory under /usr/local/lib. What makes sense since these are not packaged installations and they apply to your local machine only (hence it can't be /usr/share). With the ez_setup.py, it's easier to get this to work by using the -d parameter to redirect it. I don't seem to have any such easy mechanism to remedy this using your new script installer. I prefer this kind of separation. It is also easier to see what has been installed outside of my package manager and include it on my backups or migration from development server to production server proccess. All what it took me was create /usr/local/lib/python2.4/site-packages and voi là! Everything got easier to maintain (as I said, no need to check what files in /usr/lib/python2.4/site-packages belong to some RPM and what were hand installed) :-) This was a recent change in SuSE. It wasn't like that a while ago, so I believe this is some compilation option for Python. As you have the source you can change that, generate new python packages and have your easy_installed packages put on the same place as RPM packages without passing any option (you could also make an alias to easy_install passing the -d option making it transparent for you...). You can configure it by using a .pydistutils.cfg in your home directory: [EMAIL PROTECTED]:~$ cat .pydistutils.cfg [install] prefix=/usr/local [easy_install] site-dirs=/usr/local/lib/python2.4/site-packages Ciao Michele --~--~-~--~~~---~--~~ 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: Widget Customisation
Anton2 wrote: Hi. I want to customise the TextField class to include error handling, so that a display() of a TextField will display any error message (and help text too, after...). Basically, I want to be able to trigger the logic used to display label, field, error and helptext in TableForm (with a differnet template), on a field by field basis in the kid template. Is it possible by just overloading the TextField template ? In this case, how can I get the field object to call error_for(field) in the template ? If this is not the right solution, what pointer can you give me to solve this problem ? Many thanks IIRC there should be an error variable available to the FormField template that gives you the field error. Ciao Michele --~--~-~--~~~---~--~~ 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: EVALUATION - TurboGears Persistency System
Ilias Lazaridis wrote: I would like to evaluate TurboGears for use within a personal project and was wondering which version to use best at this point. The evaluation focuses initially on the persistence system and would look somehow like this: http://case.lazaridis.com/wiki/DjangoProductFictional I don't like the used Car model, and would prefere to use a more intuitive model. Any suggestions are welcome. Sincerely, I suggest you evaluate this page: http://en.wikipedia.org/wiki/Ilias_Lazaridis Ciao Michele --~--~-~--~~~---~--~~ 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: getting and storing favicon.ico as an image
Mmmm, is there a reason you're posting the same *obscure* message on three different groups of three different framework using with two different names? Under the a name to the turbogears and django group and under the pyne name on the web.py group. keep a list of read and unread items TG: http://tinyurl.com/nus4e django: http://tinyurl.com/ekzql web.py: http://tinyurl.com/rxw7y getting and storing favicon.ico as an image TG: http://tinyurl.com/gcxfo django: http://tinyurl.com/jdacd web.py: http://tinyurl.com/hu2hy you're just looking for desperate help? or should we just ignore you from now on? Ciao Michele a wrote: /favicon.ico i want to get the favicon.ico from the URL when a blog is added to the aggregator and then display the image, this is the usage scenario Please let me know how to do this in python i m willing to use os.spawnv() and call convert if need be thanks a lot --~--~-~--~~~---~--~~ 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: Should I know javascript before learning mochikit?
[EMAIL PROTECTED] wrote: Okay, I'm attempting to learn mochikit Is it assumed that I need to know Javascript beforehand, or at least learn it concurrently? Or is mochikit an abstract layer above javascript, so that I can safely forego knowing anything about javascript? Thanks You may want to get started by looking at something like this: http://www.crockford.com/javascript/survey.html and this: http://simon.incutio.com/slides/2006/etech/javascript/js-reintroduction-notes.html Ciao Michele --~--~-~--~~~---~--~~ 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: @view?
gasolin wrote: Damjan wrote: BTW. it contains templates, used with template plugins, it's just normal to call it templates/ Let's List all Proposals and see what's it look like: 1. @expose(template=proj.template.mypage) 2. @expose(template=proj.view.mypage) 3. @expose(view=proj.view.mypage) 4. @view(template=proj.template.mypage) I like 2nd most. It's a good convention that you exposed a method by using template mypage in your project's (proj) view folder. 5. @expose(view=template.mypage) giving that there is a views package like that: views |_ templates/ |_ json.py |_ ... and the view parameter is automatically linked to the views subpackage to save repetitive typing. Ciao Michele --~--~-~--~~~---~--~~ 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: @view?
Leandro Lucarella ha scritto: Michele Cella, el 7 de agosto a las 21:00 me escribiste: gasolin wrote: Damjan wrote: BTW. it contains templates, used with template plugins, it's just normal to call it templates/ Let's List all Proposals and see what's it look like: 1. @expose(template=proj.template.mypage) 2. @expose(template=proj.view.mypage) 3. @expose(view=proj.view.mypage) 4. @view(template=proj.template.mypage) I like 2nd most. It's a good convention that you exposed a method by using template mypage in your project's (proj) view folder. 5. @expose(view=template.mypage) ^ giving that there is a views package like that: views |_ templates/ ^ What about the plural vs singular consistency? (BTW, I don't like plural at all, either in controller, view or model) This is up to Kevin, personally I like being consistent so deciding a naming scheme to use would be great, I don't have any strong opinion regarding plural or singular. Ciao Michele --~--~-~--~~~---~--~~ 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: Struggling with form widgets.
Ian Wilson wrote: Hello, The form you use to get the error in validate() is different from the form you pass to the template. I can't really explain why that is important ...maybe someone else could but you should probably being doing it differently. I don't know why you are dynamically making the form, you should really move it outside of your CreateUser controller class and also match the validate form up with the form you pass to the template. Something like this: Yes, the problem is that he is creating a different instance of the same form, some times ago I added a feature that logs the validated form instance and displays errors only for this particular form, in this way you can display two form in the same page and without having them display validation errors if one is submitted. http://tinyurl.com/fpul2 Ciao Michele --~--~-~--~~~---~--~~ 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: how to test for exceptions with nose?
Jorge Vargas wrote: On 8/4/06, Kevin Dangoor [EMAIL PROTECTED] wrote: I'm not sure what you mean. That except clause up there will only handle ValueErrors. Anything else that comes up will error the test. (Not a failure, mind you, but it still wouldn't pass..) because even if it goes in the last assert will make it always fail try: raise NotImplementedError except NotImplementedError: assert True,True passes assert False,but here it crashes python -u assertTest.py Traceback (most recent call last): File assertTest.py, line 5, in ? assert False,but here it crashes AssertionError: but here it crashes Exit code: 1 I'm not sure if I'm understanding what you're really trying to do, anyway: try: raise NotImplementedError except NotImplementedError: assert True,True passes else: assert False,but here it crashes python -u assertTest.py Ciao Michele --~--~-~--~~~---~--~~ 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: @view?
Jorge Godoy wrote: Nicky Ayoub [EMAIL PROTECTED] writes: I would like to chime in... I agree with Lee and Fred. @expose makes more sense in my mind. I also agree with Lee that a change from 'template' to 'view' would truly accomplish the goal. I can expose methods through the web server without really presenting a 'view' at all, but if I use a template then I really want to see something out the other end. That's more intuitive and follows my thought process more closely. If it's not too late to vote, then -10 on @view and +100 on 'template' changing to 'view' as an argument of @expose... Opps, is it OK to vote more than once??? Nicky I also like more of this change (template for view and keeping @expose). So I change my vote. ;-) +1 makes *a lot* of sense (along with a views subpackge containing json.py and the templates package): @expose(view=templates.list) @expose(view=json) in this way we could also link automatically the view parameter to the view package. Ciao Michele --~--~-~--~~~---~--~~ 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: @view?
Kevin Dangoor wrote: On Jul 31, 2006, at 2:07 AM, Max Ischenko wrote: -1 from me. I think calling _controllers_ methods 'view' is rather un- intuitive. I like 'expose' much better cause it really about 'exposing' certain methods to the outside world. Here's the thing, though... it's not actually calling the method itself a view. It's saying the view for this method is this thing. The only wrinkle is that case where a controller is basically providing its own view (returning a string) or just redirecting. http://www.shorttext.com/us9w5 That's the idea that popped in mind after seeing the new RoR restful/respond_to approach (1 month ago), at the moment we can't do the restful things so easily but I think a @respond decorator is pretty self explanatory. I think we should also move json.py and templates inside a common views subpackage. Ciao Michele --~--~-~--~~~---~--~~ 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: Using widgets
Renzo ha scritto:
Hi, first of all sorry if this question has already been done, but i
haven't found the answer..
I've understood how it's possible to create a web form using widgets..
for example:
in controller:
example_form = widgets.TableForm(
fields=[widgets.TextField(name=test,label=Example),
widgets.TextField(name=test2,label=Example2),for_widget,name1
],
submit_text=Submit Me)
in template:
${example_form(action=prova)}
but it isn't so clear the way i've to follow to insert only a widgets,
without a form.
If i write:
in controller:
name1 = widgets.TextField(boh,validator=validators.NotEmpty())
and in template:
${name1}
looking at the web page, the result is:
TextField(name='boh', convert=True, field_class='textfield', attrs={},
css_classes=[]).
Instead, if i write in template:
${name1.render()}
the HTML result is:
lt;INPUT ID=boh TYPE=text CLASS=textfield requiredfield
NAME=boh
that isn't correct because it is escaped (in particular the first
character).
Could anyone suggest me the correct way i've to follow to use correctly
the TG widgets?
Thanks,
Renzo (Italy)
You should use:
name1.display()
or
name1()
(since a widget object is a callable linked to the display method)
you use the render method *only* outside of kid templates since it
dumps a plain string while display() dumps an elementtree structure.
If you're interested in using a custom layouted form inside your
template you can still use the original form in this way:
class MyFields(WidgetsList):
name = TextField()
comment = TextArea()
form = TableForm(fields=MyFields())
in your template (supposing you've passed the form variable to it) you
can do things like:
${form.display_field_for('name')}
${form.display_field_for('comment')}
Hope this helps.
Ciao
Michele
PS
Ti stavo rispondendo in TG-it ma ho visto lo stesso messaggio qui... ;-)
--~--~-~--~~~---~--~~
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: @view?
Kevin Dangoor wrote: Actually, @view/expose already handles multiple types of responses (not based on HTTP method but based on accept headers and tg_format). Yes, I know that that's why it makes sense to call it @respond IMHO. ;-) Anyway that's not a big problem just another idea to throw into the discussion. I think we should also move json.py and templates inside a common views subpackage. That is likely a good idea, but I think that's a good idea for later. Yep, 1.1 probably. Ciao Michele --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: r1686 breaks widgets tests
I may miss something but actually TG internal widgets are kid only but
you should be able to get use a different template language as long as
it provides the template plugin.
For example:
class MyWidget(Widget):
template = stan:path.to.template
Ciao
Michele
[EMAIL PROTECTED] wrote:
Heya guys.
r1686:
Index: branches/1.0/turbogears/widgets/base.py
===
--- branches/1.0/turbogears/widgets/base.py (revision 1549)
+++ branches/1.0/turbogears/widgets/base.py (revision 1686)
@@ -224,5 +224,5 @@
# update_data has been deprecated
self.update_data(params)
-return view.transform(params, template=self.template_c)
+return view.engines.get('kid').transform(params,
self.template_c)
Makes sense to me as widgets are kid-only.
However, the engines are usually lazily loaded upon the first call to
view.transform (via _choose_engine). So as long as your app calls
view.transform before a widget's display method is called, you're ok,
as the engines will be loaded.
However for simple widgets tests, view.transform is not called first,
just the widgets display method. Thus view.engines is unpopulated,
view.engines.get('kid') returns None and an exception is thrown.
I'm not sure of the best way to fix this.
Is there a particular advantages to engines being lazily loaded? Can we
explicitly load them at module import? Or would it be better to add a
public function to get an specific engine that calls _load_engines?
Shall I open a ticket?
--~--~-~--~~~---~--~~
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: r1686 breaks widgets tests
[EMAIL PROTECTED] wrote: The test breakage with r1686 was posted on the main TurboGears list, and I added a proposed patch. If there's no problems with intializing the engines dict at module load-time instead of lazily when calling _choose_engine I'll go ahead and commit the patch: http://groups.google.com/group/turbogears/browse_thread/thread/00134fe24706d991 Kevin any opinion on this? Michele Cella wrote: I may miss something but actually TG internal widgets are kid only but you should be able to get use a different template language as long as it provides the template plugin. For example: class MyWidget(Widget): template = stan:path.to.template Actually the base Widget class expects all Widget templates to be Kid, as seen in the __init__ method's call to load_kid_template. The Widget class will need some changes before other template engines will be supported. r1686 at least allows you to use widgets when your default template engine is not Kid. You're absolutely right, I forgot that thing... sorry :-( We should try to fix this issue. 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 -~--~~~~--~~--~--~---
[TurboGears] Re: www.cherrypy.org offline ?
Same here Roger. :-( Ciao Michele Roger Demetrescu wrote: Sorry for the off-topic msg... Is anyone else having problem accessing http://www.cherrypy.org/ or is just me ? Thanks Roger --~--~-~--~~~---~--~~ 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: Facing issue with identity management and autoload. Bug?
Kevin Dangoor wrote: On Aug 3, 2006, at 1:25 AM, Sanjay wrote: Probably the post was too long and hence could not attract attention. Speaking in one line, using identity management while autoloading tables is not working for me. If it's a bug, am I supposed to post it in trac? I believe the bug is that identity is currently expecting ActiveMapper to be used (which is a bug). Kevin Hi Kevin, I think there is a patch that should fix these things... http://trac.turbogears.org/turbogears/ticket/1041 Ciao Michele --~--~-~--~~~---~--~~ 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: How to inject a widget into the template variables independent of controller output?
Hi guys, what about totally changing the way variable providers works? My idea is to check for a special method inside the actual controller that returns a dict of variables that will be injected inside the dict returned by every method of that controller, this allows for great flexibility combined with OOP. Let me make an example: class BlogController(Controller): def __variables__(self): return dict(cool_widget=cool_widget) def list(self): return dict(notes=notes) the save method will always return cool_widget and notes. If you need something on every page you can subclass Controller and use it in every controller instead of the original one, you can also mix things as you need. Ciao Michele Alberto Valverde wrote: On Jul 31, 2006, at 10:32 PM, Kevin Dangoor wrote: On Jul 16, 2006, at 8:34 PM, Christopher Arndt wrote: how can I inject a widget into the template variables without explicitly including it in the returned dict of a controller method? I know about view.variable_providers, but unfortunately controllers._process_output() does not retrieve CSS or JavaScript from widgets in the 'tg' namespace. I guess, my only option would be an ugly hack by saving view.stdvars() somewhere and then overriding/wrapping it with my own version that adds my widget to the toplevel namespace of the template variables. But this would be, well, ugly. Any suggestions? If you are wondering about the need for this: I want to replace $tg_flash with a nice widget (I'll be releasing a demo soon) that needs some CSS and JavaScript, and thatswhy I can't just add it to the controller output. I didn't see a reply to this, but it sounds useful. Some people have wanted variable_providers to be able to put things outside of the tg namespace. That might be one way. How would you *like* it to work? Hi, I've been tinkering sometime ago trying to implement this feature (retrieving js, and css from widgets present in stdvars) and found out that in order to implement it some change might be needed in the way stdvars are sent to the engine: So, IIRC, not on crack or way too sleepy, I've seen that the engine is initialized with a callable, (stdvars in our case, http:// tinyurl.com/je2td), which is called inside the engine to populate a dict with extra variables. The problem with this approach is is that this dict is built outside TG in the template engine, hence we have no chance to inspect it to see if any widgets are present and pull their resources from them. At least I couldn't find a way to do it. Mainly because a check for isinstance(obj, Widget) inside the engine would couple it unnecessarily with TG. This could be easily solved if stdvars was called inside TG (in view.render(), for example), the dict produced was inspected there and it's resources pulled out and prepared to be included in the template. I got a semi-working patch (just some polishes needed to pass all tests) using the approach I mentioned which I could dig up from the dustbin if I'm going in the right direction. BTW, this is related to ticket #692, so we might as well move the technical discussion, patches, etc, there ;) 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: How to inject a widget into the template variables independent of controller output?
Alberto Valverde wrote: Hi Michele, On Aug 1, 2006, at 12:10 PM, Michele Cella wrote: Hi guys, what about totally changing the way variable providers works? Too drastic for 1.0, isn't it? ;) Yep, definitely... :D My idea is to check for a special method inside the actual controller that returns a dict of variables that will be injected inside the dict returned by every method of that controller, this allows for great flexibility combined with OOP. Let me make an example: class BlogController(Controller): def __variables__(self): return dict(cool_widget=cool_widget) def list(self): return dict(notes=notes) the save method will always return cool_widget and notes. If you need something on every page you can subclass Controller and use it in every controller instead of the original one, you can also mix things as you need. Sounds like a good idea and will surely reduce lots of boiler-plate in controllers. However, I would make the __variables__ signature (self, d) where d is the dict being sent to the template to update it with new variables (a là update_params). This would make it easier to extend the controller's superclass IMO, something like: def __variables__(self, d): super(BlogController, self).__variables__(d) d.update(cool_widget=cool_widget) Mmm, I think the invoked method should take the precedence among __variables__ so no need to modify any dict, you can do what you've described in this way: def __variables__(self): d = super(BlogController, self).__variables__(d) d.update(cool_widget=cool_widget) return d or we can just pass an empty dict and update it like you have show? BTW, do we really need those underscores? Maybe call it update_variables? Well, it seems I'm the only one who likes the double underscore (remember __css__, __javascript__, __validate__ ...) but to me it just feels more pythonic, it clearly states that the method is special and that the framework will recognize it's presence and eventually use in the right way (just like __eq__ in python...), it clearly states the presence of that protocol and moreover it doesn't introduce possible name conflicts with exposed methods... maybe variables is not the best name in this particular case. We can still keep the good 'ol variable_providers untouched for backwards compatibility. Yes, for sure. ;-) Could/should this make it into 0.9a9? Dunno... :-/ Ciao Michele --~--~-~--~~~---~--~~ 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: How to inject a widget into the template variables independent of controller output?
Jason Chu wrote: On Wed, 2 Aug 2006 02:09:20 +0200 Alberto Valverde [EMAIL PROTECTED] wrote: We can still keep the good 'ol variable_providers untouched for backwards compatibility. I like variable_providers, it lets me specify things that are available throughout the entire application, instead of on a controller-by-controller basis (I assume you're not going to walk the controller tree up just to see what variables to apply). If we got rid of variable_providers entirely I'd be annoyed that turbogears can stuff things into the global kid namespace but I can't (the tg variable). You could do that in a more elegant way: 1) By adding your method to the base Controller class before creating an instance of it: from turbogears import Controller def my_global_provider(self): return dict(#stuff that into every template) Controller.__variables__ = my_global_provider class BlogController(Controller): 2) By subclassing the Controller class and using that new class as your controller class ApplicationController(Controller): def __variables__(self): return dict(stuff that into every controller) This solution allows you to keep tg uncluttered by your stuffs and at the same time you can stuff anything into *every* templates or just *some* templates in the way you want, this means you can use custom namespace or object to group things (and not just tg) or just plain methods or widget instances. ;-) Ciao Michele --~--~-~--~~~---~--~~ 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: Using checkbox widget
OriginalBrownster wrote:
Hi
I want to know how to implement the following source code and template
sample they gave within the widget browser.
I reviewed over the checkbox widget, and I think it will be easier
using the widget than creating my own form in my template.
I am assuming this is supposed to go in the controller
class CheckBoxListDesc(CoreWD):
name = CheckBox List
for_widget = CheckBoxList(your_checkbox_list,
options=[(1, Python),
(2, Java),
(3, Pascal),
(4, Ruby)],
default=[1,4])
and this in the template
ul xmlns:py=http://purl.org/kid/ns#;
class=${field_class}
id=${field_id}
py:attrs=list_attrs
li py:for=value, desc, attrs in options
input type=checkbox
name=${name}
id=${field_id}_${value}
value=${value}
py:attrs=attrs
/
label for=${field_id}_${value} py:content=desc /
/li
/ul
However I get a traceback error
Traceback (most recent call last):
File /var/projects/document_site/se/start-se.py, line 27, in ?
from se.controllers import Root
File /var/projects/document_site/se/se/controllers.py, line 75, in
?
class CheckBoxListDesc(CoreWD):
NameError: name 'CoreWD' is not defined
I need alot of help with this. I've been trying to use checkboxs within
my application but I have had NO SUCCESS. If someone is willing to help
me out it would be greatly appreciated.
Thank you
Stephen
Hi Stephen,
I will show you how to build a complete form containing even a
CheckBoxList, in your controller do something like this:
from turbogears import expose, validate, error_handler, flash, widgets,
validators
class MyFields(widgets.WidgetsList):
name = TextField()
email = TextField(validator=validators.Email())
language = CheckBoxList(options=[(1, Python), (2, Java), (3,
Pascal),(4, Ruby)],
default=[1,4])
my_form = widgets.TableForm(fields=MyFields(), action=save)
now you need two methods methods attached to your controller in this
way:
@expose(template=test.new)
def new(self, tg_errors=None):
if tg_errors is not None:
flash(Please fix all errors)
return dict(my_form=my_form)
@expose()
@validate(form=my_form)
@error_handler(new)
def save(self, name, email, language):
#the data your received is valid and you can add it to the database
...
Hope this helps, keep in mind that when you look at a widget using the
widget browser the source code refers to the code running that example,
generally what you really need is the for_widget portion, the template
tab refers to the widget's template for further customization that
oftten is not needed.
Inside the turbogears's trac you can find a complete package that shows
how to use widgets (very easy example anyway), I have updated it to
work with the latest turbogears version (0.9a8), you can find it here:
http://trac.turbogears.org/turbogears/attachment/wiki/SimpleWidgetForm/FormsTutorial-0.9a8.tar.bz2?format=raw
Ciao
Michele
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[tg-trunk] Re: SelectionField.options called in ctor (backward-incompatible with 0.9a6)
Alberto Valverde wrote: On Jul 29, 2006, at 12:29 PM, Alberto Valverde wrote: I think the best solution for this would be to avoid guessing altogether as it'll will follow the In the face of ambiguity, avoid the temptation to guess PyZen principle and make this validator default to a String if no one is given. However, it would break some existing code until it's fixed with an explicit validator. Opinions? Just to make this clearer: should read: it would break some existing *user* code until it's fixed with an explicit validator I mean, people's apps, not TG's code. Hi guys, If you think the validator guessing causes too much trouble and probably magic effects :D I'm +1 on removing it. Ciao Michele PS Sorry if I'm not too responsive lately... I'm really busy but things should get better soon hopefully. ;-) --~--~-~--~~~---~--~~ 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: Kid vs Cheetah
[EMAIL PROTECTED] wrote: Kevin Dangoor wrote: I'd be interested to see the same test run with Markup: http://markup.edgewall.org/ Yeah, I'd like to see a benchmark of Markup vs. Cheetah as well. Unfortunately the test Cheetah template has a strange recursion error, so it's currently not runnable. If someone can figure out why this is going into an infinite recursion please let me know: http://markup.edgewall.org/browser/trunk/examples/bench/basic.py#L22 Current benchmarks of Markup and other templating languages are here: http://markup.edgewall.org/wiki/MarkupPerformance Work is still ongoing on optimizing portions of the engine in C, so Markup's performance may have improved some since the benchmarks were last made. I plan to update the example of using Markup with TurboGears this week and will make a more official announcement soon. -- Matt Good Markup looks really cool, keep up the great work guys! :-) Ciao Michele --~--~-~--~~~---~--~~ 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: Possible bug with Kid Widgets
Hi Sean,
this is a know issue with kid:
http://www.kid-templating.org/trac/ticket/145
hopefully it will be fixed shortly.
Basically you can't use py:strip on the very first tag.
Ciao
Michele
Sean Jamieson wrote:
I'm trying to create a very simple widget to represent a menu box with
links. Theoretically this should have been fairly straight forward, but
I'm getting an error that doesn't seem to be caused by my widget or
template.
Here is the error, as generated by ipython:
/var/www/Test-Site/console
/usr/lib/python2.4/site-packages/TurboGears-0.9a4-py2.4.egg/turbogears/widgets/base.py
in display(self, value, convert, **template_vars)
156 template_vars[value] =
to_unicode(self.adjust_value(value, convert))
157 self.update_data(template_vars)
-- 158 return view.transform(template_vars,
template=self.template_c)
159
160 def retrieve_javascript(self):
/usr/lib/python2.4/site-packages/TurboGears-0.9a4-py2.4.egg/turbogears/view/base.py
in transform(info, template)
134 Create ElementTree representation of the output
135 engine, template, enginename = _choose_engine(template)
-- 136 return engine.transform(info, template)
137
138 def loadBaseTemplates():
/usr/lib/python2.4/site-packages/TurboKid-0.9.3-py2.4.egg/turbokid/kidsupport.py
in transform(self, info, template)
168 options = self.options
169 if options.get(kid.i18n.runTemplateFilter, False):
170 t._filters+=[options.get(kid.i18n_filter)]
-- 171 return ElementStream(t.transform()).expand()
172
/usr/lib/python2.4/site-packages/kid-0.9-py2.4.egg/kid/pull.py in
expand(self)
109 last.tail = item
110 else:
-- 111 current.text = item
112 if isinstance(last, list):
113 return last[0]
AttributeError: 'list' object has no attribute 'text'
I don't know what 'current' is, or why it's a list here. This seems to
be something wrong with the internals of kid. But it certanly happens
when I do menu.render() or menu.display().
I get this same error from the running application, or from console,
console backtrace is much shorter since I call menu.display() directly,
but the last few bits are the same.
My widget is simply this:
class MenuBlock( widgets.Widget ):
params = ( 'title', 'links' )
template = '''
menu py:strip=True xmlns:py=http://purl.org/kid/ns#;
div class=title$title/div
div class=body py:for=link in links
a href=${link[0]}${link[1]}/a
span py:if=len(link) 2${link[2]}/span
/div
/menu
'''
And it's used in the master.kid file as:
div id=menu
div class=block py:for=menu in view.menu
${menu.display()}
/div
/div
Thanks in advance for any help,
Sean
--~--~-~--~~~---~--~~
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: display validation errors on form
Indeed, the problem is most probably with a different instance being used, the ideal solution is to avoid such things since you're meant to reuse the same widget instance. In this particular case to avoid collisions between two forms displayed inside the same page we display errors only for the form that has been validated, Randall IIRC something like this should do the trick for you: @expose(template=tgwater.planreview.templates.edit) def edit(self, obj, tg_errors): form = createPlanReviewForm() if tg_errors: cherrypy.request.validated_form = form return dict(project=obj, form=form) Ciao Michele Kevin Dangoor wrote: I don't think I've personally tested the case where a different Form instance is used in each location. Otherwise, it seems like this should work. I'd say open a ticket. Something that could help a lot, if you have time, is to rearrange the code below into a test case (check out turbogears.widgets.tests.test_forms for examples). Having test cases makes things easy to fix and makes sure the bugs stay dead. Kevin On Jun 26, 2006, at 5:06 PM, Randall wrote: SVN 1590 with SQLA patches. I'm using widgets to create a form and thought that the widgets automagically displayed error messages when a FormEncode validation failed, but I'm getting back the form with no errors displayed. Here is what my code looks like. class PlanReviewSchema(validators.Schema): title = validators.String(not_empty=True) def createPlanReviewForm(controller=None): # some stuff form = TableForm(fields=fields, action=save, submit_text=Save, validator=PlanReviewSchema()) class PlanReviewController(controllers.RootController, RESTfulController): # Some methods. # ... @expose(template=tgwater.planreview.templates.edit) def edit(self, obj): form = createPlanReviewForm() return dict(project=obj, form=form) @expose() @validate(form=createPlanReviewForm) @error_handler(edit) def save(self, project, **data): tg.flash(Changes saved!) raise tg.redirect(/) I purposely leave the title field empty so the validator fails and the edit method gets called because it is the error_handler. But why is there not an error message next to title on the form? Randall -- Kevin Dangoor TurboGears / Zesty News email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.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 -~--~~~~--~~--~--~---
[tg-trunk] Re: simpler version of LocalizableJSLink
Kevin Dangoor wrote: On 6/4/06, Max Ischenko [EMAIL PROTECTED] wrote: I was proposing to replace original LocalizableJSLink with my simpler version and rename original to CalendarLangFileLink. Your mods should go to the latter (and I very much agree with you cause I'm having the same problem with calendar widget). That looks quite simple and straightforward, but I don't really have a strong feel for this part. I was hoping Michele would say something, since he created the original one. Hey, sorry for coming here now I've just forgot to reply, I'm deeply into exams these days... :-( I think Max has a far better understanding of localization issues so if he thinks this is the easier and best way of doing it I'm totally +1. Max, if you think the Calendar can and should use this version then go ahead and do it, otherwise I think renaming your one to LocalizableJSLink and the advanced one to CalendarLangFileLink makes a lot of sense because ATM we have two things with almost the same name. ;-) 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 -~--~~~~--~~--~--~---
[TurboGears] Re: display_field_for but no display_errors_for?
Jason Chu wrote:
If I wanted to refer to the errors of a widget, and I'm using the
display_field_for, it'd make sense to have a display_errors_for. Right
now there is none...
Is there some other way I can do this?
Hi Jason,
You still use error_for, it works taking a widget as argument or a
name.
error_for('age')
Ciao
Michele
--~--~-~--~~~---~--~~
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: CompoundWidgets and non-dict values
Jason Chu wrote:
I'm still in the midst of upgrading from 0.9a4 to 0.9a6 and one of the
things I've noticed is that CompoundWidgets must have dict values
passed to them. If I pass something like a SQLObject object the widget
just ends up seeing {} as the value.
Before, I could pass anything as the value and it'd be seen in the
update_params function, no matter if it was a CompoundWidget or not.
Most of my CompoundWidgets are widgets that display complex data, not
ones that display disconnected data. I'd prefer to be able to pass
non-dict values to a widget and still be able to modify the d['value']
inside the update_params function.
Instead I've been forced to override the display method to do my value
manipulation.
Suggestions?
Hi Jason,
this was discussed inside tg-trunk, basically passing an instance is
still working but I fear you haven't followed my advice of using
member_widgets hence you're getting an empty dict.
You should really consider using member_widgets + display_field_for
inside your widget's template. ;-)
Ciao
Michele
--~--~-~--~~~---~--~~
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: Refering to callables in widgets
Jason Chu wrote: Sorry for not following up on this one for a while. I just realized why we didn't use member_widgets before. member_widgets doesn't make the widget accessible to the template by name. You people who autogenerate your form based off the fields that come in don't care about refering to specific fields, but us people who use custom templates and place each field by hand do ;) That's why I'm presenting you the display_field_for method, it will become your best friend, I introduced it for people like you that are taking special care of they fields. ;-) If you know in advance the name of the field and you're placing each field by hand (your exact case) you can use the display_field_for method to display the field in a insanely easy way since you don't even need to pass value_for and params_for, inside your widget template that's all you need to do: display_field_for(email) Give it a try and let me know. Ciao Michele --~--~-~--~~~---~--~~ 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: Widgets For Beginers Request
Kevin Horn wrote: Thanks, Michele! I guess I overlooked the second print render It's very late... That does seem to answer my question quite nicely, I just didn't manage to see it for some reason. but _also_: I was actually going to reply to this thread with news that I had (re)discovered _this_ thread from a while back: http://groups.google.com/group/turbogears/msg/6d3bc5e83180b1ef In which you wrote an excellent explanation of exactly what I was looking for! So thanks for that too! Great, thanks to you! ;-) I think that while replying here on the group I've somewhat explained pretty much any feature you can find inside our widgets, it would be great if someone can collect it in one place to make some nice docs, it's a shame but ATM I can't really do that... :-( Ciao Michele --~--~-~--~~~---~--~~ 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 site design is up!
Very cool! great work Richard! Some things: - I'm seeing (as Karl) the olive background - On secondary pages I need to refresh the page with CTRL-R otherwise the side box are overlapping the header - I suggest you switch to the favicon that we provide with a quickstarted project that's nicer, a yellow one (like the gear) would rock but I think such a small image needs to be designed from the ground up to nicely fit at this size (or if the original gear is in vector format you can cut details and keep the shape) - Finally I think that we you're reading documentation or basically when you're in a secondary section of the site (where the header is also different) the side boxes shouldn't be there, IMHO they should stay only in the frontpage since they are taking up too much space and can become redundant for someone that knows TG and is just looking at the doc. Great work again! ;-) Ciao Michele Kevin Dangoor wrote: Like many of the folks on this mailing list, when I go to TG.org, I'm almost invariably in turbogears.org/preview/. It looks quite nice in there, thanks to Richard Standbrook. I finally couldn't take it any more. TurboGears.org now has the new site design! Thanks for the facelift, Richard! Kevin -- Kevin Dangoor TurboGears / Zesty News email: [EMAIL PROTECTED] company: http://www.BlazingThings.com blog: http://www.BlueSkyOnMars.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: readonly TextField
[EMAIL PROTECTED] wrote:
Hi all,
is there possibility to dynamically set form field to readonly? I found
only how to pass desired field name to disabled_fields parameter when
creating Form instance. But this is not exactly I need.
I need this field which is normally enabled and visible (upon creating
new record) to be posted to next handler (save or add). But when
editing is needed, this column must NOT be editable.
Thanks
Jiri
Pass a disabled attribute when you're displaying an edit page:
from turbogears import widgets as w
form = w.TableForm(fields=[w.TextField(name=hello)])
print form.render(attrs=dict(hello={'disabled':'disabled'}))
FORM METHOD=post CLASS=tableform NAME=form
...
INPUT DISABLED TYPE=text CLASS=textfield NAME=hello
ID=hello
...
/FORM
Ciao
Michele
--~--~-~--~~~---~--~~
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: Refering to callables in widgets
Jason Chu wrote:
I'm now trying to migrate our code from 0.9a4 to 0.9a6. Now if I do a
self.variable inside a widget and variable is callable, the
widget's metaclass will call variable() and return its value. Couple
that with widgets being callable and I can no longer pass references to
my internal widgets around.
Where do I do this? Just about every custom edit form that we have.
We use params (used to be template_vars) to be able to refer to widgets
by name inside a template. Obviously, we also pass the widgets in
as the fields argument to the __init__ function so that value_for and
options_for still works.
Here is an example:
params = ['name', 'priority', 'duedate', 'duetime', 'summary',
'description', 'completed', 'typeList']
def __init__(self, *args, **kw):
self.priority =
widgets.SingleSelectField(name='Priority', options=...,
validator=...)
self.duedate =
CalendarDatePicker('Due Date')
self.summary = widgets.TextField(name='Summary',
validator=...)
self.description = widgets.TextArea(name='Description')
self.completed = widgets.CheckBox(name='Completed',
validator=...)
self.typeList =
TypeList(name='Types', numCols=1, options=model.getUserTags)
fields =
[self.priority,self.duedate,self.summary,self.description,self.completed,self.typeList]
super(TodoEditForm, self).__init__(fields=fields, *args, **kw)
I've edited it for brevity, but you get the idea. The fields = [] part
is where I run into problems. Because self.priority is a callable,
it's called, and its value is returned instead of the reference to it.
Before I go and change every reference to every widget in every form,
how exactly am I supposed to do something like this? I want to be able
to get to each of my widgets by some name inside the template, but
still have them play nicely with all the form stuff.
Hi Jason,
you should not use params when you are working with widgets inside
another widgets, this means you have a CompoundWidget and what you must
use is member_widgets not params.
member_widgets works just like params but it doesn't handle callables
automatically and you can override them only at init not
render/display time, this makes sense since you're going to instantiate
a widget during a request...
http://trac.turbogears.org/turbogears/wiki/StatelessWidgets
Ciao
Michele
--~--~-~--~~~---~--~~
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: Checkbox value always True, even when unchecked?
Roger Rohrbach wrote: I've got a Checkbox: doit = widgets.CheckBox(default=True) Regardless of whether I check or uncheck it, the value of the 'doit' keyword argument to the controller method I specify as the form's action is always True. This is in TurboGears 0.9a1. Is there any way to work around this? I don't see anything in Trac that would indicate that this was ever a bug, but it sure looks like one, and I simply cannot upgrade right now... I'm pretty sure I've fixed this bug: http://trac.turbogears.org/turbogears/changeset/1215 If you're going to patch your own copy please note that the fix was not perfect so I had to do other modifications: http://trac.turbogears.org/turbogears/changeset/1244 http://trac.turbogears.org/turbogears/changeset/1254 Ciao Michele --~--~-~--~~~---~--~~ 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: how to override CalendarDatePicker language?
Max Ischenko wrote: Hi, I'm using CalendarDatePicker which uses LocalizableJSLink to select appropriate language to display calendar in. Is it possible to override this choice somehow? Passing custom calendar_lang doesn't work, it still uses value from Accept-Language header. ATM you can't do that, but you can subclass and define a different javascript. What I suggest to do is this. if calendar_lang is None: use the LocalizableJSLink (the last link should point to en that we know is a good existing fall-back) else: use a normal JSLink that uses calendar_lang I think this is the most intuitive way, when you define calendar_lang you want it to be the calendar lang, no matter what the Accept-Language is. Ciao Michele --~--~-~--~~~---~--~~ 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: Search options: Are there any, should we be considering them?
Some links... just in the case you haven't catched them: http://swapoff.org/wiki/pyndexter http://blog.case.edu/bmb12/2006/03/merquery_text_indexing_and_search_with_a_focus http://blog.case.edu/bmb12/2006/03/more_on_merquery Ciao Michele Robin Haswell wrote: Hey guys Let's face it, every application on the web these days need some form of search, and as far as I can see, TG + SO/any ORM is going to make that tricky. So I was wondering, should we be thinking about a portable way of providing search for TG apps? Or at least, I think we should provide an integration method for something which is quite easily obtainable, if not shipped with TG itself. I think we have at least two options: 1. PyLucene (http://pylucene.osafoundation.org/) Pros * Stable, well-maintained project * Core engine used in a billion different things * Lots of packages Cons * Appears to be a Java hack * Stems from a Java project * Did I mention Java? * Looks a bit heavyweight 2. XapWrap (http://divmod.org/projects/xapwrap) Pros * Looks quite simple to use * Very Pythonic * Under active development * Cool name Cons * Somewhat immature at the moment * Not full-featured (eg no stemming - do we care?) * Current documentation appears to consist of a few docstrings Personally I would prefer XapWrap, however I need a search engine right now and for internal reasons I'm going to give PyLucene a spin. I'll report back what I think of it. Anyway that's my $0.02 - I hope we can have a good discussion about this. -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: Widgets vs standard forms.
:-(
It seems you haven't received my off-list message yesterday, google
group was not working for me.
Anyway here it's the best way of mixing widgets and allow your designer
to tweak the form appearance *very* easily:
==
If you need to feed your forms to a designer you can mix the two things
very easily, for example you can use all forms widgets features like
TextField, SingleSelectField but leave the form layout up to your
designer.
For a very customized example take a look here, keep in mind that you
don't necessarily need the StandardTextField thing but I think you can
easily understand the concept, basically all you need is
form.display_field_for('address', my_value) and
form.error_for('address').
Link:
http://trac.turbogears.org/turbogears/attachment/wiki/SimpleWidgetForm/WeAreFlexible-0.9a5.tar.gz
Ciao
Michele
mulicheng wrote:
I've been playing around with Form widgets (0.9a5). I've got
validation to work and have tweaked the forms to look how I like in
most cases. I have forms designed by a graphical designer. It seems
to me that with the work I did to customize the forms (instead of using
a standard TableForm for instance), that it might have been cleaner to
just use the std.xxx methods to check/fill the inputs instead of use
widgets.
Is there a way to use validation on forms what are not widget Forms
though? What about error messages?
Just looking for some best practice advice.
Thanks
Dennis
--~--~-~--~~~---~--~~
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: Helpful utility functions for select-style Widgets.
Very very cool and useful stuff Matthew!!
What about putting these things into a CookBook page? ;-)
Ciao
Michele
Matthew Bevan wrote:
Working as much as I have on widgets (use of, not creation of) I've come up
with a few useful tidbits I'd like to share:
I define a SingleSelectField as:
W.SingleSelectField('author', label='Author',
options=make_list(model.Account, 'No Author'),
help_text='Select an author to display in byline information.'),
The make_list function and build_list method are the trick, here. The
make_list function prepends an optional empty value to an existing callable
(which should return a list of tuples). It also allows you to pass arguments
to the callable; the primary reason for the function.
def make_list(c, none_label=None, *args, **kwargs):
def _call():
return [ [], [(None, none_label)] ][none_label is not None] + \
c.build_list(*args, **kwargs)
return _call
The build_list method of my SQLObject classes return a list of tuples suitable
for use in a select-type widget (single, multiple, radio, or checkbox) by
performing a simple .select() on itself, passing any arguments it receives to
the select method.
@classmethod # of Account
def build_list(self, *args, **kwargs):
return [(a.id, a.full_name) for a in self.select(*args, **kwargs)]
An alternative and generic build_list function is: (and can be used alongside
classes using the above method)
@classmethod # of anything
def build_list(self, field, *args, **kwargs):
return [(a.id, getattr(a, field)) for a in self.select(*args, **kwargs)]
Any additional arguments to make_list are automatically passed, thus, to the
select method, allowing you to use SQLBuilder in your arguments to the
widget. Take the following examples:
from model import *
from datetime import datetime
..., options=make_list(Account, None,
Account.q.enabled, orderBy=Account.q.full_name), ...
..., options=make_list(Language, Unspecified, Language.q.strings 0), ...
# Alternate method for accounts:
..., options=make_list(Account, None, 'user_name'), ...
Note that you can't use both methods within a single class.
Enjoy!
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[tg-trunk] Re: Break nested widgets or break use of instances in a6?
Alberto Valverde wrote:
I'm attaching a patch that implements the ObjToDct (non recursive)
we've been discussing. It doesn't break current tests but I haven't
tested with a real SQLObject (or any other) so I cannot guarantee
anything :/
However, it should serve as a starting point
Disclaimer: I haven't looked at your patch yet.
Anyway I was wondering, if we do something like this? shouldn't it
work? simple and straigtforward no ObjToDict needed, we simply prepare
a dict on the fly without leaving this job to the user...
def adjust_value(value=None, **params):
if value is not None and not isinstance(value, dict):
adapted_value = {}
for w in self.iter_member_widgets():
if hasattr(value, w.name):
adapted_value[w.name] = getattr(value, w.name)
value = adapted_value
return super(CompoundWidget, self).adjust_value(value, **params)
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: Params docs for widgets
Alberto Valverde wrote: On 09/05/2006, at 10:15, Alberto Valverde wrote: FYI: I've just committed the 'params_doc' attribute for widgets we talked back a couple of days ago. Comments? Yep, CSS sucks! Can someone with a better CSS-fu than me give it whirl? Many thanks :) Great work, looks very useful... apart the css. :P I still wonder how we can document member_widgets without introducing a member_widgets_doc (I would rather prefer to avoid it), and how params_doct plays with PythonDoc in the end. 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: Break nested widgets or break use of instances in a6?
Alberto Valverde wrote: Yep, that should work to I believe Still immersed in java nightmares? ;) Yep... not to mention how messy the code I'm looking at is... :-( 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: Break nested widgets or break use of instances in a6?
Kevin Dangoor wrote: On 5/9/06, Kevin Dangoor [EMAIL PROTECTED] wrote: This works for instances but, according to our tests, repeating fields can also have lists coming in. Do we just add a not isinstance(value, list)? Actually, it really seems like CompoundWidget wants a dict and Repeating stuff is a special case. So, I put this on RepeatingInputWidget: def adjust_value(self, value, **params): return Widget.adjust_value(self, value, **params) Yep, for a repeating we may want to support instances inside a list, example: value = [one_page, another_page] so we should do the same adaption for every element of the list if needed, this means that we should make a dict it the element is an instance, anyway I think that this can wait. But as a workaround we should be using InputWidget not Widget. 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: widget browser needs paging
Kevin Dangoor wrote: On 5/9/06, Ronald Jaramillo [EMAIL PROTECTED] wrote: What about changing the setup, so we only display one widget at a time in a content area and we have a permanent list of all widgets to the left? A bit like the way the wx demo app work. At some point we could even allow people to change the template/ and or parameters to the widget directly through the browser and re-render/update the widget according to that. Updating parameters would be a cool feature! I really like being able to scan the widgets and not have to click through each one, so I wouldn't want this to go to that extreme of the wx demo. This shouldn't be difficult at all, I don't have time to implement it but I have the idea of how it should work here in my mind. Ideally, to make it easier I think that if you want to play with widget'params we should display the widget alone in a page. We then provide a simple form to tweak widgets' params, when you click apply we submit an ajax request to a method that does something like this: @expose(fragment=True) def apply_params(self, **kw): [kw contains new params] return [pick up the widget desc module name from kw].render(**kw) then we replace the sample div with the new one received by this method. This is only a concept of what we need but it should work. 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: Break nested widgets or break use of instances in a6?
Kevin Dangoor wrote:
On 5/9/06, Michele Cella [EMAIL PROTECTED] wrote:
Yep, for a repeating we may want to support instances inside a list,
example:
value = [one_page, another_page]
so we should do the same adaption for every element of the list if
needed, this means that we should make a dict it the element is an
instance, anyway I think that this can wait.
So we really want adjust value to be something like this:
newvalue = [super(RepeatingInputField, self).adjust_value(val) for val in
value]
Mmm I don't think this will work since the validator of a
RepeatingInputField expects a list (is wrapped inside a ForEach) while
in this way it will end-up to get a dict for every value.
We may want to factor out the function we have used into a method
maybe.
class CompoundWidget(...):
...
def _adapt_instance(self, value):
if value is None or isinstance(value, dict):
return value
else:
adapted_value = {}
for w in self.iter_member_widgets():
if hasattr(value, w.name):
adapted_value[w.name] = getattr(value, w.name)
return adapted_value
def adjust_value(self, value=None, **params):
return super(CompoundWidget,
self).adjust_value(self._adapt_instance(value), **params)
class RepeatingInputWidget(...):
...
def adjust_value(self, value=None, **params):
return super(RepeatingInputWidget,
self).adjust_value([self._adapt_instance(v) for v in value], **params)
This should finally do the trick (note I'm not testing what I'm writing
but I'm pretty sure).
I don't like the _adapt_instance name, but the leading underscore
should stay there since it's a method that we want to use only
internally to a CompoundWidget.
If you want to try this, tests will tell.
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: Break nested widgets or break use of instances in a6?
Kevin Dangoor wrote: The tests didn't quite like this. Here's an example (running only nosetests turbogears/widgets/tests/test_widgets.py) == FAIL: turbogears.widgets.tests.test_widgets.test_textfield -- Traceback (most recent call last): File /Library/Frameworks/Python.framework/Versions/2.4/lib/python2.4/site-packages/nose-0.9.0a1.dev_r27-py2.4.egg/nose/case.py, line 48, in runTest self.testFunc() File /Users/taz/projects/turbogears/turbogears/widgets/tests/test_widgets.py, line 398, in test_textfield assert 'id=form_blonk' in tf.render().lower(), '%s' % tf.render() AssertionError: FORM METHOD=post CLASS=listform NAME=form UL LI CLASS=even LABEL CLASS=fieldlabel FOR=blonkBlonk/LABEL INPUT CLASS=textfield TYPE=text ID=blonk NAME=blonk /LI LI INPUT TYPE=submit CLASS=submitbutton /LI /UL /FORM Mmm, I will look into this when I get home. In the meanwhile using InputWidget.adjust_value can work for 0.9a6, I don't expect anyone using repeating fields with an instance ATM. 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Porting from 0.9a4 - 0.9a5 identity
Ville Vainio wrote: We were just about to demonstrate our school project on a fresh laptop and boom, in comes 0.9a5 identity that broke our program. Chalk that one up to lack of preparation, but it would be cool of there were individual preview download pages for stuff that is almost certain to break stuff... That being said, we got another chance at demonstrating our software, are there some specific instructons on how to migrate to the new system? Or alternatively, download an old version of TG and associated dependencies? I tried adding the name field to submit in login.kid and some other configuration thing that I inferred from release notes (but can't remember right now), but it didn't work. I was getting constant stack limit exceeded (recursion) in SQLObject and assumed everything was in a broken state... Is clearly stated in the preview site that updating to 0.9a5 needs special care for identity: http://www.turbogears.org/preview/download/upgrade.html look at the Updating from 0.9x to 0.9a5 section. ;-) Ciao Michele --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] A nicer widget browser with tabs...
Hi guys, during my hacking rampage I've added tabs to our widget browser, but I haven't committed it, take a look here: http://trac.turbogears.org/turbogears/ticket/841 Any css tweaking and TOC help is welcome. Motivation: the actual widget browser is a mess to use, too much infos in a single page. Ciao Michele PS Also (during the rampage) I've removed a lot of boilerplate code from compound widgets by introducing a iter_member_widgets() method that... well the name is pretty self explanatory, I'm not a generator guru so if you see any error or improvement feel free to commit it, this is nice not only for boilerplate but to avoid copy/paste of the same code that makes any fix very hard to propagate. We should add a note to the changelog to suggest our users to use it if they were copying/pasting the old code. ;-) --~--~-~--~~~---~--~~ 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: A nicer widget browser with tabs...
Alberto Valverde wrote: On 08/05/2006, at 13:14, Kevin Dangoor wrote: On 5/8/06, Alberto Valverde [EMAIL PROTECTED] wrote: Have the Tabber widget too, committing soon a patch fort all (widget template, tabber widget, syntaxHilighth widget) Groovy! Thanks! (BTW, the syntax highlighter widget should probably take a list of languages at instantiation time to use for choosing which scripts to run. -- and it needs to be instantiation time, since the javascripts are pulled out in advance...) Yep, I was just implementing that ;) Ok, then I can trash the 2nd-step patch I've made for the template thing, well just 4 lines ... ;-) Anyway I prefer using Template instead of Widget Template, what do you think? it's already clear that the template refers to the widget and we aren't using Widget Sample, Widget Soruce and so on... Thanks! 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: dictionary vs. instance in forms
Kevin Dangoor wrote: I am, of course, not a big fan of pushing responsibility to the user. In some ways, I'd be more interested in extending FormEncode to be able to do getattrs than to push the responsibility to the user. That would allow the user to keep the behavior of any properties they have and whatnot without having to write a custom dictionify function. Because of properties and things, atribute access is really just like a superset of dictionary access (which is what DicitonaryWrapper took advantage of). Personally I think Widgets should always work with a dict since this fits better with the nested paradigm also. We can avoid patching FE and instead we can add to tg.util a ObjToDict wrapper (you get the point) that wraps an object so that we can access it like a dict, then in CompoundWidget we just need this: def adjust_value(self, value, **params): if not isinstance(value, dict): value = ObjToDict(value) return super(CompoundWidget, self).adjust_value(value, **params) this is the best solution that should keep everyone happy, me for the widget code (only use dicts), users and Kevin. ;-) I really prefer wrapping an object to be like a dict that doing the contrary. 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: Adding TurboCheetah to the install_requires
Jorge Godoy wrote: Em Segunda 08 Maio 2006 12:13, Kevin Dangoor escreveu: PasteScript brought along Cheetah (and we actually use it for our quickstart templates). I needed to generate some plain text in a test, and I realized that since we already have Cheetah installed it seems foolish to not also have TurboCheetah (which is tiny in comparison). So, I'm adding TurboCheetah to install_requires so that people can actually choose to use their installed Cheetah if so desired. +1. +1+1 = +2 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Problems Passing Values to Nested Forms
Hi Ed,
1) change:
params = [fieldsets]
to:
member_widgets = [fieldsets]
I told you about this in your last thread but you probably missed it,
it's quite important since fieldsets are not simple params but member
widgets of your form, you need this for validating and passing values,
also member_widgets are not overridable at render/display time.
2) change:
values=myformvalues
to:
value=myformvalues
I also suggest to change:
fieldsets=(MyForm())
into:
fieldsets=MyForm()
but that's not a big problem.
Ciao
Michele
Ed Singleton wrote:
I can't seem to pass values into a nested forms. It's probably a
simple error on my part but I can't work it out to save my life.
from turbogears.widgets import *
class MultiFieldSet(Form):
template =
form xmlns:py=http://purl.org/kid/ns#;
name=${name}
action=${action}
method=${method}
class=tableform
py:attrs=form_attrs
div py:for=fieldset in fieldsets
py:replace=fieldset.display(value_for(fieldset),
**params_for(fieldset))
/
/form
params = [fieldsets]
fieldsets = []
class FS1(WidgetsList):
f1 = TextField()
class FS2(WidgetsList):
f2 = TextField()
class MyForm(WidgetsList):
fs1 = FieldSet(fields=FS1())
fs2 = FieldSet(fields=FS2())
myform = MultiFieldSet(fieldsets=(MyForm()))
myformvalues = dict(fs1=dict(f1=one),fs2=dict(f2=two))
assert one in myform.render(values=myformvalues)
The assert fails for me.
Any help would be greatly appreciated
Thanks
Ed
--~--~-~--~~~---~--~~
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: Problems Passing Values to Nested Forms
Hi Ed,
there is a problem in your template, you shouldn't access the field or
your fieldset directly but let the fieldset display them otherwise the
field will not result as nested once displayed.
I'm trying to understand what you want to do, I will send here another
template.
Ciao
Michele
Ed Singleton wrote:
After a little investigation, my form with multiple fieldsets returns
a nested dictionary when it is submitted, whereas the table form with
multiple fieldsets returns a flat dictionary.
Interesting.
Ed
On 08/05/06, Ed Singleton [EMAIL PROTECTED] wrote:
Well, the form now works fine with values being passed in like there's
no tomorrow.
However the multi fieldset table form I wrote, only seems to accept a
flat list of values, rather than a nested list, which is nice in some
ways, but it's annoying that it is different to the other form.
from turbogears.widgets import *
class MultiFieldSetTable(TableForm):
template =
form xmlns:py=http://purl.org/kid/ns#;
name=${name}
action=${action}
method=${method}
class=tableform
py:attrs=form_attrs
table py:attrs=table_attrs
tbody py:for=fieldset in fieldsets py:strip=True
tr py:if=fieldset.legend
td colspan=2
h1 py:content=fieldset.legendThis is a
Heading/h1
div py:for=field in hidden_fields
py:replace=field.display(value_for(field),
**params_for(field))
/
/td
/tr
tr py:for=i, field in enumerate(fieldset.fields)
class=${i%2 and 'odd' or 'even'}
td
label class=fieldlabel
for=${field.field_id} py:content=field.label /
/td
td
span
py:replace=field.display(value_for(field), **params_for(field)) /
span py:if=error_for(field)
class=fielderror py:content=error_for(field) /
span py:if=field.help_text class=fieldhelp
py:content=field.help_text /
/td
/tr
/tbody
/table
/form
member_widgets = [fieldsets]
fieldsets = []
class FS1(WidgetsList):
f1 = TextField()
class FS2(WidgetsList):
f2 = TextField()
class MyForm(WidgetsList):
fs1 = FieldSet(fields=FS1())
fs2 = FieldSet(fields=FS2())
myform = MultiFieldSetTable(fieldsets=(MyForm()))
nestedvalues = dict(fs1=dict(f1=one),fs2=dict(f2=two))
flatvalues = dict(f1=one,f2=two)
assert one in myform.render(value=nestedvalues)
assert two in myform.render(value=nestedvalues)
assert one in myform.render(value=flatvalues)
assert two in myform.render(value=flatvalues)
Gives me:
assert one in myform.render(value=nestedvalues)
Traceback (most recent call last):
File console, line 1, in ?
AssertionError
assert two in myform.render(value=nestedvalues)
Traceback (most recent call last):
File console, line 1, in ?
AssertionError
assert one in myform.render(value=flatvalues)
assert two in myform.render(value=flatvalues)
Is there an easy way to fix this?
Thanks
Ed
On 08/05/06, Michele Cella [EMAIL PROTECTED] wrote:
Hi Ed,
1) change:
params = [fieldsets]
to:
member_widgets = [fieldsets]
I told you about this in your last thread but you probably missed it,
it's quite important since fieldsets are not simple params but member
widgets of your form, you need this for validating and passing values,
also member_widgets are not overridable at render/display time.
2) change:
values=myformvalues
to:
value=myformvalues
I also suggest to change:
fieldsets=(MyForm())
into:
fieldsets=MyForm()
but that's not a big problem.
Ciao
Michele
Ed Singleton wrote:
I can't seem to pass values into a nested forms. It's probably a
simple error on my part but I can't work it out to save my life.
from turbogears.widgets import *
class MultiFieldSet(Form):
template =
form xmlns:py=http://purl.org/kid/ns#;
name=${name}
action=${action}
method=${method}
class=tableform
py:attrs=form_attrs
div py:for=fieldset in fieldsets
py:replace=fieldset.display(value_for(fieldset),
**params_for(fieldset))
/
/form
params = [fieldsets]
fieldsets = []
class FS1(WidgetsList):
f1 = TextField()
class FS2
[TurboGears] Re: Problems Passing Values to Nested Forms
Yes, that's basically what you need.
Another example, similar to your one here, unfortunately there is kid
bug that prevents this to be even more componentized (you can't put
py:strip in the first tag ATM).
Sorry but now I really have other things to do... :-(
Again, IMHO the best thing is using a custom form that just display a
set of FieldSet, you remove the label, help_text and error thing and
use the FieldSet provided by TG, then with css you can do everything
with it, and use the legend as a heading.
Ciao
Michele
from turbogears.widgets import *
class MyFieldSet(FieldSet):
template =
tr xmlns:py=http://purl.org/kid/ns#; py:for=i, field in
enumerate(fields) class=${i%2 and 'odd' or 'even'}
td
label class=fieldlabel for=${field.field_id}
py:content=field.label /
/td
td
span py:replace=field.display(value_for(field),
**params_for(field)) /
span py:if=error_for(field) class=fielderror
py:content=error_for(field) /
span py:if=field.help_text class=fieldhelp
py:content=field.help_text /
/td
/tr
class MultiFieldSetTable(TableForm):
template =
form xmlns:py=http://purl.org/kid/ns#;
name=${name}
action=${action}
method=${method}
class=tableform
py:attrs=form_attrs
div py:for=field in hidden_fields
py:replace=field.display(value_for(field),
**params_for(field))
/
table py:attrs=table_attrs
div py:for=fieldset in fieldsets py:strip=True
tr py:if=fieldset.legend
td colspan=2
h1 py:content=fieldset.legendThis is a
Heading/h1
/td
/tr
div py:replace=fieldset.display(value_for(fieldset),
**params_for(fieldset)) /
/div
tr
td#160;/td
td py:content=submit.display(submit_text) /
/tr
/table
/form
member_widgets = [fieldsets]
fieldsets = []
class FS1(WidgetsList):
f1 = TextField()
class FS2(WidgetsList):
f2 = TextField()
class MyForm(WidgetsList):
fs1 = MyFieldSet(fields=FS1())
fs2 = MyFieldSet(fields=FS2())
myform = MultiFieldSetTable(fieldsets=(MyForm()))
nestedvalues = dict(fs1=dict(f1=one),fs2=dict(f2=two))
assert one in myform.render(value=nestedvalues)
assert two in myform.render(value=nestedvalues)
Ed Singleton wrote:
I think I know what to do, I need to call fieldset.display() within my
table for each fieldset, but to do that I need to override the
template of fieldset to display a series of table rows.
I think this is roughly what I want:
class TableFieldSet(FieldSet):
template=
tbody xmlns:py=http://purl.org/kid/ns#; py:strip=True
tr py:if=legend
td colspan=2
h1 py:content=legendThis is a Heading/h1
div py:for=field in hidden_fields
py:replace=field.display(value_for(field),
**params_for(field))
/
/td
/tr
tr py:for=i, field in enumerate(fields)
class=${i%2 and 'odd' or 'even'}
td
label class=fieldlabel
for=${field.field_id} py:content=field.label /
/td
td
span
py:replace=field.display(value_for(field), **params_for(field)) /
span py:if=error_for(field)
class=fielderror py:content=error_for(field) /
span py:if=field.help_text
class=fieldhelp py:content=field.help_text /
/td
/tr
/tbody
class MultiFieldSetTable(TableForm):
template =
form xmlns:py=http://purl.org/kid/ns#;
name=${name}
action=${action}
method=${method}
class=tableform
py:attrs=form_attrs
table py:attrs=table_attrs
tbody py:for=fieldset in fieldsets
py:replace=fieldset.display(value_for(fieldset),
**params_for(fieldset))
/tbody
/table
/form
member_widgets = [fieldsets]
fieldsets = []
Ed
On 08/05/06, Michele Cella [EMAIL PROTECTED] wrote:
Hi Ed,
there is a problem in your template, you shouldn't access the field or
your fieldset directly but let the fieldset display them otherwise the
field will not result as nested once displayed.
I'm trying to understand what you want to do, I will send here another
template.
Ciao
Michele
Ed Singleton wrote:
After a little investigation, my form with multiple fieldsets returns
a nested dictionary when
[tg-trunk] Re: Small change to how params (a dict in particular) are managed
Kevin Dangoor wrote: I think you (Michele) made the point a couple messages back, though, that default attrs can be handled directly in the template. input type=foo default=attrs go=here py:attrs=attrs/ And then you can still pass in attrs at instantiation or display time to override, right? I think this makes good sense. attrs is then strictly for overrides. Yep, in fact that's the point, updating is usually useful for attrs like params, but you can achieve the exact same effect in this way that's also more explicit. ;-) I've commit this change (with a small cleanup of the code) at r1407. 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 :) Given that we're still in alpha mode, getting it out earlier is better. I can always release one more alpha if there's major havoc. I'd rather that the beta is not a shaky release. Another good point, done. ;-) At r1406 I've also added support for grouped options, ATM you get it only for Single/MultipleSelectField, any markup idea for CheckBoxList and RadioButtonList? That's what I've done and then discarded: ul divA Group/div li1/li li2/li divAnother Group/div li1/li li2/li /ul 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 -~--~~~~--~~--~--~---
[TurboGears] Re: SingleSelectField missing optgroup functionality
Robin Haswell wrote:
Hi Matt,
Thanks for pointing this out, your right indeed!
I forgot that a dict doesn't preserve the order (sorry guys) (any news
in the python world regarding this? I can't see how maintaining the
order could ever hurt, while mixing it sometimes hurts, WidgetsList...
:-().
Your hybrid solution looks good but probably requires too much
verbosity, for today I'm stopping here, let's see what other thinks, to
recap:
1) My solution n°1
2) Matt solution
vote please! ;-)
Ciao
Michele
Hey Michele, thanks for looking in to this. I was just about to cross Open
ticket on optgroups on
my todo list when I noticed that it seems a bit redundant now. Can I add my
$0.02 on this?
Regarding SingleSelectField vs SingleSelectFieldWithOptgroups, I think this
is unnecessary as the
format of the parameter is going to make this rather obvious, and the two
aren't necessarily exclusive.
I propose the solution of:
[
(None, [Please choose an option]),
('Dynamic Languages',
[(1, Python), (2, Ruby)]
),
('Others',
[(3, Java), (4, C++)]
),
]
This gives us the advantage of allowing us to `zip` two lists - a list of
optgroups and a list of
options:
optgroups = [None, Dynamic Languages, Others]
options = [
[Please choose an option],
[(1, Python), (2, Ruby)],
[(3, Java), (4, C++)]
]
select_options = zip(optgroups, options)
print select_options
[(None, ['Please choose an option']), ('Dynamic Languages', [(1, 'Python'),
(2, 'Ruby')]),
('Others', [(3, 'Java'), (4, 'C++')])]
I think my solution is more semantically accurate (and easier to generate the
structure)3 than the
equivalent dict option, however differentiating between what is supposed to
be a regular single
select field and what is supposed to have optgroups might be a bit messy:
for value, option in options:
if type(option) is list:
# optgroup code
pass
else:
# just show an option/
pass
However, this allows us to simplify our case of when we don't want an
optgroup before some optgroups to:
[
(None, Please choose an option), # The second value of this tuple is
not a list
('Dynamic Languages',
[(1, Python), (2, Ruby)]
),
('Others',
[(3, Java), (4, C++)]
),
]
Of course, if detecting whether we want an optgroup or not is a bit messy, we
could always have an
OptGroup widget. I'm not a fan of this plan though as I think more class
hoop-jumping is bad :-/
Cheers
-Rob
Hi Robin,
Thanks for the feedback, incidentally this is the exact syntax I
ended-up to implement yesterday:
http://tinyurl.com/hpzbj
You will probably find this into 0.9a6 since I'm going to commit it...
;-)
Ciao
Michele
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[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] Small change to how params (a dict in particular) are managed
Hi guys,
while implementing this:
http://tinyurl.com/z4clj
initial patch here (yes, the mystical ticket #490 :D):
http://trac.turbogears.org/turbogears/attachment/ticket/490/optgroup-support.patch
I noticed that since the SelectionField is declaring options as a list
we can't pass a dictionary at construction since our params managing
system tries to update the original dict (that's a list in this case)
with the new one and raises an error (update method not present on a
list).
This is a good occasion since I was going to bring the issue up anyway,
ATM if you declare something like:
class Foo(Widget):
params = [attrs]
attrs = {'size': 10}
when you do:
foo = Foo(attrs={})
or
foo.render(attrs={})
you will *always* end-up with attrs={'size':10} anyway since not like a
normal variable and not like a normal list we manage dictionaries in a
different way and upgrade the original one in this sequence.
Now, this is something that I don't like so much anymore and I would
rather prefer to remove it since I swear this is not what people would
normally expect to happen and I can see it's usefulness only for attrs
like things, but in this case we can get the exact same behavior by
declaring attributes used by default inside the template this is also
more explicit and works thanks to how py:attrs works.
Note that my initial idea of implementing it in this way was in fact
given by how py:attrs works and was not taking into account more use
cases like the one I mentioned above that not only doesn't work but
will also introduce an unwanted behavior IMHO.
Opinions? If we all agree I will finish the patch and do this slight
change that will also cleanup (only) a bit the params code.
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
Jorge Godoy wrote: You mean making it an attribute that can be used directly as we have label, attrs, etc. today. I agree that it is better. I also remember that we agreed on doing this only for required attributes and providing the rest within the dict attrs. You're, now, proposing that we change this and support *all* possible attributes somehow? No, this is not what I'm discussing about... I know I always ask, but... What will I have to change in my code? ;-) heheheheh... I'm a bit tired of changes and things stopping working (I'll post another message about a new unwanted behavior for a widget) so often. But if it is for better and if I can help testing it, just make it clear what has to be changed... :-) This is the key concept: If you're using a dict in params this dict is updated (and not replaced) with the one passed at init and then the one passed at render/display, is this what most people expects? or should replace the dict instead of updating it? So: 1) Update a dict param with the following chain class-init-display 2) Simply replace it? 1 or 2? Nothing will change in your code (most probably) if you're not dealing with some widgets that provide a dict that's not empty and you pass just the options you want to update, and IIRC apart from some deprecations (all backward compatible) the API has been kept backward compatible for a long time now... ;-) 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 -~--~~~~--~~--~--~---
[TurboGears] Re: SingleSelectField missing optgroup functionality
Mark Ramm wrote: In fact, not only backwards compatible but not making optiongroup required at all. The majority of cases won't require it. If backwards compatibility and making optiongroup optional are difficult we could just create a whole new SelectWithOptionGroupWidget. Hi guys, no, that's not a problem I've already implemented the whole thing in a totally backward compatible way, if you want to look at the patch (initial attempt): http://trac.turbogears.org/turbogears/attachment/ticket/490/optgroup-support.patch As you can see if you want to use the group functionality the template only requires a small addition else it works exactly as before. Ciao Michele PS there is only a small issue a will discuss about in the trunk list --~--~-~--~~~---~--~~ 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: SingleSelectField missing optgroup functionality
Matt Good wrote:
The option groups sound like a good idea. The dict implementation seems
easy to use, but unfortunately you lose all control over the ordering of
the groups and can't have options without a group. If you wanted to
keep the options more structured you could use a hybrid solution:
options=[(None, 'Please choose an option'),
{'Dynamic Languages':
[(1, Python),
(2, Ruby)]},
{'Others':
[(3, Java),
(4, C++)]}]
If you wanted to also allow multi-keyed dicts of option groups sorting
by the key would keep them from appearing in totally random order.
Hi Matt,
Thanks for pointing this out, your right indeed!
I forgot that a dict doesn't preserve the order (sorry guys) (any news
in the python world regarding this? I can't see how maintaining the
order could ever hurt, while mixing it sometimes hurts, WidgetsList...
:-().
Your hybrid solution looks good but probably requires too much
verbosity, for today I'm stopping here, let's see what other thinks, to
recap:
1) My solution n°1
2) Matt solution
vote please! ;-)
Ciao
Michele
--~--~-~--~~~---~--~~
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
-~--~~~~--~~--~--~---
[tg-trunk] Re: fastdata-incompatible change in widgets?
Alberto Valverde wrote: I'm not sure it's the problem... I wanted Max to test the patch to confirm, but I'm pretty sure it is. Your proposal sounds good, however, I'm not sure how to implement it (maybe inspecting the 'path' at CP.request?) Using my memory, we can try something like this: if self.path and (self.path[0].widget is self): [do the from_python thing] that means if the path is not empty and we are the top level widget in the path (usually the form), anyway thinking about it this may cause some problem when using display_field_for since here you directly pass the value to the widget at display without passing it to a form... we may need a better solution. Oh just comes to my mind, we can simply force convert=False to be used by every CompoundWidget with it's members, we just need to cycle our member widgets and put convert=False into params[member_widgets_params] for every member_widget that's not a compound. something like this into update_params of a CompoundInputWidget will work: def update_params(self, params): ... convert = dict() for member in self.__class__.member_widgets: for attr_name in self.__class__.member_widgets: attr = getattr(self, attr_name, []) if not isinstance(attr, list): attr = [attr] for widget in attr: if not getattr(widget, compound, False): convert[widget.name] = False params[member_widgets_params][convert] = convert I'm pretty sure this solution will work (if the problem is the one we're talking about) and it's the best one IMHO since it's totally transparent, anyone that can give this one a go? 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Summer of Code - SQLAlchemy schema migration
Evan Rosson wrote: Hey all, I'd like to create a tool to help with SQLAlchemy schema migration a bit. I've been interested in this for a while now (ie. I'm not just blindly copying a suggestion from this mailing list) - I'm working on a TG project which I know will have a good number of database changes later on (lots of small changes, mostly), and I need a way to manage that. SQLAlchemy fits many other requirements for my project, but lacks a tool to manage schema changes; I've been looking into how I'd make a good schema migration tool - seems like a good candidate for my SoC project. I've made good progress on my proposal, though it's not done just yet. I think I've got a pretty good plan so far, but more info on how this has been done before would be helpful. So, my question: has anyone out there have a schema migration tool they've used and really liked? I'm familiar with these: - SQLObject's versioning: http://sqlobject.org/sqlobject-admin.html#versioning-upgrading - Rails' migration: http://api.rubyonrails.com/classes/ActiveRecord/Migration.html - Writing migration scripts by hand (the default way to do things, with no tool) Anyone out there used something good for this that I haven't looked into? Cool. There are also a lot of info here: http://code.djangoproject.com/wiki/SchemaEvolution Good luck! Ciao Michele --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: unicode() argument 2 must be string, not None
Kevin Dangoor wrote: On 5/1/06, Michele Cella [EMAIL PROTECTED] wrote: I've some fixes to try here but I'm getting this error again using latest 1.0 branch from the toolbox and also inside a quickstarted project, am I the only one? The Toolbox works for me. Is it possible you've got an old version of a widget or something? Once this is fixed, I'm going to tweak WidgetDescription to not pass a value at display since you can easily achieve the same effect using default at for_widget construction and this fixes a bug. Sounds good. We should merge all docs to the trunk, right? You can, but it's not critical. The docs are going to leave this part of the repository anyhow, once I get a little time to migrate them to Docudo. Ok, but just to keep the timeline ordered I merged them. ;-) Regarding the unicode issue now it's all working fine, dunno why! :D It could be that I forgot to update the kid support plugin... :-/ Anyway, it's there something we can do for this thing in the console output? Traceback (most recent call last): File /usr/lib/python2.4/logging/__init__.py, line 737, in emit self.stream.write(fs % msg) AttributeError: 'str' object has no attribute 'write' 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: unicode() argument 2 must be string, not None
Kevin Dangoor wrote: I haven't seen this one myself. This is just with the default logging configuration? This could be another false alarm, it seems as you get it only if running tg-admin toolbox from outside a project dir hence without a default configuration, not a big problem... ;-) 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] Task based documentation
Hi guys, I would like to hear your opionion regarding how our docs are actually organized, personally I find the *big* index of content too much book oriented, it doesn't fit so well inside the web and it's quite intimadatory for the newbie, that was my first impression at least. What I find way more friendly and appealing is the concept of task based documentation, for example instead of presenting a link like tg-admin we should use something like: Managing your application from the command line or identity: Adding authentication support to your application and so on. I'm sure you get the point, I really dislike the index of content style, it's pretty difficult to search what you're looking for when what you want is searching for the way you have to do a particular thing. Opinions? 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: Task based documentation
Alberto Valverde wrote: +1, though reference style docs are also helpful... maybe these could be placed in docstrings and link to the pydoc generated pages from the tasks? Yeah, indeed reference are essential but ATM we have a mix of the two things, and since we are under-documented the table of contents style also gives a bad impression. I particularly like how the Django folks are doing this: http://www.djangoproject.com/documentation/ 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: unicode() argument 2 must be string, not None
Kevin Dangoor wrote: On 5/2/06, Michele Cella [EMAIL PROTECTED] wrote: This could be another false alarm, it seems as you get it only if running tg-admin toolbox from outside a project dir hence without a default configuration, not a big problem... ;-) That would still be a bug though. Do you want to Trac it? Done ;-) http://trac.turbogears.org/turbogears/ticket/815 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: 'tg_exception' in errorhandling in .9a5 out of sync with branch 1.0
Jorge Godoy wrote: Em Terça 02 Maio 2006 14:19, Alberto Valverde escreveu: I'm confused then... why did .9a5 come out from trunk instead of 1.0? I got the impression that bugfixes to get 1.0 out should go to branch 1.0 and experimental stuff to trunk (http://tinyurl.com/m8snp). Am I missing something? I thought the same: stable changes (bugfixes) in 1.0 and new features + other stuff into the trunk... I can't answer about why using the trunk for 0.9a5... Mmm, I haven't noticed this, if 0.9a5 has really come out from trunk I think Kevin inadvertantely swapped his shells most probably, luckily enough [1257] is the only divergence between the two ATM. 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Custom Form Widgets
Ed Singleton wrote:
I guess so, but I really would like to work out how to create my own
form fields. Is there no explanation of how the widgets work
internally?
Not much ATM :-(, anyway keep this in mind usually what you need are
more parameters to customize the widget behavior at display/render
time, to do this *all* that you need is listing an additional parameter
in params, this tells the Widget system that this is attribute is
special and you can update it at construction or render/display and
it's available inside the template or update_params, you don't need to
override init or update_params to manage it.
Example:
class FooBar(Widget):
template = div${foo}/div
params = [foo]
foo = Hello
Thanks for this. It was enough info for me to do a rough draft of
what I want. It's untested and needs more stuff adding, but it's
basically what I want. (Though I really want to know how I add extra
parameters and stuff). It's the RepeatingFieldSet with a different
template (uses the legend for the header content):
Are you sure that what you want is a repeating widget? this widget uses
a repetitions parameter to display one or more repetitions of the same
widget and to validate them.
I think you don't want this in your case...
Ciao
Michele
--~--~-~--~~~---~--~~
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: TG Email Wrapper, Please Test
jvanasco wrote: TG doesn't handle email, and the class in trac broke on rev962 so i rewrote the whole thing add a few lines to app.cfg to configure, and you're good to go i've tested it w/sendmail - it works i don't have access to a non-ssl smtp server, so i can't test for that ( i require ssl on all my boxes, and don't have them configured to ignore it on localhost, neither do i want to do that ) http://dev.2xlp.com/svn/turbogears_extensions/turboemail/trunk/ Cool, you may want to use turbogears.view so that you can pass a valid TG template path and you get template plugin support for free, for example template=stan:templates.confirm_email and you just need to pass a dict and so on. Also, that's what rails offers just to provide you a reference: http://api.rubyonrails.org/classes/ActionMailer/Base.html Keep up the enthusiastic work. ;-) Ciao Michele --~--~-~--~~~---~--~~ 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: Custom Form Widgets
Ed Singleton wrote: No not at all sure. I assumed the RepeatingFieldSet iterated through some fieldsets, displaying each one. I do like the idea of building FieldSets and then constructing a form out of a bunch of fieldsets (Contact Info, or similar will be on a lot of forms and I can just insert that fieldset in my form rather than copy and paste it each time). No, RepeatingFieldSet displays n repetitions of the *same* FieldSet. Yes, building and reusing fieldsets is indeed a nice way of doing things IMHO, and widgets support this quite well. I think you don't want this in your case... Probably not, but I do now want to do something with groups of fieldsets rather than with a single long form with headers inserted. However I have produced this, which seems to work fine for the moment (I'm going to go look more at fieldsets now). Ok, you may want to use a different name than TableForm and avoid repeating everything apart from templates if you inherit form it (TableFormWithHeaders(TableForm)), params and such are all automatically inherited from your bases classes. ;-) Ciao Michele --~--~-~--~~~---~--~~ 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: Custom Form Widgets
Alberto Valverde wrote: Looks pretty good :) One thing, class MultiFieldsetTable(TableForm) could be just class MultiFieldsetTable(Form) as you're providing a custom template. TableForm just provides a template to Form so you can skip one inheritance step. Just a picky detail ;) @Alberto: That's not the case since Ed is also using table_attrs in its template that's provided by TableForm. @Ed: Change this: params = [fieldsets] fieldsets = [] to be: member_widgets = [fieldsets] fieldsets = [] this ensures that fieldsets is immutable after construction, that the validation schema is correctly generated and that javascript and css for member widgets are retrieved correctly. As a rule of thumb, you use params for every generic parameter that you can update at subclassing, construction and display/render, while you use member_widgets when you're making a CompoundWidget that's made up of other widgets, in this case your various field sets. Other than that everything looks ok. Ciao Michele --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: MultipleSelectField problem with latest svn
Hi Max,
Actually I can't look more deeply into your code anyway I can tell you
why _is_option_selected works in this way and why it should work in
this way.
Let's say you have a MultipleSelectField like this:
MultipleSelectField(name=languages, options=[(1, Python), (2,
Java), (3, Ruby)])
as you can see we are using int as values, hence the guessed validator
is Int().
Ok, now you submit a form that contains such a field with some values
selected, the form has an error hence it's redisplayed and the field
grabs the value previously selected by the user (we want this behavior)
from the request, since those values are coming from the web they
always are strings, hence we have something like this for instance:
languages = ['1', '3']
if _is_options_selected doesn't coerce those values to be coherent with
the values we expect from this field (that as I said are Int(s)) they
will never match and hence we will redisplay the field with nothing
selected while the user actually selected something.
I hope this helps you understand the logic behind that, your
from_python method should return a string (this is just what you need
in the web world) while to_python should return the same type you're
passing as options ids.
Ciao
Michele
PS
Is there a good reason you reverted patch #785 here:
http://trac.turbogears.org/turbogears/changeset/1340
when you already committed it to both branch in:
http://trac.turbogears.org/turbogears/changeset/1242
http://trac.turbogears.org/turbogears/changeset/1243
??? :D
Max Ischenko wrote:
Hi,
I have a TableForm widget which uses MultipleSelectField.
After recent updates I discovered that it no longer displays currently
selected options properly. It used to work OK so I'm not sure whether the
error is in my code or there is (introduced) bug in widgets code.
The problem, as I see it, is that _is_option_selected compares raw input
values with converted options values and those never match.
E.g.: data['readers'] are user ids; options list contains user ids as well.
But then _is_option_selected converts (with .to_python) data['readers'] into
proper User instances and compares them with ids from the options list
Here is my code, hopefully someone can help me to figure out what's wrong.
form = widgets.TableForm('manage', fields=[
...
widgets.MultipleSelectField('readers', label='Readers',
validator=ModelReferenceValidator(User, if_empty=0),
options=list_regular_users),
])
# options value list
def list_regular_users():
users = [...]
options = [(u.id, str(u)) for u in users]
return options
# controller excerpt:
data['readers'] = [r.grantee_user.id for r in rules if (...) ]
# my validator:
class ModelReferenceValidator(validators.FancyValidator):
def __init__(self, modelClass, *args, **kw):
validators.FancyValidator.__init__(self, *args, **kw)
self.modelClass = modelClass
def _to_python(self, value, state):
if isinstance(value, self.modelClass):
return value
try:
pk = long(value)
return self.modelClass.get(pk)
except (ValueError, TypeError):
raise validators.Invalid, \
(self.message('integer', state), value, state)
except SQLObjectNotFound:
typename = self.modelClass.__name__
raise validators.Invalid, \
(self.message('invalid', state, type=typename), value,
state)
_from_python = _to_python
--~--~-~--~~~---~--~~
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] unicode() argument 2 must be string, not None
Hi guys, I've some fixes to try here but I'm getting this error again using latest 1.0 branch from the toolbox and also inside a quickstarted project, am I the only one? Once this is fixed, I'm going to tweak WidgetDescription to not pass a value at display since you can easily achieve the same effect using default at for_widget construction and this fixes a bug. Ciao Michele PS We should merge all docs to the trunk, right? --~--~-~--~~~---~--~~ 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: model - widgets
Joris wrote: Hi all, This is probably an obvious and/or stupid question since I'm not a Programmer by any measure, but please bear with me. I start a TG project and define a nice model. Then I find myself repeating much of the model for the widgets/forms. So much, that I've started doing copy/pastes. Is there no way to automate the conversion between sqlobject-properties (with added validators) to forms? It would be nice to say FormAlize(Somesqlobject) and not bother with it again? Install FastData and use formmaker.fields_for: http://trac.turbogears.org/turbogears/browser/projects/FastData/trunk/tgfastdata/formmaker.py#L124 Example: from model import Page fields_list = fields_for(Page) And you're done. ;-) Ciao Michele --~--~-~--~~~---~--~~ 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: How to use tg.fancy_exception?
Robin Haswell wrote: I saw this in the feature list for .9a5 which intrigued me: * Added a new turbogears.start_server function which will help ease the transition to 1.1 *and* adds the ability to use Ian Bicking's EvalException. You must turn on tg.fancy_exception to use it at this point. I was wondering, how do you enable this? I tried putting tg.fancy_exception=True in the global section of dev.cfg, but it didn't seem to do any good. Could someone provide some advice please? Cheers :-) Works fine here, by the way you need an exception to see it in action. ;-) assert False works fine as a first test. Ciao Michele --~--~-~--~~~---~--~~ 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: TurboGears 0.9a5 released!
jsonified (#472) * datetime.date instances are properly jsonified (#759) * Commas are supported in number validation (#720) * It's now possible to determine what permissions are required for a given controller method (#603) *Changes* * Identity model classes are now placed directly into the model.py of a quickstarted project. This new setup is much easier to change, since requirements for the identity model vary dramatically. Another advantage is that quickstart projects that don't need identity start off with cleaner code, and projects that do need identity need almost no additional configuration or setup. * quickstart projects include a json.py file as a home for JSON view code. * i18n scan command has been changed to collect to match the admi18n Toolbox tool * If you quickstart a project while in an svn checkout, files are no longer automatically svn added. This corrects some problems that people ran into with that behavior. * The prod.cfg file in quickstart projects is now called sample-prod.cfg to reflect that it is just used as a sample that you copy to your real production servers (#762). * The various classes used to make dictionaries look like normal objects have been replaced by turbogears.util.Bunch (#779) *Fixes* * Model Designer can now handle joins to the same table (#769) * Unicode values sent to the turbogears.url function are utf8 encoded. * NotEmpty validator works with CheckBoxList now. (#696) * Grid widget's css has been improved to not interact with other widgets (#729, thanks to [EMAIL PROTECTED]) * the self parameter is no longer accidentally removed by validation * tg_format is properly stripped out for JSON requests (#740) * calendar widget language fixes (many language files needed patching) * DataController's float columns are properly converted (#707) * str values in Kid templates are now assumed to be utf8 rather than ASCII (changeable via kid.encoding) (#743) * The flash message set on the current request takes precedence over the one in the cookie (#747) * py:match was being used in the default templates in a way that would drop the text from the first node. (#785) * AutoCompleteField widget's only_suggest now works correctly when there is only one item listed (#750) * Lots of HTML cleanup *Project Updates* * TurboGears now uses ConfigObj 4.3.0 for configuration * MochiKit upgraded to 1.3 * simplejson upgraded to 1.3 * CherryPy upgraded to 2.2.1 * Kid upgraded to 0.9.1 * FormEncode upgraded to 0.5.1 * PasteScript upgraded to 0.5.1 *Contributors* Alberto Valverde González, Jeff Watkins, Max Ischenko, Michele Cella, Simon Belak, Jorge Godoy, Patrick Lewis, Jorge Vargas, Joost Moesker, Joseph Tate, Philip Walls, Bob Ippolito, Steve Bergman, Andrey Lebedev, Brian Beck, Roger Demetrescu. --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
[tg-trunk] Re: how about tomorrow for a5? :)
Jorge Vargas wrote: Ahh me too. Good to know it's not just me Well, anyway you're probably more lucky than me since I'm still on 56k and not for my decision... :-( 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: Inconsistent behavior with widgets ordering on widgets.WidgetsList (again)
Jorge Godoy wrote: But you're supposing that common_widget is *one* widget only. What if it is a list (I'd write set but we have it in Python as well, so... ;-)) of them? Same applies, you have to deffer the widget creation to when you effectively use it. As I said if we want to fix something like this to work I have a pretty straightforward patch that works, still I'm not sure suggesting to nest WidgetsList is something we should do, it looks so ugly. :P I'll check this and it solves the problem for me in an ugly way -- I'd rather have all my widgets inside widgets.WidgetsList derived classes instead of mixing functions and classes to write them. Specially because there are cases where the widget alone makes sense and should be usable to build a form... So, can I do, with the above code: my_form = widgets.TableForm(fields = common_widget()) wrap it inside a list: my_form = widgets.TableForm(fields = [common_widget()]) I can't see the problem, you're just using a single widget so you need to wrap it in a list, but this is saving you [index] in the WidgetsList declaraion, or you can also do if you: def common_widget(in_list=False): if in_list: return [TextField()] else: return TextField() then: class MyWidgets(WidgetsList): name = TextField() common = common_widget my_form = widgets.TableForm(fields = common_widget(True)) 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: Inconsistent behavior with widgets ordering on widgets.WidgetsList (again)
Jorge Godoy wrote: Em Quinta 27 Abril 2006 17:22, Michele Cella escreveu: With 3 lines of code I have a working solution but this won't go into 0.9a5, I need to flesh out some other things before doing that, for example in your code what name do you expect the widget to get? If I do: name = SomeClassOfWidgetsList()[0] I'd expect it to be named name for this place. If using the name declared at SomeClassOfWidgetsList is easier, then I wouldn't bother using the same name everywhere. But being able to override it in a different place would be really nice. That's why you can't nest WidgetsList, at this point the name is invariable since using a WidgetsList you defined it before, basically if is_named is True the WidgetsList should not modify it. class Foo(w.WidgetsList): ... hello = w.TextField(name=bar) ... name = w.TextField() ... for widget in Foo(): ... print widget.name, widget.is_named ... bar True name True 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: a5 - thursday
jvanasco wrote: If this ticket for 'TurboEmail' is good as-is ( which some suggested - but I don't know ), it would be nice to have it in now. http://trac.turbogears.org/turbogears/ticket/244 Great work with everything Keven others. Thanks a ton. Mmm I think something like this should be an external plugin. Just my two cents. 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: r1257 (potentially breaks error handling and failsafe)
Roger Demetrescu wrote: Hi Michele !!! On 4/26/06, Michele Cella [EMAIL PROTECTED] wrote: (...) I particularly like your commit message! :D +1 ! Oh, and please Michele (one L not two, only Roger calls me Michelle) :D My God !!! Why didn't you tell me before !!? Since when did you change your name ? I swear I have read you name as Michelle all this time... really :)) Sorry man... it won't happen again... LOL no problem! ;-) 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: Inconsistent behavior with widgets ordering on widgets.WidgetsList (again)
Mmmm, everytime a widget is declared it increments a global counter to keep the right order of declaration (since a class dict is not ordered sadly), we may experiment with tweaking the WidgetsList so that when a new instance of it is created it tells the widget to increment it's counter this could do the trick, I'm going to experiment with it quickly since I need to do some Java programming here also... :-( Ciao Michele Jorge Godoy wrote: Hi... Continuing to refactor several forms I isolated some common fields and I found out that I can reuse them inside a new list. Something like this: class CommonWidget(widgets.WidgetsList): my_common_widget = widgets.SomeField(...) class UseCommonWidget(widgets.WidgetsList): one_widget = widgets.OneField(...) another_widget = widgets.AnotherField(...) common = CommonWidget()[0] class UseCommonWidgetAsWell(widgets.WidgetsList): other_widget = widgets.OtherField(...) yet_another_widget = widgets.YetAnotherField(...) common = CommonWidget()[0] after_common_widget = widgets.AfterCommonField(...) And this works except for the fact that CommonWidget doesn't respect the ordering while displaying a form that uses any of UseCommonWidget or UseCommonWidgetAsWell. They are placed as the first widget while rendering the template. It doesn't matter -- on my tests -- what type of widget is SomeField (TextField, CheckBox, SingleSelectField) this always happens. If I have this CommonWidget as the last one there's no problem in concatenating it while creating the form and in fact I do that for several forms. The problem is when CommonWidget should be in the middle of the form what would require me to split the form in two so that I could concatenate them -- breaking the logic flow sometimes. Or when there are three, four different common fields (it is not feasible to break a form in 5 or 6 parts just because of that). Why am I worried with that? Because it requires one to either duplicate code and makes maintenance more problematic and also because this is not the behavior we have with lists, where order is preserved: some_list = [1] another_list = [2, 3, some_list[0], 4] another_list [2, 3, 1, 4] So, is there any magic going on here? Is it intentional? If not, is it possible to fix this so that we have a consistent behavior with lists and widgets lists? (Making it clear, these aren't HiddenFields ;-)) -- Jorge Godoy [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: logical logging - at last!
Jorge Godoy wrote: Em Quinta 27 Abril 2006 14:15, Kevin Dangoor escreveu: That's a great idea. I'll have to fiddle with the code a little bit, but I think I can do that. Though I agree that a separate log.cfg would be nice, I'll probably drop them in app.cfg for now because that requires fewer changes. If in the future you read log.cfg before reading app.cfg -- if possible -- I believe we can change approaches in a backwards compatible way. :-) It is better having logging in app.cfg than not having it so I don't mind having a big file as well (hey! I already have httpd.conf and other Apache's mess... ;-)) Great work Kevin, and +1 for log.cfg when possible. :-) 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: logical logging - at last!
Kevin Dangoor wrote: On 4/27/06, Michele Cella [EMAIL PROTECTED] wrote: Great work Kevin, and +1 for log.cfg when possible. :-) Already done :) Oh that's great, are these tickets fixed now? http://trac.turbogears.org/turbogears/ticket/609 http://trac.turbogears.org/turbogears/ticket/609 Ciao Michele PS Don't forget the CHANGELOG diff I have sent to you. ;-) --~--~-~--~~~---~--~~ 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: logical logging - at last!
Kevin Dangoor wrote: On 4/27/06, Michele Cella [EMAIL PROTECTED] wrote: Oh that's great, are these tickets fixed now? http://trac.turbogears.org/turbogears/ticket/609 http://trac.turbogears.org/turbogears/ticket/609 I think I'm seeing double. 609 and 609 are both fixed. :) D'oh!! :D http://trac.turbogears.org/turbogears/ticket/506 not sure about this one, this is probably internal TG conventions? disclaimer: haven't read the whole ticket 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: Inconsistent behavior with widgets ordering on widgets.WidgetsList (again)
With 3 lines of code I have a working solution but this won't go into 0.9a5, I need to flesh out some other things before doing that, for example in your code what name do you expect the widget to get? my_common_widget will be used name, since the widget at this point is_named we can't change this state arbitrarily. Ciao Michele Michele Cella wrote: Mmmm, everytime a widget is declared it increments a global counter to keep the right order of declaration (since a class dict is not ordered sadly), we may experiment with tweaking the WidgetsList so that when a new instance of it is created it tells the widget to increment it's counter this could do the trick, I'm going to experiment with it quickly since I need to do some Java programming here also... :-( Ciao Michele Jorge Godoy wrote: Hi... Continuing to refactor several forms I isolated some common fields and I found out that I can reuse them inside a new list. Something like this: class CommonWidget(widgets.WidgetsList): my_common_widget = widgets.SomeField(...) class UseCommonWidget(widgets.WidgetsList): one_widget = widgets.OneField(...) another_widget = widgets.AnotherField(...) common = CommonWidget()[0] class UseCommonWidgetAsWell(widgets.WidgetsList): other_widget = widgets.OtherField(...) yet_another_widget = widgets.YetAnotherField(...) common = CommonWidget()[0] after_common_widget = widgets.AfterCommonField(...) And this works except for the fact that CommonWidget doesn't respect the ordering while displaying a form that uses any of UseCommonWidget or UseCommonWidgetAsWell. They are placed as the first widget while rendering the template. It doesn't matter -- on my tests -- what type of widget is SomeField (TextField, CheckBox, SingleSelectField) this always happens. If I have this CommonWidget as the last one there's no problem in concatenating it while creating the form and in fact I do that for several forms. The problem is when CommonWidget should be in the middle of the form what would require me to split the form in two so that I could concatenate them -- breaking the logic flow sometimes. Or when there are three, four different common fields (it is not feasible to break a form in 5 or 6 parts just because of that). Why am I worried with that? Because it requires one to either duplicate code and makes maintenance more problematic and also because this is not the behavior we have with lists, where order is preserved: some_list = [1] another_list = [2, 3, some_list[0], 4] another_list [2, 3, 1, 4] So, is there any magic going on here? Is it intentional? If not, is it possible to fix this so that we have a consistent behavior with lists and widgets lists? (Making it clear, these aren't HiddenFields ;-)) -- Jorge Godoy [EMAIL PROTECTED] --~--~-~--~~~---~--~~ 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: how about tomorrow for a5? :)
Kevin Dangoor wrote: I may very well have the release ready today, but I don't like releasing at the end of the day in case something is very wrong with the build that's out there. Go for it. ;-) There is a small typo in the CHANGELOG.txt: In widgets, if the widget you are using provides a default validator, for example a SelectionWidget, you can tweak its parameters ***without*** by just passing a dictionary of those parameters as validator (for example, validator=dict(not_empty=True)) I would do it myself but I have some connection problem 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: line endings
Kevin Dangoor wrote:
I got a couple conflicts trying to merge from 1.0 to trunk and it
looks like test_errorhandling at least has some bad line endings that
my editor graciously corrected, but now I need to merge. (And it's
harder for me to know if I just take everything since work has begun
on the trunk).
So, just a reminder to keep your editors set for spaces and unix-style
line endings.
Yep I also noticed this sometimes ago but forgot to mention it, by the
way here we get an useful output I think:
[EMAIL PROTECTED]:~/Progetti/TurboGears/svn/1.0/turbogears$ svn revert -R *
Skipped 'catwalk-session'
[EMAIL PROTECTED]:~/Progetti/TurboGears/svn/1.0/turbogears$ find . -name
*.py -exec dos2unix '{}' \;
[EMAIL PROTECTED]:~/Progetti/TurboGears/svn/1.0/turbogears$ svn revert -R *
Skipped 'catwalk-session'
Reverted 'decorator.py'
Reverted 'genericfunctions.py'
Reverted 'i18n/format.py'
Reverted 'i18n/utils.py'
Reverted 'tests/catwalk_models/model_list.py'
Reverted 'tests/catwalk_models/model_structure.py'
Reverted 'tests/catwalk_models/single_join.py'
Reverted 'tests/catwalk_models/browse.py'
Reverted 'tests/test_catwalk.py'
Reverted 'toolbox/catwalk/browse.py'
Reverted 'widgets/tests/test_datagrid.py'
[EMAIL PROTECTED]:~/Progetti/TurboGears/svn/1.0/turbogears$
it seems those files have been all corrected.
Should I try with *.*?
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: Inconsistent behavior with widgets ordering on widgets.WidgetsList (again)
Jorge Godoy wrote: Hi... Continuing to refactor several forms I isolated some common fields and I found out that I can reuse them inside a new list. Something like this: class CommonWidget(widgets.WidgetsList): my_common_widget = widgets.SomeField(...) class UseCommonWidget(widgets.WidgetsList): one_widget = widgets.OneField(...) another_widget = widgets.AnotherField(...) common = CommonWidget()[0] class UseCommonWidgetAsWell(widgets.WidgetsList): other_widget = widgets.OtherField(...) yet_another_widget = widgets.YetAnotherField(...) common = CommonWidget()[0] after_common_widget = widgets.AfterCommonField(...) Actually I would like to strongly discourage nesting WidgetsList in this way, we end up with some problems related to naming those widgets and their declarative_counter also I would like to suggest you a far easier solution that actually works: from turbogears import widgets def common_widget(): return widgets.TextField() class FooBar(widgets.WidgetsList): bar = widgets.TextField() common = common_widget() foo = widgets.TextField() key = common_widget() mouse = common_widget() for widget in FooBar(): print widget.name output: bar common foo key mouse Rule of thumb of the day: never nest WidgetsList instances. This avoids you any sort of problem. 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 -~--~~~~--~~--~--~---
[TurboGears] Re: Fun with Forms - Captchas and Redirects
jvanasco wrote: ok, i'm 2/3 done w/a captcha class. i'll post it tomorrow, but i don't know if i can get it widgetized. maybe somone can help with that. the general idea is: it requires PIL and freetype. Its modeled after http://svn.navi.cx/misc/trunk/pycaptcha/ , but trying to push it closer to the google captcha system (which i hear is pretty strong ) i've been using pwntcha as a guide ( http://sam.zoy.org/pwntcha/ ) instead of storing anything in the server, it generates an md5 of the captcha text + a site secret , and provides that to be displayed on the page as a hidden element. validate the captcha and the md5 will match. hooray. Very nice, maybe when you're done I can look at it to see what an eventual widget could look like, some times ago I brainstormed an eventual captcha widget. IMHO it should be pretty straightforward to use in this way, you have a captcha form field that visually provides an entry (to enter the captcha text) and the image, on the code side this widget has a custom FE validator that validates (using your system) the entered text and takes care of everything, so in the end to use your captcha one should be able to just do something like this. class MyFields(WidgetsList): name = TextField() password = TextField() captcha = CaptchaWidget() not sure anyway. Ciao Michele --~--~-~--~~~---~--~~ 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: Fun with Forms - Captchas and Redirects
Sylvain Hellegouarch wrote: This is the way we do with docs.cherrypy.org. Have a look at the following code: http://cherryobject.python-hosting.com/file/trunk/cherry/util/captcha.py That's a very interesting piece of code Sylvain, any applied example code? I've seen you're using it in docs.cherrypy.org for the comment form, it would be nice to look at the underlying code, is that code hosted somewhere or closed? Thanks. Ciao Michele --~--~-~--~~~---~--~~ 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: SQLObject rant: unicode support sucks
jvanasco wrote: Are you sure that truncation is done in sqlobject? what database are you using? if its mysql, chances are the truncation happened there ( you can set it to use 'traditional sql' to give you warnings on that if you're running mysql5+) mysql is awful about that. Aside from that, I think the issue is more of a problem with Unicode -- unicode doesn't store every charcter with the same required space ( http://en.wikipedia.org/wiki/UTF-8 ). The ascii strings aren't re-encoded for legacy support -- so if you wanted a UnicodeCol of 100 characters , you'd really have to set the schema to be ( 100 x Max Storage Requirement for UTF Version ) Most probably an useless reply but I've just found this link today regarding python and unicode: http://dalchemy.com/opensource/unicodedoc/ Ciao Michele --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
