Tom,
Thanks for going forward with this, there are alot of people who
want something like this.
On Mar 23, 8:17 am, Tom Smith <[EMAIL PROTECTED]> wrote:
> > Unfortunatly given your example, 90% of what you want (urls.py with
> > static file handling, a media directory, building the actual model)
> > are things I expressly do NOT want the wizard to do for ME. (I have my
> > own genapp.py tool I use for creating new apps.)
>
> Interesting... I'd like to know why you don't want those things and
> see your own genapp script...
It will be checked into the PyCon-Tech code base in a month or two
(other projects are consuming my time these days).
http://us.pycon.org/TX2007/PyConTech
I optionally want models.py, views.py, forms.py, urls.py,
decorators.py, media/{js, img, css}/, templates/<appname>/,
templatetags/<appname>.py with some standard header information.
There are very, very few common threads between my models, and I would
prefer a graphical interface for the models, as a second stage in the
app building.
Of the 7 core apps for the conference software, no two share a common
model structure:
https://svn.python.org/conference/django/trunk/pycon/
I was being a little disingenuous when I said I didn't want most of
it. I don't want a text based model builder.
The tool I have is a small wxpython app. A friend and I were thinking
of turning it into a django app with an ajax model builder. I'm an old
OMT hack and it appeals to me, but the recursive nature of it gives me
a migraine.
On the serving of static media:
I have a custom django app (called appmedia) which deals with serving
up static content in the 'media' directory of any app if its the dev
server, otherwise it is up to apache or httplight to serve up media in
production. (and adds {% app_media_root "myapp" %} ) so there is no
need for me to serve up media local to the apps urls.py
This goes against one of the django style rules, but I feel its
cleaner.
> I've started re-working mine based
> purely on my own crazy preferences and habits. For example, if I add
> an attribute to a class called "name", it assumes it's a CharField
> and it also adds a SlugField called "slug"... I didn't know they
> existed till today. If I add an attribute called "url"... you can
> guess where that one is going..
I like the Idea of it, but I am concerned you will end up with a meta-
model language once you get everything done. As long as you don't go
too crazy with it, it should be fine.
> I'd love a call like this...
>
> >>> python startapp.py my_app_name -flavour=(tom | doug | malcolm |
> james )
My first implementation used something like the flavor you propose (I
made the mistake of calling it -type).
I had 4 spec'd out, and discovered that NONE of my 25 some odd apps
actually conformed to any of the 4 specs.
I think this was due to my purist mind conflicting with the reality of
the apps I wrote.
Someone other than me will hopefully be able to find some reoccurring
patterns that actually reoccur.
-Doug
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django users" group.
To post to this group, send email to django-users@googlegroups.com
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/django-users?hl=en
-~----------~----~----~----~------~----~------~--~---
