Ver 4: Still no support for Includes or Design TimeStylesheets?

[MikeyJ]

Wow...well, without either of these I can't make use of this product. I guess
I'm confused at the level of user this product may be marketed toward, although
with the amount of focus put on Blogs and Blogging in this version I'm getting
a better idea.

Most intermediate to advanced designers will almost always, and have been
taught, to use includes to minimize page changes in multiple places...it's such
a common thing to do. But unless an included page can be edited inline I have
no way to turn my users loose with this app. One solution that seems
reasonable would be to allow Design Time Stylesheets like Dreamweaver does in
which case, the users could edit the included page directly and at least see it
like it should look with formatting which they can't do now because of the lack
of an applied stylesheet when opening the include file directly.

Do they expect that once we've written a site using "advanced features" like
includes we should have our content providers use Dreamweaver? I don't know
about the rest of you but that's asking for a heck of a lot of trouble turning
non-designer/developers loose with Dreamweaver.

Sorry for the rant, I'm just a bit frustrated as I really need an app that can
let me make use of "Content Providers" in our company. Anyone else have
thoughts on all of this?

Thx,
Mike

[Budonk]

I'm right there with you.

So frustrating! It makes no sense to me. There are browser-based editors that
will allow you to do this but for some reason Contribute will not.

I've made multiple, unanswered inquiries and unfortunately, my only solution
so far has been to abandon Contribute until they decide to support this simple
feature.

Let me know if you hear anything new.

[anclarke]

Hi. I'm going to reopen this thread instead of starting a new one. Maybe
someone here can help me figure out how Contribute can solve my client's
editing woes.

His site is built in ColdFusion, with template information that's stored in
the database for each page. Currently this is what happens, simplified.

1. User requests /foo.cfm
2. Database looks up header, footer, and template to use for /foo.cfm, or the
page can use "no template" in which case whatever's in the page gets put
between the header and footer.
3. The template or the page will contain one or more "editable regions", to
use a Dreamweaver term. These blocks of HTML are pulled out of the database,
and can currently be edited within the CMS by a browser-based WYSWYG editor.

The problem is, the WYSIWYG editor in question isn't up to the task.
Contribute seems to be, but I can't figure out how to fit it into a workflow
compatible with this site!

We don't use Dreamweaver and from what I've seen Dreamweaver templates aren't
going to work in this application. It seems that if you make a change to the
template, Dreamweaver has to go and update all 800 pages that use the template
.... ??!? ... if so, lame.

I don't mind pulling out all the HTML content snippets from the database and
making a "database" on the filesystem of files that can be edited in
Contribute. No problem. One of these snippets may be a "contact us" box or
something that's used on 100 pages throughout the site, so I'm not going to put
stuff like that separately on every page.

If I do this, though, my snippets when I open them to edit them in Contribute
are missing their CSS. This is because the CSS is set up in the header file,
which is not included in the snippet HTML, obviously. The snippets also won't
have the header and footer navigation and stuff, but I can live with that.

How can I get the CSS to show up for my client when he edits the HTML snippets?

The only solution I can think of is to put a stylesheet include into every
snippet, and then pull that out with a regular expression from EVERY include at
runtime whenever I display that HTML to the end user. Talk about a gross,
ugly, non-extensible hack. Please tell me there's a better way...

Thanks for reading,
- Andrew.

[anclarke]

Hi, it's me again. I figured I'd post again since I implemented what I wrote
about above.

I dumped out all my content from the database to flat files, and when I did it
I put a <link rel="stylesheet" type="text/css" href="/Styles.css" /> at the top
of all my includes. This way when I open them in Contribute, I get my styles.

When I include the HTML in my pages, I remove that line from the top of the
file.

Now I'm faced with a problem that the relative hyperlinks that Contribute uses
don't work, but I've detailed that issue in another post. All in all, I'm
discovering that the upside is that I can hack a solution to every problem I've
come across so far with Contribute. The downside is that if the product was
designed with a little more forethought for the "power user" I wouldn't have to
hack this stuff.

- Andrew.