On Tue, Jan 6, 2009 at 6:26 AM, vArDo <mateusz.bilin...@gmail.com> wrote: > I'd like to know what are priorities for these projects. Are example > apps (blog, cms) important or maybe CRUD is the most-wanted > subproject? >
> [3] http://wiki.pylonshq.com/display/pylonsprojects/Home I deleted two of the WebHelpers-related projects that are already done. Ben could use some help finishing the Pylons documentation for 0.9.7, although that's too short a timeframe for the Summer of Code. Pylons' dependencies need to be ported to Python 3 so that Pylons can be ported. As for wiki/blog/CMS-related projects and CRUD projects, there have been several started over the past year that haven't made it onto the project pages. I don't know what exactly they are or what state they're in, so you'll have to ask here (and hopefully update the project pages :). === Wiki/blog/CMS - Plone can supposedly be embedded in a Pylons app and vice-versa, and I hear most of Plone has now been ported to Zope 3 (so is cleaner code). Maybe better integration or documentation would help, possibly via Repoze.*. - Three Pylons CMS projects were started but last time i looked they were variously abandoned, undocumented, or didn't really seem like CMS's. - The Pylons Book has, or had, code for a basic CMS. I haven't read the final version of the book so I'm not sure if it made it, but James has the code. - Some sites need specifically wiki features, a la MoinMoin. I've heard MoinMoin is difficult to set up in a WSGI environment and integrate into a larger site, so perhaps there's something there to work on. - There has long been a desire for a Pylons-powered wiki to replace Confluence as Python's wiki, but MoinMoin was missing some features and is considered difficult to embed in WSGI applications, and the Pylons developers didn't want to distract themselves from documentation writing and framework building. Maybe that could be started. We'd have to start by making a list of requirements. - Some sites need a ticketing system a la Trac or Roundup or [something new this year?], so there's another integration potential. === CRUD - TurboGears is building something along those lines. - FormAlchemy is doing something cruddish (cruddy). I almost considered integrating it with WebHelpers and @validate, except it's incompatible with non-SQL databases. === Non-relational databases. This is more of a documentation issue than a technical issue. Non-relational databases like CouchDB, Hypertable, and App Engine's Datastore provide some unique opportunities compared to SQLAlchemy, but also provide some unique disadvantages that have to be worked around or done another way. There are also products that attempt to reconcile the two database systems or provide a common front end bridging SQL and non-SQL databases. These are not often used in Pylons programs because they are so new and unknown. In some cases that may be because a SQL database *is* adequate and better for the job, but in other cases it's because people don't understand the alternatives. So some howtos and pattern code for these products would be helpful, as well as comparisions between them and SQL and object databases (ZODB, Durus) for various tasks. === Authentication/authorization This has been is another hot issue. Here there are multiple complete libraries (AuthKit and Repoze.who). It has been suggested that one of them be blessed as Pylons standard, but we have never made a comprehensive assessment of what Pylons needs in a standard auth system (should be somewhat minimalist yet flexible, a la FormEncode/WebHelpers) and how the two meet it, or whether repoze.who has too many Zopish dependencies. Some TurboGears developers are also creating Repoze.what as their standard authorization system, and perhaps it could be adopted by Pylons at some point. So either work on Repoze.what itself or on documenting it for Pylons would be helpful. === ToscaWidgets ToscaWidgets is still pretty undocumented for Pylons. Last time I checked, Alberto's tutorial was the only one up to date but it only covered simple usage, not building custom widgets. That's the main reason it's not used much in Pylons applications. it sounded like TW was making some good advances, dropping C dependencies and that rule library, and adding Mako templates so that Genshi wasn't required. That should all have made it more Pylons compatible by now. -- Mike Orr <sluggos...@gmail.com> --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en -~----------~----~----~----~------~----~------~--~---
