rbMan 0.7 (resource bundle manager) updated
rbMan is a cfmx app used for managing java resource bundles. It can be intergrated into other apps or run as a stand alone web based editor. The beauty of it being web based is that your translators can work on a live app from anywhere around the world without having to install any third party software. For more info on what's been updated have a look at the release notes @ http://www.jmpj.net/rbman/ ...
The current version uses the Model Glue framework, but can be easily adapted to whichever framework you like.
If you have any feedback I would love to hear it.
- Jason's blog
- 323 reads
Comments
Jason, does rbMan play nice with rbManager (IBM's tool)? Looks like it could be a quick alternative.
I'd be interested in integrating something like this for the FarCry community, though I'd have to have a think about how we synch it up with our version control and code release process.
I may have this all wrong, but I thought that typically there was a bundle per locale, and that bundles had the concept of groups of entries/properties and the option for a comment against each entry. rbMan appears to have lots of bundles prefaced with the word group, is this an alternative approach to say rbManager?
just saw this. jason, javaRB/rbJava read in rb files & return a cf structure but what you do with them afterwards is the app's business. we typically load these into application scope just the once (lazily or all at once depending on the locale/users being served), not re-read on every page (though matt robertson says it's actually not that bad).
...and the last time i looked your app too *ate* rbManager's management code (which seems to be the standard behavior). so no, it doesn't play nicely w/rbManager.
first off rbManager is from IBM, not my shop. more importantly, your note implies just "comments" but that's where rbManager stores it's control codes. when your app eats the comments, it makes rbManager blind & deaf about what's been done to that rb file.
Hi - I am having in issue with rbMan writing back to the config file. The problem occurs in:
org\rbMan\configDAO.cfc:46
It's basically failing on <cfset XMLtext=ToString(arguments.config.getConfig())>
Something in the XML chockes the ToString() functions, and I can't get any info on the ToString function outside the CFDocs. It doesn't even throw a meaningful error.
I am however able to dump arguments.config.getConfig() via CFDUMP and it does get rendered properly.
Thanks for any help!
Hi Stas, thanks for letting me know. Are you using cf6? I believe there was a problem with the ToString funcion in CF6, but one of the updaters fixed it. It would help if you'd post the actual exception info...Anyhow, despite you problem with the old version, I'm releasing a new version in the next day or two with a Flex front end and a database backend.. It's a much more flexible and robust solution.. Watch this space in the next couple of days.
Hi Jason,
I am not quite sure if it's 6 or 7, definitely MX. The problem is, there is no exception code. It just fails on the ToString func, and according to CFMX docs, the function doesn't provide any info on why the error occurs.
Unfortunately, I don't thing a new version will help, as the one I am using is a part of a shopping cart solution that has some integrated cfqueries and I'm a quite sure I won't have time to roll in app specific code.
Would you be able to recall wich patched fixed the issue so I could let me hosting company know?
Thank you,
Stas
stas, you might want to try wrapping the toString() method in a try catch and email the catch dump to yourself. i.e.
<cftry>
<cfset toString(xmlObject) />
<cfcatch>
<cfmail from="blah@blah.net" to="blah@blah.net" subject="Exception" type="html">
<cfdump var="#cfcatch#">
</cfmail>
</cfcatch>
</cftry>
Hey Jason - I was just checking out the rb Manager - looks like it will be exactly what I'd need - and downloadded the fusebox version - as our application will be fusebox as well, I figured this would work well -
One thing I noticed when editing a properties file that I already had in existance, was that if i didn't add in a 'comment' into the bottom 'Editor Comments' field in main.edit, that it would tell me that it could not update. Turns out it was throwing an error in rbMan.cfc that 'One of the key values was empty.' as the form text area had no data in it. It wasn't clear as to why the original update would not work - but after commenting out the cftry/catch block, that message was shown and I could then determine it was b/c I had nothing in that field.
Maybe some simple client side validation or * required fields would prevent this - just a thought in case others ran into it -
Great Stuff - thanks a bunch! Happy Holidays
Kevin Penny
one more comment on the .7 release - I found that it was not deleting individual keys from the edit bundle page - found the issue - line 179 rbMan.cfc -
if (NOT ListFindNoCase(arguments.formData.deletekey, thisKey))
should be
if (NOT ListFindNoCase(arguments.formData.deletekey, keyPart)) instead.
Also for those of you upgrading from the fusebox version to the new.7 version - the dsp_editBundle page will have to reference the 'getKeyvalue' of the thisRB values and baseRB in the display page - as well as line 70 setting rbKeys = thisRB.getKeyArray() and line 72 baseRBKeys = baseRB.getKeyArray() -
That, plus the initApp in fusebox version no longer should check for a results.success - upon init.
Hope that helps someone -
Hello, is this version still available, the page seems to be unavailable?
Hi Geoff,
> does rbMan play nice with rbManager (IBM's tool)?
rbMan will work with rbManager bundles, but not exactly the same way. It uses java the java.util.Properties class to read and write the bundles, so all your bundle keys will remain in tact, but you'll lose your comments on each key. The comments for each bundle are stored in a separtate xml config file. I opted only to use a single comment block for an entire bundle because I though having a comment for each key was a bit of overkill.
> I'd be interested in integrating something like
> this for the FarCry community, though I'd have
> to have a think about how we synch it up with
> our version control and code release process.
I believe you use Paul Hastings bundle reader in Farcry. The bundles produced with rbMan will work with it in the same way and you'd be able to manually intergrate them with your cvs, etc if you want, but the idea behind rbMan is that it runs as an integrated part of your app. It creates a bundle collection that's stored in memory, thereby removing the need to read your bundles in from file each time a page is loaded. The editor can also be integrated into your app and the bundles can be translated on the fly. If add another locale to a live app the properties will initially appear in the base locale and propogate through the app as they're translated. Unfortunately, there's no mechanism for posting drafts to be validated for publishing, but this may be a feature to put down on the todo list.
> I thought that typically there was a bundle per
> locale, and that bundles had the concept of
> groups of entries/properties
The problem with that approach is that all your keys need to be unique per bundle. In a large project this could get a bit out of hand. I typically us a bundle per page.
> rbMan appears to have lots of bundles prefaced
> with the word group, is this an alternative
> approach to say rbManager?
This was the simplest way I could think of to group bundles automatically. If you add a new bundle with a different prefix it will create a new group on the fly. However, grouping is not manditory.
Hi Paul,
I didn't mean to imply that with javaRB/rbJava you had to read your bundles in on every request...sorry about that. I was just pointing out that rbMan would manage the in memory bundle collection for you.
Regarding eating your rbManager bundles, I thought i made it pretty clear in my previous comment.. i.e.
>rbMan will work with rbManager bundles, but not
>exactly the same way. It uses java the
>java.util.Properties class to read and write the
>bundles, so all your bundle keys will remain in
>tact, but you'll lose your comments on each key.
That's right Paul, all the rbManager control codes are stored in the comments. That's why I explicitly stated that they would be deleted. rbManager from IBM doesn't use standard java properties files, so from my point of view i'm sticking to the standards and putting all my control code in an xml config file. Personally, I think it's a bit of a dodgy work around to hijack the comments to use them for config data. Config data should be kept separate in my honest opinion..
Hi Kevin,
thanks for the info. Unfortunately, I'm not maintaining the 0.7 version any more. I know there are issues in it, but i just don't have the time to keep both versions up to date. The flex version is much better that the old 0.7 release. I'd really recommend using it instead .. even though your application is running in fusebox, you can still run rbMan2 independently and integrate it with your apps authentication mechanism. More info on that here: http://www.jmpj.net/jason/page.cfm/RbMan2
Post new comment