On Fri, Jun 13, 2008 at 6:38 AM, Brian Rosner <[EMAIL PROTECTED]> wrote: > > Hello, > > I need to draw some quick attention to media handling in newforms- > admin. Ticket #7129 [1] was opened with the intension of the old > admin's behavior with the js inner Admin option. The trunk > documentation states: > > If you use relative URLs — URLs that don't start with http:// or / — > then the admin site will automatically prefix these links with > settings.ADMIN_MEDIA_PREFIX. > > However with the use of the new Media class the default behavior of > relative paths will prepend settings.MEDIA_URL. I am wondering if the > change to force an explicit prepend of ADMIN_MEDIA_PREFIX is now the > requirement on newforms-admin? Should the admin handle media slightly > different or should there be note in the docs about this? When the > media handling code landed there wasn't any docs in regard to the > admin specific handling of media, it was just implied from the regular > media handling code for newforms.
It has been a while, but I believe my thinking went something like this: A media definition is a media definition, no matter where it appears. All media should follow the same set of rules, no matter whether it is in admin or not - after all, admin is just another application. Admin defines a bunch of widgets that have media requirements, and it will often make sense for those media files to be served from a different path to the other media for the site. ADMIN_MEDIA_PREFIX exists as a configuration setting for the admin app to describe where those media files can be found. All the internal admin media definitions force prepend ADMIN_MEDIA_PREFIX. ADMIN_MEDIA_PREFIX will generally be an absolute URL, so the MEDIA_URL won't be prepended. However, this setup does allow you to easily serve /media/mymedia and /media/admin by specifying a relative ADMIN_MEDIA_PREFIX of 'admin' on a base MEDIA_URL of '/media/'. Ticket #7129 is the point at which this approach starts to fail - a user defined Media block that needs to reference an admin media script. Trunk makes a special case of admin media definitions (or rather, it does deal with media anywhere but admin), so this has never been an issue before. My gut feeling is that this particular problem won't be a particularly common occurrence, and a lot less common than in trunk. The most common reason I can think of to reference admin media is to use the admin widgets, but the widgets wrap their own media. This only leaves utility scripts like getElementBySelector.js. In many cases, these scripts will get inherited from the base media definition, so there won't be a need to explicitly reference them anyway. For the remaining cases, I can't say I have any particular problem requiring people to specify ADMIN_MEDIA_PREFIX + 'js/getElementBySelector.js' if they want to reference these files - after all, this is what the file is called. The upshot of this approach is that the requirement to prepend would be the same whether you were defining an admin media definition or a media definition for any other form in your application. IMHO, consistency between Admin behaviour and normal behaviour is a good thing. Yes, it is a slight change from trunk, but I think it is a change that makes sense in terms of the new generic media handling framework. Put me down as +1 to documenting this as a change from trunk->newforms admin. If we _do_ want to maintain the old trunk behaviour, one solution might be to allow a 'prefix' setting on Media definitions. By default, the prefix is MEDIA_URL, but the default Media definition for ModelAdmin defines the prefix as ADMIN_MEDIA_PREFIX. User extensions of ModelAdmin would then inherit the prefix definition, and #7129 could be avoided. Other applications with similar needs could define their own prefix settings, so we're not introducing an admin-specific behaviour. Yours, Russ Magee %-) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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-developers?hl=en -~----------~----~----~----~------~----~------~--~---
