[Framework-Team] Re: DataGridField for z3c.form?
I found myself having the same need as Vincent so I looked a little bit at z3c.form. The end result is very much a mixed blessing. As Vincent discovered it is not very hard to get z3c.form 2.1 to manage a list of items. In my example I have this interface which is repeated: class IInformationLink(Interface): A link to more information related to a risk. url = schema.URI( title = _(uURL), required = True) description = schema.TextLine( title = _(uDescription), required = False) this has to be an Interface: if you use a zope.schema.Schema things break badly. You can then use this in your main interface like this: class IRisk(form.Schema, IRichDescription, IBasic): A possible risk that can be present in an organisation. links = schema.List( title = _(uInformation links), description = _(uA list of links to webpages which provide u more information on this risk.), required = False, value_type = schema.Object( title = _(uLink), schema = IInformationLink)) This works, but the resulting markup from z3c.form is quite ugly: a big mess of divs, nested divs, label elements inside div.label elements, etc. The UI it presents is also very confusing: https://photos-1.getdropbox.com/i/o/JmLD1SNVPJbwy12pgo-FYOWLsG-9L9lKNdBCm6yIfok is an example. Notice how it is very unclear that the Add/Remove buttons at the button belong to the 'Links' field. It gets even worse if you try to insert some data: https://photos-1.getdropbox.com/i/o/ZrPquRJE5oEOZn1DhCdS6ZTDArNqKhAZ15UGtF-3sqA . Part of this is a flaw in zope.schema which does not except URLs without a http: prefix (which will confuse users). The 'The system could not process the given value' is a mysterious one and reveals an essential bit that is not documented: z3c.form requires a IObjectFactory factory for the IInformationLink interface. This is an multi-adapter (with 4 facets, almost none of which you will ever need) and requires the name of the adapter to be set to the interface (feels like ZCA abuse to me): from zope.interface import Interface from zope.interface import implements from zope.component import adapts from z3c.form.interfaces import IObjectFactory class InformationLinkFactory(object): adapts(Interface, Interface, Interface, Interface) implements(IObjectFactory) def __init__(self, context, request, form, widget): pass def __call__(self, value): return dict(value) which you can register in zcml like so: adapter factory=.risk.InformationLinkFactory name=euphorie.content.risk.IInformationLink / and then it still does not work since it requires that your object factory returns something that zope.schema.Object can handle. In other words: it is not possible to return dictionaries. Next attempt: use a simple object that can implement IInformationLink: class InformationLink(object): implements(IInformationLink) def __init__(self, value): self.url=value[url] self.description=value[description] class InformationLinkFactory(object): adapts(Interface, Interface, Interface, Interface) implements(IObjectFactory) def __init__(self, context, request, form, widget): pass def __call__(self, value): return InformationLink(value) and that finally works. The lessons I have learned from this are: - z3c.form produces very awful HTML - z3c.form produces very confusing user interfaces - z3c.form documentation is indeed incomplete (no mention of ObjectFactory) - z3c.form you can do cool stuff with it, although I am not convinced it is much better than hand-coding the form And the reason I cc'ed the framework team: I strongly feel that until the generated markup and user interfaces from z3c.form are improved to meet Plone standards Plone itself should start using it. Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: DataGridField for z3c.form?
- z3c.form produces very awful HTML Does that apply to the general case, or only to the case of nested structures like this? The markup of the widgets I've seen has generally been pretty good. I think we need a much richer, mainly JavaScript-driven and probably less generalised widget for the grid use case anyway. - z3c.form produces very confusing user interfaces Again, I think that applies to - z3c.form documentation is indeed incomplete (no mention of ObjectFactory) It's certainly better than formlibs. ;-) - z3c.form you can do cool stuff with it, although I am not convinced it is much better than hand-coding the form One of the reasons we had a woefully incomplete Plone control panel and relied on the ZMI for far too much up until Plone 3 was that no-one likes or bothers with hand-coding forms for things like that. The same goes for content add/edit menus and anything else that is largely schema driven. There's definitely a place for hand-coded forms, but it's not a panacea either. And the reason I cc'ed the framework team: I strongly feel that until the generated markup and user interfaces from z3c.form are improved to meet Plone standards Plone itself should start using it. I think you're over-generalising. The output of a z3c.form form is not any worse than what we have with formlib or Archetypes (in fact, it's probably better, and it's certainly easier to standardise). There may be reasons for and against z3c.form, and the complex nested forms stuff is probably not quite mature, but it's not any less mature than it is in anything else. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: DataGridField for z3c.form?
On 9/10/09 16:43 , Martin Aspeli wrote: - z3c.form produces very awful HTML Does that apply to the general case, or only to the case of nested structures like this? To the general case. There are lots of unneeded divs, weird things like div class=errordiv class=errorerror message/div/div or div class=labellabelsome label/label/div and even some empty divs divdiv//div. I suspect that at least 50% of the markup generated by z3c.form can safely be removed and the rest replaces with a simple set of fieldset, label, legend and form elements with perhaps an extra p or em for error messages. - z3c.form documentation is indeed incomplete (no mention of ObjectFactory) It's certainly better than formlibs. ;-) The z3c.form documentation seems to follow the implementation structure and often reads like a doctest instead of human friendly documentation. It's nice that there is documentation, but it is not ideal. - z3c.form you can do cool stuff with it, although I am not convinced it is much better than hand-coding the form One of the reasons we had a woefully incomplete Plone control panel and relied on the ZMI for far too much up until Plone 3 was that no-one likes or bothers with hand-coding forms for things like that. The same goes for content add/edit menus and anything else that is largely schema driven. There's definitely a place for hand-coded forms, but it's not a panacea either. I think there are two reasons that that is true: Plone did not have anyone the last few years with both the right skillset and necessary time to make good forms, and none of the form-frameworks support a mix of hand-written and generated forms (or perhaps they do and there is just no documentation for it). Going forward we should aim to do better and not use existing form frameworks as excuse for not doing better. I think you're over-generalising. The output of a z3c.form form is not any worse than what we have with formlib or Archetypes (in fact, it's probably better, and it's certainly easier to standardise). From what I've seen today it is worse than Archetypes. Perhaps we have different criteria of what good markup should look like. Wichert. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: DataGridField for z3c.form?
Martin Aspeli wrote: - z3c.form produces very awful HTML Does that apply to the general case, or only to the case of nested structures like this? The markup of the widgets I've seen has generally been pretty good. I think we need a much richer, mainly JavaScript-driven and probably less generalised widget for the grid use case anyway. - z3c.form produces very confusing user interfaces Again, I think that applies to - z3c.form documentation is indeed incomplete (no mention of ObjectFactory) It's certainly better than formlibs. ;-) - z3c.form you can do cool stuff with it, although I am not convinced it is much better than hand-coding the form One of the reasons we had a woefully incomplete Plone control panel and relied on the ZMI for far too much up until Plone 3 was that no-one likes or bothers with hand-coding forms for things like that. The same goes for content add/edit menus and anything else that is largely schema driven. There's definitely a place for hand-coded forms, but it's not a panacea either. And the reason I cc'ed the framework team: I strongly feel that until the generated markup and user interfaces from z3c.form are improved to meet Plone standards Plone itself should start using it. I think you're over-generalising. The output of a z3c.form form is not any worse than what we have with formlib or Archetypes (in fact, it's probably better, and it's certainly easier to standardise). There may be reasons for and against z3c.form, and the complex nested forms stuff is probably not quite mature, but it's not any less mature than it is in anything else. There is another important factor too: z3c.form is seeing active development and has a committed maintainer, who cares about compatibility with Plone. I'm sure he'd appreciate patches and constructive feedback, rather than negative generalisations. I don't think anyone's yet built a good composite form solution. I suspect that z3c.form at least has the power to let you do so in a way that's going to end up being usable by mere mortals, even if it errs a little on the side of generalisation in providing hooks to those solving that rather complex use case. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
[Framework-Team] Re: DataGridField for z3c.form?
Wichert Akkerman wrote: On 9/10/09 16:57 , Martin Aspeli wrote: I don't think anyone's yet built a good composite form solution. I suspect that z3c.form at least has the power to let you do so in a way that's going to end up being usable by mere mortals, even if it errs a little on the side of generalisation in providing hooks to those solving that rather complex use case. Unfortunately I strongly feel that z3c.form is based on a basic principle I disagree with: it tries to support everything you may want to do in a form. As a result it has become a large and complex framework that can handle many things, but not something I enjoy using. I prefer simple things that do very little, but allow me to easily extend them whenever I need something non standard. For me something between repoze.formapi and FormEncode is ideal. I do see that z3c.form can be very useful for environments such as Plone, but it does mean that I am not going to put a much energy into improving it as my interests lie elsewhere. z3c.form can be cleaned up without too much work, but someone else will need to champion that effort. If you're actively discouraging the solution we do have that works today, you're not interested in improving it, and you'd like to see some other solution that doesn't exist yet take its place, then I fear we're at an impasse and we'll never get anywhere. As you say, z3c.form (in design principle if nothing else) meets a need (schema-based forms) that is quite common in Plone. When we did the UI support for Dexterity, it was the only good alternative we had, since formlib was both being abandoned by its maintainers and proved too inflexible and awkward to work with, and hand-written forms would be, well, silly. I won't claim that z3c.form is perfect, but I will say that we'd be better off trying to work with what we have today. It doesn't sound like you're about to champion a new comprehensive forms solution that will be usable in the next few weeks or months. :) I'd also guess that the HTML markup from the default widgets is probably not as important to everyone else as it seems to be to you. Martin -- Author of `Professional Plone Development`, a book for developers who want to work with Plone. See http://martinaspeli.net/plone-book ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: DataGridField for z3c.form?
Hi Wichert, --On Donnerstag, September 10, 2009 16:27:14 +0200 Wichert Akkerman wich...@wiggy.net wrote: [...] class IInformationLink(Interface): A link to more information related to a risk. url = schema.URI( title = _(uURL), required = True) description = schema.TextLine( title = _(uDescription), required = False) As with formlib (and IIRC similar to Archetypes) I use a TextLine with an isUrl constraint (validator) that (in my case) checks for http or https (but that's a matter of taste and use case) and throws an Error message tailored to my users. It is one of the nice features of z3c.form that you can register you own error snippets (even different snippets for different forms, layers etc). But it's enough to write an contraint and throw an exception: badge_url = TextLine( title=u'Website', required=False, missing_value=u'', constraint=isHttpURL, ) def isHttpURL(value): if ...: return True else: raise UrlException class UrlException(zope.schema.ValidationError): __doc__ = uPlease use a valid url like http://ploneconf2009.org; zope.interface.implements(zope.app.form.interfaces.IWidgetInputError) [...] and that finally works. The lessons I have learned from this are: - z3c.form produces very awful HTML It can be enhanced. At the same time it's partly a matter of z3c.form, but the zope 2 and plone integration packages. - z3c.form produces very confusing user interfaces What's missing here (speaking for what a framework can provide) is a border around each object and a border around all objects. z3c.form doesn't do it as it does not provide additional resources like css or images, it's not written as part of an application. The zope/plone integration packages are written for z3c.form 1.9 which doesn't contain an object widget. Using the MultiWidget with TextLines gives an understandable UI. Also it's a matter of adoption. Unless someone has the usecase, nobody will write a customization for something that could be optimized when used in plone. - z3c.form documentation is indeed incomplete (no mention of ObjectFactory) Yes. And it's bad that the documentation is the complete doctest suite for z3c.form which partly makes it confusing and not very friendly for average plone developers/integrations. We have to provide plone specific documentation anyway and have to fill this gap. But the truth is that it's much better than the formlib documentation. - z3c.form you can do cool stuff with it, although I am not convinced it is much better than hand-coding the form We have the need for auto generated, schema driven forms. Maybe we would better use hand written forms at some places, but don't do for various reasons. But that leaves the rest. But much of what you tell comes from wrong expectations. If you have a general framework for autogenerate forms, you can not expect it to produce the markup and ui that is optimal for your use case. If you want that for usability reasons, you'd better use handwritten form or, in this case, add some css if it is enough for your requirements. Your right that the plone integration package is rough at some points, but it will only get better if more people use it, especially people that have a sense for markup and user interfaces. And it will only get a variety of widget alternatives if it has a bigger user base. If the framework team allows the usage of z3c.form for the two (?) plips it does not mean that everybody will do z3c.forms from the next day on. There will be a long transition phase where we will develop better templates and add css to make the user experience better. We will also get more z3c.form documentation on a basic level for developers and integrators to solve the common use cases. I'd be against the use of z3c.form if * formlib is similarly suited as the general autogenerated form solution * z3c.form is too complex for integrators or * there is an alternative identifiable that will do a better job for schema based autogenerated forms within the next 1 or 2 years. But I think nothing of this is true. ..Carsten ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
Re: [Framework-Team] Re: DataGridField for z3c.form?
On 2009-9-10 17:23, Martin Aspeli wrote: If you're actively discouraging the solution we do have that works today, you're not interested in improving it, and you'd like to see some other solution that doesn't exist yet take its place, then I fear we're at an impasse and we'll never get anywhere. As you say, z3c.form (in design principle if nothing else) meets a need (schema-based forms) that is quite common in Plone. When we did the UI support for Dexterity, it was the only good alternative we had, since formlib was both being abandoned by its maintainers and proved too inflexible and awkward to work with, and hand-written forms would be, well, silly. I am saying that for Plone z3c.form is a possibly good alternative for generated forms, but that right now in my opinion it needs some work to meet Plone user interface and markup standards. I am also saying that I personally am not willing to do that work since my priorities are elsewhere. I am not trying to provide stop energy here - my only goal is to make sure that we are not going to reduce the Plone UI because our attention is too focused on shiny new technology. I'd also guess that the HTML markup from the default widgets is probably not as important to everyone else as it seems to be to you. The markup for z3c.form is both overly complex as well as very different than the markup patterns Plone uses. This means that styling a Plone site which uses z3c.form as well as Archetypes is twice as hard since it requires writing CSS for two different markup patterns. Wichert. -- Wichert Akkerman wich...@wiggy.net It is simple to make things. http://www.wiggy.net/ It is hard to make things simple. ___ Framework-Team mailing list Framework-Team@lists.plone.org http://lists.plone.org/mailman/listinfo/framework-team
