Re: What I'd like to see gsoc achieve: plone distributions

> On 28 Mar 2015 01:59, "Asko Soukka" <[email protected]> wrote:
> > > I figure the simplest way is to use GS but store it in portal_resources inside the theme in a profiles folder.
> 
> I'd prefer not to see it in themingplugins as I don't agree with encouraging jbot use as it discourages the use of a proper api and instead makes hacking the core the recommended way to customise a site. Besides its a change unrelated to jbot or ttw coding so why conflate it?
> 

I meant that this should be doable within the constaints of p.a.theming's plugin framework and thought p.a.themingplugins as a "one place shop" for all experimental features.

Dedicated package like c.themesitesetups sounds would be ok as well. (I should check at some point, if zpt-fragments could also be published as its own add-on.)

> > But should there be support for uninstalling the profile imported during a theme activation? And if so, would it be good enough to run GS implicit "magical" uninstall, or should an explicit uninstall profile be supported?
> 
> I suppose it should mirror fs GS as much as possible since that is well supported and documented including uninstall profiles and possibly someway to support upgrade profiles? Do zip themes even have version numbers now?
> 

I guess, themes don't have versions, because they have been though to be "volatile", without any persisting side effects.

To be exact about GS, it doesn't know anything about uninstalling. It's QuickInstaller, which tries to keep track of changes made by GS profiles and unstall them during when "add-on" is "deactivated". And then we have the ad-hoc-convention of "uninstall profiles", which are executed through GS import profile API via QuickInstaller uninstall hook.

Well, need to do a simple proof-of-concept at first.
> > When it's not universal? AFAIK it emulates DAV PUT, which should be universal. There might be limitations for Archetypes (e.g. only one primary field per content item), but DX content uses the new plone.rfc822, which is can be extended for custom field types. (I have experimental plone.rfc822 adapters for Archetypes', but it's long shot to merge those into Archetypes).
> >
> 
> As in it only works for AT and DX. Might not work for things like Plomino databases but I guess that can be lived with or data stored in annotations.
> 

Yes. To be more exact. It only works for schema defined data. The CMF version of Plomino documents should be importable, but they would be empty, because the import would not have any idea of their schema. Also, for AT it only support single primary field (Blob or RichText) per content object (and that's why I had to adapt AT for plone.rfc822).

So, in Plone, there's a separation between content and its configuration, and RFC822 only cares about the configuration. Yet, I think, with DX, it should be possible to define a such behavior that would take care of providing exporting and importing of configuration (as fields) for plone.rfc822 (which iterates through all fields of all behaviors).

Well, of course, any JSON import/export -packages could also reuse plone.rfc822 -adapters.

Regards,
Asko

------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers