Re: [Zope3-Users] thoughts about z3c.form-package

2008-10-08 Thread Hermann Himmelbauer
Am Mittwoch 08 Oktober 2008 01:11:24 schrieb garz:
 hey,

 while using z3c.form-package i reach its limits here and there. thats why i
 started to think about how a more general implemention should look like. my
 intention of writing this is that i want to know what you are thinking
 about it and i want to know the design-decisions that led to the different
 aspects of z3c.form.

 in the first part i try to give definitions of the concepts of z3c.form as
 would understand them.
 summary:

 z3c.form is all about this one use-case where the user describes a context
 with the help of a schema. you define fields, those fields are used to
 create fieldwidgets and those are rendered in the standard-forms from
 z3c.formui. its very nice to have this use-case well supported, but this
 support should be based on more general implementations. this would enable
 the user to create any kind of form.

Yes, that's the obvious use-case. However, there's much more you can do with 
z3c.form, I often use z3c.form for context-less patterns, or use a session as 
context. In my scenario here, I sparely use ZODB, instead, I have 
SQLAlchemy-based functions that I call in the button handlers. Thus I have 
already interfaces/schemas for all RDB objects, and what I do is to define 
interfaces for those forms and copy those schemas I need into this 
form-interface. Then I can use this interface in my form via 
field.Fields(IMyForm).

But I have to admit, it took me quite a long time to implement certain 
patterns, and very often, the solution I tried was not possible due to some 
complicated z3c.form internals, meaning, I often tried to violate some 
concepts (as I did not understand them).

I think I'm not the only one here, I read quite often about similar problems 
in this list here, so this is my resumee:

- z3c.form is complex
- It's not obvious how to implement certain form-patterns
- People are often overwhelmed by that and don't look through

So, I think two solutions to that could be:

- Improve the documentation (however, I'm unsure in what way, though).
- Create a WIKI or something similar where people can find suggestions how to 
implement certain patterns with z3c.form.
- Do some voting machinery where people can choose which patterns they 
really use. This information may be valuable to find out what people expect  
from a form package and which concepts people actually understand and use.
- If we find patterns that can not be implemented with z3c.form in a viable 
way, try to extend z3c.form so that it is possible.

For me, this looks like the better approach than to trying to implement 
a better form package that may lead to the very same problems as z3c.form 
in the end.

Best Regards,
Hermann

-- 
[EMAIL PROTECTED]
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


Re: [Zope3-Users] thoughts about z3c.form-package

2008-10-08 Thread Tim Cook
On Wed, 2008-10-08 at 06:25 +0200, Roger Ineichen wrote:

 Adam Groszer is working on a ObjectWidget implementation.

What is the proposed functionality of ObjectWidget?

Thanks,
Tim



-- 
Timothy Cook, MSc
Health Informatics Research  Development Services
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
Skype ID == timothy.cook 
**
*You may get my Public GPG key from  popular keyservers or   *
*from this link http://timothywayne.cook.googlepages.com/home*
**

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


Re: [Zope3-Users] thoughts about z3c.form-package

2008-10-08 Thread Roger Ineichen
Hi Tim, Adam

 Betreff: Re: [Zope3-Users] thoughts about z3c.form-package
 
 On Wed, 2008-10-08 at 06:25 +0200, Roger Ineichen wrote:
 
  Adam Groszer is working on a ObjectWidget implementation.
 
 What is the proposed functionality of ObjectWidget?

The ObjectWidget is a widget for an IObject field.
This field is used for attributes which provide a own
schema and hold a refenece to a pyton instance 
providing this schema. (does this make sense?)

Probably a sample explains it better.
The attribute door in the sample below is an Object field.

class IDoor(zope.interface.Interface):
A cars door.

color = zope.schem.TextLine(
title=u'Color')

class ICar(zope.interface.Interface):
A car.

door = zope.schem.Object(
title=u'A cars door',
schema=IDoor)
...


The ObjectWidget is now responsible for render an input
widgets in an EditForm for the color attribte of the door.

Adam, is this correct?

Regards
Roger Ineichen

 Thanks,
 Tim
 
 
 
 --
 Timothy Cook, MSc
 Health Informatics Research  Development Services LinkedIn 
 Profile:http://www.linkedin.com/in/timothywaynecook
 Skype ID == timothy.cook
 **
 *You may get my Public GPG key from  popular keyservers or   *
 *from this link http://timothywayne.cook.googlepages.com/home*
 **
 
 

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


Re: [Zope3-Users] thoughts about z3c.form-package

2008-10-08 Thread Adam GROSZER
Hey Roger,

Yes, you're right, thanks for the explanation.

Wednesday, October 8, 2008, 3:32:04 PM, you wrote:

RI Hi Tim, Adam

 Betreff: Re: [Zope3-Users] thoughts about z3c.form-package
 
 On Wed, 2008-10-08 at 06:25 +0200, Roger Ineichen wrote:
 
  Adam Groszer is working on a ObjectWidget implementation.
 
 What is the proposed functionality of ObjectWidget?

RI The ObjectWidget is a widget for an IObject field.
RI This field is used for attributes which provide a own
RI schema and hold a refenece to a pyton instance 
RI providing this schema. (does this make sense?)

RI Probably a sample explains it better.
RI The attribute door in the sample below is an Object field.

RI class IDoor(zope.interface.Interface):
RI A cars door.

RI color = zope.schem.TextLine(
RI title=u'Color')

RI class ICar(zope.interface.Interface):
RI A car.

RI door = zope.schem.Object(
RI title=u'A cars door',
RI schema=IDoor)
RI ...


RI The ObjectWidget is now responsible for render an input
RI widgets in an EditForm for the color attribte of the door.

RI Adam, is this correct?

RI Regards
RI Roger Ineichen

 Thanks,
 Tim
 
 
 
 --
 Timothy Cook, MSc
 Health Informatics Research  Development Services LinkedIn 
 Profile:http://www.linkedin.com/in/timothywaynecook
 Skype ID == timothy.cook
 **
 *You may get my Public GPG key from  popular keyservers or   *
 *from this link http://timothywayne.cook.googlepages.com/home*
 **
 
 

RI ___
RI Zope3-users mailing list
RI Zope3-users@zope.org
RI http://mail.zope.org/mailman/listinfo/zope3-users


-- 
Best regards,
 Adam GROSZERmailto:[EMAIL PROTECTED]
--
Quote of the day:
She who loves roses must be patient and not cry out when she is pierced by 
thorns.
- Brouman, Olga 

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


Re: [Zope3-Users] thoughts about z3c.form-package

2008-10-08 Thread Tim Cook
On Wed, 2008-10-08 at 15:32 +0200, Roger Ineichen wrote:
  
  What is the proposed functionality of ObjectWidget?
 
 The ObjectWidget is a widget for an IObject field.
 This field is used for attributes which provide a own
 schema and hold a refenece to a pyton instance 
 providing this schema. (does this make sense?)
 

Yes, it makes perfect sense to me.  I have LOTS of these in my
implementation.  

http://www.openehr.org/svn/ref_impl_python/TRUNK/oship/src/oship/openehr/ 

I just do not have working forms yet.  :-(  

I still have a lot to learn about z3c.form 

I am assuming, though haven't tried, that I can specify an interface
that is maybe 3,4 or more steps through Object attributes and have the
correct widget (text, textline, etc.) render? 

 
 The ObjectWidget is now responsible for render an input
 widgets in an EditForm for the color attribte of the door.

Sorry but I have *no clue* what this means. 

Cheers,
Tim


___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


Re: [Zope3-Users] thoughts about z3c.form-package

2008-10-08 Thread Adam GROSZER
Hello Tim,

Wednesday, October 8, 2008, 3:52:20 PM, you wrote:

TC I am assuming, though haven't tried, that I can specify an interface
TC that is maybe 3,4 or more steps through Object attributes and have the
TC correct widget (text, textline, etc.) render? 

It should, but actually those 3,4 levels sound like you'd need some
sort of subforms or even separated forms for those.
(I say that without having a look at your interfaces)

-- 
Best regards,
 Adam GROSZERmailto:[EMAIL PROTECTED]
--
Quote of the day:
All changes, even the most longed for, have their melancholy; for what we leave 
behind is a part of ourselves; we must die to one life before we can enter into 
another! 
- Anatole France 

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


Re: [Zope3-Users] thoughts about z3c.form-package

2008-10-08 Thread Roger Ineichen
Hi Tim
 
 Betreff: Re: AW: [Zope3-Users] thoughts about z3c.form-package
 
 On Wed, 2008-10-08 at 15:32 +0200, Roger Ineichen wrote:
   
   What is the proposed functionality of ObjectWidget?
  
  The ObjectWidget is a widget for an IObject field.
  This field is used for attributes which provide a own 
 schema and hold 
  a refenece to a pyton instance providing this schema. (does 
 this make 
  sense?)
  
 
 Yes, it makes perfect sense to me.  I have LOTS of these in 
 my implementation.  
 
 http://www.openehr.org/svn/ref_impl_python/TRUNK/oship/src/osh
 ip/openehr/ 
 
 I just do not have working forms yet.  :-(  
 
 I still have a lot to learn about z3c.form 

Don't forget to take a look at z3c.formdemo. This package shows many
different usecases.

I think we should probably write more demos which could show
some different concepts for z3c.form.

 I am assuming, though haven't tried, that I can specify an 
 interface that is maybe 3,4 or more steps through Object 
 attributes and have the correct widget (text, textline, etc.) render? 

I'm not sure if the widget works for nested objects. Which whould 
allow to render more then one level of objects.


  The ObjectWidget is now responsible for render an input 
 widgets in an 
  EditForm for the color attribte of the door.
 
 Sorry but I have *no clue* what this means. 

Oh, this was a comment to the sample in my mail. The color means
the IDoor.color attribute.

Regards
Roger Ineichen

 Cheers,
 Tim
 
 
 

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


Re: [Zope3-Users] thoughts about z3c.form-package

2008-10-08 Thread Roger Ineichen
Hi Hermann

 Betreff: Re: [Zope3-Users] thoughts about z3c.form-package

[...]

 I think I'm not the only one here, I read quite often about 
 similar problems in this list here, so this is my resumee:
 
 - z3c.form is complex
 - It's not obvious how to implement certain form-patterns
 - People are often overwhelmed by that and don't look through

I agree that if you use z3c.form and if you try to do some complex things
that it is not allways simple. But that's because z3c.form offers everything
what you need for doing what everybody needs. It's not only an
AddForm, EditForm or DisplayForm generator, z3c.form is much more.

in my point of view z3c.form.browser is just one (defualt) implementation
which is usable out of the box fo most HTML generting forms. The core of
z3c.form (without the browser package) can be used for other things then
HTML generated output.

 So, I think two solutions to that could be:
 
 - Improve the documentation (however, I'm unsure in what way, though).
 - Create a WIKI or something similar where people can find 
 suggestions how to implement certain patterns with z3c.form.

That's a very good idea

[...]

 - If we find patterns that can not be implemented with 
 z3c.form in a viable way, try to extend z3c.form so that it 
 is possible.

Yes, we should implement more things, e.g. the ObjectWidget
and better sub forms. Anything else?

 
 For me, this looks like the better approach than to trying to 
 implement a better form package that may lead to the very 
 same problems as z3c.form in the end.

I think it's an illusion ot write a simpler form package which
does a better job and is simpler at the same time. Every concept
will ha ve it own edges and limitations. But I whould agree that
it's possible to write a simpler form package which only has the 
goal to generate schema field based HTML widgets. But the problem is
if you are using such a package and you need to write a PDF generator
you can't probably use that simpler framwork and you have to find 
another way do to the same again.

Probably we can add another API for z3c.form and write a 
z3c.formzcml package which offers the same editForm and addForm
ZCML directives  which zope.app.form offers. This whould probably
make things simpler if you start using z3c.form.

Regards
Roger Ineichen

 Best Regards,
 Hermann
 
 --
 [EMAIL PROTECTED]
 GPG key ID: 299893C7 (on keyservers)
 FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7 
 ___
 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


Re: [Zope3-Users] thoughts about z3c.form-package

2008-10-08 Thread Hermann Himmelbauer
Am Mittwoch 08 Oktober 2008 16:28:07 schrieb Roger Ineichen:
 Hi Hermann

  Betreff: Re: [Zope3-Users] thoughts about z3c.form-package

 [...]
  So, I think two solutions to that could be:
 
  - Improve the documentation (however, I'm unsure in what way, though).
  - Create a WIKI or something similar where people can find
  suggestions how to implement certain patterns with z3c.form.

 That's a very good idea

 [...]

  - If we find patterns that can not be implemented with
  z3c.form in a viable way, try to extend z3c.form so that it
  is possible.

 Yes, we should implement more things, e.g. the ObjectWidget
 and better sub forms. Anything else?

Well, that looks like the major points. What I specifically need, are lists of 
ObjectWidgets (representing relations in an RDB).

  For me, this looks like the better approach than to trying to
  implement a better form package that may lead to the very
  same problems as z3c.form in the end.

 I think it's an illusion ot write a simpler form package which
 does a better job and is simpler at the same time. Every concept
 will ha ve it own edges and limitations. But I whould agree that
 it's possible to write a simpler form package which only has the
 goal to generate schema field based HTML widgets. But the problem is
 if you are using such a package and you need to write a PDF generator
 you can't probably use that simpler framwork and you have to find
 another way do to the same again.

Exactly.

 Probably we can add another API for z3c.form and write a
 z3c.formzcml package which offers the same editForm and addForm
 ZCML directives  which zope.app.form offers. This whould probably
 make things simpler if you start using z3c.form.

Hmmm, well, I'm not so sure about that. I personally have minor usage for such 
vanilla-implementations. At first, such things may suffice, but later on, I 
always needed some specific form behaviour that is not covered out of the 
box.

Moreover, z3c.form is complex, but it isn't hard if one knows what to do/how 
to do - which leads me back to my WIKI idea...

Best Regards,
Hermann

-- 
[EMAIL PROTECTED]
GPG key ID: 299893C7 (on keyservers)
FP: 0124 2584 8809 EF2A DBF9  4902 64B4 D16B 2998 93C7
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


Re: [Zope3-Users] thoughts about z3c.form-package

2008-10-08 Thread Tim Cook

(Thanks Roger and Adam for your earlier replies.)

On Wed, 2008-10-08 at 16:59 +0200, Hermann Himmelbauer wrote:

 Moreover, z3c.form is complex, but it isn't hard if one knows what to do/how 
 to do - which leads me back to my WIKI idea...

Hermann,

This is a very good point.  For those of us just trying to get a handle
on how to use z3c.form, in the best and most efficient way, a Wiki is a
great way to collect patterns.  

I think (feel?) that z3c.form is a very powerful package and the
documentation isn't bad either.  Some of us learn better by seeing
actual use cases though in order to adapt them to our own needs. 

This usually means that folks like Roger, Stephen, etc. can keep doing
what they do best (making the package better) and experienced users can
contribute their experiences and ideas via the Wiki.

(My 2 cents)

Regards,
--Tim


  

-- 
Timothy Cook, MSc
Health Informatics Research  Development Services
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
Skype ID == timothy.cook 
**
*You may get my Public GPG key from  popular keyservers or   *
*from this link http://timothywayne.cook.googlepages.com/home*
**

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


Re: [Zope3-Users] thoughts about z3c.form-package

2008-10-08 Thread garz

thx for your replies! now i have new stuff to think about. :)


Can you give an example what you can't do with z3c.form? 
i think z3c.form is in respect of what can be done with it general enough. i
can realize what i want to do with it plus i know how to do it. it isnt that
i dont understand z3c.form, i even think i nearly fully understand it. the
issue is, that i cant do it in a nice way and i think if z3c.form would be
structured differently, this shouldnt be a problem... at least i think that.
but maybe this will change after thinking about what you guys wrote. then i
will probably be back with new stuff to discuss, when i try to realize my
list- and dict-forms further on. :)


I have some ideas how I think a subform should be implemented.
 THe existing implementation doesn't fit. It at least has some
 issues if you write complex forms with complex action and handlers.
 
 The update order of a form and subform is an important part
 which doesn't fit in the existing implementation. 
since you mean by subform this:

A subform should be used to write forms with totaly different objects
 as context. A sub form can probably used for write a form for items
 in a container etc.
what are your imaginations about the problem that would arise? why should
the update-order should be an issue?


In general I see your point, z3c.form provides many, many hooks
 which looks like a little or big overhead.
this wasnt what i wanted to express. :D i dont think that there are too many
hooks, i like them and i think this is a really nice design with those
adapters. i have never seen this before and and know that i understand it i
can say that i learned a lot. =)



 Let's see what Adam Groszer is doing with the ObjectWidget
 implementation, probably this could be used for your use cases. 
this objectwidget would really be nice. i already have a working
implementation with my own subform-package that you took a look at. and i
already tried to turn it into an objectwidget, but then i didnt like the way
it would have to be done in z3c.form and i started thinking about a better
form-package and this thread was born. :D

but now, as i said, i will have to think over everything again. then i'll be
back. :D

until then i made a uml-graph, giving an overview over z3c.form-package. it
shows the classes, their methods and the hooks, conceptually. this means i
added the (from my point of view) most important things that show how
z3c.form works. it should be a lot easier studying z3c.form from this chart,
but combined with looking at the sources, if more detailed knowledge is
needed (and maybe i forgot a detail here and there :). all those hooks are
bold, interfaces are yellow and functions red. the file is in pdf-format and
the graph therefor is a vectorgraphic.

but subform- and groups-package are missing.

hope this helps. at least it should be a nice overview that prevents you
from looking at the sources too often. here it is:
http://rapidshare.de/files/40641861/z3c.form.pdf.html

greets garz
-- 
View this message in context: 
http://www.nabble.com/thoughts-about-z3c.form-package-tp19869292p19891158.html
Sent from the Zope3 - users mailing list archive at Nabble.com.

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


[Zope3-Users] Named layouts for z3c.pagelet

2008-10-08 Thread Ilshad
Hello,

I need use several layout templates in same layer for z3c.pagelet-based
browser views.
For this, in current project I did follow:

renderer.py:

from zope.component import getMultiAdapter
from z3c.template.interfaces import ILayoutTemplate

def layoutRenderer(self):
Allow to use named layout templates.
try:
   name = self.layout_name
except:
   name = u''

 self.update()
 if self.layout is None:
layout = getMultiAdapter((self, self.request),
ILayoutTemplate, name)
return layout(self)
 return self.layout()

So, a pagelet's code look like:

from  renderer import layoutRenderer

class Pagelet(object):
__call__ = layoutRenderer



and usual pass the name into zcml-directive:

z3c:pagelet
...
layout-name=narrow
/

And layout-directive from z3c.template allow define name.

Summary, it quite convenient. But my proposal - let's add this feature into
z3c.pagelet package.

-- 
Ilshad Habibullin
Gadoz, Inc (http://www.gadoz.com)
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


Re: [Zope3-Users] Named layouts for z3c.pagelet

2008-10-08 Thread Ilshad
For example, default empty layout_name in pagelet directive handler (and not
use try ... except).

2008/10/9 Ilshad [EMAIL PROTECTED]

 Hello,

 I need use several layout templates in same layer for z3c.pagelet-based
 browser views.
 For this, in current project I did follow:

 renderer.py:

 from zope.component import getMultiAdapter
 from z3c.template.interfaces import ILayoutTemplate

 def layoutRenderer(self):
 Allow to use named layout templates.
 try:
name = self.layout_name
 except:
name = u''

  self.update()
  if self.layout is None:
 layout = getMultiAdapter((self, self.request),
 ILayoutTemplate, name)
 return layout(self)
  return self.layout()

 So, a pagelet's code look like:

 from  renderer import layoutRenderer

 class Pagelet(object):
 __call__ = layoutRenderer

 

 and usual pass the name into zcml-directive:

 z3c:pagelet
 ...
 layout-name=narrow
 /

 And layout-directive from z3c.template allow define name.

 Summary, it quite convenient. But my proposal - let's add this feature into
 z3c.pagelet package.

 --
 Ilshad Habibullin
 Gadoz, Inc (http://www.gadoz.com)




-- 
Ilshad Habibullin
Gadoz, Inc (http://www.gadoz.com)
___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users


[Zope3-Users] ZCML Layout Decision?

2008-10-08 Thread Tim Cook
Hi All,

What are your thoughts on the best way to implement the configure.zcml
files for this application framework?

The framework is a nested structure up to five levels deep in places of
approximately 150 classes. 
  
Would it be better/more efficient to create a configure.zcml in each
package or just one at the top level?  

Another design decision is that this is a framework for application
developers and probably 99% of them will have no previous Zope
experience.  So teaching them how to setup zcml for their own security
declarations etc will be an issue as well.

Thanks,
Tim




-- 
Timothy Cook, MSc
Health Informatics Research  Development Services
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
Skype ID == timothy.cook 
**
*You may get my Public GPG key from  popular keyservers or   *
*from this link http://timothywayne.cook.googlepages.com/home*
**

___
Zope3-users mailing list
Zope3-users@zope.org
http://mail.zope.org/mailman/listinfo/zope3-users