I love your enthusiasm!
On 12/21/05, Alvin Wang <[EMAIL PROTECTED]> wrote:
>
> I am planning on doing a lot of coding over Christmas. A mail list
> system, Flickr based photo album, etc. If I could write them in a way
> that it would be easy for other people to integrate, I would be happy
> to donate.
>
>
> My understanding - please correct
>
> Naming Convention/Coding style
> http://www.python.org/peps/pep-0008.html
>
> Widgets
> http://www.turbogears.org/docs/devcasts.html
> they go in Turbogears.widgets
The "standard" widgets go in turbogears.widgets. That means widgets
that are going to be used in a decent majority of apps and are
compatible (licensing-wise) with TurboGears. Otherwise, widgets can go
in whatever package they need to go in. (And if they can't, that's a
bug.)
> Toolbox
> turbogears.toolbox.tools
> Things that I think would be interesting and I will get around to.
> Batch manager - nightly,weekly cleanup jobs
> email manager - process incoming email.
"Process incoming email"? Isn't that what Thunderbird is for? (Or do
you just mean behind-the-scenes? Toolbox is for interactive tools.)
> Security manager - I want to make a new identity system with database
> configuration
I wasn't clear from your other message on what exactly wasn't meeting
your needs with the existing one. The desired roles for a given method
were specified in the decorator, but the actual roles that a person
has can be in the database.
Either way, my goal would be that the turbogears.identity module will
either (a) do what you need out of the box, or (b) allow you to plug
in custom code that does precisely what you need.
> Paypal manager or accounting manager.
A good module, to be sure.
>
>
> Modules
> By this, I mean chunks of code with templates, javascript, images, etc.
> A photoalbum, a bulletin board, a shopping cart, etc.
> Suppose, I wrote my module
> - code was in
> turbogears/addins/ModuleName
> - template directory would be below it.
> - model.py would be in the ModuleName directory. That way, a procedure
> could vacuum up all the model.py's and add them automatically.
> - database tablenames would start with ModuleName_blah
>
> - static files are in
> turbogears/static/addins/ModuleName
>
This part of things is not fully-formed yet. I can guarantee that the
vast majority of things built like this will not become a part of
TurboGears proper, because they're outside the realm of what webapps
need to do. (More specifically, they *are* webapps themselves.)
The direction that I was heading (and CherryPy 2.2 supports this
better) is that you'd quickstart a project and just build it up
naturally (you should use appropriate package namespaces to keep your
stuff distinct). Then, if you're putting together a site, you can do
this:
from alvinphoto import PhotoAlbum
class Root(controllers.Root):
album = PhotoAlbum(dir="/foo/bar/photos")
> I am planning on using apache to serve the static stuff.
Unless you're expecting a lot of traffic, I wouldn't even bother with
that step. If you are expecting a lot of traffic, it's a good idea.
>
> Theoretically, you could add
> Root.bbs = BulletinBoard()
> and be done.
Right. That is theoretically the case. However, there are issues with
configuration and whatnot that are better sorted out in CP2.2.
Paste integration would provide additional ways to hook apps together.
> I am not yet sure what to do with batch jobs and email processors but
> they should be easy to find too.
>
>
> Packaging
> - use easyinstall
> No idea how I would do this yet but I will figure it out when the time
> comes.
Piece of cake. If you quickstart a project, you just run
python setup.py bdist_egg
and you'll get a .egg file in your dist directory, all ready for
easy_installing. Python's distutils also makes it super easy to
register your package with the Cheeseshop, which means that
"easy_install AlvinPhoto" could work just like that.
> Sorry if this is beyond what TG should be. I am just really
> enthusiastic about it. I recently threw away about 10K lines of buggy
> PHP code that I wrote. It only did about half of what TG does. Of
> course, there are a few things that TG does not do and I want to add
> them in quickly.
Cool!
TurboGears is *not* PythonNuke. But, having good pre-built components
for things people like to do on their sites is a good thing.
Maybe we can leverage the Cheeseshop. If TurboGears addons are put
into appropriate categories, we can pull that information and display
it on TurboGears.org. easy_install would work, because it checks the
Cheeseshop *and* people would have an easy way to quickly browse the
packages available for TurboGears directly on the TG site.
Kevin
