Modified items

All recently modified items, latest first.

Products.Marshall-2.1.2-1.lbn13.noarch: Marshall is a framework for pluggable marshalling policies Features ======== - A ControlledMarshaller class that delegates to underlying implementations - A marshall registry tool where you can configure some predicates for choosing marshallers based on several pieces of information available. Copyright ========= - This code is copyrighted by Enfold Systems, LLC. You can find more information at http://www.enfoldsystems.com/ - Portions of this code are copyright ObjectRealms You can find more information at http://www.objectrealms.net

Products.Maps-3.3-1.lbn13.noarch: A Google Maps solution for Plone with the 'GeoLocation' content type. The main purpose of this product is to provide a very simple to use Google Maps integration for Plone. The following goals were set for development: * Ease of use o Add locations to a folder o Set the view of the folder to Map o It figures out how to center and zoom the map automatically * Flexibility for enhancement by using the Zope 3 component architecture * Sane fallbacks when Javascript is not available * Clean separation of javascript, templates and logic * Works on Smart Folders Additionally Maps has the following features: * Support for content which has a location set with the geolocation product

Products.ManagableIndex-2.1.5-4.lbn13.noarch: Products.ManagableIndex is a framework for the easy construction of efficient, flexible, via the ZMI fully customizable indexes for Zope 2.11 (or above). It comes with a set of predefined indexes: Field, Keyword, Path, Range, Word and SimpleText index. Usually, they are more flexible and more efficient than the corresponding indexes from the Zope core. Products.ManagableIndex uses dm.incrementalsearch when it is installed. This can speed up queries by several orders of magnitude when used together with Products.AdvancedQuery

Products.MailHost-2.13.1-2.lbn13.noarch: zope.sendmail integration for Zope 2.

Products.MIMETools-2.13.0-2.lbn13.noarch: MIMETools provides the &lt;!--#mime--&gt; tag for DocumentTemplate.

Products.LDAPUserFolder-2.26-1.lbn13.noarch: This product is a replacement for a Zope user folder. It does not store its own user objects but builds them on the fly after authenticating a user against the LDAP database. Why does the LDAPUserFolder not show all my LDAP groups? According to feedback received from people who use Netscape directory products the way a new group is instantiated allows empty groups to exist in the system. However, according to the canonical definition for group records groups must always have a group member attribute. The LDAPUserFolder looks up group records by looking for group member entries. If a group record has no members then it will be skipped. As said above, this only seems to affect Netscape directory servers. To work around this (Netscape) phenomenon add one or more members to the group in question using the tools that came with the directory server. It should appear in the LDAPUserFolder after that. Why use LDAP to store user records? LDAP as a source of Zope user records is an excellent choice in many cases, like... * You already have an existing LDAP setup that might store company employee data and you do not want to duplicate any data into a Zope user folder * You want to make the same user database available to other applications like mail, address book clients, operating system authenticators (PAM-LDAP) or other network services that allow authentication against LDAP * You have several Zope installations that need to share user records or a ZEO setup * You want to be able to store more than just user name and password in your Zope user folder * You want to manipulate user data outside of Zope ... the list continues. The LDAP Schema Your LDAP server should contain records that can be used as user records. Any object types like person, organizationalPerson, or inetOrgPerson and any derivatives thereof should work. Records of type posixAccount should work correctly as well. The LDAPUserFolder expects your user records to have at least the following attributes, most of which are required for the abovementioned object classes, anyway: * an attribute to hold the user ID (like cn, uid, etc) * userPassword (the password field) * objectClass * whatever attribute you choose as the username attribute * typcial person-related attributes like sn (last name), givenName (first name), uid or mail (email address) will make working with the LDAPUserFolder nicer Zope users have certain roles associated with them, these roles determine what permissions the user have. For the LDAPUserFolder, role information can be expressed through membership in group records in LDAP. Group records can be of any object type that accepts multiple attributes of type "uniqueMember" or "member" and that has a "cn" attribute. One such type is "groupOfUniqueNames". The cn describes the group / role name while the member attributes point back to all those user records that are part of this group. Only those group-style records that use full DNs for its members are supported, which excludes classes like posixGroup. For examples of valid group- and user-records for LDAP please see the file SAMPLE_RECORDS.txt in this distribution. It has samples for a user- and a group record in LDIF format. It is outside of the scope of this documentation to describe the different object classes and attributes in detail, please see LDAP documentation for a better treatment. Things to watch out for Since a user folder is one of these items that can lock users out of your site if they break I suggest testing the settings in some inconspicuous location before replacing a site's main acl_users folder with a LDAPUserFolder. As a last resort you will always be able to log in and make changes as the superuser (or in newer Zope releases called "emergency user") who, as an added bonus, can delete and create user folders. This is a breach of the standard "the superuser cannot create / own anything" policy, but can save your skin in so many ways. LDAP Schema considerations when used with the CMF The CMF (and by extension, Plone) expect that every user has an email address. In order to make everything work correctly your LDAP user records must have a "mail" attribute, and this attribute must be set up in the "LDAP Schema" tab of your LDAPUserFolder. When you add the "mail" schema item make sure you set the "Map to Name" field to "email". The attributes that show up on the join form and the personalize view are governed by the properties you 'register' using the 'Member Properties' tab in the portal_memberdata tool ZMI view, which in turn is sourced from the 'LDAP Schema' tab in the LDAPUserFolder ZMI view. Attributes you would like to enable for portal members must be set up on the LDAPUserFolder 'LDAP Schema' tab first, and then registered using the 'Membeer properties' screen in the Member data tool ZMI view.

Products.LDAPMultiPlugins-1.14-1.lbn13.noarch: The LDAPMultiPlugins provides PluggableAuthService plugins that interoperate with LDAP.

Products.LDAPConnector-1.0-2.lbn13.noarch: Persistent Zope 2 LDAP connection manager

Products.GroupUserFolder-3.55.1-3.lbn13.noarch: GroupUserFolder is a kind of user folder that provides a special kind of user management.

Products.GenericSetup-1.7.4-1.lbn13.noarch: This product provides a mini-framework for expressing the configured state of a Zope Site as a set of filesystem artifacts. These artifacts consist of declarative XML files, which spell out the configuration settings for each "tool" in the site , and supporting scripts / templates, in their "canonical" filesystem representations.

Products.FusionChartsFree-4.0.3-2.lbn13.noarch: FusionCharts Free is a flash charting component that can be used to render data-driven & animated charts for your web applications and presentations. It is a cross-browser and cross-platform solution that can be used with PHP, ASP, JSP, ASP.NET, ColdFusion, Ruby on Rails, simple HTML pages or even PowerPoint Presentations to deliver interactive and powerful flash charts. You do NOT need to know anything about Flash to use FusionCharts. All you need to know is the language you're programming in.

Products.ExternalMethod-2.13.0-2.lbn13.noarch: This package provides support for external Python methods within a Zope 2 environment.

Products.ExternalFile-1.4.0-4.lbn13.noarch: ExternalFile extends Zope to work with files in the filesystem. You can create instances of ExternalFile that behave like standard Zope objects except that they get their contents from a file located anywhere in a Zope-accessable filesystem. You can edit the contents directly using file-based tools, or through Zope in the browser (for ASCII files) or through Zope via FTP or webdav. For example, ExternalFile has been used to provide convenient access to Java WebStart (".jnlp") files, Shockwave Flash scripts, etc. We've also included our own BLOB support with the new ZPublisher file_stream iterator.

Products.ExternalEditor-1.1.0-2.lbn13.noarch: Zope External Editor ==================== The Zope External Editor is a new way to integrate Zope more seamlessly with client-side tools. It has the following features: - Edit objects locally, directly from the ZMI. - Works with any graphical editor application that can open a file from the command line, including: emacs, gvim, xemacs, nedit, gimp, etc. - Automatically saves changes back to Zope without ending the editing session. - Associate any client-side editor application with any Zope object by meta-type or content-type. Both text and binary object content can be edited. - Locks objects while they are being edited. Automatically unlocks them when the editing session ends. - Can add file extensions automatically to improve syntax highlighting or file type detection. - Works with basic auth, cookie auth and Zope versions. Credentials are automatically passed down to the helper application. No need to reauthenticate. - https support (Openssl required) Using It -------- Use of the application is about as easy as using the ZMI once your browser is configured (see the installation instructions). To edit an object externally, just click on the pencil icon next to the object in the ZMI. The object will be downloaded and opened using the editor application you have chosen (you will be prompted the first time to choose an editor). You edit the object just like any other file. When you save the changes in your editor, they are automatically uploaded back to Zope in the background. While the object is open in your editor, it is locked in Zope to prevent concurrent editing. When you end your editing session (ie you close your editor) the object is unlocked. How it Works ------------ Ok, so this all sounds a bit too good to be true, no? So how the heck does it work anyway? First I'll give you a block diagram:: +------------+ +------------+ +---------+ +------+ | Editor App | <-- | Helper App | <-- | Browser | <-/ /- | Zope | +------------+ +------------+ +---------+ +------+ ^ ^ ^ ^ \ / \ / v v -----------------------/ /---- ------- / Local \ \ File / ------- Now the key to getting this to work is solving the problem that the editor cannot know about Zope, and must only deal with local files. Also, there is no standard way to communication with editors, so the only communication channel can be the local file which contains the object's content or code. It is trivial to get the browser to fire up your editor when you download a particular type of data with your browser. But that does you little good, since the browser no longer involves itself once the data is downloaded. It just creates a temp file and fires off the registered application, passing it the file path. Once the editor is running, it is only aware of the local file, and has no concept of where it originated from. To solve this problem, I have developed a helper application whose job is essentially two-fold: - Determine the correct editor to launch for a given Zope object - Get the data back into Zope when the changes are saved So, let's take a step by step look at how it works: 1. You click on the external editor link (the pencil icon) in the Zope management interface. 2. The product code on the server creates a response that encapsulates the necessary meta-data (URL, meta-type, content-type, cookies, etc) and the content of the Zope object, which can be text or binary data. The response has the contrived content-type "application/x-zope-edit". 3. The browser receives the request, and finds our helper application registered for "application/x-zope-edit". It saves the response data locally to disk and spawns the helper app to process it. 4. The helper app, reads its config file and the response data file. The meta-data from the file is parsed and the content is copied to a new temporary file. The appropriate editor program is determined based on the data file and the configuration. 5. The editor is launched as a sub-process of the helper app, passing it the file containing the content data. 6. If so configured, the helper app sends a WebDAV lock request back to Zope to lock the object. 7. Every so often (if so configured), the helper app stats the content file to see if it has been changed. If so, it sends an HTTP PUT request back to Zope containing the new data. 8. When the editor is closed, the content file is checked one more time and uploaded if it has changed. Then a WebDAV unlock request is sent to Zope. 9. The helper application exits. Configuration ------------- The helper application supports several configuration options, each of which can be triggered in any combination of object meta-type, content-type or domain. This allows you to create appropriate behavior for different types of Zope objects and content or even different servers. The configuration file is stored in the file "~/.zope-external-edit" (Unix) or "~\ZopeEdit.ini" (Windows). If no configuration file is found when the helper application starts, a default config file is created in your home directory. The configuration file follows the standard Python ConfigParser format, which is pretty much like the old .ini file format from windows. The file consists of sections and options in the following format:: [section 1] option1 = value option2 = value [section 2] ... Options ------- The available options for all sections of the config file are: editor -- Command line or plugin name used to invoke the editor application. On Windows, if no editor setting is found for an object you edit, the helper app will search the file type registry for an appropriate editor based on the content-type or file extension of the object (which can be specified using the extension option below). By default, the file path of the local file being edited is appended to this command line. To insert the file path in the middle of your command, use "$1" for Unix and "%1" for Windows respectively. save_interval -- (float) The interval in seconds that the helper application checks the edited file for changes. use_locks -- (1 or 0) Whether to use WebDAV locking. The user editing must have the proper WebDAV related permissions for this to work. always_borrow_locks -- (1 or 0) When use_locks is enabled this features suppresses warnings when trying to edit an object you have already locked. When enabled, external editor will always "borrow" the existing lock token instead of doing the locking itself. This is useful when using CMFStaging for instance. If omitted, this option defaults to 0. cleanup_files -- (1 or 0) Whether to delete the temp files created. WARNING the temp file coming from the browser contains authentication information and therefore setting this to 0 is a security risk, especially on shared machines. If set to 1, that file is deleted at the earliest opportunity, before the editor is even spawned. Set to 0 for debugging only. extension -- (text) The file extension to add to the content file. Allows better handling of images and can improve syntax highlighting. temp_dir -- (path) Path to store local copies of object data being edited. Defaults to operating system temp directory. *Note: this setting has no apparent effect on Windows* 8^( long_file_name -- (1 or 0) Whether to include the whole path to the object including the hostname in the file name (the default) or just the id of the object being edited. Turn this option off for shorter file names in your editors, and for editors that don't like long names. file_name_separator -- (string) Character or characters used to separate path elements in long files names used by external editor. Defaults to a comma (,). This must be a legal character for use in file names on your platorm (i.e., don't use a path separator character!). This option is ignored if 'long_file_name' is set to 0. Sections -------- The sections of the configuration file specify the types of objects and content that the options beneath them apply to. There is only one mandatory section '[general]', which should define all of the above options that do not have a default value. If no other section defines an option for a given object, the general settings are used. Additional sections can apply to a particular domain, content-type or meta-type. Since objects can have all these properties, the options are applied in this order of precedence. - [content-type:text/html] -- Options by whole content-type come first. - [content-type:text/*] -- Options by major content-type come second. - [meta-type:File] -- Options by Zope meta-type are third. - [domain:www.mydomain.com] -- Options by domain follow. Several sections can be added for each domain level if desired. - [general] -- General options are last. This scheme allows you to specify an extension by content-type, the editor by meta-type, the locking settings by domain and the remaining options under general for a given object. Editor Plugins -------------- For tighter client-side integration, external editor has a plugin system that allows it to interact directly with supported applications. On Windows this generally means using COM to invoke the application, open the content file and wait for the user to save and close the file. Because each application has different remote scripting capabilities and APIs, editor specific plugins must be written tailored to each supported application and platform. This system allows external editor to efficiently connect to running applications without relaunching them and therefore fully support MDI environments. The following applications currently have plugin support:: Application Platform Plugin Module Name(s) =================================================== HomeSite Windows homesite5, homesite Dreamweaver Windows dreamweaver Photoshop Windows photoshp, photoshop MS Word Windows winword, word MS Excel Windows excel MS Powerpoint Windows powerpnt, powerpoint External editor will attempt to load a plugin for any application before using the general editor control method. It does this by matching the name of the application executable file (sans extension) in the editor command line with the available plugins. Because plugins do not require the path of the editor application to work, you can simply specify the plugin module name for your editor in the configuration file if desired. For example, to specify Photoshop for all image files, use add the following section to your config file (ZopeEdit.ini on Windows):: [content-type:image/*] editor=photoshop This is only a shortcut and specifying the full application path will still use the plugin where possible. Plugin Notes ------------ Photoshop -- Photoshop's COM API is quite limited, and external editor cannot detect that you have closed a file until you exit the entire application (it can still detect saves). Therefore you may want to turn off DAV locking (use_locks=0) or borrow locks (always_borrow_locks=1) when using it. Dreamweaver -- External editor cannot detect when you have finished editing a single file. Objects edited with Dreamweaver will remain locked on the server until you exit the application. As with Photoshop above, you may want to turn off locking for Dreamweaver. If your favorite editor needs a plugin because the general support is not good enough, please let me know. Keep in mind that I must be able to run a copy of the application in order to develop a plugin for it. So, unless the application is free, or a full demo is available for download I won't be able to help much. Plugins are not difficult to write, and I encourage you to write one for your favorite editor, start by reading one of the existing ones. I am happy to include third-party plugins with the distribution. Permissions ----------- External editing is governed by the permission "Use external editor". Users with this permission can launch external editor from editable objects. In order to save changes, users will need additional permissions appropriate for the objects they are editing. If users wish to use the built-in locking support, they must have the "WebDAV access", "WebDAV Lock items" and "WebDAV Unlock items" permissions for the objects they are editing. If these permissions are not set in Zope, then the helper application will receive unauthorized errors from Zope which it will present to the user. Integrating with External Editor -------------------------------- The external editor product in zope installs a globally available object that can format objects accessible through FTP/DAV for use by the helper application. You can take advantage of this functionality easily in your own content management applications. Say you have an FTP editable object, "document", in a Zope folder named "my_stuff". The URL to view the object would be:: http://zopeserver/my_stuff/document The URL to kick off the external editor on this document would be:: http://zopeserver/my_stuff/externalEdit_/document Now, this may look a bit odd to you if you are used to tacking views on to the end of the URL. Because externalEdit_ is required to work on Python Scripts and Page Templates, which swallow the remaining path segments on the URL following themselves, you must put the call to externalEdit_ *directly before* the object to be edited. You could do this in ZPT using some TAL in a Page Template like:: <a href='edit' attributes='href string:${here/aq_parent/absolute_url}/externalEdit_/${here/getId}'> Edit Locally </a> As an alternative, you can also pass the path the object you want to edit directly to the `externalEdit_` object when you call its index_html method. It can be called either directly by URL or from a python script. externalEdit_ will return the proper response data for the object to edit. Here are some examples:: http://zopeserver/externalEdit_?path=/my_stuff/document return context.externalEdit_.index_html( context.REQUEST, context.RESPONSE, path='/my_stuff/document') When integrating External Editor with a CMS that already uses DAV locks, it will, by default allow users to borrow locks made on the server after displaying a confirmation dialog box. Although you can make this automatic by specifying 'always_borrow_locks = 1' in the External Editor config file, it may be desireable to make this the default behavior when using that server. To facilitate this, you can specify that locks should be automatically borrowed in the URL (New in 0.7):: http://zopeserver/my_stuff/externalEdit_/document?borrow_lock=1 External Editor also defines a global method that you can call to insert pencil icon links for appropriate objects. The method automatically checks if the object supports external editing and whether the user has the "Use external editor" permission for that object. If both are true, it returns the HTML code to insert the external editor icon link. Otherwise it returns an empty string. The method is 'externalEditLink_(object)'. The object argument is the object to create the link for if appropriate. Here is some example page template code that inserts links to objects in the current folder and the external editor icon where appropriate:: <div tal:repeat="object here/objectValues"> <a href="#" tal:attributes="href object/absolute_url" tal:content="object/title_or_id">Object Title</a> <span tal:replace="structure python:here.externalEditLink_(object)" /> </div> Conclusion ---------- I hope you enjoy using this software. If you have any comments, suggestions or would like to report a bug, send an email to the author:

Products.ExtendedPathIndex-3.1-1.lbn13.noarch: This is an index that supports depth limiting, and the ability to build a structure usable for navtrees and sitemaps. The actual navtree implementations are not (and should not) be in this Product, this is the index implementation only.

Products.EasyNewsletter-2.6.12-1.lbn13.noarch: EasyNewsletter is a simple but powerful newsletter/mailing product for Plone. Features Support Text and HTML Newsletter (including images) Support manual written Newsletters/Mailings Plonish (can use Plone's Collections to collect content) Variable templates to generate newsletter content Subscribing / Unsubscribing and can use Plone Members/Groups as receivers (works also with Membrane) support for external subscriber sources (configured through a Zope utility) support for external delivery services (other than Plone MailHost) TTW customizeable output Template to generate nice HTML Newsletter Support personalized mails Support for sending daily issues automatically, based on collections (by cron or clock-server) mass import/export subscribers via csv support external filtering/manipulation (filter out or add more subscribers) plugins

Products.DeadlockDebugger-1.0-2.lbn13.noarch: This product adds a hook so that a deadlocked Zope process can be debugged, by dumping a traceback of all running python processes. The dump is sent to the event log (at the DEBUG level) and returned to the browser (even though the Zope is deadlocked and doesn't answer any other requests!). DeadlockDebugger can of course also be used to debug Zope in non-deadlock situations, when a Zope process is taking a long time and you wish to know what code is being executed. The standard way to call it is to go to the URL:: http://yourzopesite:8080/manage_debug_threads?sesame This will return a dump, and also send this dump to the event log.

Products.DateRecurringIndex-2.1-1.lbn13.noarch: A Zope 2 catalog index with support for indexing of recurring events, following the icalendar standard. It is a drop-in replacement for the Zope2 DateIndex and will produce the same results for non-recurring dates. The DateRecurringIndex accepts following parameters: id Required. The name of the field or object attribute to be indexed. recurdef Required. The name of the object attribute, which returns the icalendar rrule (recurrence rule) string. until Optional. The name of the objects attribute, which returns the date, until the recurrence should happen. The recurrence definition can also contain an UNTIL component. If both are defined, the recurrence calculation stops whenever the first until-date is met. If not given at all, there is a MAXCOUNT ceiling constant, defined in plone.event.recurrence, which defines the maximum number of occurences. Datetime.DateTime vs. datetime.datetime Inside Zope2 everybody uses DateTime.DateTime or iow the Zope-DateTime. At time of writing Zope-DateTime (around 1998) there was no good date/time implementation in python. But these days we have a better implementation. Even if the pythons datetime implementation has its problems, together with pytz for timezone handling it is very mature. So, why is it covered here? Just because dst-handling over recurring events works only if the start and until values are non-naive python datetimes. Just keep it in mind when using this index: If you use recurring dates and you want dst-adjust make sure your implementation returns a python datetime. And also keep in mind: If youre i.e. in Austria with CET timezone, add a recurring date: it will look fine to you, every day at 11:00am, doesnt matter if DST or not, your event happens. If you go international and your event is shown in a different timezone - or in the same in a country without DST at all - it might differ and is not always at the the time.

Products.DataGridField-1.8.4-1.lbn13.noarch: A table input component for Plone. Uses Javascript to make entering tabular data more user friendly process - there are no round trip HTTP requests to the server when inserting or deleting rows. Features o Any number of columns set by a developer o Any number of rows filled by a user o Insert and deleting rows without submitting a form o Many different column types

xmltooling-schemas-1.4.2-2.1.lbn13.x86_64: The XMLTooling library contains generic XML parsing and processing classes based on the Xerces-C DOM. It adds more powerful facilities for declaring element- and type-specific API and implementation classes to add value around the DOM, as well as signing and encryption support. This package includes XML schemas and related files.

« Previous 20 items Next 20 items » 1 ... 2388 2389 2390 2391 2392 2393 2394 ... 2423


	Copyright © 2000-2025 Corporation of Balclutha Inc. All rights reserved.

Sections

Modified items