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
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
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
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:
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
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
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
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
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
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:
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:
[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
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.
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
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
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
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
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...
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(
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
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
://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
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
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
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
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
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
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
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
[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
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.
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
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
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
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
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
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
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
[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
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
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
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
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
:-(
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
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:
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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,
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
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
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
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,
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
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:
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
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
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... ;-)
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
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
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
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
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
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
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
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 ;)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
1 - 100 of 546 matches
Mail list logo
