| Re .1,
But surely we aren't expecting Pam's customer to wait til November for
an answer to this note. I thought we were supposed to help customers.
Re .0,
Ok I'll start the first point and a phrase I believe originated from
the great author himself is "you can use CM in the old way" or
something like that. What that means is that if the customer had their
customisations in CM in v2.4 as modified base elements and new site
elements as part of the OA application then they can continue to do that
in v3.0 and many if not most will.
However if their customisations are more than just change the MAIN
menu type stuff and form a distinct application such as Expenses or
something then there are advantages in making it a seperate application
such as:
o future upgrades to ALL-IN-1 (aka the OA application) can be done
almost seamlessly without affecting the CUST application.
o the CUST application can be transported and restored to other nodes
in the network when new relases of it are made available.
It depends on the type of customisation.
As to ASSETS well I currently live in the U.S where ASSETS no longer
exist so I can't say for sure but in Europe there is still a thriving
ASSETS program that makes money and you should probably contact them
for advice. Personally I wouldn't attempt to port v2.4 compatible
ASSETS to v3.0 yourself but wait until the ASSETS program produces its
v3.0 compatible versions and given that v3.0 versions are being announced
at the rate of one or more a week in this conference it shouldn't be
long before they're all there.
Hope this helps you and your customer a little.
Regards,
Andrew.D.Wicks
|
| I'll tastefully ignore the comments about books etc.
This is how we have handled upgrades for MJU and FCR, both PASS tools
coming to you soon for ALL-IN-1 V3.0.
The elements were either already in CM (from previous development) or
created/loaded in CM. Everything was loaded as site elements, or
customized versions of base elements. In other words, just as if a
customization had been developed on-site. This is the sensible way to
treat things. There is no point in creating an application separate
from OA unless:
- You have a large discrete application which is restricted to a group
of users (or programmers)
- You're building something like Lotus 1-2-3
- You want to anyway, just for the fun of it.
Continuing to work as before allows you to deal with elements in a
familiar manner AND use the new CM+ functionality. We use package and
transfer, for example, to create savesets for MJU and FCR.
The customer is totally free to create their own application and use
that for their core customizations, but I would leave them the way they
are today. If they use a good naming convention (prefix everything
with their own code) then there's no need to go galloping into areas.
Why fix something that isn't broken?
Now to ADW's point regarding ASSETS. To set people's expectations
straight, the packages being upgraded (by my group anyway) are
CHECKMAIL, MJU, and FCR. When we are done with these we won't do any
more unless ASSETS pays us to do so. End of story.
Tony
|
| I would suggest that ALL customisations/applications are recorded in CM
somewhere since this helps supporting the system.
Deciding on where to record the elements (ie. the OA application or a
separate application) is a different matter and some good points have
been raised by Tony.
When deciding whether to create a new application or just add elements
to the OA application you must always consider how your end-users are
going to access the application. CM does not do any of this for you.
The default live locations associated with the OA application are
always accessible (through CMTXL,A1TXL,SITEOAFORM.FLB, OAFORM.FLB etc).
You can always add other live locations if you add your application
elemenst to OA.
If you have a separate application then it will have separate live
locations from the OA application. These live locations will probably have
to be included in OA$FORM_SEARCH_ORDER and OA$FILE_SEARCH_ORDER before
the end-users can access the application.
Kevinz
|