Custom fields design doc

[Bradley Baetz]

On Mon, May 26, 2003 at 02:27:44AM -0400, Daniel Berlin wrote:

> Errr, isn't this type of thing a solved problem (IE haven't other 
> internationalized projects been here before)?

Sure. I'm not aware of any other project which wants this to be
adminable via the web rather than a config file, but thats not a big
difference.

> 
> In the DB, they are mostly only referred to by ID already (IE have 
> separate namespaces)
> 
> Some (heavily, i would imagine) included perl file(s) that is/are in 
> the template/<language> dir contains a hash table mapping the specific 
> id's to strings.


> Past that, what's so hard about making the current code use 
> Data::Dumper (if you want readability) or IO::Storable (if you want 
> speed of loading/storing) to rewrite the approriate file for the 
> current language when someone edits a product name?  This makes it web 
> editable.

None of this is hard. Its just that we don't currently do this, so
someone has to write the backend infrastruture too.

Personally, I'd prefer Data::Dumper but thats a side issue.

> 
> It also seems simple to check if the current language file was modified 
> since we last read it in and re-load the hash, and to do this check in 
> get_product_name (or wherever).  This makes it hand editable.
> 

When not running under mod_perl, theres nowhere to persist it anyway -
it will be loaded every time anyway.

> > Custom field descriptions fall into
> >the same category, in that a localiaser cannot proivde them, since
> >they're specified by the admin. A template which the admin modifies ahs
> >the disadvantage that its not web editable.
> How is the above not web editable?

Auto-generating the template won't quite work, because of the
permissions stuff - the webserver won't have the access to write out the
template in the template dir. Putting this in data/ means fudging with a
template provider a bit so that compiled templates are stuff under data.
I have a patch which makes those use abolute dirs anyway (needed for
mod_perl), so I guess thats not an issue.

> Even if the file doesn't exist for the current language, we still know 
> how many *things* we need names for, and what the keys are, and thus 
> can make up "default" values like "unset localized product name 1", and 
> write it out as the file for that language.
> 

Sure.
 
> >We're probably going to have
> >to end up wuth a {language,type,id,text} table at some point.
> >
> Only if you aren't willing to serialize perl structures in some form.  
> If this is a requirement (not serializing perl structures, that is) you 
> are pretty much left with the DB to do this.
> 

Even if we do serialise, we still want to persist stuff into the
database, and use the perl as a cache, similarly to how the versioncache
works. That gives us one place to back stuff up (the mysql db). If we do
it that way, then outputing to a TT template probably makes more sense.

Bradley