plone.api – back to the future?

[Malthe Borch-2]

I have been seeing some checkins on Github to a `plone.api` package.

Where's the PLIP for this? Zope tried to do the same very thing with
"zapi" and it's been deprecated since Zope 3.5.

I think there's a two camps in terms of where and how Plone's "app"
code should live, i.e. fully split up into atoms of responsibility
with the `plone.app.*` family (the current state of affairs; this is
the majority), or as a single, or a couple of major eggs, e.g. `Plone`
(wishful thinking; the minority).

Where does this new API fit in? Arguably in the second camp, because
it's got to have dependencies to a great many `plone.app.*` eggs
and/or CMF products. If you update a dependency, you need to update
the API. It's the "mother egg" and her dependencies are strong.

I understand the idea of approaching the problem of Plone's
problematic codebase from the outside, taming the beast with clean,
modernized wrappers, but it doesn't make much sense in terms of the
dependency graph -and- it's a step away from eventually cleaning up
and refactoring the codebase altogether:

 – get rid of the very deep class hierarchy of Plone-objects;
 – lose code weight; currently it's likely an inverse 80/20 rule (20%
code used by 80% installations).
 – refactor and improve existing code so that it fits the bill as an "API".

Add to this that  existing third party code will only very slowly or
never migrate to the API.

\malthe

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[J-C Brand]

On Sun, 2012-02-26 at 09:39 +0100, Malthe Borch wrote:
> I have been seeing some checkins on Github to a `plone.api` package.
>
> Where's the PLIP for this? Zope tried to do the same very thing with
> "zapi" and it's been deprecated since Zope 3.5.

> I think there's a two camps in terms of where and how Plone's "app"
> code should live, i.e. fully split up into atoms of responsibility
> with the `plone.app.*` family (the current state of affairs; this is
> the majority), or as a single, or a couple of major eggs, e.g. `Plone`
> (wishful thinking; the minority).
>
> Where does this new API fit in? Arguably in the second camp, because
> it's got to have dependencies to a great many `plone.app.*` eggs
> and/or CMF products. If you update a dependency, you need to update
> the API. It's the "mother egg" and her dependencies are strong.

Products.CMFPlone currently depends on 103 packages, so much of the
heavy lifting of tracking dependencies and maintaining compatibility is
already being done there.

Would an API need to depend on packages outside of these 103 CMFPlone
dependencies?

> I understand the idea of approaching the problem of Plone's
> problematic codebase from the outside, taming the beast with clean,
> modernized wrappers, but it doesn't make much sense in terms of the
> dependency graph -and- it's a step away from eventually cleaning up
> and refactoring the codebase altogether:
>
>  – get rid of the very deep class hierarchy of Plone-objects;

How would an API implemented by wrappers hinder efforts to get rid of
the deep class hierarchy?

For integrators who use the API, the changing of classes behind it would
be less disruptive, since the API stays constant.

>  – lose code weight; currently it's likely an inverse 80/20 rule (20%
> code used by 80% installations).

AFAIU, the idea of a Plone API is to provide a consistent, pythonic way
of doing CRUD operations that integrators will do over and over again.

People are not going to stop changing workflow states or setting member
properties.

>  – refactor and improve existing code so that it fits the bill as an "API".

A laudable goal, but very difficult (if not impossible) to achieve when
using disparate packages from hundreds of authors.

> Add to this that existing third party code will only very slowly or
> never migrate to the API.

This is true, but is it a showstopper?

Unmaintainted 3rd party code will in any case become unusable as Plone
evolves.

JC





------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[ajung]

To make it short...my 2 cents on plone.api. I really love the idea from the integrators point of view (although I know how to use the real API methods)...I would love to see the same API being exposed as a web-service. wsapi4plone is already doing a good job right now..having a consistent  programmatic API and a consistent web-service API together in one would be a cool addition for integrators.

-aj

J-C Brand wrote

On Sun, 2012-02-26 at 09:39 +0100, Malthe Borch wrote:
> I have been seeing some checkins on Github to a `plone.api` package.
>
> Where's the PLIP for this? Zope tried to do the same very thing with
> "zapi" and it's been deprecated since Zope 3.5.

> I think there's a two camps in terms of where and how Plone's "app"
> code should live, i.e. fully split up into atoms of responsibility
> with the `plone.app.*` family (the current state of affairs; this is
> the majority), or as a single, or a couple of major eggs, e.g. `Plone`
> (wishful thinking; the minority).
>
> Where does this new API fit in? Arguably in the second camp, because
> it's got to have dependencies to a great many `plone.app.*` eggs
> and/or CMF products. If you update a dependency, you need to update
> the API. It's the "mother egg" and her dependencies are strong.

Products.CMFPlone currently depends on 103 packages, so much of the
heavy lifting of tracking dependencies and maintaining compatibility is
already being done there.

Would an API need to depend on packages outside of these 103 CMFPlone
dependencies?

> I understand the idea of approaching the problem of Plone's
> problematic codebase from the outside, taming the beast with clean,
> modernized wrappers, but it doesn't make much sense in terms of the
> dependency graph -and- it's a step away from eventually cleaning up
> and refactoring the codebase altogether:
>
>  – get rid of the very deep class hierarchy of Plone-objects;

How would an API implemented by wrappers hinder efforts to get rid of
the deep class hierarchy?

For integrators who use the API, the changing of classes behind it would
be less disruptive, since the API stays constant.

>  – lose code weight; currently it's likely an inverse 80/20 rule (20%
> code used by 80% installations).

AFAIU, the idea of a Plone API is to provide a consistent, pythonic way
of doing CRUD operations that integrators will do over and over again.

People are not going to stop changing workflow states or setting member
properties.

>  – refactor and improve existing code so that it fits the bill as an "API".

A laudable goal, but very difficult (if not impossible) to achieve when
using disparate packages from hundreds of authors.

> Add to this that existing third party code will only very slowly or
> never migrate to the API.

This is true, but is it a showstopper?

Unmaintainted 3rd party code will in any case become unusable as Plone
evolves.

JC





------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli-3]

On 26 Feb 2012, at 12:46, ajung <[hidden email]> wrote:

> To make it short...my 2 cents on plone.api. I really love the idea from the
> integrators point of view (although I know how to use the real API
> methods)...I would love to see the same API being exposed as a web-service.
> wsapi4plone is already doing a good job right now..having a consistent
> programmatic API and a consistent web-service API together in one would be a
> cool addition for integrators.
>

I like the idea too. It solves a big problem we have with API discoverability.

However, API design is hard and a bad API is worse than none at all in this case. I'd like to make sure we take documentation and review if this very seriously before any release. I'd like to volunteer to help with this type of review.

Martin

> -aj
>
>
> J-C Brand wrote
>>
>> On Sun, 2012-02-26 at 09:39 +0100, Malthe Borch wrote:
>>> I have been seeing some checkins on Github to a `plone.api` package.
>>>
>>> Where's the PLIP for this? Zope tried to do the same very thing with
>>> "zapi" and it's been deprecated since Zope 3.5.
>>
>>> I think there's a two camps in terms of where and how Plone's "app"
>>> code should live, i.e. fully split up into atoms of responsibility
>>> with the `plone.app.*` family (the current state of affairs; this is
>>> the majority), or as a single, or a couple of major eggs, e.g. `Plone`
>>> (wishful thinking; the minority).
>>>
>>> Where does this new API fit in? Arguably in the second camp, because
>>> it's got to have dependencies to a great many `plone.app.*` eggs
>>> and/or CMF products. If you update a dependency, you need to update
>>> the API. It's the "mother egg" and her dependencies are strong.
>>
>> Products.CMFPlone currently depends on 103 packages, so much of the
>> heavy lifting of tracking dependencies and maintaining compatibility is
>> already being done there.
>>
>> Would an API need to depend on packages outside of these 103 CMFPlone
>> dependencies?
>>
>>> I understand the idea of approaching the problem of Plone's
>>> problematic codebase from the outside, taming the beast with clean,
>>> modernized wrappers, but it doesn't make much sense in terms of the
>>> dependency graph -and- it's a step away from eventually cleaning up
>>> and refactoring the codebase altogether:
>>>
>>> – get rid of the very deep class hierarchy of Plone-objects;
>>
>> How would an API implemented by wrappers hinder efforts to get rid of
>> the deep class hierarchy?
>>
>> For integrators who use the API, the changing of classes behind it would
>> be less disruptive, since the API stays constant.
>>
>>> – lose code weight; currently it's likely an inverse 80/20 rule (20%
>>> code used by 80% installations).
>>
>> AFAIU, the idea of a Plone API is to provide a consistent, pythonic way
>> of doing CRUD operations that integrators will do over and over again.
>>
>> People are not going to stop changing workflow states or setting member
>> properties.
>>
>>> – refactor and improve existing code so that it fits the bill as an
>>> "API".
>>
>> A laudable goal, but very difficult (if not impossible) to achieve when
>> using disparate packages from hundreds of authors.
>>
>>> Add to this that existing third party code will only very slowly or
>>> never migrate to the API.
>>
>> This is true, but is it a showstopper?
>>
>> Unmaintainted 3rd party code will in any case become unusable as Plone
>> evolves.
>>
>> JC
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> Plone-developers mailing list
>> Plone-developers@.sourceforge
>> https://lists.sourceforge.net/lists/listinfo/plone-developers
>>
>
>
> --
> View this message in context: http://plone.293351.n2.nabble.com/plone-api-back-to-the-future-tp7318823p7319176.html
> Sent from the Core Developers mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Domen Kožar]

There are few people at the sprint working on design docs for review

and idea was discussed on the last few successful drinkups.

I guess code is there only for experimenting with underlying implementation.

Currently the main blocker is a clear vision of goals plone.api is trying achieve.

On Sun, Feb 26, 2012 at 2:48 PM, Martin Aspeli <[hidden email]> wrote:

On 26 Feb 2012, at 12:46, ajung <[hidden email]> wrote:

> To make it short...my 2 cents on plone.api. I really love the idea from the
> integrators point of view (although I know how to use the real API
> methods)...I would love to see the same API being exposed as a web-service.
> wsapi4plone is already doing a good job right now..having a consistent
> programmatic API and a consistent web-service API together in one would be a
> cool addition for integrators.
>

I like the idea too. It solves a big problem we have with API discoverability.

However, API design is hard and a bad API is worse than none at all in this case. I'd like to make sure we take documentation and review if this very seriously before any release. I'd like to volunteer to help with this type of review.

Martin

> -aj
>
>
> J-C Brand wrote
>>
>> On Sun, 2012-02-26 at 09:39 +0100, Malthe Borch wrote:
>>> I have been seeing some checkins on Github to a `plone.api` package.
>>>
>>> Where's the PLIP for this? Zope tried to do the same very thing with
>>> "zapi" and it's been deprecated since Zope 3.5.
>>
>>> I think there's a two camps in terms of where and how Plone's "app"
>>> code should live, i.e. fully split up into atoms of responsibility
>>> with the `plone.app.*` family (the current state of affairs; this is
>>> the majority), or as a single, or a couple of major eggs, e.g. `Plone`
>>> (wishful thinking; the minority).
>>>
>>> Where does this new API fit in? Arguably in the second camp, because
>>> it's got to have dependencies to a great many `plone.app.*` eggs
>>> and/or CMF products. If you update a dependency, you need to update
>>> the API. It's the "mother egg" and her dependencies are strong.
>>
>> Products.CMFPlone currently depends on 103 packages, so much of the
>> heavy lifting of tracking dependencies and maintaining compatibility is
>> already being done there.
>>
>> Would an API need to depend on packages outside of these 103 CMFPlone
>> dependencies?
>>
>>> I understand the idea of approaching the problem of Plone's
>>> problematic codebase from the outside, taming the beast with clean,
>>> modernized wrappers, but it doesn't make much sense in terms of the
>>> dependency graph -and- it's a step away from eventually cleaning up
>>> and refactoring the codebase altogether:
>>>
>>> – get rid of the very deep class hierarchy of Plone-objects;
>>
>> How would an API implemented by wrappers hinder efforts to get rid of
>> the deep class hierarchy?
>>
>> For integrators who use the API, the changing of classes behind it would
>> be less disruptive, since the API stays constant.
>>
>>> – lose code weight; currently it's likely an inverse 80/20 rule (20%
>>> code used by 80% installations).
>>
>> AFAIU, the idea of a Plone API is to provide a consistent, pythonic way
>> of doing CRUD operations that integrators will do over and over again.
>>
>> People are not going to stop changing workflow states or setting member
>> properties.
>>
>>> – refactor and improve existing code so that it fits the bill as an
>>> "API".
>>
>> A laudable goal, but very difficult (if not impossible) to achieve when
>> using disparate packages from hundreds of authors.
>>
>>> Add to this that existing third party code will only very slowly or
>>> never migrate to the API.
>>
>> This is true, but is it a showstopper?
>>
>> Unmaintainted 3rd party code will in any case become unusable as Plone
>> evolves.
>>
>> JC
>>
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Virtualization & Cloud Management Using Capacity Planning
>> Cloud computing makes use of virtualization - but cloud computing
>> also focuses on allowing computing to be delivered as a service.
>> http://www.accelacomm.com/jaw/sfnl/114/51521223/
>> _______________________________________________
>> Plone-developers mailing list
>> Plone-developers@.sourceforge
>> https://lists.sourceforge.net/lists/listinfo/plone-developers
>>
>
>
> --
> View this message in context: http://plone.293351.n2.nabble.com/plone-api-back-to-the-future-tp7318823p7319176.html
> Sent from the Core Developers mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Laurence Rowe]

On 26 February 2012 14:48, Martin Aspeli <[hidden email]> wrote:

>
>
> On 26 Feb 2012, at 12:46, ajung <[hidden email]> wrote:
>
>> To make it short...my 2 cents on plone.api. I really love the idea from the
>> integrators point of view (although I know how to use the real API
>> methods)...I would love to see the same API being exposed as a web-service.
>> wsapi4plone is already doing a good job right now..having a consistent
>> programmatic API and a consistent web-service API together in one would be a
>> cool addition for integrators.
>>
>
> I like the idea too. It solves a big problem we have with API discoverability.
>
> However, API design is hard and a bad API is worse than none at all in this case. I'd like to make sure we take documentation and review if this very seriously before any release. I'd like to volunteer to help with this type of review.

We already have the @@context_state and @@portal_state views from
plone.app.layout along with @@folderListing from
plone.app.contentlisting. Rather than create a whole new API, I think
it's important to build on these, perhaps adding further views along
similar lines, and making them more easily reachable from pure python
code. Being views makes them easy to use from page templates.

Also note that getSite() does not always return the portal object
itself. KSS views setup their own site manager and I expect subsite
type add-ons like lineage will do so in the future if we enable
traversal events in Zope2/4.

Laurence

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[ajung]

I think that the concept of a view must be kept under the hood. It is ok re-using
existing views but they should be exposed through a simple API. Complexity must be hidden.  E.g. traversing a folder hierarchy should follow the natural __getitem__() API, traversal should work similar to restrictedTraverse()....setting/getting object schema attributes should follow the __setattr__, __getattr__ API while implementation specific
differences (AT mutator/accessor methods vs. AT FieldProperties vs. Dexterity) must be be hidden.

-aj

Laurence Rowe wrote

On 26 February 2012 14:48, Martin Aspeli <[hidden email]> wrote:
>
>
> On 26 Feb 2012, at 12:46, ajung <[hidden email]> wrote:
>
>> To make it short...my 2 cents on plone.api. I really love the idea from the
>> integrators point of view (although I know how to use the real API
>> methods)...I would love to see the same API being exposed as a web-service.
>> wsapi4plone is already doing a good job right now..having a consistent
>> programmatic API and a consistent web-service API together in one would be a
>> cool addition for integrators.
>>
>
> I like the idea too. It solves a big problem we have with API discoverability.
>
> However, API design is hard and a bad API is worse than none at all in this case. I'd like to make sure we take documentation and review if this very seriously before any release. I'd like to volunteer to help with this type of review.

We already have the @@context_state and @@portal_state views from
plone.app.layout along with @@folderListing from
plone.app.contentlisting. Rather than create a whole new API, I think
it's important to build on these, perhaps adding further views along
similar lines, and making them more easily reachable from pure python
code. Being views makes them easy to use from page templates.

Also note that getSite() does not always return the portal object
itself. KSS views setup their own site manager and I expect subsite
type add-ons like lineage will do so in the future if we enable
traversal events in Zope2/4.

Laurence

------------------------------------------------------------------------------
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Nejc Zupan]

Hi all,

as some of you have already noticed, work has begun on a new package: plone.api.

The main goal is, quoting it's documentation, "a simple entry point for 20% of tasks

we do 80% of the time."

At this moment we have defined which methods should be in plone.api, their parameters

and their return values: http://readthedocs.org/docs/ploneapi/en/latest/api.html

We also have a narrative documentation that guides new Plone developers through

the process of managing content, users and groups:

http://readthedocs.org/docs/ploneapi/en/latest/index.html#narrative-documentation

Note that *no code* has been written so far. All focus went into getting consensus on

what to include and how the API should look like. In this light:

Please don't go around adding/fixing API without first getting a few "+1"s from

*non-rockstar* developers. It is absolutely crucial that whatever gets into plone.api

to be understandable without years of Plone experience. I'm sure we missed some

common use-cases, let's get them out there in the open to discuss whether to include

them in plone.api.

Actual method implementations are very welcome, but we'd like the API to stay mostly

frozen unless the majority agrees on changing it. Baby steps. Use branches and

pull-requests, keep master clean. 

On behalf of Plone Konferenz sprinters,

Nejc

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[David Glick (GW)]

On 2/26/12 9:30 AM, Laurence Rowe wrote:

> On 26 February 2012 14:48, Martin Aspeli<[hidden email]>  wrote:
>>
>> On 26 Feb 2012, at 12:46, ajung<[hidden email]>  wrote:
>>
>>> To make it short...my 2 cents on plone.api. I really love the idea from the
>>> integrators point of view (although I know how to use the real API
>>> methods)...I would love to see the same API being exposed as a web-service.
>>> wsapi4plone is already doing a good job right now..having a consistent
>>> programmatic API and a consistent web-service API together in one would be a
>>> cool addition for integrators.
>>>
>> I like the idea too. It solves a big problem we have with API discoverability.
>>
>> However, API design is hard and a bad API is worse than none at all in this case. I'd like to make sure we take documentation and review if this very seriously before any release. I'd like to volunteer to help with this type of review.
> We already have the @@context_state and @@portal_state views from
> plone.app.layout along with @@folderListing from
> plone.app.contentlisting. Rather than create a whole new API, I think
> it's important to build on these, perhaps adding further views along
> similar lines, and making them more easily reachable from pure python
> code. Being views makes them easy to use from page templates.
>
> Also note that getSite() does not always return the portal object
> itself. KSS views setup their own site manager and I expect subsite
> type add-ons like lineage will do so in the future if we enable
> traversal events in Zope2/4.
>

Yes, I suggested using getUtility(ISiteRoot) instead.
David


----------
David Glick
 Web Developer
 [hidden email]
 206.286.1235x32

The Engagement Party 2012. So much more fun than the wedding reception.

http://www.npoengagementparty.com



------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[David Glick (GW)]

On 2/26/12 7:02 PM, Nejc Zupan wrote:

> Hi all,
>
> as some of you have already noticed, work has begun on a new package:
> plone.api.
>
> The main goal is, quoting it's documentation, "a simple entry point
> for 20% of tasks
> we do 80% of the time."
>
> At this moment we have defined which methods should be in plone.api,
> their parameters
> and their return values:
> http://readthedocs.org/docs/ploneapi/en/latest/api.html
>
> We also have a narrative documentation that guides new Plone
> developers through
> the process of managing content, users and groups:
> http://readthedocs.org/docs/ploneapi/en/latest/index.html#narrative-documentation
>
> Note that *no code* has been written so far. All focus went into
> getting consensus on
> what to include and how the API should look like. In this light:
>
> Please don't go around adding/fixing API without first getting a few
> "+1"s from
> *non-rockstar* developers. It is absolutely crucial that whatever gets
> into plone.api
> to be understandable without years of Plone experience. I'm sure we
> missed some
> common use-cases, let's get them out there in the open to discuss
> whether to include
> them in plone.api.
>
> Actual method implementations are very welcome, but we'd like the API
> to stay mostly
> frozen unless the majority agrees on changing it. Baby steps. Use
> branches and
> pull-requests, keep master clean.
>
>
> On behalf of Plone Konferenz sprinters,
> Nejc

Nejc,
Thanks for the overview and congrats to the sprinters; it looks like
this is off to a great start! It remains to be seen whether it will be
successful in the way zapi was not for Zope, but I am encouraged by the
approach of documentation first and preferring input from non-rockstars.
So kudos!

Some suggestions:

1. Regarding the calls like get_site_url() and get_request(), it's a bit
misleading to say that these will *always* be available. It would be
good to warn that the API is intended for use within code published by
the ZPublisher (which sets up the necessary thread locals), as opposed
to external methods or code run via bin/instance run or whatever.  
Uh...I'll let you guys translate that into non-Zope-addled-brain
language. :)

2. In Dexterity we have plone.dexterity.utils.createContentInContainer
which is similar to plone.api.content.create(). One thing I've found
very useful in the Dexterity version is the checkConstraints=False flag
if I want to add a content item and ignore the normal security checks
for whether the item is allowed (useful for example in a browser view
intended to let anonymous users submit something). Can we add something
like this to api.content.create()? If not, please at least clarify in
the documentation which API calls check permissions and which don't;
this info is currently omitted.

3. This is me channeling wiggy: For the user API, can we please use
"user_id" as the argument name instead of "username"? "Username" and
"user id" are slightly different concepts in PAS and it gets endlessly
confusing when the terminology changes from place to place. (We should
probably supporting getting a user either by user_id or login.)

4. The documentation for get_tool should include a list of the tools
that are available in a standard Plone installation.

5. Some additional things I think it would be useful to include in the
API (or at least brainstorm further). (I came up with this list by going
through the .py files of a recent client project and looking for things
that could let me remove an import statement if it were part of the
api....perhaps this is a useful exercise for others to do too.) Calls to:
   a. get a content item's UID, and to get a content item from a UID
   b. list the names of a content item's schema fields (no matter if it
is Archetypes or Dexterity) and get/set a field value by name
   c. grant or revoke a permission to a role within a particular context
   d. get the navigation root (which may be different than the site root)
   e. get/set plone.app.registry record values
   f. format a date/time or number for the current locale
   g. make sure a given path exists (i.e. add several levels of folder
structure with one call)
   h. activate, upgrade, or deactivate an add-on
   i. As Laurence and Andreas mentioned, the things currently included
in the views in plone.app.layout.globals...this also requires some
discussion of what parts of the API to make accessible to untrusted code
(i.e. page templates and TALES expressions).
   j. An is_homepage() check (this is a FAQ, how do I check if I'm on
the homepage)

One final word -- I hope others will see the new plone.api project not
as an excuse to never simplify the APIs of the existing underlying Zope
and Plone packages, but rather as an inspiration to do more of that. :)

cheers,
David



----------
David Glick
 Web Developer
 [hidden email]
 206.286.1235x32

The Engagement Party 2012. So much more fun than the wedding reception.

http://www.npoengagementparty.com



------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[matthew lange-3]

Oh my gooodness, thank you so much...this looks awesome.
Only writing python code <5% of my time, and an even smaller % for other plone bits--I am so happy to see this initiative.  

I often find myself knowing what needs to be done, but hating that I'd forgotten how to do it--or that the methods had changed, etc.--and then of course, hating writing code even more.

A few things I didn't see this in the links provided that I do think it would be good to be able to do:

list the members of a group/role (based on credentials of course)...
a simple find/union/intersect functionality--similar to the get function listed:

SomeContentCol = api.content.find(path='/somePath', type='someContentType', attributeName='someAtributeName', attributeValue='someAtributeValue')

SomeOtherContentCol = api.content.find(path='/posSomeOtherPath', type=' posSomeOtherContentType', attributeName=' posSomeOtherAtributeName', attributeValue='posSomeOtheAtributeValue') 

IntersectedContent = api.content.intersect (SomeContentCol, SomeOtherContentCol, attrNamesValuesToMatch, attrNamesValuesToFilter)

UnionedContent = api.content.union (SomeContentCol, SomeOtherContentCol, attrNamesValuesToMatch, attrNamesValuesToFilter)

Above is simplified of course, the attribute name/values would have to be arrayable...but this kind of easily readable/teachable interface for content interrogation would really go a long way toward getting me--and perhaps many others--off of SQL RDBMS...which is still my biggest holdback for total embracement of Plone.

Great work.

~mc

On Sun, Feb 26, 2012 at 7:02 PM, Nejc Zupan <[hidden email]> wrote:
>
> Hi all,
>
> as some of you have already noticed, work has begun on a new package: plone.api.
>
> The main goal is, quoting it's documentation, "a simple entry point for 20% of tasks
> we do 80% of the time."
>
> At this moment we have defined which methods should be in plone.api, their parameters
> and their return values: http://readthedocs.org/docs/ploneapi/en/latest/api.html
>
> We also have a narrative documentation that guides new Plone developers through
> the process of managing content, users and groups:
> http://readthedocs.org/docs/ploneapi/en/latest/index.html#narrative-documentation
>
> Note that *no code* has been written so far. All focus went into getting consensus on
> what to include and how the API should look like. In this light:
>
> Please don't go around adding/fixing API without first getting a few "+1"s from
> *non-rockstar* developers. It is absolutely crucial that whatever gets into plone.api
> to be understandable without years of Plone experience. I'm sure we missed some
> common use-cases, let's get them out there in the open to discuss whether to include
> them in plone.api.
>
> Actual method implementations are very welcome, but we'd like the API to stay mostly
> frozen unless the majority agrees on changing it. Baby steps. Use branches and
> pull-requests, keep master clean. 
>
>
> On behalf of Plone Konferenz sprinters,
> Nejc
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers
>

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli-3]

On 27 February 2012 06:36, David Glick <[hidden email]> wrote:

> On 2/26/12 9:30 AM, Laurence Rowe wrote:
>>
>> On 26 February 2012 14:48, Martin Aspeli<[hidden email]>  wrote:
>>>
>>>
>>> On 26 Feb 2012, at 12:46, ajung<[hidden email]>  wrote:
>>>
>>>> To make it short...my 2 cents on plone.api. I really love the idea from
>>>> the
>>>> integrators point of view (although I know how to use the real API
>>>> methods)...I would love to see the same API being exposed as a
>>>> web-service.
>>>> wsapi4plone is already doing a good job right now..having a consistent
>>>> programmatic API and a consistent web-service API together in one would
>>>> be a
>>>> cool addition for integrators.
>>>>
>>> I like the idea too. It solves a big problem we have with API
>>> discoverability.
>>>
>>> However, API design is hard and a bad API is worse than none at all in
>>> this case. I'd like to make sure we take documentation and review if this
>>> very seriously before any release. I'd like to volunteer to help with this
>>> type of review.
>>
>> We already have the @@context_state and @@portal_state views from
>> plone.app.layout along with @@folderListing from
>> plone.app.contentlisting. Rather than create a whole new API, I think
>> it's important to build on these, perhaps adding further views along
>> similar lines, and making them more easily reachable from pure python
>> code. Being views makes them easy to use from page templates.
>>
>> Also note that getSite() does not always return the portal object
>> itself. KSS views setup their own site manager and I expect subsite
>> type add-ons like lineage will do so in the future if we enable
>> traversal events in Zope2/4.
>>
> Yes, I suggested using getUtility(ISiteRoot) instead.

... which works, except I believe it doesn't get the RequestContainer
fake aq parent, so anything doing context.REQUEST with that (or a
traversed-to child of it) as the context won't work.

Martin

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[David Glick (GW)]

On 2/26/12 11:49 PM, Martin Aspeli wrote:

> On 27 February 2012 06:36, David Glick<[hidden email]>  wrote:
>> On 2/26/12 9:30 AM, Laurence Rowe wrote:
>>> On 26 February 2012 14:48, Martin Aspeli<[hidden email]>    wrote:
>>>>
>>>> On 26 Feb 2012, at 12:46, ajung<[hidden email]>    wrote:
>>>>
>>>>> To make it short...my 2 cents on plone.api. I really love the idea from
>>>>> the
>>>>> integrators point of view (although I know how to use the real API
>>>>> methods)...I would love to see the same API being exposed as a
>>>>> web-service.
>>>>> wsapi4plone is already doing a good job right now..having a consistent
>>>>> programmatic API and a consistent web-service API together in one would
>>>>> be a
>>>>> cool addition for integrators.
>>>>>
>>>> I like the idea too. It solves a big problem we have with API
>>>> discoverability.
>>>>
>>>> However, API design is hard and a bad API is worse than none at all in
>>>> this case. I'd like to make sure we take documentation and review if this
>>>> very seriously before any release. I'd like to volunteer to help with this
>>>> type of review.
>>> We already have the @@context_state and @@portal_state views from
>>> plone.app.layout along with @@folderListing from
>>> plone.app.contentlisting. Rather than create a whole new API, I think
>>> it's important to build on these, perhaps adding further views along
>>> similar lines, and making them more easily reachable from pure python
>>> code. Being views makes them easy to use from page templates.
>>>
>>> Also note that getSite() does not always return the portal object
>>> itself. KSS views setup their own site manager and I expect subsite
>>> type add-ons like lineage will do so in the future if we enable
>>> traversal events in Zope2/4.
>>>
>> Yes, I suggested using getUtility(ISiteRoot) instead.
> ... which works, except I believe it doesn't get the RequestContainer
> fake aq parent, so anything doing context.REQUEST with that (or a
> traversed-to child of it) as the context won't work.
>
>

I think it says something that I then have no idea what the right way is
to get the site root 100% of the time :-/
David


----------
David Glick
 Web Developer
 [hidden email]
 206.286.1235x32

The Engagement Party 2012. So much more fun than the wedding reception.

http://www.npoengagementparty.com



------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli]

On 27 February 2012 03:02, Nejc Zupan <[hidden email]> wrote:
> Hi all,
>
> as some of you have already noticed, work has begun on a new package:
> plone.api.

I think this is really great :)

There is a risk that we'll end up in a situation where all of our own
packages depend on plone.api (I think this was Malthe's concern),
creating a somewhat challenging dependency management situation. We
need to think about how we address that, perhaps by mandating that
Plone core packages can't use plone.api, i.e. it's a "consumer-facing"
package only. Another option would be to make plone.api have 'soft'
dependencies only i.e. the API functions are available if the relevant
packages are in sys.path, otherwise they give an error, but there is
no install_requires dependency for things like Products.CMFPlone.

> The main goal is, quoting it's documentation, "a simple entry point for 20%
> of tasks
> we do 80% of the time."
>
> At this moment we have defined which methods should be in plone.api, their
> parameters
> and their return
> values: http://readthedocs.org/docs/ploneapi/en/latest/api.html

A bunch of thoughts follow:

First off - these methods use lowercase_and_underscore() methods. That
is what PEP8 (now!) says, but it's not the Zope standard. Since you
can't replicate every function on every object, you can't hide all the
mixedCase() methods. Dexterity started out as the former and had a
painful transition to the latter as API code became really confusing.
I think we just need to accept mixedCase() and stick with it.

get_tool() should be called getToolByName(). That one is already an
API and having two things importable from two places that do the same
thing with similar-but-different names is confusing. This is mainly
about old documentation and code that we can't expect to update in one
fell swoop.

get_all() for users is likely to be impossible in many scenarios (e.g.
LDAP/AD) and very, very slow. Probably best not to expose this as an
API. A search-based API is better.

We should consider the API on objects returned by items as well. At
the very least, dict-like access to folderish items (which works, even
for AT content), but also common methods like getId().

I was hoping to see some content search/catalog APIs.

There is no API for for developing new functionality, e.g. registering
new views, viewlets etc. I'd suggest trying to incorporate those into
plone.api may be a fallacy, as they are well-established elsewhere.
However, the documentation should cover where these are and give some
examples of important constructs. At the very least, I'd cover views.

We should either subsume or extend the plone_portal_state and
plone_context_state views for some of this. Access from TAL (including
expressions on things like actions) will be important. They also allow
for per-request caching which is important for performance. A simple
way to do that may be to replicate the relevant APIs on those views
and have the module-global function look up the view and call the
method.

> We also have a narrative documentation that guides new Plone developers
> through
> the process of managing content, users and groups:
> http://readthedocs.org/docs/ploneapi/en/latest/index.html#narrative-documentation

This is fantastic. :-)

> Note that *no code* has been written so far. All focus went into getting
> consensus on
> what to include and how the API should look like. In this light:
>
> Please don't go around adding/fixing API without first getting a few
> "+1"s from
> *non-rockstar* developers. It is absolutely crucial that whatever gets into
> plone.api
> to be understandable without years of Plone experience. I'm sure we missed
> some
> common use-cases, let's get them out there in the open to discuss whether to
> include
> them in plone.api.

I'll have a look through chapter 9 of PP4D and pull out anything I
felt was important enough to include there that may be missing.

We should also look at the Dexterity Developer Manual, which intends
to expose useful content operations, even if not exactly Dexterity
specific.

David also added a bunch of potentially useful functions.

> Actual method implementations are very welcome, but we'd like the API to
> stay mostly
> frozen unless the majority agrees on changing it. Baby steps. Use branches
> and
> pull-requests, keep master clean.

Good ideas. I think writing the implementations will be relatively easy.

Martin

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Martin Aspeli-3]

On 27 February 2012 07:55, David Glick <[hidden email]> wrote:

> I think it says something that I then have no idea what the right way is to
> get the site root 100% of the time :-/

I don't think it's 100% possible every scenario if you don't have a
valid acquisition context. If you do, use the potral_url tool.

The fix is simple, though: a traversal hook like the one that sets the
'site' threadlocal that getSite() returns that only triggers on the
site root and not other component site managers.

Martin

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Malthe Borch-2]

On 27 February 2012 11:24, Martin Aspeli <[hidden email]> wrote:
> There is a risk that we'll end up in a situation where all of our own
> packages depend on plone.api (I think this was Malthe's concern),
> creating a somewhat challenging dependency management situation. We
> need to think about how we address that, perhaps by mandating that
> Plone core packages can't use plone.api, i.e. it's a "consumer-facing"
> package only. Another option would be to make plone.api have 'soft'
> dependencies only i.e. the API functions are available if the relevant
> packages are in sys.path, otherwise they give an error, but there is
> no install_requires dependency for things like Products.CMFPlone.

I don't think it's a worry for `plone.*` packages, because they
typically interact with packages that do have reasonable APIs (e.g.
plone.session, keyring and friends).

The `plone.app.*` packages – these would probably benefit from using
the standard API. Actually, they'd benefit from not being separate
packages at all:

  plone/app/layout
  plone/app/locales
  ... etc ...

Then, you'd simply have top-level imports:

  from plone import get_members_by_id

That's *simple* – and I believe it's also the intention with the project.

It's unnessary to use the `plone.api` namespace, because this will be
just functions, and a name requirement could be that the published
names be sufficiently long and descriptive, and contain at least one
underscore (as illustrated by the example).

\malthe

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Nejc Zupan]

On 27/02/2012, at 07:37, David Glick wrote:

Some suggestions:

1. Regarding the calls like get_site_url() and get_request(), it's a bit misleading to say that these will *always* be available. It would be good to warn that the API is intended for use within code published by the ZPublisher (which sets up the necessary thread locals), as opposed to external methods or code run via bin/instance run or whatever.  Uh...I'll let you guys translate that into non-Zope-addled-brain language. :)

Definitely. If someone can give me a definitive list of when get_request() and such won't work,

and possibly links to in-depth explanations why, I'm happy to add this to the API documentation

(as in plone.api limitations). See https://github.com/plone/plone.api/issues/1.

2. In Dexterity we have plone.dexterity.utils.createContentInContainer which is similar to plone.api.content.create(). One thing I've found very useful in the Dexterity version is the checkConstraints=False flag if I want to add a content item and ignore the normal security checks for whether the item is allowed (useful for example in a browser view intended to let anonymous users submit something). Can we add something like this to api.content.create()?

I like the idea, I'll put it up for discussion. See https://github.com/plone/plone.api/issues/2

If not, please at least clarify in the documentation which API calls check permissions and which don't; this info is currently omitted.

I'll need help here, someone going through the methods one by one and writing down what the

security implications are. See https://github.com/plone/plone.api/issues/3.

3. This is me channeling wiggy: For the user API, can we please use "user_id" as the argument name instead of "username"? "Username" and "user id" are slightly different concepts in PAS and it gets endlessly confusing when the terminology changes from place to place. (We should probably supporting getting a user either by user_id or login.)

What the underlying terminology uses is not that relevant. The main question is How should the

API look like. In an ideal world, disregarding what goes on underneath, do we want the

api.user.create() to have:

 - ``username`` and ``user`` parameters OR

 -  ``userid`` and ``user`` parameters

I vote the former. What do you think?

4. The documentation for get_tool should include a list of the tools that are available in a standard Plone installation.

Good one! See https://github.com/plone/plone.api/issues/4.

5. Some additional things I think it would be useful to include in the API (or at least brainstorm further). (I came up with this list by going through the .py files of a recent client project and looking for things that could let me remove an import statement if it were part of the api....perhaps this is a useful exercise for others to do too.)

Yes, this is exactly how we did it :).

Calls to:
 a. get a content item's UID

Should this just be documented or do we need an actual api helper method. Isn't is just content.UID()?

and to get a content item from a UID

Already in, see http://readthedocs.org/docs/ploneapi/en/latest/api.html#plone.api.content.get.

 b. list the names of a content item's schema fields (no matter if it is Archetypes or Dexterity)

Yes! And also list user properties. See https://github.com/plone/plone.api/issues/5.

and get/set a field value by name

Also good. We already have api.user.get_property and api.user.set_property, so having the same for

content object is expected. See https://github.com/plone/plone.api/issues/6.

 c. grant or revoke a permission to a role within a particular context

Cannot this be easily performed through UI. Does it fall in the 20% of most common tasks?

 d. get the navigation root (which may be different than the site root)

If you have a site where navigation root is different than site root, you are doing something funky

and should know what you are doing without an abstraction layer covering it up for you.

A use-case that plone.api does not want to cover.

 e. get/set plone.app.registry record values

Yes! See https://github.com/plone/plone.api/issues/7

 f. format a date/time or number for the current locale

Also good, see https://github.com/plone/plone.api/issues/8.

 g. make sure a given path exists (i.e. add several levels of folder structure with one call)

Shall this be a separate method or a flag in create/move/copy?

 h. activate, upgrade, or deactivate an add-on

Uhm ... again, is it in the 20%? Isn't the UI approach good enogh and we document that 

rather than adding another method to plone.api (I really want to keep it sleek).

 i. As Laurence and Andreas mentioned, the things currently included in the views in plone.app.layout.globals...this also requires some discussion of what parts of the API to make accessible to untrusted code (i.e. page templates and TALES expressions).

If something in there proves usefull, we can easily add a method to plone.api that gets the relevant view

and then the relevant method. Is there something in globals that is used all the time and we don't yet

have in plone.api?

 j. An is_homepage() check (this is a FAQ, how do I check if I'm on the homepage)

See https://github.com/plone/plone.api/issues/9

One final word -- I hope others will see the new plone.api project not as an excuse to never simplify the APIs of the existing underlying Zope and Plone packages, but rather as an inspiration to do more of that. :)

On the contrary, plone.api will clearly show which parts of Plone APIs suck the most and need to get fixed.

z.

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Nejc Zupan]

On 27/02/2012, at 07:37, matthew lange wrote:

A few things I didn't see this in the links provided that I do think it would be good to be able to do:

list the members of a group/role (based on credentials of course)...

Yep, missed that one, please see https://github.com/plone/plone.api/issues/10.

a simple find/union/intersect functionality--similar to the get function listed:

SomeContentCol = api.content.find(path='/somePath', type='someContentType', attributeName='someAtributeName', attributeValue='someAtributeValue')

SomeOtherContentCol = api.content.find(path='/posSomeOtherPath', type=' posSomeOtherContentType', attributeName=' posSomeOtherAtributeName', attributeValue='posSomeOtheAtributeValue') 

IntersectedContent = api.content.intersect (SomeContentCol, SomeOtherContentCol, attrNamesValuesToMatch, attrNamesValuesToFilter)

UnionedContent = api.content.union (SomeContentCol, SomeOtherContentCol, attrNamesValuesToMatch, attrNamesValuesToFilter)

If you can further elaborate on how these should work, what parameters do you expect it to

have, etc. and write it up as an issue on GitHub so we can all comment on it there? Including examples

of how you would it in your code?

z.

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[Nejc Zupan]

On 27/02/2012, at 08:55, David Glick wrote:
> I think it says something that I then have no idea what the right way is
> to get the site root 100% of the time :-/

:)


------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers

[yuri-2]

Shouldn't the software adhere to the apis, instead of the apis adhere to
the software? :)

Il 27/02/2012 14:16, Nejc Zupan ha scritto:

> On 27/02/2012, at 07:37, matthew lange wrote:
>
>> A few things I didn't see this in the links provided that I do think
>> it would be good to be able to do:
>>
>> list the members of a group/role (based on credentials of course)...
>
> Yep, missed that one, please see
> https://github.com/plone/plone.api/issues/10.
>
>
>> a simple find/union/intersect functionality--similar to the get
>> function listed:
>>
>> SomeContentCol =
>> api.content.find(path='/somePath', type='someContentType', attributeName='someAtributeName', attributeValue='someAtributeValue')
>>
>>
>> SomeOtherContentCol =
>> api.content.find(path='/posSomeOtherPath', type='
>> posSomeOtherContentType', attributeName='
>> posSomeOtherAtributeName', attributeValue='posSomeOtheAtributeValue')
>>
>> IntersectedContent = api.content.intersect
>> (SomeContentCol, SomeOtherContentCol, attrNamesValuesToMatch, attrNamesValuesToFilter)
>> UnionedContent = api.content.union
>> (SomeContentCol, SomeOtherContentCol, attrNamesValuesToMatch, attrNamesValuesToFilter)
>
> If you can further elaborate on how these should work, what parameters
> do you expect it to
> have, etc. and write it up as an issue on GitHub so we can all comment
> on it there? Including examples
> of how you would it in your code?
>
>
> z.
>
>
> ------------------------------------------------------------------------------
> Try before you buy = See our experts in action!
> The most comprehensive online learning library for Microsoft developers
> is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
> Metro Style Apps, more. Free future releases when you subscribe now!
> http://p.sf.net/sfu/learndevnow-dev2
>
>
> _______________________________________________
> Plone-developers mailing list
> [hidden email]
> https://lists.sourceforge.net/lists/listinfo/plone-developers

------------------------------------------------------------------------------
Try before you buy = See our experts in action!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-dev2
_______________________________________________
Plone-developers mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/plone-developers