Update objects on class rename

classic Classic list List threaded Threaded
18 messages Options
Reply | Threaded
Open this post in threaded view
|

Update objects on class rename

Marius Dumitru Florea
Hi devs,

I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the page
rename job (from refactoring module) to update the existing objects when a
class is renamed *if the "Update links" options is checked*.

Of course, we could add a new option (e.g. "Update objects") but:

* it complicates the rename UI (too many options)
* I think most of the users understand the current "Update links" option as
"update the places where this page is *used*". I don't think it makes sense
to have separate options (at least at the UI level) for things like "Update
macro calls" or "Update image includes".
* I don't see why you would want to update the back-links but not the
objects (or the other way around).

If we agree on using a single option ("Update links") then the next
questions are:

* Is there a better name? I think "Update links" is a good name for simple
users so I would keep it. Another option is "Update references" but it has
a special meaning for XWiki developers.

* Should we update the hint for the "Update links" option? I think we
should, but only for advanced users, since they should be aware of the
implications of renaming a class. Simple users are not aware of the
existence of objects, most probably, so I wouldn't complicate their lives.

The final question is whether we should keep the rename job question about
classes. I think we should. The reason we added it is because renaming a
class is currently dangerous. Updating the objects makes it a bit less
dangerous because the data is preserved, but classes are often used in
scripts (e.g. a live table) and those scripts are not updated so there's a
high chance that something will not work correctly after the class rename.

WDYT?

Thanks,
Marius
Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

Ecaterina Moraru (Valica)
For simplicity reasons I agree that we could reuse the "Update links"
option to also apply it to updating the objects references.
The desired behavior is that XWiki will handle all the technical cases and
will help the users complete the rename as simple as possible.

The current UI for rename looks like this:
[image: rename.png]

Thanks,
Caty

On Wed, Jan 30, 2019 at 4:46 PM Marius Dumitru Florea <
[hidden email]> wrote:

> Hi devs,
>
> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the page
> rename job (from refactoring module) to update the existing objects when a
> class is renamed *if the "Update links" options is checked*.
>
> Of course, we could add a new option (e.g. "Update objects") but:
>
> * it complicates the rename UI (too many options)
> * I think most of the users understand the current "Update links" option as
> "update the places where this page is *used*". I don't think it makes sense
> to have separate options (at least at the UI level) for things like "Update
> macro calls" or "Update image includes".
> * I don't see why you would want to update the back-links but not the
> objects (or the other way around).
>
> If we agree on using a single option ("Update links") then the next
> questions are:
>
> * Is there a better name? I think "Update links" is a good name for simple
> users so I would keep it. Another option is "Update references" but it has
> a special meaning for XWiki developers.
>
> * Should we update the hint for the "Update links" option? I think we
> should, but only for advanced users, since they should be aware of the
> implications of renaming a class. Simple users are not aware of the
> existence of objects, most probably, so I wouldn't complicate their lives.
>
> The final question is whether we should keep the rename job question about
> classes. I think we should. The reason we added it is because renaming a
> class is currently dangerous. Updating the objects makes it a bit less
> dangerous because the data is preserved, but classes are often used in
> scripts (e.g. a live table) and those scripts are not updated so there's a
> high chance that something will not work correctly after the class rename.
>
> WDYT?
>
> Thanks,
> Marius
>

rename.png (253K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

Ecaterina Moraru (Valica)
In reply to this post by Marius Dumitru Florea
For simplicity reasons I agree that we could reuse the "Update links"
option to also apply it to updating the objects references.
The desired behavior is that XWiki will handle all the technical cases and
will help the users complete the rename as simple as possible.

Thanks,
Caty

On Wed, Jan 30, 2019 at 4:46 PM Marius Dumitru Florea <
[hidden email]> wrote:

> Hi devs,
>
> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the page
> rename job (from refactoring module) to update the existing objects when a
> class is renamed *if the "Update links" options is checked*.
>
> Of course, we could add a new option (e.g. "Update objects") but:
>
> * it complicates the rename UI (too many options)
> * I think most of the users understand the current "Update links" option as
> "update the places where this page is *used*". I don't think it makes sense
> to have separate options (at least at the UI level) for things like "Update
> macro calls" or "Update image includes".
> * I don't see why you would want to update the back-links but not the
> objects (or the other way around).
>
> If we agree on using a single option ("Update links") then the next
> questions are:
>
> * Is there a better name? I think "Update links" is a good name for simple
> users so I would keep it. Another option is "Update references" but it has
> a special meaning for XWiki developers.
>
> * Should we update the hint for the "Update links" option? I think we
> should, but only for advanced users, since they should be aware of the
> implications of renaming a class. Simple users are not aware of the
> existence of objects, most probably, so I wouldn't complicate their lives.
>
> The final question is whether we should keep the rename job question about
> classes. I think we should. The reason we added it is because renaming a
> class is currently dangerous. Updating the objects makes it a bit less
> dangerous because the data is preserved, but classes are often used in
> scripts (e.g. a live table) and those scripts are not updated so there's a
> high chance that something will not work correctly after the class rename.
>
> WDYT?
>
> Thanks,
> Marius
>
Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

Simon Urli
In reply to this post by Marius Dumitru Florea
Hi Marius,

On 30/01/2019 15:45, Marius Dumitru Florea wrote:

> Hi devs,
>
> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the page
> rename job (from refactoring module) to update the existing objects when a
> class is renamed *if the "Update links" options is checked*.
>
> Of course, we could add a new option (e.g. "Update objects") but:
>
> * it complicates the rename UI (too many options)
> * I think most of the users understand the current "Update links" option as
> "update the places where this page is *used*". I don't think it makes sense
> to have separate options (at least at the UI level) for things like "Update
> macro calls" or "Update image includes".
> * I don't see why you would want to update the back-links but not the
> objects (or the other way around).
>

I agree that the UI for final users should remain simple. Now on a dev
user point of view maybe it might worth it to distinguish the two
options in the RenameRequest.

> If we agree on using a single option ("Update links") then the next
> questions are:
>
> * Is there a better name? I think "Update links" is a good name for simple
> users so I would keep it. Another option is "Update references" but it has
> a special meaning for XWiki developers.
>
> * Should we update the hint for the "Update links" option? I think we
> should, but only for advanced users, since they should be aware of the
> implications of renaming a class. Simple users are not aware of the
> existence of objects, most probably, so I wouldn't complicate their lives.
>
> The final question is whether we should keep the rename job question about
> classes. I think we should. The reason we added it is because renaming a
> class is currently dangerous. Updating the objects makes it a bit less
> dangerous because the data is preserved, but classes are often used in
> scripts (e.g. a live table) and those scripts are not updated so there's a
> high chance that something will not work correctly after the class rename.
>
> WDYT?

I agree that the question should remain if we cannot guarantee that all
mentions of the classes are not renamed.

Simon
>
> Thanks,
> Marius
>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

Guillaume Delhumeau
Why can't we introduce an "Update objects" field, but only when the page
actually hold an XClass? It's not the main use-case. It's even quite rare a
end-user rename such a page. That would not complicate the UI that much 99%
of the times.

A warning could also be displayed, saying that it might break some
application (even when updating the XObjects, because the Velocity scripts
are not magically updated as well).

Le mer. 30 janv. 2019 à 16:55, Simon Urli <[hidden email]> a écrit :

> Hi Marius,
>
> On 30/01/2019 15:45, Marius Dumitru Florea wrote:
> > Hi devs,
> >
> > I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
> > https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the
> page
> > rename job (from refactoring module) to update the existing objects when
> a
> > class is renamed *if the "Update links" options is checked*.
> >
> > Of course, we could add a new option (e.g. "Update objects") but:
> >
> > * it complicates the rename UI (too many options)
> > * I think most of the users understand the current "Update links" option
> as
> > "update the places where this page is *used*". I don't think it makes
> sense
> > to have separate options (at least at the UI level) for things like
> "Update
> > macro calls" or "Update image includes".
> > * I don't see why you would want to update the back-links but not the
> > objects (or the other way around).
> >
>
> I agree that the UI for final users should remain simple. Now on a dev
> user point of view maybe it might worth it to distinguish the two
> options in the RenameRequest.
>
> > If we agree on using a single option ("Update links") then the next
> > questions are:
> >
> > * Is there a better name? I think "Update links" is a good name for
> simple
> > users so I would keep it. Another option is "Update references" but it
> has
> > a special meaning for XWiki developers.
> >
> > * Should we update the hint for the "Update links" option? I think we
> > should, but only for advanced users, since they should be aware of the
> > implications of renaming a class. Simple users are not aware of the
> > existence of objects, most probably, so I wouldn't complicate their
> lives.
> >
> > The final question is whether we should keep the rename job question
> about
> > classes. I think we should. The reason we added it is because renaming a
> > class is currently dangerous. Updating the objects makes it a bit less
> > dangerous because the data is preserved, but classes are often used in
> > scripts (e.g. a live table) and those scripts are not updated so there's
> a
> > high chance that something will not work correctly after the class
> rename.
> >
> > WDYT?
>
> I agree that the question should remain if we cannot guarantee that all
> mentions of the classes are not renamed.
>
> Simon
> >
> > Thanks,
> > Marius
> >
>
> --
> Simon Urli
> Software Engineer at XWiki SAS
> [hidden email]
> More about us at http://www.xwiki.com
>


--
Guillaume Delhumeau ([hidden email])
Research & Development Engineer at XWiki SAS
Committer on the XWiki.org project
Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

Simon Urli


On 30/01/2019 17:04, Guillaume Delhumeau wrote:
> Why can't we introduce an "Update objects" field, but only when the page
> actually hold an XClass? It's not the main use-case. It's even quite rare a
> end-user rename such a page. That would not complicate the UI that much 99%
> of the times.
>
> A warning could also be displayed, saying that it might break some
> application (even when updating the XObjects, because the Velocity scripts
> are not magically updated as well).

The users are already warned when renaming a page containing an XClass,
but it's displayed after the form, see:
https://www.xwiki.org/xwiki/bin/view/Documentation/UserGuide/Features/DocumentLifecycle/#HPagesthatcontainsanusedXClass-1

>
> Le mer. 30 janv. 2019 à 16:55, Simon Urli <[hidden email]> a écrit :
>
>> Hi Marius,
>>
>> On 30/01/2019 15:45, Marius Dumitru Florea wrote:
>>> Hi devs,
>>>
>>> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
>>> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the
>> page
>>> rename job (from refactoring module) to update the existing objects when
>> a
>>> class is renamed *if the "Update links" options is checked*.
>>>
>>> Of course, we could add a new option (e.g. "Update objects") but:
>>>
>>> * it complicates the rename UI (too many options)
>>> * I think most of the users understand the current "Update links" option
>> as
>>> "update the places where this page is *used*". I don't think it makes
>> sense
>>> to have separate options (at least at the UI level) for things like
>> "Update
>>> macro calls" or "Update image includes".
>>> * I don't see why you would want to update the back-links but not the
>>> objects (or the other way around).
>>>
>>
>> I agree that the UI for final users should remain simple. Now on a dev
>> user point of view maybe it might worth it to distinguish the two
>> options in the RenameRequest.
>>
>>> If we agree on using a single option ("Update links") then the next
>>> questions are:
>>>
>>> * Is there a better name? I think "Update links" is a good name for
>> simple
>>> users so I would keep it. Another option is "Update references" but it
>> has
>>> a special meaning for XWiki developers.
>>>
>>> * Should we update the hint for the "Update links" option? I think we
>>> should, but only for advanced users, since they should be aware of the
>>> implications of renaming a class. Simple users are not aware of the
>>> existence of objects, most probably, so I wouldn't complicate their
>> lives.
>>>
>>> The final question is whether we should keep the rename job question
>> about
>>> classes. I think we should. The reason we added it is because renaming a
>>> class is currently dangerous. Updating the objects makes it a bit less
>>> dangerous because the data is preserved, but classes are often used in
>>> scripts (e.g. a live table) and those scripts are not updated so there's
>> a
>>> high chance that something will not work correctly after the class
>> rename.
>>>
>>> WDYT?
>>
>> I agree that the question should remain if we cannot guarantee that all
>> mentions of the classes are not renamed.
>>
>> Simon
>>>
>>> Thanks,
>>> Marius
>>>
>>
>> --
>> Simon Urli
>> Software Engineer at XWiki SAS
>> [hidden email]
>> More about us at http://www.xwiki.com
>>
>
>

--
Simon Urli
Software Engineer at XWiki SAS
[hidden email]
More about us at http://www.xwiki.com
Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

Marius Dumitru Florea
In reply to this post by Guillaume Delhumeau
On Wed, Jan 30, 2019 at 6:04 PM Guillaume Delhumeau <
[hidden email]> wrote:

> Why can't we introduce an "Update objects" field, but only when the page
> actually hold an XClass? It's not the main use-case. It's even quite rare a
> end-user rename such a page. That would not complicate the UI that much 99%
> of the times.
>

Renaming directly a page that defines a class might be rare but renaming a
page that has a child page that defines a class is definitely not rare. So
you're suggesting to always update the objects when renaming the parent of
a class (with "Preserve child pages" on) but to allow the (advanced) users
to decide not to update the objects when renaming directly the class? Or
are you suggesting to use the "Update links" option when renaming the
parent of a class and the "Update objects" option when renaming directly
the class? I find both ways too complicated.


>
> A warning could also be displayed, saying that it might break some
> application (even when updating the XObjects, because the Velocity scripts
> are not magically updated as well).
>
> Le mer. 30 janv. 2019 à 16:55, Simon Urli <[hidden email]> a écrit :
>
> > Hi Marius,
> >
> > On 30/01/2019 15:45, Marius Dumitru Florea wrote:
> > > Hi devs,
> > >
> > > I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
> > > https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the
> > page
> > > rename job (from refactoring module) to update the existing objects
> when
> > a
> > > class is renamed *if the "Update links" options is checked*.
> > >
> > > Of course, we could add a new option (e.g. "Update objects") but:
> > >
> > > * it complicates the rename UI (too many options)
> > > * I think most of the users understand the current "Update links"
> option
> > as
> > > "update the places where this page is *used*". I don't think it makes
> > sense
> > > to have separate options (at least at the UI level) for things like
> > "Update
> > > macro calls" or "Update image includes".
> > > * I don't see why you would want to update the back-links but not the
> > > objects (or the other way around).
> > >
> >
> > I agree that the UI for final users should remain simple. Now on a dev
> > user point of view maybe it might worth it to distinguish the two
> > options in the RenameRequest.
> >
> > > If we agree on using a single option ("Update links") then the next
> > > questions are:
> > >
> > > * Is there a better name? I think "Update links" is a good name for
> > simple
> > > users so I would keep it. Another option is "Update references" but it
> > has
> > > a special meaning for XWiki developers.
> > >
> > > * Should we update the hint for the "Update links" option? I think we
> > > should, but only for advanced users, since they should be aware of the
> > > implications of renaming a class. Simple users are not aware of the
> > > existence of objects, most probably, so I wouldn't complicate their
> > lives.
> > >
> > > The final question is whether we should keep the rename job question
> > about
> > > classes. I think we should. The reason we added it is because renaming
> a
> > > class is currently dangerous. Updating the objects makes it a bit less
> > > dangerous because the data is preserved, but classes are often used in
> > > scripts (e.g. a live table) and those scripts are not updated so
> there's
> > a
> > > high chance that something will not work correctly after the class
> > rename.
> > >
> > > WDYT?
> >
> > I agree that the question should remain if we cannot guarantee that all
> > mentions of the classes are not renamed.
> >
> > Simon
> > >
> > > Thanks,
> > > Marius
> > >
> >
> > --
> > Simon Urli
> > Software Engineer at XWiki SAS
> > [hidden email]
> > More about us at http://www.xwiki.com
> >
>
>
> --
> Guillaume Delhumeau ([hidden email])
> Research & Development Engineer at XWiki SAS
> Committer on the XWiki.org project
>
Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

Thomas Mortagne
Administrator
In reply to this post by Marius Dumitru Florea
On Wed, Jan 30, 2019 at 3:46 PM Marius Dumitru Florea
<[hidden email]> wrote:

>
> Hi devs,
>
> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the page
> rename job (from refactoring module) to update the existing objects when a
> class is renamed *if the "Update links" options is checked*.
>
> Of course, we could add a new option (e.g. "Update objects") but:
>
> * it complicates the rename UI (too many options)
> * I think most of the users understand the current "Update links" option as
> "update the places where this page is *used*". I don't think it makes sense
> to have separate options (at least at the UI level) for things like "Update
> macro calls" or "Update image includes".
> * I don't see why you would want to update the back-links but not the
> objects (or the other way around).

+1 for single option

>
> If we agree on using a single option ("Update links") then the next
> questions are:
>
> * Is there a better name? I think "Update links" is a good name for simple
> users so I would keep it. Another option is "Update references" but it has
> a special meaning for XWiki developers.
>
> * Should we update the hint for the "Update links" option? I think we
> should, but only for advanced users, since they should be aware of the
> implications of renaming a class. Simple users are not aware of the
> existence of objects, most probably, so I wouldn't complicate their lives.

+1 for update the hint, maybe reword it a bit to make clear is not
just about wiki links without entering too much in the details

>
> The final question is whether we should keep the rename job question about
> classes. I think we should. The reason we added it is because renaming a
> class is currently dangerous. Updating the objects makes it a bit less
> dangerous because the data is preserved, but classes are often used in
> scripts (e.g. a live table) and those scripts are not updated so there's a
> high chance that something will not work correctly after the class rename.

+1, object/class almost always imply that some code is manipulating
them it's not going to be fixed so the risk is still the same level
for me

>
> WDYT?
>
> Thanks,
> Marius



--
Thomas Mortagne
Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

vmassol
Administrator
In reply to this post by Marius Dumitru Florea
Hi Marius/all,

> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <[hidden email]> wrote:
>
> Hi devs,
>
> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the page
> rename job (from refactoring module) to update the existing objects when a
> class is renamed *if the "Update links" options is checked*.
>
> Of course, we could add a new option (e.g. "Update objects") but:
>
> * it complicates the rename UI (too many options)
> * I think most of the users understand the current "Update links" option as
> "update the places where this page is *used*". I don't think it makes sense
> to have separate options (at least at the UI level) for things like "Update
> macro calls" or "Update image includes".
> * I don't see why you would want to update the back-links but not the
> objects (or the other way around).

Sounds good to me in general.

> If we agree on using a single option ("Update links") then the next
> questions are:
>
> * Is there a better name? I think "Update links" is a good name for simple
> users so I would keep it. Another option is "Update references" but it has
> a special meaning for XWiki developers.

Maybe "Update other pages” with a hint saying “Ensure that other pages using the renamed pages continue to work after the rename”.

?

>
> * Should we update the hint for the "Update links" option? I think we
> should, but only for advanced users, since they should be aware of the
> implications of renaming a class. Simple users are not aware of the
> existence of objects, most probably, so I wouldn't complicate their lives.

Would be nicer to find a single message that work for everyone but I agree it’s not easy if we wish to provide details.

I feel a nicer option would be to NOT show “Update other pages” for simple users since that should always be checked. Only offer the ability to uncheck it for advanced users and this solves the hint issue too :)

> The final question is whether we should keep the rename job question about
> classes. I think we should. The reason we added it is because renaming a
> class is currently dangerous. Updating the objects makes it a bit less
> dangerous because the data is preserved, but classes are often used in
> scripts (e.g. a live table) and those scripts are not updated so there's a
> high chance that something will not work correctly after the class rename.

Sounds good.

Thanks
-Vincent

>
> WDYT?
>
> Thanks,
> Marius

Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

vmassol
Administrator
Hi Marius/All,

See below

> On 31 Jan 2019, at 11:29, Vincent Massol <[hidden email]> wrote:
>
> Hi Marius/all,
>
>> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <[hidden email]> wrote:
>>
>> Hi devs,
>>
>> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
>> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the page
>> rename job (from refactoring module) to update the existing objects when a
>> class is renamed *if the "Update links" options is checked*.
>>
>> Of course, we could add a new option (e.g. "Update objects") but:
>>
>> * it complicates the rename UI (too many options)
>> * I think most of the users understand the current "Update links" option as
>> "update the places where this page is *used*". I don't think it makes sense
>> to have separate options (at least at the UI level) for things like "Update
>> macro calls" or "Update image includes".
>> * I don't see why you would want to update the back-links but not the
>> objects (or the other way around).
>
> Sounds good to me in general.
>
>> If we agree on using a single option ("Update links") then the next
>> questions are:
>>
>> * Is there a better name? I think "Update links" is a good name for simple
>> users so I would keep it. Another option is "Update references" but it has
>> a special meaning for XWiki developers.
>
> Maybe "Update other pages” with a hint saying “Ensure that other pages using the renamed pages continue to work after the rename”.
>
> ?
>
>>
>> * Should we update the hint for the "Update links" option? I think we
>> should, but only for advanced users, since they should be aware of the
>> implications of renaming a class. Simple users are not aware of the
>> existence of objects, most probably, so I wouldn't complicate their lives.
>
> Would be nicer to find a single message that work for everyone but I agree it’s not easy if we wish to provide details.
>
> I feel a nicer option would be to NOT show “Update other pages” for simple users since that should always be checked. Only offer the ability to uncheck it for advanced users and this solves the hint issue too :)

Nobody replied to this proposal but I really find it the best by far and it solves your other questions too while making the UI simpler globally.

WDYT?

Thanks
-Vincent

[snip]

Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

Marius Dumitru Florea
On Fri, Feb 8, 2019 at 9:52 AM Vincent Massol <[hidden email]> wrote:

> Hi Marius/All,
>
> See below
>
> > On 31 Jan 2019, at 11:29, Vincent Massol <[hidden email]> wrote:
> >
> > Hi Marius/all,
> >
> >> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <
> [hidden email]> wrote:
> >>
> >> Hi devs,
> >>
> >> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
> >> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the
> page
> >> rename job (from refactoring module) to update the existing objects
> when a
> >> class is renamed *if the "Update links" options is checked*.
> >>
> >> Of course, we could add a new option (e.g. "Update objects") but:
> >>
> >> * it complicates the rename UI (too many options)
> >> * I think most of the users understand the current "Update links"
> option as
> >> "update the places where this page is *used*". I don't think it makes
> sense
> >> to have separate options (at least at the UI level) for things like
> "Update
> >> macro calls" or "Update image includes".
> >> * I don't see why you would want to update the back-links but not the
> >> objects (or the other way around).
> >
> > Sounds good to me in general.
> >
> >> If we agree on using a single option ("Update links") then the next
> >> questions are:
> >>
> >> * Is there a better name? I think "Update links" is a good name for
> simple
> >> users so I would keep it. Another option is "Update references" but it
> has
> >> a special meaning for XWiki developers.
> >
> > Maybe "Update other pages” with a hint saying “Ensure that other pages
> using the renamed pages continue to work after the rename”.
> >
> > ?
> >
> >>
> >> * Should we update the hint for the "Update links" option? I think we
> >> should, but only for advanced users, since they should be aware of the
> >> implications of renaming a class. Simple users are not aware of the
> >> existence of objects, most probably, so I wouldn't complicate their
> lives.
> >
> > Would be nicer to find a single message that work for everyone but I
> agree it’s not easy if we wish to provide details.
> >
> > I feel a nicer option would be to NOT show “Update other pages” for
> simple users since that should always be checked. Only offer the ability to
> uncheck it for advanced users and this solves the hint issue too :)
>
>

> Nobody replied to this proposal but I really find it the best by far and
> it solves your other questions too while making the UI simpler globally.
>

The only issue I see with this option is that by hiding the "Update Links"
the simple users might not be aware of the side effects of the rename
operation: the fact that other pages will have to be updated. Seeing that a
page you want to rename is referenced in many places can make you think
twice about the rename.

Now, the current hint for "Update Links" doesn't indicate all the side
effects. For instance it indicates the number of back-links to the page
you're trying to rename but it *doesn't include back-links to child pages*
(when child pages are preserved). So what I said above it not really true
ATM either.

Thanks,
Marius


>
> WDYT?
>
> Thanks
> -Vincent
>
> [snip]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

vmassol
Administrator


> On 8 Feb 2019, at 09:20, Marius Dumitru Florea <[hidden email]> wrote:
>
> On Fri, Feb 8, 2019 at 9:52 AM Vincent Massol <[hidden email]> wrote:
>
>> Hi Marius/All,
>>
>> See below
>>
>>> On 31 Jan 2019, at 11:29, Vincent Massol <[hidden email]> wrote:
>>>
>>> Hi Marius/all,
>>>
>>>> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <
>> [hidden email]> wrote:
>>>>
>>>> Hi devs,
>>>>
>>>> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it for
>>>> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the
>> page
>>>> rename job (from refactoring module) to update the existing objects
>> when a
>>>> class is renamed *if the "Update links" options is checked*.
>>>>
>>>> Of course, we could add a new option (e.g. "Update objects") but:
>>>>
>>>> * it complicates the rename UI (too many options)
>>>> * I think most of the users understand the current "Update links"
>> option as
>>>> "update the places where this page is *used*". I don't think it makes
>> sense
>>>> to have separate options (at least at the UI level) for things like
>> "Update
>>>> macro calls" or "Update image includes".
>>>> * I don't see why you would want to update the back-links but not the
>>>> objects (or the other way around).
>>>
>>> Sounds good to me in general.
>>>
>>>> If we agree on using a single option ("Update links") then the next
>>>> questions are:
>>>>
>>>> * Is there a better name? I think "Update links" is a good name for
>> simple
>>>> users so I would keep it. Another option is "Update references" but it
>> has
>>>> a special meaning for XWiki developers.
>>>
>>> Maybe "Update other pages” with a hint saying “Ensure that other pages
>> using the renamed pages continue to work after the rename”.
>>>
>>> ?
>>>
>>>>
>>>> * Should we update the hint for the "Update links" option? I think we
>>>> should, but only for advanced users, since they should be aware of the
>>>> implications of renaming a class. Simple users are not aware of the
>>>> existence of objects, most probably, so I wouldn't complicate their
>> lives.
>>>
>>> Would be nicer to find a single message that work for everyone but I
>> agree it’s not easy if we wish to provide details.
>>>
>>> I feel a nicer option would be to NOT show “Update other pages” for
>> simple users since that should always be checked. Only offer the ability to
>> uncheck it for advanced users and this solves the hint issue too :)
>>
>>
>
>> Nobody replied to this proposal but I really find it the best by far and
>> it solves your other questions too while making the UI simpler globally.
>>
>
> The only issue I see with this option is that by hiding the "Update Links"
> the simple users might not be aware of the side effects of the rename
> operation: the fact that other pages will have to be updated. Seeing that a
> page you want to rename is referenced in many places can make you think
> twice about the rename.

We could keep that info, it could be useful indeed.

I was referring to hiding the option (the checkbox). This makes the UI simpler to use for simple user, which is the direction we want to go and I cannot find tons of reasons why simple users would want to not fix links… Actually in the past all issues that were raised were the opposite, users who didn’t check the box, and then we made it checked by default.

> Now, the current hint for "Update Links" doesn't indicate all the side
> effects. For instance it indicates the number of back-links to the page
> you're trying to rename but it *doesn't include back-links to child pages*
> (when child pages are preserved). So what I said above it not really true
> ATM either.

Yes, it’s actually worse in a sense :) Right now it makes it seem as if it’ll work perfectly well…

Thanks
-Vincent

>
> Thanks,
> Marius
>
>
>>
>> WDYT?
>>
>> Thanks
>> -Vincent
>>
>> [snip]

Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

Marius Dumitru Florea
On Fri, Feb 8, 2019 at 10:25 AM Vincent Massol <[hidden email]> wrote:

>
>
> > On 8 Feb 2019, at 09:20, Marius Dumitru Florea <
> [hidden email]> wrote:
> >
> > On Fri, Feb 8, 2019 at 9:52 AM Vincent Massol <[hidden email]>
> wrote:
> >
> >> Hi Marius/All,
> >>
> >> See below
> >>
> >>> On 31 Jan 2019, at 11:29, Vincent Massol <[hidden email]> wrote:
> >>>
> >>> Hi Marius/all,
> >>>
> >>>> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <
> >> [hidden email]> wrote:
> >>>>
> >>>> Hi devs,
> >>>>
> >>>> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it
> for
> >>>> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the
> >> page
> >>>> rename job (from refactoring module) to update the existing objects
> >> when a
> >>>> class is renamed *if the "Update links" options is checked*.
> >>>>
> >>>> Of course, we could add a new option (e.g. "Update objects") but:
> >>>>
> >>>> * it complicates the rename UI (too many options)
> >>>> * I think most of the users understand the current "Update links"
> >> option as
> >>>> "update the places where this page is *used*". I don't think it makes
> >> sense
> >>>> to have separate options (at least at the UI level) for things like
> >> "Update
> >>>> macro calls" or "Update image includes".
> >>>> * I don't see why you would want to update the back-links but not the
> >>>> objects (or the other way around).
> >>>
> >>> Sounds good to me in general.
> >>>
> >>>> If we agree on using a single option ("Update links") then the next
> >>>> questions are:
> >>>>
> >>>> * Is there a better name? I think "Update links" is a good name for
> >> simple
> >>>> users so I would keep it. Another option is "Update references" but it
> >> has
> >>>> a special meaning for XWiki developers.
> >>>
> >>> Maybe "Update other pages” with a hint saying “Ensure that other pages
> >> using the renamed pages continue to work after the rename”.
> >>>
> >>> ?
> >>>
> >>>>
> >>>> * Should we update the hint for the "Update links" option? I think we
> >>>> should, but only for advanced users, since they should be aware of the
> >>>> implications of renaming a class. Simple users are not aware of the
> >>>> existence of objects, most probably, so I wouldn't complicate their
> >> lives.
> >>>
> >>> Would be nicer to find a single message that work for everyone but I
> >> agree it’s not easy if we wish to provide details.
> >>>
> >>> I feel a nicer option would be to NOT show “Update other pages” for
> >> simple users since that should always be checked. Only offer the
> ability to
> >> uncheck it for advanced users and this solves the hint issue too :)
> >>
> >>
> >
> >> Nobody replied to this proposal but I really find it the best by far and
> >> it solves your other questions too while making the UI simpler globally.
> >>
> >
> > The only issue I see with this option is that by hiding the "Update
> Links"
> > the simple users might not be aware of the side effects of the rename
> > operation: the fact that other pages will have to be updated. Seeing
> that a
> > page you want to rename is referenced in many places can make you think
> > twice about the rename.
>
>

> We could keep that info, it could be useful indeed.
>

I can keep the message but then I'll probably need to display different
messages for simple and advanced users. Moreover, ideally the message
should be updated whenever the Preserve Children checkbox is clicked (e.g.
to indicate that there are more pages to update if the child pages are
preserved).


>
> I was referring to hiding the option (the checkbox). This makes the UI
> simpler to use for simple user, which is the direction we want to go and I
> cannot find tons of reasons why simple users would want to not fix links…
> Actually in the past all issues that were raised were the opposite, users
> who didn’t check the box, and then we made it checked by default.
>
> > Now, the current hint for "Update Links" doesn't indicate all the side
> > effects. For instance it indicates the number of back-links to the page
> > you're trying to rename but it *doesn't include back-links to child
> pages*
> > (when child pages are preserved). So what I said above it not really true
> > ATM either.
>
> Yes, it’s actually worse in a sense :) Right now it makes it seem as if
> it’ll work perfectly well…
>
> Thanks
> -Vincent
>
> >
> > Thanks,
> > Marius
> >
> >
> >>
> >> WDYT?
> >>
> >> Thanks
> >> -Vincent
> >>
> >> [snip]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

vmassol
Administrator


> On 8 Feb 2019, at 12:45, Marius Dumitru Florea <[hidden email]> wrote:
>
> On Fri, Feb 8, 2019 at 10:25 AM Vincent Massol <[hidden email]> wrote:
>
>>
>>
>>> On 8 Feb 2019, at 09:20, Marius Dumitru Florea <
>> [hidden email]> wrote:
>>>
>>> On Fri, Feb 8, 2019 at 9:52 AM Vincent Massol <[hidden email]>
>> wrote:
>>>
>>>> Hi Marius/All,
>>>>
>>>> See below
>>>>
>>>>> On 31 Jan 2019, at 11:29, Vincent Massol <[hidden email]> wrote:
>>>>>
>>>>> Hi Marius/all,
>>>>>
>>>>>> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <
>>>> [hidden email]> wrote:
>>>>>>
>>>>>> Hi devs,
>>>>>>
>>>>>> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it
>> for
>>>>>> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change the
>>>> page
>>>>>> rename job (from refactoring module) to update the existing objects
>>>> when a
>>>>>> class is renamed *if the "Update links" options is checked*.
>>>>>>
>>>>>> Of course, we could add a new option (e.g. "Update objects") but:
>>>>>>
>>>>>> * it complicates the rename UI (too many options)
>>>>>> * I think most of the users understand the current "Update links"
>>>> option as
>>>>>> "update the places where this page is *used*". I don't think it makes
>>>> sense
>>>>>> to have separate options (at least at the UI level) for things like
>>>> "Update
>>>>>> macro calls" or "Update image includes".
>>>>>> * I don't see why you would want to update the back-links but not the
>>>>>> objects (or the other way around).
>>>>>
>>>>> Sounds good to me in general.
>>>>>
>>>>>> If we agree on using a single option ("Update links") then the next
>>>>>> questions are:
>>>>>>
>>>>>> * Is there a better name? I think "Update links" is a good name for
>>>> simple
>>>>>> users so I would keep it. Another option is "Update references" but it
>>>> has
>>>>>> a special meaning for XWiki developers.
>>>>>
>>>>> Maybe "Update other pages” with a hint saying “Ensure that other pages
>>>> using the renamed pages continue to work after the rename”.
>>>>>
>>>>> ?
>>>>>
>>>>>>
>>>>>> * Should we update the hint for the "Update links" option? I think we
>>>>>> should, but only for advanced users, since they should be aware of the
>>>>>> implications of renaming a class. Simple users are not aware of the
>>>>>> existence of objects, most probably, so I wouldn't complicate their
>>>> lives.
>>>>>
>>>>> Would be nicer to find a single message that work for everyone but I
>>>> agree it’s not easy if we wish to provide details.
>>>>>
>>>>> I feel a nicer option would be to NOT show “Update other pages” for
>>>> simple users since that should always be checked. Only offer the
>> ability to
>>>> uncheck it for advanced users and this solves the hint issue too :)
>>>>
>>>>
>>>
>>>> Nobody replied to this proposal but I really find it the best by far and
>>>> it solves your other questions too while making the UI simpler globally.
>>>>
>>>
>>> The only issue I see with this option is that by hiding the "Update
>> Links"
>>> the simple users might not be aware of the side effects of the rename
>>> operation: the fact that other pages will have to be updated. Seeing
>> that a
>>> page you want to rename is referenced in many places can make you think
>>> twice about the rename.
>>
>>
>
>> We could keep that info, it could be useful indeed.
>>
>
> I can keep the message but then I'll probably need to display different
> messages for simple and advanced users. Moreover, ideally the message
> should be updated whenever the Preserve Children checkbox is clicked (e.g.
> to indicate that there are more pages to update if the child pages are
> preserved).

By messages I meant to indicate (as information) the number of links leading to the renamed pages.

For me this is the same info whether you’re simple or advanced, no? OTOH the checkbox for advanced users could provide additional info as hint.

Or we just don’t display this message at all for simple users. I wouldn’t mind either. Makes it simpler in practice :)

Thanks
-Vincent


>
>
>>
>> I was referring to hiding the option (the checkbox). This makes the UI
>> simpler to use for simple user, which is the direction we want to go and I
>> cannot find tons of reasons why simple users would want to not fix links…
>> Actually in the past all issues that were raised were the opposite, users
>> who didn’t check the box, and then we made it checked by default.
>>
>>> Now, the current hint for "Update Links" doesn't indicate all the side
>>> effects. For instance it indicates the number of back-links to the page
>>> you're trying to rename but it *doesn't include back-links to child
>> pages*
>>> (when child pages are preserved). So what I said above it not really true
>>> ATM either.
>>
>> Yes, it’s actually worse in a sense :) Right now it makes it seem as if
>> it’ll work perfectly well…
>>
>> Thanks
>> -Vincent
>>
>>>
>>> Thanks,
>>> Marius
>>>
>>>
>>>>
>>>> WDYT?
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>> [snip]

Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

Marius Dumitru Florea
On Fri, Feb 8, 2019 at 1:51 PM Vincent Massol <[hidden email]> wrote:

>
>
> > On 8 Feb 2019, at 12:45, Marius Dumitru Florea <
> [hidden email]> wrote:
> >
> > On Fri, Feb 8, 2019 at 10:25 AM Vincent Massol <[hidden email]>
> wrote:
> >
> >>
> >>
> >>> On 8 Feb 2019, at 09:20, Marius Dumitru Florea <
> >> [hidden email]> wrote:
> >>>
> >>> On Fri, Feb 8, 2019 at 9:52 AM Vincent Massol <[hidden email]>
> >> wrote:
> >>>
> >>>> Hi Marius/All,
> >>>>
> >>>> See below
> >>>>
> >>>>> On 31 Jan 2019, at 11:29, Vincent Massol <[hidden email]> wrote:
> >>>>>
> >>>>> Hi Marius/all,
> >>>>>
> >>>>>> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <
> >>>> [hidden email]> wrote:
> >>>>>>
> >>>>>> Hi devs,
> >>>>>>
> >>>>>> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it
> >> for
> >>>>>> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change
> the
> >>>> page
> >>>>>> rename job (from refactoring module) to update the existing objects
> >>>> when a
> >>>>>> class is renamed *if the "Update links" options is checked*.
> >>>>>>
> >>>>>> Of course, we could add a new option (e.g. "Update objects") but:
> >>>>>>
> >>>>>> * it complicates the rename UI (too many options)
> >>>>>> * I think most of the users understand the current "Update links"
> >>>> option as
> >>>>>> "update the places where this page is *used*". I don't think it
> makes
> >>>> sense
> >>>>>> to have separate options (at least at the UI level) for things like
> >>>> "Update
> >>>>>> macro calls" or "Update image includes".
> >>>>>> * I don't see why you would want to update the back-links but not
> the
> >>>>>> objects (or the other way around).
> >>>>>
> >>>>> Sounds good to me in general.
> >>>>>
> >>>>>> If we agree on using a single option ("Update links") then the next
> >>>>>> questions are:
> >>>>>>
> >>>>>> * Is there a better name? I think "Update links" is a good name for
> >>>> simple
> >>>>>> users so I would keep it. Another option is "Update references" but
> it
> >>>> has
> >>>>>> a special meaning for XWiki developers.
> >>>>>
> >>>>> Maybe "Update other pages” with a hint saying “Ensure that other
> pages
> >>>> using the renamed pages continue to work after the rename”.
> >>>>>
> >>>>> ?
> >>>>>
> >>>>>>
> >>>>>> * Should we update the hint for the "Update links" option? I think
> we
> >>>>>> should, but only for advanced users, since they should be aware of
> the
> >>>>>> implications of renaming a class. Simple users are not aware of the
> >>>>>> existence of objects, most probably, so I wouldn't complicate their
> >>>> lives.
> >>>>>
> >>>>> Would be nicer to find a single message that work for everyone but I
> >>>> agree it’s not easy if we wish to provide details.
> >>>>>
> >>>>> I feel a nicer option would be to NOT show “Update other pages” for
> >>>> simple users since that should always be checked. Only offer the
> >> ability to
> >>>> uncheck it for advanced users and this solves the hint issue too :)
> >>>>
> >>>>
> >>>
> >>>> Nobody replied to this proposal but I really find it the best by far
> and
> >>>> it solves your other questions too while making the UI simpler
> globally.
> >>>>
> >>>
> >>> The only issue I see with this option is that by hiding the "Update
> >> Links"
> >>> the simple users might not be aware of the side effects of the rename
> >>> operation: the fact that other pages will have to be updated. Seeing
> >> that a
> >>> page you want to rename is referenced in many places can make you think
> >>> twice about the rename.
> >>
> >>
> >
> >> We could keep that info, it could be useful indeed.
> >>
> >
> > I can keep the message but then I'll probably need to display different
> > messages for simple and advanced users. Moreover, ideally the message
> > should be updated whenever the Preserve Children checkbox is clicked
> (e.g.
> > to indicate that there are more pages to update if the child pages are
> > preserved).
>
>

> By messages I meant to indicate (as information) the number of links
> leading to the renamed pages.
>

Sure, but it's not just links. There's also xobjects of a class that is
among those pages being renamed. There are two options:

* show a single number (e.g. "There are *10 other pages* that are going to
be updated because they are referencing the pages that are being renamed")
. The issue here is de-duplication: if you simply sum up the backlinks +
xobjects + etc. then you can have pages counted multiple times... Moreover,
we would need to provide a link to a view showing these other pages (as we
have for backlinks right now), and having a unified backlinks + xobjects +
etc. is complex.

* show multiple numbers (i.e. "There are 4 pages that have links to the
pages being renamed. There are 7 pages with xobjects defined by classes
that are going to be renamed. etc.")


>
> For me this is the same info whether you’re simple or advanced, no? OTOH
> the checkbox for advanced users could provide additional info as hint.
>
> Or we just don’t display this message at all for simple users. I wouldn’t
> mind either. Makes it simpler in practice :)
>
> Thanks
> -Vincent
>
>
> >
> >
> >>
> >> I was referring to hiding the option (the checkbox). This makes the UI
> >> simpler to use for simple user, which is the direction we want to go
> and I
> >> cannot find tons of reasons why simple users would want to not fix
> links…
> >> Actually in the past all issues that were raised were the opposite,
> users
> >> who didn’t check the box, and then we made it checked by default.
> >>
> >>> Now, the current hint for "Update Links" doesn't indicate all the side
> >>> effects. For instance it indicates the number of back-links to the page
> >>> you're trying to rename but it *doesn't include back-links to child
> >> pages*
> >>> (when child pages are preserved). So what I said above it not really
> true
> >>> ATM either.
> >>
> >> Yes, it’s actually worse in a sense :) Right now it makes it seem as if
> >> it’ll work perfectly well…
> >>
> >> Thanks
> >> -Vincent
> >>
> >>>
> >>> Thanks,
> >>> Marius
> >>>
> >>>
> >>>>
> >>>> WDYT?
> >>>>
> >>>> Thanks
> >>>> -Vincent
> >>>>
> >>>> [snip]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

vmassol
Administrator


> On 8 Feb 2019, at 14:00, Marius Dumitru Florea <[hidden email]> wrote:
>
> On Fri, Feb 8, 2019 at 1:51 PM Vincent Massol <[hidden email]> wrote:
>
>>
>>
>>> On 8 Feb 2019, at 12:45, Marius Dumitru Florea <
>> [hidden email]> wrote:
>>>
>>> On Fri, Feb 8, 2019 at 10:25 AM Vincent Massol <[hidden email]>
>> wrote:
>>>
>>>>
>>>>
>>>>> On 8 Feb 2019, at 09:20, Marius Dumitru Florea <
>>>> [hidden email]> wrote:
>>>>>
>>>>> On Fri, Feb 8, 2019 at 9:52 AM Vincent Massol <[hidden email]>
>>>> wrote:
>>>>>
>>>>>> Hi Marius/All,
>>>>>>
>>>>>> See below
>>>>>>
>>>>>>> On 31 Jan 2019, at 11:29, Vincent Massol <[hidden email]> wrote:
>>>>>>>
>>>>>>> Hi Marius/all,
>>>>>>>
>>>>>>>> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <
>>>>>> [hidden email]> wrote:
>>>>>>>>
>>>>>>>> Hi devs,
>>>>>>>>
>>>>>>>> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need it
>>>> for
>>>>>>>> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change
>> the
>>>>>> page
>>>>>>>> rename job (from refactoring module) to update the existing objects
>>>>>> when a
>>>>>>>> class is renamed *if the "Update links" options is checked*.
>>>>>>>>
>>>>>>>> Of course, we could add a new option (e.g. "Update objects") but:
>>>>>>>>
>>>>>>>> * it complicates the rename UI (too many options)
>>>>>>>> * I think most of the users understand the current "Update links"
>>>>>> option as
>>>>>>>> "update the places where this page is *used*". I don't think it
>> makes
>>>>>> sense
>>>>>>>> to have separate options (at least at the UI level) for things like
>>>>>> "Update
>>>>>>>> macro calls" or "Update image includes".
>>>>>>>> * I don't see why you would want to update the back-links but not
>> the
>>>>>>>> objects (or the other way around).
>>>>>>>
>>>>>>> Sounds good to me in general.
>>>>>>>
>>>>>>>> If we agree on using a single option ("Update links") then the next
>>>>>>>> questions are:
>>>>>>>>
>>>>>>>> * Is there a better name? I think "Update links" is a good name for
>>>>>> simple
>>>>>>>> users so I would keep it. Another option is "Update references" but
>> it
>>>>>> has
>>>>>>>> a special meaning for XWiki developers.
>>>>>>>
>>>>>>> Maybe "Update other pages” with a hint saying “Ensure that other
>> pages
>>>>>> using the renamed pages continue to work after the rename”.
>>>>>>>
>>>>>>> ?
>>>>>>>
>>>>>>>>
>>>>>>>> * Should we update the hint for the "Update links" option? I think
>> we
>>>>>>>> should, but only for advanced users, since they should be aware of
>> the
>>>>>>>> implications of renaming a class. Simple users are not aware of the
>>>>>>>> existence of objects, most probably, so I wouldn't complicate their
>>>>>> lives.
>>>>>>>
>>>>>>> Would be nicer to find a single message that work for everyone but I
>>>>>> agree it’s not easy if we wish to provide details.
>>>>>>>
>>>>>>> I feel a nicer option would be to NOT show “Update other pages” for
>>>>>> simple users since that should always be checked. Only offer the
>>>> ability to
>>>>>> uncheck it for advanced users and this solves the hint issue too :)
>>>>>>
>>>>>>
>>>>>
>>>>>> Nobody replied to this proposal but I really find it the best by far
>> and
>>>>>> it solves your other questions too while making the UI simpler
>> globally.
>>>>>>
>>>>>
>>>>> The only issue I see with this option is that by hiding the "Update
>>>> Links"
>>>>> the simple users might not be aware of the side effects of the rename
>>>>> operation: the fact that other pages will have to be updated. Seeing
>>>> that a
>>>>> page you want to rename is referenced in many places can make you think
>>>>> twice about the rename.
>>>>
>>>>
>>>
>>>> We could keep that info, it could be useful indeed.
>>>>
>>>
>>> I can keep the message but then I'll probably need to display different
>>> messages for simple and advanced users. Moreover, ideally the message
>>> should be updated whenever the Preserve Children checkbox is clicked
>> (e.g.
>>> to indicate that there are more pages to update if the child pages are
>>> preserved).
>>
>>
>
>> By messages I meant to indicate (as information) the number of links
>> leading to the renamed pages.
>>
>
> Sure, but it's not just links. There's also xobjects of a class that is
> among those pages being renamed. There are two options:
>
> * show a single number (e.g. "There are *10 other pages* that are going to
> be updated because they are referencing the pages that are being renamed")
> . The issue here is de-duplication: if you simply sum up the backlinks +
> xobjects + etc. then you can have pages counted multiple times... Moreover,
> we would need to provide a link to a view showing these other pages (as we
> have for backlinks right now), and having a unified backlinks + xobjects +
> etc. is complex.

Why is it complex? For me it’s about putting references to pages in a Set. Whether the update will come from a link or an xobject can be seen as a detail.

We could simply mention the number of pages (i.e. references) that will be updated as you suggested and provide a LT for that (should be easy).

We could also decide to not show anything for simple users.

> * show multiple numbers (i.e. "There are 4 pages that have links to the
> pages being renamed. There are 7 pages with xobjects defined by classes
> that are going to be renamed. etc.”)

If you think that’s interesting info (and it’s probably the case), we could display this one for advanced users, as additional info.

Thanks
-Vincent

>
>
>>
>> For me this is the same info whether you’re simple or advanced, no? OTOH
>> the checkbox for advanced users could provide additional info as hint.
>>
>> Or we just don’t display this message at all for simple users. I wouldn’t
>> mind either. Makes it simpler in practice :)
>>
>> Thanks
>> -Vincent
>>
>>
>>>
>>>
>>>>
>>>> I was referring to hiding the option (the checkbox). This makes the UI
>>>> simpler to use for simple user, which is the direction we want to go
>> and I
>>>> cannot find tons of reasons why simple users would want to not fix
>> links…
>>>> Actually in the past all issues that were raised were the opposite,
>> users
>>>> who didn’t check the box, and then we made it checked by default.
>>>>
>>>>> Now, the current hint for "Update Links" doesn't indicate all the side
>>>>> effects. For instance it indicates the number of back-links to the page
>>>>> you're trying to rename but it *doesn't include back-links to child
>>>> pages*
>>>>> (when child pages are preserved). So what I said above it not really
>> true
>>>>> ATM either.
>>>>
>>>> Yes, it’s actually worse in a sense :) Right now it makes it seem as if
>>>> it’ll work perfectly well…
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>>
>>>>> Thanks,
>>>>> Marius
>>>>>
>>>>>
>>>>>>
>>>>>> WDYT?
>>>>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>> [snip]

Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

Marius Dumitru Florea
On Fri, Feb 8, 2019 at 4:12 PM Vincent Massol <[hidden email]> wrote:

>
>
> > On 8 Feb 2019, at 14:00, Marius Dumitru Florea <
> [hidden email]> wrote:
> >
> > On Fri, Feb 8, 2019 at 1:51 PM Vincent Massol <[hidden email]>
> wrote:
> >
> >>
> >>
> >>> On 8 Feb 2019, at 12:45, Marius Dumitru Florea <
> >> [hidden email]> wrote:
> >>>
> >>> On Fri, Feb 8, 2019 at 10:25 AM Vincent Massol <[hidden email]>
> >> wrote:
> >>>
> >>>>
> >>>>
> >>>>> On 8 Feb 2019, at 09:20, Marius Dumitru Florea <
> >>>> [hidden email]> wrote:
> >>>>>
> >>>>> On Fri, Feb 8, 2019 at 9:52 AM Vincent Massol <[hidden email]>
> >>>> wrote:
> >>>>>
> >>>>>> Hi Marius/All,
> >>>>>>
> >>>>>> See below
> >>>>>>
> >>>>>>> On 31 Jan 2019, at 11:29, Vincent Massol <[hidden email]>
> wrote:
> >>>>>>>
> >>>>>>> Hi Marius/all,
> >>>>>>>
> >>>>>>>> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <
> >>>>>> [hidden email]> wrote:
> >>>>>>>>
> >>>>>>>> Hi devs,
> >>>>>>>>
> >>>>>>>> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need
> it
> >>>> for
> >>>>>>>> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change
> >> the
> >>>>>> page
> >>>>>>>> rename job (from refactoring module) to update the existing
> objects
> >>>>>> when a
> >>>>>>>> class is renamed *if the "Update links" options is checked*.
> >>>>>>>>
> >>>>>>>> Of course, we could add a new option (e.g. "Update objects") but:
> >>>>>>>>
> >>>>>>>> * it complicates the rename UI (too many options)
> >>>>>>>> * I think most of the users understand the current "Update links"
> >>>>>> option as
> >>>>>>>> "update the places where this page is *used*". I don't think it
> >> makes
> >>>>>> sense
> >>>>>>>> to have separate options (at least at the UI level) for things
> like
> >>>>>> "Update
> >>>>>>>> macro calls" or "Update image includes".
> >>>>>>>> * I don't see why you would want to update the back-links but not
> >> the
> >>>>>>>> objects (or the other way around).
> >>>>>>>
> >>>>>>> Sounds good to me in general.
> >>>>>>>
> >>>>>>>> If we agree on using a single option ("Update links") then the
> next
> >>>>>>>> questions are:
> >>>>>>>>
> >>>>>>>> * Is there a better name? I think "Update links" is a good name
> for
> >>>>>> simple
> >>>>>>>> users so I would keep it. Another option is "Update references"
> but
> >> it
> >>>>>> has
> >>>>>>>> a special meaning for XWiki developers.
> >>>>>>>
> >>>>>>> Maybe "Update other pages” with a hint saying “Ensure that other
> >> pages
> >>>>>> using the renamed pages continue to work after the rename”.
> >>>>>>>
> >>>>>>> ?
> >>>>>>>
> >>>>>>>>
> >>>>>>>> * Should we update the hint for the "Update links" option? I think
> >> we
> >>>>>>>> should, but only for advanced users, since they should be aware of
> >> the
> >>>>>>>> implications of renaming a class. Simple users are not aware of
> the
> >>>>>>>> existence of objects, most probably, so I wouldn't complicate
> their
> >>>>>> lives.
> >>>>>>>
> >>>>>>> Would be nicer to find a single message that work for everyone but
> I
> >>>>>> agree it’s not easy if we wish to provide details.
> >>>>>>>
> >>>>>>> I feel a nicer option would be to NOT show “Update other pages” for
> >>>>>> simple users since that should always be checked. Only offer the
> >>>> ability to
> >>>>>> uncheck it for advanced users and this solves the hint issue too :)
> >>>>>>
> >>>>>>
> >>>>>
> >>>>>> Nobody replied to this proposal but I really find it the best by far
> >> and
> >>>>>> it solves your other questions too while making the UI simpler
> >> globally.
> >>>>>>
> >>>>>
> >>>>> The only issue I see with this option is that by hiding the "Update
> >>>> Links"
> >>>>> the simple users might not be aware of the side effects of the rename
> >>>>> operation: the fact that other pages will have to be updated. Seeing
> >>>> that a
> >>>>> page you want to rename is referenced in many places can make you
> think
> >>>>> twice about the rename.
> >>>>
> >>>>
> >>>
> >>>> We could keep that info, it could be useful indeed.
> >>>>
> >>>
> >>> I can keep the message but then I'll probably need to display different
> >>> messages for simple and advanced users. Moreover, ideally the message
> >>> should be updated whenever the Preserve Children checkbox is clicked
> >> (e.g.
> >>> to indicate that there are more pages to update if the child pages are
> >>> preserved).
> >>
> >>
> >
> >> By messages I meant to indicate (as information) the number of links
> >> leading to the renamed pages.
> >>
> >
> > Sure, but it's not just links. There's also xobjects of a class that is
> > among those pages being renamed. There are two options:
> >
> > * show a single number (e.g. "There are *10 other pages* that are going
> to
> > be updated because they are referencing the pages that are being
> renamed")
> > . The issue here is de-duplication: if you simply sum up the backlinks +
> > xobjects + etc. then you can have pages counted multiple times...
> Moreover,
> > we would need to provide a link to a view showing these other pages (as
> we
> > have for backlinks right now), and having a unified backlinks + xobjects
> +
> > etc. is complex.
>
>

> Why is it complex? For me it’s about putting references to pages in a Set.
> Whether the update will come from a link or an xobject can be seen as a
> detail.
>

I'm not sure that scales.. Renaming a large hierarchy of pages (I've heard
users trying to rename / move the XWiki page...) can lead to thousands of
back-links, xobjects, etc.


> We could simply mention the number of pages (i.e. references) that will be
> updated as you suggested and provide a LT for that (should be easy).
>
> We could also decide to not show anything for simple users.
>
> > * show multiple numbers (i.e. "There are 4 pages that have links to the
> > pages being renamed. There are 7 pages with xobjects defined by classes
> > that are going to be renamed. etc.”)
>
> If you think that’s interesting info (and it’s probably the case), we
> could display this one for advanced users, as additional info.
>
> Thanks
> -Vincent
>
> >
> >
> >>
> >> For me this is the same info whether you’re simple or advanced, no? OTOH
> >> the checkbox for advanced users could provide additional info as hint.
> >>
> >> Or we just don’t display this message at all for simple users. I
> wouldn’t
> >> mind either. Makes it simpler in practice :)
> >>
> >> Thanks
> >> -Vincent
> >>
> >>
> >>>
> >>>
> >>>>
> >>>> I was referring to hiding the option (the checkbox). This makes the UI
> >>>> simpler to use for simple user, which is the direction we want to go
> >> and I
> >>>> cannot find tons of reasons why simple users would want to not fix
> >> links…
> >>>> Actually in the past all issues that were raised were the opposite,
> >> users
> >>>> who didn’t check the box, and then we made it checked by default.
> >>>>
> >>>>> Now, the current hint for "Update Links" doesn't indicate all the
> side
> >>>>> effects. For instance it indicates the number of back-links to the
> page
> >>>>> you're trying to rename but it *doesn't include back-links to child
> >>>> pages*
> >>>>> (when child pages are preserved). So what I said above it not really
> >> true
> >>>>> ATM either.
> >>>>
> >>>> Yes, it’s actually worse in a sense :) Right now it makes it seem as
> if
> >>>> it’ll work perfectly well…
> >>>>
> >>>> Thanks
> >>>> -Vincent
> >>>>
> >>>>>
> >>>>> Thanks,
> >>>>> Marius
> >>>>>
> >>>>>
> >>>>>>
> >>>>>> WDYT?
> >>>>>>
> >>>>>> Thanks
> >>>>>> -Vincent
> >>>>>>
> >>>>>> [snip]
>
>
Reply | Threaded
Open this post in threaded view
|

Re: Update objects on class rename

vmassol
Administrator
Hi Marius,

See below

> On 9 Feb 2019, at 13:11, Marius Dumitru Florea <[hidden email]> wrote:
>
> On Fri, Feb 8, 2019 at 4:12 PM Vincent Massol <[hidden email]> wrote:
>
>>
>>
>>> On 8 Feb 2019, at 14:00, Marius Dumitru Florea <
>> [hidden email]> wrote:
>>>
>>> On Fri, Feb 8, 2019 at 1:51 PM Vincent Massol <[hidden email]>
>> wrote:
>>>
>>>>
>>>>
>>>>> On 8 Feb 2019, at 12:45, Marius Dumitru Florea <
>>>> [hidden email]> wrote:
>>>>>
>>>>> On Fri, Feb 8, 2019 at 10:25 AM Vincent Massol <[hidden email]>
>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>>> On 8 Feb 2019, at 09:20, Marius Dumitru Florea <
>>>>>> [hidden email]> wrote:
>>>>>>>
>>>>>>> On Fri, Feb 8, 2019 at 9:52 AM Vincent Massol <[hidden email]>
>>>>>> wrote:
>>>>>>>
>>>>>>>> Hi Marius/All,
>>>>>>>>
>>>>>>>> See below
>>>>>>>>
>>>>>>>>> On 31 Jan 2019, at 11:29, Vincent Massol <[hidden email]>
>> wrote:
>>>>>>>>>
>>>>>>>>> Hi Marius/all,
>>>>>>>>>
>>>>>>>>>> On 30 Jan 2019, at 15:45, Marius Dumitru Florea <
>>>>>>>> [hidden email]> wrote:
>>>>>>>>>>
>>>>>>>>>> Hi devs,
>>>>>>>>>>
>>>>>>>>>> I'm working on https://jira.xwiki.org/browse/XWIKI-1660 (I need
>> it
>>>>>> for
>>>>>>>>>> https://jira.xwiki.org/browse/XWIKI-13352) and I'd like to change
>>>> the
>>>>>>>> page
>>>>>>>>>> rename job (from refactoring module) to update the existing
>> objects
>>>>>>>> when a
>>>>>>>>>> class is renamed *if the "Update links" options is checked*.
>>>>>>>>>>
>>>>>>>>>> Of course, we could add a new option (e.g. "Update objects") but:
>>>>>>>>>>
>>>>>>>>>> * it complicates the rename UI (too many options)
>>>>>>>>>> * I think most of the users understand the current "Update links"
>>>>>>>> option as
>>>>>>>>>> "update the places where this page is *used*". I don't think it
>>>> makes
>>>>>>>> sense
>>>>>>>>>> to have separate options (at least at the UI level) for things
>> like
>>>>>>>> "Update
>>>>>>>>>> macro calls" or "Update image includes".
>>>>>>>>>> * I don't see why you would want to update the back-links but not
>>>> the
>>>>>>>>>> objects (or the other way around).
>>>>>>>>>
>>>>>>>>> Sounds good to me in general.
>>>>>>>>>
>>>>>>>>>> If we agree on using a single option ("Update links") then the
>> next
>>>>>>>>>> questions are:
>>>>>>>>>>
>>>>>>>>>> * Is there a better name? I think "Update links" is a good name
>> for
>>>>>>>> simple
>>>>>>>>>> users so I would keep it. Another option is "Update references"
>> but
>>>> it
>>>>>>>> has
>>>>>>>>>> a special meaning for XWiki developers.
>>>>>>>>>
>>>>>>>>> Maybe "Update other pages” with a hint saying “Ensure that other
>>>> pages
>>>>>>>> using the renamed pages continue to work after the rename”.
>>>>>>>>>
>>>>>>>>> ?
>>>>>>>>>
>>>>>>>>>>
>>>>>>>>>> * Should we update the hint for the "Update links" option? I think
>>>> we
>>>>>>>>>> should, but only for advanced users, since they should be aware of
>>>> the
>>>>>>>>>> implications of renaming a class. Simple users are not aware of
>> the
>>>>>>>>>> existence of objects, most probably, so I wouldn't complicate
>> their
>>>>>>>> lives.
>>>>>>>>>
>>>>>>>>> Would be nicer to find a single message that work for everyone but
>> I
>>>>>>>> agree it’s not easy if we wish to provide details.
>>>>>>>>>
>>>>>>>>> I feel a nicer option would be to NOT show “Update other pages” for
>>>>>>>> simple users since that should always be checked. Only offer the
>>>>>> ability to
>>>>>>>> uncheck it for advanced users and this solves the hint issue too :)
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>>> Nobody replied to this proposal but I really find it the best by far
>>>> and
>>>>>>>> it solves your other questions too while making the UI simpler
>>>> globally.
>>>>>>>>
>>>>>>>
>>>>>>> The only issue I see with this option is that by hiding the "Update
>>>>>> Links"
>>>>>>> the simple users might not be aware of the side effects of the rename
>>>>>>> operation: the fact that other pages will have to be updated. Seeing
>>>>>> that a
>>>>>>> page you want to rename is referenced in many places can make you
>> think
>>>>>>> twice about the rename.
>>>>>>
>>>>>>
>>>>>
>>>>>> We could keep that info, it could be useful indeed.
>>>>>>
>>>>>
>>>>> I can keep the message but then I'll probably need to display different
>>>>> messages for simple and advanced users. Moreover, ideally the message
>>>>> should be updated whenever the Preserve Children checkbox is clicked
>>>> (e.g.
>>>>> to indicate that there are more pages to update if the child pages are
>>>>> preserved).
>>>>
>>>>
>>>
>>>> By messages I meant to indicate (as information) the number of links
>>>> leading to the renamed pages.
>>>>
>>>
>>> Sure, but it's not just links. There's also xobjects of a class that is
>>> among those pages being renamed. There are two options:
>>>
>>> * show a single number (e.g. "There are *10 other pages* that are going
>> to
>>> be updated because they are referencing the pages that are being
>> renamed")
>>> . The issue here is de-duplication: if you simply sum up the backlinks +
>>> xobjects + etc. then you can have pages counted multiple times...
>> Moreover,
>>> we would need to provide a link to a view showing these other pages (as
>> we
>>> have for backlinks right now), and having a unified backlinks + xobjects
>> +
>>> etc. is complex.
>>
>>
>
>> Why is it complex? For me it’s about putting references to pages in a Set.
>> Whether the update will come from a link or an xobject can be seen as a
>> detail.
>>
>
> I'm not sure that scales.. Renaming a large hierarchy of pages (I've heard
> users trying to rename / move the XWiki page...) can lead to thousands of
> back-links, xobjects, etc.

We already display backlinks and that’s coming from a table so I guess you’re referring to finding all pages having XObjects in them. I was under the impression you wanted to display the count. This is not something I’m proposing. I was just commenting about what you were saying:

> The issue here is de-duplication: if you simply sum up the backlinks + xobjects + etc. then you can have pages counted multiple times...

However let’s try to see what we could do:

* I wouldn’t display anything by default for simple users. Only for advanced users.
* What we need to do is find all XClass in the page being renamed and children. Then for each XClass, we need to count each XObject implementing that XClass in the whole wiki. We can probably come up with a single nested query to do that. That would solve the performance issue.
* Note that there’s one safety we could also implement (for both simple and advanced users): When the total count of pages to modify (ie backlinks+xobjects) is greater than a value (say 20), we could issue some warning saying that there are more than 20 pages that will need to be modified and that it might take a while, and ask for validation. Another variation which is at least as good IMO, is to count the number of pages that will be renamed and issue the warning if it’s > 20 for example.

WDYT?

In summary, all I’m proposing from the beginning is basically to not display the “include children" checkbox for simple users and have it only for advanced users. My goal is to make the UI as simple as it can be.

Thanks
-Vincent

>
>> We could simply mention the number of pages (i.e. references) that will be
>> updated as you suggested and provide a LT for that (should be easy).
>>
>> We could also decide to not show anything for simple users.
>>
>>> * show multiple numbers (i.e. "There are 4 pages that have links to the
>>> pages being renamed. There are 7 pages with xobjects defined by classes
>>> that are going to be renamed. etc.”)
>>
>> If you think that’s interesting info (and it’s probably the case), we
>> could display this one for advanced users, as additional info.
>>
>> Thanks
>> -Vincent
>>
>>>
>>>
>>>>
>>>> For me this is the same info whether you’re simple or advanced, no? OTOH
>>>> the checkbox for advanced users could provide additional info as hint.
>>>>
>>>> Or we just don’t display this message at all for simple users. I
>> wouldn’t
>>>> mind either. Makes it simpler in practice :)
>>>>
>>>> Thanks
>>>> -Vincent
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> I was referring to hiding the option (the checkbox). This makes the UI
>>>>>> simpler to use for simple user, which is the direction we want to go
>>>> and I
>>>>>> cannot find tons of reasons why simple users would want to not fix
>>>> links…
>>>>>> Actually in the past all issues that were raised were the opposite,
>>>> users
>>>>>> who didn’t check the box, and then we made it checked by default.
>>>>>>
>>>>>>> Now, the current hint for "Update Links" doesn't indicate all the
>> side
>>>>>>> effects. For instance it indicates the number of back-links to the
>> page
>>>>>>> you're trying to rename but it *doesn't include back-links to child
>>>>>> pages*
>>>>>>> (when child pages are preserved). So what I said above it not really
>>>> true
>>>>>>> ATM either.
>>>>>>
>>>>>> Yes, it’s actually worse in a sense :) Right now it makes it seem as
>> if
>>>>>> it’ll work perfectly well…
>>>>>>
>>>>>> Thanks
>>>>>> -Vincent
>>>>>>
>>>>>>>
>>>>>>> Thanks,
>>>>>>> Marius
>>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>>> WDYT?
>>>>>>>>
>>>>>>>> Thanks
>>>>>>>> -Vincent
>>>>>>>>
>>>>>>>> [snip]