Re: [Framework-Team] resigning from framework team

[David Glick (Plone)]

Thank you so much for your service to Plone on the framework team, 
Johannes. Enjoy the chance to put time and energy into other things, but 
you are welcome back any time!

David

On 12/12/17 3:40 PM, Johannes Raggam wrote:

Hi guys,

since some time it's getting harder for me to attend the Framework Team
meetings. It's due to workload, family obligations and rediscovered
personal interests which are getting in the way. Also, I'm part of this
team since 2011 and I feel it's time to make room for others.

So: I want to resign and leave the Framework Team.

Of course I'll continue to work on my submitted PLIPs, take part in
discussions and continue to contribute to Plone wherever and whenever I
can. So I won't wind down my Plone contributions. I just try to get back
my spare time :)

Maybe I'll rejoin this or another team if I find some more time for it
in the future.


So long and all the best,
   Johannes
___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team



___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] Stepping down

[David Glick (Plone)]

Open source work has a way of taking more of us than we originally 
intended to give, and it's so important to recognize when that happens 
and correct it.


Jesse Noller had a good blog post on this topic recently: 
http://jessenoller.com/blog/2015/10/31/community-boundaries


And I also think of Marius Gedminas' recent tweet, " At least I no 
longer do stuff because I think I should, or because stuff need to be 
done - when I do FOSS, I do it because it's fun."


All the best to you Roel, and the rest of you...hope to see many of you 
in Boston, or maybe sooner.

David

On 11/10/15 3:36 PM, Roel Bruggink wrote:

Hi all,

Okay, that "change of interest" sounded a bit more dramatic than 
intended :)


I found myself in a position where work-private life was out of 
balance and no longer sustainable for me.


There were two triggers for this conclusion. One was, of course, Rob 
leaving Four Digits and the process in "reinventing" our company. The 
other was a remark by Timo during the Anniversary Sprint where we 
talked a bit about why he stopped playing drums, which boiled down to 
"that's how things go". It made me think if I was ready to give up on 
that just now - I'm not.


Playing drums and making music has been a huge part of my life for a 
long time, but didn't get the attention it needed. I'm not trying to 
become a rockstar -as Ramon suggested-,  though I do need to find 
myself a band and create music again.


In all, thank you for an awesome and educational time in the FWT. 
Hopefully see you guys soon!


-Roel

On 10 November 2015 at 22:16, Johannes Raggam > wrote:


tnx man! and hope to see you around some time.

cheers,
  johannes

On 11/10/2015 05:23 PM, Roel Bruggink wrote:

Hi all,

I'm stepping down from the FWT effective immediately due to
change of
interest.
If you need any kind of input, please don't hesitate to ask!

So long, and thanks for all the fish!

--
Roel Bruggink
https://www.fourdigits.nl/over-ons#roel-bruggink


Four Digits BV
https://www.fourdigits.nl  tel:
+31 26 4422700


___
Framework-Team mailing list
framework-t...@lists.plone.org

https://lists.plone.org/mailman/listinfo/plone-framework-team




--
Roel Bruggink
https://www.fourdigits.nl/over-ons#roel-bruggink 



Four Digits BV
https://www.fourdigits.nl  tel: +31 26 4422700


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] How to change default template for plone.schemaeditor?

[David Glick (Plone)]

On 5/29/15 4:55 AM, Eric Bréhault wrote:

Hello people,

I am trying to finish the TTW member schema editing PLIP 
(https://dev.plone.org/ticket/13350) for Plone 5.
I think it is a very useful feature, but there are still some issues 
to fix (see 
https://github.com/plone/Products.CMFPlone/labels/PLIP%2013350%3A%20Edit%20Member%20Schema%20TTW), 
so I would need a little help.


One of them is about the template (we want to display the schemaeditor 
into the regular Plone control panel template, for UI consistency 
reasons) https://github.com/plone/Products.CMFPlone/issues/516


I am pretty sure it is easy to fix (probably something like one or two 
zcml lines), and I saw it has been done successfully in 
plone.app.dexterity, but I am lost, I just cannot find a way to tell 
plone.z3cform to use a specific template for plone.schemeditor.


Does anyone know how to do it?

SchemaListing only renders the actual listing of fields; you can include 
it from your own view that renders the entire page, which is what 
plone.app.dexterity does.

___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] RFC: buildout.coredev all commits branch

[David Glick (Plone)]

On 2/16/15 10:02 AM, Timo Stollenwerk wrote:

Hi,

two months ago the FWT discussed creating a buildout.coredev branch 
that contains all commits to all packages in the Plone repo:


https://docs.google.com/document/d/1UVNLqQFrq8AJkmNxEO9J4flIqGTf_TbAqR3TWwFguRY/edit 



We need this in order to be able to trigger the buildout.coredev 
Jenkins jobs and properly passing the changelog to it.


As discussed back then Ramon implemented the functionality:

https://github.com/plone/buildout.coredev/commits/5.0-all-commits

As far as we can tell it works fine. Though, the only way to really 
test it is to put it in production (we can not do fully automated 
rebases on the all-commits branch therefore the branch diverged from 
the 5.0 branch, this problem will be gone if we switch to using the 
5.0 branch).


We were working hard (especially Gil!) in the last month to get the 
new Jenkins server ready for production:


http://78.47.49.108/

I think we could be ready within the next weeks. That would be a good 
opportunity to switch the 5.0 branch to the all-commits functionality.


Any objections?


+1 from me. I'm looking forward to the new Jenkins server.
___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] plone 4 only branches

[David Glick (Plone)]

On 1/25/15 9:24 PM, Nathan Van Gheem wrote:

Hi All,


I'd like to merge plone.app.widgets into all of other plone packages 
for plone 5.


In doing so, I need to create some plone 4 only branches for 
plone.app.dexterity and plone.app.contenttypes.


Any objections?


I don't really understand the benefit of spending effort to move the 
code. Is there an important reason I'm forgetting?




Also, what does everything think about Archetypes and 
plone.app.widgets. Should that code be merged as well or do we just 
start ignoring Archetypes in plone 5 a bit?


I think if we ignore Archetypes in Plone 5, it will significantly 
discourage users with custom AT content types from upgrading to Plone 5.


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] Joining the Framework team

[David Glick (Plone)]

+1!

On 11/3/14, 10:27 AM, Eric Bréhault wrote:

Hello,

At the Plone conference, Giacomo kindly asked me if I would like to be 
part of the Framework team.
I think it could be nice, so if you think my help could be valuable to 
you, I would be happy to join you.


Eric


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] auto csrf plip merged

[David Glick (Plone)]

Um. Looks like a bunch of tests aren't even running: 
http://jenkins.plone.org/job/plone-5.0-python-2.7/1931/console


On 3/11/14, 7:46 PM, Nathan Van Gheem wrote:

Hi all,

The auto-csrf plip should now be merged.

The test failures should clear up.

Let me know if there are any problems.


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] Arnhem Sprint PLIP Champions Wanted!

[David Glick (Plone)]

I put together an overview of the various efforts that are underway for 
Plone 5, along with a few thoughts on what the highest priorities are 
right now: http://titanpad.com/Sfinb2geKV


On 11/4/13, 7:42 AM, Rob Gietema wrote:

Just one more week and the Arnhem Sprint will start!

We currently have a total of 33(!) sprinters which we'll split into 5 
scrum teams during the sprint. To get the most out of the sprint we 
would like to get PLIP Champions who will act as Product Owners for 
the teams (preferably on location, but remote is also fine).


If you want a team to work on your PLIP please let me know and I'll 
add you to the list of available PLIP's. Checkout 
https://dev.plone.org/roadmap for available PLIP's for Plone 5.


Cheers,

Rob Gietema
Four Digits


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] additional index for plone.app.event

[David Glick (Plone)]

On 11/8/13, 2:51 AM, Johannes Raggam wrote:

On Fre, 2013-11-08 at 05:36 +0100, Rok Garbas wrote:

Quoting David Glick (Plone) (2013-11-08 03:45:05)

On 11/5/13, 1:07 PM, Johannes Raggam wrote:

Any thoughts or suggestions?



It seems like when importing you could just strip off the domain and use
the existing UID index? We shouldn't add a new index unless we really
need it, because it makes writes slower and increases the chance of
conflict errors.

you mean, on importing, that instead let plone generate a uuid on event
creation, i should just write the external uid into the UUIDIndex? i
don't think that this is a sane behavior - we expect plone.uuid (or
whatever) to do that and not rely on external uid values, which might
not follow RFC4122.


Oh, I see, you want to support event ids from an external source, that 
weren't generated by plone.app.event. That's the piece I was missing.



also, while we can omit the domain name when exporting, and thus
exporting the plone.uuid value directly, i think we cannot cut the
domain name from external events, because it's just part of their uid
(we want still be able to export that, right?).  (thinking again of
this, i still can store the external uid on the content itself, so this
argument is not so strong...)


If we do need to add this index for some reason that I'm missing, it
should be a UUIDIndex instead of a FieldIndex so that we don't have to
store an IITreeSet for each index term (since there should only be one
event for each event_uid).

aha, hm... so, an IITreeSet is stored, I didn't think about that.

on the other hand, i think of a use case, where a UUIDIndex is not
suitable: having a portal where different users can maintain private,
different calendars, they might import the same external event. then
there are many events with the same event_uid and a UUIDIndex cant help,
am i right?
the catalog search for existing events currently restricts on the
current path and does not even search in subfolders.


Hmm, good point.

Too bad we can't give FieldIndex a hint that most of the time a single 
value will be stored, so it could start that way and only upgrade to a 
treeset when needed.



side note: before releasing 1.0, i renamed event_uid index to sync_uid,
since i think that this concept can generally be used within plone for
any synchronization tasks.


+1. I would have called it external_id (it's the id from an external 
system, and it's not necessarily unique even within the portal, based on 
the discussion above). But maybe it's too much trouble to change now.


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] Arnhem Sprint PLIP Champions Wanted!

[David Glick (Plone)]

On 11/4/13, 10:36 PM, Timo Stollenwerk wrote:

I also started to write a PLIP for the removal of selected portal tools:

https://dev.plone.org/ticket/13770

Since I won't be able to attend the full sprint (only two days) it might
make sense if somebody else would champion that PLIP (at least for the
sprint). @David?

Yep, I can be the champion for the tool removal.


Another PLIP that I would like to see is to move all catalog indexes in
Plone to use unicode instead of utf-8 encoded strings. I don't want to
add another PLIP that I personally won't have time to work on though.


+0.5. It's a good idea but it'll probably mean a lengthy upgrade step. 
If we do it we should consider giving FieldIndex and KeywordIndex the 
ability to automatically decode bytes as utf8 while indexing.


Also we should review whether we really need all our catalog indexes. 
For example right now we have id and getId which is just silly.



How do you guys plan to organize the sprint teams? My idea would be to
break down the PLIPs into single tasks to make it easy for people to get
started. Liz added github issues for the skins removal:

https://github.com/plone/Products.CMFPlone/issues?labels=PLIP+13260%3A+Remove+CMFstate=open

Should we do the same or do we have a dedicated tracker for the sprint?


I think adding small tasks to the CMFPlone tracker is good, even if 
there is a separate tracker for the sprint.

___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] Arnhem Sprint PLIP Champions Wanted!

[David Glick (Plone)]

On 11/5/13, 9:40 AM, Rok Garbas wrote:

Quoting David Glick (Plone) (2013-11-05 18:15:21)

On 11/4/13, 10:36 PM, Timo Stollenwerk wrote:

I also started to write a PLIP for the removal of selected portal tools:

https://dev.plone.org/ticket/13770

Since I won't be able to attend the full sprint (only two days) it might
make sense if somebody else would champion that PLIP (at least for the
sprint). @David?

Yep, I can be the champion for the tool removal.


Another PLIP that I would like to see is to move all catalog indexes in
Plone to use unicode instead of utf-8 encoded strings. I don't want to
add another PLIP that I personally won't have time to work on though.

+0.5. It's a good idea but it'll probably mean a lengthy upgrade step.
If we do it we should consider giving FieldIndex and KeywordIndex the
ability to automatically decode bytes as utf8 while indexing.

Also we should review whether we really need all our catalog indexes.
For example right now we have id and getId which is just silly.


if i remember correctly you've been also thinking to create ReferenceIndex
right? so we can ditch reference_catalog or not to rely on crazy z3c.relations
stuff.



Yes, the idea is to have all relations (whether defined as Archetypes 
references or z3c.relationfield relations) automatically indexed by one 
index in portal_catalog, so that you avoid the need for duplicating 
indexes and metadata in other catalogs. Also to help remove the 
Archetypes dependency that still exists in things like linkintegrity. It 
wouldn't handle the fancy transitive queries that the zc.relation 
catalog does, but it would handle simple lookup of backreferences which 
is all that we need in core. And it would let you do queries that 
involve relations and some other criteria (give me all the documents in 
the foo folder that were created less than a month ago and have a 
reference to item X)


I have a proof-of-concept implementation that needs some more work to 
integrate. (Fun fact: it was mostly written during a Seattle Plone 
gathering on Fulvio's sailboat.) If someone else is interested in 
working on it I can add some notes and post what I have to github.


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] mockup/widgets/toolbar PLIP nr. 13476

[David Glick (Plone)]

On 10/24/13, 9:39 AM, Rok Garbas wrote:

hey all,

during my last days in brasil i've pushed initial work on getting plip 13476
into coredev. since plip 13476 is quite big it would make sense to split it up,
like we already did with other plips.


1. as first i would like to merge into core all work being done in
plone.app.widgets. plip13476-mockup.cfg buildout will continue to depend on
plone.app.widgets package to the last day before release changed packages.

 base.py - only depends on lxml and new package will be created for this
 utils.py - CMFPlone # code used by AT and DX depends on getToolByName
 at.py - P.Archetypes # AT specific code
 dx.py - p.a.z3cform # DX specific code

also plone.app.widgets will never reach 2.0 version since all code after
that will be part of Plone 5.0.


+1. And I guess the actual js and css bundles go in CMFPlone?


main tasks on TODO list are (should happen in following cronological order):
  - get remaining unit/integrational tests done
  - get remaining robot tests done (we have only one example test)
  - release plone.app.widgets
  - remove collective.z3cform.datetimewidget (mostly done)
  - remove plone.formwidget.datetime
  - remove plone.formwidget.querystring
  - remove plone.formwidget.autocomplete
  - create contenttree widget (already started in mockup) and remove
plone.formwidget.contenttree
  - finish recurrencewidget in mockup and remove plone.formwidget.recurrence

anyway i'll be working on getting tests done and release plone.app.widgets
ASAP. but i would really appreaciate help on other tasks.


2. once plone.app.widgets work is merged and all tests are passing only then
i would move to include plone.app.toolbar work into coredev.

i think code from plone.app.toolbar should be moved to plone.app.layout, but
i'm open for better suggestions.

biggest change that will happen with this merge is that we will replace all
javascript with javascript that we developed in mockup. 95% of this part is
already done and once plone.app.widgets are properly merged i don't see any
bigger blocker to get plone.app.toolbar merged quickly.

when releasing plone.app.widgets i'll be also releasing plone.app.toolbar to
give ppl a preview what is the progress on this.



i tried to explained everything in much detail as i could remember but please
ask if something was not explained as it should be. main goal of this 2 step
merge is mostly to keep jenkins job happy and green and to not interfere with
any other plip work.

If we first add the widgets bundle to CMFPlone, then we can work on 
converting the widgets in Archetypes and plone.app.z3cform one widget at 
a time in smaller pull requests, rather than needing one 
mega-PLIP-branch. What do you think?  I know I personally would be 
motivated to work on the reference widget/plone.formwidget.contenttree 
replacement, because I am starting to look into converting portlets to 
z3c.form, and I need it for that.


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] collective.elephantvocabulary

[David Glick (Plone)]

On 10/24/13, 10:18 AM, Rok Garbas wrote:

with plone.app.event we also added new dependency
collective.elephantvocabulary. i'm the author of this package and what this
package does is extends a bit zope.schema's vocabulary. also if there is
plone.app.registry present it also makes use of that.

now at the time i needed this and when working on plone.app.event project also
plone.app.event benefit from this functionality and still does.

introducing yet another package makes very little sense in my opinion and
functionality wise this package could easily fit into plone.app.vocabularies
package.

would somebody object this move? (to move c.elephantvocabulary code into
p.a.vocabularies)

also if somebody can comeup with some more descriptive name i'm all ears :)


I think we can avoid adding this functionality altogether.

As I understand it, the package exists to make sure that if a term is 
removed from a vocabulary but there is existing data that stores that 
term's value, the existing data can still be edited without losing the 
stored value. z3c.form has added a different solution to the same 
problem, and is the form library we're standardizing on for Plone 5, so 
I don't think we should add another solution to plone.app.vocabularies.

___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

[Framework-Team] please vote on merging PLIP 13679

[David Glick (Plone)]

Hi framework team,
Can you all please vote on whether PLIP 13679 (automatic CSRF 
protection) is ready to merge?


Also please make sure you have recorded your vote on PLIP 13091 
(multilingual). I just updated the ticket to reflect the current plan 
based on my discussion with Ramon in Brazil.


And remember we have a meeting in 2 hours.

cheers,
David
___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] Middleware render on Plone 5

[David Glick (Plone)]

On 10/8/13 1:38 PM, Ramon Navarro Bosch wrote:
I've been sprinting today on the middleware rendering subject and this 
are my points to be discussed :


* Without direct access (with diazo) to Plone we will not be able to 
access @@manage-viewlets so we will need some control panel that 
decides which viewlet should be rendered on the middleware for diazo ?


I guess you are asking how to disable some viewlets that are not used in 
the theme, so that you can avoid the overhead of rendering them?


We can disable diazo for the manage-viewlets page. But it may be better 
to have a more conventional control panel where you can click a checkbox 
to show/hide each viewlet.


* The main goal I'm looking for is reducing the amount of things that 
are beeing rendered on plone before diazo. So my idea is to implement 
a IMainTemplate view that renders the main template depending on the 
viewlet managers that are active. Also in case it's a browser request 
from toolbar ( we can mark with some interface ) render only the 
content part with some possible viewlets managers before or after. 
Toolbar is only rendering the content of the edit page and doesn't 
make any sense to render all the page for this requests.


The current main_template already has the ajax_request flag to disable 
rendering of most viewlet managers. Do we really need something new?




* So we render the viewlets that have been said to be rendered, the 
view of the content and the portlets ( we could integrate plone_layout 
and plone view on this main_template view ). The question is how we 
show it:


* We need to find a a way that it's easy for themeeditor to map
the content to the diazo theme. Maybe a list of elements
(viewlets/portels/contents) instead of seeing the actual sunburst
view.

* We need to discard XML for the user content as they can write
non valid XML and we need to render the view of the content with
the custom browser view.

* We need to use the same id's we have now on the main_template to
provide BBB on diazo themes ?

* What about js registry and css registry ? we need to render the
bunch of js/css that are needed on addons and the one's that are
conditionals (logged in and aren't not on toolbar)


I'm thinking on small steps that are affortable to provide a better 
diazo only concept on Plone 5.


We did some tests, creating a main_template-remove on 
Products.CMFPlone and did some performance tests having a bit better 
performance.


If somebody knows some work done on the same direction, or have some 
time, I'll try to sprint on it tomorrow also so I can write a PLIP.


Ramon


2013/10/2 Johannes Raggam d...@programmatic.pro 
mailto:d...@programmatic.pro


On Die, 2013-10-01 at 15:58 +0100, Martin Aspeli wrote:
 On 1 October 2013 14:03, Ramon Navarro Bosch ramon...@gmail.com
mailto:ramon...@gmail.com
wrote:
 Since we are moving to Diazo I have the bad feeling that rendering
twice the page is a waste of energy and a possible
missunderstanding for
integrators / developers ( we will have the frontend, the backend of
widgets, the native rendering ... )
 During these days in Brazil, we've been discussing if it's possible
to change the main_template to export the structure of plone
instead of
a rendered page, different sections with the viewlets, with the
portlets, the content,  and on diazo rules it would be much easier
to define the rules. As right now is the moment to discuss about this
subject(diazo theme is really in early step and plone5 is a possible
target to change this), my idea is to talk about it today at FWT
meeting
if it's ok with you.
 So to check my understanding: you are saying main_template exposes
something very simple, e.g. a pile of divs with sensible ids, and then
Diazo makes it visually appealing?
 If so, that makes sense to me, at least once we have good out
of the
box Diazo themes.

What if we expose each of these building blocks via HTTP and let diazo
fetch them via the href attribute?

This way we can also provide alternative dynamic user interfaces,
where
we fetch the contents for a page via Javascript AJAX calls.

Johannes


--
programmatic  web development
di(fh) johannes raggam / thet
python plone zope development
mail: off...@programmatic.pro mailto:off...@programmatic.pro
web: http://programmatic.pro
http://bluedynamics.com




--
Ramon a.k.a bloodbare


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] plone.app.event and it's portlets issue

[David Glick (Plone)]

On 10/3/13 7:38 PM, Rok Garbas wrote:

Quoting Johannes Raggam (2013-10-01 16:44:58)

Hey FWT!

I need some advice on how to handle a problem with plone.app.event:

In plone.app.event there is a ploneintegration submodule, profile and
setuptools extra. This is primarily needed because plone.app.event
registers the portlets.Events and portlets.Calendar under the same name
as plone.app.portlets. Therefore it needs to unregister them with
z3c.unconfigure for versions of plone.app.event, where those portlets
aren't removed - otherwise I get some zcml double-registration errors on
Zope startup.

The ploneintegration setuptools extra has to be included manually for
versions of Plone  5.

Now, while integrating plone.app.event with plone.app.contenttypes,
which should work for Plone 4.2 and up, I don't want to depend on the
ploneintegration extra if possible. This pulls in the z3c.unconfigure
package, which has to version-fixed to 1.0.1 - otherwise it would
pull-in zope.component 3.8, which is not a Plone 4.x core dependency
version and not backwards compatible.

Ideally I would get rid of the ploneintegration package.

I see these options:

1) Releasing plone.app.portlets 2.5a1, where portlets.Calendar and
portlets.Events are already removed. This way, I can depend on this
version as a minimum requirement for plone.app.event and the portlets
double-registration issue isn't any more. Con: For other versions of
Plone 4.x, plone.app.portlets has to be maintained in it's 2.4.x branch.

2) Registering the portlets in plone.app.event under different names.
Pro: no zcml double-registration issues and no need to remove the
portlets.Calendar and portlets.Events from plone.app.portlets (altough,
they won't make much sense there when plone.app.event is merged into
Plone-core). Drawback: No seamless Upgrade-path and it breaks existing
installations (there are already some installations by different
integrators).

3) Including a hard-dependency on z3c.unconfigure in plone.app.event and
doing the unregistration if
plone.app.portlets.portlets.calendar.Renderer can be imported via a
zcml:conditional.


I prefer the first option, because it's quite straight-forward.
Can someone make a release, if you agree?

 From pypi:
Package Index Owner: optilude, wichert, hannosch, esteele, maurits,
malthe, evilbungle, laurencerowe, davisagli, timo, vangheem
Package Index Maintainer: do3cc


i would go for option number 1.




Released!
___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] reminder. framework team meeting today!

[David Glick (Plone)]

Is there anyone who could review the work Myroslav Opyr has been doing 
on the implementation of PLIP 13350? (see 
https://dev.plone.org/ticket/13706)  I have been meaning to do it but I 
don't think I'll find time before the Plone conference.


I'm going to have a look at Nathan's CSRF PLIP this morning.

On 9/17/13 8:00 AM, Rok Garbas wrote:

just to remind you that we have meeting today.

--
Rok Garbas - http://www.garbas.si
___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

[Framework-Team] date widgets for Plone 5

[David Glick (Plone)]

Currently we have way too many date and datetime widgets in core:
- Archetypes
- z3c.form
- collective.z3cform.datetimewidget (added as an override of the default 
z3c.form one by plone.app.z3cform; uses jquerytools date picker)

- plone.formwidget.datetime (added by plone.app.event; uses jquerytools)
- plone.app.widgets (uses pickadate)

The latter 2 offer both Archetypes and Dexterity compatible widgets, and 
we should standardize on one of them for Plone 5. Rok and Johannes, can 
you make a recommendation?

___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] date widgets for Plone 5

[David Glick (Plone)]

On 9/17/13 4:16 PM, Johannes Raggam wrote:

plone.app.widgets.

i'll check this out at the buschenschanksprint this week. also
plone.formwidget.recurrence should become a plone.app.widgets pattern.


Great!


then we have to deprecate plone.formwidget.* for plone.app.event.
i'm unsure about how to do with the 1.0 release of plone.app.event.
switching from p.formwidget.* to p.a.widgets seems too big for a change
from a 1.0RC version to a 1.0 final version of plone.app.event.
what do you think?


So release plone.app.event 1.0 targeting Plone 4.3, and then work on the 
switch to plone.app.widgets for plone.app.event 2.x, targeting Plone 5?


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] plone.app.event core integration related questions

[David Glick (Plone)]

On 9/3/13 3:01 AM, Johannes Raggam wrote:

Hi FWT,

I'm thinking about implications of the integration of plone.app.event in
Plone core and need to have some feedback:


1) Products.CMFPlone.CalendarTool was only used by the calendar portlet
and is now obsolete. Should we better remove or deprecate that tool?


Remove in 5.0. Once that's complete, we can add deprecation warnings in 
Plone 4 if we want.



2) With the removal of the CalendarTool, we can also drop the dependency
on Products.CMFCalendar. Remove or deprecate?


Remove.


3) plone.app.event provides it's own event-settings control panel.
plone.app.controlpanel's calendar-controlpanel isn't needed anymore.
Remove or deprecate?


Remove.


4) The Products.CMFPlone.skins.plone_content.event_view.pt skin template
can be moved to plone_deprecated. OK?


Maybe it should go in a skin layer in ATContentTypes.


5) The calendar and event portlets are now moved from plone.app.portlets
to plone.app.event and registered under the same name, making them a
drop-in replacement for the old ones. This should give us a smooth
upgrade path, especially because there are still the calendar and event
modules in plone.app.portlets.portlets, which import plone.app.event's
portlet Assignment classes. Otherwise the persistent Assignments would
break.
(I think we agreed on this and it has some good sides but it gives me
regulary some headache when maintaining Plone 4.x compatibility (because
of the need of having the ploneintegration module and profile). I'm just
sayin'...)
I'm going to remove the calendaring related tests from
plone.app.portlets (relevant tests were moved to plone.app.event), OK?


+1.


There are still some unresolved issues, wich are better to fix later on:

- Moving/Removing of
   Products.CMFPlone.skins.plone_3rdParty.jscalendar
   Products.CMFPlone.skins.plone_ecmascript/calendar_formfield.js
   Products.CMFPlone.skins.plone_forms/calendar_popup.pt
   Products.CMFPlone.skins.plone_templates/calendar_macros.pt

- Creating a Mockup/plone.app.widgets pattern for
jquery.recurrenceinput.js.

- Depending on plone.app.widgets and possibly dropping the dependency on
plone.formwidget.datetime and plone.formwidget.recurrence.

Right, every place in Plone that uses a date picker widget should use 
the same one. :)


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

[Framework-Team] reminder: meeting today

[David Glick (Plone)]

Please remember to look over the PLIPs in the Submitted section of the 
PLIP status spreadsheet, leave any comments you have in trac, and vote 
on whether to accept the proposal for implementation.

thanks,
David
___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

[Framework-Team] strategic sprint designation for Arnhem sprint

[David Glick (Plone)]

Hi team,
There is a topic I forgot to bring up in our meeting earlier today. 
Maarten Kling from Four Digits contacted me to say that Four Digits is 
organizing a sprint in Arnhem for mid-November, and wondered if the 
Framework Team would be willing to recommend it to the board as a 
strategic sprint.


I will be +1 on that as long as the sprint organizers can supply a plan 
for what will be worked on at the sprint that fits with our current 
ideas of what needs to be implemented for Plone 5. Maarten, is there a 
particular plan for the sprint topic(s)?  If not, maybe the FWT can 
recommend some things that we know need more work for Plone 5.

best,
David

p.s. Maarten please join the framework team list before replying or I 
think your post will get moderated.

___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] Fwd: applying for framework team

[David Glick (Plone)]

+1

On 7/19/13 3:30 PM, Steve McMahon wrote:


On Fri, Jul 19, 2013 at 1:42 PM, Rok Garbas r...@garbas.si 
mailto:r...@garbas.si wrote:


 Forwarded message from Rok Garbas (2013-06-27 15:22:19):
  hi,
 
  i've been thinking on helping fwt in the past but never really
had enough time
  to send this email (others ppl call this lazyness). i've been
around plone for
  few years and last yeas i've also started contributing to
plone core on more
  regular basis.
 
  main reason i want to join fwt is to make sure that javascript
that is going to
  be added to plone is of proper quality.
 
  there is ton of old javascript code that is not tested and is
working only
  because probably some developers sold part of their soul to
devil. i can accept
  and agree with any style of programing and library that is
going to be added to
  plone, but not untested code in javascript i can never. by
can not accept
  i ment help plippers help/guide them to write tests for their
javascript code.
 
  i'm only mentioning javascript becuase i see it as a thing i
can help most
  with. i'll be happy reviewing other plips as well.
 
 
  tnx and may your javascript be tested!
 
 
  --
  Rok Garbas - http://www.garbas.si




___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

[Framework-Team] reminder: get your reviews done

[David Glick (Plone)]

Hi team, friendly reminder to get your PLIP reviews done:

13419: Ross, Guido Stevens
12344: Johannes, Franco
13270: Craig, Andrzej
12253: David, Ross
10359: Andrzej, Ross

thanks,
David
___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

[Framework-Team] prep for meeting

[David Glick (Plone)]

Hi team,
If you have a chance before our meeting today, please go to the PLIP 
worksheet and do the following:

- make sure you've recorded a vote for the PLIPs in Submitted
- make sure you know the status of PLIPs you're the champion for under 
In Process

- sign up to do reviews of the PLIPs under Under Review
thanks,
David
___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] Farewell

[David Glick (Plone)]

Hi Marcio,
It's certainly understandable that planning the conference would take 
considerable time and energy! I have appreciated your contributions to 
the team and hope you'll consider participating again sometime in the 
future.

See you in Brazil,
David

On 1/20/13 7:32 AM, Marcio Mazza wrote:

Dear FWT members,

Since the invitation to join the FWT, at the first day in Arnhem, some 
important changes happened to my priorities and to my use of time and 
energy.


One of them is the fact that my city will host the next Plone 
Conference and I am one of the organizers of the effort. I have come 
to the conclusion that this will take a whole lot more work than I 
thought. That's a priority to me now: that we all have a great 
conference. For this and some other personal reasons I have to leave 
this team I just joined.


I'd like to thank you for this short period together. I was greatly 
pleased to participate, even for a short time.


Thank you all. Hope to see you here in Brazil in a few months.

Marcio.



___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

[Framework-Team] Reminder: framework team meeting on Dec. 11

[David Glick (Plone)]

Here's a reminder of your action items; please try to make progress on 
these:

- Eric is working on 4.2.3 and 4.3b1 releases.
- If you're championing a PLIP, make sure you know its status.
- Craig, Marcio, and Franco are reviewing PLIP 13091 
(plone.app.multilingual)

- Craig and I are reviewing PLIP 10886 (plone.app.event)

best,
David
___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

[Framework-Team] Fwd: Fwd: I'd like to join the Framework team!

[David Glick (Plone)]

Nejc wasn't able to post to the framework-team list, so I'm forwarding 
this for him.



*From:* Nejc Zupan nejc.zu...@gmail.com mailto:nejc.zu...@gmail.com
*Date:* October 2, 2012 11:56:03 PM PDT
*To:* David Glick (GW) davidgl...@groundwire.org 
mailto:davidgl...@groundwire.org

*Subject:* *I'd like to join the Framework team!*

--
Hi all,

I already talked with Liz about it and seeing David's latest email I 
decided it's time to jump in

and send an email.

My experience with Plone goes back to 2006 when I started poking a 
local student organization's
website, together with Rok Garbas. We went on to organize a few 
student workshops and such and
in since 2007 I've been running NiteoWeb Ltd, a Plone consultancy from 
Slovenia. I've been
a core contributor since 2010, though the number of my commits is 
kinda low and I'd like to change
that. Above all, I attended and co-organized many sprints, I believe 
I'm currently at around number
15 or so. One of my main goals for 2012 is to be more active in the 
community and to give back to
Plone. Joining the Framework team is in my mind the perfect way to 
start doing this.



That's it, I'll keep it short, let's get rocking!
Nejc Zupan



___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] plip12908 improved syndication merged

[David Glick]

IMHO, probably https://plone.org/documentation/manual/developer-manual

(I know overall this manual needs a lot of work, but all the more reason to
try to add things to it in a well-structured way when we're documenting
PLIPs. There is also the collective docs, of course, but that seems like
it's bound to inevitably be more of a sprawling cookbook useful as a
reference than a place to get a well-organized overview of how Plone can be
customized.)

And end-user documentation related to syndication settings can go in the
user manual: https://plone.org/documentation/manual/plone-4-user-manual

Make sure you label the new stuff as applying to Plone 4.3.

David

On Sat, Sep 8, 2012 at 3:37 PM, Nathan Van Gheem vangh...@gmail.com wrote:

 Where should I write documentation on extending the new syndication
 framework?

 On Sat, Sep 8, 2012 at 5:33 PM, Nathan Van Gheem vangh...@gmail.comwrote:

 Hi Everyone,

 I've merged this plip into master if anyone wants to give it a go.


 -Nathan



 ___
 Framework-Team mailing list
 framework-t...@lists.plone.org
 https://lists.plone.org/mailman/listinfo/plone-framework-team


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

[Framework-Team] Plone framework team meeting minutes, May 8

[David Glick]

May 8 Framework team meeting
Present: Eric Steele, Alec Mitchell, David Glick, Liz Leddy; Absent: 
Craig Haynal, Ross Patterson, Martijn Pieters, Laurence Rowe, Rob Gietema.


- There has a been a pattern of the European team members missing 
meetings as of late. Do we need to reschedule the call for a better 
time? Is it time to issue a call for new team members and ask inactive 
ones to step down?

- Plone 4.2 update: Eric is releasing rc1 today!
- With the finalization of Plone 4.2, we have set cutoff dates for Plone 
4.3 PLIPs:

  1. Implementations should be done by May 31.
  2. Reviews and merging should be done by June 11.
  3. PLIPs not meeting these deadlines will be considered for 4.4.
- PLIP 12235 (batching): Merged.
- PLIP 11773 (Dexterity): Merged.
- PLIP 11838 (z3c.form portlets): Still ready for merge.
- PLIP 12110 (ignoring accents in search): Still ready for merge.
- PLIP 12227 (theme editor): A group from UCLA has volunteered to help 
review it. Martin is finishing tweaks.
- PLIP 12266 (css class for portlets): Alec has asked implementers for a 
review buildout.
- PLIP 12844 (update TinyMCE): David tried to review but had trouble; 
has asked for instructions on getting it set up to review.
- PLIP 10886 (plone.app.event): We're assuming this one won't make 4.3 
at this point. But we like surprises.

- PLIP 12350 (jquery ui): Eric will check in with Steve.
- PLIP 12776 (remove kupu): Done. (But needs to be documented.)
- PLIP 12870 (PlonePAS portrait updates): Approved for core. Liz is 
champion.
- Eric asked whether people are using inline editing. If we can drop it, 
it will simplify the task of removing our use of KSS.




--  
David Glick
Web Developer
davidgl...@groundwire.org
206.286.1235x32

Are you engaging? Find out! Use our free engagement benchmarking tool.

http://groundwire.org/labs/engagement-strategy/diy-benchmarking-survey


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team

Re: [Framework-Team] Collections portlets

[David Glick]

On 4/1/12 4:04 PM, Eric Steele wrote:
So now that we've got plone.app.collection in 4.2, how do we want to handle 
collections portlets?

We currently ship with plone.portlet.collection. plone.app.collection adds its 
own, largely the same (though missing some of the more recent features/fixes 
added to the other).

Should the p.a.collection version be made the default (and updated for parity 
with p.portlet.collection) or should p.portlet.collection be updated to handle 
the newer collections (and remove the portlet functionality from 
p.a.collection)?

Seems like the latter would be the simpler option.

I made some progress toward supporting new-style collections in 
plone.portlet.collection (by adding a backward-compatible queryCatalog method 
to the collection class in plone.app.collection...really not too hard except 
for figuring out how to get non-IContentListing-wrapped results out of the 
query builder). Remaining tasks:
- The code path for when the 'random order' option is selected is currently 
broken. To fix it the BBB queryCatalog needs to accept a sort_on parameter and 
pass it through to where the query is constructed.
- The plone.portlet.collection functional test needs to be updated to create a 
new-style collection instead of a Topic.
- We need to figure out what to do with the unnecessary portlet in 
plone.app.collection. (There have been releases of plone.app.collection so it 
doesn't seem like we should just remove it. A migration will be a pain since 
it'll have to find all the portlet assignments to update them. If the 2 portlet 
assignment classes have the same attributes maybe we can use a module alias, 
but I haven't evaluated that.)



David Glick
Web Developer
davidgl...@groundwire.org
206.286.1235x32


[http://gw-logo.s3.amazonaws.com/gw-email-signature.png]


GiveBIG is coming! Mark your calendar for May 2 and get ready to give big to 
Groundwirehttp://www.seattlefoundation.org/npos/Pages/Groundwire.aspx as part 
of this community-wide day of giving.


___
Framework-Team mailing list
framework-t...@lists.plone.org
https://lists.plone.org/mailman/listinfo/plone-framework-team