Accessing variables in alfresco-global.properties in YUI/FTL
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-09-2012 08:30 AM
(Alfresco version 3.4.8 )
How do I go about accessing properties in alfresco-global.properties within YUI js files or Freemarker FTL files?
I have a set of custom variables, and have extended the javascript api to give me my own custom object, with several methods that extend the object. So for instance:
myapp.getNetworkName();
When called from the javascript console in share (or in webscripts) would return the value of myapp.network.name property set in alfresco-global.properties. The problem is I am uncertain of how I would access this custom "myapp" object from within YUI or Freemarker. Is it even necessary to have these custom javascript calls, when there may already be a method available to call for properties in alfresco-global.properties?
How do I go about accessing properties in alfresco-global.properties within YUI js files or Freemarker FTL files?
I have a set of custom variables, and have extended the javascript api to give me my own custom object, with several methods that extend the object. So for instance:
myapp.getNetworkName();
When called from the javascript console in share (or in webscripts) would return the value of myapp.network.name property set in alfresco-global.properties. The problem is I am uncertain of how I would access this custom "myapp" object from within YUI or Freemarker. Is it even necessary to have these custom javascript calls, when there may already be a method available to call for properties in alfresco-global.properties?
Labels:
- Labels:
-
Archive
3 REPLIES 3
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-10-2012 05:35 PM
Hello,
the settings in alfresco-global.properties are - in a standard Alfresco - only accessible from code within the Alfresco Repository classpath. You cannot access it from Share web scripts or even YUI client code - unless you extend Share in such a way that it also loads the configuration and exposes it to the relevant components.
Your custom JavaScript API objects on the Repository tier are the proper way to make the settings from alfresco-global.properties available to logic. This is based on the general concepts and architecture of the Spring IoC / DI framework, which glues your configuration options and custom API together. Other than via Spring and (custom) object instantiation, you cannot access these settings (without accessing low-level Spring API directly).
Regards
Axel
the settings in alfresco-global.properties are - in a standard Alfresco - only accessible from code within the Alfresco Repository classpath. You cannot access it from Share web scripts or even YUI client code - unless you extend Share in such a way that it also loads the configuration and exposes it to the relevant components.
Your custom JavaScript API objects on the Repository tier are the proper way to make the settings from alfresco-global.properties available to logic. This is based on the general concepts and architecture of the Spring IoC / DI framework, which glues your configuration options and custom API together. Other than via Spring and (custom) object instantiation, you cannot access these settings (without accessing low-level Spring API directly).
Regards
Axel
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-11-2012 09:22 AM
Thanks for the response Axel.
Maybe I am approaching my situation incorrectly then, given the amount of effort required to expose specific properties in alfresco-global.properties. Maybe you have a cleaner, more efficient solution.
The overall end goal is that we have several different instances of Alfresco being utilized on several different intranets. Each installation on each intranet has a (varying from subtle to obvious) different set of requirements for the user interface. I figured if I expose an identifying string in alfresco-global.properties, I'd be able to manipulate the display as necessary based off the values. Is there a better location to or method to achieve this goal? We've found that the customizations made to the interface are quite extensive, and would prefer not to have to pollute our ant scripts any more than we already have if at all possible.
Thanks.
Maybe I am approaching my situation incorrectly then, given the amount of effort required to expose specific properties in alfresco-global.properties. Maybe you have a cleaner, more efficient solution.
The overall end goal is that we have several different instances of Alfresco being utilized on several different intranets. Each installation on each intranet has a (varying from subtle to obvious) different set of requirements for the user interface. I figured if I expose an identifying string in alfresco-global.properties, I'd be able to manipulate the display as necessary based off the values. Is there a better location to or method to achieve this goal? We've found that the customizations made to the interface are quite extensive, and would prefer not to have to pollute our ant scripts any more than we already have if at all possible.
Thanks.
Options
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎07-11-2012 10:17 AM
Hello,
I prefer to use "alfresco-config" XML for almost everything other than technical configuration. Only stuff like ports, hostnames etc. make it in alfresco-global.properties and everything else lands in some *-config.xml. The advantage of this is that you can bootstrap *-config.xml into the ConfigService which provides a standard API to retrieve any configuration at runtime and also to perform configuration selections. This way, you could provide all the different configuration options for the different environments in one XML and select the appropriate parts during runtime based on your environment identifier (provided via alfresco-global.properties / JNDI or a separate *-config.xml).
Regards
Axel
I prefer to use "alfresco-config" XML for almost everything other than technical configuration. Only stuff like ports, hostnames etc. make it in alfresco-global.properties and everything else lands in some *-config.xml. The advantage of this is that you can bootstrap *-config.xml into the ConfigService which provides a standard API to retrieve any configuration at runtime and also to perform configuration selections. This way, you could provide all the different configuration options for the different environments in one XML and select the appropriate parts during runtime based on your environment identifier (provided via alfresco-global.properties / JNDI or a separate *-config.xml).
Regards
Axel