Hi Jorge,
If I've got right what you are trying to do, I think you can do
something like this:
on your master.kid
body py:match=item.tag=='{http://www.w3.org/1999/xhtml}body'
py:attrs=func
If you put it inside the template that extends master.kid it wouldn't
work, that's something to look at
David Bernard wrote:
About your suggestion of using a Form's method :
* to do this errors should be part of the Form'state,
* in my case I share the Form instance between every request, so
interference could append if two users use simultanously the form.
You are right, indeed. :-)
Sorry.
william wrote:
Does this is implementable into CP2.1
AFAIK, such flexible URL would available in CP2.2.
I think Routes provides the maximum flexibility one could ever need and
it seems that it will be easily integrable with CherryPy 2.2:
Michele Cella wrote:
I'm unable to make a choice between 1 and 2, definitely not the third
option.
Ok, the first seems the best.
If I read the second it seems like I'm going to edit (or show) 10
articles not the article number 10.
So +1 for the first.
Ciao
Michele
Well, I've found another opinion (and some comments) regarding 1) vs 2)
from the Rails side:
http://tech.rufy.com/entry/91
(notice the above url :D)
Ciao
Michele
Hi (and welcome) runge,
IMHO the solution implemented by Kevin for TG is more powerful,
flexible and makes full use of Kid (the templating language).
Moreover TG widgets are not limited to the form handling problem (but
probably for 0.9 and 1.0 it will be so), take a look here for an
example:
Hi Jared,
Great work! :-)
Only one small thing, I think you should also include a section for the
cool FeedObject implemented by Elvelind.
There is a small tutorial here:
http://trac.turbogears.org/turbogears/wiki/FeedObject
Be aware that he was working on some (nice) api improvements but I'm
I think that it should also work if you change your py:match expression
to be like this:
py:match=item.tag == '{http://www.w3.org/1999/xhtml}greeting'
Ciao
Michele
Michele Cella wrote:
widget name=optionsel template=my_designer_option_selector.kid /
By the way here I'm totally on crack since for compound widgets (like
a form) you will not be able to define a template for their subwidgets,
and thinking even more about this is better to leave the template
Kevin Dangoor wrote:
On 11/30/05, Michele Cella [EMAIL PROTECTED] wrote:
Michele Cella wrote:
widget name=optionsel template=my_designer_option_selector.kid /
By the way here I'm totally on crack since for compound widgets (like
a form) you will not be able to define a template
Kevin Dangoor wrote:
On 11/28/05, Michele Cella [EMAIL PROTECTED] wrote:
Kevin, regarding this what do you think about my proposal of hiding the
widget insert mechanism behind a custom tag?
widget name=datepicker [attributes for others options] /
It looks nice, but widgets are designed
Kevin Dangoor wrote:
It's an interesting point, though. It may be possible, with a little
API smoothing, to make *all widgets* usable in places where you'd
currently have to use a form. If that sounds good to people, it's
worth opening a ticket on... opinions?
Last week I've made a small
Elvelind Grandin wrote:
I belive there are already somebody doing nighly eggs, but I can seem
to find the link now.
If not I can certainly do it.
I think the link is this:
http://www.opensource4you.com/nightly_tarballs.shtml
Ciao
Michele
Kevin Dangoor wrote:
Here's the good bit: I *think* that a bit of code shuffling with
possibly minor API tweaks will eliminate the need for a distinction.
If a widget has useful application in a form, you can use it that way.
If it's useful outside a form, you can use it that way. Seems
Hi Wavy,
note that at some point (before 0.9) the master template will be
cleaned up and these thing will be moved to the sitetemplate:
http://trac.turbogears.org/turbogears/ticket/107
Ciao
Michele
Wavy Davy wrote:
Heya all
Due to the new widget code in development, the quickstart
.
tg|has_patch
tg|patch_tested
tg|to_commit
etc.
That way custom reports can be set up with ease searching simply on
the keywords. These keywords are just examples, and could/should be
changed to fit our needs.
Does this sound like a good idea?
Lee
On 21/11/05, Michele Cella
Hi Jorge,
This is actually a problem, and sometimes ago there was a discussion
about this:
http://tinyurl.com/cd525
I've also made a wiki page to collect feedback like your:
http://trac.turbogears.org/turbogears/wiki/WidgetsBrainStorming
As I noted on the wiki page the ability to give a
Hi list,
I've just created a wiki page to discuss about TG widgets, possible
improvements, suggestions and solution to actual problems (for example
ticket #106).
You can find it here:
http://trac.turbogears.org/turbogears/wiki/WidgetsBrainStorming
Please take a look at this and give any
Michael Schneider wrote:
Hello All,
Hi Michael,
I spend a couple of days investigating the use of STAN in turbogears.
Here is a very short writup on these efforts.
Is STAN useful to Turbogears?
Thanks,
Mike
...
class Root(controllers.Root):
[EMAIL
Hi Michael,
As I have already pointed out I'm not a Stan/Nevow user (this means I'm
not aware of the many thing they can do), nor a big web programmer
(only small projects actually, I'm still studying :-( ) and also not a
big programmer also, so please take my words with this in mind.
I see your
Jared Kuolt wrote:
I think you actually have to be logged in as a subversion user to
use the assign to me.
I've just been doing assign to and put in my name. Though I'm not
sure what's the best practice here...
I think you are doing the right thing putting your name in the assign
to filed.
Patrick Lewis wrote:
I went ahead and submitted a patch for the issue. I think the patch
contains a general fix, but specifics as to actual namespaces and
tablenames may need to be tweaked.
Hi Patrick,
I added a small comment to the ticket with a link to another possible
solution posted on
Sean CazzellCazzell wrote:
There has been a lot of interest on the list of having a way to
automatically wrap a request in a transaction. The most obvious way to
do this is to add it into expose. Michele has done a great job putting
together the relevant information (with suggestions
Kevin Dangoor wrote:
On 11/12/05, william [EMAIL PROTECTED] wrote:
I think that the most important point is that the pages can be updated
by every TG contributors. That's the basic idea of a wiki. Isn't it ?
How many Trac users expect to have a RST file ?
Does Kevin prefer strandard
Awesome work, as always.
Ronald Jaramillo wrote:
Hi,
This may be relevant for those of you planning to join the chat
tomorrow.
I'm not sure if we will be talking about Toolbox, but in case we are,
I made a couple of mock-up screens.
Check them out here:
Elvelind Grandin wrote:
With version 0.9 turbogears will support easy generating of rss/atom feeds.
There still some stuff to add like knowledge of wich elements are valid etc.
But here is a quicklook at how it looks like now.
http://trac.turbogears.org/turbogears/wiki/FeedObject#preview
Leonardo wrote:
Hi Kevin..
where I will have that to look for?
http://trac.turbogears.org/turbogears/changeset/167
how to make?
if you are running a svn checkout of TurboGears (I think so since you
are using the Identity Code) you can update it to get the fix in.
Ciao
Michele
Cool! that's very nice and original! :-)
I added it to the wiki page.
Ciao
Michele
Ronald Jaramillo wrote:
Hi,
Kevin had a good idea for a tag line to the small logo.
Instead of 'Powered by TurboGears', he suggested 'TurboGears - Under
The Hood'.
I checked in a revised logo to the
Kevin Dangoor wrote:
On 11/10/05, scmikes [EMAIL PROTECTED] wrote:
Does that mean the turbogears will become 2.3 centric, or 2.3 backwards
compatable?
Would decorators be dropped from the demos?
@email
def response():
paragraphs = set([Good question. *I* run Python 2.4 and have no
Steve Bergman wrote:
As a user, I'm quite happy enough about how the lists are set up now. I
enjoy seeing the development discussions. And as TG's api is undergoing
rapid evolution, I think the closest possible association between users
and developers is likely beneficial.
I agree, the
p wrote:
4. Finally, why the heck is everything stuffed into an init file?
ew. :-)
Agreed.
I'm new to python (so that's probably the right thing) but the first
time I looked at TG source code I wondered why __init__.py files
contains so many thing instead of exposing only the package
william wrote:
FAQ:
Side to the good Turbogears documentation, I propose you to use the
Turbogears wiki to collect the FAQ (and their answers) that you think
relevant.
Great work william.
Two days ago I tried to make the FAQ page more appealing and easy to
mantain, like this one:
Kevin Dangoor wrote:
On 11/9/05, Michele Cella [EMAIL PROTECTED] wrote:
Two days ago I tried to make the FAQ page more appealing and easy to
mantain, like this one:
http://projects.edgewall.com/trac/wiki/TracFaq
Unfortunately TurboGears trac can't find the docutils package
Elvelind Grandin wrote:
but if it's sub-apps, perhaps a feedobject( ;) ) that you add to
Just wondering, are you working on a feedobject? :-)
Ciao
Michele
it
will be far better that what I would have been able to do.
Ciao
Michele
On 11/9/05, Michele Cella [EMAIL PROTECTED] wrote:
Elvelind Grandin wrote:
but if it's sub-apps, perhaps a feedobject( ;) ) that you add to
Just wondering, are you working on a feedobject? :-)
Ciao
Michele
are all components of TG)
Let me know what you (and the others) think about it.
william wrote:
Michele Cella wrote:
Great work william.
Thanks. Always nice to see that it's appreciated.
For me, it's easier if the info reside only at 1 place.
Probably I'm squared but I don't get your
Hi william,
Kevin is busy working on implementing his ideas, you can find the
source code of what he has done so far here:
http://trac.turbogears.org/turbogears/browser/trunk/turbogears/forms/
and a relevant post here:
Kevin Dangoor wrote:
Hi Michele,
It took me a bit longer to get back to this one.
No problem. ;-)
The default templates need to be stored somewhere, of course. Since
these initial ones were pretty small, I decided to just stick them in
there with the code. They remain easily
Hi Sean,
Sean Cazzell wrote:
Kevin, adding back positional params will be awesome. I know you can
currently use default, but you are going to have to create a separate
class for every exposed method or put some sort of dispatch logic into
your Root.default. I do agree that not having to
Kevin Dangoor wrote:
Hi Michele,
Hi Kevin,
Thanks for taking the time to write this. I know how long it can take
to write something in a non-native language.
Thank you for giving me your attention.
On 11/4/05, Michele Cella [EMAIL PROTECTED] wrote:
I've just found this link to a post
Michele Cella wrote:
widgets.TextField(name, template=myproject.templates.textfield)
This is a feature I didn't notice, and I think that's a quite important
feature, If i got it right you are directly referencing a Kid template,
right?
Now I will not say again see below but I
Kevin Dangoor wrote:
On 10/26/05, Todd Greenwood [EMAIL PROTECTED] wrote:
Great, thanks Kevin. I'll put this in my next tutorial extension.
Somehow this escaped me in the docs. The django has an OR mapping more
like what I was expecting...
Which is?
I'm all for API improvements that
wrote:
Michele Cella wrote:
I've added (hope you don't mind Kevin) your work to this turbogears
wiki page:
http://trac.turbogears.org/turbogears/wiki/SimpleAdminIdeas
I take a look over wiki and proposal about CRUD. And I've got a
question :
Why generate form at runtime, why
I've added (hope you don't mind Kevin) your work to this turbogears
wiki page:
http://trac.turbogears.org/turbogears/wiki/SimpleAdminIdeas
Maybe you should also take a closer look at this discussion:
http://tinyurl.com/9afbk
Ciao
Michele
Ivo van der Wijk wrote:
Hi All,
I've been thinking
. The default tends toward simplicity,
but Python makes the expansion very easy.
Hope this helps,
Krys
Michele Cella wrote:
Hi Kevin,
I follow TG developments since the beginning but unfortunately I
haven't yet got a chance to play with it (hope to get it soon), anyway
I would like to ask
Kevin Dangoor wrote:
On 10/22/05, Catalin Constantin [EMAIL PROTECTED] wrote:
Reading the 20 minutes wiki tutorial, will give you a big impulse in
starting to do some TurboGears.
When you really start and want to do some real usable application with
it, you find out lots of design
501 - 546 of 546 matches
Mail list logo
