Re: do we need plone.app.customerize? was: [Plone-Users] Insufficient privileges on folder_contents

"T. Kim Nguyen" <[email protected]>
Newsgroups gmane.comp.web.zope.plone.devel
Message-ID <1386656180899.900d4a0b@Nodemailer>
Please do not remove TTW customization via portal_skins nor portal_view_customizations until people have had time to try out your proposed replacements for them for at least one full version of Plone. In other words by all means let's explore better ways of supporting TTW customizations but as add ons and only consider making them the default (and removing skins and customerize) from core until quite some time has passed for all to run them through their use cases. 




I'm capable (mostly) enough as a developer but out university runs so many sites, each of which has an owner who wants a slightly customized theme and viewlets. Customerize has caused errors for us and we learned how to detect those cases and work around them. It's not perfect but it's better than making a team or two or three devs work only in the file system

and have to run buildout and restart clients constantly in order to keep up with the flood of custom behaviour requests that non devs can handle now, live, without ssh or file system access into /opt and all that involved. 




Skins: I just finished throwing together a PFG form and some custom scripts and External Methods that will deliver student opinion survey reports electronically to 300-400 instructors each semester. I do not want to contemplate a world in which I have to do all of that on the file system instead of being able to test and evolve and demo it live TTW. 




At PSM13 we talked about how there would be documentation showing noobs like me how I should do all these TTW things without skins and customerize. Only then would people like me know for sure we could tell our institutions and organizations that Plone still scales for our kind of use cases. 




Please move cautiously. 




Kim

—
920-292-0863 mobile/Google Voice

Sent from Mailbox for iPhone

On Mon, Dec 9, 2013 at 11:34 PM, Nathan Van Gheem <[email protected]>
wrote:

> Playing with the idea of TTW jbot:
> https://github.com/collective/collective.jbot
> This approach isn't "safe." It actually creates temp files for each
> template customization so templates aren't run in restricted python.
> I think this could hit most people's use-cases though.
> Thoughts?
> -Nathan
> On Thu, Dec 5, 2013 at 12:41 PM, David Glick (Plone)
> <david.glick-z4DKO/[email protected]>wrote:
>> On 12/5/13, 6:24 AM, Nathan Van Gheem wrote:
>>
>>> I think many problems can probably be solved with diazo these days and
>>> yes, customerize doesn't not consistently work.
>>>
>>> That being said, we do need a customization story for non-devs.
>>>
>>> How feasible would it be to make a TTW jbot?
>>>
>>>  Shouldn't be too hard. z3c.jbot already has the right hooks to look for
>> a template's source "somewhere else" when a template is rendered. We would
>> just need to add to the possible "somewhere else" locations, by configuring
>> it with a set of ZODB paths to search for templates.
>>
>> This only takes care of overriding existing templates though. In a world
>> without portal_skins and Acquisition, to add new templates we would need a
>> way to register new views TTW (stored in the persistent component
>> registry). There's no technical reason that can't be done, but no one has
>> built it yet.
>>
>> And even for the use case of overriding templates, security is a caveat.
>> Part of the problem with portal_view_customizations is that it takes a
>> template which was running as filesystem code (i.e. unrestricted) and, once
>> customized, runs it as restricted Python. That tends to lead to
>> authorization errors once things are customized if the template was/is
>> using things that aren't allowed in restricted code. For some sites (i.e.
>> most standalone sites) it would be fine to allow unrestricted execution of
>> TTW-edited code as long as only Managers are allowed to edit that code. But
>> for shared hosting (multiple Plone sites for different clients in one Zope
>> instance) that's not very safe. I'm not sure how to solve this for those
>> sites, short of maybe doing automated testing of all templates to make sure
>> they still execute successfully as restricted Python.
>>
> -- 
> Nathan Van Gheem
> Solutions Architect
> Wildcard Corp

------------------------------------------------------------------------------
Sponsored by Intel(R) XDK 
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk

_______________________________________________
Plone-developers mailing list
Plone-developers-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/plone-developers
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.