>
> I'm thinking about page authors using things like Dreamweaver or other
> tools that would generate full html pages <html><head>. our current
> configure could cause some hassle. I'm just thinking if we wnat
> to change this stuff, now is the time.
>
I've thought a little about this.
First, if you are going to use Dreamweaver's templates and libraries to lay
out the pages of a site. It should be fairly straightforward. But there is
no reason to use the layout/navigation templates in Turbine. Each page is
just a screen. The bad thing about this is that Dreamweaver's templates and
libraries are very limiting. It has been my experience that a client wants
a site that can be managed by Dreamweaver, designers come up with a user
friendly, greatlooking site, and then the client gets to choose whether they
will sacrifice the great designs so that they can maintain the site in
Dreamweaver.
I recently programmed a template/navigation system in Javascript
(Dreamweaver's native tongue), which provided the same level of
functionality that was possible with Turbine (the site was static). It has
the same problem as pre-template-system servlets. The html is output in
Strings. This allows novice page designer's to alter screen content without
constantly screwing up the page template, but does require more than a
novice user's ability to alter the template.
Using Turbine layouts (even with the <html>, etc. tags) within Dreamweaver
will not gain much, you must expand the navigations and screen in order for
the page to look remotely as it is intended in Dreamweaver. Therefore I do
not see the benefit of having <html> in the layout, if you need to run the
screen through Turbine in order to see the page.
I was thinking it would be good if somehow, Turbine could be set up to keep
a modularized version of the site and a flattened version. The basic rule
would be that changes to the screen content would get carried over to the
modularized screens, the rest of the flattened document would be marked off
limits to editting and if it was these changes would get thrown out when the
two versions are synched. It would probably be good to set a flag on which
way screen content was brought into synch. But this would take some effort
to engineer and it would probably be substantially easier to build to a
WYSIWYG editor that was Java aware. And would be much more satisfying if we
could build it to a OSS editor.
John McNally
------------------------------------------------------------
To subscribe: [EMAIL PROTECTED]
To unsubscribe: [EMAIL PROTECTED]
Search: <http://www.mail-archive.com/turbine%40list.working-dogs.com/>
Problems?: [EMAIL PROTECTED]
