Search results

plone.resource-1.2.3-1.lbn25.noarch

plone.resource publishes directories of static files via the ZPublisher. These directories may be located either in the ZODB (as OFS folders and files), or on the filesystem. Each resource directory has a type and a name. When combined, these are used to traverse to the resource directory. For example: /++theme++mytheme/<subpath> /++sitelayout++mylayout/<subpath> /++templatelayout++mylayout<subpath>

plone.resource-1.2.3-1.lbn25.noarch

plone.resource publishes directories of static files via the ZPublisher. These directories may be located either in the ZODB (as OFS folders and files), or on the filesystem. Each resource directory has a type and a name. When combined, these are used to traverse to the resource directory. For example: /++theme++mytheme/<subpath> /++sitelayout++mylayout/<subpath> /++templatelayout++mylayout<subpath>

plone.resourceeditor-1.0-1.lbn13.noarch

This package contains resources for integrating ACE (http://ace.ajax.org/) into Plone, with a file manager that can edit plone.resource resource directories in the ZODB. ACE can be found under ++resource++plone.resourceeditor/ace/*. The file manager can be included in a view with the following in the header: <metal:block use-macro="resourceDirectory/@@plone.resourceeditor.filemanager/macros/resources" /> and the following in the body: <metal:block use-macro="resourceDirectory/@@plone.resourceeditor.filemanager/macros/filemanager"> In both of these cases, resourceDirectory should be an in-ZODB plone.resource resource directory instance.

plone.resourceeditor-1.0.1-1.lbn25.noarch

This package contains resources for integrating ACE (http://ace.ajax.org/) into Plone, with a file manager that can edit plone.resource resource directories in the ZODB. ACE can be found under ++resource++plone.resourceeditor/ace/*. The file manager can be included in a view with the following in the header: <metal:block use-macro="resourceDirectory/@@plone.resourceeditor.filemanager/macros/resources" /> and the following in the body: <metal:block use-macro="resourceDirectory/@@plone.resourceeditor.filemanager/macros/filemanager"> In both of these cases, resourceDirectory should be an in-ZODB plone.resource resource directory instance.

plone.resourceeditor-1.0.1-1.lbn25.noarch

This package contains resources for integrating ACE (http://ace.ajax.org/) into Plone, with a file manager that can edit plone.resource resource directories in the ZODB. ACE can be found under ++resource++plone.resourceeditor/ace/*. The file manager can be included in a view with the following in the header: <metal:block use-macro="resourceDirectory/@@plone.resourceeditor.filemanager/macros/resources" /> and the following in the body: <metal:block use-macro="resourceDirectory/@@plone.resourceeditor.filemanager/macros/filemanager"> In both of these cases, resourceDirectory should be an in-ZODB plone.resource resource directory instance.

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.