|
Paul Borgermans
|
Wednesday 07 July 2004 9:18:50 am
Lior, there is no documentation on the structure of the XML file (although there once was a "concept" published, but which is no longer valid) Try reverse engineering: create a node which contains dummy nodes of the classes/structure that you want. Look at what is generated when you export this so you "know" what to do. I think a php (or perl) script armed with XML functions should be able to create a valid XML import file. For your MsWord documents, you will need to serialize them. hth -paul
eZ Publish, eZ Find, Solr expert consulting and training
http://twitter.com/paulborgermans
|
|
Kåre Køhler Høvik
|
Thursday 08 July 2004 1:04:41 am
We've not ducumented the xml structure in the current import/export, because it needs some improvement to be used as a general import/export format. Untill this is done I suggest you reverse engeneer the packages, it's quite simple xml.
--
Kåre Høvik
Kåre Høvik
|
|
Patrice DUCLAUD
|
Wednesday 21 July 2004 6:02:47 am
Hi Paul,
Is it possible to use Import/Export package only generating an XML file where XML tags (name) will correspond to the structure of a class (attribute’s names) defined in eZpublish ?
Like plenty of eZpublish’s users I've a mount of data in my information system (another system and another databases) and I'd like to transfer every day and automatically a part of data in eZpublish for my future web site (list of clients (futur identified users of the web site), about 4000 and a few data). Every day I realise changes (add, modify, delete...) and I don't want to do this task twice and manually. The need is the same if I want to migrate my actual intranet site to eZpublish. I’m sure that Import/export package functionalities are perfect to transfer data from a eZpublish web site to another.
So, you said :
“Try reverse engineering: create a node which contains dummy nodes of the classes/structure that you want. Look at what is generated when you export this so you "know" what to do.”
Ok, That’s right, but how can I be sure my code will work with next eZpublish upgrades ? The use of eZpublish’s functionalities (XML import/export package) is certainly the best way to do good job, to stay coherent with the release plan and to profit of complete integration of my data in eZpublish class (search, versioning …). I'd like, if it’s possible, not to have to rewrite all my code. Just write once it’s hard for me … :-(
You said too,
“…no documentation on the structure of the XML file (although there once was a "concept" published, but which is no longer valid)”
That’s mean my code will be no longer valid too :-(
In a package generated by eZpublish (class article) I can see 3 folders (documents, ezcontentobjects (my data are here) and simplefiles) and an xml file (package.xml). According to you, the best way for me will be to generate this structure (but it's not simple). Furthermore plenty of tags in XML file have unknown value for me (remote_id="61c021e4d8382f65302cd92c4287ea92") and I‘m not familiar with the structure of XML import/export package.
The use of a generic structure (which certainly does not exist now ?) where I’ll just have to create an xml file containing the data I want to manipulate will be a good solution. Perhaps a simple structure and a script (using command line) is imaginable or is it a dream ?
It’s difficult for me to think I could not use eZpublish only because automatic import data from another system is not easy ( eZ :-) ) when I do this every day in another system (import/export data (text and xml) ). Yes I know other system don’t do what eZpublish do. Thanks for all the other functionalities of eZpublish and the general concept which is and will stay a very good product. Sorry for my English ;-(, I’ll be better next time, I hope . Patrice Duclaud.
|