Re: ProductCatalogId (and etc.) is not escaped/unescaped

[Jonathon -- Improov <jo...@improov.com>]

David,

I'm curious why Product.productId isn't a meaningless neutral integer as prescribed by the Data 
Model book. Chris Howe described some issues caused by using the Product.productId under some 
circumstances, and they seems closely related to this.

HTTP should support characters 0-9. Is there any language in the world that doesn't use 0-9 but 
something else instead?

Jonathon

David E. Jones wrote:
> 
> HTTP in general is NOT capable of UTF-8 arguments, and you should always 
> stick with ISO-8859(-1) characters for that. For OFBiz this means no *Id 
> fields should have more general, ie UTF-8 or whatever, characters.
> 
> There are quite a few good discussions on this in the OFBiz mailing list 
> archives, and hundreds of general discussions and information pages 
> about it around the internet and even in various RFCs.
> 
> -David
> 
> 
> On Mar 31, 2007, at 4:48 AM, Shi Yusen wrote:
> 
>> Hi list,
>>
>> I want to use a catalog named in Chinese. The creation is OK. But when
>> click the link
>> of /catalog/control/EditProdCatalog?prodCatalogId=ChineseCatalogName on
>> Catalog Main page, there's an error said "Could not Find Product Catalog
>> with Id". I think it's because ProductCatalogId is not
>> escaped/unescaped. I searched the code and could not find
>> escape/unescape method.
>>
>> If there are no such methods, I'll add them.
>>
>> Did I miss something?
>>
>> TIA,
>>
>> Shi Yusen/Beijing Langhua Ltd.
>>
>>
> 

Re: ProductCatalogId (and etc.) is not escaped/unescaped

[Chris Howe <cj...@yahoo.com>]

It is nice to have a primary key be descriptive, as it allows less
programming thought and verification to go into an application. 
However that should be weighed against the dangers and limitations that
convention may put on you.  I don't think prodCatalogId or
prodCategoryId, for that matter, have as many potential pitfalls as
productId does, at least not in the limited ways they have been used
thus far. Also, any convention used for a prodCatalogId or
prodCategoryId can be discarded and not cause as large of a business
interruption as changing a convention on productId might, I would
imagine.  

Tossing my 2 cents in since my name was invoked. :-)

--- Jonathon -- Improov <jo...@improov.com> wrote:

> Hi Shi Yusen,
> 
> You mentioned "prodCatalogId". That goes for all other fields of type
> id-ne, including 
> Product.productId?
> 
> I do agree that improvements need to be made incrementally, so we
> don't have to wait say a decade 
> before we can start using the "corrected" OFBiz. As I told Chris, I'd
> rather not have to 
> do/witness the painfully arduous task of creating say OFBiz version
> "ERD Corrected". It works now 
> for me, and that's all I need (at least until I need to put chinese
> characters into URLs for 
> lookups, but I'd use POST usually).
> 
> I'm just curious why it was done that way, that's all.
> 
> By the way, I was just thinking of importing data, and I realized I
> wouldn't know the primary keys 
>   when entering data for import if those keys were auto-incremented
> integer ids. Is that why all 
> id fields are strings instead of integers?
> 
> Maybe I'll dig into the data reader (that imports data from xml
> files). What happens if my data 
> for import omits primary key values?
> 
> Jonathon
> 
> Shi Yusen wrote:
> > Hi Jonathon,
> > 
> >> I'm curious why Product.productId isn't a meaningless neutral
> integer as prescribed by the Data 
> >> Model book. Chris Howe described some issues caused by using the
> Product.productId under some 
> >> circumstances, and they seems closely related to this.
> > I think ProductId is not discussed in this topic. There's an
> implicit rule: as OFBiz is a productivity application, NO EFFICIENCY
> of OFBiz should be lost when making any improvements :). Take it
> easy.
> > 
> > Regards,
> > 
> > Shi Yusen/Beijing Langhua Ltd.
> > 
> > 
> 
> 

Re: ProductCatalogId (and etc.) is not escaped/unescaped

[Jonathon -- Improov <jo...@improov.com>]

Hi Shi Yusen,

You mentioned "prodCatalogId". That goes for all other fields of type id-ne, including 
Product.productId?

I do agree that improvements need to be made incrementally, so we don't have to wait say a decade 
before we can start using the "corrected" OFBiz. As I told Chris, I'd rather not have to 
do/witness the painfully arduous task of creating say OFBiz version "ERD Corrected". It works now 
for me, and that's all I need (at least until I need to put chinese characters into URLs for 
lookups, but I'd use POST usually).

I'm just curious why it was done that way, that's all.

By the way, I was just thinking of importing data, and I realized I wouldn't know the primary keys 
  when entering data for import if those keys were auto-incremented integer ids. Is that why all 
id fields are strings instead of integers?

Maybe I'll dig into the data reader (that imports data from xml files). What happens if my data 
for import omits primary key values?

Jonathon

Shi Yusen wrote:
> Hi Jonathon,
> 
>> I'm curious why Product.productId isn't a meaningless neutral integer as prescribed by the Data 
>> Model book. Chris Howe described some issues caused by using the Product.productId under some 
>> circumstances, and they seems closely related to this.
> I think ProductId is not discussed in this topic. There's an implicit rule: as OFBiz is a productivity application, NO EFFICIENCY of OFBiz should be lost when making any improvements :). Take it easy.
> 
> Regards,
> 
> Shi Yusen/Beijing Langhua Ltd.
> 
> 

Re: ProductCatalogId (and etc.) is not escaped/unescaped

[Shi Yusen <sh...@langhua.cn>]

Hi Jonathon,

> I'm curious why Product.productId isn't a meaningless neutral integer as prescribed by the Data 
> Model book. Chris Howe described some issues caused by using the Product.productId under some 
> circumstances, and they seems closely related to this.
I think ProductId is not discussed in this topic. There's an implicit rule: as OFBiz is a productivity application, NO EFFICIENCY of OFBiz should be lost when making any improvements :). Take it easy.

Regards,

Shi Yusen/Beijing Langhua Ltd.