Hi, Oh, I've had no notices of CPS 4 until that :-( I've read your YellowCake description and it sounds really really interesting. I will read it again carefully.
Going back to CPSSchemas, I lament the disappearance of flexible document concept. I think it is a great advantage of ZODB based applications in front of other technologies, and for us is a good argument of selling (in KMKey we have a TTW tool to define properties in objects, very much simpler than CPSSchemas, but enough to show the customers that they can personalize most of the application by their own), and also a good internal tool (some employees can personalize instances with no knowledge of programming). I understand that if Nuxeo doesn't need this features, you don't worry about it. But, could be possible for us to develop a TTW tool to manage the most simple cases ? I don't know much about JCR, but in case of a XML definition I understand that we can create a TTW tool to edit that XML and then force CPS to reload the definition (despite this could affect all the Zope instance). Do you think that this could be technically possible ? Or they are some technical impediments to it ? As you can see, I'm just worried to find this door closed in a near future. The rest of CPS 3 is fantastic, and CPS 4 promise to be much better, so I'm decided to use CPS as the platform of next KMKey 3 (current version is developed in plain Zope) Thanks for your help Santi Camps http://www.earcon.com - http://www.kmkey.com On 5/19/06, Florent Guillaume <[EMAIL PROTECTED]> wrote:
Hi, Thanks for the praise. Regarding the future of CPSSchemas: in the CPS 3 line, they won't change at all. For CPS 4 we're going with a slightly different model. Schemas that can be edited through the web are not the main focus, and this will not be possible. The reason is that in most of our use cases, schemas are designed at specification time, and don't change after that, except for updates. This means that in this context changing schemas is an administration task akin to deploying a new version of the application. So yes, schemas will be close to the Zope 3 ones, in that they are defined "in code", or at least in a place not administered TTW. And the internal model for the CPS 4 schemas will be Zope 3 schemas (although probably read from an XML file or from a JCR repository backend). Another big change is that schemas will be hierarchical, à la XML schemas, and will be able to represent complex subobjects. Internally this uses zope.schema.Object schema fields, and zope.schema.List. As for the layout part, we don't want to change too much in CPS 4 so they won't be much different, only more complex to cater for non-flat schemas. You'll still be able to change the rendering by going to the layout and swap widgets. Another change is that the current notion of flexible document disappears, because this would mean changing a schema at runtime. On the other hand, an equivalent functionality will be provided by more complex list types, where a field of a schema can be a list of complex subobjects themselves described by a schema. With lists, you get most of what flexible documents are used for. Florent On 18 May 2006, at 12:15, Santi Camps wrote: > I was studing CPSSchema's for some days, and I'm really excited with > it. It's really a impressive work. Congratulations. > > I'm planning to develop the next generation of our product, KMKey, > using CPS and CPSSchema's. But before that, I want be sure of the > future of CPSSchema's. I can see that in last products like > CPSSharedCalendar you are already using the Zope 3 way, using > interfaces and Z3 autogenerated add and edit forms, widgets, etc. > That way has an inconvenience for me: a lot of flexibility is lost. > It's not so easy add a field to a type in one site, and leave the > others sites without this specific field, for instance. > > Is there any defined plans about the merge between CPSSchema's and > Zope 3 ? Will be the flexible types, schema's and layout's remain > available until Zope 3 local utilities can replace them ? Are you > planning to maintain CPSSchema's interface and reimplement it using Z3 > code, or simply abandon CPSSchema's and begin to use Z3 way ? > > I'm really interested about this issues. If we take that way, we > will need to contribute CPSSchema's with some code early (if you want, > of course, if not that code will be a new product). -- Florent Guillaume, Nuxeo (Paris, France) Director of R&D +33 1 40 33 71 59 http://nuxeo.com [EMAIL PROTECTED]
_______________________________________________ cps-devel mailing list http://lists.nuxeo.com/mailman/listinfo/cps-devel
