/ Forside / Teknologi / Udvikling / ASP / Nyhedsindlæg
Login
Glemt dit kodeord?
Brugernavn

Kodeord


Reklame
Top 10 brugere
ASP
#NavnPoint
smorch 9259
Harlekin 1866
molokyle 1040
Steffanst.. 758
gandalf 657
smilly 564
gibson 560
cumano 530
MouseKeep.. 480
10  Random 410
Divide and Conquer?
Fra : Steffen Tiedemann Ch~


Dato : 26-01-01 23:02

Jeg har - til en kunde - lavet en efterhånden omfattende side, som udregner
priser på en række produkter. Problemet er nu, at denne kunde ønsker at
bruge den samme funktionalitet (de samme udregningsmetoder) på en anden
hjemmeside. Eftersom der med tiden skal tilføjes flere udregningsmetoder kan
denne dobbelttænkning ikke give andet end hovedbryd.

Min ide er nu at skille hver udregningsmetode op i en slags modul, hvor de
data, der bruges til at udregne et tilbud på en vare, placeres i en flat
file (XML?), eftersom disse data ikke vil ændres ret ofte, og fordi det gør
det væsentligt lettere at lave automatisk oversættelse i forskellige sprog.
Her kommer så det første problem: Kan man i XML have en række forskellige
objekter og vælge ét af disse elementer ud fra en unik ID? Eller skal jeg
enumrere gennem eksempelvis 50 objekter? Hvor meget vil en løsning nedsætte
siden performance?

Er der nogen, der har erfaring med at bruge den slags relationer, man bruger
mellem forskellige tabeller i SQL (tabel1.ID = tabel2.tabel1_ID)?

Det andet problem er mere jordnært: Jeg har en Access 2000-database, som
gerne skulle laves om til XML-filer. Men hvordan gør man det lettest?


Tak for hjælpen,
Steffen Tiedemann Christensen



 
 
Lauritz Jensen (26-01-2001)
Kommentar
Fra : Lauritz Jensen


Dato : 26-01-01 23:23

Steffen Tiedemann Christensen wrote:
>
> [<Produkt database>
> + <"gennerelle" udregninger>
> => <flere forskellige websites>]
> [Er xml løsningen?]

Xml kan godt være et godt valg og så vil jeg forslå at du bruger xsl til
beregningerne? Microsofts xml parser er jo kommet i den enelige version
http://msdn.microsoft.com/xml/default.asp .
Du kunne evt. have et xml-ark med produkterne, lave dem til et nyt
xml-format, indeholdende de beregnede værdier (og evt. cache dette), og
så tilsidst lave dette format til forskellige html-formater.
Skal de forskellige websites være dynamiske?

> Det andet problem er mere jordnært: Jeg har en Access 2000-database,
> som gerne skulle laves om til XML-filer. Men hvordan gør man det
> lettest?

Hvorfor ikke bare genererer hele møget på baggrund af access-basen?

--
Lauritz

Steffen Tiedemann Ch~ (27-01-2001)
Kommentar
Fra : Steffen Tiedemann Ch~


Dato : 27-01-01 14:57

> Xml kan godt være et godt valg og så vil jeg forslå at du bruger xsl til
> beregningerne?
Her må I lige specficere pointen: Hvordan kan XSL lave udregningerne? Links
til gode eksempler?

> Microsofts xml parser er jo kommet i den enelige version
> http://msdn.microsoft.com/xml/default.asp .
Hvad er oddsene for at mine hosts har installeret dette (Azero og
WorldOnline)?

> Du kunne evt. have et xml-ark med produkterne, lave dem til et nyt
> xml-format, indeholdende de beregnede værdier (og evt. cache dette)
Igen kan jeg nok have brug for lidt mere forklaring.

> > Det andet problem er mere jordnært: Jeg har en Access 2000-database,
> > som gerne skulle laves om til XML-filer. Men hvordan gør man det
> > lettest?
> Hvorfor ikke bare genererer hele møget på baggrund af access-basen?
Det var sådan set også meningen, men med en let måde mener jeg en måde, hvor
jeg ikke selv behøver at skrive kode. Det lader ikke til at Access kan
eksportere til XML med det samme?

Takker,
Steffen






Lauritz Jensen (27-01-2001)
Kommentar
Fra : Lauritz Jensen


Dato : 27-01-01 15:48

Steffen Tiedemann Christensen wrote:
>
> > Xml kan godt være et godt valg og så vil jeg forslå at du bruger
> > xsl til beregningerne?
> Her må I lige specficere pointen: Hvordan kan XSL lave
> udregningerne? Links til gode eksempler?

XSL har et script element, hvori du har difinerer funktioner, som du så
kan bruge andre steder i dit stylesheet (det er en MS tilføjelse).
script-elementet:
http://msdn.microsoft.com/library/psdk/xmlsdk/xslr4s50.htm
Beskrivelse af processen:
http://msdn.microsoft.com/xml/articles/enhancingxsl.asp

Men der ud over kan du naturligvis via value-of elementet lave simple
beregninger.

> > Microsofts xml parser er jo kommet i den enelige version
> > http://msdn.microsoft.com/xml/default.asp .
> Hvad er oddsene for at mine hosts har installeret dette (Azero
> og WorldOnline)?

Den lidt ældre version af xml-komponenten (som ikke indeholder det
nyeste, som schemas men som vist godt kan klare xsl), følger med ie5, så
hvis din udbyder bruger iis5 er chancerne gode.

> > Du kunne evt. have et xml-ark med produkterne, lave dem til et nyt
> > xml-format, indeholdende de beregnede værdier (og evt. cache dette)
> Igen kan jeg nok have brug for lidt mere forklaring.

Nu ved jeg ikke om de "fælles beregninger", som du skal have udført er
nogle som afhænger af indput fra brugeren eller om det er nogle som
laves "en gang for alle". Men xsl er "jo" beregnet til at tage noget xml
som indput og spytte noget xml ud igen. Derfor kunne du tage din produkt
database og køre det igennem et xsl, som tilføjede de beregnede værdier.
Det xsl ark ville så være fælles for alle sites'ne. Det resulterede xml
dokument kunne du cache (hvis det er beregninger, som udføres "en gang
for alle"). Derefter kunne du køre det igennem et xsl, som var afhængig
af det site det skulle bruges på og som retunerede html.

> > > Det andet problem er mere jordnært: Jeg har en Access 2000-database,
> > > som gerne skulle laves om til XML-filer. Men hvordan gør man det
> > > lettest?
> > Hvorfor ikke bare genererer hele møget på baggrund af access-basen?
> Det var sådan set også meningen, men med en let måde mener jeg en måde, hvor
> jeg ikke selv behøver at skrive kode. Det lader ikke til at Access kan
> eksportere til XML med det samme?

Jamen, kan du ikke køre hele møget fra start (access-database) til slut
(html) i access?
Mht. xml eksport fra access, mener jeg at have set adskillige eksempler
på omdannelse af et recordset til et xml-dokument på msdn (men er der
ikke også en indbygget funktion i recordsettet?).

--
Lauritz

Steffen Tiedemann Ch~ (28-01-2001)
Kommentar
Fra : Steffen Tiedemann Ch~


Dato : 28-01-01 09:32

> Jamen, kan du ikke køre hele møget fra start (access-database) til slut
> (html) i access?
> Mht. xml eksport fra access, mener jeg at have set adskillige eksempler
> på omdannelse af et recordset til et xml-dokument på msdn (men er der
> ikke også en indbygget funktion i recordsettet?).
Den skjulte pointe ville være at det script, som lige nu opdaterer alle
..html-, .asp-, .sql-, .php- .... filer vil kunne oversætte alle strenge i
"databasen" samtidigt. Det vil spare ret så meget tid i længden.
Alternativet er at køre med 5 forskellige databaser, der indeholder det
samme...

Fra og med ADO 2.5 kan man eksportere en Access table til en XML-fil, men
netop fordi det er autogenereret synes implementationen klodset. Det er
svært at læse og samtidigt kan man ikke benytte Æ, Ø og Å.


Som en konklussion: Min ide var en lille omprogrammering fra den nuværende,
hvor alt ligger i én .mdb-fil med en masse asp-filer, der bruger SQL
queries. Målet ville være moduler med de forskellige udregninger, hvor data
til hver udregning lå i én .xml-fil. Men skal alle udregninger også
omprogrammeres kan det blive meget mere omfattende end det er
hensigtsmæssigt. I sig selv er XML ikke målet, men en slags teknologi, hvor
alle database tables ligger i flat files, som kan forespørges vha. SQL.

Steffen






Lauritz Jensen (28-01-2001)
Kommentar
Fra : Lauritz Jensen


Dato : 28-01-01 23:51

Steffen Tiedemann Christensen wrote:
>
> > Jamen, kan du ikke køre hele møget fra start (access-database)
> > til slut (html) i access?
> > Mht. xml eksport fra access, mener jeg at have set adskillige
> > eksempler på omdannelse af et recordset til et xml-dokument på
> > msdn (men er der ikke også en indbygget funktion i
> > recordsettet?).
>
> Den skjulte pointe ville være at det script, som lige nu
> opdaterer alle .html-, .asp-, .sql-, .php- .... filer vil kunne
> oversætte alle strenge i "databasen" samtidigt. Det vil spare
> ret så meget tid i længden.
> Alternativet er at køre med 5 forskellige databaser, der
> indeholder det samme...

Nu ved jeg ikke hvordan dit system er designet og din kode er lavet. Det
kan godt være at xml er en løsning, men det kan da også være at der er
andre (og bedre) løsninger.

> Fra og med ADO 2.5 kan man eksportere en Access table til en
> XML-fil, men netop fordi det er autogenereret synes
> implementationen klodset. Det er svært at læse og samtidigt
> kan man ikke benytte Æ, Ø og Å.

Jeg har aldrig brugt den, jeg mente bare at jeg havde set methoden og
ville give dig en pointer.

> Som en konklussion: Min ide var en lille omprogrammering fra
> den nuværende, hvor alt ligger i én .mdb-fil med en masse
> asp-filer, der bruger SQL queries. Målet ville være moduler
> med de forskellige udregninger, hvor data til hver udregning
> lå i én .xml-fil. Men skal alle udregninger også
> omprogrammeres kan det blive meget mere omfattende end det er
> hensigtsmæssigt.

Du siger at målet er "moduler med de forskellige udregninger". Hvorfor
skal de ligge i xml? Xml er til data. Jeg roder nok vist rundt i det.

> I sig selv er XML ikke målet, men en slags teknologi, hvor
> alle database tables ligger i flat files, som kan
> forespørges vha. SQL.

Det er da en beskrivelse af en access-database? Du kan ikke bruge sql
imod en xml fil.

--
Lauritz

Steffen Tiedemann Ch~ (29-01-2001)
Kommentar
Fra : Steffen Tiedemann Ch~


Dato : 29-01-01 20:39

> Du siger at målet er "moduler med de forskellige udregninger". Hvorfor
> skal de ligge i xml? Xml er til data. Jeg roder nok vist rundt i det.
Det er data, der er basis for udregningerne. Eksempelvis priser på
forskellige subprodukter.

Steffen




Lauritz Jensen (30-01-2001)
Kommentar
Fra : Lauritz Jensen


Dato : 30-01-01 05:16

Steffen Tiedemann Christensen wrote:
>
> > Du siger at målet er "moduler med de forskellige udregninger".
> > Hvorfor skal de ligge i xml? Xml er til data. Jeg roder nok
> > vist rundt i det.
> Det er data, der er basis for udregningerne. Eksempelvis priser
> på forskellige subprodukter.

Ookay! Jamen, så kan du jo (bare) lave et admin interface, på et af
websitesne, hvor du laver opdateringerne, og som så ftp'er/post'er det
rundt til de andre?

--
Lauritz

Søg
Reklame
Statistik
Spørgsmål : 177557
Tips : 31968
Nyheder : 719565
Indlæg : 6408868
Brugere : 218888

Månedens bedste
Årets bedste
Sidste års bedste