Modified items

All recently modified items, latest first.

libunwind-0.99-0.13.20090430betagit4b8404d1.fc13.x86_64: Libunwind provides a C ABI to determine the call-chain of a program. This version of libunwind is targetted for the ia64 platform.

kss.core-1.6.5-2.lbn13.noarch: KSS is an Ajax framework that allows UI development without writing any Javascript. It uses style sheets with CSS-compliant syntax to declare and bind dynamic behaviors in the browser. The engine supports a set of generic DOM-like commands; they are computed on the server and sent back to manipulate the HTML page. What is KSS? ************ KSS is an AJAX framework. KSS has both a client-side Javascript library and server-side support. The client-side Javascript library needs to be included in your page. It fetches Kinetic style sheets from the server, parses them and binds a set of action to browser events and/or page elements. It is clean Javascript code that can peacefully coexist with other clean Javascript librarys like JQuery or ExtJS. It is about 100k in production mode. You can integrate your own Javascript code by using its extension mechanism through plugins. Server-side code is currently available for Zope (2 and 3, which includes Plone). The kss.base egg (which is currently in alpha) brings server-side support to other pythonic platforms, such as: * pylons * django * grok The Javascript client-side code can be used independently of existing server-side support. In other words, it is usable on platforms where we have not built server-side support like PHP, Ruby or Java. (If you have interest in porting KSS to the server environment you use and need help, please contact us !)

kss-1.6.5-2.lbn13.noarch: kss python module

ipython-0.13.1-1.lbn13.noarch: IPython provides a replacement for the interactive Python interpreter with extra functionality. Main features: * Comprehensive object introspection. * Input history, persistent across sessions. * Caching of output results during a session with automatically generated references. * Readline based name completion. * Extensible system of 'magic' commands for controlling the environment and performing many tasks related either to IPython or the operating system. * Configuration system with easy switching between different setups (simpler than changing $PYTHONSTARTUP environment variables every time). * Session logging and reloading. * Extensible syntax processing for special purpose situations. * Access to the system shell with user-extensible alias system. * Easily embeddable in other Python programs. * Integrated access to the pdb debugger and the Python profiler.

hexagonit.swfheader-1.2-1.lbn13.noarch: SWF metadata parser

grokcore.viewlet-1.11-1.lbn13.noarch: Grok-like configuration for zope viewlets

grokcore.view-2.8-1.lbn13.noarch: Grok-like configuration for Zope browser pages

grokcore.site-1.6.1-2.lbn13.noarch: Grok-like configuration for Zope local site and utilities

grokcore.security-1.6.2-2.lbn13.noarch: Grok-like configuration for Zope security components

grokcore.formlib-1.9-2.lbn13.noarch: Grok-like configuration for zope.formlib components

grokcore.component-2.5-2.lbn13.noarch: Grok-like configuration for basic components (adapters, utilities, subscribers)

grokcore.annotation-1.3-2.lbn13.noarch: Grok-like configuration for Zope annotations

graphviz-python-2.28.0-16.fc17.armv6hl: Python extension for graphviz.

graphviz-python-2.26.3-2.fc13.x86_64: Python extension for graphviz.

graphviz-2.28.0-16.fc17.armv6hl: A collection of tools for the manipulation and layout of graphs (as in nodes and edges, not as in barcharts).

graphviz-2.26.3-2.fc13.x86_64: A collection of tools for the manipulation and layout of graphs (as in nodes and edges, not as in barcharts).

google-perftools-1.7-1.fc13.x86_64: Perf Tools is a collection of performance analysis tools, including a high-performance multi-threaded malloc() implementation that works particularly well with threads and STL, a thread-friendly heap-checker, a heap profiler, and a cpu-profiler.

gomobiletheme.basic-1.0.9-2.lbn13.noarch: This product provides Go Mobile Default Theme mobile site theme for Go Mobile for Plone <http://webandmobile.mfabrik.com>. The theme look and feel resemble's Plone 4's Sunburst theme. The theme contains two optimized image resolutions * 48x48 based icon tiles for > 640 pixels wide mobile screens (based on Javascript screen width detection). * 24x24 based icon tiles for smaller screens CSS3 styles are used for WebKit based mobile browsers. Low-end phones, or non-webkit based proprietary mobile browsers, are also supported partially.

Products.DCWorkflowGraph-0.4-3.lbn13.noarch: DCWorkflowGraph is a DCWorkflow graphic viewer now. It uses Graphviz. I want to make it a graphic editor for DCWorkflow, just like what OpenFlowEditor does.

Products.DCWorkflow-2.2.4-3.lbn13.noarch: This product provides fully customizable workflows for the CMF portal_workflow tool. Developing a workflow ===================== This tool is easiest to use if you draw a state diagram first. Your diagram should have: - States (bubbles) - Transitions (arrows) - Variables (both in states and transitions) Remember to consider all the states your content can be in. Consider the actions users will perform to make the transitions between states. And consider not only who will be allowed to perform what functions, but also who will be *required* to perform certain functions. On the "States" tab, add a state with a simple ID for each state on your diagram. On the "Transitions" tab, add a transition with a simple ID for each group of arrows that point to the same state and have similar characteristics. Then for each state choose which transitions are allowed to leave that state. Variables are useful for keeping track of things that aren't very well represented as separate states, such as counters or information about the action that was last performed. You can create variables that get stored alongside the workflow state and you can make those variables available in catalog searches. Some variables, such as the review history, should not be stored at all. Those variables are accessible through the getInfoFor() interface. Worklists are a way to make people aware of tasks they are required to perform. Worklists are implemented as a catalog query that puts actions in the actions box when there is some task the user needs to perform. Most of the time you just need to enter a state ID, a role name, and the information to put in the actions box. You can manage all of the actions a user can perform on an object by setting up permissions to be managed by the workflow. Using the "Permissions" tab, select which permissions should be state-dependent. Then in each state, using the "permissions" tab, set up the role to permission mappings appropriate for that state. Finally, you can extend the workflow with scripts. Scripts can be External Methods, Python Scripts, DTML methods, or any other callable Zope object. They are accessible by name in expressions. Scripts are invoked with a state_change object as the first argument; see expressions.stx. Once you've crafted your workflow, you hook it up with a content type by using the portal_workflow top-level "Workflows" tab. Specify the workflow name in the target content type's box.

« Previous 20 items Next 20 items » 1 ... 2308 2309 2310 2311 2312 2313 2314 ... 2359


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

Sections

Modified items