Workflow process with FOSI editing and Editor 5.3

[ptc-953343]

I'm trying to get back up to speed on creating FOSI's in Editor 5.3. I
previously used the FOSI editor to manage this process for the easy
things. Styler has replaced that interface so I'm having troubles just
getting started.

For instance a big problem I have right now is that I'm editing the FOSI
as a document (or in Textpad). If I make a change how do I get the edit
window to refresh based upon those changes? Note right now I just want to
see screen FOSI changes, I'll deal with the PE issues next. So I have some
notes that say to use Ctrl F2 but this seems to be forcing PE to execute.

Any suggestions for a workflow and how to manage a FOSI in this new Editor
worls would be greatly appreciated.

..dan

[ClayHelberg]

Hi Dan--

I'm not sure about a complete workflow for FOSI editing, which can be as
much a matter of personal taste as best practice, but to address your
specific question of how to refresh the screen view when you update the
screen FOSI: you can use Revert Stylesheet on the Format menu. (You might
need to enable Full Menus in preferences to see this.) Contrary to the name,
this doesn't change your stylesheet back to some previous version, but
rather reloads the stylesheet, which is just what you want in this case.

I don't think there's a hotkey defined for this by default, but you could
put some code in your startup file to assign one using the map command. The
ACL command corresponding to the menu item is stylesheet_revert().

BTW, if this is something you'll be doing for a while, you should consider
attending PTC/USER World Event in June. There's going to be some nice
content on FOSI there this year. Check it out:

[jkaplansky]

My best advice is to not attempt FOSI development in Editor. You might
be able to do some things in PE Interactive, but your best bet is to use
Epic Architect as your gateway to FOSI. The FOSI development tools are
still in Architect.

Hope this helps.

-Jean

[naglists]

After making screen FOSI changes close the document and reopen. This rereads
the stylesheet. I am not aware of a way to make Editor reread and apply a
screen FOSI without closing the document.

With PE 5.1 and 5.2, each new composition request rereads the FOSI. With
5.3, I'm learning, this isn't so and a Tomat/PE restart is required. There
is a PE web page that theoretically allows you to restart all of the PE
subprocesses without restarting Tomcat (and without logging on to the
server). It isn't working for me ... it, in fact, hangs the PE subprocesses.

While working on or validating screen FOSI changes, I use a custom folder on
my laptop. When ready for release, I copy it to the network custom folder
shared by all an application's authors.

While working on print FOSI changes (in most cases print and screen are the
same), I do development in:
z_dev.fos

Authors QA my work in:
z_test.fos

Production uses:
application.fos

These are stored in the PE custom folder stored locally on the server
hosting PE. Even if the FOSIs are the same, authors and PE are accessing
different physical copies. Sometimes I regret this!

Having to restart PE in 5.3 is going to be a pain. That used to interrupt
client DLM sessions. I haven't validated whether this is still true in 5.3
yet or not. The restart requirement may force me to involve operations staff
if I am unable to have access to the production environment.

[AndyEsslinger]

I know one way to re-read the FOSI without closing the document: Click
on Format->Select Stylesheet, click on modify, pick another style sheet,
click on modify again and reload the original stylesheet with your
changes.

A pain, but it is sometimes faster than closing a document and
re-opening it; especially as some changes (which changes I do not know)
require Epic to be restarted unless you do it this way.

You mighht also look into putting this inside an instance.acl file in
your doctype directory:
set doctypecachesize=0;

Hope this helps,
-Andy
\ / Andy Esslinger LM Aero Tech Order Data
_____-/\-_____ (817) 279-0442 Box 748, Mail Zone 4285
\_\/_/ (817) 777 3047 Ft. Worth, TX 76101-0748

[ptc-953343]

> Hi Dan--
>
> I'm not sure about a complete workflow for FOSI editing, which can be as
> much a matter of personal taste as best practice, but to address your
> specific question of how to refresh the screen view when you update the
> screen FOSI: you can use Revert Stylesheet on the Format menu. (You might
> need to enable Full Menus in preferences to see this.) Contrary to the
> name,
> this doesn't change your stylesheet back to some previous version, but
> rather reloads the stylesheet, which is just what you want in this case.

In reading Suzanne Napoleon's FOSI Turtorial I found a couple of commands
that bring back the FOSI editor environment to Editor.
- sysgroups
- fed

If you use fed, that launches the FOSI in the tag editor view. If you make
a change in that view you can then use File -> Apply FOSI Changes to
update your document view.

I'll probably be creating my own menu items to put these back on the
Editor menus.


>
> I don't think there's a hotkey defined for this by default, but you could
> put some code in your startup file to assign one using the map command.
> The
> ACL command corresponding to the menu item is stylesheet_revert().
>
> BTW, if this is something you'll be doing for a while, you should consider
> attending PTC/USER World Event in June. There's going to be some nice
> content on FOSI there this year. Check it out:
>

[steve.thompson4]

>-----Original Message-----
>From: Dan Vint [

[ptc-953343]

> One caveat re' the FOSI Editor using 'fed' as opposed to starting it from
> Architect:
> The title bar of the FOSI Editor in Architect includes '[public]' in
> identifying the file that's loaded. When opened using 'fed', it includes
> '[private]'. Don't remember right this second all that it signifies, but
> it's not an insignificant difference.
>

It does this from the editor as well in 5.3 at least. The consequence of
public/private is that you can't save changes to the public FOSI. It warns
you of this if you pay attention, and it will allow you to create a new
private FOSI to save the edits. I got bit by this today when I didn't pay
attention to the message that popped up.

This public/private setting doesn't affect the use of the File -> Appply
FOSI Changes though. The Editor window will update, but you probalby can't
test the changes in PE (just a guess).

It looks like the eic command doesn't work properly in the editor window,
but might with the Architect, so that appears to be a difference that
affects the editing.

..dan

[ptc-1908075]

In theory, a public FOSI is the "installed" FOSI, which is not supposed to be edited. However, if a FOSI is located in a different directory or has a different name than the rest of the doctype files, it can be edited and saved.

BTW: Clicking after a tag in the Edit window and entering eic at the command line works for me in 5.3 to open the style panel for that element. You can also click after an e-i-c in the tagged FOSI editor and enter fed_panel() at the command line in the tagged editor to start the corresponding style panel. But you can't resolve a panel started from the tagged editor, only a panel started from the Edit window. And IMHO, Resolve is the best thing that ever happened to a FOSI developer, especially if you're maintaining a FOSI developed by someone else.

<plug>">http://FOSIexpert.com/tutorials.html</plug>

Suzanne Napoleon
www.FOSIexpert.com
"WYSIWYG is last-century technology!"

[ebenton]

You can also use the FOSI panels to re-read the FOSI. Select
Format->Modify Element in Context and within a given panel, click on one
of the "expandable" fields (the ones with bold text content, or with two
little hyphens if there is no content). This should expand the field so
that the text is surrounded by a filled arrow/pointer on each end. Hit
return, then "Apply-> Apply format changes" from the FOSI panel menu.
This will "re-apply" the FOSI without having to close and re-open the
document or switch FOSIs back and forth. (The "Apply format changes"
menu selection will be grayed -out unless you perform the above steps
so that Arbortext thinks you changed something.)

[ptc-953343]

thanks all

I've been fighting a number of PE issues while
trying to also make changes to the FOSI - not a
good situation. I don't remember this being as
hard with just publisher and the FOSI editor but
maybe I'm just getting old and forgetful 😉

..dan

[jkaplansky]

I know of what you speak. I've been watching the various "doors to
FOSI" close throughout the last few releases. While you can get some of
the functionality back up and running in Editor with the commands that
Suzanne has documented, there appears to be some unpredictable behavior
around whether you are working on a public or private FOSI that often
results in making changes to a file that you think is not Read-Only,
only to find that Editor _does_ think the file is Read-Only.

I avoid this by working with doctypes through Epic Architect, which is
very stable with regard to understanding whether or not a FOSI is truly
writable (at least in my experience). The other benefit of this is that
all of the commands that Suzanne documented work just fine in the test
editor, and I have the full breadth of FOSI tools available to me -
style panels, FED, command line, and a known way of forcing the session
to recognize an updated file (edit -current in the FED command line)
without having to shut down and restart Editor, change the stylesheet to
and from, or go through other additional steps.

As for working the FOSI within the PE environment, and constantly
needing to restart Tomcat: I believe you can mitigate the need to
restart Tomcat for every set of changes by actually running Epic
Architect using PE Interactive and developing and testing all of your
changes in this environment, where you don't need to worry about Tomcat.
To do this, I copied the Epic Architect shortcut installed with Styler
and re-directed the startup command to the bin folder in the PE install
path like this: "C:\Program Files\Arbortext\PE\bin\epic.exe" -architect.
This may be as close as you can get to actually editing a FOSI in real
time in PE (albeit, the interactive PE). As an extra QA step, I also do
unit testing with the actual PE Server setup to ensure that that I get
the expected results from the Server that I see in PE Interactive.

Hope this helps.

-Jean K.

[ptc-953343]

At 07:23 PM 3/2/2009, you wrote:
>I avoid this by working with doctypes through Epic Architect, which is
>very stable with regard to understanding whether or not a FOSI is truly
>writable (at least in my experience). The other benefit of this is that
>all of the commands that Suzanne documented work just fine in the test
>editor, and I have the full breadth of FOSI tools available to me -
>style panels, FED, command line, and a known way of forcing the session
>to recognize an updated file (edit -current in the FED command line)
>without having to shut down and restart Editor, change the stylesheet to
>and from, or go through other additional steps.

I went looking at Architect today and didn't see anywhere to launch
the FOSI editor. Are you saying that the fed and eic commands just
work better in the Architect editing window? Did I miss something? I
have pretty much given up on using Architect since XML no longer
requires the DTD to be compiled.



>As for working the FOSI within the PE environment, and constantly
>needing to restart Tomcat: I believe you can mitigate the need to
>restart Tomcat for every set of changes by actually running Epic
>Architect using PE Interactive and developing and testing all of your
>changes in this environment, where you don't need to worry about Tomcat.
>To do this, I copied the Epic Architect shortcut installed with Styler
>and re-directed the startup command to the bin folder in the PE install
>path like this: "C:\Program Files\Arbortext\PE\bin\epic.exe" -architect.
>This may be as close as you can get to actually editing a FOSI in real
>time in PE (albeit, the interactive PE). As an extra QA step, I also do
>unit testing with the actual PE Server setup to ensure that that I get
>the expected results from the Server that I see in PE Interactive.


Well we have another nasty problem there. I have a shared custom
environment and run under Windows. From what I understand a named
user has to be setup to run PE, but that same setup makes it
impossible to launch any of the editors. So to make this work I have
to go into control panel and set the DCOM privileges to allow access
to the editor, which in turn breaks its use for anyone running a job.
It probably keeps me from using the shared custom area out on the network.

At least that is as far as I've taken it, this is one of my PE issues
that I'm trying to work out.

..dan


---------------------------------------------------------------------------
Danny Vint

Panoramic Photography

[ebenton]

We use Print Composer, not PE. Therefore, we have not seen any "doors
to FOSI" close in that domain. It works the same as it did back in
Adept 5.4.1. If PTC ever does away with the Print Composer feature,
however, we will be looking for other software.

[jkaplansky]

Dan -

In Epic Architect, all you have to do is open your doctypes, and then
open a test document via Edit -> Test Document and Stylesheet

Remember also, that you need to have FOSI editing enabled in both your
DCF file and in advanced preferences (FOSIedit="on").

-Jean

[ptc-953343]

In Reply to Paul Nagai:

>>drv So you get around the public/private editing problem with the FOSI editor by working on the local laptop, but to test you then have to copy the FOSI over to custom/doctype area and place it with the DTD - is this correct? Reason I ask is I thought I would create a fosi-dev area in my custom folder, create a directory for each of the DTDs I manage and just put the FOSI I want to edit and test in that area. This doesn't seem to beworking - at least I can't get PE to recognize the path to the FOSI. I've made sure to try "associating" the FOSI with both a mapped drive letter and the UNC file path and neither are working.

The reason I tried setting this fosi-dev area up is I seem to be getting different results; almost like I have 2 different copies of the FOSI. One seems to be seen by the editor and the other by PE. I've created a simple bullet list item. This appears to at least put the bullet in place in the Editor view but doesn't produce anything in the PDF output.

I have an additional complication with this FOSI. I inherited this FOSI and it was setup to use some FOSI fragments/entities. So instead of 1 file I have about 7. The entities in the FOSI would have to be tweaked to point to the test version of the entities vs the released and I would have to remember to copy all the updated files over and change the paths to make it useable for everyone else.

Is this process as bad if you use styler? I'm about ready to bite the bullet on this and switch over.

I just tried using Architect with the fed command and it looks like it says I'm editing a private FOSI but I beleive I'm accessing the public FOSI.

***********************

While working on print FOSI changes (in most cases print and screen are the
same), I do development in:
z_dev.fos

Authors QA my work in:
z_test.fos

Production uses:
application.fos

These are stored in the PE custom folder stored locally on the server
hosting PE. Even if the FOSIs are the same, authors and PE are accessing
different physical copies. Sometimes I regret this!

Having to restart PE in 5.3 is going to be a pain. That used to interrupt
client DLM sessions. I haven't validated whether this is still true in 5.3
yet or not. The restart requirement may force me to involve operations staff
if I am unable to have access to the production environment.

[ptc-953343]

Found it this morning. I thought it would be under Styler I guess, anyway
found it in the format menu.

..dan

> Dan -
>
> In Epic Architect, all you have to do is open your doctypes, and then
> open a test document via Edit -> Test Document and Stylesheet
>
> Remember also, that you need to have FOSI editing enabled in both your
> DCF file and in advanced preferences (FOSIedit="on").
>
> -Jean
>

[ptc-953343]

Remind me, Print composer was limited to a desktop environment - true?
Maybe it was a floating license setup. I beleive I have access to a
license of Publisher, but I don't really want to be the only able to print
the documents we produce.

Is composer able to produce PDF bookmarks? I think that is one of the
short comings I found a few years back and that forced us to go with an
XSL approach instead of FOSI. I also had simple software documentation
where I'm now back into milspec work.

..dan

> We use Print Composer, not PE. Therefore, we have not seen any "doors
> to FOSI" close in that domain. It works the same as it did back in
> Adept 5.4.1. If PTC ever does away with the Print Composer feature,
> however, we will be looking for other software.
>

[naglists]

For print / PE all three FOSIs I named before are in PE's doctype directory
under the application name. So, there is:
pepath/custom/doctypes/appname/z_dev.fos
pepath/custom/doctypes/appname/z_test.fos
pepath/custom/doctypes/appname/appname.fos

I edit z_dev.fos with Text pad across the network. For 5.1 and 5.2, new
composition requests pick up any changes I've made to z_dev.fos
automatically. For 5.3, I'm learning I must restart Tomcat for those changes
to be read. When I'm "done" and want my changes tested, I copy z_dev.fos
over z_test.fos and now my QA authors can test against z_test.fos while, if
necessary, I can begin work immediately on a different change or batch of
changes in z_dev.fos.

I work on FOSI on my laptop only when I am concerned with how something
displays in Editor. Well, I do also try to open XML using the updated
z_dev.fos copied local to my laptop as appname.fos just to be sure I haven't
typo'ed or put something out of order in the FOSI (obviously testing for
these potential gotchas is part of the price I pay for not using
Architect!).

I don't know if I answered your question or not ... keep after me if I
missed the subtlety you're trying to nail down.

[ebenton]

Yes, Print Composer is for desktop publishing. You can use a concurrent
(floating) license for it. It is a separately-licensed feature of
Arbortext Editor. If you want it, you have to do a "custom"
installation and select it from the list in the appropriate dialog box.
Of course, you also need a license for it, either concurrent or fixed.

You can produce PDF bookmarks with it. You need to define your division
tags in your DCF file, among other things, in order to get them. See
the help on this.

[ptc-953343]

good news I just found out at the end of the day that we have
composer as well. I think I will be testing with that. I think I have
to keep PE going so that we can get bookmarks

..dan

[ptc-953343]

At 01:49 PM 3/3/2009, you wrote:
> don't know if I answered your question or not ... keep after me if
> I missed the subtlety you're trying to nail down.

thanks this is what I thought you meant. It looks like you have a
single file fosi so this works. I have a fosi with about 6 other
entities. this was why I hoped to replicate the structure in a
different directory - but that appears to not work.

..dan
---------------------------------------------------------------------------
Danny Vint

Panoramic Photography

[ptc-953343]

At 02:56 PM 3/3/2009, you wrote:
>Yes, Print Composer is for desktop publishing. You can use a concurrent
>(floating) license for it. It is a separately-licensed feature of
>Arbortext Editor. If you want it, you have to do a "custom"
>installation and select it from the list in the appropriate dialog box.
>Of course, you also need a license for it, either concurrent or fixed.
>
>You can produce PDF bookmarks with it. You need to define your division
>tags in your DCF file, among other things, in order to get them. See
>the help on this.

thanks I'll look at that more. it certainly is easier to print this
way. I already did that tonight with a new dtd I installed, but I'm
still struggling with PE

If I can get bookmarks then I don't need PE for now. I'm not doing
anything fancy with it. I may have more questions on the bookmarks,
but I will try that out tomorrow.

..dan
---------------------------------------------------------------------------
Danny Vint

Panoramic Photography

[ebenton]

Try help 5820 (in Editor 5.2)