st support schedule around.
And I think you'll find that even major TurboGears projects will be
relatively easy to port to TG2, which will be supported for even
longer.
--Mark Ramm
TG2 Maintainer
--~--~-~--~~~---~--~~
You received this message because you are su
'll also handle forms differently
(using ToscaWidgets by default).
--Mark Ramm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@googleg
On 9/3/07, skyogre <[EMAIL PROTECTED]> wrote:
>
> Hi.
>
> I liked the turbogears style of templates usage. Decorators are used
> to specify the template and function flash() or exceptions are used to
> display the result of the operation.
>
> Is there a way to get the similar usage in pylons-based
g designed to support alternate backends,
and pylons+toscawidgets should be relitively simple to integrate as a
front end.
--Mark Ramm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To po
up to attend the sprint.
http://docs.turbogears.org/SprintOrganization
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
&quo
le pylons community which has helped us
a lot in making TG2 possible.
--Mark Ramm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
"pylons-discuss" group.
To post to this group, send email to pylons-discuss@
at the moment are the WebOb and
WebTest transitions. I want to make TG2 use WebOb as soon as is
possible, so that we don't start training our users on an API which we
know is going to break soon. ;)
And once you've got WebOb, webtest seems like a nat
and on
the turbogears-trunk mailing list.
There will also be lots of work on Pylons stuff and on other TG2
related projects, and all that stuff is being documented and organized
on the wiki:
http://docs.turbogears.org/SprintOrganization
so, feel free to upate that page with what you are working on.
what
I think you are describing,
I think both aproaches have their place, and Django people will be
very familiar with one approach, rails users the other, so it will be
nice to be able to support both, and if we can innovate a bit on both
sides, and
to stop in and we'll
hang out and hack on TG2/Pylons and other cool WSGI Stuff.
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
blog: www.compoundthinking.com/blog
--~--~-~--~~~---~--~~
You received this message because you are subscribed
> URIs can be UTF-8 with standard URL %-escaping - most browsers will
> decode (and encode) that automatically and show the unicode string in
> the address bar. That is especially important for languages with a
> non-latin character set: without this URLs are horrible for them.
It would be awesom
> Another issue with url_for is the handling of query string parameters
> using keyword arguments. Currently any extra keyword arguments will be
> added to the generated URL as query string, for example:
>
> url_for('/page', arg='val') ==> /page?arg=val
>
> The problem is that you can't use ke
> But what if I don't want to SCRIPT_NAME to be prefixed to the URL
> because it's a link for a different application ? For example if
> pylons app has SCRIPT_NAME of "/pylons" but I want to create a URL for
> "/blog/newposts" which is served an a different blog application (so
> it should not b
> So what about having a 'params' argument but keeping the current
> behavior if 'params' is not set. That would allow backward
> compatibility.
>
> Then if 'params' is set and another argument doesn't correspond to any
> path variable, I guess you'd raise an error.
Well, what we did in tg2 was m
.
> But there are
> other things they seem to handle in an ad-hoc manner that paster
> provides for us, like the application startup file.
Yea, we've got to do more paste integration in general. This is
actually pretty high on our priority list. ;)
--
Mark Ramm
> I couldn't be happier with this news. I've been using TurboGears for
> almost a year now, and had been frustrated with the stagnation in
> development and the myriad of Python web frameworks. I'm glad to see
> two of the top contenders combining, rather than duplicating, their
> efforts.
Pylons
> It's proven trivial to drop SAContext into
> an existing Pylons application (one variable definition and two
> search-and-replaces) so I expect the same will be true for TG
> applications.
Yea, Jonathan has stuff to talk to you about. I think SAContext
could be pretty easily modified to meet
change anything get
transaction overhead that they don't need. So we are looking for the
best way to control transactions on a per controller basis.
--Mark Ramm
--~--~-~--~~~---~--~~
You received this message because you are subscribed to the Google Groups
> > Trac tickets, and see the direction of Pylons development. The group link:
> > http://groups.google.com/group/pylons-devel
>
> Is there any plan on creating a check-ins ML?
>
> Best,
> Edin
>
> >
>
--
Mark Ramm-Christensen
email: mark at compoundthinking dot com
bl
19 matches
Mail list logo