Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > it.comp.www.php > #21975 > unrolled thread

Associare caratteristiche identiche a prodotti diversi

Back to article view | Back to it.comp.www.php

Contents

  Associare caratteristiche identiche a prodotti diversi GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2018-04-13 10:41 +0200
    Re: Associare caratteristiche identiche a prodotti diversi Alessandro Pellizzari <shuriken@amiran.it> - 2018-04-13 10:31 +0100
      Re: Associare caratteristiche identiche a prodotti diversi GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2018-04-14 00:01 +0200
    Re: Associare caratteristiche identiche a prodotti diversi Leonardo Serni <lserni@gmail.com> - 2018-04-13 16:50 +0200
      Re: Associare caratteristiche identiche a prodotti diversi GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2018-04-13 23:37 +0200
        Re: Associare caratteristiche identiche a prodotti diversi fmassei@gmail.com - 2018-04-13 15:01 -0700
          Re: Associare caratteristiche identiche a prodotti diversi Leonardo Serni <lserni@gmail.com> - 2018-04-14 01:26 +0200
            Re: Associare caratteristiche identiche a prodotti diversi GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2018-04-14 11:29 +0200
          Re: Associare caratteristiche identiche a prodotti diversi GabrieleMax <gabriele1NOSPAM@hotmail.com> - 2018-04-14 11:25 +0200
            Re: Associare caratteristiche identiche a prodotti diversi fmassei@gmail.com - 2018-04-14 08:31 -0700
        Re: Associare caratteristiche identiche a prodotti diversi Leonardo Serni <lserni@gmail.com> - 2018-04-14 13:06 +0200
          Re: Associare caratteristiche identiche a prodotti diversi fmassei@gmail.com - 2018-04-14 08:37 -0700
            Re: Associare caratteristiche identiche a prodotti diversi Leonardo Serni <lserni@gmail.com> - 2018-04-14 21:37 +0200
              Re: Associare caratteristiche identiche a prodotti diversi fmassei@gmail.com - 2018-04-15 09:04 -0700
                Re: Associare caratteristiche identiche a prodotti diversi Leonardo Serni <lserni@gmail.com> - 2018-04-15 19:42 +0200
                  Re: Associare caratteristiche identiche a prodotti diversi fmassei@gmail.com - 2018-04-15 10:52 -0700
                    Re: Associare caratteristiche identiche a prodotti diversi Leonardo Serni <lserni@gmail.com> - 2018-04-15 22:39 +0200
                      Re: Associare caratteristiche identiche a prodotti diversi fmassei@gmail.com - 2018-04-16 06:29 -0700
                        Re: Associare caratteristiche identiche a prodotti diversi Leonardo Serni <lserni@gmail.com> - 2018-04-16 17:41 +0200
                          Re: Associare caratteristiche identiche a prodotti diversi fmassei@gmail.com - 2018-04-16 09:35 -0700
                            Re: Associare caratteristiche identiche a prodotti diversi Leonardo Serni <lserni@gmail.com> - 2018-04-16 23:28 +0200
                              Re: Associare caratteristiche identiche a prodotti diversi fmassei@gmail.com - 2018-04-16 15:51 -0700
                                Re: Associare caratteristiche identiche a prodotti diversi Leonardo Serni <lserni@gmail.com> - 2018-04-17 07:40 +0200

Page 1 of 2  [1] 2  Next page →

#21975 — Associare caratteristiche identiche a prodotti diversi

Salve,

visto che sto postando da qualche giorno tengo a precisare che quello 
che chiedo non è per lavoro ma per chiarirmi le idee a livello tecnico 
per poi affidarmi a dei professionisti che implementeranno il tutto 
evitando di farli smattire con richieste "assurde" o cambiamenti in 
corso d'opera onerosi sotto tutti i punti di vista (...).

Nel creare una tabella in mysql ci sarebbe l'esigenza di associare 
caratteristiche simili (pensiamo agli ingredienti dei prodotti che si 
comprano al supermercato) a prodotti diversi.

Ad esempio in una tabella potrei inserire i valori "zucchero", "sale", 
"farina", etc. e nel momento in cui inserisco un prodotto dovrei 
associargli/inserire più valori (ovvero più ingredienti) obbligando però 
l'utente a scegliere tra quelli disponibili.

Inserire gli ingredienti in un'apposita tabella mi permetterebbe anche 
di tradurli in lingue diverse però credo che non si potrà lavorare a 
livello di db ad esempio con delle FK per avere vincoli di integrità ma 
bisognerà agire direttamente con uno script php che legga e proponga i 
valori della tabella ingredienti.

Saluti.
GabrieleMax

[toc] | [next] | [standalone]

#21976

On 13/04/2018 09:41, GabrieleMax wrote:

> Nel creare una tabella in mysql ci sarebbe l'esigenza di associare 
> caratteristiche simili (pensiamo agli ingredienti dei prodotti che si 
> comprano al supermercato) a prodotti diversi.

> Ad esempio in una tabella potrei inserire i valori "zucchero", "sale", 
> "farina", etc. e nel momento in cui inserisco un prodotto dovrei 
> associargli/inserire più valori (ovvero più ingredienti) obbligando però 
> l'utente a scegliere tra quelli disponibili.

Sempre lo stesso trucco della tabella intermedia per le relazioni n:n
Con l'aggiunta che, nella stessa tabella, puoi mettere informazioni 
aggiuntive.

Per esempio:

create table prodotto_ingrediente (id_prod int, id_ingr int, qta text);

insert into prodotto_ingrediente values(123, 456, "100g")

> Inserire gli ingredienti in un'apposita tabella mi permetterebbe anche 
> di tradurli in lingue diverse però credo che non si potrà lavorare a 
> livello di db ad esempio con delle FK per avere vincoli di integrità ma 
> bisognerà agire direttamente con uno script php che legga e proponga i 
> valori della tabella ingredienti.

Definisci una tabella di ingredienti come "master language" (di solito 
inglese) e la fai come ho detto sopra.

Poi definisci le tabelle di traduzione.

create table ingredients(id primary key, name text, description text);

create table ingredients_it_IT(id int references ingredients(id), name 
text, description text)

Nota che l'id in quella di traduzione non è primary key, nè 
auto_increment: viene assegnata allo stesso valore della tabella 
ingredienti originale.

In questo modo puoi avere il fallback della lingua automaticamente:

select i.id, i.name, i.description, t.name as name_it, t.description as 
description_it from ingredients i left join ingredients_it_IT t on 
(i.id=t.id)

Da PHP, se name_it è null, prendi name, e lo stesso con description.

Puoi anche fare (left) join multilpe per avere tutte le traduzioni allo 
stesso tempo, ma questo te lo lascio come esercizio per casa. :P

Bye.

[toc] | [prev] | [next] | [standalone]

#21979

> Sempre lo stesso trucco della tabella intermedia per le relazioni n:n

Azz... avevo già la soluzione, bastava "ragionarci" un po' di più! :D

> Con l'aggiunta che, nella stessa tabella, puoi mettere informazioni 
> aggiuntive.
> 
> Per esempio:
> 
> create table prodotto_ingrediente (id_prod int, id_ingr int, qta text);
> 
> insert into prodotto_ingrediente values(123, 456, "100g")

Ma se inserisco una lista di ingredienti il campo quantità sarà per 
forza relativo ad ogni ingrediente mentre se un prodotto avesse un peso 
unico non potrebbe stare qui giusto?

> Definisci una tabella di ingredienti come "master language" (di solito 
> inglese) e la fai come ho detto sopra.
> 
> Poi definisci le tabelle di traduzione.
> 
> create table ingredients(id primary key, name text, description text);
> 
> create table ingredients_it_IT(id int references ingredients(id), name 
> text, description text)
> 
> Nota che l'id in quella di traduzione non è primary key, nè 
> auto_increment: viene assegnata allo stesso valore della tabella 
> ingredienti originale.

Anche in questo caso gira e rigira ci sarei potuto arrivare pensandoci 
qualche sec... una mezz'oretta in più! :D

> In questo modo puoi avere il fallback della lingua automaticamente:
> 
> select i.id, i.name, i.description, t.name as name_it, t.description as 
> description_it from ingredients i left join ingredients_it_IT t on 
> (i.id=t.id)
> 
> Da PHP, se name_it è null, prendi name, e lo stesso con description.
> 
> Puoi anche fare (left) join multilpe per avere tutte le traduzioni allo 
> stesso tempo, ma questo te lo lascio come esercizio per casa. :P

Vista l'ora ed il pomeriggio passato a decespugliare rimando gli 
esercizi al weekend imminente anche se... ora che ci penso dovrei 
sistemare il prato appena piantato! :D

> Bye.

Saluti!
GabrieleMax

[toc] | [prev] | [next] | [standalone]

#21977

On Fri, 13 Apr 2018 10:41:09 +0200, GabrieleMax <gabriele1NOSPAM@hotmail.com>
wrote:

>Nel creare una tabella in mysql ci sarebbe l'esigenza di associare 
>caratteristiche simili (pensiamo agli ingredienti dei prodotti che si 
>comprano al supermercato) a prodotti diversi.

>Ad esempio in una tabella potrei inserire i valori "zucchero", "sale", 
>"farina", etc. e nel momento in cui inserisco un prodotto dovrei 
>associargli/inserire più valori (ovvero più ingredienti) obbligando però 
>l'utente a scegliere tra quelli disponibili.

ingredienti
	id_ingrediente		133
	default_name		ATCHUGHE

nomi_ingredienti
	id_nome			1701
	id_ingrediente		133
	id_lingua		EN
	nome_locale		Anchovies

ingredienti_in_prodotto
	id_ingrediente		133
	id_prodotto		72	--> "pizza napule" (tab. prodotti)
	id_um			15   	--> "gr." (tabella unita_misura)
	quantita		20
	
>di tradurli in lingue diverse però credo che non si potrà lavorare a 
>livello di db

Puoi crearti una VIEW ingredienti_locali che, data una lingua, ti mostri un
campo contenente o il nome localizzato o, se non c'è, il nome default dalla
tabella ingredienti.

(O puoi usare un file .po adatto al posto di nomi_ingredienti)

Leonardo
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]

#21978

Ti ringrazio intanto per la risposta e tra qualche secondo replico anche 
ad Alessandro! :D

Ipotizziamo:

> ingredienti
> 	id_ingrediente		133
> 	default_name		ATCHUGHE

ingredienti
	id_ingrediente		133
	default_name		ATCHUGHE
         id_ingrediente		134
	default_name		MOZRELLA

> nomi_ingredienti
> 	id_nome			1701
> 	id_ingrediente		133
> 	id_lingua		EN
> 	nome_locale		Anchovies

nomi_ingredienti
	id_nome			1701
	id_ingrediente		133
	id_lingua		EN
	nome_locale		Anchovies
         id_nome			1702
	id_ingrediente		134
	id_lingua		EN
	nome_locale		Boh

> ingredienti_in_prodotto
> 	id_ingrediente		133
> 	id_prodotto		72	--> "pizza napule" (tab. prodotti)
> 	id_um			15   	--> "gr." (tabella unita_misura)
> 	quantita		20

ingredienti_in_prodotto
	id_ingrediente	133
	id_prodotto	72	--> "pizza napule" (tab. prodotti)
	id_ingrediente	134
	id_prodotto	72	--> "pizza napule" (tab. prodotti)

Da quel che ho capito in quest'ultima tabella inserirò tutti gli 
ingredienti giusto? Nel mio caso il peso sarebbe il peso generale del 
prodotto non avendo la necessità di indicare il peso per ogni 
ingrediente andrò a togliere questo campo oppure se necessario potrei 
pure lasciarlo...

Per quanto riguarda il campo id_lingua si collegherà ovviamente alla 
tabella lingua dove inserirò i vari IT, EN, etc. giusto?

> Puoi crearti una VIEW ingredienti_locali che, data una lingua, ti mostri un
> campo contenente o il nome localizzato o, se non c'è, il nome default dalla
> tabella ingredienti.
> 
> (O puoi usare un file .po adatto al posto di nomi_ingredienti)

Non sono cosi' addentro, come già detto voglio solo farmi un'idea di 
quel che vorrei far realizzare da "terzi" cercando di essere 
tecnicamente il più chiaro possibile!

> Leonardo

Saluti!
GabrieleMax

[toc] | [prev] | [next] | [standalone]

#21980

On Friday, April 13, 2018 at 5:37:27 PM UTC-4, GabrieleMax wrote:
> Non sono cosi' addentro, come già detto voglio solo farmi un'idea di 
> quel che vorrei far realizzare da "terzi" cercando di essere 
> tecnicamente il più chiaro possibile!
> 

Se non li scegli tra gente che passa per caso non hai bisogno di entrare
in questi dettagli. Un sacco di scelte tecniche dipendono troppo dal
progetto. Un esempio sono proprio le traduzioni, che si possono fare in
cinque/sei modi diversi, tutti sensati se rapportati al giusto caso.

Prova piuttosto a scrivere, in maniera che consideri perfetta, quello che
vuoi ottenere alla fine. Come tecnico, troppe volte capita di trovare
qualcuno che ti dice come fare questo o quello, ma non sa cosa vuole
di *preciso*.


Ciao!

[toc] | [prev] | [next] | [standalone]

#21981

On Fri, 13 Apr 2018 15:01:39 -0700 (PDT), fmassei@gmail.com wrote:

>Se non li scegli tra gente che passa per caso non hai bisogno di entrare
>in questi dettagli. Un sacco di scelte tecniche dipendono troppo dal
>progetto. Un esempio sono proprio le traduzioni, che si possono fare in
>cinque/sei modi diversi, tutti sensati se rapportati al giusto caso.

>Prova piuttosto a scrivere, in maniera che consideri perfetta, quello che
>vuoi ottenere alla fine. Come tecnico, troppe volte capita di trovare
>qualcuno che ti dice come fare questo o quello, ma non sa cosa vuole
>di *preciso*.

+137

Leonardo
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]

#21983

> +137

Ti volevo semplicemente chiedere se l'esempio da me fatto in risposta al 
tuo post sia corretto o meno.

> Leonardo

Saluti.
GabrieleMax

[toc] | [prev] | [next] | [standalone]

#21982

> Se non li scegli tra gente che passa per caso non hai bisogno di entrare
> in questi dettagli. Un sacco di scelte tecniche dipendono troppo dal
> progetto. Un esempio sono proprio le traduzioni, che si possono fare in
> cinque/sei modi diversi, tutti sensati se rapportati al giusto caso.

Hai ragione ma sai meglio di me che nel mondo web sono entrati tutti dal 
programmatore serio in grado di farti il progetto su misura a quello che 
salta di CMS in CMS prendendo pezzi e bocconi qua e là facendoti credere 
che quanto da lui realizzato sia il top!

Se ti andrà di farmi degli esempi sul modo di gestire le traduzioni io 
ti leggerò ben volentieri!

> Prova piuttosto a scrivere, in maniera che consideri perfetta, quello che
> vuoi ottenere alla fine. Come tecnico, troppe volte capita di trovare
> qualcuno che ti dice come fare questo o quello, ma non sa cosa vuole
> di *preciso*.

Sono in grado di fare le pagine con Dreamweaver, lo utilizzo da quando 
Macromedia lo lanciò secoli addietro e prima ancora a metà anni '90 le 
facevo a mano con un editor di testo anche perchè all'epoca il web era 
talmente agli albori che facevo il preload delle immagini in bianco e 
nero per evitare che l'utente aspettasse troppo...

Io son dell'idea che presentare ad un programmatore delle pagine già 
fatte con le varie form sapendo cosa inserire in ognuna di esse, un db 
non dico già finito sennò non avrebbe nulla da fare ma qualcosa che gli 
permetta di capire quali dati vadano in ogni campo imho credo sia un bel 
aiuto per rendere il progetto aderente alle richieste.

> Ciao!

Saluti!
GabrieleMax

[toc] | [prev] | [next] | [standalone]

#21985

On Saturday, April 14, 2018 at 5:25:40 AM UTC-4, GabrieleMax wrote:
> Io son dell'idea che presentare ad un programmatore delle pagine già 
> fatte con le varie form sapendo cosa inserire in ognuna di esse, un db 
> non dico già finito sennò non avrebbe nulla da fare ma qualcosa che gli 
> permetta di capire quali dati vadano in ogni campo imho credo sia un bel 
> aiuto per rendere il progetto aderente alle richieste.
> 

I dati in persistenza dipendono anche dal data-flow, se te o il tuo
programmatore decidete in un secondo momento di usare Ajax per facilitare
gli utenti, puoi buttare sia le pagine che probabilmente parte del tuo db.

Per dire.

Capisco che vuoi dare una mano anche a livello tecnico, ma secondo me stai
facendo una fatica inutile.

Ciao!

[toc] | [prev] | [next] | [standalone]

#21984

On Fri, 13 Apr 2018 23:37:26 +0200, GabrieleMax <gabriele1NOSPAM@hotmail.com>
wrote:

>> ingredienti
>> 	id_ingrediente		133
>> 	default_name		ATCHUGHE
        id_ingrediente		134
>	default_name		MOZRELLA

Okay.

>	id_ingrediente		134
>	id_lingua		EN
>	nome_locale		Boh

E' sempre "mozzarella" anche in inglese ;-D ("mozzarella cheese" se uno vuole
proprio fare fìi).

>ingredienti_in_prodotto
>	id_ingrediente	133
>	id_prodotto	72	--> "pizza napule" (tab. prodotti)
>	id_ingrediente	134
>	id_prodotto	72	--> "pizza napule" (tab. prodotti)

>Da quel che ho capito in quest'ultima tabella inserirò tutti gli 
>ingredienti giusto? Nel mio caso il peso sarebbe il peso generale del 
>prodotto non avendo la necessità di indicare il peso per ogni 
>ingrediente andrò a togliere questo campo oppure se necessario potrei 
>pure lasciarlo...

Sì, naturalmente nel primo caso il campo peso va nella tabella prodotti.

>Per quanto riguarda il campo id_lingua si collegherà ovviamente alla 
>tabella lingua dove inserirò i vari IT, EN, etc. giusto?

Sì. Ma come giustamente ricorda fmassei, questo tipo di decisioni è bene se le
lasci al programmatore.

Tu preoccupati magari di cose tipo "La mappatura delle lingue deve potersi sia
scaricare facilmente per mandarla al servizio di traduzione, sia uploadare per
l'aggiornamento". Questo può influenzare poi la scelta del sistema da usarsi.

Al programmatore vanno dette cose come:

	"ogni ingrediente deve poter avere un nome in N lingue, con
	 N che potrebbe aumentare, in un secondo tempo; ma potrebbe
	 anche non averlo, e allora deve usare un nome di default".

Leonardo
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]

#21986

On Saturday, April 14, 2018 at 7:06:21 AM UTC-4, Leonardo Serni wrote:
> Tu preoccupati magari di cose tipo "La mappatura delle lingue deve
> potersi sia scaricare facilmente per mandarla al servizio di traduzione,
> sia uploadare per l'aggiornamento". Questo può influenzare poi la scelta
> del sistema da usarsi.
> 

Scritto così io ad esempio sarei andato su gettext invece che sul db,
come penso tutti.


> Al programmatore vanno dette cose come:
> 
> 	"ogni ingrediente deve poter avere un nome in N lingue, con
> 	 N che potrebbe aumentare, in un secondo tempo; ma potrebbe
> 	 anche non averlo, e allora deve usare un nome di default".
> 

Questo livello di chiarezza purtroppo non ci se lo può aspettare da uno
che non scrive specifiche di mestiere, ma sicuramente è possibile andarci
vicino anche per chi non l'ha mai fatto, con un po' di buona voglia.


Ciao!

[toc] | [prev] | [next] | [standalone]

#21987

On Sat, 14 Apr 2018 08:37:59 -0700 (PDT), fmassei@gmail.com wrote:

>On Saturday, April 14, 2018 at 7:06:21 AM UTC-4, Leonardo Serni wrote:
>> Tu preoccupati magari di cose tipo "La mappatura delle lingue deve
>> potersi sia scaricare facilmente per mandarla al servizio di traduzione,
>> sia uploadare per l'aggiornamento". Questo può influenzare poi la scelta
>> del sistema da usarsi.

>Scritto così io ad esempio sarei andato su gettext invece che sul db,
>come penso tutti.

Dipende anche da come sono manutenute le traduzioni. Se sono aggiornate una
volta ogni tanto è più efficiente gettext - infatti scrivevo,

    (O puoi usare un file .po adatto al posto di nomi_ingredienti)

- poi uno uploada il file .mo appropriato. Per dare possibilità a un utente
esterno di modificare on line le traduzioni, si potrebbe fare lo stesso (ho
trovato https://github.com/phpmo/php.mo ), ma il database è più facile. Poi
ti consente più flessibilità, se ti serve (per es., lo stesso messaggio, in
due file diversi, tradotto in modi diversi; che si fa pure con gettext, ma,
a scoprire solo dopo quanto ti serviva, è una faccenda pelosa).

Comunque, è vero che si può passare da gettext a database, e viceversa, con
uno sforzo abbastanza ridotto.

Leonardo
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]

#21988

On Saturday, April 14, 2018 at 3:37:58 PM UTC-4, Leonardo Serni wrote:
> Comunque, è vero che si può passare da gettext a database, e viceversa, con
> uno sforzo abbastanza ridotto.
> 

"Ridotto" è da definire... Sul mio progetto attuale, se dovessi cambiare,
sarebbe un bagno di sangue :)

Ciao!

[toc] | [prev] | [next] | [standalone]

#21989

On Sun, 15 Apr 2018 09:04:22 -0700 (PDT), fmassei@gmail.com wrote:

>On Saturday, April 14, 2018 at 3:37:58 PM UTC-4, Leonardo Serni wrote:
>> Comunque, è vero che si può passare da gettext a database, e viceversa, con
>> uno sforzo abbastanza ridotto.

>"Ridotto" è da definire... Sul mio progetto attuale, se dovessi cambiare,
>sarebbe un bagno di sangue :)

Sostituisci _() con _t(), dopo di che... :-)

Leonardo
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]

#21990

On Sunday, April 15, 2018 at 1:43:02 PM UTC-4, Leonardo Serni wrote:
> On Sun, 15 Apr 2018 09:04:22 -0700 (PDT), fmassei@gmail.com wrote:
> 
> >On Saturday, April 14, 2018 at 3:37:58 PM UTC-4, Leonardo Serni wrote:
> >> Comunque, è vero che si può passare da gettext a database, e viceversa, con
> >> uno sforzo abbastanza ridotto.
> 
> >"Ridotto" è da definire... Sul mio progetto attuale, se dovessi cambiare,
> >sarebbe un bagno di sangue :)
> 
> Sostituisci _() con _t(), dopo di che... :-)
> 

Dopo di che devo rivedere tutte le query? :D
Certo, a meno che non vuoi farne mille a pagina, o avere ogni pagina che
carica il tabellone senza motivo...

Ciao!

[toc] | [prev] | [next] | [standalone]

#21991

On Sun, 15 Apr 2018 10:52:12 -0700 (PDT), fmassei@gmail.com wrote:

>> >On Saturday, April 14, 2018 at 3:37:58 PM UTC-4, Leonardo Serni wrote:
>> >> Comunque, è vero che si può passare da gettext a database, e viceversa, con
>> >> uno sforzo abbastanza ridotto.

>> >"Ridotto" è da definire... Sul mio progetto attuale, se dovessi cambiare,
>> >sarebbe un bagno di sangue :)

>> Sostituisci _() con _t(), dopo di che... :-)

>Dopo di che devo rivedere tutte le query? :D

Nooo. Ma immagino che se usi gettext tu abbia qualcosa del tipo _('STRING')
più o meno ovunque. A quel punto è relativamente semplice passare a __(), e
quella funzione poi chiamerà il database. A seconda dei casi e di come sono
fatte le stringhe, e quante ce ne sono, può convenire caricare in memoria -
che so - le diecimila stringhe della lingua in uso (diciamo che siano sugli
80 caratteri l'una, vengono circa 800 Kb - in PHP, in realtà, più verso gli
1.2 - 1.5 MB; comunque tutto sommato accettabile) come hash. Oppure fare in
effetti una query per ogni __(). O trasformare _() in __(__FILE__,...), per
effettuare una query meno onerosa (o usare qualcos'altro invece di __FILE__
- la view attiva, per dire).

Il viceversa è più semplice, ma AFAIR pure il file .MO viene caricato tutto
in memoria [benché in modo meno memory-intensive] alla prima chiamata.

Leonardo
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]

#21992

On Sunday, April 15, 2018 at 4:39:52 PM UTC-4, Leonardo Serni wrote:
> On Sun, 15 Apr 2018 10:52:12 -0700 (PDT), fmassei@gmail.com wrote:
> >Dopo di che devo rivedere tutte le query? :D
> 
> Nooo. Ma immagino che se usi gettext tu abbia qualcosa del tipo _('STRING')
> più o meno ovunque. A quel punto è relativamente semplice passare a __(), e
> quella funzione poi chiamerà il database. A seconda dei casi e di come sono
> fatte le stringhe, e quante ce ne sono, può convenire caricare in memoria -
> che so - le diecimila stringhe della lingua in uso (diciamo che siano sugli
> 80 caratteri l'una, vengono circa 800 Kb - in PHP, in realtà, più verso gli
> 1.2 - 1.5 MB; comunque tutto sommato accettabile) come hash. Oppure fare in
> effetti una query per ogni __(). O trasformare _() in __(__FILE__,...), per
> effettuare una query meno onerosa (o usare qualcos'altro invece di __FILE__
> - la view attiva, per dire).
> 

Eh, infatti. O fai mille query o carichi sempre il tabellone.
L'ultima alternativa mi sembra mostruosamente complessa da gestire, con
stringhe a caso piazzate qua e la.

Ciao!

[toc] | [prev] | [next] | [standalone]

#21993

On Mon, 16 Apr 2018 06:29:57 -0700 (PDT), fmassei@gmail.com wrote:

>On Sunday, April 15, 2018 at 4:39:52 PM UTC-4, Leonardo Serni wrote:
>> On Sun, 15 Apr 2018 10:52:12 -0700 (PDT), fmassei@gmail.com wrote:
>> >Dopo di che devo rivedere tutte le query? :D
>> 
>> Nooo. Ma immagino che se usi gettext tu abbia qualcosa del tipo _('STRING')
>> più o meno ovunque. A quel punto è relativamente semplice passare a __(), e
>> quella funzione poi chiamerà il database. A seconda dei casi e di come sono
>> fatte le stringhe, e quante ce ne sono, può convenire caricare in memoria -
>> che so - le diecimila stringhe della lingua in uso (diciamo che siano sugli
>> 80 caratteri l'una, vengono circa 800 Kb - in PHP, in realtà, più verso gli
>> 1.2 - 1.5 MB; comunque tutto sommato accettabile) come hash. Oppure fare in
>> effetti una query per ogni __(). O trasformare _() in __(__FILE__,...), per
>> effettuare una query meno onerosa (o usare qualcos'altro invece di __FILE__
>> - la view attiva, per dire).

>Eh, infatti. O fai mille query o carichi sempre il tabellone.

Sì, ma come dicevo, caricare il tabellone non è poi così male: è quello che
fa gettext, alla fin fine (e con una cache abbastanza ignorante, anche). Va
detto che se il sito ha molti accessi concorrenti, con il setup giusto quel
malloppone di gettext va in shared memory.

Ma le due soluzioni non sono così differenti in termini di prestazioni, con
l'ipotesi di lavorare bene in tutti e due i casi, né il costo del "lavorare
bene" è così diverso.

Il che non stupisce, perché gettext non è che faccia cose così diverse.

(Poi tutto dipende, sempre. Metti che un DB non c'è? gettext forever...).

>L'ultima alternativa mi sembra mostruosamente complessa da gestire, con
>stringhe a caso piazzate qua e la.

Noo, è più la paura che il danno :-)

Ammesso di avere una funzione __(prefix, string, [num=1]) che oltre che una
stringa messaggio accetta un prefisso, puoi cercare nella tabella hash

	prefix/string
	default/string
	string

e ritornare il primo che trovi. Tutta la "complicazione" è in __(), cioè in
un posto solo (per elenchi piccoli, chiaro che $prefix non ti serve).

Leonardo
-- 

"You all presumably know why" :-) :-(

[toc] | [prev] | [next] | [standalone]

#21994

On Monday, April 16, 2018 at 11:41:30 AM UTC-4, Leonardo Serni wrote:
> On Mon, 16 Apr 2018 06:29:57 -0700 (PDT), fmassei@gmail.com wrote:
> >Eh, infatti. O fai mille query o carichi sempre il tabellone.
> 
> Sì, ma come dicevo, caricare il tabellone non è poi così male: è quello che
> fa gettext, alla fin fine (e con una cache abbastanza ignorante, anche). Va
> detto che se il sito ha molti accessi concorrenti, con il setup giusto quel
> malloppone di gettext va in shared memory.
> 
> Ma le due soluzioni non sono così differenti in termini di prestazioni, con
> l'ipotesi di lavorare bene in tutti e due i casi, né il costo del "lavorare
> bene" è così diverso.
> 
> Il che non stupisce, perché gettext non è che faccia cose così diverse.
> 
> (Poi tutto dipende, sempre. Metti che un DB non c'è? gettext forever...).
> 

Non andrebbe in "shared memory", semmai in disk cache.
Comunque il DB in questo caso non può che essere più lento, per forza di
cose. Non so di quanto, sinceramente, ma penso di un bel po'.

> >L'ultima alternativa mi sembra mostruosamente complessa da gestire, con
> >stringhe a caso piazzate qua e la.
> 
> Noo, è più la paura che il danno :-)
> 
> Ammesso di avere una funzione __(prefix, string, [num=1]) che oltre che una
> stringa messaggio accetta un prefisso, puoi cercare nella tabella hash
> 
> 	prefix/string
> 	default/string
> 	string
> 
> e ritornare il primo che trovi. Tutta la "complicazione" è in __(), cioè in
> un posto solo (per elenchi piccoli, chiaro che $prefix non ti serve).
> 

Non capisco. La stringa "log in" dove la metti? E "Questa è la pagina dei
contatti"?. E come fa un utente, o il servizio di traduzione, ad aggiornare
i testi? Continua a sembrarmi un casino tremendo.

Ciao!

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | it.comp.www.php

csiph-web