Re: [Fez-users] Status of immutable fields?

[Christiaan K. <c.k...@li...>]

Hi Keith

This is addressed with the new html input type for these is =8Chidden input=B9.
If you look at the latest Journal Article MODS display mapping in the lates=
t
fez you will see it being used to do just what you are suggesting you need
it for. This will keep it around and not show it to users. Another option i=
f
you don=B9t want to change the input type (or just hide this field from the
user) temporarily you can use the new =8Cis invisible?=B9 checkbox for the
field. That way it will still be a text input/whatever but it=B9s TR will hav=
e
style=3Dhidden so the user won=B9t see it.

Cheers,
Christiaan


On 25/1/08 7:57 AM, "Keith Maull - Colorado Alliance of Research Libraries"
<ke...@co...> wrote:

> Christiaan =AD
>=20
> I wanted to quickly ask the status of immutable fields in Fez.  I remembe=
r way
> back, when we talked about the problem of existing fields being removed w=
hen
> they are edited in a HTML form, particularly if they exist in the metadat=
a
> already.
>=20
> Recall we had the example of our own handle being generated outside of Fe=
z
> using the DC:identifier field and once the object was updated, such
> information was being removed since it never existed in the XSD HTML matc=
hing
> editor =AD or if it did, was replaced altogether with the user value.
>=20
> We ran into problems when we used DC:identifier to specify our repository
> handle URL, but if a user edited the form, of course this was a field we =
did
> not want them to edit =AD and merely =B3pass through=B2 once the edit was compl=
ete.
> The difficulty appeared when the field was mysteriously =B3deleted=B2 after t=
he
> edit, since it was not in the HTML form.  This becomes even more complex =
with
> we want users to actually *use* the field for their own purposes =AD i.e. a
> repeating field, much like DC:identifier, where *we* want to add our own
> identified in addition to the user editable one.
>=20
> A few solutions could be taken :
>=20
> 1) allow for a field to be marked as immutable (in the XSD editor, allow =
a
> flag that says =B3if this exists already, DO NOT REMOVE IT, merely copy the
> existing value into the new XML document upon edit),
>=20
> 2) pass the user information that they=B9re editing a field that already ex=
ists
> or has a special meaning when being edited and give them a chance to choo=
se
> which value or values that they want,
>=20
> 3) treat repeating fields differently or have 2 or more classes of repeat=
ing
> fields that address these issues more directly,
>=20
> 4) create a =B3first value sticks=B2 field =AD such that the =B3first value=B2 of a
> field remains =AD Fez would obviously have to keep track of the first insta=
nce
> of that value and basically just add it back when an update was made.  Th=
is
> seems like a reasonable solution as it would make sure the value (while b=
eing
> deleted) would re-appear as the last insert of the updated object,
>=20
> 5) keep things as they are.
>=20
> I don=B9t know which one I like most, but I don=B9t like 5.  It=B9s pretty clea=
r
> that this is a tough problem.  It borders a =B3merging=B2 solution that is ne=
ver
> really an easy problem to solve.
>=20
> Are there changes in F2 that I am missing that address this issue?
>=20
> Thanks,
>=20
> K:M
>=20


--=20
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Christiaan Kortekaas
Senior Library Open Sorcerer
Library Technology Service
The University of Queensland, Australia QLD 4072
Telephone : (+61) (7) 3346 4337
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~