Re: djangocms-history And History
Dear django-cms and others, This is a generally announce that the cmsplugin-diff plugin is in beta and can be found here: https://github.com/doctormo/django-cmsplugin-diff There's a demo site which can be quickly brought up via `./setup.py demo` and should give you a localhost taste of the basic recording of edits and publishing events. * It does NOT use reversion * There are diffs * Django 1.8 and 1.11 Let me know any issues or thoughts, I've put this in it's own repository so other users can make use of it, but it'll be deployed at inkscape.org pretty soon. Best Regards, Martin Owens Inkscape Website Developer On Saturday, June 17, 2017 at 7:43:22 PM UTC-4, Martin Owens wrote: > > Dear djangocms, > > I've been following the djangocms-history project, and we have 0.4.0 > installed on the side to see what it can do. So far the history app, > doesn't seem to include any history. > > The functionality is undo and redo of changes pre-publish. There's no > record post-publish, no list of history (even pre-publish) during editing > and we're a very long way away from having diffs and other nice visuals. > > What is the roadmap for the djangocms-history application? > > The Inkscape project is keen on long-haul history, we're even willing to > have history per plugin rather than history per page. Diffs obviously and > diffs in alert messages which are sent to translators. We don't really need > undo and redo as such, the action parts aren't needed so much as the > information parts. Users have no clue at the moment what has changed, who > last changed the page, why (no comment on publishing for example) > > Should this kind of informational logging history be a separate app? > djangocms-log? > > Best Regards, Martin Owens > Inkscape Website Administrator > -- 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/61984f6b-f828-481e-aff6-8cf5e752ba5b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
djangocms-history And History
Dear djangocms, I've been following the djangocms-history project, and we have 0.4.0 installed on the side to see what it can do. So far the history app, doesn't seem to include any history. The functionality is undo and redo of changes pre-publish. There's no record post-publish, no list of history (even pre-publish) during editing and we're a very long way away from having diffs and other nice visuals. What is the roadmap for the djangocms-history application? The Inkscape project is keen on long-haul history, we're even willing to have history per plugin rather than history per page. Diffs obviously and diffs in alert messages which are sent to translators. We don't really need undo and redo as such, the action parts aren't needed so much as the information parts. Users have no clue at the moment what has changed, who last changed the page, why (no comment on publishing for example) Should this kind of informational logging history be a separate app? djangocms-log? Best Regards, Martin Owens Inkscape Website Administrator -- 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/5f813fd4-1c5c-4726-9be3-f05e6a92f542%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [Feature request] Template language type annotations (#27703)
On Monday, January 9, 2017 at 2:43:00 PM UTC-5, Дмитрий Симонов wrote:
>
> Ok. Here is my example with multiline annotations.
>
> https://github.com/a1fred/django-template-type-annotations
>
> What do you think?
>
It should probably avoid parsing of the main body, I don't believe that to
be canonical with the rest of django's tags.
It might be better to parse each pair of variables from the {% var %} tag
itself. Just allow that tag to take more than one pair and you should have
all the support for single and multiple declarations.
The other issue I have is that the tag doesn't effect the output the
template produces, so it's placement in templates will complicate the
formatting for non-coding contributors. This might be worth it, but I can
see the benefit of keeping these check lists outside of the template file
itself too. Having a test suite pick up these issues is my preferred
pattern, but anyway you develop it you'll have a very small amount of use
from most projects.
Best Regards, Martin Owens
Inkscape Website Admin
--
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/a06029e0-ceb4-4b7c-bd63-6acbaa406fd1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: DEP pre-proposal for a simpler URLs syntax.
This looks like a useful addition.
I'd also like to chip in with a DRY pattern I've been using in all my
projects which might be worth considering.
To take your example:
def url_tree(regex, *urls):
return url(regex, include(patterns('', *urls)))
urlpatterns = [
> url_tree('articles/',
> url('2003/', views.special_case_2003),
>url_tree('/',
> url('', views.year_archive),
> url_tree('/',
> url('', views.month_archive),
> url('/', views.article_detail),
> ),
> ),
>),
> ]
>
>
So long as the proposal doesn't make the above url_tree pattern impossible
(or harder to do) then I think it's a positive addition. (I have projects
which have very interesting urls patterns)
Best Regards, Martin Owens
Inkscape Website, django 1.8
On Monday, October 3, 2016 at 6:24:04 AM UTC-4, Tom Christie wrote:
>
> Hi folks,
>
> I wanted to push forward the consideration of introducing a simpler URLs
> syntax, plus support for URL parameter type conversion.
>
> A pre-proposal is available here:
> https://gist.github.com/tomchristie/cb388f0f6a0dec931c611775f32c5f98
>
> At this point I'm seeking feedback, before hopefully iterating on the
> proposal, and making a formal submission.
>
> I'm not making any assumptions right now about where this might get too,
> or who'd be involved if it does make it to the DEP stage, and would very
> much welcome outside involvement. I'm also aware that while there's been
> some positive reception, it's not yet clear if we'll reach a consensus on
> inclusion in core.
>
> Personally I'm very firmly +1 on this, as I feel that the existing syntax
> is a rather glaring and unnecessary pain point.
>
> Thanks to everyone who's started to kick this off, in particular Emil
> Stenström for raising the original thread, and Sjoerd Job Postmus for their
> work on the Django Simple URL
> <https://github.com/sjoerdjob/django-simple-url> package.
>
> - Tom
>
--
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/ab9eb20f-3d91-4a6f-9905-280909ba0abd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Cache invalidating with generic class based views
Dear django developers, I've had to develop a middleware piece for the django website inkscape.org, the website requires page caching for it's django-cms parts, but was suffering horribly from over-caching on non-cms pages. What I want to ask is, is a generic solution to generic class based views a crazy idea and if not, is it something that has already been done (hopefully better by someone)? You can see the middleware piece I've written here, designed for django 1.8: http://bazaar.launchpad.net/~inkscape-webadmin/inkscape-web/inkscape-web/revision/1214 The core of the idea is to record view cache keys against object and model ids and then invalidate those cache keys when that model is saved. There are a few non generic views that needed some extra code, and I imagine there could be views that use multiple objects or multiple querysets would need work to make it better. Best Regards, Martin Owens -- 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/20a5c7fe-e086-4990-9842-21653781a757%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Making Django more PaaS-friendly
I look after many different django websites and I'd like to add something
conceptual.
There is a difference between settings intended by developers to be used by
other developers in order to enable and configure their app's behaviour so
it work with other code. (I call these developer settings)
And settings used by systems administrators to define the environment they
are deployed to as well as any deployment specific controls. (I call these
sysadmin settings)
Django has always mixed the two into one file, and it causes problems. I've
seen keys and passwords committed to github, extravagant json or os.env
based solutions with piles of lines of messy code to what I see most which
is a local_settings.py with a template version which is copied in at
runtime with sane defaults.
I'd be happy to see a canonical decision made for django, but I'd focus on
"who should be editing this setting" not just what it's for, if it's a
secret or if it should be different or the same per instance.
Best regards, Martin Owens
On Monday, April 11, 2016 at 7:33:54 AM UTC+1, James Bennett wrote:
>
> Apologies for how late in the process this is; job hunt + moving
> cross-country ate a lot of my time.
>
> At Django Under the Hood I proposed that for Django 1.10 we try to find
> some common best practices for deploying Django on popular
> platform-as-a-service (PaaS) solutions, and building support for them into
> Django. The biggest one of these is probably having the ability to read
> configuration from environment variables instead of hard-coding things into
> settings files.
>
> At the very least I'd like to propose (assuming Kenneth is on board with
> it) integrating dj-database-url[1] or something like it directly into
> Django, so that there's no longer a third-party dependency for reading the
> database configuration from an environment variable. Whether this is just
> porting dj-database-url itself in, or making the DATABASES setting
> understand URLs, I'm unsure of yet and would be interested to hear feedback
> on. Either way I'm willing to put in the time to develop the patch.
>
> More generally, I'd like to see Django grow helpers for specifying
> settings that should be read from environment variables, and which
> environment variables to use (the email settings are another common case,
> as is anything that requires an API key to access).
>
> There are a few ways to design this. One option would be just a minimal
> wrapper around os.getenv, perhaps taking an optional type or type-coercing
> function, so that it would be possible in a settings file to do:
>
> SECRET_NUMBER_SETTING = env_setting('SECRET_NUMBER', int)
>
> However, this is not much better than the current practice of calling
> os.getenv. A better solution might be the ability to specify a group of
> settings which will be read from the environment, and have Django
> automatically read and set them. For example:
>
> ENV_SETTINGS = [
> ('SECRET_NUMBER_SETTING', int),
> ('ACME_API_KEY', str),
> ('VOLCANO_LAIR_PASSWORD', str),
> ]
>
> would read the named settings from those environment variables, and coerce
> them to the appropriate types using the function provided.
>
> The main problem with this is that it's really not very elegant. But at
> the moment I can't think of anything better, and so I'd like to throw the
> floor open to ideas on nicer approaches to this. If one can't be found, I
> do think Django 1.10 should at least figure out how to handle database
> config from env since that's such a common use case nowadays, but ideally
> we'd be able to pin down a good API for generically pulling configuration
> from the environment.
>
>
> [1] https://github.com/kennethreitz/dj-database-url
>
--
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/f0ff81bc-0eb0-476e-8741-6ba7e7db7926%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: #25227 Add utility method `get_updated_model()` to `ModelForm`
> Add utility method get_updated_model() to ModelForm > > I think the problem I have with the name here is that I often think of the Model as the class definition and not the instance object that the model makes. When I got passing around model classes like a mad django diva, I might get confused if I think get_updated_model might return a model class instead of an instance. Could we use something simple like 'update()' and 'commit()' to which save would call both? Martin Owens, -- 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 http://groups.google.com/group/django-developers. To view this discussion on the web visit https://groups.google.com/d/msgid/django-developers/614465a2-3dff-428e-97b5-7048fe9b23e4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
