New Python.org website ?

G

Guest

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Tim said:
[...] Thanks for installing pyramid! Can
you give me any feedback on what parts of the install process were
painful..
Click to expand...

There was nothing particularly painful.

I tried to avoid having to install everything manually and to use the
packages that my system (Ubuntu 5.10) provides where possible. In the
end, this were only the Zope Interfaces and Twisted. Everything else was
either in too old versions in Ubuntu or not packaged.

- -- Gerhard
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD06YldIO4ozGCH14RAkJzAJ9SXjcDRnUIdkAVQIGCWiJyWKZHVwCgpsj6
irzdJP0rSR+IE81f5cAGkTU=
=u3i0
-----END PGP SIGNATURE-----
 
?

=?ISO-8859-1?Q?Gerhard_H=E4ring?=

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


I've also done some experimentation this weekend, and my solution would
be based on MoinMoin and KID.

Fredrik said:
[...] and a more
extensive (but still rough) translation is available here:

http://effbot.org/pydotorg/

the sample site contains ~600 pages. each page has been automatically
translated from python.org sources to moinmoin markup, and then stored
in a moinmoin 1.5 instance. a separate component has then extracted the
pages from moinmoin, and converted them XHTML fragments for rendering.
Click to expand...

Great.

This sounds a lot like the ugly hacked script I produced that would dump
all MoinMoin contents to XHTML in one directory, and the raw MoinMoin
sources to another directory:

http://ghaering.de/pydotorg/dumpwiki.py
(the sample pages on that page are basically the XHTML fragments as is;
the final site generator should of course use a suitable templating system
and nice CSS for the final product). [...]
Click to expand...

The other part of my experiment was a stupid build system that
recursively looks for KID files in a directory tree and renders them to
HTML.

My idea is that for each KID file there would be a corresponding
content.xml file that would come from the MoinMoin dump-to-XHTML (*).

As for the navigation, my solution would look like this:

- each KID file uses a master KID template
- the "normal" KID files do look about like this:

<html py:extends="'templates/layout.kid'"
xmlns:py="http://purl.org/kid/ns#">

<head>
<title>The page title</title>
</head>

<body>

<div py:replace="document('src/content.xml')" />

</body>
</html>

i. e. all they do is define the page title, and include the content
XML file created from MoinMoin.

- the "make-like" generator script will give each template its name as
a parameter, so that the template (and in particular the master
template) know what the current path is. Using this information, it can
render the left-side navigation bar appropriately.

- If there really is a need to, additional processing instructions can
be put as comments in MoinMoin at the top of a wiki page, like:

## RENDER hideNav("/dev"); expandNav("/about")

As we also have access to the dumped raw MoinMoin sources, we could
parse these comments and handle them while rendering the KID templates.

IMO this system would be flexible enough to do all that the current one
can do, and integrate nicely with MoinMoin.

It would be not *ALL* dynamic via MoinMoin, but at least the contents
can be editied through a Wiki. Site structure would still be editied via
the filesystem.

What do you think of an approach like this?

- -- Gerhard

(*) MoinMoin dumps do not always produce valid XHTML, so eventually I
still need a cleanup step.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFD062EdIO4ozGCH14RAhoRAJ9pumD9LpKRohngbacHXSaub+zYtQCgmyHd
m9cCT2pXdRRIX0Qg+qdgMDM=
=hljf
-----END PGP SIGNATURE-----
 
T

Tim Parkin

Gerhard said:
The other part of my experiment was a stupid build system that
recursively looks for KID files in a directory tree and renders them to
HTML.

My idea is that for each KID file there would be a corresponding
content.xml file that would come from the MoinMoin dump-to-XHTML (*).

As for the navigation, my solution would look like this:

- each KID file uses a master KID template
- the "normal" KID files do look about like this:

<html py:extends="'templates/layout.kid'"
xmlns:py="http://purl.org/kid/ns#">

<head>
<title>The page title</title>
</head>

<body>

<div py:replace="document('src/content.xml')" />

</body>
</html>

i. e. all they do is define the page title, and include the content
XML file created from MoinMoin.

- the "make-like" generator script will give each template its name as
a parameter, so that the template (and in particular the master
template) know what the current path is. Using this information, it can
render the left-side navigation bar appropriately.

- If there really is a need to, additional processing instructions can
be put as comments in MoinMoin at the top of a wiki page, like:

## RENDER hideNav("/dev"); expandNav("/about")

As we also have access to the dumped raw MoinMoin sources, we could
parse these comments and handle them while rendering the KID templates.

IMO this system would be flexible enough to do all that the current one
can do, and integrate nicely with MoinMoin.

It would be not *ALL* dynamic via MoinMoin, but at least the contents
can be editied through a Wiki. Site structure would still be editied via
the filesystem.

What do you think of an approach like this?

-- Gerhard

(*) MoinMoin dumps do not always produce valid XHTML, so eventually I
still need a cleanup step.
Click to expand...

It sounds very similar to what we have already built!! What we have also
parses yaml files, rest files, inline rest content, has special
renderers for navigation and breadcrumbs and handles cacheing of built
data to speed generation. It also keeps the format of all original
documents intact and can handle the differences in encodings that exist
in the current content. It will also include static html files (such as
some of the summaries and a lot of the pycon content), data structures
(the sigs and some other sections of the site), custom functionality
needed to remove emails from certain documents and the render some
custom data elements (peps) and the ability to add custom sidebar
elements. It also retains the ability to render complex page layouts on
the occasion they are needed. There is also a module being added that
will parse the current docs and rerender them within the site framework
adding a hierarchical navigation system.

With regards to integrating wiki content, it also has a beta directive
to include content from a wiki so there could be a good overlap here
between keeping the data stored in text files in subversion (a
requirement) and using moinmoin to help manage the content.

The goal will be to add a wiki-like rest editor that could also handle
the non-wiki/non-rest like content (such as sigs, peps, mirrors,
donations, jobs, members, psf meeting minutes, etc).

Tim
 
F

Fredrik Lundh

Tim said:
It sounds very similar to what we have already built!! What we have also
parses yaml files, rest files, inline rest content, has special
renderers for navigation and breadcrumbs and handles cacheing of built
data to speed generation.
Click to expand...

except that it isn't: you're talking about a modernized version of
the current HT2HTML/make system, we're talking about a purely
wiki-driven system.

if we add django to the mix, the pages shown to the user won't
even exist on disk.

</F>
 
P

Paul Boddie

Fredrik said:
for the curious, I've found a few more spare 15-minute slots, and a more
extensive (but still rough) translation is available here:

http://effbot.org/pydotorg/
Click to expand...

I've also been messing around with different content sources, and the
results can be viewed here:

http://www.boddie.org.uk/python/python-site/index.html

The infrastructure isn't that impressive: I just take some RSS feeds
and XBEL bookmarks files, add some results from parsing the
PythonEvents page on the Wiki, put them into an XML document, and then
render the different pages using some XSLT-based templates. Not exactly
a top-end portal solution, but does it have to be?

Of course, the above works for simple portal-like overview pages, but
for the real textual content you'd have to make use of more
sophisticated sources than feeds and bookmarks. Arguably, organising,
retrieving and presenting such content is the hard part of a project
like this, and it would be interesting to see how the Wiki could be
used for such purposes whilst maintaining a certain level of coherency
lacking in parts of the current site (try finding definitive copyright
and licence information) and in the Wiki itself (try finding anything
very quickly without doing a search).

Paul

P.S. The events make use of the hCalendar microformat, meaning that you
can export them from the page given the appropriate tools.
 
T

Tim Parkin

Fredrik said:
Tim Parkin wrote:




except that it isn't: you're talking about a modernized version of
the current HT2HTML/make system, we're talking about a purely
wiki-driven system.
Click to expand...
Fred, It's not a updated ht2html, just as it's not a web framework and
it's also not a database backed content management system. It is what it
is, text files with content on disk that get delivered as flat css/xhtml
files (via a simple xml based templating system) and stored in a
subversion repository.

The way people edit content can be via any tool capable of editing text
files. That includes, but is not limited to, textareas (via a wiki if
you will) or gedit or vim or notepad.

I would like your help, if you are willing, to suggest ways of parsing
wiki markup into valid, semantic html that can be used on the website. I
would also like you help in integrating the documentation into the
website. If you want to help, send me an email, if you don't want to
help but would like to continue the discussion, I'm happy to do so in
private and then we can both come back and post our conclusions on the
mailing list.

Thanks

Tim Parkin
 
A

Aahz

Agreed. The main page should be like a slick book cover. It should grab
you and leave you wanting more. I think the beta page does that pretty
well.

[...]

Of course, I'm a minimalist. I understand techy types want the details,
but I don't doubt the details will be no more than two clicks away.
Click to expand...

Which sort of gets to the heart of the argument: who is www.python.org
for?

I suggested one alternative a long time ago, but we never had the
bandwidth to do the necessary refactor:

The idea is that we make www.python.org even more minimal than the
current beta.python.org; it becomes a portal similar in simplicity to
google.com (with a bit more explanation). It would lead off to
subdomains such as business.python.org, tech.python.org, help.python.org,
and so on. That would make it easy for people to bookmark a specific
section that was appropriate for their needs.

If we can't do that, I think we should overall slant the focus toward the
primary users of python.org: people wanting to learn Python and people
doing real work in using Python. (I have mostly been keeping my mouth
shut during this discussion because I'm one of the (e-mail address removed)
team and therefore should be contibuting labor to make this happen -- but
I haven't had the bandwidth.)
 
A

Aahz

for the curious, I've found a few more spare 15-minute slots, and a more
extensive (but still rough) translation is available here:

http://effbot.org/pydotorg/

the sample site contains ~600 pages. each page has been automatically
translated from python.org sources to moinmoin markup, and then stored
in a moinmoin 1.5 instance. a separate component has then extracted the
pages from moinmoin, and converted them XHTML fragments for rendering.
Click to expand...

That looks pretty good. The most serious bug I've found so far in your
conversion is the missing form for grabbing SF bugs/patches on
http://www.python.org/dev/
just after "Links for Developers"

I'm curious what you plan to do for handling sidebar links, especially
context-sensitve ones that change as you switch between sections of the
site.
 
T

Terry Hancock

On 22 Jan 2006 14:18:18 -0800
The idea is that we make www.python.org even more minimal
than the current beta.python.org; it becomes a portal
similar in simplicity to google.com (with a bit more
explanation). It would lead off to subdomains such as
business.python.org, tech.python.org, help.python.org, and
so on. That would make it easy for people to bookmark a
specific section that was appropriate for their needs.
Click to expand...

This is a good idea, particularly if the links are domains
as you give in your example, and thus not treated like "deep
links" (which too often get broken).

The truth is, the comment about being offended by scrollbars
made me want to vomit! There are few things more annoying
to me than web sites that are designed like Powerpoint
presentations. My preference is to condense information
onto fewer pages, with more complete information. My
expectation of web pages is that they are more like
"documents" than like "slides".

This is particularly relevant if you are on a slow or
high-latency web connection (dialup or satellite,
respectively).

For me, having the document in my browser puts *me* in
control of viewing it, instead of making me click repeatedly
through someone else's "clever" idea of what I should read.

*I* don't want a "slick brochure" for Python as the website.

For all the commercial value in Python (and there is plenty,
I am sure), it's not Java, and I don't want it to be. I'm
cool with suits loving it too, but I don't want to have to
put on a suit to play. Python is an absolutely top-notch
free software language for free software developers, not
least of which are the amateurs, who program for love, not
money.

I hesitate to express this opinion, because I don't want to
seem intolerant (and I'm going to use whatever site there
is), but if the suits can get their own place and leave me
alone, I'm for that. ;-)

For me, the most important function of the python.org site
is as a quick-reference to deeper documentation that I
actually need in the process of writing Python code.

I don't really know if I'm the "market" for this site. I'm
already sold on Python, after all, I just want something
useful that I can use to stay up-to-date, and to find other
Python resources if they move, get created, or if I just
lose track of the URLs.
 
B

Bryan

Aahz said:
The idea is that we make www.python.org even more minimal than the
current beta.python.org; it becomes a portal similar in simplicity to
google.com (with a bit more explanation). It would lead off to
subdomains such as business.python.org, tech.python.org, help.python.org,
and so on. That would make it easy for people to bookmark a specific
section that was appropriate for their needs.
Click to expand...

+1 IMO, this is the best suggestion i've heard yet. it seems like such a
simple, clean, minimalist yet fully functional solution. and it seems to
elegantly solve the suits vs developer issue. for those who like fancy images
on the home page, you could now have an image that clearly links to each
subdomain. you could even have a search on the home page that searches all the
python subdomains.

bryan
 
R

Roy Smith

Terry Hancock said:
For all the commercial value in Python (and there is plenty,
I am sure), it's not Java, and I don't want it to be. I'm
cool with suits loving it too, but I don't want to have to
put on a suit to play. Python is an absolutely top-notch
free software language for free software developers, not
least of which are the amateurs, who program for love, not
money.
Click to expand...

I didn't have anything to do with this prototype (in fact, I didn't even
know it was being built until it was announced here recently), but I was
involved with some of the early discussions 3-4 years back about how to
promote Python within the corporate world.

For the most part, I agree with Terry; I want a site that gives me the info
I need without any fluff getting in the way. But, at the same time, I
realize that there is a need for marketing to suits.

I've been working with Python for something like 8 years (and, depending on
how you count, 3 or 4 employers). I've seen how difficult it is to get it
adopted in the corporate world. Like it or not, suits run the business
world, and they make the business decisions. It's one thing for me to
decide to write something in Python, but to actually get something
integrated into the build system, get the QA guys on board, get legal to
endorse its use, etc, involves getting a lot of suits involved. That's
life in the corporate world.

I may think Java sucks, and you may think Java sucks, but like it or not,
it's accepted in the corporate world. If you want to get paid to write
Python code, it's in your best interests to get Python accepted by the
suits the same way Java is now. If that means www.python.org looks like
something that came out of a corporate PR department, that's a pretty small
price to pay.
 
T

Tim Parkin

Terry said:
On 22 Jan 2006 14:18:18 -0800
*I* don't want a "slick brochure" for Python as the website.

For all the commercial value in Python (and there is plenty,
I am sure), it's not Java, and I don't want it to be. I'm
cool with suits loving it too, but I don't want to have to
put on a suit to play. Python is an absolutely top-notch
free software language for free software developers, not
least of which are the amateurs, who program for love, not
money.

I hesitate to express this opinion, because I don't want to
seem intolerant (and I'm going to use whatever site there
is), but if the suits can get their own place and leave me
alone, I'm for that. ;-)
Click to expand...
Cool!... I think thats exactly what we are after also. Only the home
page plus a handful of interior pages (in the about section) will be
targeted at businessmesn, developers and users. The rest of the site
will stay pretty much untouched (albeit cleaning up the html, ensuring
accessibility also adding consistent navigation to aid usability)

For me, the most important function of the python.org site
is as a quick-reference to deeper documentation that I
actually need in the process of writing Python code.
Click to expand...
All of these functions will still be in place.
I don't really know if I'm the "market" for this site. I'm
already sold on Python, after all, I just want something
useful that I can use to stay up-to-date, and to find other
Python resources if they move, get created, or if I just
lose track of the URLs.
Click to expand...
you shouldn't have a problem at all then. Developers are the primary
marketing for the site. The home page is the only one that needs to
server multiple purposes and we're trying to balance those multiple
purposes between developers who come to the python site for the first
time and business people who come to python for the first time. The
homepage isn't very often used by people who are already developing or
using python, apart from to view news and to use the navigation to find
deeper content.

What I'd like is to add a 'developer homepage' that includes lots of rss
feeds from python related sites, cheeseshop announcements, etc, etc.
Then the majority of developers can bookmark a really useful page.

Tim
 
M

Magnus Lycka

Roy said:
For the most part, I agree with Terry; I want a site that gives me the info
I need without any fluff getting in the way. But, at the same time, I
realize that there is a need for marketing to suits.
Click to expand...

I'll leave layout to others, but content-wise, I don't think this
is very difficult. A "Python is"-blurb with current buzzwords, (I
guess that could be autogenerated by some bot that extracts buzz-
words from the net ;) a few quotes (we have that) and links to
success stories. Both to http://www.pythonology.org/success and
to O'Reilly's both publications:
http://python.oreilly.com/news/python_success_stories.pdf
and http://python.oreilly.com/news/PythonSS.pdf
Adorn the O'Reilly links with images depicting the covers
of those booklets. (I'm sure it's fairly simple to extract
the covers from the PDF's to .png files.)

In general, I think it's a good idea to avoid producing content
that's already out there. Use the resources on the internet.
Sure, it means that we're not quite in control, but I'm sure it's
much less work to maintain some links than to create a lot of
content and keep that up-to-date. It also adds credibility to
show that we have such a wide support from third parties such as
the publishing houses and companies like Google etc.

I'm pretty sure that a lot of what's in the web site today could
be in the wiki, such as the topic guides and SIG pages.

For documentation, I'd put a prominent link to Amazon's page for
"Books > Subjects > Computers & Internet > Programming > Languages &
Tools > Python" besides the standard documentation and a wiki page
were the community can maintain links to on-line tutorials etc.
 
S

Sibylle Koczian

Tony said:
Perhaps you're not aware of this, but the 'plus' shape existed before
Christianity, too.

=Tony.Meyer
Click to expand...

And the Python logo _is_ a plus sign and _not_ a christian cross. Try
crucifying anybody on it.
 
A

A.M. Kuchling

For me, the most important function of the python.org site
is as a quick-reference to deeper documentation that I
actually need in the process of writing Python code.
Click to expand...

docs.python.org is probably the site most useful to you, then.

--amk
 
F

Fredrik Lundh

Aahz said:
That looks pretty good. The most serious bug I've found so far in your
conversion is the missing form for grabbing SF bugs/patches on
http://www.python.org/dev/
just after "Links for Developers"
Click to expand...

forms and tables are not handled well, and there are lots of minor issues
with the current html->moin converter (it's a 2x15-minute hack, after all).
I'm curious what you plan to do for handling sidebar links, especially
context-sensitve ones that change as you switch between sections of the
site.
Click to expand...

I think I mentioned this in an earlier post; simply adding a special SideBar
link list at the top of a page should be good enough

SideBar: <side bar title>
* [link title]
* [link title]
* [link title]

<rest of page>

</F>
 
F

Fredrik Lundh

Gerhard said:
Great.

This sounds a lot like the ugly hacked script I produced that would dump
all MoinMoin contents to XHTML in one directory, and the raw MoinMoin
sources to another directory:

http://ghaering.de/pydotorg/dumpwiki.py
Click to expand...

that's quite similar to what I've been using, with the exception that I'm pulling
the text from a moinmoin server, and cleaning up the resulting HTML (which is
wikified, and quite horrible ;-).
The other part of my experiment was a stupid build system that
recursively looks for KID files in a directory tree and renders them to
HTML.

What do you think of an approach like this?
Click to expand...

makes perfect sense, in itself (but I think the choice of templating system can
wait until we've sorted out the CMS and rendering side of things). let's get the
content in good shape first...

</F>
 
A

Aahz

forms and tables are not handled well, and there are lots of minor issues
with the current html->moin converter (it's a 2x15-minute hack, after all).
Click to expand...

That's fine, just wanted to make sure it wasn't getting lost in the
noise.
I'm curious what you plan to do for handling sidebar links, especially
context-sensitve ones that change as you switch between sections of the
site.
Click to expand...

I think I mentioned this in an earlier post; simply adding a special SideBar
link list at the top of a page should be good enough

SideBar: <side bar title>
* [link title]
* [link title]
* [link title]

<rest of page>
Click to expand...

Hrm. So you're suggesting that each page have a manually-created
sidebar? One thing I do like about the current (and currently planned
future) setup is that it's easy to create a custom sidebar for a section
of the website. (E.g. all the dev pages have the same sidebar.)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

A website that I couldn't make a screenshot of it nor save any page from. 1
Coding Problem/Challenge website that limits your resource usage 2
First website practice project advisement 4
How to add augmented reality content to a website? 3
[email protected] 0
My New project 1
New python.org site 14
I need help making an html website 2

Members online

No members online now.
Total: 23 (members: 0, guests: 23)
Robots: 147

Forum statistics

Threads
473,776
Messages
2,569,603
Members
45,187
Latest member
RosaDemko

Latest Threads

Top