Priority: Urgent
Current State: No Action Required
Released In:
Target Release: n/a
Applies To: Engine
Component:
Branches:
How to reproduce:
- in
TestWeb1
(or whatever you cal lit), create a form ContactForm
with a formfield CompanyName
- create a topic
CompanyName
(not sure if that step is needed)
- create a topic and attach this form to it
- move it to another web
TestWeb2
- check out the data of the form after it has been moved using
?raw=all
- your formfield
ContactForm
has been renamed to TestWeb1.ContactForm
and thus has destroyed any code (e.g. $meta->get('FIELD', 'CompanyName')
) that relied on it to be called ContactForm
and not TestWeb1.ContactForm
.
How do we resolve this? Is it okay to never ever rewrite formfield names (and titles)? When would you expect formfield
names to be renamed
the same way normal
WikiWords are?
--
MichaelDaum - 30 Sep 2008
years ago, I started to use fully qualified names for formfields - as in, always Web dot
WIkiName for exactly this reason.
None the less thou, I found it necessary to make moves and renames affect form meta data (as for
WikiWord renames) - as I found myself moving form definition topics (after they had been used for a while) to a separate web.
--
SvenDowideit - 05 Oct 2008
This is a difficult call, as the form name is also a wikiword. Further, it's a wikiword that
may be used to get - for example - options for a select. Therefore when you move the form to a different web, the topic reference
must change.
In the case of the specific example you give, I'd suggest that the solution lies with the code that looks up the form field, and not the formfield
itself.
Either way this has been the case for a long time, and cannot be classed as a release blocker. Confirmed as "Normal".
--
CrawfordCurrie - 03 Nov 2008
This bug is so severe for me that I added specific code to the
ClassificationPlugin to revert changes in the formfield names made by a move operation.
--
MichaelDaum - 13 Nov 2008 - 08:53
This bug has been reported long time ago and it still bites me every day. I raised it to urgent again to give it another spin. Note, that rewriting wiki words in meta data not only affects the form name but also pretty much anything stored in meta data.
Let me elaborate further:
- there's a topic
SourceWeb.MyTopic
that has got the formfield TopicType with the value ClassifiedTopic
- there is a topic in the
SourceWeb
called ClassifiedTopic and the formfield value of SourceWeb.MyTopic
links to it within the SourceWeb
... as expected.
- note, the data form isn't displayed. so the fact that the WikiWord might link to an existing topic in the web is negligible.
- there is also a topic in the
TargetWeb
called ClassifiedTopic (means, both webs participate in the knowledge management application)
- now, when I move the
MyTopic
from SourceWeb
to TargetWeb
the WikiWords within the data form are rewritten to point back to the original location, that is ... the formfield value of TopicType
of the new TargetWeb.MyTopic
becomes SourceWeb.ClassifiedTopic
even though I want it to be the same as it was: just stay ClassifiedTopic
.
- there is a specific
afterSaveHandler()
in ClassificationPlugin that fixes the TopicType
field again .... bah
I am not sure what the best way is to resolve this issue as there are use cases for both (1) rewrite and (2) don't rewrite formfield values during move/rename. Any ideas?
--
MichaelDaum - 10 Dec 2009
In my case, the web is a namespace/context area and the form field name is a topic that represents a concept within that context which either won't exist or won't mean the same thing in the target web. So the existing behaviour actually works as I need it to.
- I see. Well, would you move topics between those webs at all, i.e. given that prerequisites for the moved topic to make "sense" in the new web are not fulfilled? -- MD
- Well, I don't think we have moved form topics to other webs, no. But we do have a need for building forms that use term topics outside of the current web. The application framework allows groups to build these "term topics" as a sort of vocabulary; then a different group of users cherry-pick the terms they need from a variety of contexts/namespaces to build new forms ("profiles"); then a different group again are able to do data entry using those forms. The idea is that the profile (form) builders should be able to build 90% of their form using existing well-defined terms, and only create new terms of their own within their own specific context only if they truly need to. -- PH
What if: Fully qualified
TopicName formfields retained the existing behaviour;
JustATopicName as a formfield name doesn't get rewritten?
A less violent solution would probably be to add a new attribute (we already have M and H: how about NR? No-Rewrite)
I think 1.0.9 is actually overdue, it would be nice if we could assign this to a later release.
--
PaulHarvey - 10 Dec 2009
Michael, just to be sure I'm understanding you: You want the move process to leave the form
fields untouched, even if the form
name is updated to point to the original web?
--
RafaelAlvarez - 10 Dec 2009
Rafael, I'd prefer the move process
not to touch the name nor the value attribute of a meta data object as both has high potential to break wiki apps. Sorry if I was unclear.
--
MichaelDaum - 11 Dec 2009
Hi Michael, I don't deny that the current behaviour is probably detrimental to the majority of dataform apps out there.
If we are to fix this thing I would still like access to the existing behaviour. The web that the term topic lives in (or rather, the link that fully identifies the concept) is important information to me and I don't want that to be lost during a move.
Hopefully this can be achieved by implementing an additional formfield attribute.
--
PaulHarvey - 12 Dec 2009
I was just thinking about this in the context of an dataform application I just wrote. It would be a disaster if the formfield was
not renamed when the topic moved; I rely on the renaming of the formfield to access select options, without reproducing those options in every target web. So this is not so clear cut. the more I think about, the more convinced I am that the current behaviour is the expected behaviour, and what Michael is proposing is counter-intuitive for most people.
I changed the wording of the summary from "destroys" to "modifies" because this modification is actually
beneficial to many dataform apps.
Given that the current behaviour cannot (IMHO) be classed as a bug, we are left with looking at this from Michael's perspective. He needs to be able to "protect" field names and values from rename. Here are a few ideas:
- Add an interactive option to suppress reference renaming during renaming of a form topic
- Add TML to create suppression regions e.g. ...
- Add %META that tells the rename code how to handle formfield references in the given topic
- Add one or more preferences to control renaming behaviour
- (12:55:25) pharvey: Regarding http://foswiki.org/Tasks/Item6032, what about adding a new formfield attribute other than M and H?
--
CrawfordCurrie - 12 Dec 2009
I agree with Crawford. Changing the spec will make some happy and others not happy.
We have had several similar bug reports before and we have zig-zagged with bugs that changed too much when we rename and others that changed too little.
Better keep the spec as is - and find a new feature type solution to Michaels fully valid use case. Challenge is a solution that does not score too high on the
NerdoMeter.
I guess it is time to go into a Feature proposal phase and come with some solutions. I am sure a good proposal can reach consensus. I am putting this in No Action but please reopen when we have a feature proposal passed.
--
KennethLavrsen - 13 Dec 2009