Peter,
 
Sounds like you're loading all the bundles into the app scope at startup?  That's probably workable and would eliminate the need for view specific files.  The main issue is that preMX code had properties files being written for each view.  The file would be included if it was there but all the properties weren't loaded at once.  They were only loaded as needed and we put them into the request scope.  Now, we had a global properties file that was in the app scope for things like error messages, field labels, formats, etc.  But it got unweildy to have one file and the content management system was built to have a properties file per web page (which is a slightly different concept anyways since a MachII request can consist of many views).
 
long story i know.  sorry.
 
so, we're moving things over to MachII and I was just trying to duplicate the loading of a properties file per view functionality.  (each view on any given request is of course in the same locale.)
 
for example:
 
    <cffunction name="localizeView" displayname="Localize View" hint="Loads the properties file for the given view."
        output="false" returntype="void" access="public">
 
        <!--- define arguments --->
        <cfargument name="viewName" type="string" required="true" hint="This is the name of the view to localize.  Note: it's an alias from the MachII config.xml" />
 
        <!--- define local vars --->
        <cfset var viewNameTranslated = "" />
 
        <!--- execute actions for this method --->
        <cfset viewNameTranslated = replaceNoCase(arguments.viewName, ".", "/", "ALL") />
        <cftry>
            <cfinclude template="#getConstantsBean().getAppPath()#properties/views/#viewNameTranslated#_#request.locale#.cfm" />
            <cfcatch type="missingInclude">
            </cfcatch>
            <cfcatch type="any">
                <cfrethrow />
            </cfcatch>
        </cftry>
 
    </cffunction>
 
this would load a page like this:
 
<cfscript>
request.properties["someString"] = "Hoyven Mayven pickle matrix";
request.properties["someOtherString"] = "All work and no play.";
</cfscript>
 
There's no performance issues and the maintenance has been super easy to do it this way.  Now I could put it all into the app scope but I didn't want to change what I was doing on this just yet if I didn't have too.  :)
 
See what i mean?  anywho... if I can't get the viewName at this point it's not the end of the world...  just need to work on migrating it over to the app scope entirely.
 
-greg
 
 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Peter J. Farrell
Sent: Tuesday, May 23, 2006 4:10 PM
To: [email protected]
Subject: Spam:*****, Re: [CFCDev] Re: MachII Plugin...

Greg Brown said the following on 5/23/2006 5:40 PM:
Master P,
 
There's a list for MachII on CFC Dev?  I'll have to check that out.
Actually, it's at Topica (It's the official Mach-II list as well):
http://lists.topica.com/lists/mach-ii-coldfusion/read
anyways... so the goal of this is to prepare or load a properties file that is then used by a resource bundle in the view.  if i can build it into the plugin i have the plugin load the bundle for that view and i don't have to repeat myself in every view.  then all i need to do in my views is rb.getString("stringName").  i'm aware of the connection to the framework but I'm okay with this minor connection as it's easily implemented elsewhere.
 
right now i have a function in all the views to get the localized information.
<cfset localizeView(arguments.viewName) />
 
the preView seems ideal.  what do you think?  any other solutions that would be more ideal in your opinion?
Just trying to figure out why you need the view name?  Are you display some views that would be english and other that would a different language (meaning you have multiple views being put together in a single request)?  Usually, I would suspect that the whole request is going to be in a certain locale and not switching the locales based on which view is being used.

Matt and I loading the rb bundles on the preEvent plugin point in one of plugins for MachBlog.  This is all done through a facade which is being managed by ColdSpring, but there is also a reference that we set in the Mach-II properties.  All be have to do is something like this when we need a resource bundle resource:

#getProperty("resourceBundleFacade").getResourceBundle().getResource("more")#

Although we're dealing we one locale per blog which can be changed.  I don't see why you can't inject the required RB into the event object in the preview if it's missing - all based on the locale being served.  Just still trying to figure out why you need to know the view name in order to serve the correct locale RB.  Maybe you can post your localizeView function?  So I can see what info it is giving you - that way I might get better insight into this.
thanks in advance for your thoughts.
 
-greg
 
btw.  love the cfweekly.  good stuff.
Thanks about the ColdFusion Weekly.  All I can say is that the best kudos Matt and I can receive is a call for the query, quiz or listener feedback.  Call us! Don't be shy... ;-)

HTH,
.Peter
-- 
Peter J. Farrell - Maestro Publishing
Certified Adobe ColdFusion MX7 Developer
Member Team Mach-II and Team Fusion
--
Co-Host of the ColdFusion Weekly Podcast
The "Virtually Live" Call-In Show
http://www.coldfusionweekly.com



----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email.

CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com).

An archive of the CFCDev list is available at www.mail-archive.com/[email protected]

Reply via email to