>> Solutions: >> >> 1) Create a new type using CPSTypeMaker. Worked great. >> Couldnt find where items were stored and as such no >> way to do a bulk load
>They are stored as objects in whatever workspace/section you choose to create >them. > No they are not. They are stored as proxies for the actual objects. >> 3) Create a new SQL based CPSDirectory, interfacing to >> the previous Gadfly table. Works fine for search. It >> doesnt work for insert. No way to bulk upload >It's probably not tested with Gadfly. MySQL might work better. > Right. Why should I need an aditional piece of software to manage? >> Any hints? Whats the best way to bring in a table (SQL type of >> table, even if spreadsheet/csv stored) into CPS, with CRUD interface >> (preferably the CPS-based workspaces) >> *and* do a bulk upload? >It depends on what you want to do with the data. Since it is contact data, I >would go for a >CPSDirectory of some sort. Making a script that takes CSV data >and creates entries in a ZODB base >CPSDirectory shouldn't be much work. > What happens with the next table of stuff? Should a programmer be needed to do this kind of basic stuff? I'm trying to resist the RoR pull.. but with the Zope "complicate as much as possible strategy" and the CPS "lets go the Java path strategy" its getting hard. Perhaps I should have gone the Plone way; or someone might actually fork CPS and maintain the Zope/Python base.... -- MV _______________________________________________ cps-users mailing list [email protected] http://lists.nuxeo.com/mailman/listinfo/cps-users
