In case anyone is interested, this was rather simple to implement using schemaextender.
The svn for the product is at https://svn.plone.org/svn/collective/uwosh.pfg.d2c/trunk/, it on pypi http://pypi.python.org/pypi/uwosh.pfg.d2c and I'm waiting for approval on plone.org. uwosh.pfg.(d)ata(2)(c)ontent I know it's probably a stupid name, but it's the best I could think of without getting it getting too long and I hate wasting too much time thinking of a decent name for a package. -Nathan On Mon, Jul 26, 2010 at 8:09 AM, Rose Pruyne <[email protected]> wrote: > Nathan, As someone who is currently spending quite a bit of time working on > creating content types to correspond with FormGen data, I think your adapter > would be much appreciated by many and would get a great deal of use. > > -- > Rose Pruyne > Programmer-Analyst > WebLion at Penn State > weblion.psu.edu > > On Fri, Jul 23, 2010 at 1:38 PM, Matt Barkau <[email protected]> wrote: > > >> >> ---------- Forwarded message ---------- >> From: Nathan Van Gheem <[email protected]> >> Date: Fri, Jul 23, 2010 at 1:30 PM >> Subject: Re: [Product-Developers] A better PloneFormGen save data adapter >> To: David Hostetler <[email protected]> >> Cc: Plone Products Developers <[email protected]> >> >> >> Thanks for the quick responses. >> >> A dexterity content type, you mean? >> >> No, not exactly. This is a long term goal of course. >> >> What I'd create is a generic content type that the save data adapter would >> always use. So it'd be a pseudo proxy type of the actually form and behave >> like a regular archetype object using the schema from the pfg form. >> >> What 'type' is the resulting content item? >> >> This would always use the same Archetype type. So it's not an >> auto-generated one or anything. It would just dynamically generate it's own >> schema from the pfg form. >> >> What determines the 'view' template for the ad-hoc content item? >> >> It'd just use default views, but you could always add extra views on your >> own. >> >> Can you explain a little more how this differs (and is presumably >>> better) than the 'manual' equivalent: >> >> >>> <http://plone.org/products/ploneformgen/documentation/how-to/creating-content-from-pfg> >>> http://plone.org/products/ploneformgen/documentation/how-to/creating-content-from-pfg >> >> The use case is different from actually generating the real content type. >> If you're interested in that, check out uwosh.northstar. That would generate >> an archetype type with pfg using zopeskel. >> >> I know the long term goal of unifying our schemaeditor for zope schema >> generation so you can easily use them with pfg, dexterity, etc. This is just >> a really simple alternative in the meantime for cases where you don't really >> need a full-fledged type and any extra customization can be done with TTW >> page template view and placeful workflows. >> >> >> Does that clear up everything? >> >> >> -Nathan >> >> On Fri, Jul 23, 2010 at 11:39 AM, David Hostetler >> <[email protected]>wrote: >> >>> Just seeing if I understand this right.. >>> >>> Basically this would allow a PFG instance to take on the role of the edit >>> form for an ad-hoc content type? >>> >>> Whereas the edit form for content types is provided automatically by >>> Archetypes or via a hand-crafted .pt, this allows the form itself to be a >>> PFG object. And furthermore, the PFG object becomes the source of the >>> definition of the schema of the resulting target content instance. >>> >>> What 'type' is the resulting content item? >>> >>> What determines the 'view' template for the ad-hoc content item? >>> >>> >>> >>> Sounds interesting. Can you explain a little more how this differs >>> (and is presumably better) than the 'manual' equivalent: >>> >>> >>> http://plone.org/products/ploneformgen/documentation/how-to/creating-content-from-pfg >>> >>> >>> thanks! >>> >>> -David >>> >>> >>> >>> >>> On Fri, Jul 23, 2010 at 12:20, Nathan Van Gheem <[email protected]>wrote: >>> >>>> Hello All, >>>> >>>> I'm interested in writing a save data adapter for ploneformgen that >>>> saves the data to an actual content type. It'd just take the fields from >>>> the >>>> ploneformgen form for it's schema. I find that in some cases, a user just >>>> wants a persistent form and it seems foolish to write a packaged content >>>> type for each one. >>>> >>>> The advantages being: >>>> >>>> - can use collections to query results if some of the dublin core >>>> meta data is available >>>> - can apply placeful workflows to content type >>>> - users can comment on form >>>> - easier to manage data after >>>> >>>> One possible snag is if a user removes a field or renames it, there >>>> might be data loss. >>>> >>>> I'm posting this here because I'm interested in hearing what others >>>> think of the idea, if it's already done, or if I'm just being foolish >>>> before >>>> I write a product for it. >>>> >>>> >>>> Thanks, >>>> Nathan >>>> >>>> _______________________________________________ >>>> Product-Developers mailing list >>>> [email protected] >>>> http://lists.plone.org/mailman/listinfo/product-developers >>>> >>>> >>> >> >> _______________________________________________ >> Product-Developers mailing list >> [email protected] >> http://lists.plone.org/mailman/listinfo/product-developers >> >> >> > > > >
_______________________________________________ Product-Developers mailing list [email protected] http://lists.plone.org/mailman/listinfo/product-developers
