Mailing List Archive

On Friday, January 17, 2003, at 09:57 AM, D.Kreft wrote:

> So I'm trying to create a new element (a common page header) and I went
> through and added a few custom fields (a series of text boxes).
>
> After having created several of these fields as "Required", I realized
> that
> I didn't want them to be required after all. So, I deleted them. Now,
> when I
> try to add another textbox with the same name, I'm told:
>
> An "link" attribute already exists. Please try another name.
>
> How do I get around this? Do I have to nuke the entire thing (the
> header
> element) and start over again?

That's one way to do it. Easier, however, is to just create the field
with a different "Name" (e.g., "url"), but give it the same "Label".

HTH,

David

--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]



-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit encryption.
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

On Fri, 17 Jan 2003, David Wheeler did scribble:

> That's one way to do it. Easier, however, is to just create the field
> with a different "Name" (e.g., "url"), but give it the same "Label".

The "problem" (albeit a small one) is that I'm creating elements out of
pre-existing Mason components and templates, so I want to keep them as close
to the same as possible.

It seems to me, though, that if I click on "Delete" and I get a message that
says that I'm going to "permanently delete" something, it should be *gone.*
Why does Bricolage still keep track of them if I've nuked them. This is
rather counter-intuitive...if/when I go to launch this on our intranet, I
*know* that this is something that users are going to constantly bug me
about.

__END__

mod_bigdan
Softwear Enguneer <><
Intranet Technologies

An Ada exception is when a routine gets in trouble and says
'Beam me up, Scotty'.



-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit encryption.
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

I ran into the same behaviour, and if I understand the explanation
correctly; just because you delete the field from the story element, it
isn't lost to other stories already existing that use that story element. So
if you put a new one in with the same name, but different attributes, you
will break any existing stories. Since all my content right now is of the
form: "Here's a story. Here's some more of it!" it wasn't an issue to create
new elements.

But I do think the message doesn't accurately reflect what is happening. If
it warned you that you could never use that element name again, it would be
more helpful, at least to new users.

I wasn't too concerned, because I couldn't see the people I would turn
content creation over to being capable of doing much customization anyway,
so only a few people would have to be familiar with element design.

gh

> -----Original Message-----
> From: D.Kreft [mailto:bigdan@amazon.com]
> It seems to me, though, that if I click on "Delete" and I get
> a message that
> says that I'm going to "permanently delete" something, it
> should be *gone.*
> Why does Bricolage still keep track of them if I've nuked
> them. This is
> rather counter-intuitive...if/when I go to launch this on our
> intranet, I
> *know* that this is something that users are going to
> constantly bug me
> about.


-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit encryption.
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general

I've added this Bric::FAQ:

=item I added a field to an element and deleted it, and now I can't add
a new
field with the same name. Why not?

Fields cannot have the same name, even if they've been deleted. This is
because you might have older stories around that use the old name, and
still
republish them to templates that use the old name.

The solution is to give the new version of the field a different name,
but
make the "Label" the same. So you might have a name like
"new_paragraph" and
the label "Paragraph". Just remember to change any references to the
old field
name in your templates to use the new field name.

HTH,

David

On Friday, January 17, 2003, at 10:28 AM, Harrison, George (FSH) wrote:

> I ran into the same behaviour, and if I understand the explanation
> correctly; just because you delete the field from the story element, it
> isn't lost to other stories already existing that use that story
> element. So
> if you put a new one in with the same name, but different attributes,
> you
> will break any existing stories. Since all my content right now is of
> the
> form: "Here's a story. Here's some more of it!" it wasn't an issue to
> create
> new elements.
>
> But I do think the message doesn't accurately reflect what is
> happening. If
> it warned you that you could never use that element name again, it
> would be
> more helpful, at least to new users.
>
> I wasn't too concerned, because I couldn't see the people I would turn
> content creation over to being capable of doing much customization
> anyway,
> so only a few people would have to be familiar with element design.
>
> gh
>
>> -----Original Message-----
>> From: D.Kreft [mailto:bigdan@amazon.com]
>> It seems to me, though, that if I click on "Delete" and I get
>> a message that
>> says that I'm going to "permanently delete" something, it
>> should be *gone.*
>> Why does Bricolage still keep track of them if I've nuked
>> them. This is
>> rather counter-intuitive...if/when I go to launch this on our
>> intranet, I
>> *know* that this is something that users are going to
>> constantly bug me
>> about.
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts
> will
> allow you to extend the highest allowed 128 bit encryption to all your
> clients even if they use browsers that are limited to 40 bit
> encryption.
> Get a guide
> here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
> _______________________________________________
> Bricolage-General mailing list
> Bricolage-General@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bricolage-general
>
>
--
David Wheeler AIM: dwTheory
david@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: Theory@jabber.org
Kineticode. Setting knowledge in motion.[sm]



-------------------------------------------------------
This SF.NET email is sponsored by: Thawte.com - A 128-bit supercerts will
allow you to extend the highest allowed 128 bit encryption to all your
clients even if they use browsers that are limited to 40 bit encryption.
Get a guide here:http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0030en
_______________________________________________
Bricolage-General mailing list
Bricolage-General@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bricolage-general