Re: RoR Ajax helpers port to Django tags?
Eugene Lazutkin wrote: Look at Dojo. I did a small how-to on creating widgets here: http://lazutkin.com/blog/2005/dec/24/live-filtering/. Some people, who read it, missed my point: it was not about Ajax functionality (you can do it with any library), it was about creation of self-contained generic widgets, which don't pollute your html code with unnecessary garbage. You can download LiveFilter.js (link in the tutorial) and use it literally without modifications with practically any form in your project to make it "live". All you have to do is to implement a relatively simple view to support it on Django's side (example included). No JavaScript knowledge is involved in actual use. But if you want to be fancy, you can create your own widgets, and reuse them across projects. Additional bonus (useful for medium-to-large projects): such widgets provide a clean separation between client-side programmers, server-side programmers, and (most importantly) designers --- everybody is doing stuff they are familiar with. Nice example. I think it points towards the basic direction that a Django AJAX framework should take. Client-side code should be in template-vars (ContextProcessor if needed) and template-tags connected to client-side "views" in .js files. Server-side code should consist of simple RESTful views (there are several existing generic views that could easily be used for that task, and there are probably some good ideas out there for other good AJAX-friendly generic views). I think it points to another idea I think would be nice to see in Django: "smart views" (actually, it would really just be a smart template loader and a single additional piece of information needed to pass to the generic views, in order to pass to the template loader). There are several cases where you might have the same view (all of the X objects, details of the X object with id=somenumber, ...), but different output formats based on circumstance. You could let the template loader handle the format... I would use the file extension. For example, you could have your HTML templates as myobject_list.html and your RSS template for the same object as myobject_list.rss. Then you could just add the proper format setting to your info_dict for the generic object_list view and let it choose the proper one. (Assuming for whatever reason you don't want to use the existing RSS Framework, which works well, but this is just the first example to come to mind.) Another example would then be the "simple" views for use in AJAX/REST projects (using .ajax or .rest or .js or .raw.xml depending on the content type, perhaps). You could even design your URLs to take advantage of the format context *if you wanted*. Something like (using an object_detail-style example this time): ``r'^mysite/coolthings/(?P\d+)(?P\.\w+)?/?'`` That would match things like: /mysite/coolthings/1/ (The typical HTML view for a Django site) /mysite/coolthings/1.xml Overall it would be subtle "opt-in" and shouldn't affect the current behavior (ie, if the generic view+template loader doesn't know the expected output format, default gracefully to the default in settings.py). Anyone else see it as useful? -- --Max Battcher-- http://www.worldmaker.net/ "History bleeds for tomorrow / for us to realize and never more follow blind" --Machinae Supremacy, Deus Ex Machinae, Title Track
image field update impossible.
Hello i created a foo model to expose the problem,
from django.core import meta
# Create your models here.
class Aclass(meta.Model):
question = meta.CharField(maxlength=200)
img= meta.ImageField('Attach Image', upload_to='postimgs',
blank=True)
class META:
admin = meta.Admin(
fields = (
(None, {'fields': ('question', 'img')}),
),
)
wiht img behind a normal image field,
when i go to the admin part and add a foo object with the form
everyhting is fine, my image is well saved.
However when i edit this same foo object tu change some data, any
change to the image field, (browsing path to an other image), give a
form checking error in red once saved.
Please correct the error below. :
Enter a valid filename.
whats wrong ?
thank you
Re: RoR Ajax helpers port to Django tags?
Ben Bangert wrote: Eugene Lazutkin wrote: A lot of people who use list boxes, radio buttons, and other widgets don't know X11/Win32 graphics APIs and event systems. My point is there are many ways to minimize exposure to js. Agreed, I have yet to see anyone come up with clear cases for widgets within web programming. Zope has some, and they're pretty decent I believe, but there's a bit of a learning curve as usual. Look at Dojo. I did a small how-to on creating widgets here: http://lazutkin.com/blog/2005/dec/24/live-filtering/. Some people, who read it, missed my point: it was not about Ajax functionality (you can do it with any library), it was about creation of self-contained generic widgets, which don't pollute your html code with unnecessary garbage. You can download LiveFilter.js (link in the tutorial) and use it literally without modifications with practically any form in your project to make it "live". All you have to do is to implement a relatively simple view to support it on Django's side (example included). No JavaScript knowledge is involved in actual use. But if you want to be fancy, you can create your own widgets, and reuse them across projects. Additional bonus (useful for medium-to-large projects): such widgets provide a clean separation between client-side programmers, server-side programmers, and (most importantly) designers --- everybody is doing stuff they are familiar with. As soon as I deal with never-ending stuff on my plate (sigh), I plan to bundle some widgets and corresponding generic views to make it super simple to use for simple projects. I'd suggest taking both approaches, RailsHelpers and something like RJS now; new thing when its ready. The amount of effort required for something like RJS is pretty minimal, for an AJAX widget system there will likely be extensive planning, meetings, etc. As I plan on doing something like the RJS stuff anyways, Django need only have a single person who implements it for Django (like Louis did for the RailsHelpers) Agreed. "Let 1000 flowers bloom" (c) Chairman Mao. Like I said before you did fantastic work porting this stuff over to Django. Thanks, Eugene
Cache issue on Dreamhost?
I recently installed Django on Dreamhost, following the great instructions here: http://wiki.dreamhost.com/index.php/Django. The installation worked fine, but any change I make to an app takes hours to register on the Web. It seems to be an fcgi or caching problem, possibly not reloading myproject.settings upon reload of the page. To test, I altered the line os.environ['DJANGO_SETTINGS_MODULE'] ='myproject.settings' in django.fcgi, changing 'myproject.settings' to something invalid. As it should have, the page gave me an error on reload. I then changed ' myproject.settings' back to normal, and my changes appeared immediately -- I'm guessing because it was forced to reload the settings file. Any idea how to fix this? I'm running Django on a subdomain, with all the files in the home directory. I'm also new to this. Mercy would be appreciated. Thanks, Chase
Re: magic_removal table update
Jason Davies wrote:
ALTER TABLE auth_groups ALTER id SET DEFAULT
nextval('public.auth_group_id_seq'::text);
This was the peculiar incantation I was looking for, thanks. Now I just
have a non-fatal, non-blocking error from the django_content_types table...
--
--Max Battcher--
http://www.worldmaker.net/
Re: RoR Ajax helpers port to Django tags?
Eugene Lazutkin wrote: > A lot of people who use list boxes, radio buttons, and other widgets > don't know X11/Win32 graphics APIs and event systems. My point is there > are many ways to minimize exposure to js. Agreed, I have yet to see anyone come up with clear cases for widgets within web programming. Zope has some, and they're pretty decent I believe, but there's a bit of a learning curve as usual. AJAX web widgets is a bit different than just putting list boxes and radio buttons up, its a whole infrastructure thing with backend responses, etc. Minor deviations in customization of the web widget can easily involve modifying server-side code to handle the interaction, etc. It seems like AJAX web widgets is very different from X11/Win32 graphic API's as far as I can tell. The real question is, are Django people happy to wait while some new, super-neat, powerful, widget system is developed using AJAX; or would Django coders like to use something as soon as possible? I'd suggest taking both approaches, RailsHelpers and something like RJS now; new thing when its ready. The amount of effort required for something like RJS is pretty minimal, for an AJAX widget system there will likely be extensive planning, meetings, etc. As I plan on doing something like the RJS stuff anyways, Django need only have a single person who implements it for Django (like Louis did for the RailsHelpers) > Of course it is debatable that the absence of knowledge is The Good > Thing (tm). ;-) In many cases it is used to dumb down the programming > tools for dumb down programmers to create dumb down applications. > Personally I prefer to learn the proper way using proper tools. :-) Sure, it goes both ways. In the case of RJS and RailsHelpers, I think the philosophy is, if you just want to use AJAX to swap some elements or something, that in itself is not enough reason to invest hours into being a Javascript programmer. There's a lot of tools up and down the toolchain of web programming, I seriously doubt any of us are completely proficient at each and every level of it. > "If your only tool is a hammer, all your problems will look like nails." > This is what I call "a low-level approach" --- using a crutch instead of > building a proper web application. Alternatively, I think RailsHelpers is meant purely for hitting nails. You can get creative and smash in some screws without much harm, but obviously you'll need a better tool if your needs are larger. Anyways, the RailsHelpers are mostly done. The RJS/Javascript Generator won't take me more than an hour or two to port, then its a matter of figuring out good practices for using it since our setup is rather different than Rails. Anyone interested in taking a look at this, and figuring out how to slot it into Django, feel free to contact me. Cheers, Ben
Re: rss problem
On 1/25/06, danylo <[EMAIL PROTECTED]> wrote: > This is what I'm getting: > > > > http://www.foo.bar > > http://www.foo.bar > Hey Dan, You need to create templates for the title and description. If your feed's slug is foo, these templates should be called "feeds/foo_title.html" and "feeds/foo_description.html". In those templates, you describe how to construct the contents of the and . The templates are passed a variable "obj", which, in your case, is the WriterFeed object for the current item. Here's the relevant part of the docs: http://www.djangoproject.com/documentation/syndication/#a-simple-example Check out the part that begins: "To specify the contents of and ..." Adrian -- Adrian Holovaty holovaty.com | djangoproject.com | chicagocrime.org
Re: several django questions, models, apache
removing the trailing ^ is the only way so far,
here the httpd where i took ofthe / after "/cefinban
and added a ServerName
then typing in the browser http://127.0.0.1/cefinban/admin/
if url.py link is (r'^admin/',
include('django.contrib.admin.urls.admin')), give me a 404 error
The current URL, /cefinban/admin/, didn't match any of these.
however taking of the ^ make it work.
ServerName www.cefinban.no-ip.com
SetHandler python-program
PythonHandler django.core.handlers.modpython
PythonPath sys.path+['/home/greg/Projects']
SetEnv DJANGO_SETTINGS_MODULE cefinban.settings
PythonDebug On
Alias /media "/var/www/cefinban/media"
SetHandler None
Re: RoR Ajax helpers port to Django tags?
Ben Bangert wrote: I think its actually rather high level, in that you don't really need to know any Javascript what-so-ever. Obviously not knowing any Javascript will be a limitation to exactly what you can do, but the helpers and RJS meet a lot of people's needs with a very minimal amount of additional learning required to utilize it. A lot of people who use list boxes, radio buttons, and other widgets don't know X11/Win32 graphics APIs and event systems. My point is there are many ways to minimize exposure to js. Of course it is debatable that the absence of knowledge is The Good Thing (tm). ;-) In many cases it is used to dumb down the programming tools for dumb down programmers to create dumb down applications. Personally I prefer to learn the proper way using proper tools. :-) If you don't know Javascript, but use Rails style helpers, you'd instead just update the cart element with the reply from the server, etc. "If your only tool is a hammer, all your problems will look like nails." This is what I call "a low-level approach" --- using a crutch instead of building a proper web application. Thanks, Eugene
rss problem
As part of my first steps into Python and Django, I'm trying to generate an RSS feed for a group of individual writers. I'm finally able to generate an RSS feed, but it's incorrect. This is what I'm getting: http://www.foo.bar http://www.foo.bar The link and guid are correct, but I'm not getting the actual title or description or other data (publication date, etc). I'm just not seeing what I need to do differently to pull in the actual values for title and description. Any ideas? Thanks much, Dan This is the feeds.py: from django.contrib.syndication.feeds import Feed from django.models.bylines import writers, writerfeeds class Authors(Feed): def get_object(self, bits): if len(bits) != 1: raise ObjectDoesNotExist return writers.get_object(feed_name__exact=bits[0]) def title(self, obj): return "Stories by %s" % obj.byline def link(self, obj): return "/rss/writers/%s" % obj.feed_name def description(self, obj): return "Stories by %s" % obj.byline def items(self, obj): return writerfeeds.get_list(writerid__id__exact=obj.id, limit=25, order_by=['-pub_date'])
Re: RoR Ajax helpers port to Django tags?
I'd think the most reasonable approach would be to have the frameworks reference the module. Myghty doesn't require an API, as the names are just imported and attached to a template global helper object, ie, <% h.observe_field(.) %>. TurboGears may likely require a bunch of API's for the various template languages Buffet support, I don't know offhand. For those cases, I'd have no problem including the API glue in the RailsHelpers repository since it makes little sense to have yet another package that just contains that API glue.
Re: RoR Ajax helpers port to Django tags?
That sounds like a great idea (working together), and personally I'm
not too hung up about which AJAX library I use, as long as it can do
the job (which most seem too for my simple things)
I like the idea of having one way of doing this across frameworks, it
makes them all simpler to learn and increases the adoption of all of
them.
my only question is how are you planning on setting this up. are you
thinking that each framework should just reference your module, or are
you planning that you put the API glue into your SVN repo as well?
(alongside a turbogears & myghty version I'm guessing)
Louis has already started integrating django with it, and I'm most
concerned that his hard work doesn't get lost.
--I
On 1/26/06, Ben Bangert <[EMAIL PROTECTED]> wrote:
>
> For those concerned about the fact that these helpers use ProtoType and
> Scriptaculous, it should be noted that Mochikit 1.3 will include
> equivalent functionality. This should make it seamless to use Mochikit
> instead with no or minimal changes to the helper functions.
>
> There's several people now working on the RailsHelpers package to keep
> it up with the Rails version, as well as the unit tests. The one big
> thing this package does not include is the Javascript Generator object
> used for the very very new Rails feature (only in svn I think) called
> Rails Javascript Scripts (or something like that, RJS). Here's an
> example:
>
> page.insert_html :bottom, 'list',
> content_tag("li", "Fox")
> page.visual_effect :highlight, 'list', :duration => 3
> page.replace_html 'header',
> 'RJS Template Test Complete!'
>
> As one can see, it makes AJAX so trivial, you can do a ton of stuff not
> knowing Javascript at all. These functions just generate some
> Javascript that does the work for you. I would like to have something
> similar for use in Python, anyone else interested in helping out on
> this?
>
> Since this is just generating Javascript from a function, I see nothing
> particularly framework specific in it, so we should all be able to work
> together on it. :)
>
>
--
[EMAIL PROTECTED] -- blog: http://feh.holsman.net/ -- PH: ++61-3-9877-0909
If everything seems under control, you're not going fast enough. -
Mario Andretti
Re: RoR Ajax helpers port to Django tags?
For those concerned about the fact that these helpers use ProtoType and
Scriptaculous, it should be noted that Mochikit 1.3 will include
equivalent functionality. This should make it seamless to use Mochikit
instead with no or minimal changes to the helper functions.
There's several people now working on the RailsHelpers package to keep
it up with the Rails version, as well as the unit tests. The one big
thing this package does not include is the Javascript Generator object
used for the very very new Rails feature (only in svn I think) called
Rails Javascript Scripts (or something like that, RJS). Here's an
example:
page.insert_html :bottom, 'list',
content_tag("li", "Fox")
page.visual_effect :highlight, 'list', :duration => 3
page.replace_html 'header',
'RJS Template Test Complete!'
As one can see, it makes AJAX so trivial, you can do a ton of stuff not
knowing Javascript at all. These functions just generate some
Javascript that does the work for you. I would like to have something
similar for use in Python, anyone else interested in helping out on
this?
Since this is just generating Javascript from a function, I see nothing
particularly framework specific in it, so we should all be able to work
together on it. :)
Re: flash
[EMAIL PROTECTED] wrote: I have problem is that my flash is not working when i used Django i am using internet explorer i don't know why althought i put my swf file is in the media folder 1st of all: test with your browser that all required files are accessible. E.g., enter .swf's url and see if you get any errors. Thanks, Eugene
flash
I have problem is that my flash is not working when i used Django i am using internet explorer i don't know why althought i put my swf file is in the media folder Mary Adel Software Developper ITrize-Egypt 13 Naguib Hashad medan elhegaz heliopolis email: [EMAIL PROTECTED] Office: +202 - 6236612 EXT. 102 Mobile: +2012 5241719
repository with apps
It would be nice with an official repository with django apps. There may very well exist 1000 roughly equivalent poll app implementations out there already. Wouldn't it be good if we had a repository of reusable common apps? I think it would be awesome. Not sure who should get commit access and stuff. It would be useless with a repository with hundreds of abandoned and messed up apps. A repository with commented and documented apps would on the other hand be extremly useful and would probably make django explode. Is there such a repository or are there any plans of such? Tim
Re: meta.Admin 'fleids' option
Big thanks! I'm found error, misprint in field's names..
Re: Template cache which speeded up my setup 25 times
On 1/25/06, hugo <[EMAIL PROTECTED]> wrote: > You might have written this as a simple template loader - and used the > basic template loaders as starting point, just overloading the > get_template functionality. That way you would be able to use the > standard render_to_xxx functions - you only would have to change the > TEMPLATE_LOADERS setting. And that way integration with the Django core > is quite simple, as it is just another bunch of template loaders the > user can just activate. I'm not sure that would work, because I suspect much of the performance savings Wojtek is getting is from the fact that his patch caches *compiled* templates, not the raw template code. (He has a template that loads another template within a loop.) I don't see how a template loader -- in the TEMPLATE_LOADERS framework -- would be able to cache compiled templates. I was thinking we could add a CACHE_COMPILED_TEMPLATES setting and change get_template() to give it a "cache" keyword argument, which would default to the value of CACHE_COMPILED_TEMPLATES. Any quick thoughts before I implement this? Adrian -- Adrian Holovaty holovaty.com | djangoproject.com | chicagocrime.org
Re: magic_removal table update
On 1/25/06, Max Battcher <[EMAIL PROTECTED]> wrote:
> I'm living on the bleeding edge (just migrated to rev. 2123) with my
> current development, and followed the suggested ALTER TABLE commands
> from the wiki page, and though I can read from the data (all of the
> views work correctly), I can't save because all of the sequences are now
> out of sync. I tried renaming the sequences to fit the new naming
> scheme, but to no avail (Django is calling the new sequence name and the
> table itself still refers to the old sequence name).
This is the one lame thing about PostgreSQL -- when you rename tables,
you have to rename the sequences as well. Here's an example:
ALTER TABLE chicagocrime_wards RENAME TO chicagocrime_ward;
ALTER TABLE chicagocrime_wards_id_seq RENAME TO chicagocrime_ward_id_seq;
ALTER TABLE chicagocrime_ward ALTER COLUMN id DROP DEFAULT;
ALTER TABLE chicagocrime_ward ALTER COLUMN id SET DEFAULT
nextval('public.chicagocrime_ward_id_seq'::text);
I will edit the RemovingTheMagic wiki page to add this example explicitly.
Adrian
--
Adrian Holovaty
holovaty.com | djangoproject.com | chicagocrime.org
Template cache which speeded up my setup 25 times
Hey,
On my hosts doing several hundred requests per second the load was at
100 already, and then Adrian suggested to cache the templates. So I
implemented a simple cache (which is now a hack but perhaps it will be
included in Django soon) which brought the load down to 5 - so a lot of
speedup at the cost of templates not being reloaded when changed (you
have to restart apache or whatever you're using for Django).
The actual page load time on a non-loaded server went down from 0.17 to
0.07 seconds with the templates cached.
The code is below, all you have to do is call install_loader_cache()
when your app starts (in the urls perhaps) and use render_to_response
from this package when rendering output (the default one has an old
reference to get_template so it won't use the cache until this feature
gets included in Django).
Regards!
Wojtek
# django template cache by [EMAIL PROTECTED]
from django.core import template_loader
from django.core.template import Origin, StringOrigin, Template,
Context
from django.utils.httpwrappers import HttpResponse
orig_get_template = template_loader.get_template
cache = {}
def get_template(name):
if cache.has_key(name):
return cache[name]
else:
tpl = orig_get_template(name)
cache[name] = tpl
return tpl
def render_to_string(template_name, dictionary=None,
context_instance=None):
"""
Loads the given template_name and renders it with the given
dictionary as
context. The template_name may be a string to load a single
template using
get_template, or it may be a tuple to use select_template to find
one of
the templates in the list. Returns a string.
"""
dictionary = dictionary or {}
if isinstance(template_name, (list, tuple)):
t = template_loader.select_template(template_name)
else:
t = get_template(template_name)
if context_instance:
context_instance.update(dictionary)
else:
context_instance = Context(dictionary)
return t.render(context_instance)
def render_to_response(*args, **kwargs):
return HttpResponse(render_to_string(*args, **kwargs))
def install_loader_cache():
global orig_get_template
template_loader.get_template = get_template
template_loader.render_to_string = render_to_string
Re: magic_removal table update
Max Battcher wrote:
> I'm living on the bleeding edge (just migrated to rev. 2123) with my
> current development, and followed the suggested ALTER TABLE commands
> from the wiki page, and though I can read from the data (all of the
> views work correctly), I can't save because all of the sequences are now
> out of sync. I tried renaming the sequences to fit the new naming
> scheme, but to no avail (Django is calling the new sequence name and the
> table itself still refers to the old sequence name).
Yeah, you need to do something like:
ALTER TABLE auth_groups_id_seq RENAME TO auth_group_id_seq;
ALTER TABLE auth_groups ALTER id SET DEFAULT
nextval('public.auth_group_id_seq'::text);
...for each sequence that needs renaming.
Regards,
Jason
Re: magic_removal table update
On 1/25/06, Max Battcher <[EMAIL PROTECTED]> wrote: > At this point I'm a bit stumped on how to properly do this. Is there an > easy way to resync the sequences in PostgreSQL that I've overlooked? Did you try "django-admin.py sqlsequencereset"? This used to work for me. Andreas
magic_removal table update
I'm living on the bleeding edge (just migrated to rev. 2123) with my current development, and followed the suggested ALTER TABLE commands from the wiki page, and though I can read from the data (all of the views work correctly), I can't save because all of the sequences are now out of sync. I tried renaming the sequences to fit the new naming scheme, but to no avail (Django is calling the new sequence name and the table itself still refers to the old sequence name). At this point I'm a bit stumped on how to properly do this. Is there an easy way to resync the sequences in PostgreSQL that I've overlooked? Otherwise, I'm assuming: * Dump the data to a file * Drop Cascade everything * Re-install * Import back from the file I made a brief remark on the wiki page that someone should probably amplify into some better general migration guideline. -- --Max Battcher-- http://www.worldmaker.net/
