TurboGears 2.2 Beta

[Michael Pedersen]

Well, after working on the package updates last night, I worked on getting a beta release of TG2.2 out.

You won't find it on PyPi, and I have no intention of ever putting it there.

However, you can install it with only slight variation on the normal instructions:

easy_install -i http://tg.gy/beta tg.devtools

All of the packages are upgraded as high as they can be. That means that only Pylons, Chameleon, repoze.who, and transaction are not at the latest possible release.

People, please test this with your code. File tickets. Let us know of problems. We're going to release this as our current stable release soon. Definitely before the end of May, and hopefully at the end of April. Without your feedback, though, we could create problems for you. We don't want that, so please let us know.

Many new packages, many internal code changes to fix many bugs, and many new features, and no support for Python 2.4. This is a major release. Help us get it right.

Thank you.

--
Michael J. Pedersen

My Online Resume: http://www.icelus.org/ -- Google+ http://plus.ly/pedersen

Google Talk: m.ped...@icelus.org -- Twitter: pedersentg

[Carlos Daniel Ruvalcaba Valenzuela]

Great :)

I trowed the templating benchmark at it just for fun and the
performance improvements are starting to show, can't wait for 2.3:

http://blog.blackchairsoft.com/2012/04/11/turbogears-2-2-beta-benchmarking/

While benchmarking it caught my attention that when using Jinja
quickstart template TG will complain that only Genshi and Mako are
supported under TG, which really only means that we need to have
either Genshi or Mako loaded too for other things besides the
application templates (which can be in Jinja with no problems).

That warning got me thinking that maybe I should also load Mako with
Jinja, I'm not really sure if not loading another template system can
hurt other functions such as TW, but I'm under the impression that the
TW integration code sets the TW templates to either Mako or Genshi
depending on what we have loaded.

Any ideas on that?

Regards,
Carlos Daniel Ruvalcaba Valenzuela

[Alessandro Molina]

On Wed, Apr 11, 2012 at 11:13 AM, Carlos Daniel Ruvalcaba Valenzuela
<clsd...@gmail.com> wrote:
>
> That warning got me thinking that maybe I should also load Mako with
> Jinja, I'm not really sure if not loading another template system can
> hurt other functions such as TW, but I'm under the impression that the
> TW integration code sets the TW templates to either Mako or Genshi
> depending on what we have loaded.
>
> Any ideas on that?
>

Thinking of it,
I'm starting to think that we should probably always add the genshi
dependency by default whenever any other tempate engine is used to
quickstart a tg project.
I know that it is something many people might not use and one more
dependency, but I see some reasons to do it anyway:

1) Many extensions like debugbar, admin and so on require Genshi to
work (admin works both with genshi and mako) . So people will have to
install it anyway and having it available from the begin might help
new users to work with TG without issues. As Genshi is already the
default template engine for TG it would make sense to have it as the
always available one.

2) Power Users are perfectly able to delete a line from their
setup.py, while newcomers might not even know what is setup.py and
would get angry if they click on the admin link and see an error
after they just quickstarted the app with the random template engine
one of their friends told them is the best.

3) Having a clear default template engine, even if not perfect, would
make life easier for people that write extensions. Probably not having
a default engine will bring us to the point where every extension is
written with the author favorite engine resulting in projects that use
all template engines: one for each extension they plugged in.

4) Please note that point three has the side effect that whenever the
user plugs an app with a new template engine he will have to write the
master template for that specific template engine, having 4 master
templates to keep in sync is pain for everyone. At least if we make
genshi the default one he will probably have to write only two master
templates.

Just my two cents, but they seem to make a lot of sense to me

[Michael Pedersen]

Ya know, I really hate it when logical arguments get made that I should have thought of. Just can't stand it.

Alessandro is right, we should have a default engine, all the time. Our current default is Genshi, and there's a strong argument to be made for making that the all the time engine.

Anybody have any arguments against it?

--
You received this message because you are subscribed to the Google Groups "TurboGears Trunk" group.
To post to this group, send email to turbogea...@googlegroups.com.
To unsubscribe from this group, send email to turbogears-tru...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/turbogears-trunk?hl=en.

[Alessandro Molina]

While working on it one issue raised due to jinja2 dotted name support.

Currently jinja2 master template is named master.html, what happens
when you try to use the admin extension with genshi?
Well, it crashes as it expects master.html to be a genshi template.

This is caused by the fact that both jinja2 and genshi use .html as
their template extension, so if you have an extension that uses genshi
templates they would try to inherit from master.html expecting it to
be a genshi template.
The same issue doesn't happen with mako as mako templates are clearly
named .mak and so you will have master.html for your jinja2 template
and master.mak for mako and each template would inherit from
master.html or master.mak avoiding clashes.

The only solution to this issue I can think of is to use the .jinja2
extension for jinja2 templates so that they wouldn't collide anymore
with genshi templates, this is what some frameworks do and would solve
the clash making possible to have both genshi and jinja2 templates in
the same project.

As the jinja2 quickstart is still in beta and jinja2 dotted names
support has been a recent addition in 2.1.5 we are on time to change
it, while changing how genshi behaves would probably break many more
projects

I'm open to other proposals as I can see that some users might not
like the idea of having to use .jinja2 as the extension for jinja2
templates as the suggested extension on the jinja2 doc is actually
.html.

[Carlos Daniel Ruvalcaba Valenzuela]

I think is doable to change the default Jinja template extension to
.jinja, pyramid does this and if the quickstart template provides all
the files with this extension I don't think it would represent much
problem, at least on my part there is no problem changing code.

We could check if the template looks like a jinja one and if not just
mark it as genshi and use that loader from then on, but that is way
more complicated than just changing the default extension.

I'm with Alessandro with the extension change with dottedname loader.
Any other jinja user that may voice its opinion against?

I'll try to get a patch ready tonight for this.

[Mengu]

i do not wantt to use .jinja or .jinja2 in my template names, i am
fine with .html. if "master.html"s are conflicting then i will just
change mine to "base.html". :)

On 13 Nisan, 01:59, Carlos Daniel Ruvalcaba Valenzuela

[Alessandro Molina]

On Fri, Apr 13, 2012 at 1:12 PM, Mengu <whal...@gmail.com> wrote:
> i do not wantt to use .jinja or .jinja2 in my template names, i am
> fine with .html. if "master.html"s are conflicting then i will just
> change mine to "base.html". :)
>

The issue is that when you quickstart with jinja, there has to be both
the genshi master.html for plugins and admin and the jinja master
template.

If we want to rename the jinja2 master template file to base.html you
would end having master.html+master.mak when quickstarting with mako
and master.html+base.html when quickstarting with Jinja.

Apart from being the only quickstart where the master file is called
"base" instead of "master" you would even cause more confusion by
having a master.html which is not the master file for your application
and has not clear evidence of not being it (as it ends with .html like
any other jinja template in the directory).

I think that the solution of providing jinja files with the .jinja
extension by default is more viable, and would still allow users to
switch to .html if they like it more and know that it will break many
extensions.

[Mengu]

got it, then i am totaly fine with it :)

On 13 Nisan, 15:00, Alessandro Molina <alessandro.mol...@gmail.com>
wrote:

[Michael Pedersen]

I know I asked for you to post here because I wanted to see if there were other options. It sounds like none of them are really good options, so let's go for it.

Anybody currently using .html for jinja templates, we're sorry. We need to do this change to provide better support for everything.

We also need to make sure that any template engine gets its own extensions. Very much needed.

[Alessandro Molina]

I finally found time to fix the issues with jinja and extensions and
merge the Bootstrap based quickstart.

Some work is being done on TW2 core to solve an issue with the tw2
resources injection when using response streaming.
As soon as this is solved I think we can think of releasing another
2.2 beta release for testing.
Which I hope should be the last beta before the actual release :D

[alind]

I dont know wheter for 2.2beta error/bugs creating a seperate thread is appropriate, so I am posting it in this ongoing thread.
Running a simple quickstart with default values gives this error while accessing the groups in admin .

TypeError: 'SortableColumn' object has no attribute '__getitem__'


View as:   Interactive (full)  |  Text (full)  |  XML (full)

Module ?:47 in <Expression u"XML(tmpl_context.widget(value=value_list, action=mount_point+'.json'))">         view

>>  ${XML(tmpl_context.widget(value=value_list, action=mount_point+'.json'))}

Module sprox.viewbase:104 in __call__         view

>>  return self.__widget__.__call__(*args, **kw)

Module tw.core.base:544 in __call__         view

>>  return self.display(value, **kw)

Module tw.core.base:539 in display         view

>>  kw = self.prepare_dict(value, kw)

Module tw.core.base:582 in prepare_dict         view

>>  self.update_params(d)

Module tw.forms.datagrid:121 in update_params         view

>>  columns = self._parse(fields)

Module tw.forms.datagrid:146 in _parse         view

>>  title, name_or_f = col[:2]

TypeError: 'SortableColumn' object has no attribute '__getitem__'