DW removes spaces surrounding updated library items

Question

I've filed a bug with Adobe on this issue, but I'm wondering
if anyone else has received a fix for what I consider a
showstopping bug. In a nutshell, whenever I update a library item,
DW removes all spaces surrounding the updated library item, and
will even remove spaces surrounding unrelated library items during
the same operation.
For example, let's say I have a simple library item that
contains only the character "^". I insert that into a page to
render like this: "| ^ |", using normal spaces in the page code to
separate the three characters. If I then edit the library item to
use the character "-" instead, all updated pages will lose the
surrounding spaces: "|-|".
I've developed hundreds of library items over the years, and
can reproduce this over the last three versions of DW (8, MX 2004,
MX), on multiple computers using new code or existing sites. If I
edit a single library item, it corrupts hundreds of pages in a
large site, and I have to use special searches to find and fix the
error. I can't believe that noone else is affected by this problem,
or isn't using library items to the extent that I do.
I'd really like to see library item functionality repaired,
and this is my last appeal before finding a replacement for DW, Are
any DW developers monitoring this list?

Answer 1

> bug is just as capable of affecting SSI
I don't think so. At least, I have never seen it happen. Have
you?
> Library items are particularly aimed at professionals
managing large
> sites.
I don't think so here, either. Why would one EVER choose a
Library item
over SSI? On a large site, you would upload hundreds if not
thousands of
files for each change with the former.
> It is an opportunity to
> create reusable code that can be managed and edited in
one central
> location, so
> that changes to a single file can be replicated
throughout the entire code
> base.
Precisely what SSI does, only better.
> Yes, it may be more desirable to use a server side
technology to control
> these bits through the use of variables and includes,
but I also build and
> manage high performance web servers, and no dynamic
language can even come
> close to the speed of delivering static files,
especially if you want to
> withstand a slashdotting or other unusual burst of
activity.
This is true - since Library items are design-time tools, you
take the
bandwidth hit on the upload side of things rather than on the
fetch side of
things.
> I'm hoping that someone at Adobe is monitoring this list
They do not. If you need to communicate with them, you must
contact them
directly. But you have been told that Adobe is aware of the
problem at
least twice - is that not enough?
Murray --- ICQ 71997575
Adobe Community Expert
(If you *MUST* email me, don't LAUGH when you do so!)
==================
http://www.dreamweavermx-templates.com
- Template Triage!
http://www.projectseven.com/go
- DW FAQs, Tutorials & Resources
http://www.dwfaq.com - DW FAQs,
Tutorials & Resources
http://www.macromedia.com/support/search/
- Macromedia (MM) Technotes
==================
"jorey" <[email protected]> wrote in message
news:[email protected]...
> The examples I used are overly simplified to more
clearly demonstrate the
> problem. Using a server-side technology is not relevant
to this issue.
> This
> bug is just as capable of affecting SSI, PHP, ASP, or
any other code
> edited and
> managed with Dreamweaver.
>
> Library items are particularly aimed at professionals
managing large
> sites.
> Who else would even be interested in such a feature? It
is an opportunity
> to
> create reusable code that can be managed and edited in
one central
> location, so
> that changes to a single file can be replicated
throughout the entire code
> base. To suggest that it is necessary to create slightly
different
> versions of
> code snippets to suit the individual needs of each
generated page utterly
> defeats the purpose of library items.
>
> As for the uses of library items, sure, I'll use it to
maintain large
> blocks
> of code, but it's also useful for little things that
change on a regular
> basis,
> such as names of people in specific roles, addresses,
phone numbers, email
> addresses, URLs, dates and other things that might
appear hundreds of
> times
> throughout a site in a variety of contexts. This bug has
serious
> repercussions,
> because it is not limited to the item being updated. You
could update a
> large
> block of code and have unpredictable changes occur
elsewhere. This is
> unacceptable, and may not be limited to library items,
but may also affect
> templates or any other site management function that
relies on the same
> routines.
>
> Yes, it may be more desirable to use a server side
technology to control
> these bits through the use of variables and includes,
but I also build and
> manage high performance web servers, and no dynamic
language can even come
> close to the speed of delivering static files,
especially if you want to
> withstand a slashdotting or other unusual burst of
activity.
>
> But as I mentioned, the type of code or use of the
library item is
> irrelevant.
> Dreamweaver as a programming editor has a serious bug.
It's broken, and
> needs
> to be fixed. I'm hoping that someone at Adobe is
monitoring this list and
> will
> understand that this is a problem that affects advanced
users and whole
> teams
> who have made extensive and productive use of this
feature before it was
> broken.
>