Conference iosg::all-in-1_v30

Following up with what Frank is asking about, it would seem to me that
(unavoidably) application areas that have a "duplicate" of something in another
area (OA or otherwise) will have their copy placed into the TXL based on
alphabetical ordering of the application entries.

So if ALL-IN-1 EARS supplies something called X that FOOBAR supplies, the
ALL-IN-1 EARS one makes it into the TXL, unless X also appears in the ABC
application?  If this is true, is there no other means of hierarchy?  It would
seem to be advantageous to be the A package instead of ZZZZ, as A's element
will always be used (except in the case that Frank brought up in .0).  A call
to the support center for ZZZZ would result in lots of "well, you have to
integrate the changes we shipped with those of A and ALL-IN-1 EARS and FOOBAR
and ... before you can see our change, even though our version has all these
changes already in it".

/Marty

    Each application (defined in CM$APP) has a priority number assigned to
    it. The TXL compilation script builds a list of areas to be included
    into the TXL sorted in priority order..... So you can ensure that
    package A gets included before the OA application (ALL-IN-1), which
    ships with a priority value of 50.
    
    Priority orders are processed in descending order. An application with
    priority 10 has precedence over one with a value of 50. Give your
    application a priority value of 25 (for example) to include its
    elements before ALL-IN-1.
    
    Tony
    

    The priority order is based on CM$APP firstly and then CM$MAF so you
    can set the precedence for your areas within an application if so
    desired.
    
    The 'problem' described by Frank is related to the fact that the TXL(s)
    are still system wide and not application-wide. We had lots of
    discussions around using separate application TXLs when designing
    CM+ but unfortunately they did not happen.
    
    A solution to Franks problem would be to have WPPRINT for application X
    install into both base and site areas - as if the element had been
    customized. This would still allow you to check any customizations made
    to the element and to revert back to the base if need be etc. However,
    how would you know which elements were duplicate names of other
    applications? Answer? The CART will tell you if you run it for your
    application.
    
    Kevin

    Hi Frank, Marty,

    A start...

    .1)

    Yes, this situation has definitely crossed our minds, as the situation
    you describe is not a rear one.

    However, we decided to continue with 1 Base and 1 Site TXL. This might 
    put you in the situation you described, the situation of an element which
    appears in more than one area, but will only appear once in the TXL. This
    both for the A1TXL and CMTXL. But this is how the system wide TXL works. 
    It gets nuts with duplicate entries.

    This situation doesn't differ too much from forms of the same name, 
    appearing in multiple libraries; only one can be accessed. However, 
    some manipulation of the OA$FORM_SEARCH_ORDER makes this somewhat more 
    flexible.

    I would disagree on the 'foils the purpose of having customizable 
    application areas'. If you only take the TXL into account, strictly spoken 
    yes, it might look like that. However, seperate applications and 
    application areas do have a lot more advantages in contrast to the 
    situation of V2.*. 

    In case of your example where WPPRINT is supplied again, and the original 
    has been customized and made live, but you want the WPPRINT of your 
    application to be used:

	- Check if the WPPRINT of your application needs to be adjusted
	  for the changes made to the original one (which is not impossible)
	- Make the changes to your WPPRINT
	- Make it live
	- Assign a higher priority to your application (see .2))
	- Compile the TXL

	or:

	- Copy your WPPRINT to Development (no changes to be made)
	- Make it live
	- Assign a higher priority to your application (see .2))
	- Compile the TXL

    (This is as you already suggested, only with the additional 'Priority'
    list). 
 
    One could think of an application specific type of TXL,
    which would be handled as seperate entities in a particular order (or a
    flag should indicate which TXL to check/use), which then would prevent
    the situation just described. The APPLICATION function could play a
    possible role. But I'm very carefull when saying this.

    .2)

    Marty, when the TXL (either one) is compiled, the order is decided according
    to Priority/Alphabet.

    When creating an application, there is a 'Priority' field. By default, the
    priority is '50'. If all applications (and areas within the appllication)
    have priority set to '50', then the alphabet works. However, if, in your
    case, X of FOOBAR should be compiled instead of X of EARS, assign a higher
    priority ('1' is the highest priority, '99' the lowest) to application
    FOOBAR by editing the 'Application' record. 

    This same procedure is possible with an application. If 2 application areas
    contain the same element which should go into the TXL, you can change the
    priority of the application area also.

    The code is as follows:

        FOR CM$APP:PRIORITY DO GET #CM_APP = .CODE \\-
         FOR CM$MAF:PRIORITY WITH .CODE EQS #CM_APP DO GET #CM_AREA = .AREA \\\
          FOR CM$AUTH$LOCATIONS WITH .AREA = #CM_AREA AND .TXL = CM$_Y -

    The Priority secundary key consists of:

        SEG0_LENGTH               2	\
        SEG0_POSITION             363	/ Priority
        SEG1_LENGTH               4	\
        SEG1_POSITION             0	/ Application code

    This means, if all entries have priority '50' the order is decided upon
    the alphabet.

    HTH,

	Simon    

    Just to note that we are working the issue reported in the IPR, and
    hope that we will have good news soon...
    
    Tony

    
    Perhaps I missed this, but I read both the CM and Manager's Guide
    and didn't see anything on it:
    
    When new applications are created, what mechanism controls the opening
    of their associated form libraries and the setting of the appropriate
    search orders for users?  I see how elements are integrated into the
    TXLs, but I don't see how users access forms or non-TXL elements such
    as command procedures for new applications.  What am I missing?
    
    - David
    

    Application initialization, which involves setting of search orders and
    opening of form libraries, as well as checking for access rights etc.,
    is totally the responsibility of the application itself. CM+ makes no
    assumptions about applications and provides no default mechanisms for
    their invocation.  The reasoning behind this is simple - there are so
    many ways that an application is started up in ALL-IN-1, and so many
    good reasons why different approaches are adapted, that we couldn't
    come up with a singular approach that we were happy with as a default.
    
    Cheers, Tony