Re: [Zope3-dev] Release schedule and deprecation decisions
Jim Fulton wrote: A while ago, we had some discussion on when to make releases and how long to support deprecated features. The discussion has died down so I'll summarize what I think the conclusions were: - We'll move releases up one month to may and November from June and December. This means that the next release is scheduled for May and the next feature freeze is April 1. - We will support deprecated features for 1 year. I consider there to be decisions. :) +1 -- Dmitry Vasiliev (dima at hlabs.spb.ru) http://hlabs.spb.ru ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] RFE: Ignore .svn directories when doing a Zope3 "make install"
Hello: I would like to request a small enhancement to the installation scripts for Zope 3. I believe it is easy to do, but not being familiar with the packaging machinery, I could not figure out how to do it quickly. Like many Zope3 developers, I download a new Zope3 tarball and do the standard dance: ./configure make make check make install However, we have the convention that *all* third party tools and libraries (of which Zope is one) should be stored in a thirdparty repository under version control. This ensures repeatability of builds in our environment. The problem is that placing Zope-3.2.0 under version control creates ".svn" subdirectories all over the place (or "CVS" subdirectories in the case of CVS). The installation script which is invoked when you type "make install" apparently does a recursive copy for directories such as "bin", "zopeskel", etc. and you end up copying the .svn subdirectories over. Is there a way to provide an ignore pattern for the installation scripts? If someone can point me in the right direction to get started, I can provide a patch. Thanks in advance, --Craeg ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions
On Sunday 05 February 2006 14:42, Gary Poster wrote: > ...as I said, Jim disagreed with this sort of change the last time it > was brought up. Okay, I did not know that. > This needs to have a proposal, or at least needs to > have Jim weigh in on it, IMO. Yeah, I forgot about a proposal. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Three new Zope Corp packages now developed on zope.org
On Sunday 05 February 2006 14:35, Gary Poster wrote: > On Feb 5, 2006, at 10:41 AM, Stephan Richter wrote: > > On Wednesday 11 January 2006 14:10, Gary Poster wrote: > >> zope.locking: a replacement for zope.app.locking that provides > >> additional features while learning from the zope.app.locking > >> strengths and weaknesses. > > > > Could we deprecate zope.app.locking and move the code to zope.locking? > > +1 with deprecating zope.app.locking and using zope.locking. > > Move what code? Dependents like zope.app.externaleditor? No, I mean: 1. Deprcating zope.app.locking 2. Moving zc.locking to zope.locking. > BTW, on a somewhat related note, if anyone wants some of the zc.* > code to be moved into Zope proper (maybe even just the zope.* > namespace, and not the project itself), don't assume that the release > as a zc.* package means we're against that. Keeping the zc.* > namespace was the easiest thing to do, and did not demand refactoring > our software, refactoring the core, or making a proposal. If someone > wants to champion it and do the work (well, obviously not refactoring > our software, but providing a generation to compensate for the name > change and whatever else happened), propose it. yep, I figured that. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions
On Feb 5, 2006, at 12:20 PM, Stephan Richter wrote: On Tuesday 24 January 2006 12:26, Shaun Cutts wrote: It would seem that the current default mechanism is poorly suited to providing default values for non-immutables. For example: class IBar( Interface ): a = Object( schema = IFoo, default = Foo() ) Yes, this is even more apparent with the Datetime object, where you often want to make the default "now". That's true. It's been raised before...and changes like this have not been approved by Jim. [...] BTW, I am really glad someone is looking at this code. It has not gotten the attention it deserves. Thank you very much! I add my thanks. But... I really hope you will get checkin rights and check in your suggestions! :-) ...as I said, Jim disagreed with this sort of change the last time it was brought up. This needs to have a proposal, or at least needs to have Jim weigh in on it, IMO. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Three new Zope Corp packages now developed on zope.org
On Feb 5, 2006, at 10:41 AM, Stephan Richter wrote: On Wednesday 11 January 2006 14:10, Gary Poster wrote: zope.locking: a replacement for zope.app.locking that provides additional features while learning from the zope.app.locking strengths and weaknesses. Could we deprecate zope.app.locking and move the code to zope.locking? +1 with deprecating zope.app.locking and using zope.locking. Move what code? Dependents like zope.app.externaleditor? BTW, on a somewhat related note, if anyone wants some of the zc.* code to be moved into Zope proper (maybe even just the zope.* namespace, and not the project itself), don't assume that the release as a zc.* package means we're against that. Keeping the zc.* namespace was the easiest thing to do, and did not demand refactoring our software, refactoring the core, or making a proposal. If someone wants to champion it and do the work (well, obviously not refactoring our software, but providing a generation to compensate for the name change and whatever else happened), propose it. Gary ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Release schedule and deprecation decisions
--On 5. Februar 2006 12:11:08 -0500 Jim Fulton <[EMAIL PROTECTED]> wrote: A while ago, we had some discussion on when to make releases and how long to support deprecated features. The discussion has died down so I'll summarize what I think the conclusions were: - We'll move releases up one month to may and November from June and December. This means that the next release is scheduled for May and the next feature freeze is April 1. - We will support deprecated features for 1 year. I consider there to be decisions. :) Also +1 -aj pgpSOq50rodlE.pgp Description: PGP signature ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Release schedule and deprecation decisions
On Sunday 05 February 2006 12:11, Jim Fulton wrote: > A while ago, we had some discussion on when to make releases and > how long to support deprecated features. The discussion has died down > so I'll summarize what I think the conclusions were: > > - We'll move releases up one month to may and November from June and > December. This means that the next release is scheduled for May and > the next feature freeze is April 1. > > - We will support deprecated features for 1 year. > > I consider there to be decisions. :) Okay, +1. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.schema: defaults for non-immutables... questions
On Tuesday 24 January 2006 12:26, Shaun Cutts wrote: > It would seem that the current default mechanism is poorly suited to > providing default values for non-immutables. For example: > > class IBar( Interface ): > > a = Object( schema = IFoo, default = Foo() ) Yes, this is even more apparent with the Datetime object, where you often want to make the default "now". > A proposal to remedy: if the default is a callable object, it is assumed > to be a factory. That is dangerous. What if a value is really a callable. > How does this sound? (This would apply to missing_value as well.) I would prefer a new defaultFactory argument, which would be more backward-compatible too. > A few further questions: > > 1) who should be responsible for setting defaults, and how should it be > done? > I have a base class from which I derive (e.g.) Bar, whose constructor > loops through fields of interfaces provided by the instance: > > for iface in zope.interface.providedBy( self ): > for fname, field in zope.schema.getFields( iface > ).iteritems(): > > It checks default & missing_value, and sets them. However, if one field > shadows another in the interfaces, there is no guarantee that I hit them > in the right order. Might it not be good to have a > "attributesProvidedBy( instance ) in zope.interface that guarantees that > it passes back the most derived versions (and resolves consistently when > there is no "most derived" )? Usually we do not enforce defaults like that. Defaults are provided by the constructor arguments. The default value is really only used for the UI. > Also, currently, when something doesn't have a definition, and is not > required, I check first for "default" then for "missing_value", and use > the first I find as a missing value. Is this correct? Yes, I think so. > How should > "default" and "missing_value" interact with each other? What makes most > sense to me is: (pseudocode): > If not specified: > If default defined > Use default > Else > If required > Raise error > Else > If missing value defined > Use missing value > Else > Raise error > > Finally, a missing missing_value eventually gets "None" in the current > Field constructor. Shouldn't it be left undefined when it wasn't > specified? (Same for default.) I think using None as a default for missing_value is ok, so the only thing I would change in your pseudo code is to change the last error raising to: missing_value = None BTW, I am really glad someone is looking at this code. It has not gotten the attention it deserves. Thank you very much! I really hope you will get checkin rights and check in your suggestions! :-) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Release schedule and deprecation decisions
A while ago, we had some discussion on when to make releases and how long to support deprecated features. The discussion has died down so I'll summarize what I think the conclusions were: - We'll move releases up one month to may and November from June and December. This means that the next release is scheduled for May and the next feature freeze is April 1. - We will support deprecated features for 1 year. I consider there to be decisions. :) Jim -- Jim Fulton mailto:[EMAIL PROTECTED] Python Powered! CTO (540) 361-1714http://www.python.org Zope Corporation http://www.zope.com http://www.zope.org ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] zope.schema Field... constraints: should they really constrain each other?
On Thursday 19 January 2006 04:05, Shaun Cutts wrote: > What is happening is that "min" (and max) are ValidatedProperties of > Orderable. When a "missing_value" is supplied, min = None (by default) > is checked and fails validation. Good analysis. > One solution is to change "None" into missing_value in the Orderable > __init__. More exhaustively, min, max, and default should have defaults > as "__missing_value_marker" in the Orderable __init__ (using the trick > in Field.__init__), which would then be converted to the actual > missing_value, if specified, or None, if not. Yes, this sounds like the right way to do it. > (But I don't know if constraints should (always?) apply to each other. > For instance, if "min" were actually defined as the largest value > smaller than the range, it wouldn't validate against itself.) There should definitely be a check there; you are right. It would be great, if you could check in your suggestions into the repository or at least make an issue entry! Good work! Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Undo Principal Transaction problems with pluggable users
On Tuesday 10 January 2006 21:17, Jeff Shell wrote: > 'getPrincipalTransactions' works fine, I'm assuming (or hoping) that > as a workaround that once my code has the filtered transaction list, I > could call 'undo' on the undo manager instead of undo principal > transactions, so long as I remove the security proxy first. I'm fairly > satisfied (enough for tonight) that the selected transaction I want > the view to undo is the users own. > > I'm hoping that works so I can leave here in relative peace tonight, I guess you figured it out, based on a later post. If the undo machinery does equate principals instead of their ides, then you will have no luck, since the principal is created at runtime. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Add HomeFolder enhancement to CHANGELOG
On Sunday 05 February 2006 11:17, Florian Lindner wrote: > should I add the enhancement to the homefolder manager to the CHANGELOG or > is it too unimportant to add? (revision 41424) Everything should be added. :-) Whether I add it as a change entry in the release announcement is a different story. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] Add HomeFolder enhancement to CHANGELOG
Hello, should I add the enhancement to the homefolder manager to the CHANGELOG or is it too unimportant to add? (revision 41424) Florian ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Three new Zope Corp packages now developed on zope.org
On Wednesday 11 January 2006 14:10, Gary Poster wrote: > zope.locking: a replacement for zope.app.locking that provides > additional features while learning from the zope.app.locking > strengths and weaknesses. Could we deprecate zope.app.locking and move the code to zope.locking? Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] trigger in ecm.workflow?
On Tuesday 17 January 2006 03:27, Markus Leist wrote: > is there any small kind of sourcecode which can do a "simple" trigger of an > ecm.workflow direct in an object-method? > I have some xmlrpc-methods in which i have to modify the state of > "self"...workflow. > > in my old "zope.app.workflow"-source it looks like: > def changeWorkflowFrom... > adapter = IProcessInstanceContainer( self) > wf_host1 = removeAllProxies(adapter.get( "wf_host1")) > wf_host1.fireTransition(u"configured_offline") > > any idea? Well, in WfMC you cannot just trigger a transition. Instead you have to finish all the workitems. In SchoolTool I keep track of all the workitems in a list. Then I just finish them. Note that you only need to keep track of workitems that require manual interaction. All this can be seen from the zope.wfmc/README.txt file. I had to read the file about 3 or 4 times before I knew what was going on. But it is very complete. > at what place i should post a kind of "mini-howto" (in a few day)? I think the Zope 3 Wiki would be a good place. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] schema api
On Tuesday 17 January 2006 13:08, Jeff Shell wrote: > I noticed that modules that begin with an underscore aren't shown in > apidoc in Zope 3.2. I think (but am unsure) that Zope 3.1 showed > these. I'm sure there may have been a good reason for doing this, but > it makes navigating the zope.schema package for documentation even > more difficult. I am pretty sure noone changed that part of the code. The idea is that apidoc only documents public API, and modules starting with '_' are not considered public. > In particular, there are the convenience functions in the _schema.py > module that are useful for schema querying. getFieldNames, getFields, > etc... I can never quite remember what's in there and which ones > return sequences of tuples and which return mappings or lists or > iterables. Note that those functions are exposed in __init__.py > There's also no easily visible list of all of the fields available > from zope.schema.*. The interfaces are there, but people interact with > the classes in this package more than their interfaces. Since all of > the fields are defined in _bootstrapfields and _fields, they're no > longer visible. They can be found from the interface down in the > factories/classes section, maybe that's good enough? I hear your point. Maybe the package overview page should changed to show the objects imported in the __init__.py file? I think this would be a great idea. I would love if you would contribute this code or at least write a small proposal. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Fixing list descriptions
On Monday 16 January 2006 19:12, Philipp von Weitershausen wrote: > I just noticed that the descriptions of Zope 3 mailinglists in > http://mail.zope.org/mailman/listinfo aren't ideal. Currently is says: > > Zope3-dev Discuss development of and for Zope3 > Zope3-users Users of Zope 3 > > I think it should say something along the lines of: > > Zope3-dev Discuss development of Zope3 itself > Zope3-users Discuss development with Zope 3 +1 > Could someone with the right mailman privileges change this perhaps? Not me. :-( Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Principal Comparison and/or References
On Friday 13 January 2006 07:35, Gary Poster wrote: > It might be reasonable to add a bit to the IPrincipal interface that > __eq__ is provided and uses id to compare. That seems reasonable to > me, but maybe others have qualms. Care to write a mini-proposal? ;-) You have my +1 vote. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] RFC: Local Component Management Simplification
On Friday 03 February 2006 17:23, Dieter Maurer wrote: > Stephan Richter wrote at 2006-2-3 12:45 -0500: > > ... > > > > > > > > > > > > The "declareSite" looks redundant. I see at the "site name='mysite'" > element that a site with name "mysite" is declared... No it is not. Explicit is better then implicit. "declareSite" creates a new site in the sites mapping. We use this pattern for layers and skins already. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Mini-proposal: member-aware group interface
+1 for this one as well. :-) Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Mini-proposal: new principal interface in zope.security for full closure of group membership
+1 on the proposal for me, though I would think that we could add the new attribute/method to the interface with a note that it does not have to be implemented yet. This gets us back to our interface versioning discussion. I know you just wanted to avoid this by declaring a new interface, but maybe it is time to figure something out here. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] Mini-proposal: zope.app.authentication group events
On Thursday 12 January 2006 14:11, Gary Poster wrote:
> Problem:
> We want to perform actions when a user is added to a group, and
> possibly when a user is removed from a group. There is no hook point
> for this currently in the zope.app.authentication code.
>
> Solution:
> Fire events in the zope.app.authentication code when principals are
> added and removed from groups.
>
> 8<8<
> from zope import interface
>
> def IPrincipalAddedToGroup(interface.Inteface):
> group = interface.Attribute('the group to which the principal
> was added')
> principal = interface.Attribute('the principal added')
>
> def IPrincipalRemovedFromGroup(interface.Inteface):
> group = interface.Attribute('the group from which the principal
> was removed')
> principal = interface.Attribute('the principal removed')
>
> 8<8<
>
> In terms of implementation, it looks like
> zope.app.authentication.groupfolder.GroupFolder._addPrincipalToGroup
> and
> zope.app.authentication.groupfolder.GroupFolder._removePrincipalFromGrou
> p are the methods that would fire the events.
For what it is still worth, +1.
Regards,
Stephan
--
Stephan Richter
CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student)
Web2k - Web Software Design, Development and Training
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] [ANIM] Compound storages (cpsskins)
Hi! Here is an implementation of "compound storages" in CPSSkins (this concerns the CPSSkins AJAX toolkit only so it also applies to Zope3 in general, or to any other server that can handle JSON requests and responses). First of all, this is a great step towards simplifying the development of AJAX applications since it provides a complete abstraction between the model and the storage. The development model gets shifted from writing code in _javascript_ that moves data around places to defining a consistent data model. It is not necessarily easier unless one is used to creating application by first creating a model as opposed to starting by creating skins. Background: A data model needs some form of storage. There are many types of storages (persistent, volatile, with synchronous access, with asynchronous access, fast, slow, with low latency, with high latency...). An AJAX application needs different types of storages to manipulate data locally, to store the results of some user action on a server, to provide temporary persistence for instance when editing a document, ... There isn't one type storage that is best suited for everything. In the CPSSkins AJAX toolkit, there are three types of base storages available: the RAM storage, the local storage (cookie-based), and the remote storage (that uses accessors to get and set data via a remote server, e.g. Zope3). A problem that occurs in the MVC model when many types of storages are available is that since a given view (a widget) can only observe a single model, all the data will have to be stored in the same place and in the same way unless there is an indirection between the model and the storage(s). Solution: The "compound storage" makes it possible to combine several models to set their respective storages in common. The "compound storage" is similar to a RAID controller: it uses several storages to create what looks like a single storage, also it dispatches the I/O to the different storages. In the current implementation, the storages communicate with the compound storage and the compound storage communicates with the model using a simple event system (publish-subscribe with a extra message). When some data gets stored in a given storage, an event is sent to the subscribers (e.g. the compound storage). The event then gets propagated to the model which relays the event to the view(s) which in turn get updated. This is completely event-driven, so no "user-space" controller is involved. The advantage is that it can occur asynchronously. The compound storage defines a list of partitions. Each partition corresponds to the storage associated to a given model. The data stored in a model is accessed according to a schema which means that storages are protected against data corruption (such as changing the type of a field, or adding an unknown field). There is a lot of complexity in the toolkit implementation, but this is as much complexity that gets hidden from the application: the controller simply needs to set data in the model it doesn't have to know anything about ajax.requests or cookies. I've started writing a simple live chat application, and all in all the entire application code consists in about 40 lines of code in zope3 and in a 3Kb page template. The model definition can be created TTW, since the data is represented in JSON data structures, it involves no _javascript_. The only part that is _javascript_-heavy is the part that renders the widget, but there will be widget libraries. The animation: http://www.z3lab.org/sections/front-page/design-features/compound-storages The toolkit code: http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/ui/framework/cpsskins.js The code in Zope3: http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/ui/framework/tests/zope3/functional/quiz/browser.py The page template: http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/ui/framework/tests/zope3/functional/quiz/cpsskins_quiz.pt Here is the text seen in the animation: CPSSkins: storage adapters A storage adapter can be specified in the model definition to describe how the model will access the data. There are 4 types of storages available: RAM Local (stores the data in cookies) Remote (accesses a remote server) Compound (a combination of several storages) RAM storage In a RAM storage the data is entirely stored in the client's memory. The server is never accessed. There is no data persistence. Local storage In a local storage the data is stored in a cookie on the client. The server is never accessed. There is data persistence as long as the cookie does not expire. Remote storage In this example the data is stored on the server inside the session. This provides some persistence which means that the page can be reloaded or the user can leave and return to the page and the current data will be restored. An extra delay has been added when retrieving and when storing dat
[Zope3-dev] Selecting a code name
On Friday 03 February 2006 12:14, Shane Hathaway wrote: > Andreas Zeidler wrote: > > On Fri, Feb 03 17:24, Encolpe Degoute <[EMAIL PROTECTED]> wrote: > >>Zope 3 / Revolution ? > > > > well, how about "Zope3, Reloaded" for all the matrix fans out there? :) > > The idea of release code names adds a little spice. Most people like > spices on their food, so why not on their software too? But the naming > scheme really has to be based on the Tarzan series. Jim's a Tarzan fan. Okay, I am giving in on this. There is a three step process that will have to be fullfilled to assign a codename to the Zope 3.3 release. 1. Write a proposal that justifies the use of a codename. Announce it on zope3-dev asking for votes. 2. Ask for codename and.or codename scheme suggestions on this and the zope3-dev mailing list. Have the community vote on the suggestions. 3. Give me guidance on how to include and promote the codename when I make the releases. Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
