Re: AW: [Zope3-dev] Re: AW: Are pagelets content providers?

2007-10-02 Thread Jacob Holm

Hi Roger,

I didn't follow this discussion closely but thought this needed a comment.

Roger Ineichen wrote:

[snip lots of context...]

Did you recognize that the __init__ are different.

A IContentProvider defines:

def __init__(self, context, request, view)
self.context = context
self.request = request
self.view = view

and a IPagelet defines:

def __init__(self, context, request):
self.context = context
self.request = request

Probably we should describe this in the interface too.
This whould manifest the difference of content provider
which provide content and pagelets whcih defines content
in a better way.
  
It would make sense to have the 'view' attribute a part of the 
IContentProvider interface, and *that* might make them different.  The 
constructor signature  is all about the class instead of the instance 
and should therefore *not* be part of the interface.


It is perfectly reasonable to have a number of different 
(multi-)adapters with different signatures that adapt to the same 
interface.


Hope this makes sense.  I'll go back to lurking now.

Regards

 Jacob

--
Jacob Holm
CTO
Improva ApS

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Re: [Z3d] 721/ 8 Comment Handling of empty prefixes in zope.formlib and zope.app.form

2006-12-20 Thread Jacob Holm

Christian Theune skrev:

Hi Jacob,

Jacob Holm wrote:
  
I don't have time to check it in now, but I will do it in a few days 
unless i hear otherwise.



I have now checked it in on the trunk, and backported to the 3.3 and 3.2 
branches.



I didn't see any change on this, if there is anything I can do to help
or support your, I'd be happy to do so.
  


You can tell me if there is anything else I need to do.


No worries if you're just short on time (we're all on Christmas
preparations!), I just wanted to follow up and keep this on the radar.
  


Thank you for reminding me.  In the rush to get everything done before 
Christmas I almost forgot.


--
Jacob Holm
CTO
Improva ApS


___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



[Zope3-dev] Re: [Z3d] 721/ 8 Comment Handling of empty prefixes in zope.formlib and zope.app.form

2006-12-12 Thread Jacob Holm

Hi, Christian

Ah. I didn't look right here too and mistook -3 as the alternative. I've
looked at -alt now and I like it more.
  

Sorry about the confusion. Thank you for taking the time to look again.

The name 'expandPrefix' doesn't strike me as very obvious, but I
couldn't find an alternative.
  
'expandPrefix' was the least bad name i could think of.  If anyone can 
suggest a better name I am all for changing it.

Nothing to say besides that. IMHO enough people already agreed in
general, so if I'd be you, I'd go ahead and check it in.
  
I don't have time to check it in now, but I will do it in a few days 
unless i hear otherwise.


Jacob

--
Jacob Holm
CTO
Improva ApS

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Handling of empty prefixes in zope.formlib and zope.app.form

2006-10-10 Thread Jacob Holm

Bjorn Tillenius skrev:

Since no one else commented, I guess I could do it. Personally, I think
it's OK. As you pointed out, having an id with a leading period is not
valid XHTML, so I'd be surprised if anyone would depend on it. It'd be
good to have someone responsible for zope.formlib +1 the patch, but if
no one gives it -1 one in the near future, it should be OK to merge it
anyway.
  

Thank you for taking the time to look at this.

It's a good sign that no existing tests failed, but you should of
course add tests for this functionality before merging.
  
Of course.  I have added the necessary tests in my local checkout. I 
will submit the updated patch as soon as zope.org starts responding again...
The patch is minimal in the sense that no API is changed, 
only the behavior related to empty prefix strings. Specifically it does 
not change the constructor of the (internal?) class 
zope.formlib.form.Widgets to take the actual prefix instead of just its 
length. Doing this would simplify the code and allow some sanity checks, 
but could cause breakage if the class is used anywhere else.



I think it's good to do it the way you did it. I have an example where
I use the Widgets class directly, so changing its API would be harder,
since you'd need to ensure backwards-compatibility.
  

Harder, but not too hard. Changing the signature to:

   def __init__(self, widgets, prefix_length=None, prefix=None):
   ...

And possibly deprecating the 'prefix_length' argument should do the 
trick.  Since the 'Widgets' class is undocumented, I wouldn't expect 
many uses outside zope.formlib.form, but i may be wrong.  (Note: The 
*class* is undocumented. The interface IWidgets is part of the public 
interface of zope.formlib, but this is irrelevant in in this discussion)
 
+def prefixjoin(*args):

+return '.'.join(filter(None,args))



I rarely see filter being used these days. Personally I prefer list
comprehensions instead.

return '.'.join([argument for argument in args if argument])

If you use filter there should at least be a space after the comma.

return '.'.join(filter(None, args))
  
I personally like 'filter' for being short and efficient, but don't care 
much either way. I agree that the space is needed for readability.

Although personally I wouldn't have bothered creating 'prefixjoin' at
all. The code it replaced was so simple, so I wouldn't say it's more
readable to have it factored it out into a function, and it would have
made the patch even smaller :) Also, the name of the function isn't
that clear. Sometimes it's used to join two prefixes, sometimes it's
used to join a prefix and a field name.
  
I agree that the name is less than perfect, and would definitely welcome 
suggestions for a better name.
As to whether the function is needed at all...  Having tried both with 
and without, I definitely think that having a separate function helps 
readability.

+
+def prefixlen(prefix):
+if not prefix:
+return 0
+return len(prefix)+1
+
 def setUpWidgets(form_fields,



Normally I would comment on the PEP-8 correctness, and say that the
top-level functions should be separated by two blank lines. I see that
you are consistent with the rest of the file, though, so I won't comment
on it.
Thank you for not commenting then ;-)   I tried to be consistent with 
the existing style.

  It wouldn't hurt being a bit inconsistent and add docstrings to
the added functions, though. Understanding the implementation of
zope.formlib can be quite hard at the moment, since there are
practically no docstrings at all. This is an excellent example where a
docstring is needed, since it's not easy to know whether the period
should be considered part of the prefix or not.
  
If the Widgets constructor is changed as suggested above, the 
'prefixlen' function could be removed.


That does not change the fact that the code is underdocumented though. I 
have added a docstring to prefixjoin in the patch I am about to upload.


--
Med venlig hilsen / Kind regards

Jacob Holm
CTO

Improva ApS
Symbion Science Park
Fruebjergvej 3, boks 46
2100 København Ø

Phone (+45) 3917 9801

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com



Re: [Zope3-dev] Handling of empty prefixes in zope.formlib and zope.app.form

2006-10-08 Thread Jacob Holm

I have created an issue for this in the tracker so it won't get lost. See:

 http://www.zope.org/Collectors/Zope3-dev/721

(I probably should have done this from the start)

Jacob

--
Jacob Holm
CTO
Improva ApS

___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com