Some self-closing tags are messed up with Genshi template backend of TG2.1
Victor
somehow, the template rendering arguments for genshi might be changed
in TG2.1. I found some tag be self-closed. For example, the genshi
output xhtml like this
<script src="xxx" />
It generated a self-closed tag for script, which is not right, and
leads the browser can't parse the document correctly. Same problem
can be found in permission adding page of a quick-started project with
genshi template. Please reference following screenshot:
http://images.plurk.com/3803264_de72ce7669b1d4079e58db8fdc53d93c.jpg
And the problem was caused by this tag:
<textarea id="description" name="description" class="textarea"
rows="7" cols="50"/>
The textarea should not be self-closed, but somehow, genshi template
engine did that. In TG2.0, I didn't see self-closed script or
textarea like this one in TG2.1. I know how to solve this problem
which genshi, it is easy, switch the output method from "xhtml" to
"html" and it works. But however, I can't find any way to change the
output method of genshi easily with TG2, it seems the only way to do
it is to replace the rendering function? Is that right?
Thanks.
Christoph Zwerschke
> The textarea should not be self-closed, but somehow, genshi template
> engine did that. In TG2.0, I didn't see self-closed script or
> textarea like this one in TG2.1. I know how to solve this problem
> which genshi, it is easy, switch the output method from "xhtml" to
> "html" and it works. But however, I can't find any way to change the
> output method of genshi easily with TG2, it seems the only way to do
> it is to replace the rendering function? Is that right?
I think you can set templating.genshi.method = html in the config.
-- Christoph
Victor
for people who encountered same issue. :)
Christoph Zwerschke
> Thanks, I thought this should be added to document, it would be help
> for people who encountered same issue. :)
I think the same, and had hoped the docs would be brought in shape
*before* the 2.1 release, but the planned doc sprint was cancelled and
nobody cared. Our main developers don't have enough time and our users
don't get involved, contribute or help out. Sadly, that's the state of
Turbogears for some time already and we have to live with it or put our
hope on the merge with Pyramid/Pylons.
-- Christoph
percious
That's about the most negative response I've seen in sometime. Yes, I
could have held up the 2.1 release, I saw this happen back in the days
of 0.8/1.0 TG, and it ultimately hurt the community. I would
encourage anyone seeing a hole in our documentation to please ask how
to contribute and I will be more than willing to send some info their
direction. I did care that the docsprint got cancelled. Yes, I would
like to see more people help with the work that has to be done. Yes,
I plan to support TG for the coming future and I am not looking at a
merger as an absolute solution to our challenges. We have a user-base
that provides 300 unique visitors to our documentation a day. If 1%
helped out on that we'd have more than enough contribution to give the
docs the necessary love. On the other hand, I understand the asking
folks to write documentation is nearly impossible, and I do what I can
with my free time to provide the software updates that are so required
to keep the framework modern.
cheers.
-chris
Christoph Zwerschke
> That's about the most negative response I've seen in sometime. Yes, I
> could have held up the 2.1 release, I saw this happen back in the days
> of 0.8/1.0 TG, and it ultimately hurt the community.
There are many things which hurt the community.
As you also pointed out, we have many users who are not very experienced
yet, and we also want to be attractive to new users. For both of these
people, proper docs are a crucial issue.
Therefore in the last time on tg-trunk we talked a lot about how to
improve the docs before releasing 2.1 so that when it comes out, people
would have a good impression and experience. That's why I worked quite a
bit on a new layout and Sphinx theme and reserved time for the doc
sprint. But it was cancelled, there was no alternate date, and when I
suggested a new doc sprint on the mailing list last week, nobody
answered, so I think it's fair for me to say that "nobody cared". Maybe
my response was negative, but yes, I am disappointed about that.
Well, stuff happens, so we can always change our plans and priorities.
My point is that when plans are altered then this should be discussed or
at least communicated. Therefore we have our mailing lists [2]. I'm not
on IRC all day and honestly had no idea that the 2.1 release was going
to happen last weekend. I was also a bit annoyed because tickets from
the 2.1 final milestone were postponed or closed without comment and
without giving people a chance for feedback before the release.
My wish for the future is that the dates for important releases such as
2.1 are announced beforehand, and we can have a sprint with everybody
who cares where we try to fix the open tickets for the milestone or
decide together which need to be postponed, test everything in different
environments [1], and brush up the docs and release notes.
I hope you don't misunderstand me. You've done a lot, try to push TG 2
forward and we all appreciate that. But there are issues which cannot be
solved by you working even more and harder on TG 2. They can only be
solved by having better communication and release management [2] that
gets all committers and new people involved instead of getting them
accustomed that you're doing everything for them anyway.
-- Christoph
[1] I noticed that some tickets you closed as "worksforme" still did not
work for me, because I had different versions of Paste, Pylons or
repoze.who/what.xyz, webutils etc. Tried to adapt some required
versions, not sure if these changes made it into the release.
[2] http://www.oss-watch.ac.uk/resources/releasemanagement.xml
"When preparing a new release, the release manager needs to determine
its scope and planning. They should involve the committers and users and
seek some level of agreement from them about the scope and planning of
the release. This is because the users will play a very important role
in testing the prospective release and adopting the release once it has
been made final. For this reason, all communication about the scope and
planning of the release should be publicly accessible, for example via a
public mailing list."
Martin Reed
pylons)
and got stuck when looking at the permissions page as I could see it
is broken
in the 2.1 quickstart setup. I worked out that there was an html
rendering problem but could not navigate into repoze to find where
the
error was but found this thread. I was about to give up on
TurboGears ....
Now can one of you kind people tell me where I should set
emplating.genshi.method = html
?
I was gessing myapp/config/app_cfg.py
however I guess I am missing an import as I get:
NameError: name 'templating' is not defined
Your help would be appreciated.
Christoph Zwerschke
> Now can one of you kind people tell me where I should set
> emplating.genshi.method = html ?
>
> I was gessing myapp/config/app_cfg.py
>
> however I guess I am missing an import as I get:
>
> NameError: name 'templating' is not defined
In development/deployment.ini you can write:
templating.genshi.method = html
In app_cfg.py you need to set:
base_config['templating.genshi.method'] = 'html'
-- Christoph
Martin Reed
where the setting should be.
For what it is worth I am finding the TurboGears documentation
very good. In fact it seems better for a new person than the
pylons (yes I know it is based on that). If I will be doing more
development with it then I will look into helping out with
documentation.
percious: it must be frustrating to get both a good release
date and the documentation ready.
Thanks for the very quick help.
percious
Thanks for the feedback. I have replied below to address your issues.
cheers.
-chris
On Nov 22, 4:39 am, Christoph Zwerschke <c...@online.de> wrote:
> Am 22.11.2010 05:49 schrieb percious:
>
> > That's about the most negative response I've seen in sometime. Yes, I
> > could have held up the 2.1 release, I saw this happen back in the days
> > of 0.8/1.0 TG, and it ultimately hurt the community.
>
> There are many things which hurt the community.
>
> As you also pointed out, we have many users who are not very experienced
> yet, and we also want to be attractive to new users. For both of these
> people, proper docs are a crucial issue.
>
> Therefore in the last time on tg-trunk we talked a lot about how to
> improve the docs before releasing 2.1 so that when it comes out, people
> would have a good impression and experience. That's why I worked quite a
> bit on a new layout and Sphinx theme and reserved time for the doc
> sprint. But it was cancelled, there was no alternate date, and when I
> suggested a new doc sprint on the mailing list last week, nobody
> answered, so I think it's fair for me to say that "nobody cared". Maybe
> my response was negative, but yes, I am disappointed about that.
assumed that the work that had gone into making the docs match the
existing website was completed at pycon.
>
> Well, stuff happens, so we can always change our plans and priorities.
> My point is that when plans are altered then this should be discussed or
> at least communicated. Therefore we have our mailing lists [2]. I'm not
> on IRC all day and honestly had no idea that the 2.1 release was going
> to happen last weekend. I was also a bit annoyed because tickets from
> the 2.1 final milestone were postponed or closed without comment and
> without giving people a chance for feedback before the release.
that I had about 40 tickets to go through and I wanted to do this
before the release. The 2.1rc1 release was cut without anyone moving
the open tickets forward, and the milestone was closed leaving a
number of "dead" tickets. I revived them and moved them to the
appropriate places. My involvement with the rc1 release was limited
to actually creating the TG eggs and putting them in the index, I
wanted to make sure we were caught up for the formal release. The
great thing about a ticketing system is that you may open tickets that
may have been closed in error.
>
> My wish for the future is that the dates for important releases such as
> 2.1 are announced beforehand, and we can have a sprint with everybody
> who cares where we try to fix the open tickets for the milestone or
> decide together which need to be postponed, test everything in different
> environments [1], and brush up the docs and release notes.
release deadline is more detrimental to the community than stealth
releasing. My real life schedule has been hectic lately, resulting in
a delayed release candidate and formal release, so I sort of have to
release when there is time. I would be willing to announce a plan
for a release in the TG-trunk ml, or even to you personally if that
makes sense. The other issue is that doing release by committee sets
us up for not releasing at all. I am happy to cut 2.1.x releases
whenever we deem them important. I see at least 10 tickets that we
can solve quickly for the next release, and it is my belief that
people find 2.1.1 releases more appealing in general. Getting 2.1 out
the door sets us up for much better release process in the future.
>
> I hope you don't misunderstand me. You've done a lot, try to push TG 2
> forward and we all appreciate that. But there are issues which cannot be
> solved by you working even more and harder on TG 2. They can only be
> solved by having better communication and release management [2] that
> gets all committers and new people involved instead of getting them
> accustomed that you're doing everything for them anyway.
>
> -- Christoph
>
> [1] I noticed that some tickets you closed as "worksforme" still did not
> work for me, because I had different versions of Paste, Pylons or
> repoze.who/what.xyz, webutils etc. Tried to adapt some required
> versions, not sure if these changes made it into the release.
percious
responses below.
cheers.
-chris
On Nov 23, 3:57 pm, Martin Reed <martinjr...@googlemail.com> wrote:
> Many thanks worked a treat, I should have realised that that was
> where the setting should be.
>
> For what it is worth I am finding the TurboGears documentation
> very good. In fact it seems better for a new person than the
> pylons (yes I know it is based on that). If I will be doing more
> development with it then I will look into helping out with
> documentation.
> percious: it must be frustrating to get both a good release
> date and the documentation ready.
are more hours of work required to "finish" the docs than I have hours
in a day/week/month. Here is a list of todo items in the docs:
http://turbogears.org/2.1/docs/todo.html
and here are the list of items from the ticketing system:
http://trac.turbogears.org/query?status=new&status=assigned&status=reopened&milestone=2.1+docs
I would like to organize another sprint in the _near_ future, but I
also have some work to do to get c5t (a Mongo-TG cms) out now that TG
has a formal release. I would ask that someone would step up to
organize the sprint, and I will do what I can to participate.
cheers.
-chris
Christoph Zwerschke
> Where is this work located? I'd like to get it integrated. I had
> assumed that the work that had gone into making the docs match the
> existing website was completed at pycon.
No, last month we talked about improving the layout here in this group,
and I posted three drafts already:
https://groups.google.com/group/turbogears/browse_thread/thread/65603fd23816dec
The drafts are not online any more, but the last version of my suggested
layout is here:
https://bitbucket.org/cito/tg-docs-21
> My problem with announcing when TG will be released is that missing a
> release deadline is more detrimental to the community than stealth
> releasing.
I think differently - planning and communication is important. Django
does this much better, e.g. at http://www.djangoproject.com/weblog/
You will observe that they also missed a release, and then simply
explained why, and encouraged developers to get their patches in.
> My real life schedule has been hectic lately, resulting in a delayed
> release candidate and formal release, so I sort of have to release
> when there is time.
But this does not work very well if there are also other developers in
the team. Some coordination and advance notice is always necessary in a
community project. Also, the 2.1 release was important so it deserved
some more polish. Yes, we can always have a 2.1.1 release, but most
people try the 2.1 when it comes out and if they have a bad experience
with the docs or installation troubles, may never come back. One sprint
for the polish and the docs would have been appropriate for 2.1. If we
can't manage even that, then this only shows again that it's a good idea
to team up with the Pylons folks.
> The 2.1rc1 release was cut without anyone moving the open tickets
> forward, and the milestone was closed leaving a number of "dead"
> tickets.
Seems the same happened with 2.1 again, there are 21 tickets still open
for 2.1:
http://trac.turbogears.org/query?status=new&status=assigned&status=reopened&milestone=2.1
> I would be willing to announce a plan for a release in the TG-trunk
> ml, or even to you personally if that makes sense.
On the TG-trunk list please. We really should use that list much more to
communicate and get people involved.
-- Christoph