11/27/2024 5:23:45 AM
|
| |
| slxdeveloper.com Community Forums |
|
| |
|
|
The Forums on slxdeveloper.com are now retired. The forum archive will remain available for the time being. Thank you for your participation on slxdeveloper.com!
Forum to discuss writing script in Architect plugins for SalesLogix & general SalesLogix customization topics (for Windows client only). View the code of conduct for posting guidelines.
|
|
|
|
Best Practice - MainView naming
Posted: 17 Feb 07 6:37 AM
|
fiogf49gjkf0d I feel a bit silly for asking this, but trying to get my brain around the correct approach.
Whenever one makes a modification to an OOB form, such as Contact Detail, the best practice is to give it a new name, e.g. C_Contact Details - MyCompany. Otherwise an upgrade could overwrite all of one's fine work. Easy enough.
And once created, its also quite simple, then, to change the form that is displayed in the existing Contact Details MainView, from Contact Detail to C_Contact Details - MyCompany. But that bothers me a bit, since I am changing an OOB MainView...
However, if I instead save this tweaked MainView as C_MV Contact Details, there are probably 23 places in menus, forms, toolbars and navbars that would have to be changed to launch this new MainView, right?
So what's the opinion on best practice for naming modifications to the OOB TACO MainViews? Or am I missing somthing here? |
|
|
|
Re: Best Practice - MainView naming
Posted: 17 Feb 07 7:25 AM
|
fiogf49gjkf0d Just to clarify 1 point , during an upgrade SalesLogix does not overwrite an existing form, it simply unreleases and then releases the new form.
After the upgrade process is finished it is a 'simple' process of comparing your original custom form and the new SalesLogix form, merging your customization into the new SalesLogix form and releasing it.
|
|
|
|
Re: Best Practice - MainView naming
Posted: 17 Feb 07 9:30 AM
|
fiogf49gjkf0d That line of thinking, naming a changed form something else like with a "C_" prefix, only applied to pre-v6 days. You don't have to worry about all that with the versioning built into v6 and higher. Never change the names of plugins now. That way you won't need to change all the many places where the form/mainview/script is invoked. You won't loose your work since your modified plugin will be a different version (which includes the company name as well).
Make sense? |
|
|
|
Re: Best Practice - MainView naming
Posted: 17 Feb 07 10:44 AM
|
fiogf49gjkf0d Hey Ryan and Tony, thanls.
That's a refreshing perspective, and makes life simpler (I think). Last year in the week-long Sage SalesLogix Developer course in Scottsdale for v6, the necessity of naming plugins with, for example, "C_" prefix was emphasized... Perhaps I missed a a distinction between modified OOB plugins and de novo plugins created by the developer?
It does make it easier to find non-SLX plugins when they have a different prefix, especially since our db (most, perhaps?) have OOB plugins authored by both Legacy and SalesLogix. But using Author is an adequate way of distinguishing them.
So if I interpret this correctly, when a developer modifies Contact Detail (for example), it should NOT be renamed. And if a Service Pack provides a new version of Contact Detail, it will unrelease the developer's version, and the developer would then need to examine the new form, and recreate any mods, right?
I'm digging deep into this because our 6.2.3 db still has modified Legacy Contact Detail (and Account Detail) forms being displayed within the non-Legacy MainViews. In working to recreate these mods on the current v6 Contact Detail form, the issue of appropriate naming arose.
I'm clear now, unless the above text indicates I'm still not interpreting correctly |
|
|
|
Re: Best Practice - MainView naming
Posted: 17 Feb 07 2:36 PM
|
fiogf49gjkf0d We still emphasize this in the 7 class (that I teach)...
I was always told this and never had occasion to test it (but I believe you)/.
Ryan what do you prefix new forms with? |
|
|
|
Re: Best Practice - MainView naming
Posted: 17 Feb 07 3:20 PM
|
fiogf49gjkf0d My opinion is that naming with "C_" no longer has any value. SalesLogix plugins can always be identified by the author name and/or company name.
That being said, using the C_ naming convention doesn't hurt either . This should only apply to custom plugins however, and not modified plugins. I can't think of a reason to change the name of a stock plugin. As Ryan mentions it just makes you go change a bunch of code/menus/toolbars/configuration settings/etc. to point to the new name. What a PITA.
Timmus |
|
|
| |
|
Re: Best Practice - MainView naming
Posted: 18 Feb 07 5:29 AM
|
fiogf49gjkf0d I agree with Ryan / Timmus - there is no longer any need to do this any longer. I'm still working with a 5.2 db where this was used heavilty and it's just horrible to work with ! |
|
|
|
Re: Best Practice - MainView naming
Posted: 18 Feb 07 2:35 PM
|
fiogf49gjkf0d Same here. I stopped creating "custom" names (BTW.. NEVER used C_ for anything at verson 6.0 for Forms, scripts, etc. Total waste of effort to do so and results in a mess where you have to re-point things, etc.
Even on 5.2 I did not create "custom" names, Just saved a copy of the originals (views/scripts) as Whatever_OOTB.
--
rjl |
|
|
|
Re: Best Practice - MainView naming
Posted: 18 Feb 07 9:20 PM
|
fiogf49gjkf0d Originally posted by Jason Huber
Ryan what do you prefix new forms with? |
|
I don't prefix my custom forms/scripts with anything. Since all plugins are identified by version and company name, it is easy to see which ones are mine and which ones are the OOTB plugins.
The idea of changing the name, and adding prefixes like the "C_", was done in the past for the following reasons:
1) To avoid getting plugins overwritten (main reason)
2) so that your custom plugins were easier to identify
With versioning in v6 #1 is no longer the case and certainly not needed. Your custom plugin will not be overwritten by any other bundle because it has a unique company name and it's own version. If I modify the "System:Account Detail" form and then apply a SP from SLX that has a new version of the System:Account Detail form, it's company name and version will be different than mine, so they will not be seen as the same plugin, but two different plugins with the same name. My plugin will not be overwritten by the other in the SP because the one in the SP has a company name of "SalesLogix" and a version of "7.0.1" and mine has a company of "Customer FX Corporation" with a version of "2.0.3" (even if mine also was version 7.0.1 it wouldn't matter, the company name is different).
As for #2, since all plugins will carry my company name, as defined in the options in Architect, I can easily identify my own custom plugins and any plugins from other vendors by sorting or filtering on the company name. I can see all OOTB plugins by viewing only those with the company name "SalesLogix".
I like to just name a form what makes sense. No cryptic names or prefixes, just a simple name that describes what the form is for.
-Ryan |
|
|
|
Re: Best Practice - MainView naming
Posted: 19 Feb 07 9:20 AM
|
fiogf49gjkf0d It should be mentioned that naming of custom tables and fields is another topic. For custom tables/fields, SalesLogix may introduce the same table name or field name in a future release. You should consider this when naming these elements. Those still make sense to have a custom naming process. |
|
|
|
Re: Best Practice - MainView naming
Posted: 19 Feb 07 10:21 AM
|
fiogf49gjkf0d Good point. Also, reports do not have any built in versioning, so use caution when modifying those (if there is a potential to have a bundle that could overwrite your report. Not sure which is better - rename the report or keep a backup copy (which is what I do), but still something to look out for. |
|
|
|
You can
subscribe to receive a daily forum digest in your
user profile. View the site code
of conduct for posting guidelines.
 Forum RSS Feed - Subscribe to the forum RSS feed to keep on top of the latest forum activity!
|
|
|
|
|
|
|
|