[Zope3-Users] Re: [Zope3-dev] z3c.formjs-0.2 and z3c.formjsdemo-0.2 released!
Hi Paul, Hey, very smooth. Congratulations. I've committed a change to buildout.cfg removing z3c.form* develop eggs which kinda spoilt the buildout. Best regards, Darryl Cousins ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] z3c.formjs-0.2 and z3c.formjsdemo-0.2 released!
The 0.2 versions of z3c.formjs and z3c.formjsdemo have just been released! (for the blog version of this mail, see http://beta.carduner.net/wordpress/?p=20) For those who have not been following the development, z3c.formjs is a package that extends z3c.form (written by Stephan Richter and Roger Ineichen), adding JavaScript and AJAX functionality. More specifically, it allows you to control JavaScript and AJAX from within a presentation component like a form based view class. Alternatively ala Stephan Richter, This package is designed to provide a Python API to common Javascript features for forms written with the "z3c.form*" packages. While the reference backend-implementation is for the JQuery library, any other Javascript library can be hooked into the Python API. Here's what's new in the 0.2 release, taken straight from CHANGES.txt: z3c.formjs - Version 0.2.0 (7/18/2007) * Feature: Registration of public AJAX server calls via a simple decorator. The calls are made available via a special ajax view on the original view. * Feature: Allow registering of JS subscriptions via a decorator within the presentation component. * Feature: Added a new CSS selector. * Feature: Implementation of AJAX-driven widget value validation. * Restructure: Completely overhauled the entire API to be most easy to use and have the most minimal implementation. * Bug: The package is now 100% tested. * Feature: Implementation of AJAX request handlers in forms. z3c.formjsdemo Version 0.2.0 (7/18/2007) * Feature: The new chatroom demo implements a simple chat client in HTML and Javascript using the z3c.formjs package. * Feature: Validation demo showing off on the fly ajax field validation. * Restructure: Code updated to keep up with the changes in the API of z3c.formjs. Installation Instructions -- To checkout the demo, perform the following commands: svn co svn://svn.zope.org/repos/main/z3c.formjsdemo/tags/0.2.0 z3c.formjsdemo cd z3c.formjsdemo python2.4 bootstrap.py ./bin/buildout -Nv ./bin/demo fg The demo will then be available at http://localhost:8080. Alternatively, checkout the live demo at http://demo.carduner.net:8080/ (please no slashdot posts) Cheese Shop - Both of these packages are available on the Python Cheese Shop at * http://cheeseshop.python.org/pypi/z3c.formjs/0.2.0 and * http://cheeseshop.python.org/pypi/z3c.formjsdemo/0.2.0 Want to help? -- This is by no means a one (or two (or three ( … ) ) ) (wo)man project and I am very interested in what kinds of use cases other people have and would like to see implemented or demonstrated. I am also very interested in having other people join the fun and hack on some code. z3c.formjs is in theory JavaScript library agnostic, and I would love for that theory to be tested with a MochiKit rendering plugin or any other type of rendering plugin. So, please if you are interested, contact me at paulcarduner at gmail dot com or just make lots of noise on zope3-users, zope3-dev, or #zope3-dev and we can discuss further goals and tasks. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: Vedr. Zope 3 API documentation needs a new strategy
Luciano Ramalho wrote: > ... abundant README.txt files scattered all over the source tree where > the real documentation exists. Doctest text files are the first and primary resource for me. Packages published on PyPI with long_description from README.txt+CHANGES.txt are a much-appreciated convenience. I don't find ViewCVS to be great for browsing package sources. Trac or something similarly capable at launchpad.net/zope providing source browsing and a commit activity timeline would be helpful. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] z3c.form 1.5.0 and z3c.formdemo 1.3.0 released!
Hello everyone, I am pleased to announce new releases for z3c.form and z3c.formdemo. The latest changes were mainly driven by Paul Carduner's work on z3c.formjs and z3c.formjsdemo, but also by continued customer work. Again for the curious and impatient ... --- This time there is no new demo available, but the old ones still work as expected. To run the demos do the following:: $ svn co svn://svn.zope.org/repos/main/z3c.formdemo/trunk formdemo $ cd formdemo $ python bootstrap.py $ ./bin/buildout -v $ ./bin/demo fg Now you can access the demo under: http://localhost:8080/ We now also have functional tests that check all the demos: $ ./bin/test -vp1 On the Javascript Front --- A lot more progress has been made on this front. Look out for Paul's announcement! It will make up for the missing new demo in formdemo! Changes --- z3c.form - Feature: Added a span around values for widgets in display mode. This allows for easier identification widget values in display mode. - Feature: Added the concept of widget events and implemented a particular "after widget update" event that is called right after a widget is updated. - Feature: Restructured the approach to customize button actions, by requiring the adapter to provide a new interface ``IButtonAction``. Also, an adapter is now provided by default, still allowing cusotmization using the usual methods though. - Feature: Added button widget. While it is not very useful without Javascript, it still belongs into this package for completion. - Feature: All ``IFieldWidget`` instances that are also HTML element widgets now declare an additional CSS class of the form "-field". - Feature: Added ``addClass()`` method to HTML element widgets, so that adding a new CSS class is simpler. - Feature: Renamed "css" attribute of the widget to "klass", because the class of an HTML element is a classification, not a CSS marker. - Feature: Reviewed all widget attributes. Added all available HTML attributes to the widgets. - Documentation: Removed mentioning of widget's "hint" attribute, since it does not exist. - Optimization: The terms for a sequence widget were looked up multiple times among different components. The widget is now the canonical source for the terms and other components, such as the converter uses them. This avoids looking up the terms multiple times, which can be an expensive process for some applications. - Bug/Feature: Correctly create labels for radio button choices. - Bug: Buttons did not honor the name given by the schema, if created within one, because we were too anxious to give buttons a name. Now name assignment is delayed until the button is added to the button manager. - Bug: Button actions were never updated in the actions manager. - Bug: Added tests for textarea widget. z3c.formdemo - Feature: Created functional tests for the demos. - Feature: Moved all application ZCML declarations into a ZCML file called ``application.zcml``. Enjoy! Regards, Stephan -- Stephan Richter CBU Physics & Chemistry (B.S.) / Tufts Physics (Ph.D. student) Web2k - Web Software Design, Development and Training ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: Vedr. [Zope3-Users] Zope 3 API documentation needs a new strategy
Luciano Ramalho wrote: And finally, the wiki Documentation page does not mention the abundant README.txt files scattered all over the source tree where the real documentation exists. Yup, I agree that the README.txt's have a lot of useful info but how would you know to look for them if you were new to Z3 ? I also agree with the comment about PHP documentation - I can't stand PHP, but you can't argue with the size of the community that they must be doing something right, perhaps meeting the needs of the target audience ? :-) I think Z3 is awesome, but is (IMHO) still not really ready for a larger audience than the devotees using it now, mostly because of little things like documentation. Cheers, Andrew. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: Vedr. [Zope3-Users] Zope 3 API documentation needs a new strategy
On 7/18/07, Benji York <[EMAIL PROTECTED]> wrote: Does http://wiki.zope.org/zope3/Documentation help? Not really. Before yesterday, there was no explanation about how to access apidoc (I put that in the linked page APIDocTool yesterday). The apidoc tool itself is limited. For debugging purposes, it might be useful that the search is limited to registered interfaces. But while reading about Zope 3 I wanted to check on IComponentArchitecture but the search could not find it. I had to use grep to find it and learn the path that I could use to browse to it in the apidoc: http://localhost:8099/++apidoc++/Interface/zope.component.interfaces.IComponentArchitecture/index.html And finally, the wiki Documentation page does not mention the abundant README.txt files scattered all over the source tree where the real documentation exists. Cheers, Luciano PS. BTW, I'd like to mention that besides the people who replied in the list, I got pvt replies of people saying that they feel the same way as I do about the current docs. ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Re: Vedr. [Zope3-Users] Zope 3 API documentation needs a new strategy
Torvald Bringsvor wrote: Very good point I think. The current documentation makes me feel stupid, sometimes wanting to go in some other direction than Z3. Does http://wiki.zope.org/zope3/Documentation help? -- Benji York Senior Software Engineer Zope Corporation ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
Vedr. [Zope3-Users] Zope 3 API documentation needs a new strategy
Very good point I think. The current documentation makes me feel stupid, sometimes wanting to go in some other direction than Z3. -Torvald --- Luciano Ramalho <[EMAIL PROTECTED]> skrev: > One of the first questions anyone needs answered > when studying a new > framework is "Where is the canonical reference for > the API?". > > If you google for "zope 3 api documentation" the > first link is Stephan > Richter's mail of Jan/2004 announcing API doc. In > it, there is the > link: > > http://localhost:8080/++apidoc++ > > However, that URL is not active by default, and it > takes some research > discover how to make it work. > > The second link returned by Google is this: > > http://wiki.zope.org/zope3/Documentation > > Here we find vague references to a certain API Doc > Tool, but no > explanation of how to enable it and access it (OK, > that is a Wiki, so > it's easy to fix; I'll start the APIDocTool page). > > The remaining links returned by Google are even less > helpful, and on > page 2 we get a link to Shane Hathaway's post titled > "Zope 3 > Frustration"... > > Everyone expects the API documentation for a > framework to be highly > visibile in it's main web site. > > OK, I understand Zope 3 is undergoing a radical > reorganization right > now, which is a further push to descentralization, > making the idea of > locally generated API documentation even more > attractive. > > But I think we *also* need the API published on > Zope.org, for a few > advantages that the apidoc tool will never be able > to give us: > > - we need to be able to use Google to search the API > documentation > (even if the apidoc search worked perfectly, which > it doesn't) > > - we need to be able to collaborate with comments > and examples to the docs; > > The second point is really crucial. Just take a look > at this page, *please*: > > http://www.php.net/manual/en/ref.classobj.php > > Last year I had to do a project in PHP, and again > and again the > answers I was looking for were in the contributed > comments and > examples, even though their documentation is very > compreehensive. The > same amazing user participation can be seen in all > 23 languages (!) in > which the PHP API is documented. > > Contributing to Zope 3 docs must be made *much* > easier than being a > Zope 3 committer. > > Cheers, > > Luciano > ___ > Zope3-users mailing list > Zope3-users@zope.org > http://mail.zope.org/mailman/listinfo/zope3-users > ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
[Zope3-Users] Re: View or content provider
Hi Stephan! Stephan Richter wrote: > On Tuesday 17 July 2007 14:28, Daniel Nouri wrote: >> plone.portlets introduces some two dozen (!) interfaces/concepts on top of >> viewlets in order to implement the flexibility that it needs. E.g. it >> introduces an 'available' method/property that controls visibility, which >> viewlets by themselves lack. I imagine I could do this with less overhead >> without viewlets (see my other mail), or IOW: viewlets don't seem >> inherently flexible to me. > > Then you do not understand them. They are inherently flexible because content > providers are multi-adapters of context, request, and view and viewlets are > multi-adapters of context, request, view, and viewlet manager. Using adapted > objects as discriminators has opened totally new ways of developing UI > patterns in Zope 3. We have heavily learned from using those patterns and I > think the new z3c.form* framework benefitted a lot from it. You make it sound like the more objects you adapt, the more flexible you are. Which is true to a certain extent, but at the same time, the more objects you adapt from, the harder are the registrations to read and understand and the more tedious they are to write (compared to e.g. CMF expressions). Also, adaptation only works to a certain extent as a way to determine if a viewlet should be displayed or not. So even with four interfaces to adapt from, I cannot register by permission or by a rule like "are there any news items available". I'm not saying that these use cases can't be solved easily, it's just that the registry for viewlets doesn't have a way to express them with adaptation alone. BTW, what I've seen from z3c.form* looked quite impressive! I'm sure that your concepts work nicely for you there. But maybe they are not the most practical way to define my kind of page composition use case, which needs to be highly customizable at runtime (vs. zcml time). > As to portlets. When talking about portlets, the Web community refers usually > to features described in JSR 168. Viewlets have absolutely no ambition to > come even close to this. In fact, we specifically designed viewlets to do > much less with the intend to later implement portlets on top of them. > > To you viewlets might look extremely simple, in idea and implementation. But > this did not come over night and we said: Oh cool, let's use a > triplet-adapter to do content providers. Roger and I did an independent > implementation of viewlets, then fiercly discussed for nearly a week (people > attending the Tuebingen sprint can attest to this) the design goals and > implementation. The simple design of both, content provider and viewlets, is > thus a result of a deep understanding of UI development problem, not > something that was thrown together quickly. You know, often less is more! I'm all for less is more! > As to plone.portlets, I think they are heavily overengineered. Last time I > looked at its API, it was heavily bloated. This might be a result of being a > Plone package though, I do not know, but I would certainly implement them > much slimmer. Maybe the reason is that viewlets are not the best starting point for Plone's use case? In any event, I'm glad that viewlets exist, and I hope I'll soon have a chance to use them in a way that they were designed to be used. Currently, in Plone 3, they are a source of frustration to me. (And no, it's not because Plone developers are inherently stupid :-P) Regards, Daniel ___ Zope3-users mailing list Zope3-users@zope.org http://mail.zope.org/mailman/listinfo/zope3-users
