New Extended Arrays in FarCry 4.0
An array property in FarCry allows you to have relational tables for your content types and have it easily configurable and managed from within FarCry.
Real World Scenario
Lets say I have a CFC (object) called products.cfc where I store my company's product info. To keep this example simple we'll say my fieldnames are productName, description, and price.
Now my company tells me they want to have sale prices this month (in this case just price decreases) for different products. Okay, so I create a new object called sale.cfc. To assign the products to a sale object in FarCry I can do it in one line of code in the sale.cfc file like so...
This feature has always been possible with FarCry (at least since I started using it in version 2.1) and will create a table called sale_aProducts.
But wait a second... I just realized that I need to have custom prices for each product in the sale (meaning for each item in the array table, I need a column called price to override the default product price). Before FarCry 3.0 this was not possible without managing your own table (something FarCry has always tried to eliminate the need for). However, in FarCry 3.0 a new attribute came along called arrayProps. So I could use it by adding the attribute like so...
So now if I use that attribute I'll end up the following columns in my array table parentid, data, seq, typename, and price (my new column).
This worked great and allowed me to add my new column(s) with ease. Unfortunately trying to manage the data in the new column price requires custom code/logic.
Introducing Extended Arrays
In FarCry 4.0 we set aside the "arrayProps" attribute and instead create a CFC named after the array table.
File: <project_folder>/packages/types/Sale_aProducts.cfc
2 <cfproperty name="price" type="numeric" hint="Sale price for product item" required="true" />
3</cfcomponent>
Now the data can be accessed as a native FarCry object and not just some SQL table we had to write manual queries and logic for in order to manage the data. We can even add more fields... heck, we can even add another array table to this array and the code will not get messy.
This is a great new feature to FarCry 4.0 that I plan to take full advantage of and hope you find it useful as well.
Would it be possible to use these extended arrays for multilanguage support in farcry?
For example - instead of using a string for title - use an array object which could hold the title in multiple languages.
I'm just working on a bilingual site and I've got a way to make it work in farcry 3 but it ain't exactly pretty. I'll try to blog about it as it progresses - any suggestions would be welcome!
Cheers,
Mark
Don't forget that you could always use an array table in FarCry, however you had to manually add (and manage) the extra fields of data where now FarCry 4 allows you to manage them as native FarCry objects.
Does farcry have support for a structure like object that gets stored in the DB? I'm thinking that this could be a very good way to support multiple languages.
Here's my rough thoughts on it:
- Admin area has list of languages enabled: en, fr, it
- All edit pages use a structure like data storage (keyed value pairs) to store values like title and body
- would need to create editors to handle this
- at run time the display page pick the correct lanaguage element with fallback
So question is - is there support for a struct like data types in the DB or would it be possible to implement them similar to how the extended arrays are handled?
Cheers,
Mark
>> Does farcry have support for a structure like object that gets stored in the DB?
No there isn't. Array types are the closest you'll get (however, if you ever need to store a structure, I've been known to store data as a WDDX in rare moments. FarCry has a good example of this in its archive feature. look at the archive table for more info).
I had proposed a solution to Daemon a while back, but it didn't look simple to implement and I'm not sure it was the best approach.
My solution starts with the UI (make sure its simple and intuitive). When in the start PLP step you have a dropdown that selects the langauge. This triggers a javascript to save what you are doing in the language currently selected and loads up the new language. By default the new language wouldn't have a record, thus would be all blank data.
The DB wouldn't be flooded with blank records, because you'd have to create them first for that language (thus you'd still have on dmHTML table and a new columb for the language). You'd then need a reporting tool to easily find which objects (html pages for example) are missing data in language X.
I'm still not sure this is the best solution. I'd like to hear more from people. IMO I think the user experience should be worked out first (so its intuitive to the user) and then design the DB structure and code.