Re: Considering removing support for ("iLmsu") regex groups in URLpatterns. Do you use them?

[Sjoerd Job Postmus]

On Mon, Dec 19, 2016 at 08:23:09AM +, Adam Johnson wrote:
> >
> >  I guess the "safest" option is to keep the code around and let this
> > feature die when the deprecation ends in Python 3.7 (and meanwhile see if
> > anyone notices the deprecation warning in their code and files a ticket
> > about it). The only extra work compared to removing this now is silencing
> > the Python deprecation warnings in the Django tests in the meantime.
> 
> 
> Sounds fair. Flags could always be added to *url()* as an extra parameter.
 
How would that work with nested URL patterns? Would adding a flag also
apply that for the "parent" and/or "child" patterns? Would that also
work correctly for reverse?

Asking because I seriously don't know.

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/20161220071528.GA21882%40sjoerdjob.com.
For more options, visit https://groups.google.com/d/optout.

Re: Template-based widget rendering

[Tim Graham]

It's ready for review:

Add 'POST_APP_DIRS' TEMPLATES option. 
https://github.com/django/django/pull/7693
Template based widget rendering: https://github.com/django/django/pull/6498

On Wednesday, December 14, 2016 at 6:59:16 PM UTC-5, Tim Graham wrote:
>
> I don't have any strong objections at this point, just wanted to think it 
> through and offer possible alternatives. If there's no further input, I'll 
> finish adding tests and docs for the TEMPLATES 'POST_APP_DIRS' option 
> tomorrow, after which I think the widget rendering patch will be ready for 
> final reviews.
>
> On Wednesday, December 14, 2016 at 6:40:36 PM UTC-5, Carl Meyer wrote:
>>
>> Hi Tim, 
>>
>> On 12/14/2016 12:50 PM, Tim Graham wrote: 
>> > My thinking is that there should typically be only one directory in 
>> each 
>> > project that overrides built-in templates, otherwise if multiple apps 
>> > provide overrides, they'll stomp on each other when using the 
>> > app_directories loader.Are your projects usually set up that way? Using 
>> > the app_directories loader eases setup but adds a cognitive overhead of 
>> > figuring out where the template overrides are coming from. 
>>
>> All of these seem like generic objections to APP_DIRS / the 
>> app_directories loader, which has been around in some form (and been the 
>> default behavior) effectively forever. For better or worse, we have a 
>> template system that layers multiple loaders in the same template 
>> namespace and allows them to stomp on each other, and leaves it up to 
>> you to figure it out if they do. This does give people some rope to 
>> create confusion, but it's also powerful and flexible, and so far we've 
>> decided that tradeoff is worth it. How is any of this specific to form 
>> templates? 
>>
>> > If you feel 
>> > the ship has sailed and the pattern of putting the main "project" 
>> module 
>> > in INSTALLED_APPS to get "project-level"  templates rendered should be 
>> > endorsed, then I guess we'll do that. 
>>
>> I think some kind of "project" or "core" app is in practice pretty 
>> common (e.g. it also becomes necessary if you want "project-level" 
>> management commands, or DTL template tags, or...). I'm sure it's not 
>> universal; I don't think there's anything wrong with it, or anything 
>> wrong with not doing it. And I don't think that any decision we make 
>> here needs to imply an endorsement of one approach or the other. 
>>
>> I understand that in my proposed default setup, if a project relies on 
>> DIRS for their project-level templates, they won't be able to override 
>> form templates along with the rest of their project-level templates; 
>> they'll either need to switch to the ProjectTemplateRenderer or put 
>> their form override templates in an app. That's not ideal, but I think 
>> it's still a reasonable set of options (I'd probably go for 
>> ProjectTemplateRenderer in that situation -- "if you want project 
>> templates to override form templates, use ProjectTemplateRenderer" seems 
>> reasonable). While I agree this is a wrinkle, I don't think this wrinkle 
>> is a good rationale for making it impossible to override built-in form 
>> templates from an app in the default setup. 
>>
>> If you disagree with that, though, I could live with with just saying to 
>> everyone "if you want to override form templates, use 
>> ProjectTemplateRenderer" -- it's not that hard to switch to 
>> ProjectTemplateRenderer. 
>>
>> I would not be in favor of the FORM_TEMPLATE_DIRS setting. It adds a 
>> brand-new concept and setting, which would typically be set to the same 
>> value as your template DIRS in the common case, without really gaining 
>> any flexibility or much ease-of-use compared to just switching to 
>> ProjectTemplateRenderer. 
>>
>> Carl 
>>
>> > An alternative could be an additional setting to declare the 
>> > "project-level" templates directory. That would allow overriding 
>> > built-in and third-party app templates without create a "project" app. 
>> > For example, the engine for the DjangoTemplateRenderer would look like: 
>> > 
>> > def engine(self): 
>> > dirs = [os.path.join(ROOT, 'templates')] 
>> > if settings.FORM_TEMPLATES_DIR: 
>> > dirs.insert(0, FORM_TEMPLATES_DIR) 
>> > return DjangoTemplates({ 
>> > 'APP_DIRS': True, 
>> > 'DIRS': dirs, 
>> > 'NAME': 'djangoforms', 
>> > 'OPTIONS': {}, 
>> > }) 
>> > 
>> > This loading order makes it impossible for apps to override the 
>> built-in 
>> > templates unless that app is pointed to by FORM_TEMPLATES_DIR. You 
>> > couldn't easily do further customizations of built-in templates without 
>> > copying that app's templates into a new directory and pointing 
>> > FORM_TEMPLATES_DIR at it, then editing those templates or adding new 
>> ones. 
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and 

Re: Does the javascript test runner need attention?

[Tim Graham]

Hopefully the situation is a bit improved after 
https://github.com/django/django/commit/10278885fd909085bd76ccc1690a979582455f9e

We had to make this update as the old pinned phantomjs version doesn't 
support SHA256 SSL certs and thus couldn't fetch 
https://cdnjs.cloudflare.com/ajax/libs/openlayers/2.13.1/OpenLayers.js 
after cloudflare updated their cert today.

On Thursday, August 25, 2016 at 11:27:39 AM UTC-4, Tim Graham wrote:
>
> Trey Hunner said [0], "Blanket and qunit are the only real requirements 
> here. We may be able to switch away from Grunt and use those together in a 
> more manual fashion so requirements can be upgraded easily."
>
> [0] https://github.com/django/django/pull/4889#issuecomment-219921988
>
> On Thursday, August 25, 2016 at 9:31:08 AM UTC-4, Josh Smeaton wrote:
>>
>> Hi All,
>>
>> While building out a vagrant image for running django's tests (plug: 
>> https://github.com/django/django-box) I came across a problem trying to 
>> run the javascript tests as defined by the tox.ini file. It ended up being 
>> the same problem as raised in https://code.djangoproject.com/ticket/25803. 
>> The fix to that ticket was to update the package.json dependencies listing 
>> npm as < 3.0.0, but I'm wondering if there's a longer term solution we're 
>> going to need to look at.
>>
>> https://github.com/ModelN/grunt-blanket-qunit appears to be abandoned 
>> and is probably the main cause of us requiring npm version 2. Maybe we 
>> could look at separate packages for generating code coverage and running 
>> qunit tests? Does that sound right? I'm happy to open a ticket to track 
>> this, but just wanted to see if it's needed or already on someones radar.
>>
>> Cheers
>>
>

-- 
You received this message because you are subscribed to the Google Groups 
"Django developers  (Contributions to Django itself)" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-developers+unsubscr...@googlegroups.com.
To post to this group, send email to django-developers@googlegroups.com.
Visit this group at https://groups.google.com/group/django-developers.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-developers/d377b3ce-7ae9-4675-bb1a-2c47d066f1dc%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Structure vs. Content mode - front-end editing needs better UX

[Peter Bittner]

Thanks Angelo, for your quick and elaborate answer.

> The structure mode is intended for advanced user

For what I know it's not even possible to add a plugin to a placeholder in 
content mode. All you can do is edit plugins that have been added (by 
someone) previously. Users that have no access to structure mode cannot add 
new content.

Also, "advanced users" have the right for decent usability, too. Losing 
context is not something that happens to people with little expertise. It 
is something that is a proven fact of user research, application design and 
usability testing.

If django CMS doesn't get it right users will go and look for other 
solutions. We developers have a better time selling django CMS as a 
solution to clients when it is simply ahead of competition. It would really 
be nice and helpful to get the user experience right.

> we do not want to limit the view space

I don't think web developers complain about the Firebug panel (and the 
like). You can adjust its size, its position, you can even detach it from 
the main window. Also, if content editors (and web developers) have a large 
screen they can use the available screen real estate in an effective 
manner, given some flexibility of the UI. It's really a matter of reusing 
established patterns. Side panels that collapse or can be folded away exist 
in tools, mail clients, etc. for years, and we love them.

Just imagine that content editors work in a similar way than web 
developers. Wouldn't that be cool to look at? Wouldn't those people feel 
empowered? More possibilities, more feedback, more transparency, all at 
your finger tips without having to do research in the menus, the popup 
dialogs, etc.

Peter


Am Montag, 19. Dezember 2016 10:21:42 UTC+1 schrieb Angelo Dini:
>
> Hallo Peter
>
> thanks for the feedback and proposition. One trick that helps is switching 
> context via SHIFT + Space, that will highlight the current _hovered_ 
> element. The main reasons for two modes are:
> - Headless mode, this will be added in the future and will disable content 
> entirely and allows the CMS to be run headlessly for frontend frameworks or 
> applications
> - Permissions, some people should only be able to "edit" content vs 
> "restructuring", this way we create separate roles for the CMS
> - Legacy, as we had to support IE6/7 back in the days we had limitations 
> on what was possible through frontend
>
> We hear you and would like to improve the content mode itself to allow for 
> simple restructuring or adding content "lite" version. So people could 
> easily add images, text or so inline. The structure mode is intended for 
> advanced user that are free to do whatever they want. Even with your 
> suggestion with an inspector, the experience would still be reserved to 
> experienced users. In addition to that we do not want to limit the view 
> space, the toolbar is sometimes already be considered as "distractor" when 
> editing content.
>
> These are my thoughts :)
>
> Cheers
> Angelo
>
> On Sunday, 18 December 2016 17:14:43 UTC+1, Peter Bittner wrote:
>>
>> Hi all,
>>
>> I'd like to ask about the reasons for having a Structure _*versus*_ 
>> Content mode switch. We do front-end editing to avoid losing context with 
>> what we want to change. Now, when we switch to structure mode all the 
>> content is hidden---and we lose context. I've seen this impression 
>> confirmed with unskilled, untrained, first-time, and elderly users.
>>
>> Structure information is good for precise editing, it should be 
>> supportive information though. The real state of the page should stay 
>> visible, so the context remains established.
>>
>> How about doing editing as with Firebug (Inspect Element, etc. in your 
>> web browser)? With a structure panel open on one side of web page (and a 
>> plugin panel / toolbox open on another side of the web page) we could have 
>> all the information we need for editing visible at the same time. When 
>> hovering over a plugin or placeholder on either the web page or the 
>> structure panel the corresponding element on the other could be 
>> highlighted. Just like web developers love it when analyzing a web site.
>>
>> Any thoughts on this?
>> Peter
>>
>

-- 
Message URL: 
https://groups.google.com/d/msg/django-cms-developers/topic-id/message-id
Unsubscribe: send a message to 
django-cms-developers+unsubscr...@googlegroups.com
--- 
You received this message because you are subscribed to the Google Groups 
"django CMS developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-cms-developers+unsubscr...@googlegroups.com.
To view this discussion on the web, visit 
https://groups.google.com/d/msgid/django-cms-developers/669947bd-650f-49b2-9348-683f09d3925d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Considering removing support for ("iLmsu") regex groups in URLpatterns. Do you use them?

[Adam Johnson]

>
>  I guess the "safest" option is to keep the code around and let this
> feature die when the deprecation ends in Python 3.7 (and meanwhile see if
> anyone notices the deprecation warning in their code and files a ticket
> about it). The only extra work compared to removing this now is silencing
> the Python deprecation warnings in the Django tests in the meantime.


Sounds fair. Flags could always be added to *url()* as an extra parameter.

On 18 December 2016 at 23:44, Tim Graham  wrote:

> Only case insensitive matching was tested in the URL tests and none of
> this is documented. That's the only flag where I see a straightforward use
> case (but I avoid regexes of any complexity and didn't even know what the
> flags were for until I just looked them up), even if case-insensitive URLs
> aren't a good practice. From the W3C [0]: "URLs in general are
> case-sensitive (with the exception of machine names). There may be URLs, or
> parts of URLs, where case doesn't matter, but identifying these may not be
> easy. Users should always consider that URLs are case-sensitive."). I guess
> the "safest" option is to keep the code around and let this feature die
> when the deprecation ends in Python 3.7 (and meanwhile see if anyone
> notices the deprecation warning in their code and files a ticket about it).
> The only extra work compared to removing this now is silencing the Python
> deprecation warnings in the Django tests in the meantime.
>
> [0] https://www.w3.org/TR/WD-html40-970708/htmlweb.html
>
> Here are the other flag values, feel free to offer a use case if you have
> one:
>
> re.I -- match case insensitive
>
> re.L -- The use of this flag is discouraged as the locale mechanism is
> very unreliable, and it only handles one “culture” at a time anyway; you
> should use Unicode matching instead, which is the default in Python 3 for
> Unicode (str) patterns. This flag makes sense only with bytes patterns.
>
> re.M -- MULTILINE -- When specified, the pattern character '^' matches at
> the beginning of the string and at the beginning of each line (immediately
> following each newline); and the pattern character '$' matches at the end
> of the string and at the end of each line (immediately preceding each
> newline). By default, '^' matches only at the beginning of the string, and
> '$' only at the end of the string and immediately before the newline (if
> any) at the end of the string.
>
> re.S -- DOTALL - Make the '.' special character match any character at
> all, including a newline; without this flag, '.' will match anything except
> a newline.
>
> re.U -- Unicode -- these are redundant in Python 3 since matches are
> Unicode by default for strings
>
> On Sunday, December 18, 2016 at 4:18:33 PM UTC-5, Adam Johnson wrote:
>>
>> Since they were used in several places in Django's test suite I feel like
>> it's highly likely they're out there in use in the wild.
>>
>> Also if Django were to remove it, it would both 1) be a bit surprising
>> compared to the re module, as it's an implementation detail that the
>> urlparser  prefixes '^/' and 2) need a deprecation path that would require
>> code to work in Python 3.6 that's equivalent to implementing the feature,
>> so why not keep said code around?
>>
>> On 16 December 2016 at 19:19, Tim Graham  wrote:
>>
>>> Python deprecated usage of flags not at the start of a regular
>>> expression [0], e.g. 'CaseInsensitive(?i)' instead of
>>> '(?i)CaseInsensitive'.
>>>
>>> Deprecation warnings shows up in a few URL tests that are using (?i) to
>>> get case-insensitive matching of URLpatterns. However, because the URL
>>> resolver prefixes '^/' [or get_script_prefix()] to all patterns [1], the
>>> warning happens even if the regex group is at the start of a urlpattern,
>>> e.g.
>>>
>>> /home/tim/code/django/django/urls/resolvers.py:464: DeprecationWarning:
>>> Flags not at the start of the expression ^\/(?i)CaseInsensiti (truncated)
>>>   if re.search('^%s%s' % (re.escape(_prefix), pattern), candidate_pat %
>>> candidate_subs, re.UNICODE):
>>>
>>> A better sense of what's affected can be seen on my PR that removes
>>> support for the ignored groups [2]. All this landed in 2008 in Malcolm's
>>> rewrite of URL parsing [3].
>>>
>>> I'm not sure if any of these groups are used in URLpatterns in the wild
>>> or if it's okay to proceed with the removal. To keep the feature, I imagine
>>> Django would need to do some extraction of flags from URLpatterns and put
>>> them at the start of patterns, but I'm not too sure.
>>>
>>> Thanks for your feedback.
>>>
>>> [0] http://bugs.python.org/issue22493
>>> [1] https://github.com/django/django/blob/5d28fef8f9329e440ee67c
>>> efc900dbf89f4c524c/django/urls/resolvers.py#L464
>>> [2] https://github.com/django/django/pull/7701
>>> [3] https://github.com/django/django/commit/a63a83e5d88cd1696d1c
>>> 40e89f254f69116c6800
>>>
>>> --
>>> You received this message because you are subscribed to the Google