Search results

plone.rest-1.0b1-1.lbn25.noarch

plone.rest allows you to use HTTP verbs such as GET, POST, PUT, DELETE, etc. in Plone. REST stands for Representational State Transfer. It is a software architectural principle to create loosely coupled web APIs. plone.rest provides the basic infrastructure that allows us to build RESTful endpoints in Plone. The reason for separating this infrastructure into a separate package from the ‘main’ full Plone REST API is so you can create alternative endpoints tailored to specific usecases. A number of these specific endpoints are already in active use. Audience plone.rest is for experienced web developers who want to build their own HTTP/REST endpoints on top of Plone. If you want to use a ready-made full RESTful Plone API, you should use plone.restapi. That package uses, and depends upon, this one. Features Registering RESTful service endpoints for the following HTTP verbs: GET POST PUT DELETE PATCH OPTIONS Support for Dexterity and Archetypes-based content objects Content negotiation (‘application/json’ is currently the only format supported). Named services allows to register service endpoints for custom URLs Registering RESTful Service Endpoints plone.rest allows you to register HTTP verbs for Plone content with ZCML.

plone.rest-1.0b1-1.lbn25.noarch

plone.rest allows you to use HTTP verbs such as GET, POST, PUT, DELETE, etc. in Plone. REST stands for Representational State Transfer. It is a software architectural principle to create loosely coupled web APIs. plone.rest provides the basic infrastructure that allows us to build RESTful endpoints in Plone. The reason for separating this infrastructure into a separate package from the ‘main’ full Plone REST API is so you can create alternative endpoints tailored to specific usecases. A number of these specific endpoints are already in active use. Audience plone.rest is for experienced web developers who want to build their own HTTP/REST endpoints on top of Plone. If you want to use a ready-made full RESTful Plone API, you should use plone.restapi. That package uses, and depends upon, this one. Features Registering RESTful service endpoints for the following HTTP verbs: GET POST PUT DELETE PATCH OPTIONS Support for Dexterity and Archetypes-based content objects Content negotiation (‘application/json’ is currently the only format supported). Named services allows to register service endpoints for custom URLs Registering RESTful Service Endpoints plone.rest allows you to register HTTP verbs for Plone content with ZCML.

plone.restapi-4.3.1-1.lbn25.noarch

REST stands for `Representational State Transfer`_. It is a software architectural principle to create loosely coupled web APIs. Most web APIs have a tight coupling between client and server. This makes them brittle and hard to change over time. It requires them not only to fully document every small detail of the API, but also write a client implementation that follows that specification 100% and breaks as soon as you change any detail. A hypermedia API just provides an entry point to the API that contains hyperlinks the clients can follow. Just like a human user of a regular website, that knows the initial URL of a website and then follows hyperlinks to navigate through the site. This has the advantage that the client just needs to understand how to detect and follow links. The URL and other details of the API can change without breaking the client.

plone.restapi-4.3.1-1.lbn25.noarch

REST stands for `Representational State Transfer`_. It is a software architectural principle to create loosely coupled web APIs. Most web APIs have a tight coupling between client and server. This makes them brittle and hard to change over time. It requires them not only to fully document every small detail of the API, but also write a client implementation that follows that specification 100% and breaks as soon as you change any detail. A hypermedia API just provides an entry point to the API that contains hyperlinks the clients can follow. Just like a human user of a regular website, that knows the initial URL of a website and then follows hyperlinks to navigate through the site. This has the advantage that the client just needs to understand how to detect and follow links. The URL and other details of the API can change without breaking the client.

plone.rfc822-1.1-1.lbn13.noarch

This package provides primitives for turning content objects described by zope.schema fields into RFC (2)822 style messages, as managed by the Python standard library's email module. It consists of: * A marker interface IPrimaryField which can be used to indicate the primary field of a schema. The primary field will be used as the message body. * An interface IFieldMarshaler which describes marshalers that convert to and from strings suitable for encoding into an RFC 2822 style message. These are adapters on (context, field), where context is the content object and field is the schema field instance. * Default implementations of IFieldMarshaler for the standard fields in the zope.schema package. * Helper methods to construct messages from one or more schemata or a list of fields, and to parse a message and update a context object accordingly.

plone.rfc822-1.1.4-1.lbn25.noarch

This package provides primitives for turning content objects described by zope.schema fields into RFC (2)822 style messages, as managed by the Python standard library's email module. It consists of: * A marker interface IPrimaryField which can be used to indicate the primary field of a schema. The primary field will be used as the message body. * An interface IFieldMarshaler which describes marshalers that convert to and from strings suitable for encoding into an RFC 2822 style message. These are adapters on (context, field), where context is the content object and field is the schema field instance. * Default implementations of IFieldMarshaler for the standard fields in the zope.schema package. * Helper methods to construct messages from one or more schemata or a list of fields, and to parse a message and update a context object accordingly.

plone.rfc822-1.1.4-1.lbn25.noarch

This package provides primitives for turning content objects described by zope.schema fields into RFC (2)822 style messages, as managed by the Python standard library's email module. It consists of: * A marker interface IPrimaryField which can be used to indicate the primary field of a schema. The primary field will be used as the message body. * An interface IFieldMarshaler which describes marshalers that convert to and from strings suitable for encoding into an RFC 2822 style message. These are adapters on (context, field), where context is the content object and field is the schema field instance. * Default implementations of IFieldMarshaler for the standard fields in the zope.schema package. * Helper methods to construct messages from one or more schemata or a list of fields, and to parse a message and update a context object accordingly.

plone.scale-1.3.3-1.lbn13.noarch

Image scaling

plone.scale-2.1-2.lbn25.noarch

This package contains image scaling logic for use in Zope environments. It supports Zope 2, grok and other systems build on using the Zope ToolKit (ZTK). Several design goals were used when writing this package: image scaling to any width, height, width&height should be supported using both up-scaling and down-scaling. Scaling parameters should never be fixed in code. This allows designers to use any image scale they want without having to modify python code. the result of scaling will be an image along with its new size, not a HTML or XHTML tag. We already have excellent tools to generate tags in the form of Zope Pagetemplates, Genshi and other template languages that are much better suited for this purpose. In addition several implementation goals were defined: image scaling must happen on demand instead of up-front. This reduces initial save time and prevents unnecessary scalings from being generated. image scaling parameters should not be part of the generated URL. Since the number of parameters can change and new parameters may be added in the future this would create overly complex URLs and URL parsing. no HTML rewriting (such as done by repoze.bitblt) should be required. it should be possibly to develop an external storage system which stores scaled images externally and returns a URL which bypasses the application server. This should be configurable via just a filesystem path & base URL. minimum number of external dependencies, allowing this package to be used in many environments. testable without requiring zope.testing. Running setup.py test should be sufficient. URLs for scaled images should have an extension which reflects their MIME type. This is facilitates cache (and other front-end services) configuration.

plone.scale-2.1-2.lbn25.noarch

This package contains image scaling logic for use in Zope environments. It supports Zope 2, grok and other systems build on using the Zope ToolKit (ZTK). Several design goals were used when writing this package: image scaling to any width, height, width&height should be supported using both up-scaling and down-scaling. Scaling parameters should never be fixed in code. This allows designers to use any image scale they want without having to modify python code. the result of scaling will be an image along with its new size, not a HTML or XHTML tag. We already have excellent tools to generate tags in the form of Zope Pagetemplates, Genshi and other template languages that are much better suited for this purpose. In addition several implementation goals were defined: image scaling must happen on demand instead of up-front. This reduces initial save time and prevents unnecessary scalings from being generated. image scaling parameters should not be part of the generated URL. Since the number of parameters can change and new parameters may be added in the future this would create overly complex URLs and URL parsing. no HTML rewriting (such as done by repoze.bitblt) should be required. it should be possibly to develop an external storage system which stores scaled images externally and returns a URL which bypasses the application server. This should be configurable via just a filesystem path & base URL. minimum number of external dependencies, allowing this package to be used in many environments. testable without requiring zope.testing. Running setup.py test should be sufficient. URLs for scaled images should have an extension which reflects their MIME type. This is facilitates cache (and other front-end services) configuration.