Why Access? ...and localization

[lazyeye]

This is not a rant but hopefully a little constructive criticism.

I'm wondering about the choice of Access by the Actinic team. That it requires one to install (read purchase) the ms office suite is already bad enough. Mysql is platform-independant, way more advantageous, let alone ubiquitous. Coupled with php, it offers easier access to the database and greater control. Even for little details as live stock level monitoring and updating of products as well as variants (ie attribute permutations), or having the possibility of running custom queries.

While Actinic is a powerful solution, it lacks flexibility and is, imho, too closed: most if not all templates/variables/phrases/stylesheets are only accessible and editable from within the software. This is also problematic with regards to localization. I don't understand why it does not provide the possibility of creating language-specific "configuration files" for all the phrases that you can ONLY change via Design>Text... (these are then read, via the GetPhrase routine, by the various perl CGIs that take care of generating html output). Based on a site-wide language session variable, one could design sites that would offer its users the possibility of choosing between, say, English or French or Spanish. The system would then just include the proper configuration file and display the pages in the chosen locale. In fact, GetPhrase should be recoded to go fetch the proper phrases within these custom language files.

[wjcampbe]

This has been the subject of ongoing discussion both on and off the Forum.

Actinic have acknowledged that ther are advantages to moving to an online database - and that these have to be balanced against the risks of having sensitive company data on a website. They have committed to examine the possibility of a move to online or indeed [my preference] a mixture of online and offline database.

Localisation - much needed - in fact it needs to go much further than you suggest. We need access [no pun intended] to every phrase that will be visible on the website, including those built by the perl scripts, and the ability to maintain multiple language resource files so that the same data can be presented in German to german customers, French to belgian customers and Arabic to arab customers, while still showing American to the english customers.

[completerookie]

I'm sure most of this is an historical issue - they started off in MS-access and now the product has grown "so big", that they would be undertaking a massive re-write, testing and release phase if they were to swap technologies mid stream ( probably read - "they won't do it" ).

with mysql/php they have to integrate / install web servers etc whereas, they only have to install the ms-access runtime files (which they do anyway).

Its only when you want to take actinic further then you may need a full ms-access installation

Nowadays, if they wanted to integrate online databases, there is no reason why they can't upload ms-tables to the web and run from them. - I'm not saying performance will be fantastic, but some performance hit is better that no on-line database integration.

I guessing that someone is going to comeback saying php, mysql was around when they started actinic, so why not start in that technology - Actinic are the only ones that can answer that.

[lazyeye]

Actinic have acknowledged that ther are advantages to moving to an online database - and that these have to be balanced against the risks of having sensitive company data on a website. They have committed to examine the possibility of a move to online or indeed [my preference] a mixture of online and offline database.

That would be my preference as well.

Localisation - much needed - in fact it needs to go much further than you suggest. We need access [no pun intended] to every phrase that will be visible on the website, including those built by the perl scripts, and the ability to maintain multiple language resource files so that the same data can be presented in German to german customers, French to belgian customers and Arabic to arab customers, while still showing American to the english customers.

That was kind of what I was getting at. All those phrases should be moved out of Actinic and placed in separate files editable either via some interface or directly in a text editor like ConTEXT, jEdit or whatever. Therefore localization can be either automatic (by detection of the geographical location of the client computer) or by choice (letting the user choose, thru a menu, the language he/she wants), and even put a "preferred language" field in the login/registration mechanism. That would be saved in an mysql "registered customers preferences" database.

[lazyeye]

I'm sure most of this is an historical issue - they started off in MS-access and now the product has grown "so big", that they would be undertaking a massive re-write, testing and release phase if they were to swap technologies mid stream ( probably read - "they won't do it" ).

That's unfortunate.

[zmagyar]

I'm sure most of this is an historical issue - they started off in MS-access and now the product has grown "so big", that they would be undertaking a massive re-write, testing and release phase if they were to swap technologies mid stream ( probably read - "they won't do it" ).

....

I guessing that someone is going to comeback saying php, mysql was around when they started actinic, so why not start in that technology - Actinic are the only ones that can answer that.

Correct. Please note Actinic has been started a while ago (actually in 1996) and version 1 was released in 1997. Its technology was on the right edge that time. In those years perl was nearly the only one language supported by ISPs to provide dynamic content (note that PHP 3 which managed to get penetration over 1% was released in 1998 and it wasn't quite common to have a DB installed on the server in cheap hosting packages).
During the last few years we have managed to build a feature rich product around our architecture. But we are also feel it too limiting nowadays. Therefore we got plans to move forward and some of you watching our development closely can guess the direction.
Unfortunately our product is far more complex now to allow us to do a one step architectural change (just the c++ source is about 120MB). But each new release in the pipline at the moment will move us forward to a direction which hopefully make all of us happy ( probably read - "they try to do it" ).
So just watch the new releases coming in this year.