From petermichaux at shaw.ca Wed Oct 26 14:51:47 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Wed, 26 Oct 2005 11:51:47 -0700 Subject: [Storerb-devel] Our first email Message-ID: <29066a28d754.28d75429066a@shaw.ca> Hi all, This is a test of the store.rb broadcasting system. Here's to unlimited potential and great success! -Peter From adam at dberg.org Wed Oct 26 18:41:11 2005 From: adam at dberg.org (Adam Denenberg) Date: Wed, 26 Oct 2005 18:41:11 -0400 Subject: [Storerb-devel] anything started yet ? Message-ID: <8F001743-1A8C-4894-83A5-C19C7906988A@dberg.org> is there any start yet to this project or is the groundwork being laid out ? I would love to contribute but not sure where you guys are at with it. adam From petermichaux at shaw.ca Wed Oct 26 23:21:18 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Wed, 26 Oct 2005 20:21:18 -0700 Subject: [Storerb-devel] anything started yet ? In-Reply-To: <8F001743-1A8C-4894-83A5-C19C7906988A@dberg.org> References: <8F001743-1A8C-4894-83A5-C19C7906988A@dberg.org> Message-ID: <27d8d5e90aef3c4471e76b06698c2f87@shaw.ca> testing the reply function From petermichaux at shaw.ca Wed Oct 26 23:32:40 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Wed, 26 Oct 2005 20:32:40 -0700 Subject: [Storerb-devel] anything started yet ? In-Reply-To: <8F001743-1A8C-4894-83A5-C19C7906988A@dberg.org> References: <8F001743-1A8C-4894-83A5-C19C7906988A@dberg.org> Message-ID: <3652bafcbc09094ec11cce39907d6550@shaw.ca> Nothing is started yet. I will get some a few threads going about database modeling in the next day or two. Different threads for catalog, multilingualism, taxes, etc In the mean time perhaps you'd like to do a little brainstorming... http://trac.vaillant.ca/store.rb/wiki/NameBrainstorm http://trac.vaillant.ca/store.rb/wiki/FeaturesBrainstorm or to introduce yourself with a people page http://trac.vaillant.ca/store.rb/wiki/People - Peter On 26-Oct-05, at 3:41 PM, Adam Denenberg wrote: > is there any start yet to this project or is the groundwork being > laid out ? I would love to contribute but not sure where you guys > are at with it. > > adam From petermichaux at shaw.ca Thu Oct 27 00:20:28 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Wed, 26 Oct 2005 21:20:28 -0700 Subject: [Storerb-devel] db model: Multilingualism Message-ID: <56d9dbde646eeb177a5a3977666a63a3@shaw.ca> Let's start the database modelling discussion with a some multilingualism. Comencemos la base de datos a modelar la discusi?n con un cierto multilingualismo. Lassen Sie uns die Datenbank beginnen, Diskussion mit einer etwas Mehrsprachigkeit zu modellieren. babelfish :) I've written up a little page so that we have something to talk about. The SQL is for MySQL because it is probably the most common. http://trac.vaillant.ca/store.rb/wiki/DbModelMultilingual Please have a look and reply to the list. -Peter From petermichaux at shaw.ca Thu Oct 27 00:21:49 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Wed, 26 Oct 2005 21:21:49 -0700 Subject: [Storerb-devel] db model: taxes Message-ID: <7b8aa79077827bdce286e31605ef5cf1@shaw.ca> Ideas about a flexible tax model. http://trac.vaillant.ca/store.rb/wiki/DbModelTax What do you think? -Peter From paul.vaillant at gmail.com Thu Oct 27 01:01:53 2005 From: paul.vaillant at gmail.com (Paul Vaillant) Date: Wed, 26 Oct 2005 23:01:53 -0600 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <56d9dbde646eeb177a5a3977666a63a3@shaw.ca> References: <56d9dbde646eeb177a5a3977666a63a3@shaw.ca> Message-ID: <9e8e66200510262201u375077b6sed288bee924dcc92@mail.gmail.com> For multiple language support, wouldn't we need a many to many between products (or categories) and the language table, with the actual translation of the text. Languages id name code Products id .. numeric fields .. ProductTexts id product_id language_id name description Also, both the Product and its text could be retrieved at the same time by creating a find_with_text() method that joined the two. Static text elements could be handled similarly by StaticElements id label StaticElementTexts id static_id language_id text My only caution for all this is the same as for product and variations; the overhead to manage this for a small site could be hugh, so care will have to be taken in the admin interface to insure that this can be disabled and text entered in a single language and the fact that there might be another table is hidden. paul On 10/26/05, Peter Michaux wrote: > > Let's start the database modelling discussion with a some > multilingualism. > > Comencemos la base de datos a modelar la discusi?n con un cierto > multilingualismo. > > Lassen Sie uns die Datenbank beginnen, Diskussion mit einer etwas > Mehrsprachigkeit zu modellieren. > > babelfish :) > > I've written up a little page so that we have something to talk about. > The SQL is for MySQL because it is probably the most common. > > http://trac.vaillant.ca/store.rb/wiki/DbModelMultilingual > > Please have a look and reply to the list. > > -Peter > > _______________________________________________ > Storerb-devel mailing list > Storerb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/storerb-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/storerb-devel/attachments/20051026/2777aecd/attachment.htm From paul.vaillant at gmail.com Thu Oct 27 01:19:19 2005 From: paul.vaillant at gmail.com (Paul Vaillant) Date: Wed, 26 Oct 2005 23:19:19 -0600 Subject: [Storerb-devel] db model: taxes In-Reply-To: <7b8aa79077827bdce286e31605ef5cf1@shaw.ca> References: <7b8aa79077827bdce286e31605ef5cf1@shaw.ca> Message-ID: <9e8e66200510262219m7d75a9e3kea1e5f708f6349bd@mail.gmail.com> Multiple taxes will need to be handled as well. For exemptions, could we simply handle this with flags on customers and products as to whether to charge taxes or not? Also, could basic taxation entries be implemented in a library which would allow us to implement more complex business logic without having to model it into a database. I'm not thinking of handling everything there, but the basics such as feredal, provincial/state taxation, etc that apply to (almost) everything and change very infrequently. Then this could be suplimented by additional taxes modeled in the database. paul On 10/26/05, Peter Michaux wrote: > > Ideas about a flexible tax model. > > http://trac.vaillant.ca/store.rb/wiki/DbModelTax > > What do you think? > > -Peter > > _______________________________________________ > Storerb-devel mailing list > Storerb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/storerb-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/storerb-devel/attachments/20051026/efccc11d/attachment.htm From petermichaux at shaw.ca Thu Oct 27 01:56:32 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Wed, 26 Oct 2005 22:56:32 -0700 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <9e8e66200510262201u375077b6sed288bee924dcc92@mail.gmail.com> References: <56d9dbde646eeb177a5a3977666a63a3@shaw.ca> <9e8e66200510262201u375077b6sed288bee924dcc92@mail.gmail.com> Message-ID: <5617edca04fd2debd236e27082a73196@shaw.ca> > For multiple language support, wouldn't we need a many to many between > products (or categories) and the language table, with the actual > translation of the text. In a way I don't think it is many to many because one product name might be used for several products; however, one product will not have multiple names for a given language. > Languages > ? id > ? name > ? code > > Products > ? id > ? .. numeric fields .. > > ProductTexts > ? id > ? product_id > ? language_id > ? name > ? description This is the schema I was using. I works but and the only part I don't like is the eventual mess of tables that are almost the same. languages categories categories_texts products products_texts variations variations_texts manufacturers manufactures_texts ... and on and on > Also, both the Product and its text could be retrieved at the same > time by creating a find_with_text() method that joined the two. With the schema I posted on the wiki there is only one table holding translations. A particular products name may have a name_ml_id of 125. Eep! I forgot a field in the ml table. I've added a field called text_id. Now can't we do something like find_with_text() that joins the product and ml tables with a "WHERE text_id = name_ml_id AND language_id = 2" kind of thing? But does this require the two tables to be joined as many times as there are multilingual text bits in the products table? I know all the data is stored in a concise way but maybe it does take too much work to get it out. Any way to rescue it so we don't have so many database tables or a zillion db calls? With the schema you posted, if someone modifying the database adds a new table they will have to also add a new texts table. I was thinking about avoiding that hassle too. (If we want to use the elasticpath attributes idea it will be more clear why I want to reduce the number of tables. But that shouldn't affect this decision.) > My only caution for all this is the same as for product and > variations; the overhead to manage this for a small site could be > hugh, so care will have to be taken in the admin interface to insure > that this can be disabled and text entered in a single language and > the fact that there might be another table is hidden. I agree. Features that are not being used must be out of sight. Not necessarily disabled but sort of hidden until a button is pressed to, say, "add another variation to this product". For those wondering what this is about see http://trac.vaillant.ca/store.rb/wiki/DesignChallenges - Peter From petermichaux at shaw.ca Thu Oct 27 02:06:53 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Wed, 26 Oct 2005 23:06:53 -0700 Subject: [Storerb-devel] db model: taxes In-Reply-To: <9e8e66200510262219m7d75a9e3kea1e5f708f6349bd@mail.gmail.com> References: <7b8aa79077827bdce286e31605ef5cf1@shaw.ca> <9e8e66200510262219m7d75a9e3kea1e5f708f6349bd@mail.gmail.com> Message-ID: <258eadfabf82e6ddcc307fcc91727b70@shaw.ca> > Multiple taxes will need to be handled as well. Do you mean the Canadian situation of PST and GST? The schema I posted can do that. > For exemptions, could we simply handle this with flags on customers > and products as to whether to charge taxes or not? I was thinking the opposite way around. Instead of exemptions I would attach certain taxes to certain customer groups, products, zones. Then during checkout you see if any taxes apply to all three of these aspects of a purchase. If you want to go with exemptions then a British Columbia customer has to be made exempt of all other taxes (every US state tax, etc). To me that seems like an awkward way to have to think. > Also, could basic taxation entries be implemented in a library which > would allow us to implement more complex business logic without having > to model it into a database. I'm not thinking of handling everything > there, but the basics such as feredal, provincial/state taxation, etc > that apply to (almost) everything and change very infrequently. Then > this could be suplimented by additional taxes modeled in the database. I'll have to think more about this but I think there would have to be a compelling difference between the taxes modelled in the library and those in the database. Otherwise we are sort of doing the same thing in two places. Also tax calculations are only calculated at checkout (or cart view at most frequent) so optimizing tax calculations is not necessarily a huge priority. Peter From papipo at gmail.com Thu Oct 27 02:51:51 2005 From: papipo at gmail.com (=?ISO-8859-1?Q?Rodrigo_Alvarez_Fern=E1ndez?=) Date: Thu, 27 Oct 2005 08:51:51 +0200 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <56d9dbde646eeb177a5a3977666a63a3@shaw.ca> References: <56d9dbde646eeb177a5a3977666a63a3@shaw.ca> Message-ID: <6d2bdda0510262351v3e267b46n191aaf33207a6ca6@mail.gmail.com> On 10/27/05, Peter Michaux wrote: > Let's start the database modelling discussion with a some > multilingualism. > > Comencemos la base de datos a modelar la discusi?n con un cierto > multilingualismo. > Comencemos a modelar la base de datos a partir de la internacionalizaci?n (i18n). I can handle the translations to Spanish :]. > Lassen Sie uns die Datenbank beginnen, Diskussion mit einer etwas > Mehrsprachigkeit zu modellieren. > > babelfish :) > From paul.vaillant at gmail.com Thu Oct 27 10:09:48 2005 From: paul.vaillant at gmail.com (Paul Vaillant) Date: Thu, 27 Oct 2005 08:09:48 -0600 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <5617edca04fd2debd236e27082a73196@shaw.ca> References: <56d9dbde646eeb177a5a3977666a63a3@shaw.ca> <9e8e66200510262201u375077b6sed288bee924dcc92@mail.gmail.com> <5617edca04fd2debd236e27082a73196@shaw.ca> Message-ID: <9e8e66200510270709q1a45f707j182e10f00c36265c@mail.gmail.com> The many to many is between products and languages; one to many from products to product_texts and languages to product_texts. I see where you were going with your schema now, but you can't have *_ml_id fields in the actual product, etc tables because there isn't just one name_ml entry, there are multiple - one for each language. In my schema there aren't *_ml_id fields in product, but product_id fields in the ml table. That aside, I agree that this starts to litter the database with tables. We could you the ActiveRecord inheritance features to make one table as below ml id type object_id language_id text and then individual records would look like (1, 'ProductTextName', 1, 1 [en], 'Green Shoe') (2, 'ProductTextName, 1, 2 [fr], 'Chaussure Verte') Problems with this are that it could lead to more ActiveRecord classes (ProductTextName and ProductTextDescription would now be two classes instead of just ProductText) and that all labels for a given objects could be more difficult to extract at the same time because the ml table would have to be joined in a number of times equal to the number of labels (ex twice for product if it had a name and a description). As for someone modifying the database; I'd ideally like for that to be as not-necessary as possible, but if someone wants to then I think sufficient documentation on what they need to do will be present that it shouldn't hinder out design decisions at this point. If someone is doing that they would have read out 'developer documentation' and understand the instructions on extension via new table because they'll have to create new object(s) as well inherited from Ml (in the above schema) for any text fields [caveat: if they want to use out ML solution and not something of their own]. Something else that I'm thinking is that this could have an impact on searching as well. Namely, we are going to need a solution that we can pull out with one query to effectively to searching I think. Implementation wise, I'm thinking that we can hide much of the gory details by creating a 'acts_as_i18n' type plugin that will allow a 'current_language' to be set in ActiveRecord::Base and then retrieve current language text fields, but also allow access to text in all languages defined for this object. We could also have a method to describe a 'text' field (ex maybe 'i18n_text :name, :description') so that if someone create a new table then it's hidden from them too. This has the added benefit of explicitly telling us how many text fields there are so that we can join in the translation table the appropriate number of times. A library like this could also help us dump the inherited tables and work with just a single translation class by filling the type field with 'product#name' and 'product#description' instead. To retrieve all translations we'd need a second call, but because this will only happen in the admin interface, it represents a marginal number of occurances vs the display on the front end. This is moot as we'd need two calls in either case. paul On 10/26/05, Peter Michaux wrote: > > > For multiple language support, wouldn't we need a many to many between > > products (or categories) and the language table, with the actual > > translation of the text. > > In a way I don't think it is many to many because one product name > might be used for several products; however, one product will not have > multiple names for a given language. > > > Languages > > > > Products > > > > ProductTexts > > This is the schema I was using. I works but and the only part I don't > like is the eventual mess of tables that are almost the same. > > languages > categories > categories_texts > products > products_texts > variations > variations_texts > manufacturers > manufactures_texts > ... and on and on > > > Also, both the Product and its text could be retrieved at the same > > time by creating a find_with_text() method that joined the two. > > With the schema I posted on the wiki there is only one table holding > translations. A particular products name may have a name_ml_id of 125. > Eep! I forgot a field in the ml table. I've added a field called > text_id. Now can't we do something like find_with_text() that joins the > product and ml tables with a "WHERE text_id = name_ml_id AND > language_id = 2" kind of thing? But does this require the two tables to > be joined as many times as there are multilingual text bits in the > products table? I know all the data is stored in a concise way but > maybe it does take too much work to get it out. Any way to rescue it so > we don't have so many database tables or a zillion db calls? With the > schema you posted, if someone modifying the database adds a new table > they will have to also add a new texts table. I was thinking about > avoiding that hassle too. > > (If we want to use the elasticpath attributes idea it will be more > clear why I want to reduce the number of tables. But that shouldn't > affect this decision.) > > > My only caution for all this is the same as for product and > > variations; the overhead to manage this for a small site could be > > hugh, so care will have to be taken in the admin interface to insure > > that this can be disabled and text entered in a single language and > > the fact that there might be another table is hidden. > > I agree. Features that are not being used must be out of sight. Not > necessarily disabled but sort of hidden until a button is pressed to, > say, "add another variation to this product". For those wondering what > this is about see > http://trac.vaillant.ca/store.rb/wiki/DesignChallenges > > - Peter > > > _______________________________________________ > Storerb-devel mailing list > Storerb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/storerb-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/storerb-devel/attachments/20051027/a03916ba/attachment.htm From petermichaux at shaw.ca Thu Oct 27 14:44:16 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Thu, 27 Oct 2005 11:44:16 -0700 Subject: [Storerb-devel] db model: Multilingualism Message-ID: <45f94645c14a.45c14a45f946@shaw.ca> Hi, Paul, I haven't had more time to digest your class inheritence idea completely. I'm actually at my day job today. I did look around for other ideas about multilingual handling and made a couple emails. Here are some things I'm looking at http://www.tuxsoft.se/sv/oss/rails/multilingual http://www.hyperionreactor.net/taxonomy/term/12 Below is an email reply I received from http://wiki.rubyonrails.com/rails/pages/TobinHarris Multilingual handling is an important thing to get right so I want to explore all options. Peter - - - - - - - - - - >From "Harris, Tobin" Sent Thursday, October 27, 2005 10:33 am Hi Peter, You're project looks interesting! I've looked at your multilingual notes. I used something similar which worked out ok, this was along the lines of (warning, bad DDL!): Create table resources ( id int(10) unique not null auto increment, resource_group_id id int(10) not null, language_id int(10) not null, name varchar(30) not null, text text not null ) Create table resource_groups ( id int(10) unique not null auto increment, name varchar(50) unique not null ) Create table languages ( id int(10) not null auto increment, native_name varchar(100) iso_code varchar(3) ) Insert into resource_groups (name) values( 'home_page'); Insert into resources (resource_group_id, language_id, name, text) values( 1, 'en-GB', 'heading', 'Welcome To My Home'); Insert into resources (resource_group_id, language_id, name, text) values( 1, 'de-DK', 'heading', 'Valkommen till min Hem'); There's some duplication in here where I have both natural keys and auto ids. This can be done better, but the main idea was to make the code more verbose. For example... <= GetResource('en-GB', 'heading') %> Is easier to work with than: <%= GetResource(27,165) %> Here's a more complete example, including use of a simple resource manager class that pre-fetches resources. <% session['resource_manager'].set_language 'en-GB' session['resource_manager'].import_resource_group 'home_page' %>

<%= GetResource('heading') %>

Actually, I copied the syntax from GetText (http://manuals.rubyonrails.com/read/chapter/105). So, the code looks like this...

<%= _('heading') %>

<%= _('introduction')%>

Of course, loading resources from the database like this does come with an overhead, so I wanted the option of being able to change my mind and switch to GetText if things were too slow. Never needed to, but handy to copy their syntax... Our application isn't even using the rails cache, we're ok just pulling text out of the db for each request. Note the use of resource groups - these mean that I can pre-fetch resources for a given page in one database query, and also allow editors to work with resources one page at a time. Resources are loaded on each web request for the page. MySql caches all resource selects so it's not even hitting the disk, just returning them out of memory. Also, if you're using rails caching then you'll hardly be hitting the db at all. There's a few more issues I've had to tackle, for example, our site has a 'language editing mode' where the site renders the names of resources instead of the text itself, allowing editors to see where new language text needs to be added. Anyway, hope this makes some sense! Let me know if you want any more info on our approach, and if you have any cool ideas about this I'd love to hear them. Cheers Tobin Content-Type: multipart/alternative; boundary="----=_Part_8773_1860320.1130422188886" ------=_Part_8773_1860320.1130422188886 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The many to many is between products and languages; one to many from products to product_texts and languages to product_texts. I see where you were going with your schema now, but you can't have *_ml_id fields in the actual product, etc tables because there isn't just one name_ml entry, there are multiple - one for each language. In my schema there aren't *_ml_id fields in product, but product_id fields in the ml table. That aside, I agree that this starts to litter the database with tables. We could you the ActiveRecord inheritance features to make one table as below ml id type object_id language_id text and then individual records would look like (1, 'ProductTextName', 1, 1 [en], 'Green Shoe') (2, 'ProductTextName, 1, 2 [fr], 'Chaussure Verte') Problems with this are that it could lead to more ActiveRecord classes (ProductTextName and ProductTextDescription would now be two classes instea= d of just ProductText) and that all labels for a given objects could be more difficult to extract at the same time because the ml table would have to be joined in a number of times equal to the number of labels (ex twice for product if it had a name and a description). As for someone modifying the database; I'd ideally like for that to be as not-necessary as possible, but if someone wants to then I think sufficient documentation on what they need to do will be present that it shouldn't hinder out design decisions at this point. If someone is doing that they would have read out 'developer documentation' and understand the instructions on extension via new table because they'll have to create new object(s) as well inherited from Ml (in the above schema) for any text fields [caveat: if they want to use out ML solution and not something of their own]. Something else that I'm thinking is that this could have an impact on searching as well. Namely, we are going to need a solution that we can pull out with one query to effectively to searching I think. Implementation wise, I'm thinking that we can hide much of the gory details by creating a 'acts_as_i18n' type plugin that will allow a 'current_language' to be set in ActiveRecord::Base and then retrieve curren= t language text fields, but also allow access to text in all languages define= d for this object. We could also have a method to describe a 'text' field (ex maybe 'i18n_text :name, :description') so that if someone create a new tabl= e then it's hidden from them too. This has the added benefit of explicitly telling us how many text fields there are so that we can join in the translation table the appropriate number of times. A library like this coul= d also help us dump the inherited tables and work with just a single translation class by filling the type field with 'product#name' and 'product#description' instead. To retrieve all translations we'd need a second call, but because this will only happen in the admin interface, it represents a marginal number of occurances vs the display on the front end. This is moot as we'd need two calls in either case. paul On 10/26/05, Peter Michaux wrote: > > > For multiple language support, wouldn't we need a many to many between > > products (or categories) and the language table, with the actual > > translation of the text. > > In a way I don't think it is many to many because one product name > might be used for several products; however, one product will not have > multiple names for a given language. > > > Languages > > > > Products > > > > ProductTexts > > This is the schema I was using. I works but and the only part I don't > like is the eventual mess of tables that are almost the same. > > languages > categories > categories_texts > products > products_texts > variations > variations_texts > manufacturers > manufactures_texts > ... and on and on > > > Also, both the Product and its text could be retrieved at the same > > time by creating a find_with_text() method that joined the two. > > With the schema I posted on the wiki there is only one table holding > translations. A particular products name may have a name_ml_id of 125. > Eep! I forgot a field in the ml table. I've added a field called > text_id. Now can't we do something like find_with_text() that joins the > product and ml tables with a "WHERE text_id =3D name_ml_id AND > language_id =3D 2" kind of thing? But does this require the two tables to > be joined as many times as there are multilingual text bits in the > products table? I know all the data is stored in a concise way but > maybe it does take too much work to get it out. Any way to rescue it so > we don't have so many database tables or a zillion db calls? With the > schema you posted, if someone modifying the database adds a new table > they will have to also add a new texts table. I was thinking about > avoiding that hassle too. > > (If we want to use the elasticpath attributes idea it will be more > clear why I want to reduce the number of tables. But that shouldn't > affect this decision.) > > > My only caution for all this is the same as for product and > > variations; the overhead to manage this for a small site could be > > hugh, so care will have to be taken in the admin interface to insure > > that this can be disabled and text entered in a single language and > > the fact that there might be another table is hidden. > > I agree. Features that are not being used must be out of sight. Not > necessarily disabled but sort of hidden until a button is pressed to, > say, "add another variation to this product". For those wondering what > this is about see > http://trac.vaillant.ca/store.rb/wiki/DesignChallenges > > - Peter > > > _______________________________________________ > Storerb-devel mailing list > Storerb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/storerb-devel > ------=_Part_8773_1860320.1130422188886 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline The many to many is between products and languages; one to many from produc= ts to product_texts and languages to product_texts.

I see where you were going with your schema now, but you can't have *_ml_id fields in the actual product, etc tables because there isn't just one name_ml entry, there are multiple - one for each language. In my schema there aren't *_ml_id fields in product, but product_id fields in the ml table.

That aside, I agree that this starts to litter the database with tables. We could you the ActiveRecord inheritance features to make one table as below

ml
  id
  type
  object_id
  language_id
  text

and then individual records would look like
  (1, 'ProductTextName', 1, 1 [en], 'Green Shoe')
  (2, 'ProductTextName, 1, 2 [fr], 'Chaussure Verte')

Problems with this are that it could lead to more ActiveRecord classes (ProductTextName and ProductTextDescription would now be two classes instead of just ProductText) and that all labels for a given objects could be more difficult to extract at the same time because the ml table would have to be joined in a number of times equal to the number of labels (ex twice for product if it had a name and a description).

As for someone modifying the database; I'd ideally like for that to be as not-necessary as possible, but if someone wants to then I think sufficient documentation on what they need to do will be present that it shouldn't hinder out design decisions at this point. If someone is doing that they would have read out 'developer documentation' and understand the instructions on extension via new table because they'll have to  create new object(s) as well inherited from Ml (in the above schema) for any text fields [caveat: if they want to use out ML solution and not something of their own].

Something else that I'm thinking is that this could have an impact on searching as well. Namely, we are going to need a solution that we can pull out with one query to effectively to searching I think.

Implementation wise, I'm thinking that we can hide much of the gory details by creating a 'acts_as_i18n' type plugin that will allow a 'current_language' to be set in ActiveRecord::Base and then retrieve current language text fields, but also allow access to text in all languages defined for this object. We could also have a method to describe a 'text' field (ex maybe 'i18n_text :name, :description') so that if someone create a new table then it's hidden from them too. This has the added benefit of explicitly telling us how many text fields there are so that we can join in the translation table the appropriate number of times. A library like this could also help us dump the inherited tables and work with just a single translation class by filling the type field with 'product#name' and 'product#description' instead.

To retrieve all translations we'd need a second call, but because this will only happen in the admin interface, it represents a marginal number of occurances vs the display on the front end. This is moot as we'd need two calls in either case.

paul

On 10/26/05, Peter Michaux <petermic= haux at shaw.ca> wrote:
> For multiple language support, wouldn't we need a many to many between=
> products (or categories) and the language table, with the actual> translation of the text.

In a way I don't think it is many to= many because one product name
might be used for several products; however, one product will not have<= br>multiple names for a given language.

>  Languages>
>  Products
>
>  ProductTexts
This is the schema I was using. I works but and the only part I don't
like is the eventual mess of tables that are almost the same.

la= nguages
categories
categories_texts
products
products_texts
= variations
variations_texts
manufacturers
manufactures_texts
... and on and on

>  Also, both the Product and its tex= t could be retrieved at the same
> time by creating a find_with_text(= ) method that joined the two.

With the schema I posted on the wiki t= here is only one table holding
translations. A particular products name may have a name_ml_id of 125.<= br>Eep! I forgot a field in the ml table. I've added a field called
text= _id. Now can't we do something like find_with_text() that joins the
product and ml tables with a "WHERE text_id =3D name_ml_id AND
lang= uage_id =3D 2" kind of thing? But does this require the two tables to<= br>be joined as many times as there are multilingual text bits in the
pr= oducts table? I know all the data is stored in a concise way but
maybe it does take too much work to get it out. Any way to rescue it so=
we don't have so many database tables or a zillion db calls? With theschema you posted, if someone modifying the database adds a new table
they will have to also add a new texts table. I was thinking about
a= voiding that hassle too.

(If we want to use the elasticpath attribut= es idea it will be more
clear why I want to reduce the number of tables.= But that shouldn't
affect this decision.)

> My only caution for all this is the = same as for product and
> variations; the overhead to manage this for= a small site could be
> hugh, so care will have to be taken in the a= dmin interface to insure
> that this can be disabled and text entered in a single language an= d
> the fact that there might be another table is hidden.

I ag= ree. Features that are not being used must be out of sight. Not
necessar= ily disabled but sort of hidden until a button is pressed to,
say, "add another variation to this product". For those wonde= ring what
this is about see
http://trac.vaillant.ca/store.rb/wiki/DesignChall= enges

- Peter


____________________________________________= ___
Storerb-devel mailing list
Storerb-devel at rubyforge.org
http://rubyforge.org/mailman/listinfo/storerb-devel

------=_Part_8773_1860320.1130422188886-- -------------- next part -------------- _______________________________________________ Storerb-devel mailing list Storerb-devel at rubyforge.org http://rubyforge.org/mailman/listinfo/storerb-devel From paul.vaillant at gmail.com Thu Oct 27 16:21:45 2005 From: paul.vaillant at gmail.com (Paul Vaillant) Date: Thu, 27 Oct 2005 14:21:45 -0600 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <45f94645c14a.45c14a45f946@shaw.ca> References: <45f94645c14a.45c14a45f946@shaw.ca> Message-ID: <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> I agree in getting it right. I think that we (both of us so far) are on the same page as Tim based on what he describes. Tim's seems to be more for static text through; he includes 'resource_group' which I take to be a page or something similar and his de-normalized the language code and label down which is similar to the last schema and what I was thinking for acts_as_i18n. The resource_group could be handly as, if I understand correctly, he loads all entries for the page + language in one statement. The other thing that I've very glad to hear is that there is little performance loss from the additional database access. >From the web pages you mentioned; http://www.tuxsoft.se/sv/oss/rails/multilingual talked about translating message strings with replacable portions. We haven't yet discussed this, but will it be required? paul On 10/27/05, Peter Michaux wrote: > > Hi, > > Paul, I haven't had more time to digest your class inheritence idea > completely. I'm actually at my day job today. > > I did look around for other ideas about multilingual handling and made a > couple emails. Here are some things I'm looking at > > http://www.tuxsoft.se/sv/oss/rails/multilingual > http://www.hyperionreactor.net/taxonomy/term/12 > > Below is an email reply I received from > http://wiki.rubyonrails.com/rails/pages/TobinHarris > > Multilingual handling is an important thing to get right so I want to > explore all options. > > Peter > > - - - - - - - - - - > > >From "Harris, Tobin" > Sent Thursday, October 27, 2005 10:33 am > > Hi Peter, > > You're project looks interesting! I've looked at your multilingual notes. > I used something similar which worked out ok, this was along the lines of > (warning, bad DDL!): > > Create table resources > ( > id int(10) unique not null auto increment, > resource_group_id id int(10) not null, > language_id int(10) not null, > name varchar(30) not null, > text text not null > ) > > Create table resource_groups > ( > id int(10) unique not null auto increment, > name varchar(50) unique not null > ) > > Create table languages > ( > id int(10) not null auto increment, > native_name varchar(100) > iso_code varchar(3) > ) > > Insert into resource_groups (name) values( 'home_page'); > Insert into resources (resource_group_id, language_id, name, text) values( > 1, 'en-GB', 'heading', 'Welcome To My Home'); > Insert into resources (resource_group_id, language_id, name, text) values( > 1, 'de-DK', 'heading', 'Valkommen till min Hem'); > > There's some duplication in here where I have both natural keys and auto > ids. This can be done better, but the main idea was to make the code more > verbose. For example... > > <= GetResource('en-GB', 'heading') %> > > Is easier to work with than: > > <%= GetResource(27,165) %> > > Here's a more complete example, including use of a simple resource manager > class that pre-fetches resources. > > <% > session['resource_manager'].set_language 'en-GB' > session['resource_manager'].import_resource_group 'home_page' > %> >

<%= GetResource('heading') %>

> > Actually, I copied the syntax from GetText ( > http://manuals.rubyonrails.com/read/chapter/105). So, the code looks like > this... > >

<%= _('heading') %>

>

<%= _('introduction')%>

> > Of course, loading resources from the database like this does come with an > overhead, so I wanted the option of being able to change my mind and switch > to GetText if things were too slow. Never needed to, but handy to copy their > syntax... Our application isn't even using the rails cache, we're ok just > pulling text out of the db for each request. Note the use of resource groups > - these mean that I can pre-fetch resources for a given page in one database > query, and also allow editors to work with resources one page at a time. > Resources are loaded on each web request for the page. MySql caches all > resource selects so it's not even hitting the disk, just returning them out > of memory. > > Also, if you're using rails caching then you'll hardly be hitting the db > at all. There's a few more issues I've had to tackle, for example, our site > has a 'language editing mode' where the site renders the names of resources > instead of the text itself, allowing editors to see where new language text > needs to be added. > > Anyway, hope this makes some sense! Let me know if you want any more info > on our approach, and if you have any cool ideas about this I'd love to hear > them. > > Cheers > > Tobin > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/storerb-devel/attachments/20051027/3f89f5d2/attachment.htm From petermichaux at shaw.ca Fri Oct 28 00:22:36 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Thu, 27 Oct 2005 21:22:36 -0700 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> References: <45f94645c14a.45c14a45f946@shaw.ca> <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> Message-ID: <4412ead84e33136860765c81efc13917@shaw.ca> Hi! Yes it does seem like Tobin's method is for static text and perhaps we could do something like his method for our static text. It certainly has nice syntax for the rhtml. Like I was saying before, when I was doing the XSL templating with language text in the XML language files, I like how it was easy for the template designer to work on the templates and static text in only a few simple text files. I thought it was less complicated than the designer working with MySQL. However in that case the XML files are actually acting like a database of sorts. So, If we are going to store the static text in the "real" database perhaps we could provide the template designer with a very simple admin interface to add an remove phrases and their translations. This would be easy to do and actually be easier than working with the XML files like I was because there would be an admin GUI page. (I never did compare the time for the XSL to get text from the XML compared with calling MySQL to do the same work. My guess is the MySQL method was slower.) For the dynamic text I am not completely opposed to the products, products_texts, categories, categories_texts approach if the other methods end up being too complicated. I think one of the links I posted requires modification of the "Rails" framework to become "Multilingual Rails" which I find very unappealing. I would hate to have to modify the Rails framework with each Rails release. Seems like an unacceptable solution to me. I don't think we will need to have replaceable portions of text. The static text is usually only a few words at most. To use this with the dynamic text seems like it would be very complicated to explain to the store owner. I'm picturing a very confusing admin interface. I can only think this would be useful in something like mail merge. I think that is way out of our scope for now. I think we should eventually try each of the promising methods and see which is the fastest and most enjoyable to work with. I'm not in a rush to find the final solution. I just want to be steadily working towards it. I have a lot of studying to do to get to a place where I can understand all of these methods and their pros and cons in implementation. I'm going to spend the weekend reading the Rails book and try to get up to speed with what I need to know to talk sensibly:) Peter On 27-Oct-05, at 1:21 PM, Paul Vaillant wrote: > I agree in getting it right. I think that we (both of us so far) are > on the same page as Tim based on what he describes. Tim's seems to be > more for static text through; he includes 'resource_group' which I > take to be a page or something similar and his de-normalized the > language code and label down which is similar to the last schema and > what I was thinking for acts_as_i18n. The resource_group could be > handly as, if I understand correctly, he loads all entries for the > page + language in one statement. > > The other thing that I've very glad to hear is that there is little > performance loss from the additional database access. > > >From the web pages you mentioned; > http://www.tuxsoft.se/sv/oss/rails/multilingual talked about > translating message strings with replacable portions. We haven't yet > discussed this, but will it be required? From paul.vaillant at gmail.com Fri Oct 28 11:29:59 2005 From: paul.vaillant at gmail.com (Paul Vaillant) Date: Fri, 28 Oct 2005 09:29:59 -0600 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <4412ead84e33136860765c81efc13917@shaw.ca> References: <45f94645c14a.45c14a45f946@shaw.ca> <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> <4412ead84e33136860765c81efc13917@shaw.ca> Message-ID: <9e8e66200510280829p206481ex3095e0a711a2a1fa@mail.gmail.com> Maybe I'll try to bang together a little prototype this weekend, as I understand it, and then we can take a look. The more I think about what you said regarding multiple tables, the more I agree. I think the final solution could be a single table, so that where I'll start, especially given what Tim said about performance. paul On 10/27/05, Peter Michaux wrote: > > Hi! > > Yes it does seem like Tobin's method is for static text and perhaps we > could do something like his method for our static text. It certainly > has nice syntax for the rhtml. > > Like I was saying before, when I was doing the XSL templating with > language text in the XML language files, I like how it was easy for the > template designer to work on the templates and static text in only a > few simple text files. I thought it was less complicated than the > designer working with MySQL. However in that case the XML files are > actually acting like a database of sorts. So, If we are going to store > the static text in the "real" database perhaps we could provide the > template designer with a very simple admin interface to add an remove > phrases and their translations. This would be easy to do and actually > be easier than working with the XML files like I was because there > would be an admin GUI page. (I never did compare the time for the XSL > to get text from the XML compared with calling MySQL to do the same > work. My guess is the MySQL method was slower.) > > For the dynamic text I am not completely opposed to the products, > products_texts, categories, categories_texts approach if the other > methods end up being too complicated. I think one of the links I posted > requires modification of the "Rails" framework to become "Multilingual > Rails" which I find very unappealing. I would hate to have to modify > the Rails framework with each Rails release. Seems like an unacceptable > solution to me. > > I don't think we will need to have replaceable portions of text. The > static text is usually only a few words at most. To use this with the > dynamic text seems like it would be very complicated to explain to the > store owner. I'm picturing a very confusing admin interface. I can only > think this would be useful in something like mail merge. I think that > is way out of our scope for now. > > I think we should eventually try each of the promising methods and see > which is the fastest and most enjoyable to work with. I'm not in a rush > to find the final solution. I just want to be steadily working towards > it. > > I have a lot of studying to do to get to a place where I can understand > all of these methods and their pros and cons in implementation. I'm > going to spend the weekend reading the Rails book and try to get up to > speed with what I need to know to talk sensibly:) > > Peter > > > > On 27-Oct-05, at 1:21 PM, Paul Vaillant wrote: > > > I agree in getting it right. I think that we (both of us so far) are > > on the same page as Tim based on what he describes. Tim's seems to be > > more for static text through; he includes 'resource_group' which I > > take to be a page or something similar and his de-normalized the > > language code and label down which is similar to the last schema and > > what I was thinking for acts_as_i18n. The resource_group could be > > handly as, if I understand correctly, he loads all entries for the > > page + language in one statement. > > > > The other thing that I've very glad to hear is that there is little > > performance loss from the additional database access. > > > > >From the web pages you mentioned; > > http://www.tuxsoft.se/sv/oss/rails/multilingual talked about > > translating message strings with replacable portions. We haven't yet > > discussed this, but will it be required? > > _______________________________________________ > Storerb-devel mailing list > Storerb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/storerb-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/storerb-devel/attachments/20051028/a691c2b2/attachment.htm From petermichaux at shaw.ca Sat Oct 29 14:02:33 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Sat, 29 Oct 2005 11:02:33 -0700 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> References: <45f94645c14a.45c14a45f946@shaw.ca> <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> Message-ID: I've been reading about plugins today. Where did you learn about writing plugins. I found some info http://wiki.rubyonrails.com/rails/pages/Plugins http://www.jamis.jamisbuck.org/articles/2005/10/11/plugging-into-rails > acts_as_i18n How about "acts_as_translated"? I'm thinking that the topic of i18n involves more than just translation which is all the plugin will deal with. I thought you wrote an email with a possible api for the plugin. I've looked everywhere but can't find it. Did you send one? If your translation plugin is super sweet perhaps we can create a spin-off rubyForge project to release it. That is something I'd like to see happen if we solve some problems that others also have. I only have Rails 0.10 on my computer so I'll have to upgrade to try the plugin. I was hoping I could wait until the Rails 1.0 gem was ready but that may be a little ways off yet. -Peter From paul.vaillant at gmail.com Sat Oct 29 17:51:39 2005 From: paul.vaillant at gmail.com (Paul Vaillant) Date: Sat, 29 Oct 2005 15:51:39 -0600 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: References: <45f94645c14a.45c14a45f946@shaw.ca> <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> Message-ID: <9e8e66200510291451p53168841k7eef6f7e22574db5@mail.gmail.com> There was some stuff burried in one of my emails, but I started a wiki page that has the API. I've got the basics of the acts_as plugin started and I was thinking the same if it work well about releasing separately, either on the same site we have or a separate site. It is something that other might have to deal with, and I went with i18n because it might eventually expand into more. The other reason that I like the library/plugin approach is that it provides a layer of abstraction, such that we can set an API and then change the underlaying implementation to be something else if we wanted without much hassle. As for rails, I agree, but still think that we should finish a model and decide on controllers/actions before we start to insure that we get something consistent at the end and not something that feels like its a bunch of separate pieces just kluged together. Do you have DBDesigner? Its a nice graphical database design program so that we can produce models and images of the model. paul On 10/29/05, Peter Michaux wrote: > > I've been reading about plugins today. Where did you learn about > writing plugins. I found some info > > http://wiki.rubyonrails.com/rails/pages/Plugins > http://www.jamis.jamisbuck.org/articles/2005/10/11/plugging-into-rails > > > acts_as_i18n > > How about "acts_as_translated"? I'm thinking that the topic of i18n > involves more than just translation which is all the plugin will deal > with. > > I thought you wrote an email with a possible api for the plugin. I've > looked everywhere but can't find it. Did you send one? > > If your translation plugin is super sweet perhaps we can create a > spin-off rubyForge project to release it. That is something I'd like to > see happen if we solve some problems that others also have. > > I only have Rails 0.10 on my computer so I'll have to upgrade to try > the plugin. I was hoping I could wait until the Rails 1.0 gem was ready > but that may be a little ways off yet. > > -Peter > > _______________________________________________ > Storerb-devel mailing list > Storerb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/storerb-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/storerb-devel/attachments/20051029/a914245d/attachment.htm From petermichaux at shaw.ca Sat Oct 29 22:00:07 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Sat, 29 Oct 2005 19:00:07 -0700 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <9e8e66200510291451p53168841k7eef6f7e22574db5@mail.gmail.com> References: <45f94645c14a.45c14a45f946@shaw.ca> <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> <9e8e66200510291451p53168841k7eef6f7e22574db5@mail.gmail.com> Message-ID: > Do you have DBDesigner? I just checked out the site and it looks like a very cool tool. It advertises it isfor KDE 2.0 and I'm using OS X. Are you developing on Linux? I agree with all the other stuff. It looks like another plugin is going to be released with the i18n name but I don't know what its features will be. I wonder if it will handle both dynamic an static text. Peter From petermichaux at shaw.ca Sat Oct 29 22:02:46 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Sat, 29 Oct 2005 19:02:46 -0700 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <9e8e66200510291451p53168841k7eef6f7e22574db5@mail.gmail.com> References: <45f94645c14a.45c14a45f946@shaw.ca> <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> <9e8e66200510291451p53168841k7eef6f7e22574db5@mail.gmail.com> Message-ID: <6750ceacd463b08f45e22c673c4d61b7@shaw.ca> Some more thoughts from Tobin below > Hi Peter, > > No probs, be interesting to see how things work out. > > Multilinguism does present many challenges, but I liked your idea of > getting rails to handle it similar to how validation is done. This has > got me thinking, so here's a few thoughts that you may/may not have > already had!... > > This is a bit of a whacky idea, but you could possibly extend rails to > do something like the following. Consider this: > > class Product < ActiveRecord::Base > uses_resources_for :field => :name, :resource_key => > "products.#{id}.name" > uses_resources_for :field => :description, :resource_key => > "products.#{id}.description" > End > > Some sample data might be: > > insert into products (id,price) values (1, 100); > > Note that we don't need to insert the name and description resource > link. Instead, Rails will work this out at runtime baed on the > "uses_resources_for" directive. > > insert into resources (key,text) values ('products.1.name', 'en-GB', > 'Sony Vaio'); > insert into resources (key,text) values ('products.1.description', > 'en-GB', 'This is a nice laptop.'); > > Then, some rhtml code might be: > > (note: user language could be given in the URL such as > www.mystore.com/en-GB/products/sony_vaio_fr415s) >

<%= product.name %>

>

<%= product.description %> > > Rails would have magically added "name" and "description" attributes, > and loaded the correct resource data in. > > You might also tell the framework how to detect the current users > selected language, such as (in config.rb) > > #to detect from urls such as http://mystore.com/en-GB/products/123 > ActiveLocale::Base.detect_locale = :request_uri > > Or > #to detect from session variable > ActiveLocale::Base.detect_locale = "session[:language_code]" > > I guess the appoach I'd like to see would be in keeping with how rails > handles many things - Rails doing the grunt work based on some simple > conventions. Hehe, I realise what I've suggested is probably loaded > with potential issues, I'm just thinking out loud really... > > Tobin > > -- > No virus found in this outgoing message. > Checked by AVG Free Edition. > Version: 7.1.361 / Virus Database: 267.12.6/151 - Release Date: > 28/10/2005 > > From papipo at gmail.com Sat Oct 29 23:03:38 2005 From: papipo at gmail.com (=?ISO-8859-1?Q?Rodrigo_Alvarez_Fern=E1ndez?=) Date: Sun, 30 Oct 2005 04:03:38 +0100 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: References: <45f94645c14a.45c14a45f946@shaw.ca> <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> <9e8e66200510291451p53168841k7eef6f7e22574db5@mail.gmail.com> Message-ID: <6d2bdda0510292003m27c786ddkb0c29b3a33713ab2@mail.gmail.com> On 10/30/05, Peter Michaux wrote: > > > Do you have DBDesigner? > > I just checked out the site and it looks like a very cool tool. It > advertises it isfor KDE 2.0 and I'm using OS X. Are you developing on > Linux? > > I agree with all the other stuff. It looks like another plugin is going > to be released with the i18n name but I don't know what its features > will be. I wonder if it will handle both dynamic an static text. > DBDesigner development stopped some time ago. Now, the developers are working in MySQL Workbench, a tool for www.mysql.com. It will be better than DBD for sure. There is an alpha version somewhere, and a beta is planned before the end of this year. This is an example of some info you can gather in their forums: http://forums.mysql.com/read.php?113,39057,39057 Regards, Rodrigo. From paul.vaillant at gmail.com Sun Oct 30 01:51:05 2005 From: paul.vaillant at gmail.com (Paul Vaillant) Date: Sat, 29 Oct 2005 23:51:05 -0600 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: References: <45f94645c14a.45c14a45f946@shaw.ca> <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> <9e8e66200510291451p53168841k7eef6f7e22574db5@mail.gmail.com> Message-ID: <9e8e66200510292251s238ab4ep86da4ad86d7f380@mail.gmail.com> I just noticed there's another dbdesigner. Check out http://fabforce.net/dbdesigner4/. I don't see a mac one, but maybe the linux or source versions might work. I develop on Windows and Linux. I'm looking for a way to justify a Mac with OS X 10.4; maybe an iBook one day, but I want to know whats going on with the whole Intel chip thing first, cause otherwise I'll run it under VMWare. paul On 10/29/05, Peter Michaux wrote: > > > > Do you have DBDesigner? > > I just checked out the site and it looks like a very cool tool. It > advertises it isfor KDE 2.0 and I'm using OS X. Are you developing on > Linux? > > I agree with all the other stuff. It looks like another plugin is going > to be released with the i18n name but I don't know what its features > will be. I wonder if it will handle both dynamic an static text. > > Peter > > _______________________________________________ > Storerb-devel mailing list > Storerb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/storerb-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/storerb-devel/attachments/20051029/67df5021/attachment.htm From petermichaux at shaw.ca Sun Oct 30 01:09:18 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Sat, 29 Oct 2005 23:09:18 -0700 Subject: [Storerb-devel] Qanah RubyForge Project Email Archives Message-ID: <6b6e31f077e9e354b5543debc91a4b7c@shaw.ca> The Qanah project is merging with store.rb. There was some discussion on the Qanah email lists and I am preserving it here This is the March 2005 archive. - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From timmy at jhnsn.org Thu Mar 24 10:03:33 2005 From: timmy at jhnsn.org (Timothy Johnson) Date: Thu Mar 24 09:58:54 2005 Subject: Technologies Message-ID: <56e86f410be8f1448b23cfea89acdf5c at jhnsn.org> I think that the public-facing portion of this website should still be done regularly, with standards-compliant XHTML and CSS, abstracting this of course from the logic so that you could essentially build an HTML 4 template replete with tables (if you wanted to, ). But the point of this is that I would really like to see the administrative interface be done with Ajax. I think it is a no-brainer for the future, and to require that shop owners/admins use one of the latest browsers will make for a vastly different experience for them. -- Timothy Johnson Found. Interactive Design www.designfound.com 540-289-3157 From jkugler at bigfoot.com Thu Mar 24 20:55:32 2005 From: jkugler at bigfoot.com (Joshua J. Kugler) Date: Thu Mar 24 20:50:41 2005 Subject: Technologies In-Reply-To: <56e86f410be8f1448b23cfea89acdf5c at jhnsn.org> References: <56e86f410be8f1448b23cfea89acdf5c at jhnsn.org> Message-ID: <200503241655.32899.jkugler at bigfoot.com> Woohoo! Our first devel post! :) On Thursday 24 March 2005 06:03, Timothy Johnson said something like: > I think that the public-facing portion of this website should still > be done regularly, with standards-compliant XHTML and CSS, > abstracting this of course from the logic so that you could > essentially build an HTML 4 template replete with tables (if you > wanted to, ). I agree, shudder. I know there are other means of doing layout, so I think I'm going to leave that to our designers, because while my tech knowledge has been progressing, my design/html/css knowledge has not. I would only know how to use tables, but I know there is a better way. I'm not sure how much we'll extract logic, but I'm open to ideas. My general idea was to use templates (or even use the views of rails as the templates), then let users mess with those. We'd provide functions for printing out links, news, etc, but most of the logic would not be in the template itself. Did you have another idea in mind? Hmm...now that I think about it. The views would be untouched, but they would be really bare bones, and simply process templates. Something to hash out. > But the point of this is that I would really like to see the > administrative interface be done with Ajax. I think it is a > no-brainer for the future, and to require that shop owners/admins use > one of the latest browsers will make for a vastly different > experience for them. Agreed...that would be great! And now Rails has that all built in as of the latest release. With Firefox now widespread, there would be no need to require IE or anything like that to use the interface. j----- k----- -- Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295 Every knee shall bow, and every tongue confess, in heaven, on earth, and under the earth, that Jesus Christ is LORD -- Count on it! From agorilla at gmail.com Thu Mar 24 23:49:02 2005 From: agorilla at gmail.com (Bill Guindon) Date: Thu Mar 24 23:44:07 2005 Subject: Technologies In-Reply-To: <200503241655.32899.jkugler at bigfoot.com> References: <56e86f410be8f1448b23cfea89acdf5c at jhnsn.org> <200503241655.32899.jkugler at bigfoot.com> Message-ID: <67a22292050324204964e9943d at mail.gmail.com> On Thu, 24 Mar 2005 16:55:32 -0900, Joshua J. Kugler wrote: > Woohoo! Our first devel post! :) > > On Thursday 24 March 2005 06:03, Timothy Johnson said something like: > > I think that the public-facing portion of this website should still > > be done regularly, with standards-compliant XHTML and CSS, > > abstracting this of course from the logic so that you could > > essentially build an HTML 4 template replete with tables (if you > > wanted to, ). > > I agree, shudder. I know there are other means of doing layout, so I > think I'm going to leave that to our designers, because while my tech > knowledge has been progressing, my design/html/css knowledge has not. > I would only know how to use tables, but I know there is a better way. > > I'm not sure how much we'll extract logic, but I'm open to ideas. My > general idea was to use templates (or even use the views of rails as > the templates), then let users mess with those. We'd provide functions > for printing out links, news, etc, but most of the logic would not be > in the template itself. Did you have another idea in mind? > > Hmm...now that I think about it. The views would be untouched, but they > would be really bare bones, and simply process templates. Something to > hash out. > > > But the point of this is that I would really like to see the > > administrative interface be done with Ajax. I think it is a > > no-brainer for the future, and to require that shop owners/admins use > > one of the latest browsers will make for a vastly different > > experience for them. I like the idea of using Ajax (even tho' I know little about it), as I've used "static" admins forever, and have grown to hate them. > Agreed...that would be great! And now Rails has that all built in as of > the latest release. With Firefox now widespread, there would be no > need to require IE or anything like that to use the interface. No, no need to require IE, but certainly something that's "current". I have no problem with that, just avoid making the fatal mistake of carrying that to the web side. Telling admins what they "must" use is fair game, but try to tell customers that... and, you'll pay for that kind of thinking. -- Bill Guindon (aka aGorilla) From jkugler at bigfoot.com Fri Mar 25 01:37:08 2005 From: jkugler at bigfoot.com (Joshua J. Kugler) Date: Fri Mar 25 01:32:18 2005 Subject: Technologies In-Reply-To: <67a22292050324204964e9943d at mail.gmail.com> References: <56e86f410be8f1448b23cfea89acdf5c at jhnsn.org> <200503241655.32899.jkugler at bigfoot.com> <67a22292050324204964e9943d at mail.gmail.com> Message-ID: <200503242137.08467.jkugler at bigfoot.com> [This was weird...shows up in the archives, but the copy sent to qanah-devel never got to me...I got the copy CC'ed to me.] On Thursday 24 March 2005 19:49, Bill Guindon said something like: > > > But the point of this is that I would really like to see the > > > administrative interface be done with Ajax. I think it is a > > > no-brainer for the future, and to require that shop owners/admins > > > use one of the latest browsers will make for a vastly different > > > experience for them. > > I like the idea of using Ajax (even tho' I know little about it), as > I've used "static" admins forever, and have grown to hate them. Things are so much easier when you can be faster..at least it feels like it. Using Ajax, it will feel like using a local client to configure your system. Should be fun. > > Agreed...that would be great! And now Rails has that all built in > > as of the latest release. With Firefox now widespread, there would > > be no need to require IE or anything like that to use the > > interface. > > No, no need to require IE, but certainly something that's "current". > I have no problem with that, just avoid making the fatal mistake of > carrying that to the web side. Telling admins what they "must" use > is fair game, but try to tell customers that... and, you'll pay for > that kind of thinking. Certainly. Requiring IE or Firefox for admin isn't a big deal. But the site itself should support the (almost) lowest common denominator. j----- k----- -- Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295 Every knee shall bow, and every tongue confess, in heaven, on earth, and under the earth, that Jesus Christ is LORD -- Count on it! From timmy at jhnsn.org Fri Mar 25 08:37:20 2005 From: timmy at jhnsn.org (Timothy Johnson) Date: Fri Mar 25 08:32:28 2005 Subject: Technologies In-Reply-To: <200503242137.08467.jkugler at bigfoot.com> References: <56e86f410be8f1448b23cfea89acdf5c at jhnsn.org> <200503241655.32899.jkugler at bigfoot.com> <67a22292050324204964e9943d at mail.gmail.com> <200503242137.08467.jkugler at bigfoot.com> Message-ID: Certainly, though I think that in 2-3 years time we can (and should) expect that AJAX will be available for a decent majority. At least you can say that the web users that spend the most time online and spend the most money will have gotten out of IE5 by then. So AJAX should be a go for the admin interface, and something we plan as a "possibility" for the customer-facing end. -- Timothy Johnson Found. Interactive Design www.designfound.com 540-289-3157 On Mar 25, 2005, at 1:37 AM, Joshua J. Kugler wrote: > No, no need to require IE, but certainly something that's "current". > I have no problem with that, just avoid making the fatal mistake of > carrying that to the web side. Telling admins what they "must" use > is fair game, but try to tell customers that... and, you'll pay for > that kind of thinking. Certainly. Requiring IE or Firefox for admin isn't a big deal. But the site itself should support the (almost) lowest common denominator. From sburton at themarcomgroup.com Fri Mar 25 12:38:59 2005 From: sburton at themarcomgroup.com (Scott Burton) Date: Sat Mar 26 02:26:58 2005 Subject: Technologies In-Reply-To: <200503241655.32899.jkugler at bigfoot.com> Message-ID: <200503251734.j2PHYfdS008612 at rubyforge.org> Now the question is how should the layout be implemented? Should they be able to change it via browser in a form? If so, will it use the current rails Layout functionality? If it does should you store the layout in the db and somehow get ActionView to use the db layout as the "layout"??? Or, should the layout load from the layout file which you can edit and it saves the changes to the file system? I have been wondering about this for a couple of applications. Any suggestions, ideas, comments? Scott Burton http://spurton.blogspot.com -----Original Message----- From: qanah-devel-bounces at rubyforge.org [mailto:qanah-devel-bounces at rubyforge.org] On Behalf Of Joshua J. Kugler Sent: Thursday, March 24, 2005 5:56 PM To: qanah-devel at rubyforge.org Subject: Re: Technologies Woohoo! Our first devel post! :) On Thursday 24 March 2005 06:03, Timothy Johnson said something like: > I think that the public-facing portion of this website should still be > done regularly, with standards-compliant XHTML and CSS, abstracting > this of course from the logic so that you could essentially build an > HTML 4 template replete with tables (if you wanted to, ). I agree, shudder. I know there are other means of doing layout, so I think I'm going to leave that to our designers, because while my tech knowledge has been progressing, my design/html/css knowledge has not. I would only know how to use tables, but I know there is a better way. I'm not sure how much we'll extract logic, but I'm open to ideas. My general idea was to use templates (or even use the views of rails as the templates), then let users mess with those. We'd provide functions for printing out links, news, etc, but most of the logic would not be in the template itself. Did you have another idea in mind? Hmm...now that I think about it. The views would be untouched, but they would be really bare bones, and simply process templates. Something to hash out. > But the point of this is that I would really like to see the > administrative interface be done with Ajax. I think it is a no-brainer > for the future, and to require that shop owners/admins use one of the > latest browsers will make for a vastly different experience for them. Agreed...that would be great! And now Rails has that all built in as of the latest release. With Firefox now widespread, there would be no need to require IE or anything like that to use the interface. j----- k----- -- Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295 Every knee shall bow, and every tongue confess, in heaven, on earth, and under the earth, that Jesus Christ is LORD -- Count on it! _______________________________________________ Qanah-devel mailing list Qanah-devel at rubyforge.org http://rubyforge.org/mailman/listinfo/qanah-devel From jkugler at bigfoot.com Thu Mar 31 23:03:46 2005 From: jkugler at bigfoot.com (Joshua J. Kugler) Date: Thu Mar 31 22:58:37 2005 Subject: I'm back! Message-ID: <200503311903.47056.jkugler at bigfoot.com> All - I apologize for my absense. Things got busy last week, and then my wife went in to labor Monday evening. I have a brand new baby girl! Mom and baby are doign great! At any rate, I should soon be be able to get back to the list. I'm working on a "brain dump:" part requirements, part design, par implementation considerations. Talk to you all soon! j----- k----- -- Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295 Every knee shall bow, and every tongue confess, in heaven, on earth, and under the earth, that Jesus Christ is LORD -- Count on it! From agorilla at gmail.com Thu Mar 31 23:13:11 2005 From: agorilla at gmail.com (Bill Guindon) Date: Thu Mar 31 23:08:01 2005 Subject: I'm back! In-Reply-To: <200503311903.47056.jkugler at bigfoot.com> References: <200503311903.47056.jkugler at bigfoot.com> Message-ID: <67a2229205033120132bae4bdf at mail.gmail.com> On Mar 31, 2005 11:03 PM, Joshua J. Kugler wrote: > All - > > I apologize for my absense. Things got busy last week, and then my wife > went in to labor Monday evening. I have a brand new baby girl! Mom > and baby are doign great! > > At any rate, I should soon be be able to get back to the list. I'm > working on a "brain dump:" part requirements, part design, par > implementation considerations. > > Talk to you all soon! > Congrats! One of the few things that even developers tend to deliver on schedule ;-) -- Bill Guindon (aka aGorilla) From petermichaux at shaw.ca Sun Oct 30 01:11:13 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Sat, 29 Oct 2005 23:11:13 -0700 Subject: [Storerb-devel] Qanah RubyForge Project Email Archives In-Reply-To: <6b6e31f077e9e354b5543debc91a4b7c@shaw.ca> References: <6b6e31f077e9e354b5543debc91a4b7c@shaw.ca> Message-ID: <4b0df2f3e2de03c74849a285f0de4d7d@shaw.ca> Qanah April 2005 archives - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From jkugler at bigfoot.com Sun Apr 24 19:50:50 2005 From: jkugler at bigfoot.com (Joshua J. Kugler) Date: Sun Apr 24 19:44:59 2005 Subject: Technologies In-Reply-To: References: <56e86f410be8f1448b23cfea89acdf5c at jhnsn.org> <200503242137.08467.jkugler at bigfoot.com> Message-ID: <200504241550.50152.jkugler at bigfoot.com> On Friday 25 March 2005 04:37, Timothy Johnson said something like: > Certainly, though I think that in 2-3 years time we can (and should) > expect that AJAX will be available for a decent majority. At least > you can say that the web users that spend the most time online and > spend the most money will have gotten out of IE5 by then. > > So AJAX should be a go for the admin interface, and something we plan > as a "possibility" for the customer-facing end. Agreed. Ajax so so much fun, and approaches the whole "desktop app via web" paradigm. I would say that we can make everything AJax when KDE's Konqueror supports it. :) I know RoR supports Ajax natively now, but I need to do some investigation on how well it degrades for non-Ajax clients. If it "auto-degrades," then we could it all Ajax from the get-go, but that will have to be thought through. j----- k----- -- Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295 Every knee shall bow, and every tongue confess, in heaven, on earth, and under the earth, that Jesus Christ is LORD -- Count on it! From jkugler at bigfoot.com Sun Apr 24 21:11:16 2005 From: jkugler at bigfoot.com (Joshua J. Kugler) Date: Sun Apr 24 21:05:25 2005 Subject: Qanah Brain Dump #1 Message-ID: <200504241711.16069.jkugler at bigfoot.com> Qanah Brain Dump #1 Well, I'm sitting here waiting for my tires to get switched out (something you do in Alaska, you have one set of tires for summer, another set for winter), I thought I'd get working on a brain dump. What this will be is a combination of requirements, design ideas, and implementation considerations. And nothing here is in hard concrete...this is ideas, brainstorming, and hopefully conversation starter. So, here we go. Let's see what I can come up with...in no particular order. === Authentication/Authorization === As was pointed out recently on the Ruby (or was it Rails) list, authentication is the easy part, authorization is what can really bring a system to its knees. I propose an ACL-based authorization system. Something along the lines of Store ID Section of store (?) Allow (maybe Deny too?) Action User ID Every time an action is attempted on the admin side of things, a query will be issued to check that the User ID has an entry that allows them to complete that action. When a person logs in, the system will check to see if their record allows them admin access, and if so, will add a link on pages displayed to get to the admin page (remembered via a cookie). Of course, if they click on this link, the system would check to make sure they can actually get to the admin interface. I'm sure there are already authorization frameworks in Resistance (or at least ideas) that would help us in this area. === Mutli-store === I want Qanah to be simple enough to run one store out of it, but still have the infrastructure to run several stores, such as a case where a person "resells" stores, or admins the tech side of the store for others who want to sell their products online. One way to do this would be one doc root, lots of hosts, and let the host requested determine the store data that is returned. Probably not a good idea. A better idea would be to have several doc roots, and in each doc root have either a config file, or and index.cgi, or somesuch, that would determine the request response. It could be as simple as a single line that says: StoreName="SomeStoreName" Which would then set the Store Name, ergo the StoreID, off of which the rest of the request would key. Of course, all the code that actually runs is the exact same, it only gets the needed config from the Doc root for the host. === Multi-department === A store needs, obviously, to be able to broken down by departments (probably sub-departments, too...see Newegg). Admin permissions would be broken down departments, too, most likely. === Style === Code will follow this style: Variables and methods should be written lower case, separated by underscores like so: method_name, variable_name Class Names should be written in MixedCase Constants should be written ALL_UPPERCASE Code will indent with hard tabs, that way, those editing can set the tabs display to whatever they want. I prefer two or four. Should we require Hungarian notation? As in, arr_variable, str_variable, int_variable, etc, or should code simply be clear enough to not need these? I know in VB Hungarian notation is nice, but there are a lot more variables floating around in a VB file too. :) One line if/unless only allowed if *all* the code fits on one line (< 80 char), otherwise use multiline if or unless blocks. === Templates and Layouts === [Prompted by a recent thread on this list] Pages for certain things such as main page, product list, account editing, may have different templates. Then again, they may all be the same, and just "filled in" with different info depending on current action. Rail's render and partial render features allow you to have a mostly HTML template in which is interspersed calls out to render views (such as a list of links, toolbars, etc). I think we should have a a "bunch" (define that however you want) of content generators (such as the aforementioned list) that could be placed wherever in the page template that you wanted. Something like this (from a recent rails post): > (html) > <%= render_partial "toolbar" %> > (html) > <%= render_partial "navigation" %> > (html) > <%= render_partial "margin" %> > (html) > <%= @content_for_layout %> > (html) That way, you could create other "partials" that fit your needs, and all we would have to do is create enough documentation to tell the user to put <%render_partial "gizmo name" %> where they want that info put, and put <%= @content_for_layout %> where they want the main content of their page. This would also allow the easy addition of other Gizmos, such as a poll, newletter subscribe, etc, without having to redo the entire page layout or controller. So, yes that means users could still use tables for layout, but hopefully our default template would be nice and purdy using CSS, XHTML, etc. Once thing we'd have to be careful about *is* file permissions. If we want to edit this from a web interface, then we'd need to make sure that the web server can write the file. Read permissions would already be there, obviously. In a shared environment, this might be an issue if all the web servers run as a single UID. But with fcgi seeming to be the preferred environment for Rails (or Webrick for devel), I don't think that will be a problem since fcgi can run SUID owner_of_script. If Rails can use a layout from the DB (which would be really cool), then permissions are a moot point. We would also one some simple "one revision" version control, or at least a way to run the newly edited layout through a check before it was committed to make sure it would pass muster before it got written as the publicly seen template. === Sessions === I would intend to use cookies to track sessions. Session ID's in URL's are really ugly (and can really mess up your app logic and security if someone is sending someone else the URL. Think of this: User logs in, find a product they like, sends the URL (with session ID) to friend. Friend views product, then discovers he's logged in to their friends account, and orders it on his account. Yes, you could require another login before purchase, but that's an inconvenience to the user. Hidden fields in a form are an option too, but that requires every operation to be a form operation. I vote cookies. Or Flash objects (just kidding!). === Shopping Carts === My initial thought was to store all shopping cart data in the DB, then once they decided to check out, it's simply moved to the orders table (the cart table would probably have a similar schema to the order table). However, it would not be hard to store the shopping cart in cookies. A format such as: "ProductID,Quantity;ProductID,Quantity;..." would store a lot of products before we got to any kind of length limit. If we did this, no session would be needed if they were not logged in. And from that follows that they would have persistant shopping carts (up to a time limit) without having to have "open" sessions or records in the site DB. === Shipping Address(es) === As Derek Sivers noted in his blog, , shipping might not be as easy as it first appears. There are split shipments (different warehouses, or backorders), and some shipments might have different items going to different addresses (think gifts). We'll need to do some serious thinking about how to handle shipments in an elegant, expandable way. I don't want Qanah (or our users) to be backed into a corner because the shipping system is not flexible enough to handle their needs. Split shipments will be a primary issue due to the nature of multiple departments, product "owners," and multiple warehouses. There will be separate shipments to keep track of, and shipping will have to be calculated from each warehouse and for each shipment. See for more shipping fun. === "Stealing" Ideas === When it comes down to it, it's all about research, right? Stealing one man's work is plagiarism. Stealing several mens' work is research. So, we probably need to look at other big eCommerce systems to "see how they did it." OSCommerce comes to mind. Do I have any volunteers to research other eCommerce projects and present a summary of how various aspects (features, etc) were engineered and handled? ====== So, that's it for my first Brain Dump. Hopefully this will spark conversation. I look forward to your feedback. j----- k----- -- Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295 Every knee shall bow, and every tongue confess, in heaven, on earth, and under the earth, that Jesus Christ is LORD -- Count on it! From agorilla at gmail.com Sun Apr 24 23:22:53 2005 From: agorilla at gmail.com (Bill Guindon) Date: Sun Apr 24 23:16:58 2005 Subject: Qanah Brain Dump #1 In-Reply-To: <200504241711.16069.jkugler at bigfoot.com> References: <200504241711.16069.jkugler at bigfoot.com> Message-ID: <67a22292050424202257c29765 at mail.gmail.com> Yikes, that's a lot to reply too. I shall do my best. On 4/24/05, Joshua J. Kugler wrote: > Qanah Brain Dump #1 > > === Authentication/Authorization === > As was pointed out recently on the Ruby (or was it Rails) list, > authentication is the easy part, authorization is what can really bring > a system to its knees. I propose an ACL-based authorization system. > Something along the lines of > > Store ID > Section of store (?) > Allow (maybe Deny too?) > Action > User ID Deny too. In my mind, "Section" == "Product Category", and it's pretty common for store owners to want "private" categories. > Every time an action is attempted on the admin side of things, a query > will be issued to check that the User ID has an entry that allows them > to complete that action. When a person logs in, the system will check > to see if their record allows them admin access, and if so, will add a > link on pages displayed to get to the admin page (remembered via a > cookie). Of course, if they click on this link, the system would check > to make sure they can actually get to the admin interface. To a degree, the same needs to happen with shoppers (see above). > I'm sure there are already authorization frameworks in Resistance (or at > least ideas) that would help us in this area. > > === Mutli-store === > I want Qanah to be simple enough to run one store out of it, but still > have the infrastructure to run several stores, such as a case where a > person "resells" stores, or admins the tech side of the store for > others who want to sell their products online. One way to do this > would be one doc root, lots of hosts, and let the host requested > determine the store data that is returned. Probably not a good idea. > > A better idea would be to have several doc roots, and in each doc root > have either a config file, or and index.cgi, or somesuch, that would > determine the request response. It could be as simple as a single line > that says: > > StoreName="SomeStoreName" > > Which would then set the Store Name, ergo the StoreID, off of which the > rest of the request would key. Of course, all the code that actually > runs is the exact same, it only gets the needed config from the Doc > root for the host. My personal opinion is avoid taking this route. It's pretty much a one in a thousand thing, and can be done as an add-on. I wouldn't make it part of the base as it adds complexity needlessly. > === Multi-department === > A store needs, obviously, to be able to broken down by departments > (probably sub-departments, too...see Newegg). Admin permissions would > be broken down departments, too, most likely. I'm very familiar with stores being broken down by department (Category), but I've not seen an admin done that way. Not sure if it's needed on the admin side, but it's a very interesting idea. > === Style === > Code will follow this style: > > Variables and methods should be written lower case, separated by > underscores like so: > method_name, variable_name > Class Names should be written in MixedCase > Constants should be written ALL_UPPERCASE > Code will indent with hard tabs, that way, those editing can set the > tabs display to whatever they want. I prefer two or four. > > Should we require Hungarian notation? As in, arr_variable, > str_variable, int_variable, etc, or should code simply be clear enough > to not need these? I know in VB Hungarian notation is nice, but there > are a lot more variables floating around in a VB file too. :) Hungarian != Ruby (imho) No need for it. > One line if/unless only allowed if *all* the code fits on one line (< 80 > char), otherwise use multiline if or unless blocks. > > === Templates and Layouts === > [Prompted by a recent thread on this list] > > Pages for certain things such as main page, product list, account > editing, may have different templates. Then again, they may all be the > same, and just "filled in" with different info depending on current > action. They should be separate, and there's likely to be a lot more than you'd think. Many stores want different looks per category for example, or even for certain product groups (also a "category", but they want the look to apply to the product page). > Rail's render and partial render features allow you to have a mostly > HTML template in which is interspersed calls out to render views (such > as a list of links, toolbars, etc). I think we should have a a > "bunch" (define that however you want) of content generators (such as > the aforementioned list) that could be placed wherever in the page > template that you wanted. Something like this (from a recent rails > post): > > > (html) > > <%= render_partial "toolbar" %> > > (html) > > <%= render_partial "navigation" %> > > (html) > > <%= render_partial "margin" %> > > (html) > > <%= @content_for_layout %> > > (html) > > That way, you could create other "partials" that fit your needs, and all > we would have to do is create enough documentation to tell the user to > put > > <%render_partial "gizmo name" %> This is probably beyond the average store owner, but it's becoming more common. > where they want that info put, and put > > <%= @content_for_layout %> > > where they want the main content of their page. > > This would also allow the easy addition of other Gizmos, such as a poll, > newletter subscribe, etc, without having to redo the entire page layout > or controller. If any/all of this could be automated when you install "Gizmo X" (at least a default placement), all the better. > So, yes that means users could still use tables for layout, but > hopefully our default template would be nice and purdy using CSS, > XHTML, etc. The avg. store owner can't even spell HTML, and very few are willing to pay for those of us who can. It should be exposed as much as possible, but "reqiured" alterations should be as few as possible. > Once thing we'd have to be careful about *is* file permissions. If we > want to edit this from a web interface, then we'd need to make sure > that the web server can write the file. Read permissions would already > be there, obviously. In a shared environment, this might be an issue > if all the web servers run as a single UID. But with fcgi seeming to > be the preferred environment for Rails (or Webrick for devel), I don't > think that will be a problem since fcgi can run SUID owner_of_script. > If Rails can use a layout from the DB (which would be really cool), > then permissions are a moot point. Don't over think this at this point. Make it work, then make it right. > We would also one some simple "one revision" version control, or at > least a way to run the newly edited layout through a check before it > was committed to make sure it would pass muster before it got written > as the publicly seen template. You want "preview" and "multiple versions". Owners would kill for ability to change look and feel based on holidays, etc. (ala Google) > === Sessions === > I would intend to use cookies to track sessions. Session ID's in URL's > are really ugly (and can really mess up your app logic and security if > someone is sending someone else the URL. Think of this: User logs in, > find a product they like, sends the URL (with session ID) to friend. > Friend views product, then discovers he's logged in to their friends > account, and orders it on his account. Yes, you could require another > login before purchase, but that's an inconvenience to the user. Hidden > fields in a form are an option too, but that requires every operation > to be a form operation. I vote cookies. Or Flash objects (just > kidding!). Cookies are fine. The average shopper has them on, those who turn them off are smart enough to understand that they need them for shopping. Session ID should be behind the scenes, but should also have a controllable expiration. Some stores want 30 mins, some 3 days. Depends on product (ie: if you're selling one of a kind art, you want it short). > === Shopping Carts === > My initial thought was to store all shopping cart data in the DB, then > once they decided to check out, it's simply moved to the orders table > (the cart table would probably have a similar schema to the order > table). > > However, it would not be hard to store the shopping cart in cookies. A > format such as: "ProductID,Quantity;ProductID,Quantity;..." would store > a lot of products before we got to any kind of length limit. If we did > this, no session would be needed if they were not logged in. And from > that follows that they would have persistant shopping carts (up to a > time limit) without having to have "open" sessions or records in the > site DB. Don't go there. Cart data can get quite huge, quite fast. On top of that, storing it in a cookie is a security risk, as I can edit that cookie. > === Shipping Address(es) === > As Derek Sivers noted in his blog, > , shipping might not be as easy > as it first appears. There are split shipments (different warehouses, > or backorders), and some shipments might have different items going to > different addresses (think gifts). Yep, HUGE issue. Don't try to deliver the world at first, start with simple but expandable. Ignore backorders for now, as they are rarely requested. > We'll need to do some serious thinking about how to handle shipments in > an elegant, expandable way. I don't want Qanah (or our users) to be > backed into a corner because the shipping system is not flexible enough > to handle their needs. > > Split shipments will be a primary issue due to the nature of multiple > departments, product "owners," and multiple warehouses. There will be > separate shipments to keep track of, and shipping will have to be > calculated from each warehouse and for each shipment. See > for more shipping fun. Again, avoid over thinking this at this point (and over designing) as it's likely to delay progress. This is such a HUGE topic, that it could easily bring development to a standstill. On that same note, payment is just as HUGE, and not mentioned. Don't forget it, it's Shipping's twin sister. > === "Stealing" Ideas === > When it comes down to it, it's all about research, right? Stealing one > man's work is plagiarism. Stealing several mens' work is research. > So, we probably need to look at other big eCommerce systems to "see how > they did it." OSCommerce comes to mind. Do I have any volunteers to > research other eCommerce projects and present a summary of how various > aspects (features, etc) were engineered and handled? We should chat privately on that topic. I'd like to show you some store admins. > ====== > > So, that's it for my first Brain Dump. Hopefully this will spark > conversation. I look forward to your feedback. You got it. Use what you like, ignore what you don't, discuss what anything that raises questions. Some topics not raised, but should be running in the background (at least): Payment systems - VERY important. Sales systems - sale, discounts, coupons, gift certificates, gift regestries, upselling. Affilitates - commissioned or simply tracking promotions. Logging - "stalk" your customers. Taxes - Everything from State or City to VAT. Product attribute system - size, color, etc. Not as simple as it may seem. Inventory tracking - Low percentage use (20%?), but can be quite complicated. Clients - desktop tools to manage the store (when possible). > j----- k----- > > -- > Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295 > Every knee shall bow, and every tongue confess, in heaven, on earth, and > under the earth, that Jesus Christ is LORD -- Count on it! > _______________________________________________ > Qanah-devel mailing list > Qanah-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/qanah-devel > -- Bill Guindon (aka aGorilla) From jkugler at bigfoot.com Thu Apr 28 03:03:16 2005 From: jkugler at bigfoot.com (Joshua J. Kugler) Date: Thu Apr 28 02:57:31 2005 Subject: Qanah Brain Dump #1 In-Reply-To: <67a22292050424202257c29765 at mail.gmail.com> References: <200504241711.16069.jkugler at bigfoot.com> <67a22292050424202257c29765 at mail.gmail.com> Message-ID: <200504272303.16597.jkugler at bigfoot.com> FYI: I didn't get the copy of this sent to the mail list. Not sure what is up with Rubyforge, or if some spam filter ate it along the way. On Sunday 24 April 2005 19:22, Bill Guindon said something like: > Yikes, that's a lot to reply too. I shall do my best. I know...it was a dump after all. > > === Authentication/Authorization === > > As was pointed out recently on the Ruby (or was it Rails) list, > > authentication is the easy part, authorization is what can really > > bring a system to its knees. I propose an ACL-based authorization > > system. Something along the lines of > > > > Store ID > > Section of store (?) > > Allow (maybe Deny too?) > > Action > > User ID > > Deny too. In my mind, "Section" == "Product Category", and it's > pretty common for store owners to want "private" categories. Right. I assume you mean categories that only certain customers . Hadn't thought of that. I'm sure we'll have to do some research on authorization frameworks. I guess one way to keep the "load" down on the auth system would be only hit it if really needed. Thus, only protected areas would generate a hit to the auth system. Same thing applys for customers as mentioned in the snipped section below. > > === Mutli-store === > My personal opinion is avoid taking this route. It's pretty much a > one in a thousand thing, and can be done as an add-on. I wouldn't > make it part of the base as it adds complexity needlessly. I guess you're right. Abandoning that, I would like to be able to have the file that change (config, templates, etc) in the document root for each store, then symlink the rest of the code. That way, there is only one location to upgrade, and a little space savings due to non-duplication of code. > > === Multi-department === > > A store needs, obviously, to be able to broken down by departments > > (probably sub-departments, too...see Newegg). Admin permissions > > would be broken down departments, too, most likely. > > I'm very familiar with stores being broken down by department > (Category), but I've not seen an admin done that way. Not sure if > it's needed on the admin side, but it's a very interesting idea. Well, the use case I'm thinking of is where you have a group of artists each maintaining their own section, thus there would need to be department admins, or at least a way of setting product ownership. A department (or category...we need an ontology) admin could modify templates for the site, I suppose. > Hungarian != Ruby (imho) > > No need for it. Didn't think so. > > Pages for certain things such as main page, product list, account > > editing, may have different templates. Then again, they may all be > > the same, and just "filled in" with different info depending on > > current action. > > They should be separate, and there's likely to be a lot more than > you'd think. > > Many stores want different looks per category for example, or even > for certain product groups (also a "category", but they want the look > to apply to the product page). Hmm...I guess we could have templates based on "inheritence." The store would have a template that would "cascade" to all objects below (e.g. a department) unless that object is explicitly modified. > > That way, you could create other "partials" that fit your needs, > > and all we would have to do is create enough documentation to tell > > the user to put > > > > <%render_partial "gizmo name" %> > > This is probably beyond the average store owner, but it's becoming > more common. > If any/all of this could be automated when you install "Gizmo X" (at > least a default placement), all the better. In default templates, we could have render_partial in various areas of the template, such as left top, center top, right top, left side, right side, etc, and have a config option to place gizmos there. Custom editing would be allowed of course. Each Gizmo cold have a record in the database as to which 'section" it will be placed in. Then, when that section is rendered, it will pull in all Gizmos for that section. If a person is using a custom template, then they will put the Gizmos where they want them and not use "page sections." Metadot uses an approach similar to this. > The avg. store owner can't even spell HTML, and very few are willing > to pay for those of us who can. It should be exposed as much as > possible, but "reqiured" alterations should be as few as possible. Hopefully we would have a set of sufficiently attractivce, and easily modifiable, default tempates. > > Once thing we'd have to be careful about *is* file permissions. > Don't over think this at this point. Make it work, then make it > right. True. > > We would also one some simple "one revision" version control, or at > > least a way to run the newly edited layout through a check before > > it was committed to make sure it would pass muster before it got > > written as the publicly seen template. > > You want "preview" and "multiple versions". Owners would kill for > ability to change look and feel based on holidays, etc. (ala Google) Oh yeah...date based usage of templates...that would be nice. Preview would be nice too. Or a "devel" side where you could be do all sorts of changes without the live side seeing them. > > === Sessions === > > I would intend to use cookies to track sessions > > Cookies are fine. The average shopper has them on, those who turn > them off are smart enough to understand that they need them for > shopping. Session ID should be behind the scenes, but should also > have a controllable expiration. Some stores want 30 mins, some 3 > days. Depends on product (ie: if you're selling one of a kind art, > you want it short). Configurable cookie expiration is a must, of course. > > === Shopping Carts === > > My initial thought was to store all shopping cart data in the DB, > > then once they decided to check out, it's simply moved to the > > orders table (the cart table would probably have a similar schema > > to the order table). > > > > However, it would not be hard to store the shopping cart in > > cookies. A format such as: > > "ProductID,Quantity;ProductID,Quantity;..." would store a lot of > > products before we got to any kind of length limit. If we did > > this, no session would be needed if they were not logged in. And > > from that follows that they would have persistant shopping carts > > (up to a time limit) without having to have "open" sessions or > > records in the site DB. > > Don't go there. Cart data can get quite huge, quite fast. On top of > that, storing it in a cookie is a security risk, as I can edit that > cookie. Hmmm...I see the size issue. But if all I'm storing in the cookie is ID and Quantity, I'm not sure I see the problem. Once you get to checkout, you've moved it server side. If they want to increase their quantity before they get to checkout, that's fine with me. :) As to keeping shopping carts in the DB, we'd then need a cron script to run every five minutes or so and clean things up. An in-memory table might even be a good idea (that's have to be in the schema for the various DB's). > > === Shipping Address(es) === > > shipping might not be as easy as it first appears. > Yep, HUGE issue. Don't try to deliver the world at first, start with > simple but expandable. > Ignore backorders for now, as they are rarely requested. I agree..start simple. The interesting part will be architecting a system which will be easy to expand, and ideally, backward compatible. > Again, avoid over thinking this at this point (and over designing) as > it's likely to delay progress. This is such a HUGE topic, that it > could easily bring development to a standstill. This is true. I know you can "throw away your first version," but I really want to try to avoid that. :) > On that same note, payment is just as HUGE, and not mentioned. Don't > forget it, it's Shipping's twin sister. See note below. > You got it. Use what you like, ignore what you don't, discuss what > anything that raises questions. Oh, there are still plenty of things to talk about. :) > Some topics not raised, but should be running in the background (at > least): > > Payment systems - VERY important. > Sales systems - sale, discounts, coupons, gift certificates, gift > regestries, upselling. > Affilitates - commissioned or simply tracking promotions. > Logging - "stalk" your customers. > Taxes - Everything from State or City to VAT. > Product attribute system - size, color, etc. Not as simple as it may > seem. Inventory tracking - Low percentage use (20%?), but can be > quite complicated. Clients - desktop tools to manage the store (when > possible). ooooo...fodder for brain dump #2. This was only #1 after all. :) You just saved me looking through feature lists for other eCommerce systems. Well, at least until after the next brain dump. :) j----- k----- -- Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295 Every knee shall bow, and every tongue confess, in heaven, on earth, and under the earth, that Jesus Christ is LORD -- Count on it! From petermichaux at shaw.ca Sun Oct 30 01:12:57 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Sat, 29 Oct 2005 23:12:57 -0700 Subject: [Storerb-devel] Qanah RubyForge Project Email Archives In-Reply-To: <4b0df2f3e2de03c74849a285f0de4d7d@shaw.ca> References: <6b6e31f077e9e354b5543debc91a4b7c@shaw.ca> <4b0df2f3e2de03c74849a285f0de4d7d@shaw.ca> Message-ID: Qanah July 2005 email archive - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - From jkugler at bigfoot.com Fri Jul 1 05:36:56 2005 From: jkugler at bigfoot.com (Joshua J. Kugler) Date: Fri Jul 1 05:30:02 2005 Subject: Qanah being put on the back burner - for now Message-ID: <200507010136.56498.jkugler at bigfoot.com> All - I owe a few people an apology. I jumped in to trying to start up a project at a time when my schedule just wouldn't handle the load. I did not accurately estimate my time commitments for the coming months when I made the announcement of Qanah this past March. So, for now, Qanah is being put on the back burner. Note I didn't say abandoned: just postponed. If you are subscribed to the listserve, please remain so. When my schedule allows, I want to hit this full on. Thank you all for your ideas and input. I will continue to pursue this as time allows. So until then, keep coding! j----- k----- -- Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295 Every knee shall bow, and every tongue confess, in heaven, on earth, and under the earth, that Jesus Christ is LORD -- Count on it! From scott at posplugin.com Sat Jul 2 00:09:05 2005 From: scott at posplugin.com (Scott Burton) Date: Sat Jul 2 00:04:16 2005 Subject: Qanah being put on the back burner - for now In-Reply-To: <200507010136.56498.jkugler at bigfoot.com> Message-ID: <20050702040903.PNDK1860.fed1rmmtao10.cox.net at ScottsMobile> I totally understand your situation. If you decide to start on something, I am willing to help still. Just give me SVN access :) I still think my package sorting tool from a previous .net project would be a cool addition. Here is an app I have been working on: www.similarthings.com it is a folksonomy-driven CMS. I hope to do more with it but it is pretty cool. I use it for a blog: http://blog.similarthings.com It can be used for a regular website too, although I need to implement the settings part where you chose if your site is a weblog or a regular site. One thing I would like to do and I hope it happens is providing the ability to create your own "things" Which someone could then create a "product thing" which will be categorized by tags. Then as maybe an ecommerce component add the ability to purchase those items. I dunno, just an idea for the future. However having the ability to do everything could be a bad idea for SimilarThings... Anyway, keep us posted! Scott Burton Weblog: spurton.blogspot.com Site: www.similarthings.com -----Original Message----- From: qanah-devel-bounces at rubyforge.org [mailto:qanah-devel-bounces at rubyforge.org] On Behalf Of Joshua J. Kugler Sent: Friday, July 01, 2005 2:37 AM To: qanah-devel at rubyforge.org; rails at lists.rubyonrails.org; ruby-talk at ruby-lang.org; qanah-users at rubyforge.org; qanah-announce at rubyforge.org Subject: Qanah being put on the back burner - for now All - I owe a few people an apology. I jumped in to trying to start up a project at a time when my schedule just wouldn't handle the load. I did not accurately estimate my time commitments for the coming months when I made the announcement of Qanah this past March. So, for now, Qanah is being put on the back burner. Note I didn't say abandoned: just postponed. If you are subscribed to the listserve, please remain so. When my schedule allows, I want to hit this full on. Thank you all for your ideas and input. I will continue to pursue this as time allows. So until then, keep coding! j----- k----- -- Joshua J. Kugler -- Fairbanks, Alaska -- ICQ#:13706295 Every knee shall bow, and every tongue confess, in heaven, on earth, and under the earth, that Jesus Christ is LORD -- Count on it! _______________________________________________ Qanah-devel mailing list Qanah-devel at rubyforge.org http://rubyforge.org/mailman/listinfo/qanah-devel From petermichaux at shaw.ca Sun Oct 30 13:20:11 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Sun, 30 Oct 2005 10:20:11 -0800 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <9e8e66200510292251s238ab4ep86da4ad86d7f380@mail.gmail.com> References: <45f94645c14a.45c14a45f946@shaw.ca> <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> <9e8e66200510291451p53168841k7eef6f7e22574db5@mail.gmail.com> <9e8e66200510292251s238ab4ep86da4ad86d7f380@mail.gmail.com> Message-ID: Hi Paul, I have had a quick read through of the acts_as_i18n plugin. It looks really cool. I have some questions that will display my poor knowledge of ruby and rails :S I hope you have some time for some really brief answers or comments. 1) What does the abreviation "TBI" stand for? 2) How does the line "if _FILE_ == $0" work? I think _FILE_ just refers to the current file but what is $0? Some sort of global zero? 3) What is "$$.to_s"? 4) If language is CHAR(2) in the database table then what if someone wants to use 'gaelic". It is the only non-two character abreviation. But if it is a standard then I suppose we have to accomodate it. 5) What do the model_id and model_type fields hold? The user doesn't have to set these so I suppose your plugin is setting them. 6) If the plugin is intended to do more than translations then setting the local using the language seems a little off to me. I might be in Canada but want to read in Spanish. What other situations do you see this plugin expanding to deal with? 7) We will need to append "DEFAULT CHARSET=utf8" at the end of the create table sql commands? 8) In the translations table, the text field allows for up to 255 characters. That is fine for product name but maybe is too short for product descriptions. Should we use field type "text" instead? 9) I haven't run rails from the command line before. I changed the she-bang line to match the path to my ruby command. Then I ran the file. I get the following error. $ ./test.rb ./test.rb:409: can't find string "EOM" anywhere before EOF ./test.rb:240: syntax error class_eval <<-EOM ^ It has something to do with this code which my editor is also flagging as something strange. (the editor Textmate knows about ruby.) class_eval <<-EOM def #{f.to_s}; i18n_get_field(:#{f}); end def #{f.to_s}=(text); i18n_set_field(:#{f},text); end EOM I'm going to try to figure out what is wrong but maybe I don't know enough yet. - - - - - - - - - Thanks, Paul! Peter On 30-Oct-05, at 12:36 AM, Paul Vaillant wrote: > No extra classes for acts_as_i18n. The library is quite small overall. > As for the post on rails@, I couldn't find the post you mentioned (I > looked through the archives, but they only go til March 05, and I > couldn't find it on cursory search through gmane), but if you could > send me a link or copy I'd be happy to look at it. I did find a number > of i18n efforts for rails, but they seemed centered on static text and > not text within the models themselves. > Also, if you want to play with acts_as_i18n, the prototype version is > attached to the wiki pages that I've been working on and it includes > tests at the bottom of the script. > > paul > From paul.vaillant at gmail.com Sun Oct 30 13:40:57 2005 From: paul.vaillant at gmail.com (Paul Vaillant) Date: Sun, 30 Oct 2005 11:40:57 -0700 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: References: <45f94645c14a.45c14a45f946@shaw.ca> <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> <9e8e66200510291451p53168841k7eef6f7e22574db5@mail.gmail.com> <9e8e66200510292251s238ab4ep86da4ad86d7f380@mail.gmail.com> Message-ID: <9e8e66200510301040g5c3d7efdn8a1041d4378faf23@mail.gmail.com> On 10/30/05, Peter Michaux wrote: > > Hi Paul, > > I have had a quick read through of the acts_as_i18n plugin. It looks > really cool. I have some questions that will display my poor knowledge > of ruby and rails :S I hope you have some time for some really brief > answers or comments. > > 1) What does the abreviation "TBI" stand for? To Be Implemented 2) How does the line "if _FILE_ == $0" work? I think _FILE_ just refers > to the current file but what is $0? Some sort of global zero? __FILE__ constant points to the current file and $0 points to the ruby file that was executed. If you required acts_as_i18n.rb from a main.rb ruby script then __FILE__ would be 'acts_as_i18n.rb' and $0 would be 'main.rb', but if you run ruby acts_as_i18n.rb __FILE__ is acts_as_i18n.rb and $0 is acts_as_i18n.rb. Basically, that block only runs if you run the library and not if you include it via require. 3) What is "$$.to_s"? $$ is the pid of the running process. Its a number (Integer) so I call $$.to_s to easily create a random number to change the name with. 4) If language is CHAR(2) in the database table then what if someone > wants to use 'gaelic". It is the only non-two character abreviation. > But if it is a standard then I suppose we have to accomodate it. The language codes (as defined by iso639a) are two letter codes. They are included as ActiveRecord::Acts::I18n::LANGAUGES and ISO639a is referenced in the link on the wiki ActsAsI18n page. 5) What do the model_id and model_type fields hold? The user doesn't > have to set these so I suppose your plugin is setting them. > model_type holds the class name ('Product' in this case), model_id holds the id (Product.find(:first).id) and field holds the virtual field name ('name' in the example). 6) If the plugin is intended to do more than translations then setting > the local using the language seems a little off to me. I might be in > Canada but want to read in Spanish. What other situations do you see > this plugin expanding to deal with? Locale= sets the langauge you want to read. If you wanted to read spanish, you'd call locale='es'. We will need to decide on a way to set the language preference, but that's outside the scope of the plugin. Either we will set it once (for no language support) or we might have a preference in the user object and set it for each request. Locale sometimes also encodes the area, but these are only used for areas with more then one langauge (fr-ca and en-ca for example). locale= could be expanded to take this form, but I just didn't. I don't think you would find a locale for es-ca though. 7) We will need to append "DEFAULT CHARSET=utf8" at the end of the > create table sql commands? Yes, this will be required for multi-bytes langauge support. 8) In the translations table, the text field allows for up to 255 > characters. That is fine for product name but maybe is too short for > product descriptions. Should we use field type "text" instead? This could be text, yes. 9) I haven't run rails from the command line before. I changed the > she-bang line to match the path to my ruby command. Then I ran the > file. I get the following error. To test this, all you need to do is run 'ruby acts_as_i18n.rb'. <<-EOM says the argument is a string that starts on the next line and goes to the marker EOM ignoring leading white space (<< would not ignore leading white space). Try maybe removing the space before the EOM marker, this might work. Please let me know if it does. $ ./test.rb > ./test.rb:409: can't find string "EOM" anywhere before EOF > ./test.rb:240: syntax error > class_eval <<-EOM > ^ > > It has something to do with this code which my editor is also flagging > as something strange. (the editor Textmate knows about ruby.) > class_eval <<-EOM > def #{f.to_s}; > i18n_get_field(:#{f}); end > def #{f.to_s}=(text); > i18n_set_field(:#{f},text); end > EOM > > I'm going to try to figure out what is wrong but maybe I don't know > enough yet. > > - - - - - - - - - > > Thanks, Paul! > > Peter > > > > On 30-Oct-05, at 12:36 AM, Paul Vaillant wrote: > > > No extra classes for acts_as_i18n. The library is quite small overall. > > As for the post on rails@, I couldn't find the post you mentioned (I > > looked through the archives, but they only go til March 05, and I > > couldn't find it on cursory search through gmane), but if you could > > send me a link or copy I'd be happy to look at it. I did find a number > > of i18n efforts for rails, but they seemed centered on static text and > > not text within the models themselves. > > > Also, if you want to play with acts_as_i18n, the prototype version is > > attached to the wiki pages that I've been working on and it includes > > tests at the bottom of the script. > > > > paul > > > > _______________________________________________ > Storerb-devel mailing list > Storerb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/storerb-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/storerb-devel/attachments/20051030/36b14b91/attachment.htm From petermichaux at shaw.ca Sun Oct 30 15:30:04 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Sun, 30 Oct 2005 12:30:04 -0800 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <9e8e66200510301040g5c3d7efdn8a1041d4378faf23@mail.gmail.com> References: <45f94645c14a.45c14a45f946@shaw.ca> <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> <9e8e66200510291451p53168841k7eef6f7e22574db5@mail.gmail.com> <9e8e66200510292251s238ab4ep86da4ad86d7f380@mail.gmail.com> <9e8e66200510301040g5c3d7efdn8a1041d4378faf23@mail.gmail.com> Message-ID: >> 1) What does the abreviation "TBI" stand for? > To Be Implemented How would you feel about going with the standard PHP gotchas? I like the names. TODO is exactly what it means and KLUDGE sounds just about right:) (if this works well in the rails world) http://www.phpinfo.net/articles/article_php-coding-standard.html#mge >> 4) If language is CHAR(2) in the database table then what if someone >> wants to use 'gaelic". It is the only non-two character abreviation. >> But if it is a standard then I suppose we have to accomodate it. > > The language codes (as defined by iso639a) are two letter codes. They > are included as ActiveRecord::Acts::I18n::LANGAUGES and ISO639a is > referenced in the link on the wiki ActsAsI18n page. Here is a snip of your LANGUAGES definition 'fr' => ['French','Romance'], 'fy' => ['Frisian','Germanic'], 'ga' => ['Irish','Celtic'], 'gaelic' => ['Scots','Gd'], 'gl' => ['Galician','Romance'], 'gn' => ['Guarani','Amerindian'], 'gu' => ['Gujarati','Indian'], 'ha' => ['Hausa','Negro-african'], from http://www.w3.org/WAI/ER/IG/ert/iso639.htm it looks like we could use "gd" for gaelic? >> 9) I haven't run rails from the command line before. I changed the >> she-bang line to match the path to my ruby command. Then I ran the >> file. I get the following error. > > To test this, all you need to do is run 'ruby acts_as_i18n.rb'. <<-EOM > says the argument is a string that starts on the next line and goes to > the marker EOM ignoring leading white space (<< would not ignore > leading white space). Try maybe removing the space before the EOM > marker, this might work. Please let me know if it does. ? Something is up with that EOM section. I tried changing it to a single line with double quotes but then there were other problems: block not supplied, odd number hash errors.... peter From paul.vaillant at gmail.com Sun Oct 30 21:02:26 2005 From: paul.vaillant at gmail.com (Paul Vaillant) Date: Sun, 30 Oct 2005 19:02:26 -0700 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: References: <45f94645c14a.45c14a45f946@shaw.ca> <9e8e66200510271321q57231f3ameeb281f338ebddb6@mail.gmail.com> <9e8e66200510291451p53168841k7eef6f7e22574db5@mail.gmail.com> <9e8e66200510292251s238ab4ep86da4ad86d7f380@mail.gmail.com> <9e8e66200510301040g5c3d7efdn8a1041d4378faf23@mail.gmail.com> Message-ID: <9e8e66200510301802s35bbbc7dqd29a24656b369554@mail.gmail.com> For coding, I tend to use TBI, BUG, FIX, HACK and XXX. I don't like KLUDGE because it long and I don't trust myself to spell it correctly repeatedly. TODO could work. I used a script to parse ISO639 definitions, so gaelic must be an error. I'll post the script to ActsAsI18n and take a look. I'll work on the EOM tonight too. paul On 10/30/05, Peter Michaux wrote: > > > >> 1) What does the abreviation "TBI" stand for? > > To Be Implemented > > How would you feel about going with the standard PHP gotchas? I like > the names. TODO is exactly what it means and KLUDGE sounds just about > right:) (if this works well in the rails world) > > http://www.phpinfo.net/articles/article_php-coding-standard.html#mge > > > >> 4) If language is CHAR(2) in the database table then what if someone > >> wants to use 'gaelic". It is the only non-two character abreviation. > >> But if it is a standard then I suppose we have to accomodate it. > > > > The language codes (as defined by iso639a) are two letter codes. They > > are included as ActiveRecord::Acts::I18n::LANGAUGES and ISO639a is > > referenced in the link on the wiki ActsAsI18n page. > > Here is a snip of your LANGUAGES definition > > 'fr' => ['French','Romance'], > 'fy' => ['Frisian','Germanic'], > 'ga' => ['Irish','Celtic'], > 'gaelic' => ['Scots','Gd'], > 'gl' => ['Galician','Romance'], > 'gn' => ['Guarani','Amerindian'], > 'gu' => ['Gujarati','Indian'], > 'ha' => ['Hausa','Negro-african'], > > from http://www.w3.org/WAI/ER/IG/ert/iso639.htm it looks like we could > use "gd" for gaelic? > > > >> 9) I haven't run rails from the command line before. I changed the > >> she-bang line to match the path to my ruby command. Then I ran the > >> file. I get the following error. > > > > To test this, all you need to do is run 'ruby acts_as_i18n.rb'. <<-EOM > > says the argument is a string that starts on the next line and goes to > > the marker EOM ignoring leading white space (<< would not ignore > > leading white space). Try maybe removing the space before the EOM > > marker, this might work. Please let me know if it does. > > Something is up with that EOM section. I tried changing it to a single > line with double quotes but then there were other problems: block not > supplied, odd number hash errors.... > > peter > > _______________________________________________ > Storerb-devel mailing list > Storerb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/storerb-devel > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/storerb-devel/attachments/20051030/cd5f6e7d/attachment.htm From petermichaux at shaw.ca Mon Oct 31 11:48:42 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Mon, 31 Oct 2005 08:48:42 -0800 Subject: [Storerb-devel] db model: virtual fields Message-ID: > On 10/31/05, Peter Michaux wrote: >> I added a couple of pages last night about db modeling to >> the s.rb trac. If you haven't read about elasticpath there is a page >> on >> that now. Also there are some pics on the DbModelCatalog page. > On 31-Oct-05, at 8:19 AM, Paul Vaillant wrote: > I did read it and I agree with this. Its an absolute requirement because we don't know what kind of item people will sell, and each type of item will need to be supported differently. > > I'm actually thinking that this might be a good place for a library > too. We could have an acts_as_virtual_fields with the same type of > underlaying structure as acts_as_i18n. This would allow us to support > virtual fields as a customization method as we could add them to just > about any one of our models (users, products, variations, etc...). > Thoughts? That is exactly what I am thinking. Perhaps the two topics close enough to share code. I suppose the way to know is to code both and factor out the common code. > One challenge we might have, and you might be able to shed light on > if/how elasticpath deals with this, is translated virtual fields. As far as I can tell elasticpath doesn't. They don't have a language field in their tables dealing with virtual fields. That is fine for numerical virtual fields but not for descriptive ones. Overall elastic path doesn't seem very internationalized. So how are we going to deal with translated virtual fields? I don't know enough about how plugins work yet. Maybe we will have to have a couple tables to deal with non-translated virtual fields and a couple more to deal with translated virtual fields. I'm ok with that because then that is the end. We would have two plugins "acts_as_virtual_field" and "acts_as_i18n_virtual_field". As a slightly related question, can one model act as more than one thing in Rails? I can see this being very useful for ordered lists. Like so Class Foo < ActiveRecord::Base acts_as_chunky_bacon acts_as_list #... end I think the two biggest modelling issues for us are i18n and virtual fields. From all the playing I've been doing with the database schema I was using, the other topics are much simpler. So time spent on these two issues are well spent. The other stuff seems like just a matter of making some decisions. Peter -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: text/enriched Size: 2472 bytes Desc: not available Url : http://rubyforge.org/pipermail/storerb-devel/attachments/20051031/91db208e/attachment.bin From agorilla at gmail.com Mon Oct 31 12:14:22 2005 From: agorilla at gmail.com (Bill Guindon) Date: Mon, 31 Oct 2005 12:14:22 -0500 Subject: [Storerb-devel] Qanah RubyForge Project Email Archives In-Reply-To: <6b6e31f077e9e354b5543debc91a4b7c@shaw.ca> References: <6b6e31f077e9e354b5543debc91a4b7c@shaw.ca> Message-ID: <67a222920510310914p71f828edpf1aa7e5a1b61d574@mail.gmail.com> On 10/30/05, Peter Michaux wrote: > The Qanah project is merging with store.rb. There was some discussion > on the Qanah email lists and I am preserving it here > Glad to see this here. I hope you find the discussions useful. -- Bill Guindon (aka aGorilla) From agorilla at gmail.com Mon Oct 31 12:18:04 2005 From: agorilla at gmail.com (Bill Guindon) Date: Mon, 31 Oct 2005 12:18:04 -0500 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <56d9dbde646eeb177a5a3977666a63a3@shaw.ca> References: <56d9dbde646eeb177a5a3977666a63a3@shaw.ca> Message-ID: <67a222920510310918u5b12dab6t301bdedb4aa1847f@mail.gmail.com> On 10/26/05, Peter Michaux wrote: > Let's start the database modelling discussion with a some > multilingualism. > > Comencemos la base de datos a modelar la discusi?n con un cierto > multilingualismo. > > Lassen Sie uns die Datenbank beginnen, Diskussion mit einer etwas > Mehrsprachigkeit zu modellieren. > > babelfish :) > > I've written up a little page so that we have something to talk about. > The SQL is for MySQL because it is probably the most common. > > http://trac.vaillant.ca/store.rb/wiki/DbModelMultilingual Couple of quick thoughts: You don't mention images. A lot of sites use images to drive navigation, etc. You may also want to consider having seperate page templates per language. > Please have a look and reply to the list. > > -Peter > > _______________________________________________ > Storerb-devel mailing list > Storerb-devel at rubyforge.org > http://rubyforge.org/mailman/listinfo/storerb-devel > -- Bill Guindon (aka aGorilla) From petermichaux at shaw.ca Mon Oct 31 12:29:55 2005 From: petermichaux at shaw.ca (Peter Michaux) Date: Mon, 31 Oct 2005 09:29:55 -0800 Subject: [Storerb-devel] db model: Multilingualism In-Reply-To: <67a222920510310918u5b12dab6t301bdedb4aa1847f@mail.gmail.com> References: <56d9dbde646eeb177a5a3977666a63a3@shaw.ca> <67a222920510310918u5b12dab6t301bdedb4aa1847f@mail.gmail.com> Message-ID: On 31-Oct-05, at 9:18 AM, Bill Guindon wrote: > Couple of quick thoughts: > > You don't mention images. A lot of sites use images to drive > navigation, etc. Could you expand on this a little. Do you mean images like an "Add to Cart" button image that has the text as part of the little gif? I'd like to avoid this and use the html