Re: widget data type
Antonio Gallardo wrote: On Dom, 20 de Marzo de 2005, 8:48, Giacomo Pati dijo: Antonio Gallardo wrote: On Vie, 18 de Marzo de 2005, 14:43, Giacomo Pati dijo: Actually we use different i18n catalogs in the same page (menu catalog, business term catalog, etc.). And special catalog for every list, is this a good idea at all? Can we define it at the sitemap level? That doesn't solve it. As said, we have pages which uses more than one catalog for i18n things (actually I don't know if one can specify several catalogs in the i18n-transformer step of the sitemap). Well, for sure you know better your requirements than me. I just wanted to point out some idea I had while reading the attributes. As I told before, I am +1 for this enhacement. Ok, I'll summarize before I commit the changes: My proposal Revised proposal --- @nullable replaced by 'if( exists( @null-text ) )' @null-text @null-text (can be an empty string) @null-text-is i18n-key @null-text-is-i18n (cannot find anything better) @label-is-i18n-key @label-is-i18n (same as @null-text-is-i18n) @i18n-catalog @i18n-catalogue I'd like to keep the 'i18n' prefix for clarity as I don't feel catalogue itself associates per se with i18n or we decide to not have his attribute at all. WDYT? Overall OK. Can be posible to use a i18n namespace for the i18n attributes? I am afraid the names are too verbose. Just an idea: Ok, after a bid of source digging I've found a solution: If a @null-text exists a nullable entry is added to the list but not as an i18n key. if a @i18n:null-text exists a nullable entry is added to the selection list as an i18n key but the @null-text attribute has precedence if both are specified. We can do the same with the label-path: if @i18n:label-path is specified instead of a lable-path we treat the label as an i18n key. WDYT now? Since @null-text-is i18n-key and @null-text-is i18n-key are of type [yes|no], then can we use one attribute called @use-i18n. The content of this attribute can be the name of the other 2 attributes, ie: @null-text-is-i18n --> @use-i18n-in="null-text" @label-is-i18n-key --> @use-i18n-in="label" When we need it in both, then: @use-i18n-in="both" or @use-i18n-in="null-text,label" I know we are running out of time. This is again only a suggestion. Please decide you the best in this case. WDYT? Best Regards, Antonio Gallardo. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com smime.p7s Description: S/MIME Cryptographic Signature
Re: widget data type
On Dom, 20 de Marzo de 2005, 8:48, Giacomo Pati dijo: > > > Antonio Gallardo wrote: >> On Vie, 18 de Marzo de 2005, 14:43, Giacomo Pati dijo: >> > > > >>>Actually we use different i18n catalogs in the same page (menu catalog, >>>business term catalog, etc.). >> >> >> And special catalog for every list, is this a good idea at all? Can we >> define it at the sitemap level? > > That doesn't solve it. As said, we have pages which uses more than one > catalog for i18n things (actually I don't know if one can specify > several catalogs in the i18n-transformer step of the sitemap). > >> Well, for sure you know better your requirements than me. I just wanted >> to >> point out some idea I had while reading the attributes. As I told >> before, >> I am +1 for this enhacement. > > Ok, I'll summarize before I commit the changes: > > My proposal Revised proposal > --- > > @nullable replaced by 'if( exists( @null-text ) )' > > @null-text@null-text (can be an empty string) > > @null-text-is i18n-key@null-text-is-i18n (cannot find anything better) > > @label-is-i18n-key@label-is-i18n (same as @null-text-is-i18n) > > @i18n-catalog @i18n-catalogue I'd like to keep the 'i18n' > prefix for clarity as I don't feel catalogue > itself associates per se with i18n or we decide > to not have his attribute at all. > > WDYT? Overall OK. Can be posible to use a i18n namespace for the i18n attributes? I am afraid the names are too verbose. Just an idea: Since @null-text-is i18n-key and @null-text-is i18n-key are of type [yes|no], then can we use one attribute called @use-i18n. The content of this attribute can be the name of the other 2 attributes, ie: @null-text-is-i18n --> @use-i18n-in="null-text" @label-is-i18n-key --> @use-i18n-in="label" When we need it in both, then: @use-i18n-in="both" or @use-i18n-in="null-text,label" I know we are running out of time. This is again only a suggestion. Please decide you the best in this case. WDYT? Best Regards, Antonio Gallardo.
Re: widget data type
Antonio Gallardo wrote: On Vie, 18 de Marzo de 2005, 14:43, Giacomo Pati dijo: Actually we use different i18n catalogs in the same page (menu catalog, business term catalog, etc.). And special catalog for every list, is this a good idea at all? Can we define it at the sitemap level? That doesn't solve it. As said, we have pages which uses more than one catalog for i18n things (actually I don't know if one can specify several catalogs in the i18n-transformer step of the sitemap). Well, for sure you know better your requirements than me. I just wanted to point out some idea I had while reading the attributes. As I told before, I am +1 for this enhacement. Ok, I'll summarize before I commit the changes: My proposal Revised proposal --- @nullable replaced by 'if( exists( @null-text ) )' @null-text @null-text (can be an empty string) @null-text-is i18n-key @null-text-is-i18n (cannot find anything better) @label-is-i18n-key @label-is-i18n (same as @null-text-is-i18n) @i18n-catalog @i18n-catalogue I'd like to keep the 'i18n' prefix for clarity as I don't feel catalogue itself associates per se with i18n or we decide to not have his attribute at all. WDYT? Giacomo -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com smime.p7s Description: S/MIME Cryptographic Signature
Re: widget data type
On Vie, 18 de Marzo de 2005, 14:43, Giacomo Pati dijo: > > > Antonio Gallardo wrote: >> On Vie, 18 de Marzo de 2005, 10:55, Giacomo Pati dijo: >> >>>Hi all >>> >>>Did you ever had the problem that you'd like to assign a >>>bean from a Collection to another beans property by the use >>>of CForms selection lists? >>> >>>I had that alot and the result was a Datatype called "bean" which can >>>be any type of Java Object. Now this Datatype is only suited to be >>>assigned >>>using selection list. Maybe I haven't found another solution of that >>> case. >>> >>>Any objections to add it? >> >> >> I think it is good. Please read the comments below. > > Ok > >> >> >>>And >>> >>> >>>I would like to extend the flow-jxpath selection list with the following >>>attributes and their meanings: >>> >>>lable-path-is-i18n-key >>> sometimes your label is the i18n key and you want is as such. >>> I haven't found an other easy way to wrap a label text with an >>> element >> >> >> @ lable-path-is-i18n-key --> i18n="yes" + current @label > > See my comment below > >>>nullable >>> same semantic as the "java" selection list has (puts a empty line >>> in the first position of the list) >>> >>>null-text >>> sometimes you'd like to put a text into the empty >>> "null" item of the list >>> >>>null-text-is-i18n-key >>> if your null-text attribute is an i18n key turn this attribut on >> >> >> I think @nullable, @null-text and @null-text-is-i18n-key can be stored >> in >> less attributes: >> >> 1-IMHO one thing is i18n and other thing is null-text: >> >> @i18n - use i18n for the list >> @null-text - define the "null" item. fromhere, we can go to: >> >> original @nullable --> @null-text="" >> original @null-text --> @null-text="[a string]" > > I can agree with the above but... > >> null-text-is-i18n-key --> @i18n="yes + "@null-text="[an i18n key]" > > How do you distinguish to have a @null-text="I18NKEY" wrapped in a > I18nMessage but not on the value at the label-path? Like a bug? :-D See below, > A sample: > > I have a collection of interest rate number and on the "null-text" I > want to say "pick the intrest rate you'd like" in a language dependant > way. With your proposal even the numbers would be warpped into a > I18nMessage as it is an all or nothing rule but they will (fingers > crossed) not find a key in a i18n catalogue. IMHO is we are i18n-ing an application, we need to take care of _every_ string or thing. ie: Today we need: 1,2,3,4,etc. Tomorrow we need: one,two,three, four, etc. (for every lang) and this happens). >>>i18n-catalog >>> for those of us who use several i18n catalogs >> >> >> I wonder how often is need to change the i18n catalog to have the need >> to >> define it right on the list element. > > Actually we use different i18n catalogs in the same page (menu catalog, > business term catalog, etc.). And special catalog for every list, is this a good idea at all? Can we define it at the sitemap level? Well, for sure you know better your requirements than me. I just wanted to point out some idea I had while reading the attributes. As I told before, I am +1 for this enhacement. Best Regards, Antonio Gallardo.
Re: widget data type
Vadim Gritsenko wrote: Spelling... lable-path-is-i18n-key label ... label="true" ... Does this tell you to wrap the label value into a I18nMessage? i18n-catalog catalogue Yes, sorry my fault. I know the i18n:text element uses that term as an attribute name. Giacomo -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com smime.p7s Description: S/MIME Cryptographic Signature
Re: widget data type
Tim Larson wrote: On Fri, Mar 18, 2005 at 03:26:56PM -0500, Vadim Gritsenko wrote: Spelling... lable-path-is-i18n-key label i18n-catalog catalogue > www.dictionary.com lists catalog first, but if people prefer the longer spelling that's ok. I will just have to check the docs each time I try to refer to it ;) The term 'catalogue' is already in use by the element so it should at least be consistent withing the i18n space (it was my failure to write it incorrectly in my first mail as I should have known). -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com smime.p7s Description: S/MIME Cryptographic Signature
Re: widget data type
Antonio Gallardo wrote: On Vie, 18 de Marzo de 2005, 10:55, Giacomo Pati dijo: Hi all Did you ever had the problem that you'd like to assign a bean from a Collection to another beans property by the use of CForms selection lists? I had that alot and the result was a Datatype called "bean" which can be any type of Java Object. Now this Datatype is only suited to be assigned using selection list. Maybe I haven't found another solution of that case. Any objections to add it? I think it is good. Please read the comments below. Ok And I would like to extend the flow-jxpath selection list with the following attributes and their meanings: lable-path-is-i18n-key sometimes your label is the i18n key and you want is as such. I haven't found an other easy way to wrap a label text with an element @ lable-path-is-i18n-key --> i18n="yes" + current @label See my comment below nullable same semantic as the "java" selection list has (puts a empty line in the first position of the list) null-text sometimes you'd like to put a text into the empty "null" item of the list null-text-is-i18n-key if your null-text attribute is an i18n key turn this attribut on I think @nullable, @null-text and @null-text-is-i18n-key can be stored in less attributes: 1-IMHO one thing is i18n and other thing is null-text: @i18n - use i18n for the list @null-text - define the "null" item. fromhere, we can go to: original @nullable --> @null-text="" original @null-text --> @null-text="[a string]" I can agree with the above but... null-text-is-i18n-key --> @i18n="yes + "@null-text="[an i18n key]" How do you distinguish to have a @null-text="I18NKEY" wrapped in a I18nMessage but not on the value at the label-path? A sample: I have a collection of interest rate number and on the "null-text" I want to say "pick the intrest rate you'd like" in a language dependant way. With your proposal even the numbers would be warpped into a I18nMessage as it is an all or nothing rule but they will (fingers crossed) not find a key in a i18n catalogue. i18n-catalog for those of us who use several i18n catalogs I wonder how often is need to change the i18n catalog to have the need to define it right on the list element. Actually we use different i18n catalogs in the same page (menu catalog, business term catalog, etc.). Cheers Giacomo -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com smime.p7s Description: S/MIME Cryptographic Signature
Re: widget data type
On Fri, Mar 18, 2005 at 03:26:56PM -0500, Vadim Gritsenko wrote: > Spelling... > > >>lable-path-is-i18n-key > > label > > >>i18n-catalog > > catalogue www.dictionary.com lists catalog first, but if people prefer the longer spelling that's ok. I will just have to check the docs each time I try to refer to it ;) --Tim Larson
Re: widget data type
Spelling... lable-path-is-i18n-key label i18n-catalog catalogue Vadim
Re: widget data type
Vadim Gritsenko wrote: Giacomo Pati wrote: I would like to extend the flow-jxpath selection list with the following attributes and their meanings: lable-path-is-i18n-key sometimes your label is the i18n key and you want is as such. I haven't found an other easy way to wrap a label text with an element You probably can programmatically create i18n labels using org.apache.cocoon.forms.util.I18nMessage, or it's not easy enough? This is exactly what I don't want. I've done so many rearranging of Collections to form a selection list suitable for the tools CForm had that I am tired of it now. When I already have a Collection of beans from wherever (i.e. beans from an O/R mapper) I don't want to recreate another Collection just to wrap one single property into a I18nMessage. I'd like CForm to do that for me. Cheers Giacomo -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com smime.p7s Description: S/MIME Cryptographic Signature
Re: widget data type
On Vie, 18 de Marzo de 2005, 10:55, Giacomo Pati dijo: > Hi all > > Did you ever had the problem that you'd like to assign a > bean from a Collection to another beans property by the use > of CForms selection lists? > > I had that alot and the result was a Datatype called "bean" which can > be any type of Java Object. Now this Datatype is only suited to be > assigned > using selection list. Maybe I haven't found another solution of that case. > > Any objections to add it? I think it is good. Please read the comments below. > And > > > I would like to extend the flow-jxpath selection list with the following > attributes and their meanings: > > lable-path-is-i18n-key > sometimes your label is the i18n key and you want is as such. > I haven't found an other easy way to wrap a label text with an >element @ lable-path-is-i18n-key --> i18n="yes" + current @label > nullable > same semantic as the "java" selection list has (puts a empty line > in the first position of the list) > > null-text > sometimes you'd like to put a text into the empty > "null" item of the list > > null-text-is-i18n-key > if your null-text attribute is an i18n key turn this attribut on I think @nullable, @null-text and @null-text-is-i18n-key can be stored in less attributes: 1-IMHO one thing is i18n and other thing is null-text: @i18n - use i18n for the list @null-text - define the "null" item. fromhere, we can go to: original @nullable --> @null-text="" original @null-text --> @null-text="[a string]" null-text-is-i18n-key --> @i18n="yes + "@null-text="[an i18n key]" > i18n-catalog > for those of us who use several i18n catalogs I wonder how often is need to change the i18n catalog to have the need to define it right on the list element. WDYT? Best Regards, Antonio Gallardo.
Re: widget data type
Giacomo Pati wrote: I would like to extend the flow-jxpath selection list with the following attributes and their meanings: lable-path-is-i18n-key sometimes your label is the i18n key and you want is as such. I haven't found an other easy way to wrap a label text with an element You probably can programmatically create i18n labels using org.apache.cocoon.forms.util.I18nMessage, or it's not easy enough? Vadim
Re: widget data type
Sylvain Wallez wrote: Giacomo Pati wrote: Hi all Did you ever had the problem that you'd like to assign a bean from a Collection to another beans property by the use of CForms selection lists? I had that alot and the result was a Datatype called "bean" which can be any type of Java Object. Now this Datatype is only suited to be assigned using selection list. Maybe I haven't found another solution of that case. Any objections to add it? No objection, but why the "bean" name and not "object"? Beacuse String is an Object as well but doesn't make much sense in this area. But I have no objections to name it object. And I would like to extend the flow-jxpath selection list with the following attributes and their meanings: lable-path-is-i18n-key sometimes your label is the i18n key and you want is as such. I haven't found an other easy way to wrap a label text with an element nullable same semantic as the "java" selection list has (puts a empty line in the first position of the list) null-text sometimes you'd like to put a text into the empty "null" item of the list null-text-is-i18n-key if your null-text attribute is an i18n key turn this attribut on i18n-catalog for those of us who use several i18n catalogs Wow, lots of new features. Just commit! Ok,here it comes. Giacomo -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com smime.p7s Description: S/MIME Cryptographic Signature
Re: widget data type
Giacomo Pati wrote: Hi all Did you ever had the problem that you'd like to assign a bean from a Collection to another beans property by the use of CForms selection lists? I had that alot and the result was a Datatype called "bean" which can be any type of Java Object. Now this Datatype is only suited to be assigned using selection list. Maybe I haven't found another solution of that case. Any objections to add it? No objection, but why the "bean" name and not "object"? And I would like to extend the flow-jxpath selection list with the following attributes and their meanings: lable-path-is-i18n-key sometimes your label is the i18n key and you want is as such. I haven't found an other easy way to wrap a label text with an element nullable same semantic as the "java" selection list has (puts a empty line in the first position of the list) null-text sometimes you'd like to put a text into the empty "null" item of the list null-text-is-i18n-key if your null-text attribute is an i18n key turn this attribut on i18n-catalog for those of us who use several i18n catalogs Wow, lots of new features. Just commit! Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research & Technology Director
widget data type
Hi all Did you ever had the problem that you'd like to assign a bean from a Collection to another beans property by the use of CForms selection lists? I had that alot and the result was a Datatype called "bean" which can be any type of Java Object. Now this Datatype is only suited to be assigned using selection list. Maybe I haven't found another solution of that case. Any objections to add it? And I would like to extend the flow-jxpath selection list with the following attributes and their meanings: lable-path-is-i18n-key sometimes your label is the i18n key and you want is as such. I haven't found an other easy way to wrap a label text with an element nullable same semantic as the "java" selection list has (puts a empty line in the first position of the list) null-text sometimes you'd like to put a text into the empty "null" item of the list null-text-is-i18n-key if your null-text attribute is an i18n key turn this attribut on i18n-catalog for those of us who use several i18n catalogs WDYT? -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com smime.p7s Description: S/MIME Cryptographic Signature
