Closed Bug 111165 Opened 23 years ago Closed 14 years ago

templates in Composer

Categories

(SeaMonkey :: Composer, enhancement)

Product:
SeaMonkey
Component:
Composer
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
RESOLVED EXPIRED

People

(Reporter: glazou, Assigned: glazou)

References

Details

I think we could add templates to Composer and Message Composition for a quite
minimal cost. Here is what I have in mind :

   1. have a special _moz_editable attribute meaning that an element is an
editable zone in a template
   2. add 4 new menu items (or subitems or whatever) "New template", "Save as
template", "Load template" and "New document from template" to File menu; have a
*.mtd (Mozilla Template Document :-) ) extension for templates
   3. add a boolean member mIsTemplate to the HTMLEditor or HTMLEditRules and
make this boolean become true when we create, load or save a document as a template
   4. apply the following stylesheet to documents edited with mIsTemplate is
true:   *[_moz_editable] { border: thin dotted red } in order to visualize
editable zones
   5. add 2 new menu items "Make editable zone" and "Remove editable zone" to
Format menu, these menu items enabled/visible only if mIsTemplate is true
   6. when Make editable is selected, add the _moz_editable attribute to all
elements in the promoted selection but not to elements into these elements
   7. when Remove editable zone is selected, remove _moz_editable attribute from
all elements in the promoted selection


   8. add a boolean member mIsFromTemplate to the HTMLEditor or HTMLEditRules
and make this boolean become true when we create a document from a template or
when the document we load contains a _moz_editable attribute
   9. apply a stylesheet to documents having mIsFromTemplate true making all
elements in the document not selectable not editable BUT the elements carrying
_moz_editable and children
  10. when the user wants to create a new element in the flow hitting the Return
key and if mIsFromTemplate is true, check if an ancestor of the current element
has the _moz_editable attribute. Do not create the new element if this test is false
  11. if mIsFromTemplate is true, never merge the contents of two elements if at
least one of these element has not ancestor having the _moz_editable attribute
  12. when saving a document with mIsFromTemplate true, ask the user if  he/she
wants to remove the link between the document and the template ; if the answer
is yes, remove all _moz_editable attributes from the document before saving and
change mIsFromTemplate to false

One extra thing that we would have to think about if we ever decide to go that
way : how can an organization distribute a template to its users and how can
these users enable the use of such a distributed template ? Email ? Web folder ?
Ldap ? Open issue...

PS: there is in Gecko a -moz-user-modify property accepting the read-only value
but I can't make it work in Composer ; that property would be very helpful for
templates

Hey, please, no answer about perf or bloat. I have filed this bug to be sure
the information is kept in safe place for the future. Let's think of long-term
future *too*.
Target Milestone: --- → M1
Target Milestone: M1 → Future
Status: NEW → ASSIGNED
removing myself from the cc list
adding self to cc list
I think that any document template (such as html template) should be viewable as
a normal web page without the template appearing incorrect.

One way to do this would be to use special comments to denote a template entry.

text can be templatized as follows (or some kind of variant):

<!--# template.entry.text -->[Enter name here]<!--# /template.entry.text -->

and would appear as a shaded "[Enter name here]" in composer (much like
Microsoft Office does it). When you click on it, you would be able to enter new
text.

<!--# template.auto.date --> Could denote a date that is automatically filled in
by composer.

<body bgcolor="#ffffff"><!--# template.attributes bgcolor{ prompt = "Add your
background color here" includes="colormap" } --> could allow you to change the
bgcolor of the body by having some kind of link or something that brings up a
dialog box.

Of course, I am just throwing out examples of syntax, and the words and syntax I
used could probably be made much better.
I've been doing some thinking on this for a while today (and occasionally in the
past too), though my method is somewhat different (and still being toyed with).
Would be a nice feature to get in, but I doubt that it would be workable until
at least 1.1beta, or perhaps even later.

I've been thinking about having wizards, too, similar to FrontPage's (but
naturally, a million times better :) because a pure HTML template can only go so
far.
There's lots of great suggestions here! I like both Brian's and Chris' 
suggestions (on 5/7).
Assignee: syd → cmanske
Status: ASSIGNED → NEW
Similarily, we can store templates and wizards in a fashion similar (gasp) to
FrontPage. In other words, have a template dir (or directories: templates
internal to Composer, templates in ~/.mozilla/[Profile Name]/[random
string].slt/composer/templates, and perhaps something like
/usr/mozilla/composer/templates or similar for those across a corp. network).

Internal to these directories are more directories, one for each template. These
each have a name and an extension, e.g. foo.tem (normal templates) or bar.wiz
(for wizards). Inside each directory you'll find two or more files, depending on
normal or wizard.

For normal templates, you'll have an .html file and an .inf file, as with
FrontPage. The .html file is just proper (X)HTML and can be treated as such --
possibility of throwing in some preprocessor to fiddle with certain values
beforehand (colors and author name as in Prefs->Composer->New Page Settings).
The .inf file contains information such as the template name and a description.
The only problem I see here is dealing with all that i18n/L10n stuff. Example
(continuing from above): foo.html and foo.inf are inside the foo.tem directory.

For wizards, you'll have a .xul and .js files to play the wizard role, the .inf
file (as above), and possibly a .html file to work from (if the wizard doesn't
generate a new one from scratch each time). Once again, i18n/L10n has it's fun.
Example (continuing): bar.wiz has bar.xul (the wizard dialog), bar.js (which
does all the work), bar.html (which is played with by the wizard), and bar.inf
(prior mention).
Summary: [RFE] templates in Composer → templates in Composer
A few thoughts :

(a) we need to use CSS to make read-only elements in a template ; that implies
    that we can't use SGML comments to designate editable zones/elements : SGML
    comments can't be styles by CSS...

(b) I really prefer a specific class "dashMozTemplateEditable" ; that will
    (b.1) validate against W3C validator (b.2) allow CSS styling (b.3) will
    restrict editability to HTML elements

(c) this bug becomes hot and I filed it loooong ago ; taking
Assignee: cmanske → glazman
Product: Browser → Seamonkey
QA Contact: sujay → composer
Target Milestone: Future → ---
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.