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

Yes I guess we can make classes. But if we support classes, we still have
to support simple functions too, because that's easier to understand for
non-Plone developers.

On Thu, Apr 2, 2015 at 7:54 AM, Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]> wrote:

>
> > On 2 Apr 2015, at 12:36 pm, Dylan Jay <djay-n0pU0XVUApFWk0Htik3J/[email protected]> wrote:
> >
> >>
> >> On 2 Apr 2015, at 11:14 am, Asko Soukka <[email protected]> wrote:
> >>
> >> Asko Soukka wrote:
> >>> Now it's possible to create selective exports into themes and
> >>> continue from that TTW
> >>
> >> TL;DR; next release of collective.themesitesetup provides support for
> exporting and importing templates and scripts from portal_skins/custom
> >>
> >> Well, to get the original idea of "heavy TTW themes" really to work, it
> should be possible to populate e.g. portal_skins/custom with custom portlet
> templates to be able to configure portlet assignments with custom TTW
> portlets in portlets.xml:
> >
> > I think porlet assignments are great but portal_skins is a bad idea.
> > portal_skins is not a great way to do TTW development which is why we
> are phasing it out.
> > fragments is better but erics idea of theme views is even better (
> https://github.com/ebrehault/collective.ttw) because its closer to proper
> views and you get the power of python so you have to learn less ZPT which
> would be
>
> except for the idea in c.ttw to create jbot templates. Overrides are a bad
> bad idea IMO.
> Also Eric, is not possible to support class based views to make them more
> similar to FS plone views?
>
> > new to people. In fact writing python views that get turned into xml
> automatically without writing any ZPT at all so all you need to know is
> python and diazo... thats not a bad idea. Most people new to plone will
> have never touched ZPT. The less they have to learn the better. Providing
> multiple ways is also bad.
> >
> > In addition this whole important and export of code isn't great. The
> code should live and be live inside the theme, not synced. This is
> integration code not the same thing as some initial content setup. If you
> change it inside a live theme it should instantly change how the site works.
> >
> > In fact this very idea of GS being "installed" isn't super great but it
> convenient for now. Longer term it would be better for certain settings to
> live in the theme itself rather than be "installed". For example all themes
> would normally provide style definitions that should appear in tinymce
> style dropdown. Having that in GS that gets synced on theme activation is
> kind of ugly. It means that if I change it via a control panel I have to
> remember to also go change it in GS xml inside the theme to ensure it gets
> shipped with my theme. A bit painful. A better solution would be to have
> those settings directly come from inside the current activated theme
> manifest rather than the registry. Alternatively something more general
> could be created whereby you have a layered registry where some settings
> from the theme are merged with local settings. I suspect that will be
> complex though however I believe something similar has already been done
> with local registries for lineage.
> >
> >
> >>
> >> I duck a bit deeper into, how GS content export/import works.
> >>
> >> The default GS import/export support all DAV-aware content objects, but
> CMFCore selects to properly export and import only CMF-objects.
> >>
> >> But I could do the following:
> >>
> >> - add a marker interface for theme developer to enable exporting of
> portal_skins/custom (by tagging first portal_skins and then custom)
> >>
> >> - enable export/import of page templates and zope scripts by
> >> tagging their classes with a required interface (they are DAV-aware,
> >> but they are just too old to provide the interface)
> >>
> >> - register a custom GS exporter for Plone site root to support
> >> the previous
> >>
> >>
> https://github.com/collective/collective.themesitesetup/commit/332ea1a1c0e4955d98b2ca70575c23af0efd66db
> >>
> >> The only "ugly" part is that I have to override the default GS content
> exporter for Plone site root, the new one should actually be a bit better,
> because the default one exports stuff it doesn't import (e.g. acl_users'
> plugin configurations).
> >>
> >> 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