I think that the extended object approach would have its advantages - in the
case of wide-application string sets, a developer could simply include any
additional string packages required for the current application.

An example:
Core RB - FarCry core (essential strings, included via farcry core).

Wide-Application RB - Ecommerce Package (optional, included via shared core
config or individual application config) - Prepackaged set of generic
'ecommerce' strings, such as "Total including Taxes", "Total Amount
Payable", etc. Horrible example, but you get the picture.

Application RB (Instance specific package, included via individual
application config) - Customised package consisting of strings required for
the particular application.


The obvious, overwhelming disadvantage to wide-application RBs is the
potential for a large number of partially complete or inconsistent or
overlapping bundles, and it would almost certainly require a high percentage
of user contributions. I'd dread waiting for an Application dump, too. :\

Just a thought!
Chris

PS: Docs would be great ;)

-----Original Message-----
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Geoff
Bowers
Sent: Tuesday, 5 April 2005 6:42 PM
To: FarCry Developers
Subject: [farcry-dev] Re: FarCry 2.3 - Admin properties?

Paul Hastings wrote:
>> I'm still not sure I'm clear on how these are managed.. if farcry_core 
>> team updates RB -- how do you avoid having your customised RB 
>> overwritten during the next update without merging?
> 
> how do you avoid the same fate for your customized app code?

All customised code is stored in a farcry project ie. the actual 
application you are writing.  farcry_core always remains untouched.

Essentially you customise the core functionality by "extending" the 
relevant object or content type in your application.  This means the 
underlying core code can happily update without breaking your code 
(unless there is a fundamental change that requires the extended code to 
be modified).

If RBs were to follow a similar vein we'd be effectively combining the 
farcry project local RB with the core RB on application initialisation.

I'm not sure I see an easy way out of this.  Unless we try and 
rationalise the lables in the RB to provide folk with a generic set they 
can use in their own apps... and have folks lobby for additions to the 
core RB.

>> And if you have to merge the data how is this done?
> 
> via rbManager. i guess i should work out some docs for that.

Docs would be great :)  Should I publish on the site the doc you sent 
through for translators?

-- geoff
http://www.daemon.com.au/




---
You are currently subscribed to farcry-dev as: [email protected]
To unsubscribe send a blank email to [EMAIL PROTECTED]
Aussie Macromedia Developers: http://lists.daemon.com.au/

Reply via email to