Re: [wwp-users] WWP: Easier v.'best' practice: para mappings, style names, CSS classes [LONGISH]

["John Frazzini" <frazzini@xxxxxxxxx>]

hedley_finger@myob.com.au wrote:
> 
> Webworkers:
> 
> I am just getting to grips with WebWorks Publisher and would like the
> advice of the battle-scarred re alternate ways of doing some key tasks:
> 
> <snip...>
>
> This is the easy way.  However, what are your opinions on, say, duplicating
> a WWP7 custom tag hc_ChapTitle from Heading1, and then mapping
> 
>      hc ChapTitle --> hc_ChapTitle ?
>

This does allow you to automatically have the tags map themselves, but
for the reasons below, I don't think this is a good idea. 
 
> <snip...>
>
> I have been lurking on the list for some time and at every new release or
> upgrade of WWP there are howls of pain when changed macros or template tags
> cause existing help projects to break.  I figure by having our own custom
> tags we are immunized from inadvertent importation of a new template
> breaking tweaked tags.

Exactly the opposite is the case. WebWorks has been trying to make their
macros more "automatic" and require less user interaction. Because of
this, the best way to prepare for a new template is to map to the
default webworks styles, then import your MAPPINGS (not the macros, just
the mappings) to a new release of a template. That way, your mappings
are preserved (because WebWorks tries to provide the same macro names
from release to release), but you get the new functionality of the
macros without having to remap everything. 

If you create your own custom macros, these are not guaranteed to be
usable with new versions of a template. Granted, WebWorks is probably
working on making their template migration tool more usable, but at the
moment, any custom macros you created in most V6 templates are not
usable in the corresponding V7 templates. 

The best way to handle the situation seems to be: 

1) map as many of your paragraphs to WebWorks default templates as
possible. 
2) Modify the default macros using the new tabs in V7 (Basic, Font,
etc.) to include the style information you wish to override from default
behavior, if desired.
3) Create as few custom macros as possible (for special situations when
you want to modify the macros, but not the style information).
4) Change any Support/*.asp files as needed. 
5) Document the heck out of the changes you made in #3 and #4 so that
you can reapply these changes to a new version of the template.
6) Save these changes as a template and have all your writers use the
template you create (one person should make these changes and everyone
else shouldn't have to deal with mappings... they should just use the
template you create and your paragraphs should map automatically).

When you have to upgrade to a new version of the template to get bug
fixes or new functionality, all you have to do is import the mappings
from your current template into the new template. Then you'll also have
to reapply any changes you made in steps #3 and #4 above, but this
should be fairly easy because there shouldn't be too many of these
changes. 


> 
> MAPPING LIST PARAS TO WWP7 TAGS
> 
> <snip...>
> 
> Has anybody any experience or opinions on the best way to go?  Does anybody
> have any fancy macros that can calculate the space required to indent the
> para after the number and then insert multiple instances of a 1 pt GIF to
> pad the text to the indent?  Or some other clever hack?
> 

You can use the Indented macros to get the same behavior you're used to
in mif2go. The problem with the indented tags is that they don't outdent
the number or bullet. Unfortunately, as Bill Burns also points out, this
is not something that can be easily fixed in the CSS. 

The rule with SmartList macros is that all paragarphs within a list must
be mapped to a macro that has the "Make Relative to Previous Paragraph"
checkbox checked on the Level tab (the default macros with this
characteristic are named with the word "Relative" in the macro name). 

There are better ways of doing smartlists, so that you don't have to be
as disciplined, and I've told Quadralay on several occasions how they
can fix their macros to be less "breakable", and given them the code to
fix the problem. However, they seem to not want to implement lists this
way, for whatever reason. 

Pretty much any WebWorks consultant worth his/her salt should be able to
work with you to give you a solution to making your smarlist macros work
with all your other paragraphs (with some tradeoffs perhaps, but for the
most part, there are better solutions). Of course, most of them will not
be willing to put in as much work as this needs without charging a fee. 


> USING CSS STYLES
> 
> <snip...>
> 
> Does anybody see a problem with this?  Once again, because my writers are
> familiar with the standard tags in their FM documents, the CSS selector and
> class names would be self-documenting for the lucky person who has to
> maintain this stuff after I have gone to my reward in heaven -- or perhaps
> just to the Gold Coast to retire.
> 
> 

Yes, I see a problem with this, but it's more philosophical than
practical.  No one said that your HTML output has to look exactly like
your FM output. In fact, it's pretty unrealisitic to expect that an
online medium like HTML SHOULD look like a medium that's designed for
printing (FM documents). However, this does seem to be a very popular
thing to try to do. 

>From a practical point of view, however, using the FM paragraph names in
the CSS file isn't going to work too well with the recommendations above
and with the way that WWP7.0 generates its own CSS files. The easiest
thing to do is to use your paragraph macros to specify the CSS
characteristics (using the Font and Basic tabs in WWP 7.0) and save your
changes as a template for everyone to use. If the template handles all
of your paragraphs/characters/tables/etc., there's no reason anyone
would need to look at the generated CSS file, or do any manual mappings,
so this point seems kind of moot. 

--John  
_______________
John Frazzini


** To unsubscribe, send a message to majordomo@omsys.com **
** with "unsubscribe framers" (no quotes) in the body.   **