| CUSTOM.pll size Problem [message #191179] |
Tue, 05 September 2006 02:11  |
omkar@tcs
Messages: 16
Registered: September 2006
|
Junior Member |
|
|
Hi all,
I have come accross a requirement to freeze existing CUSTOM.pll code and make it compusary for all the developers to add new CUSTOM.pll code in new packages and not in existing packages.
We have informed the same to all but due to huge size of organization, its impossible to keep track of each CUSTOM.pll change.
Is there any way to make CUSTOM.pll code readonly
or
can I control the size of the existing package and make them
full so that no body adds code to existing package.
|
|
|
|
|
|
| Re: CUSTOM.pll size Problem [message #191507 is a reply to message #191179] |
Wed, 06 September 2006 15:32  |
adragnes
Messages: 241
Registered: February 2005
Location: Oslo, Norway
|
Senior Member |
|
|
Do you not have any form of version control? All custom developed code should be in some form of version control system such as CVS, Subversion or even Microsoft Visual SourceSafe. With a version control system you will be able to see who did what when, and you can also limit access to specific files to particular developers.
In addition I hope you do not let just every developer migrate code to production. A version control system, procedures for code review and testing and a centralised migration team you should not have the trouble controlling what people do with in the CUSTOM Library you mentioned.
Anyway, since the introduction of Forms Personalisations, there really is not the same need for doing things in the CUSTOM Library. With Forms Personalisations extensions can be migrated on per form or per function basis, which avoids the gridlock one often experiences when using the CUSTOM Library. Who has not experienced having to delay the deployment of a CUSTOM Library extension due to some previous change not having passed testing yet.
(There are ways to get around this by splitting the code into multiple libraries and calling them from the CUSTOM Library, but this has performance implications. Search this forum for previous discussions on this topic for more on this).
--
Aleksander Dragnes
|
|
|
|
| Re: CUSTOM.pll size Problem [message #191566 is a reply to message #191179] |
Thu, 07 September 2006 02:37 |
omkar@tcs
Messages: 16
Registered: September 2006
|
Junior Member |
|
|
Dear Aleksander,
First of all , thanks you for such elaborate information....
I was thinking about mutiple librries and calling them from CSTOM.pll.
Can you please suggest some document or reading material so that i can know the performance inssues..
Omkar Lathkar
|
|
|
|
| Re: CUSTOM.pll size Problem [message #191980 is a reply to message #191566] |
Sat, 09 September 2006 08:47 |
adragnes
Messages: 241
Registered: February 2005
Location: Oslo, Norway
|
Senior Member |
|
|
Omkar,
Personally, I just have multiple packages in the CUSTOM Library, one for each form where there is a need for extensions. If you are working somewhere with a lot of concurrent development of extensions then putting these packages into separate libraries might make sense, but you must consider the fact that there is a performance hit due to these having to be loaded.
The only way to know whether this will be a problem or not is to try. Why not just do the split and benchmark the performance against the existing monolithic CUSTOM Library?
I find that after the advent of Forms personalisation there is not that many extensions that need to be done in the CUSTOM Library itself and the problem with concurrent development of CUSTOM Library extensions has pretty much gone away.
--
Aleksander Dragnes
|
|
|
|
] 
Blog
Search
Help
Members
Register
Login
Home
