On May 22, 2012, at 7:23 AM, Florian Fuchs wrote: > Am 22.05.12 13:14, schrieb Richard Wackerbarth: >> On May 21, 2012, at 8:33 PM, Stephen J. Turnbull wrote: >>> I don't understand your point. For better or worse, CSS is tied >>> to the HTML it styles via id and class tags, and element nesting >>> patterns. Another app for presenting list admin functions would >>> have different HTML and different CSS. So a site which wishes to >>> customize the appearance of postorius will need to add >>> postorius-specific CSS anyway, which may as well be indicated by a >>> path element in the URL. >> >> Yes, but one of the design points of Django is that, without a great >> deal of effort, the user can customize his site URLs in any manner. >> Further, doing so follows the DRY principle. Embedding the actual >> text stream "/postorius/" in templates, particularly multiple times, >> is a violation of this design. > > Again: This is not generally true. It is true for hard-coded *page* URLs > in templates.
But you are now making a distinction between assets based on their method of generation. Whether a file is .html , .css, or .js , django can generate it from templates. It is only for server efficiency that a distinction is made. Further, unless the content is customized for the subsystem, I would argue that the asset should appear in a global namespace and not within the namespace of the subsystem. For example, it would be a poor practice to deliver content for ".../jquery-1.7.1.js" from within the subsystem which is different from that which was supplied by the vendor. Why, therefore, should ".../postorius/jquery-1.7.1.js" ever exist? > One really should use the `url` template tag for this. Equally, there SHOULD be an equivalent mechanism for the static content. > But having the app name (in our case: the text stream "postorius") appear > hard-coded in *static file* paths (CSS/JS etc.) in base.html is, in > fact, a wide-spread and very useful Django convention. Only because that was an expedient implementation to which most users do not object. > After all, the app's name is "postorius" and as such it is the reference > point for > Django, needed for template overrides and static file collection. As an internal name, I agree. However from an external view, I think that it is more confusing than helpful. I also think that using the entire FQDN in the website URLs is a mistake. (I have no problem with them in the REST interface) There are three obvious use cases. I believe that the most common usage will be the middle one. Case 1) One website serves mailing lists from multiple email domains. Here, we need to specify both the list name and the domain in each get request in order to be able to handle duplicated list names in separate email domains. Case 2) The website serves multiple mailing lists, all from the same email domain. Here, the email domain need not be a part of the URL because it is implied by the website domain. The django view handling the transaction should supply the email domain for processing purposes. Case 3) The website serves only a single mailing list. Here the django view can supply both the list name and the email domain. Actually, the urlpattern mechanism should be capable of parsing the different URL cases and a single view can handle all three cases. So, we could supply the includable url patterns for each case and the installer could activate the appropriate one. > A prefix is not the recommended approach any more. In fact the > "admin_media_prefix" context variable in django's own contrib.admin app > is now deprecated, because that's exactly what > contrib.staticfiles/collectstatic and template overrides can do better. Actually, I think that "media" was intended to be for uploaded content, "static" is for invariant install-time content, and templates are for generated upon request content. >> You are also missing the fact that postorius is intended to be a >> subsystem within a larger website, > > There is probably more than one opinion on what Postorius is intended to > be. If you ask me, it is more than just that. A subsystem in an existing > site, yes. But also a stand-alone mailing list management app that you > might serve on a specific (sub)domain. But, that is just a special case of a trivial master site of which the postorious administration interface, and quite likely a mail archive interface are the only subsystems. _______________________________________________ Mailman-Developers mailing list Mailman-Developers@python.org http://mail.python.org/mailman/listinfo/mailman-developers Mailman FAQ: http://wiki.list.org/x/AgA3 Searchable Archives: http://www.mail-archive.com/mailman-developers%40python.org/ Unsubscribe: http://mail.python.org/mailman/options/mailman-developers/archive%40jab.org Security Policy: http://wiki.list.org/x/QIA9
