exporting-importing paragraphs into a spreadsheet

[john harding]

I'm preparing a spreadsheet designed to restructure my catalogue and I've hit a problem. My site includes some extended info. pages, created originally in the GUI, which are broken into paragraphs. I've tried two methods of copying them from the site. The first was to go to the GUI and copy the text, then paste it into the spreadsheet. What happens is that only the first paragraph ends up in the selected cell. Each successive paragraph is in a cell two rows down. That's not going to work.

The other was to copy the text from an exported .csv file. This way the text all sits in the cell into which it's pasted, but each paragraph is preceded by "\n\n". As I understand it, if I import that as it stands the \n\n will not be interpreted as paragraph markup, but as text. In that case I suppose what I have to do is use Find and Replace to substitute !!<</p>>!!!!<<p>>!!, then go back over it and remove the !!<</p>>!! from the first one and !!<<p>>!! from the last one. Not impossible, but blimey ...

Have I got that right? Is there a better way?

[completerookie]

have you thought of doing the same using the import via ODBC.
you clearly know where the data comes from, so just open the link and import, I do it all the time

[john harding]

I'm afraid I'd never heard of ODBC so it looks like rather too steep a learning curve. I imagine I'm stuck with manually editing out all the \n's, which is a pain because as well as the ones that represent my new paragraphs Actinic inserts one for every 'carriage return', so simply replacing them all with !!<</p>>!!!!<<p>>!! won't work.

This seems to me a fundamental error of design. Any operation like adjusting prices across the board is going to have to be done in a spreadsheet, so it's vital to keep the spreadsheet in sync with the site. If Actinic inserts markup that it can't read when you re-import, you have a dilemma. Either you leave the GUI well alone and make even minor changes by importing the whole darned thing, or else you remember, every time you change some little thing in the GUI, to make the same change in the file. Again, am I missing something? Is it really true that the program can't understand its own formatting markup? That's hard to believe.

[john harding]

Completerookie, are you saying that using ODBC would prevent Actinic inserting markup which it can't interpret? Do you have evidence for this? And if so is there an easy way of learning about ODBC? I don't think you know what a complete rookie is. You say, "you know where the data is", but I'm hanged if I do.

I've just edited one of my Extended Info pages. It took about 10 minutes. In order to see the whole thing I copied the text from the exported file into Notepad, then converted each "\n\n" into the appropriate HTML tag, viz:

!!<<p>>!!

!!<</p>>!!!!<<p>>!!

!!<</p>>!!

Then I pasted the result into a page in Actinic, previewed the store to check accuracy, found mistakes, corrected them, previewed again and when satisfied deleted it from the Actinic page and pasted it into the spreadsheet, hoping to God that I'd done it in the right cell.

My site has some 1500 items, and everywhere I have used paragraph breaks in the GUI I'm going to have to edit them. This is not a trivial matter. It can't be done automatically, because for each instance of "\n\n" there is a choice of three pieces of HTML.

The mistake was of course using carriage return in the GUI. How was I to know that Actinic would translate it into markup that it would not itself recognize?

Unless someone can tell me there's something I haven't thought of, I'm going to have to spend a very long time digging myself out of this hole.

If Sellerdeck cannot find a way of translating carriage return into markup that it will later be able to recognize, it should at least ensure that user are from the outset given a very prominent warning that if they use the carriage return they may be setting themselves up for disaster.

[fergusw]

John,
I think what Kevin was referring to was simply importing the Product table from Access into Excel for you to then edit:
http://office.microsoft.com/en-gb/ex...005200852.aspx

You could chop out all the unnecessary fields and leave yourself with the bare minimum.

Also, have you thought about using !!<<br/>>!! instead of <P> tags to create the breaks?
This would mean if you went down the find and replace path it should be easier to implement rather than dealing with 3 variants of </p><p> etc....

[john harding]

Thank you, that is helpful. Should have thought of it. </br> is much less likely to go wrong. I suppose I've allowed myself to be intimidated by HTML gurus who tell you it's sloppy.

This morning I started the job and it looked as if it was going to take me days, with the virtual certainty that there would be many mistakes.

Access to Excel. I see. I've actually managed to get to the age of 75 without Access so far, and with an eye on the Guinness Book of Records I'm trying to keep it that way.

I'm still mystified as to how Actinic could have got into this position. Its font formatting shows that it's capable of creating markup in the form of commented HTML, which it will be able to recognize when it gets it thrown back at it, and its blobs of \n\n show that it recognizes the carriage return as calling for markup of some sort. Why in Heaven's name could it not have used !!<</br>>!! instead of \n ?

I'm not wishing to be negative. I'm hoping this may somehow trickle back to the people who're in a position to do something about it. Because as it stands it is a catastrophe waiting to happen.

[john harding]

Thank you !

You see what I mean about the virtual certainty of errors ?