Andreas Jung wrote:
> On 03.07.09 08:23, Michael Mulich wrote:
>
>> I am writing a script that can be used to export (and eventually
>> import) all/some of the content in a Plone site to comma separated
>> values (CSV) files.[1] My question is, what would be the best
>> approach for testing the package? The package requires a Plone site,
>> but is not part of a Plone site since it is a script outside of Plone.
>>
>>
> First: why are you trying to reinvent wheels? There is for example
> ArcheCSV for importing content into Plone using CSV.
> There is GSXML for exporting/importing content based on XML. I blogged a
> while ago using an ini-file approach for doing
> content migrations..
>
> Second: personally I would not care much about tests for this particular
> use case because such test will never
> replace any real tests with real software when it comes to import those
> later into other systems. Takes three different
> spreadsheet application and all will behave slightly differently.....
>
> -aj
>
It's funny you should use wheels plural. Does that mean there is no one
good product for importing/exporting Plone content? I'd say yes,
because further research has shown that this topic is actually in a PLIP
for Plone 4.[1]
Plone has enough internal wheels and sprockets as it is. Why add
another wheel inside of Plone? I am suggesting we try doing a few
operations outside of Plone. Anymore I am reluctant to add more
products or wheels to a Plone site, sometimes for fear of upgrades,
other times for fear that the product will not uninstalling correctly.
I am not saying GSXML has either of those problems. In fact, GSXML
looks very upgradeable, seeing as it works from Plone version 2.4.4 and
up.
One of my purposes for making this external import/export script is to
leverage the wsapi4plone package.[2] The import/export use case is a
very simple one... I have not even begun to dive into using wsapi4plone
XML-RPC calls to retrieve, updated, create, and delete Plone content
from things like desktop and mobile applications. I've also developed a
decent prototype script that allows two or more Plone sites to
communicate with one another and share content using the wsapi4plone
package. We will also be working on a product in the near future for
pushing content from one site to another when a workflow event is
triggered. And in the distant future, we envision communication with
other CMSs, because not everyone uses Plone, even though we would like
them to. ;)
So yes, I may be reinventing the wheel, but sometimes that is necessary
to get a better quality, long lasting, and all terrain wheel. Maybe I'm
simply suggesting we align efforts under one light, concise, and
versatile API?
-Michael Mulich (pumazi)
[1]
http://dev.plone.org/plone/ticket/9328[2]
https://weblion.psu.edu/trac/weblion/wiki/WebServicesApiPlone_______________________________________________
Product-Developers mailing list
[hidden email]
http://lists.plone.org/mailman/listinfo/product-developers
