 |
Ubercart |
|
|
|
||
|
Thu, 09/13/2007 - 08:53
 I have given the XML importing a try with no success at all so far. I truly believe that its not the right format for the job XML is just a pain, CSV is a much better format. I am having a lot of trouble creating files in XML and converting data into that format .. There needs to be an easier way.   
Re: Data Importing
If a store's information, or even just a list of products was representable as a 2-dimensional data file, I'd agree with you. But they aren't. Products have structure, with a variable number of data structures within them. They have exactly one model number, price, and weight, but they can belong to one, many, or no categories. They can have many different attributes, each with a different number of options. And there's also shipping information which depends on the different shipping methods that are installed. Maybe there's a way to do it, but I couldn't figure out how to represent all that in a single CSV file. So I went with the painful XML. I'd have really liked to use YAML, but PHP doesn't handle that too well. 
Re: Re: Data Importing
I realize this is a huge undertaking given all the permutations. I have not seen a really "good' way to do it as of yet. I attached the way Yahoo stores uses the CSV file to do mass importing. It actually worked "pretty well". Bottom line is at some point, someone has to key information into a file. Also, have you considered an approach that might start from the system itself? Meaning -- the Admin sets up the skeleton attributes, categories, etc, in Ubercart, then generates/exports a CSV format to populate with products, then import back into Ubercart? The other issue to consider, (not saying you haven't) is to be able to 'sync' the store database to a master DB. For example, if I am a distributor for a couple of electronic manufacturers, I need to update pricing and product availability daily...sorry, I digress.
 
Also, have you considered
That's a very good idea! I'm all for that one. It would help simplify this a lot. NOte, this would be a good feature for XML as well if Lyle wants to focus that way.
Re: Data Importing
I did succeed to fill the system from an XML file, it works. At this thread (http://www.ubercart.org/forum/development/627/import_export_hooks_other_...) I placed a completely undocumented and not generic conversion script.
XML is driving me nuts
I tried loading that cck_fields_export.xml file with Excel and opening with Excel it says : So thinking well OK seems to be the only option here... It opens up and seems perfectly arranged, so I enter an additional Item to test the import , and go to save the file as XML again . But NO .. it does not want to save as XML ... It then tells me : So this is where I am stuck I cant seem to open XML and edit it or add to it and save as XML, the whole point of importing the data is to save some time and so far I could have entered a few hundred products manually in the time i have wasted trying to get this to work. It is most likely because I dont understand XML that I am having problems, but if having to spend a month learning XML to use ubercart is required then I may as well be using something else. Any clues to how to edit the XML add and remove from it would be great, help. cheers.
Re: XML is driving me nuts
There are a few people working on a more simpler import/export, by csv and/or by a more simpler xml. http://www.ubercart.org/forum/development/627/import_export_hooks_other_... Unfortunately they are not finished yet. The best one yet is over here: http://www.ubercart.org/comment/982/csv-xml-conversion-script But I have not tested it yet. So, if you would have a little more time then there will be some easier ways to import products. Hans   
Re: Data Importing
Actually, I'm half ay though my CSV import script but have hit some modeling issues which I think really needs to be discussed. Firstly, I really support Ryans decision to go with XML. If you think about it, it is just acting as in interface/stub to importing. XML is good for this because:
The reason people want CSV support is not because it's a better format, it because there is a better interface to use it, namely: spreadsheets. Also I guess all the accounting programs export to various spreadsheet formats which is where a lot of the data comes from. Then there is the problem as mentioned in point 1 above. Its interesting to note that even Yahoo haven't got a good answer for this (thanks dougdagaz for the spreadsheet above). In fact they have product attributes all in one column, which doesn't allow you to enter individual tracking numbers for combinations of these which is essential in stock tracking! I'm working off a spreadsheet for a client that has ever attribute combination for a product in its own row (i think this is how MYOB exports) and this approach solves the high dimensionality problem by flattening the whole scheme to 2D. The trade off is that you then have things like 'name' and 'description' repeated many times which is clumsy. This seems back to the modeling problem again: the 'name' and 'description' are associated with SKUs (the physical products) more like Taxonomy Terms because they related to more than one physical product (small+red, small+blue etc) and actually have no input to the actual purchasing process, apart from a visual reference for the customer to check they have the right item (referential not integral). Perhaps this metadata should be separated from the products and products should be the physical products. Anywayz, back to CSV importing ... :@
Re: Re: Data Importing
CPill your rationale sounds well... sound just so i follow. 1) uc has an export to xml function / script So assuming one knows how to format and structure the xml file, import should be pretty smooth. 3) That leads me to believe the difficulty with this is creating the appropriate structures / format in the xml file AND then getting your data from somewhere else into that format - right? 4) To that end. CpILL, are you creating a csv to XML converter or a direct csv to uc? I think it's the former because as you say, excel provides a better interface to "prep" the imported data while xml is better for the 3d structuring and universal import. Is that correct? Put another way. I create my import data file in col/rows in excel because it's easier and avoids all the tags required for xml. It also allows easy duplication of fields in columns. Once that's done, your csv to xml converter takes the csv file and then wraps it in the appropriate xml tags/structure. then it goes to uc. yes? i guess as i read my own words that doesn't exactly make sense because everybody's xml file is going to be unique (have a unique structure). a script would have to be mighty brilliant to figure that out on the fly. then again, your pic makes you look like a wise old sage. so you might just be that brilliant
Re: Re: Re: Data Importing
On (3) you are right I'm generating a(n) (Simple)XML structure from the 2D spreadsheet which is then passed to the UC Importer module (which is thus a dependency for my own module). This means that if the model on the UC side changes my impoter won't have to (assuming the XML interface stays the same). Everyones CSV will be different but within the confines of what the importer will understand. The XML is quite flexible but is also a constrained to the specification. |
|
