WebHelpers future
Mike Orr
need some input on what it should look like. As background, Ben
Bangert wrote WebHelpers for Pylons, based on various Ruby on Rails
helpers. It had a major revision in 2009-2010 (1.0) coinciding with
Pylons 0.9.7, and has had only minor changes since then. I took over
maintenance around that time. WebHelpers is widely used in Pylons
applications, is compatible with Pyramid except for a few
"Pylons-only" helpers, and provides one way to handle forms in Pyramid
(WebHelpers + FormEncode + pyramid_simpleform).
With the jump to 1.0, we revised the existing helpers and dropped some
of Rails' bad ideas and fast-changing Javascript libraries. This
introduced backward incompatibilities, so version 0.6.4 is still
available for old applications.
Since then I've discovered more cruft. WebHelpers was advertised as
framework-neutral but some helpers have subtle dependencies on Pylons.
I've now documented these, but it's still a sore point for me. So I'd
like to make a WebHelpers 2, containing only the widely-used helpers
compatible with Pyramid, and spinning off large helpers to separate
distributions. The new core would be ported to Python 3 (minimum 2.6
or 2.7). Here's my initial thoughts on the disposition of existing
helpers:
- webhelpers.constants :
Port to version 2.
- webhelpers.containers:
Port to version 2.
- webhelpers.date:
Port to version 2.
- webhelpers.feedgenerator:
Spin off to separate distribution. Looking for maintainer for
this. This is copied from django.feedgenerator and is probably behind
the original's version. I updated it once and it required several
patches to remove djangoisms like dependencies and (y, x) instead of
(x, y). Check PyPI to see if there's an existing standalone feed
generator, or consider whether to build a new one, possibly using one
of the XML libraries.
- webhelpers.html.builder:
Port to version 2. Consolidate discrepencies between ``literal()``
and ``markupsafe.Markup``.
- webhelpers.html.converters:
Delete markdown and textilize, which are thin wrappers around
external packages. Port the other helpers (format_paragraphs, nl2br)
to version 2, possibly moving them to another package.
- webhelpers.html.grid:
Spin off. Owned by Ergo, so he'd have to maintain it.
- webhelpers.html.tags:
Port to version 2.
- webhelpers.html.tools:
Do we really need ``auto_link``, ``button_to``, ``js_obfuscate``,
and ``mail_to``? I've never used them. ``strip_tags`` has been
superceded by ``format_paragraphs`` (in converters); the former
remains only for compatibility. The only helper I consider valuable is
``highlight``.
- webhelpers.media:
Port to version 2. (Or spin off; they depend on PIL.)
- webhelpers.mimehelper:
Delete. It depends on WebOb and has Pylons-specific features. Its
generic features don't seem to add much value over the stdlib
mimetypes.
- webhelpers.misc:
Port to version 2. Delete ``all``, ``any``, and ``no``, which are
superceded by Python 2.5.
- webhelpers.number:
Port to version 2.
- webhelpers.paginate:
Spin off. Owned by Christoph Haas, so he'd have first priority for
maintaining it. It has Pylons-specific cruft, and could use a
rethinking of the API.
- webhelpers.text:
Port to version 2. Maybe delete the accent-conversion helpers if
the Unidecode distribution is sufficient. Note that wrap_paragraphs
overlaps with converters.format_paragraphs; consider moving to a
common package.
- webhelpers.util:
Delete. This is a bunch of old miscellaneous stuff, mainly support
code for other helpers. Do something with ``update_params``.
- webhelpers.pylonslib:
Delete. These all depend on Pylons. ``flash`` is superceded by
Pyramid's session.flash.
``grid`` is Plons-specific wrappers for webhelpers.grid. ``minify``
depends on Pylons and has external generic equivalents.
``secure_form`` is superceded by something in Pyramid sesions.
Does anyone have comments on the proposed restructuring, or would like
to help with it, or take over any of the spin-off packages?
The project will include fixing the doc link, and moving the
repository to GitHub.
--
Mike Orr <slugg...@gmail.com>
Marius Gedminas
> Here's my initial thoughts on the disposition of existing
> helpers:
> - webhelpers.html.tools:
> Do we really need ``auto_link``, ``button_to``, ``js_obfuscate``,
> and ``mail_to``? I've never used them.
I think I've found auto_link useful for one project.
Are there better alternatives?
Marius Gedminas
--
Did you know that 7/5 people don't know how to use fractions?
plantian
Mike Orr
> I was just looking at webhelpers' feedgenerator this last week because I was
> trying to generate feeds for my site in RSS and ATOM.
>
> I could spin off the feedgenerator if no one else wants to, there is
> actually a pypi package called feedgenerator already but the homepage link
> is broken and the package has not been updated since 2010. Seems to also be
> django based. What about feedwriter?
>
> Tell me what you think.
I found the author's homepage and a GitHub project dated last month.
I'll write to him and cc you, .
'feedwriter' is OK, although people may wonder why it's not related to
the 'feedreader' package.
> -Ian
Are you the Ian I saw at the Pyramid booth at PyCon?
--
Mike Orr <slugg...@gmail.com>
Ian Wilson
--
Mike Orr <slugg...@gmail.com>
--
You received this message because you are subscribed to the Google Groups "pylons-discuss" group.
To post to this group, send email to pylons-...@googlegroups.com.
To unsubscribe from this group, send email to pylons-discus...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
Alexis Métaireau
I'm the maintainer of the feedgenerator package. Basically, it's the
feedgenerator from django, repackaged so we avoid using all the django
world to just generate feeds.
I don't remember on which version of django this is based, but it is
quite old (like more than 1 year). Updating it to the last django
stable version shouldn't be that hard, and then I can re-release
something on PyPI as well.
The repository is here: http://github.com/ametaireau/feedgenerator and
having these things merged together sounds a great idea.
Alexis