Admin "modify-content" and "get-content" urls behaviour discrepancy

[NicoC]

Hi all !

I currently evaluating different Django-based CMS and so far yours
is the best. That said nothings ever perfect and I noticed a few
annoying things. The one that matters most to me is that there is a
discripency in the way the two following [1] URLs work:
/admin/pages/<page_id>/modify-content/<content_id>/<lang> and
/admin/pages/<page_id>/get-content/<content_id>/

With the first, I can use the placeholder name used in the template.
In the second I must use a number which I guess corresponds the
content model primary key. Would it be difficult to have both URLs
work the same way ? The first behaviour would have my preference, of
course :)

This is important to me because I really like the "on-site editing"
feature of django-page-cms, and this make "cancelling" editions a
pain, when it seems it could be so simple (and avoids having to "save"
the content of a placeholder prior edition) !!

On the ergonomy of the admin site: while editing a page, when I hit
the "save and continue editing" button, I always get back to the
"default language" translation of that page, not the one I was
editing. This is really annoying... but maybe a miss-configuration on
my side ?

Thanks, and keep up the great work.
Nicolas.

[1]: I did not test all admin URLs so maybe there are others that
behave like that.

[faden]

Hi,

You are right that content_id in those 2 function don't mean the same
thing. I think it should be fixed.
You would like to use the get-content to be able to cancel a change?
You could also do it in javascript by storing the previous value in a
variable and set it back when it's canceled.

For the ergonomy part you are correct. It's a old bug in Django that I
tried to fix many times but I never manage to make it commited to the
main repo:

http://code.djangoproject.com/ticket/12241

I don't know if any of the commiter care enough about this one. It's
obviouvously not gonna be in 1.3.

[Nicolas Caniart]

Le mercredi 19 janvier 2011 à 01:04 -0800, faden a écrit :
> Hi,
>
> You are right that content_id in those 2 function don't mean the same
> thing. I think it should be fixed.
> You would like to use the get-content to be able to cancel a change?
> You could also do it in javascript by storing the previous value in a
> variable and set it back when it's canceled.

What I'd like to achieve is to have complete on-site edition.

As I said I'd rather not do that. After all we have one trusted data
source (the database) so why not use it. I think it is "safer",
whatever changes are made, to get back directly to the source, whenever
it is decided to discard those changes.

Regarding what should be the content_id, I don't know why you set up
those two urls in the first place, but they surely look to be made to
allow on-site editing (to me at least). Hence, since the placeholder
name is what is available in the html page, I guess the best way to fix
the problem should be to use that as the content_id for the get-content
url (as well as for all other urls).

Another thing I noticed: when you change the template of a page, you
either see the content of one placeholder mapped to the one that has the
same name in the new template or lose its content. Would it be possible
to see a dialog open, offering to chose how placeholders are mapped to
one another ?

I'm not completely sure it makes sense with respect to the way the
underlying model works.... But I would see something like this: a list
of the previous placeholders on one side, a list for each placeholder in
the new template sided by a button. You then select one or more
placeholders from the previous template, click on the button on the side
of the new placeholder to put the selected content in that placeholder
of the new template.

+--------------------------------------+
| Old Placeholders | New Placeholders |
| +---------------+ | Body |
| | body | | +------------+ |
| |[content ]| | > | | |
| | | | +------------+ |
| | | | left col. |
| | | | +------------+ |
| | | | > | | |
| | | | +------------+ |
| | | | right col. |
| | | | +------------+ |
| | | | > | | |
| +---------------+ | +------------+ |
+--------------------------------------+

+--------------------------------------+
| Old Placeholders | New Placeholders |
| +---------------+ | Body |
| | body | | +------------+ |
| | | | > | | |
| | | | +------------+ |
| | | | left col. |
| | | | +------------+ |
| | | | > | | |
| | | | +------------+ |
| | | | right col. |
| | | | +------------+ |
| | | | > | content | |
| +---------------+ | +------------+ |
+--------------------------------------+

Of course one can imagine much fancier UI for that (drag'n'drop, 'live
preview', etc...) But something that works first would be great :)

>
> For the ergonomy part you are correct. It's a old bug in Django that I
> tried to fix many times but I never manage to make it commited to the
> main repo:
>
> http://code.djangoproject.com/ticket/12241
>
> I don't know if any of the commiter care enough about this one. It's
> obviouvously not gonna be in 1.3.

Maybe if (many) guys like me make bug reports, they'll eventually care !
I'll have a look at the ticket you mention.

Finally, to help keep track of these problem and feature wishes, would
you like me to file in bug reports, on your google code page ?

Thanks again,
Nicolas.

>
>
> On Jan 18, 5:53 pm, NicoC <nicolas.cani...@cemsi.eu> wrote:
> > Hi all !
> >

[...]

[faden]

On Jan 19, 4:16 pm, Nicolas Caniart <nicolas.cani...@cemsi.eu> wrote:
> Le mercredi 19 janvier 2011 à 01:04 -0800, faden a écrit :
>
> > Hi,
>
> > You are right that content_id in those 2 function don't mean the same
> > thing. I think it should be fixed.
> > You would like to use the get-content to be able to cancel a change?
> > You could also do it in javascript by storing the previous value in a
> > variable and set it back when it's canceled.
>
> What I'd like to achieve is to have complete on-site edition.
>
> As I said I'd rather not do that. After all we have one trusted data
> source (the database) so why not use it. I think it is "safer",
> whatever changes are made, to get back directly to the source, whenever
> it is decided to discard those changes.

Why not, the function needs to be fixed anyway.

I think I see what you mean there.

>
>
> > For the ergonomy part you are correct. It's a old bug in Django that I
> > tried to fix many times but I never manage to make it commited to the
> > main repo:
>
> >http://code.djangoproject.com/ticket/12241
>
> > I don't know if any of the commiter care enough about this one. It's
> > obviouvously not gonna be in 1.3.
>
> Maybe if (many) guys like me make bug reports, they'll eventually care !
> I'll have a look at the ticket you mention.
>
> Finally, to help keep track of these problem and feature wishes, would
> you like me to file in bug reports, on your google code page ?

You can the github page to create page to create the issues:

https://github.com/batiste/django-page-cms

I moved the project to github because it's easier to handle
contributions with it.
You should put your ideas there.

[faden]

Here is a fix for the content_id issue:

https://github.com/batiste/django-page-cms/commit/c261edff7b9bb866a8d11037d7c7c03e0cf8de79

Cheers