FOSI - multiple levels of logic testing

Forum|Forum|15 years ago
August 19, 2010
19 replies
3029 views

I'm running into a situation where the programmer in me wants to use a
structure that would look like this:

if ((type='checklist') and (foo='1' or foo='2' or foo='3')) then ...

Attribute rules seem to be the place to do this but they don't nest. I
think I've worked around this in a case or two by introducing
pseudo-elements so I can split some of this processing out. Is this my
only option? that seems like a complicated workaround for something that
is so easy to express.

My problem is that I have an existing stylesheet that is fairly complete
but it only formats the tech manaul. Not sure how they intended to handle
all the possible variations that are required. I want to leverage this
stylesheet to make a checklist version that has a few things different in
presentation, primary one being the page size, but there are also some
numbering and linking differences as well. This impacts a fair number of
elements and is getting out of hand.

I have been working with 2 levels of logic, but now I found a requirement
for a third, not sure what else I might find.

I've also thought about creating 2 stylesheets and sharing some of the
common element definitions. This works well with the tagged FOSI view, but
entities don't work well in the other FOSI panels. Maybe I just have to
bite the bullet here and start carving thsi stylesheet up?

Any ideas are appreciated.

thanks
..dan

Show previous replies

steve.thompson4

1-Visitor

I'm definitely with Lynn on that one. I only use the panels when there's any question which e-i-c is actually being triggered by the context. The engine occasionally picks a slightly different interpretation of context than seems obvious, at least to me.

Steve Thompson
+1(316)977-0515

ebenton

1-Visitor

On the other hand, editing in tagged mode and with the panels prevents you from creating typos. You can't accidentally leave out any quotation marks or angle brackets.

steve.thompson4

1-Visitor

Sorry. I was insufficiently explicit. My editing is primarily tagged mode. Anything else, including the "in Context" panels, is strictly in support of that mode. Thoroughly agree about the safeguards of tagged mode.

Steve Thompson
+1(316)977-0515

ptc-1908075

1-Visitor

Both FOSI interfaces have their strengths. In my experience, utilizing the best
of both can make FOSI development and maintenance faster and easier.

The FOSI style panels interface has several very nice features that are not
available with the tagged editor:
* You can start a style panel from the document in order to see easily exactly
which e-i-c is being matched. This can be a huge time saver.
* You can find the next element(s) in the document that match(es) the element
in the style panel.
* Using Resolve in a style panel traces the source of each characteristic value
in the e-i-c and enables display of their style panels, which is another huge
time saver.
* You can use the Query menu in the All FOSI Components panel and the All
Elements-in-Context panel to find elements by name or expression and list them
in a separate panel, from which you can start a panel for the desired e-i-cs.
* The Query menu has an item to find and list all e-i-cs in the FOSI that do
not match elements in the DTD (which makes them pseudo-elements). Check this
list for typos that could be turning DTD elements into pseudo-elements.
* Another Query item finds all DTD elements that do not have e-i-cs in the
FOSI. If nothing is listed, maybe the FOSI is finished 🙂
* You can be in more than one place in the FOSI at the same time. For example,
you can display panels for All Counters, All Text Variables, All
Elements-in-Context, All Float Locations, on screen at the same time. This
eliminates a lot of time-consuming scrolling in the tagged editor.
* The page layout panels are helpful in understanding and coding pagesets,
quintuples, and anything else page-related. The calculation capability is great!
It shows the calculated flowtext depth and also indicates when a change to a
page layout value requires a re-calculation.
* You can link from a style panel to the corresponding place in the tagged
editor.
The FOSI tagged editor has its own features, some of which are necessary but not
available in the style panels interface:
* Entities can be declared, displayed, counted, and found.
* Some things can only be entered in the tagged editor, such as specifying
gitype.
* The tagged FOSI editor is based on the Editor, with similar menus.
* As in the Editor, ACL can be entered or sourced at the command line to
manipulate the tagged FOSI just like a document in the Editor. For example,
keymappings, while loops, etc., can be used to make repetitive changes.
* The Show Ids panel is very useful for fixing completeness and compile errors;
locating each use of charsubsets, counters, strings, float locations, etc.;
finding string variables that are not declared and initialized.
* A FOSI in the tagged editor can be formatted with a FOSI. I use this
capability to highlight stuff such as variables with certain names; categories
such as Reset; Specvals that apply only to the Edit window display; etc.
Sometimes, though, an ascii editor is the quickest way to go; for example, when
you want to change the name of a variable or charsubset or whatever that is used
dozens or hundreds of times in a FOSI. Just take care not to do anything that
will make the FOSI out of context.

Suzanne

ptc-953343

Author

1-Visitor

I like having the FOSI panels available. If nothing else they make a FOSI
more readable. Somethings are still hidden and tricky to get to, and
eventually you just get too many panels open. As Suzanne mentions there
are a lot of nice features that can make life easier.

BUT as I start to take advanatage of standard things like entities, the
panels stop displaying information.

I switch to the tagged view when doing big changes and also use TextPad.
Problen with direct editing in textpad is if you use some of the other
editors the file gets locked.

So yes, each has its place in my day to day work 😉

..dan

> Both FOSI interfaces have their strengths. In my experience, utilizing the
> best
> of both can make FOSI development and maintenance faster and easier.
>
> The FOSI style panels interface has several very nice features that are
> not
> available with the tagged editor:
> * You can start a style panel from the document in order to see easily
> exactly
> which e-i-c is being matched. This can be a huge time saver.
> * You can find the next element(s) in the document that match(es) the
> element
> in the style panel.
> * Using Resolve in a style panel traces the source of each characteristic
> value
> in the e-i-c and enables display of their style panels, which is another
> huge
> time saver.
> * You can use the Query menu in the All FOSI Components panel and the All
> Elements-in-Context panel to find elements by name or expression and list
> them
> in a separate panel, from which you can start a panel for the desired
> e-i-cs.
> * The Query menu has an item to find and list all e-i-cs in the FOSI that
> do
> not match elements in the DTD (which makes them pseudo-elements). Check
> this
> list for typos that could be turning DTD elements into pseudo-elements.
> * Another Query item finds all DTD elements that do not have e-i-cs in
> the
> FOSI. If nothing is listed, maybe the FOSI is finished 🙂
> * You can be in more than one place in the FOSI at the same time. For
> example,
> you can display panels for All Counters, All Text Variables, All
> Elements-in-Context, All Float Locations, on screen at the same time. This
> eliminates a lot of time-consuming scrolling in the tagged editor.
> * The page layout panels are helpful in understanding and coding
> pagesets,
> quintuples, and anything else page-related. The calculation capability is
> great!
> It shows the calculated flowtext depth and also indicates when a change to
> a
> page layout value requires a re-calculation.
> * You can link from a style panel to the corresponding place in the
> tagged
> editor.
> The FOSI tagged editor has its own features, some of which are necessary
> but not
> available in the style panels interface:
> * Entities can be declared, displayed, counted, and found.
> * Some things can only be entered in the tagged editor, such as
> specifying
> gitype.
> * The tagged FOSI editor is based on the Editor, with similar menus.
> * As in the Editor, ACL can be entered or sourced at the command line to
> manipulate the tagged FOSI just like a document in the Editor. For
> example,
> keymappings, while loops, etc., can be used to make repetitive changes.
> * The Show Ids panel is very useful for fixing completeness and compile
> errors;
> locating each use of charsubsets, counters, strings, float locations,
> etc.;
> finding string variables that are not declared and initialized.
> * A FOSI in the tagged editor can be formatted with a FOSI. I use this
> capability to highlight stuff such as variables with certain names;
> categories
> such as Reset; Specvals that apply only to the Edit window display; etc.
> Sometimes, though, an ascii editor is the quickest way to go; for example,
> when
> you want to change the name of a variable or charsubset or whatever that
> is used
> dozens or hundreds of times in a FOSI. Just take care not to do anything
> that
> will make the FOSI out of context.
>
> Suzanne
>

ptc-953343

Author

1-Visitor

At 07:27 PM 8/22/2010, you wrote:
>I think David is on the right track about setting things up at the
>document level whenever possible. With this approach, attribute
>testing is performed once, eliminating the need for lots of
>attribute testing in lots of e-i-cs. This may be opposite to the way
>it would be done in XSL. However, in FOSI, the one thing that will
>negatively affect FOSI performance is too many attribute tests
>and/or system-funcs.

So to extract this back to the original question. For all the
possible combinations of tests that I might need for my 10
configurations with 3 different options, I would at the top level do
those tests and create an element that flags if present (or not).

Then later at the individual element level where I need to check the
state I would just look for the presence of a given element? I don't
know if this simplifies things or not. I maybe reducing some of the
logic, but it still seems like I have to check now for one of these
elements. So if I had 30 conditions I was tracking, I would do that
complex logic at the top level once, but at individual elements in
the body, I still might have 30 conditions to check. At the element
level I guess I might be down to a yes/no test so that instead of all
the logic being repeated and tested all over the place.

Is that what is being recommended? I don't see how I can remove all
the tests when I finally need the formatting information, but I can
see that maybe this simplifies things.

So is there an easy way to debug/test pseudo elements? What I mean is
can I display them to see if they are in-line and in situations where
they have content show that content? I'm worried that I might be
thinking they are set and their not or worst, I have a typo somewhere
that prevents something from working - done that a few times even
with regular elements or contexts 😉

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

Panoramic Photography

DavidS.Taylor

1-Visitor

Hi Dan,

Referring to the brief example Suzanne sent last Sunday, the purpose of testing for your configuration and options at the top level can go beyond just setting a flag. It's possible to set up the category and characteristic parameters that need to be different for each output right at the start, using string variables and pseudo-elements. At the e-i-c where a different output format is needed, there is no test required. The category and/or characteristic values are filled by referencing the variables and pseudo-elements set up at the top level.

In the example, the <toptag> 'type' attribute determines which pseudo-element is called when 'variable.txt' is used in <childelement1> or <childelement2>. They don't require any attribute rules to determine what to output.

Hopefully you can apply this to your situation, even though the example is necessarily limited. This is also an illustration of why it is sometimes necessary to work in the FOSI tag view. Doing this using the panels could be much more difficult to follow.

I work in the tag view 95% of the time as I find it much faster. The panel view is very useful for testing and troubleshooting when something isn't coming out as expected.

Hope this helps a bit more.

Cheers,

David

David S. Taylor

Project Manager, Structured Information
Institute for Research in Construction
National Research Council Canada
Bldg. M-23A, Room 239
1200 Montreal Road, Ottawa, ON K1A 0R6

ptc-1908075

1-Visitor

You are on the right track. Keep trying to find ways to avoid as many test as
you can because too many atts really slow down the formatting speed.

Anonymous

I have been using tagged view for most of my FOSI editing; I do use a
lot of entities in the FOSI and you can have trouble seeing (and
editing) them from the panels.

But yes, the panels are great for troubleshooting and finding the e-i-c
being triggered for the element you're trying to format.

One caveat with the style panels (this may be isolated to 5.3), if you
are trying to copy and paste a pageset quint, sometimes the panels get
screwy and you can lose a whole pageset (I have cursed this more than
once).

So, based on my experiences with the FOSI panels, working in
pagesets/pagespecs is MUCH safer in tagged mode or ASCII editor.

-Jason

Sign up

Please use your PTC eSupport account.

Welcome to the PTC Community

Please use your PTC eSupport account.

Scanning file for viruses.

This file cannot be downloaded