[Zope3-dev] Re: adapter registration - sort of works :-S

2006-11-16 Thread Jean-Marc Orliaguet

Philipp von Weitershausen wrote:

Chris Withers wrote:

Chris Withers wrote:

Jean-Marc Orliaguet wrote:
once you have that utility / adapter you should be able to call it 
like:


  converter = getAdapterFor(123, type=IToStringConverter)
  strResult = converter.convert(123)


Not quite, what I'm looking to do is more along the lines of:

mystr = getAdapter(123,str)


OK, less talk, more do... and when I stop worrying about it, it all 
gets very easy:


  from zope.component import provideAdapter
  provideAdapter(str,(int,),str)
  from zope.component import getAdapter
  getAdapter(123,str)
'123'

Yay! That's _exactly_ what I want.


And that's exactly what I meant -- and wrote about half way up the 
thread. :)



Anyway, now all excited, I tried this:

  def to_date(value):
...   try:
... return DateTime(value)
...   except:
... return None
...
  provideAdapter(to_date,(str,int),DateTime)


This registers a multi adapter for (a_string, an_integer), like views 
are multi-adapters for (context, request). You want to say:


   provideAdapter(to_date, (str,), DateTime)
   provideAdapter(to_date, (int,), DateTime)



OK, but adaptation doesn't provide anything special here since int and 
str are not sufficiently typed, or formatted, so the adapter has to do 
all the guessing logic anyway, and there is no fundamental difference 
between 123456898374 as date representation  and '2006-11-16', or  061116


you might as well write a method that does that:

def to_date(value):

   if isinstance(value, int):
   ...
   else if isinstance(value, basestring):
   ...

this is why usually you don't adapt str or int, unless you're interested 
in tracing nasty bugs?


/JM


___
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: adapter registration question

2006-11-15 Thread Jean-Marc Orliaguet

Philipp von Weitershausen wrote:

Dieter Maurer wrote:

Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100:

...

def myStrAdapter(something):
   return str(something)
It instantiates a 'str' object. The 'str' object is the adapter for 
'something'.


Huh? This would be a severe terminology abuse:


I agree, it's bending the terminology a lot. It wasn't me who came up 
with the 'str' and 'int' example.



  An adapter should adapt something to something else *BUT*
  an str object does not adapt anything (it does not operate on
  another object).


Well, imagine

   str(123)
  '123'

Here '123' is the 'str' adapter of the integer 123. It's conceptually 
the same if you do


   IZopeDublinCore(myobj)

except that in the str(123) case, you call the class directly instead 
of using the Component Architecture's registry as a flexible dispatch.




But I guess Chris wanted to keep the registry lookup part, but not to 
have to adapt the context.


in other words a utility that converts something to a string based on 
the type to be converted.


once you have that utility / adapter you should be able to call it like:

  converter = getAdapterFor(123, type=IToStringConverter)
  strResult = converter.convert(123)

and reuse it:

  strResult2 = converter.convert(456)

that saves a lot of CPU / memory.

PS: calling '123' an adapter is really bending concepts.

/JM

___
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: adapter registration question

2006-11-15 Thread Jean-Marc Orliaguet

Philipp von Weitershausen wrote:

Dieter Maurer wrote:

Philipp von Weitershausen wrote at 2006-11-15 20:34 +0100:

Dieter Maurer wrote:

Philipp von Weitershausen wrote at 2006-11-15 15:08 +0100:

...

def myStrAdapter(something):
   return str(something)
It instantiates a 'str' object. The 'str' object is the adapter 
for 'something'.

Huh? This would be a severe terminology abuse:
I agree, it's bending the terminology a lot. It wasn't me who came 
up with the 'str' and 'int' example.



  An adapter should adapt something to something else *BUT*
  an str object does not adapt anything (it does not operate on
  another object).

Well, imagine

   str(123)
  '123'

Here '123' is the 'str' adapter of the integer 123. It's 
conceptually the same if you do


That's the terminology abuse:

   '123' is not an adapter because it does not do the adaption.

   '123' is the *result* of adapting 123 to 'str'.

   You may call '123' the 'str' adaption of the integer 123.

   IZopeDublinCore(myobj)

except that in the str(123) case, you call the class directly 
instead of using the Component Architecture's registry as a flexible 
dispatch.


With appropriate terminology use, you would call IZopeDublinCore
the adapter and IZopeDublinCore(myobj) the ZopeDublinCore
adaption (maybe adaptation) of myobj.

Again IZopeDublinCore(myobj) is not an adapter but an adapted value.


Not sure what official terminology glossary you're basing this on, 
but we often refer to IZopeDublinCore(myobj) as the IZopeDublinCore 
adapter of myobj. Whatever is called to instantiate that object we 
call the adapter factory or adapter implementation. The whole 
zope.component API (both registration and lookup) reflects this use of 
the terminology.





str(123) has the same syntax as IZopeDublinCore(myobj), but semantically 
there is nothing in common between the two expressions.


IZopeDublinCore(myobj) does an adapter lookup based on the type of 
'myobj' and returns an adapter instance with myobj as context, ready to 
be used.


but what problem is all this supposed to solve? are you guys writing a 
PhD or something .-) ?


/JM

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



[Zope3-dev] Re: adaptation based on class rather than interface

2006-11-13 Thread Jean-Marc Orliaguet

Philipp von Weitershausen wrote:

Jean-Marc Orliaguet wrote:

Lennart Regebro wrote:

On 11/9/06, Chris Withers [EMAIL PROTECTED] wrote:

Why do you say extra ZCML registration? You need that ZCML
registration whether or not you have to write the marker interface...


Sure, but with the marker interface you need only one. You need one
for each class, in your example, thats two. So the second one is
extra. :)


I think it is a mistake to use interfaces to specify what object 
_are_ as opposed to what they can _do_. It is better to use base 
classes for that. I agree with Chris that making classes adaptable 
would be simpler.


Classes *are* adaptable as has been said many times already. Let's 
please not make it sound like it's not possible.


Indeed technically yes. Practically not. I couldn't find many examples 
in the zope3 codebase that adapts classes.
The #1 pattern is to adapt from interfaces, it appears as though there 
is a reason for it.


So the best way to not make it sound so, is to use it so :-)




Interfaces were designed to specify what an object can do, e.g. a 
media player will do: play(), stop(), rewind(), without specifying 
the actual implementation ... whereas classes tell what objects are 
(an mp3 player, an LP player, a cassette player, ...), they are more 
specific to the object.


More generally, interfaces were designed to specify the *behaviour* of 
an object. Three basic types of behaviour have been identified in Zope:


* perform an action (method API)

* storing data (schema)

* assumed behaviour that can't be expressed in an API or schema 
(persistable, attribute annotatable, etc.)


The last use case is the one marker interfaces serve. A marker 
interface isn't any less of an interface. It just describes a 
different category of behaviour, one that can't be expressed through 
method or attribute APIs. It's still behaviour that we would like to 
express formally, and using interfaces for that seems the most logical 
solution.


Interface docstrings are as much part of the formal interface as 
method or attribute specifications! (Otherwise an interface could 
never mandate the type of an argument passed to a method, e.g. 
IContainer.__setitem__ only takes unicode or string names.)


yes, I agree. A perfect use case for interfaces without methods is when 
the specification cannot be expressed in a programmatic way. For 
instance persistable, etc. in that case only a natural language is 
appropriate.



FYI, the same discussion has occurred in Java (since there are marker 
interfaces there too and since there are interfaces too and the language 
does not prohibit using interfaces without methods). Are they an 
anti-pattern? An answer which I find perfectly valid is given at:


http://www.artima.com/intv/issuesP.html
under Appropriate Use of Marker Interfaces

however my reaction was against using interfaces without specification 
or interfaces with a very implicit and blurry specification, as in the 
cases described by Martin, in which he defends the use of marker 
interfaces basically as a way to tag classes externally (on/off 
switch, ...). A class annotation API would be better in that case, maybe 
based on the same internals as the interface API.




marker interfaces have empty specifications, that's the problem: 
they can't grow into real interfaces that have a specification. If 
you add methods to the marker interface you will have to track down 
all classes that implement the interface (unless you don't really 
care whether classes do implement their interface).


That's always a problem with interfaces. Whether or not an interface 
had specifications before or not, when you change an interface by 
adding a spec, you will *always* have to track down all 
implementations. That's why changing an existing, public interface 
isn't such a good idea. This argument has nothing to do with marker 
interfaces, though. It's a general problem of public interfaces.




yes, with the difference that marker interfaces have so little 
specification that they are almost meant to see their specification 
increase. That's what happened with all the magic flags and meta-tags in 
Zope2/CMF (isPrincipiaFolderish, meta_type, portal_type, ...). Using 
interfaces in that case does not solve the problem, and only shifts the 
problem to another area of the system.


as said in the article mentioned above, the same applies here:

[QUOTE] If the object you pass in has this marker interface, I will 
treat it in the following way. But I think that down that path lies 
darkness. Nobody knows the behavior of objects when they get their 17th 
marker interface. What if the object implements this marker interface 
and not this one, or this one and that one but not that other one? .

[END QUOTE]



All that said, I don't think we should overdo marker interfaces (like 
any kind of interface). I'm just saying they're not evil and it's not 
like they violate the pure truth of interfaces. The third category

Re: [Zope3-dev] Re: adaptation based on class rather than interface

2006-11-13 Thread Jean-Marc Orliaguet

Lennart Regebro wrote:

On 11/13/06, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote:

Indeed technically yes. Practically not. I couldn't find many examples
in the zope3 codebase that adapts classes.
The #1 pattern is to adapt from interfaces, it appears as though there
is a reason for it.


Yes, and I think both you and me mentioned it, but with different 
wordings.


If you specify it for a class, then only that class is adaptable. If
you want to use the adapter for yet another class, you have to
register it again. This is possible, but it's more flexible to specify
the adapter for an interface, and let all adaptable classes implement
that interface.



yes, but if you register an adapter for a base class you don't have to 
register it for subclasses, do you?
subclasses will pick up the same adapter. Provided that you use classes 
for typing your objects and not interfaces.


otherwise I withdraw what I previously wrote (that classes were 
adaptable) if that's for individual classes only. The basic force behind 
adapter registration (based on interfaces) is the principle of inheritance.



This is also a matter of specifying things for what they can do,
instead of for what they are, which you mentioned.

I'm not sure the proliferication (?) of marker interfaces is a big
risk. But if we get many of them, it still works better than the
options of magic __something__ attributes. :)



but conceptually it is the same mess :-) i.e. a total lack of 
specification. It only looks nicer with interfaces.


/JM


___
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: adaptation based on class rather than interface

2006-11-11 Thread Jean-Marc Orliaguet

Martin Aspeli wrote:

Jean-Marc Orliaguet wrote:

And there is nothing wrong with using inheritance when there is a 
'__IS A __' type of relation (e.g. an ordered folder IS A folder IS 
AN item, ...), or if there is a HAS_A type of relation (a folder has 
items, a chair has four legs...). It seems that Zope3 has banned all 
form of class inheritance, even those that made sense, and that would 
have simplified the implementation.


That is totally, utterly, patently rubbish. Devise some regular 
expression and grep the zope 3 source code for inheritance.




I was just expressing an opinion :-)  let me explain then:

subclassing is not used in zope3 as a method for assembling components, 
as it was used in zope2. In zope2, if you mix a folder with a catalog 
aware mixin, you'd have a catalog-aware folder because the functionality 
is expressed in the mixin class, not outside. In zope3 if you subclass a 
container you still have a container, it won't make the container more 
specialized. Now of course zope3 uses subclassing internally to avoid 
duplicating code. No need to devise a grep tool to know that.



marker interfaces have empty specifications, that's the problem: 
they can't grow into real interfaces that have a specification. If 
you add methods to the marker interface you will have to track down 
all classes that implement the interface (unless you don't really 
care whether classes do implement their interface).


Marker interfaces by design serve a different purpose than other 
interfaces. They are the equivalent of an on/off switch about object 
behaviour or purpose that is externalised from that object (i.e. they 
are not just booleans in a schema, they are potentially managed 
outside that class).


Martin



I don't think that marker interfaces were ever designed, they are the 
result of pushing a design to its limits, without knowing what an 
interface is supposed to mean in the first place. That's what happens 
when implementation gets confused with design, and when one feels the 
need to unify everything. It would have been better to have a common API 
for accessing or registering meta-information about classes, this is 
what marker interfaces do in the end since in their *implementation* 
they are stored in a class attribute ('__implemented__'), but that 
implementation feature should not be exposed to the programmer through 
the 'interface' API. Otherwise the concepts don't mean anything anymore.


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



Re: [Zope3-dev] adaptation based on class rather than interface

2006-11-09 Thread Jean-Marc Orliaguet

Lennart Regebro wrote:

On 11/9/06, Chris Withers [EMAIL PROTECTED] wrote:

Why do you say extra ZCML registration? You need that ZCML
registration whether or not you have to write the marker interface...


Sure, but with the marker interface you need only one. You need one
for each class, in your example, thats two. So the second one is
extra. :)



I think it is a mistake to use interfaces to specify what object _are_ 
as opposed to what they can _do_. It is better to use base classes for 
that. I agree with Chris that making classes adaptable would be simpler.


Interfaces were designed to specify what an object can do, e.g. a media 
player will do: play(), stop(), rewind(), without specifying the actual 
implementation ... whereas classes tell what objects are (an mp3 player, 
an LP player, a cassette player, ...), they are more specific to the object.


And there is nothing wrong with using inheritance when there is a '__IS 
A __' type of relation (e.g. an ordered folder IS A folder IS AN item, 
...), or if there is a HAS_A type of relation (a folder has items, a 
chair has four legs...). It seems that Zope3 has banned all form of 
class inheritance, even those that made sense, and that would have 
simplified the implementation.


marker interfaces have empty specifications, that's the problem: they 
can't grow into real interfaces that have a specification. If you add 
methods to the marker interface you will have to track down all classes 
that implement the interface (unless you don't really care whether 
classes do implement their interface).


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



Re: [Zope3-dev] selecting the translation domain in ZCML

2006-06-05 Thread Jean-Marc Orliaguet

Dieter Maurer wrote:

Jean-Marc Orliaguet wrote at 2006-5-30 22:13 +0200:
  

...
Dieter Maurer wrote:
...


In my view the translation domain is vital for translators --
as the domain guides the correct translations.
  

...
But it is the application that eventually sets the domain name to use, 
based on the context. Translators have no control over it, since they 
have no control over page templates or over python code.



You are right, of course: translators do not chose the domain
but are informed about it. However, this does not contradict
that the translation domain is specified in the .po file -- as
the translations in this file are only valid in the
translation domain for which they have been made...

  


It's a practical issue, I think. The way I'm organizing translations 
right now is that I'm creating a folder (named 'locales' for instance) 
with different languages 'en', 'fr' in it. So far no difference.


then inside the LC_MESSAGES folders I will place categories of translations:

- widgets.po
- portlets.po ...

see for example: 
http://svn.z3lab.org/trac/z3lab/browser/cpsskins/branches/paris-sprint-2006/standard/locales


this is instead of having one big .po file that contains everything. 
I've noticed that it's difficult to create and maintain sections inside 
a .po file. The categorization is done here on the filename. So not 
having a hardcoded filename - domain is an advantage.


also notice that few packages register translations in several domains.

Hence, the translators are only concerned with putting translations into 
folders ('business_terms', 'furniture', ...), no matter what the domain 
name will be called.



But why would you want a different domain name than that communicated
to the translators? Do you prefer meaningless over strong names?

  


put it the other way around: if you communicate a domain name to 
translators you have to inform them whenever the domain name changes.


I've just written a mergeTranslations directive, it's rather simple to use:
http://svn.z3lab.org/trac/z3lab/browser/cpsskins/branches/paris-sprint-2006/configuration/i18n/metaconfigure.py

the ZCML is:
cpsskins:mergeTranslations domain=cpsskins directory=locales /

I guess that 01_..., 02_... or some other filename scheme could be used 
to control the merge order in case some translations should override 
other translations.


Regards /JM
___
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: selecting the translation domain in ZCML

2006-06-01 Thread Jean-Marc Orliaguet

Philipp von Weitershausen wrote:

Dieter Maurer wrote:
  

Jean-Marc Orliaguet wrote at 2006-5-30 12:01 +0200:


...
although -- while thinking about it, putting the domain name in .po 
files breaks the separation on concerns between translators and 
application developer. Translators shouldn't have to worry about 
translation domains. That's application specific.
  

Are you sure? In my view the translation domain is vital for translators --
as the domain guides the correct translations.

For example, in German we have the word Bank.
It may mean bench or bank, depending on the translation domain.



That's not how we typically use translation domains, though. In most
projects, one translation domain denotes all the translations of a
particular piece of software (a library, an application, etc.). So Zope
use 'zope', Plone uses 'plone', etc.

In order to avoid ambiguities like the one you mentioned, it is
recommended to use explicit message ids whereever short labels occur, e.g.:

  p i18n:translate=bank-financialBank/p

Then 'bank-financial' is the message id for this message. In longer
sentences, this often isn't necessary because ambiguities will be
resolved by the context:

  p i18n:translate=Please go to the bank and get some money/p

Of course, your example is a bit backwards because the ambiguity isn't
in English (which typically is the source language), but in German. In
most cases, the ambiguities come from English, though, for example
because verbs and nouns are spelt the same way.

Philipp
  
yes that's the use case I have (1 domain = 1 application/package). I'm 
using dotted names to create namespaces or subdomains inside a same 
domain (e.g. cpsskins.widget.dropdownMenu)


the actual need right now is to be able to merge translations , i.e. for 
a package to be able add translations into another domain or to override 
an other package's translations. That's two use cases that can be merged 
into one.


there might be an issue with ZCML configuration stages. It should be 
made possible in ZCML to specify the order in which domains are loaded 
or merged, a bit like with UNIX rc scripts.


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



[Zope3-dev] selecting the translation domain in ZCML

2006-05-30 Thread Jean-Marc Orliaguet


Hi!

there is currently one i18n ZCML directive for registering translations:

i18n:registerTranslations directory=locales /

it uses filenames (LC_MESSAGES/en/mydomain.po) to determine the domain 
name (here: 'mydomain').


this is OK for most use cases because packages manage their own domain, 
but there is a case which I don't know how to solve, i.e.  when a 
package is supposed to register translations into another package's 
translation domain?.


what is the solution? add an option in i18n:registerTranslations? such as:

i18n:registerTranslations directory=locales domain=mydomain /

and let the ZCML handler update existing catalogs?

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



Re: [Zope3-dev] selecting the translation domain in ZCML

2006-05-30 Thread Jean-Marc Orliaguet

Wichert Akkerman wrote:

Previously Jean-Marc Orliaguet wrote:
  
this is OK for most use cases because packages manage their own domain, 
but there is a case which I don't know how to solve, i.e.  when a 
package is supposed to register translations into another package's 
translation domain?.



A po file includes its domain in its header; I'm assuming zope is smart
enough to extract and use that. If not - please fix that :)

Wichert.

  


In fact, I tried that - it worked in Zope2, but not here. Every time a 
.po file is loaded a new translation domain is registered as a utility 
otherwise there is a domain name conflict.


I agree that would be the most elegant solution.

/JM

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



Re: [Zope3-dev] selecting the translation domain in ZCML

2006-05-30 Thread Jean-Marc Orliaguet

Jean-Marc Orliaguet wrote:

Wichert Akkerman wrote:

Previously Jean-Marc Orliaguet wrote:
 
this is OK for most use cases because packages manage their own 
domain, but there is a case which I don't know how to solve, i.e.  
when a package is supposed to register translations into another 
package's translation domain?.



A po file includes its domain in its header; I'm assuming zope is smart
enough to extract and use that. If not - please fix that :)

Wichert.

  


In fact, I tried that - it worked in Zope2, but not here. Every time a 
.po file is loaded a new translation domain is registered as a utility 
otherwise there is a domain name conflict.


I agree that would be the most elegant solution.

/JM



although -- while thinking about it, putting the domain name in .po 
files breaks the separation on concerns between translators and 
application developer. Translators shouldn't have to worry about 
translation domains. That's application specific.


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



Re: [Zope3-dev] selecting the translation domain in ZCML

2006-05-30 Thread Jean-Marc Orliaguet

Dieter Maurer wrote:

Jean-Marc Orliaguet wrote at 2006-5-30 12:01 +0200:
  

...
although -- while thinking about it, putting the domain name in .po 
files breaks the separation on concerns between translators and 
application developer. Translators shouldn't have to worry about 
translation domains. That's application specific.



Are you sure? In my view the translation domain is vital for translators --
as the domain guides the correct translations.

For example, in German we have the word Bank.
It may mean bench or bank, depending on the translation domain.

  


But it is the application that eventually sets the domain name to use, 
based on the context. Translators have no control over it, since they 
have no control over page templates or over python code.


My view is that the translations can still be stored in different 
folders (one per translation context as you mentioned) and the domain 
can be set in ZCML during the configuration of the application for an 
entire folder, globally.


Hence, the translators are only concerned with putting translations into 
folders ('business_terms', 'furniture', ...), no matter what the domain 
name will be called.


In this way, changing a domain name or creating a new one is done once, 
instead of being done for each po files.


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



Re: [Zope3-dev] Zope 3 lacks Ajax capability?

2006-05-15 Thread Jean-Marc Orliaguet

Jeff Rush wrote:
Just checking if I'm missing something -- with the removal of HTTP 
streaming/chunking in 3.2, this means that the async bi-directional 
persistent socket communications associated with Ajax is NOT possible 
at this time?  That a request/response must quickly run to completion 
on a thread and cannot hang on to that thread to asynchronously 
communicate with the client?


I've been doing this in Twisted (actually Nevow's live page API) and 
had hoped to migrate some code over to Zope3.  Since Zope3 
incorporates Twisted, I'm wondering if I can beat on it enough to be 
able to run my Twisted code underneath the existing Zope3/Publisher 
arrangement.


If anyone is currently doing Ajax in Zope3, I'd be interested in 
talking with them.  I saw a brief flurry of emails some months ago 
about adopting one of the existing Javascript frameworks and then 
adjusting Zope3's API to generically work with any such framework but 
no further discussion since.


-Jeff



do you mean HTTP streaming? http://ajaxpatterns.org/HTTP_Streaming

I recently noticed something that makes it tricky to use zope3 in 
conjunction with Ajax: the request ID computed from the browser via a 
standard HTTP request/response pattern is different from the id obtain 
with XMLHttpRequest calls - which makes it rather tricky to use zope3 
session id with Ajax (the same browser is seen as 2 different browsers).


maybe setting up a page on the z3 wiki that lists current issues with 
Ajax could be a good start?

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



[Zope3-dev] zope3 bug day?

2006-05-09 Thread Jean-Marc Orliaguet

Hi there!

is there a zope3 bug day planned soon? there are a couple of bugs that 
I'd like to fix but I don't want to do it now in the midst of the 
release process.


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



Re: [Zope3-dev] help with directlyProvides

2006-05-08 Thread Jean-Marc Orliaguet

Dominik Huber wrote:

luis wrote:

Jean-Marc Orliaguet wrote:

 

luis wrote:

are you sure? I tried with:

[EMAIL PROTECTED] ~/Zope3/src $ python2.4
Python 2.4.2 (#1, Dec  4 2005, 15:28:38)
Type help, copyright, credits or license for more information.
  from zope.app.file import file
  f = file.File()
  f
zope.app.file.file.File object at 0xb7cbad2c
  import zope.interface
  class IMarker(zope.interface.Interface):
...  Marker interface
...
  zope.interface.directlyProvides(f, IMarker)
  list(zope.interface.directlyProvidedBy(f))
[InterfaceClass __main__.IMarker]
  IMarker.providedBy(f)
True



yes.. that's why I say that it seems very strange... the call to
directlyProvides works as you show with your example, ... *but*, 
after you
add your file to a folder, something removes the IMarker interface 
(or it

doesn't get saved for some reason )

directlyProvides( f, IMarker )
if not IMarker.providedBy( f ):
raise Error
myfolder['f'] = f

if you put something like that in an Adding-Form, no exception is 
raised and

the object f is added to the container. so the directlyProvides does
work...but then, if you take a look at the object f in the zmi
introspector, you will see something like:
DirectlyProvided interfaces
nothing

so what I'm saying is not that directlyProvides doesnt work, but that
provided-list gets lost somewhere on the way into the database... 
(but if f

is  a Folder, then the provided-list is kept )

luis
  
If there is a bug in the container framework my assumption would be 
that that the following part of code causes your problem. The regular 
container asserts IContained either by the directlyProvides mechanism 
if the item provides ILocation or else by a ContainedProxy.


zope.app.container.contained line 325:
  [...]
   if not IContained.providedBy(object):
   if ILocation.providedBy(object):
   zope.interface.directlyProvides(
   object, IContained,
   zope.interface.directlyProvidedBy(object))
   else:
   object = ContainedProxy(object)
  [...]

First try to provide IContained to your File implementation using the 
following zcml entry:


class class=.to.your.File 
 implements =.zope.app.container.interfaces.IContained /
/class

That should solve the problem.

If yes, could you track down if the problem: Is it caused by the 
directlyProvided mechanism or by the ContainedProxy?


(If no, perhaps a persistency problem?)

Regards,
Dominik




by what I can tell, it's the ContainedProxy line:

object = ContainedProxy(object)

that removes all directly provided interfaces on all types of objects 
not just files. With folders ContainedProxy() is not called.


/JM
___
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: help with directlyProvides

2006-05-07 Thread Jean-Marc Orliaguet




luis wrote:

  Jean-Marc Orliaguet wrote:

  
  
sorry I thought you wanted to do something else.. maybe you want to use
'alsoProvides' if it is to set a marker, to avoid removing other
interfaces that the file might provide?

/JM

  
  
nop. that's not it... I still havn't figured it out, but it seems very
strange to me. it seems like folder-like objects work, but content-like
objects don't..

for example

folder = Folder()
interface.directlyProvides( folder, IMarker )
file = File()
interface.directlyProvides( file, IMarker )
root['folder'] = folder
root['file'] = file

would leave "folder" directly providing the "IMarker" interface, but "file"
directly providing nothing.
the other strange thing is that the interface seems to be added to the
provided-list, but then it is removed again later...so when you look at the
introspector tab in the zmi, it's gone.

regards.luis

  


are you sure? I tried with:

[EMAIL PROTECTED] ~/Zope3/src $ python2.4
Python 2.4.2 (#1, Dec 4 2005, 15:28:38)
Type "help", "copyright", "credits" or "license" for more information.
 from zope.app.file import file
 f = file.File()
 f
zope.app.file.file.File object at 0xb7cbad2c
 import zope.interface
 class IMarker(zope.interface.Interface):
... """Marker interface"""
... 
 zope.interface.directlyProvides(f, IMarker)
 list(zope.interface.directlyProvidedBy(f))
[InterfaceClass __main__.IMarker]
 IMarker.providedBy(f)
True

hope it helps
/JM




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



[Zope3-dev] SimpleKeyReference

2006-05-06 Thread Jean-Marc Orliaguet


Hi,

I have a use case for using key references to non-persistent objects, so 
I'd like to use: zope.app.keyreference.testing.SimpleKeyReference


but the import path is just a bit weird:
any problem with renaming: zope/app/keyreference/testing.py to 
zope/app/keyreference/simple.py ?


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



Re: [Zope3-dev] help with directlyProvides

2006-05-04 Thread Jean-Marc Orliaguet

luis wrote:


Hi all,

I asked this a while ago in the zope3.user list but had no luck, so I'll try
it here now..

I'm having problems getting interface.directlyProvides to work...
does anyone know why the following code doesn't work (file is created, but
it doesnt provide the IMarker interface...)

thanks and regards,
luis

###
class IMarker(interface.Interface):
marker test interface 
   
 




Hi, shouldn't it be, instead:

from zope.interface.interfaces import IInterface

class IMarker(IInterface):
   ...

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



Re: [Zope3-dev] help with directlyProvides

2006-05-04 Thread Jean-Marc Orliaguet

Jean-Marc Orliaguet wrote:


luis wrote:


Hi all,

I asked this a while ago in the zope3.user list but had no luck, so 
I'll try

it here now..

I'm having problems getting interface.directlyProvides to work...
does anyone know why the following code doesn't work (file is 
created, but

it doesnt provide the IMarker interface...)

thanks and regards,
luis

###
class IMarker(interface.Interface):
marker test interface 





Hi, shouldn't it be, instead:

from zope.interface.interfaces import IInterface

class IMarker(IInterface):
   ...

/JM



sorry I thought you wanted to do something else.. maybe you want to use 
'alsoProvides' if it is to set a marker, to avoid removing other 
interfaces that the file might provide?


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



[Zope3-dev] registration of local utilities through-the-web

2006-05-03 Thread Jean-Marc Orliaguet


Hi!

I think I've identified an issue with the TTW local utilities 
registration (svn trunk), I'm not sure how this is solved (it could be a 
bug):


I have a folder that acts as a persistent components registry:

   class SomeFolder(..., PersistentComponents)
   implements(ISomeFolder)

which means that it can hold information about locally registered 
utilities, adapters, ...


The problem is that when I register a SomeFolder as a local utility, 
instead of getting registered in the site manager above, it gets 
registered in itself, so basically it never gets registered in the 
application.


to reproduce the issue simply subclass PersistentComponents, and do a 
PersistentComponents.__init__(...) on an existing component (.e.g 
HelloWorld); you will be able to register it as a local utility but it 
won't appear in the site manager's registrations.


Any idea?

regards
/JM


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



Re: [Zope3-dev] registration of local utilities through-the-web

2006-05-03 Thread Jean-Marc Orliaguet

Jean-Marc Orliaguet wrote:



Hi!

I think I've identified an issue with the TTW local utilities 
registration (svn trunk), I'm not sure how this is solved (it could be 
a bug):


I have a folder that acts as a persistent components registry:

   class SomeFolder(..., PersistentComponents)
   implements(ISomeFolder)

which means that it can hold information about locally registered 
utilities, adapters, ...


The problem is that when I register a SomeFolder as a local utility, 
instead of getting registered in the site manager above, it gets 
registered in itself, so basically it never gets registered in the 
application.


to reproduce the issue simply subclass PersistentComponents, and do a 
PersistentComponents.__init__(...) on an existing component (.e.g 
HelloWorld); you will be able to register it as a local utility but it 
won't appear in the site manager's registrations.


Any idea?

regards
/JM



well, the bug is here:

zope/app/component/browser/registration.py

   @form.action(_(Register))
   def register(self, action, data):
   sm = component.getSiteManager(self.context)

in that case 'sm' and 'context' are the same.

I've filed a bug at:
http://www.zope.org/Collectors/Zope3-dev/597

a solution would be to get the site manager on the parent folder, eg.

  if sm == context:
   sm = component.getSiteManager(getParent(context))

  ...
/JM

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



[Zope3-dev] getInterface()'s context parameter

2006-04-25 Thread Jean-Marc Orliaguet


Hi,

zope.component.getInterface takes a 'context' as a parameter, which is 
unused practically or set to None.


def getInterface(context, id):
   iface = queryInterface(id, None)
   if iface is None:
   raise ComponentLookupError(id)
   return iface

is it a relic from an old API? why not simplify it to getInterface(id) ?

regards
/JM

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



[Zope3-dev] [ANN] CPSSkins4Five and CPS4/Z3ECM Paris sprint report

2006-04-23 Thread Jean-Marc Orliaguet


Hi!

I've written a report on the work I did during the CPS4/Z3ECM sprint i 
Paris:
http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2006_04_23_cps4-z3ecm-paris-sprint 



there is also a new zope2 product called CPSSkins4Five for running 
cpsskins (for zope3) on zope2 .

http://svn.z3lab.org/trac/z3lab/browser/CPSSkins4Five/trunk/

here is an animation too:
http://www.z3lab.org/sections/front-page/design-features/cpsskins4five-preview 



all this is very experimental and requires branches that haven't been 
merged into zope2/zope3/five trunks yet. But as a proof-of-concept it 
works.


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



[Zope3-dev] [DRAFT] Uniform resource identifiers (cpsskins)

2006-03-27 Thread Jean-Marc Orliaguet



Hi!

I've began formalizing some ideas about how to identify application 
resources:

http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/io/README.txt

I post to zope3-dev too in case someone has some ideas about it. A lot 
of the points described are pertinent to zope3.


The background is the following:

Being able to identify application resources is important. First we want 
to identify what *type* of resource we have (a portlet, a widget, a 
style, ..) then we want to identify the resource itself in the context 
of the application, for instance if a portlet named '12345' is a unique 
instance of an object, a slot named '12345' will refer to a collection 
of objects, not to an individual instance.


So to start with the resource's own identifier:
The object's id in a container is not necessarily the id that is 
interesting (for instance if an item gets moved from a folder to another 
folder there can be id conflicts even though being located in a folder 
is nothing special for a resource, it might be an accidental thing).


In cpsskins the resource's id is the name of the resource in the 
*context of a relation*.  Hence resources are IRelatable:


   unicode(IRelatable(resource))

returns the resource's name in a relation. It is the only identifier 
that is used throughout the application to refer to the resource, ie. to 
register the resource, to customize it, to set it in relation with 
another resource, etc.


Note that in the case of containment  there are implicit container - 
parent container relations, so that item ids are also defined in the 
context of a relation it is just that these ids are only unique inside a 
same container.


Then we have the resource's type(s). Zope3 uses dotted names (e.g. 
widget.textinput) as well as interfaces (e.g. 
zope.form.widgets.interfaces.ITextInput) to identify object types. Both 
approaches provide a way of having unique identifiers mostly by creating 
namespaces.


The issue with dotted names is that there are no explicit rules for 
creating the names between the dots. Enforcing a policy can be difficult 
especially across different applications. The categorizations may change 
and renaming resources is not trivial. However dotted names are easy to 
transport (they are URL-friendly, they can be embedded in any export 
format XML, json, ...).


The issue with interfaces used as identifiers is that packages are often 
reoganized and the resources often change name. The coupling is very 
tight between the application's package organization on the filesystem 
and the way the data is described. This can be seen already now in ZCML: 
whenever packages are moved, a lot of search and replace must be done on 
existing configuration files. Using interface names (with the entire 
package page) in an XML export does not guarantee that the data will be 
usable in upcoming versions of the same application. We are not even 
talking about trans-typing, but just about tracking resource types that 
change names. The positive aspect about interfaces is that it is 
possible to query the type of an object using


  queryType(object, InterfaceType)

to get the type of the object.

The solution sketched here tries to combine the advantage of dotted 
names with the flexibility of interfaces.


First we do a categorization of resources according to three different 
types. In cpsskins we have:


IElementType, IResourceType, IContentType

IElementType is a first-level categorization, IResourceType a 
second-level categorization and IContentType is a third level (it is 
zope.app.content.interfaces.IContentType). There could be more levels, 
but this is enough for now.


Typically portlets are part of a 'canvas' so their element type is 
'canvas', their resource type is 'portlet' and their content type is for 
instance 'cpsskins.actions', so the URI of a portlet would be:


  'canvas-portlet-cpsskins.actions-12345'

(if '12345' is the identifier of the portlet instance)

which we can obtain directly with:

  IIdentifiable(resource).getURI()

Let us say we have a 'widget', -- in cpsskins a format element because 
it adds a format to displayed elements, then it will be identified as:


  'format-widget-cpsskins.somewidget-12345'

whereas a widget in the context of a form would be identified as:

  'form-widget-formlib.textinput-12345'


the names between the '-' signs are tagged names attached to interfaces. 
It doesn't matter if two different interfaces have the same name since 
unicity is created by combining the names. For instance we have:


  resource = Style()
  resource_type = queryType(resource, IResourceType)
  resource_type.getTaggedValue('name')
  = u'style'

  or one can also write:

  IType(resource).resourcename

So a short name is associated to an interface type that is the basis for 
creating a URI, and conversely it is possible to match URIs to interfaces:


for instance  IActionPortlet ('cpsskins.actions') extends ICanvas 
('canvas') and 

[Zope3-dev] set of interfaces?

2006-03-22 Thread Jean-Marc Orliaguet


Hi!
what is the best way in zope3 to create a collection of interfaces 
without using classes, lists, etc.?


I have a number of interfaces that I'd like to group into a same 
interface category.


e.g. ISomeCollection  = I1, I2, I3, I4 

and I'd like to be able to query which interfaces ISomeCollection 
contains. However I'd like not to instanciate a registry just to hold 
that type of information.


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



Re: [Zope3-dev] zope.configuration

2006-03-17 Thread Jean-Marc Orliaguet

Jim Fulton wrote:


Stephan Richter wrote:


On Friday 17 March 2006 06:34, Jim Fulton wrote:


The idea is that after applying configuration, you'd keep the
resolved sequence of actions around so that you could call their undo
methods later.




Of course, the undo feature has other benefits, such as reloading 
functionality without restarting the server. Or at least this is one 
required step.



I'm skeptical of this.

Jim



any plan to have something like component hotplugging, i.e. 
registering and unregistering a set of directives without restarting the 
server?


/JM

___
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: a new zcml directive?

2006-03-16 Thread Jean-Marc Orliaguet

Martijn Faassen wrote:


Philipp von Weitershausen wrote:


Martijn Faassen wrote:


I stand by my conclusions on this approach sounding simple in theory,
but still being a bit harder than it should be in practice. :)



I think this is pretty simple:

def makeAnnotationAdapter(for_, factory, key):
  @zope.component.adapter(for_)
  @zope.interface.implementer(IAnnotations)
  def annotationAdapter(context):
  annotations = IAnnotations(context)
  try:
  return annotations[key]
  except KeyError:
  ob = factory()
  annotations[key] = ob
  # to please security...
  zope.app.container.contained.contained(
  ob, context, 'foobar-whatever')
  return ob
  return annotationAdapter

getFoo = makeAnnotationAdapter(IFoo, Foo, FOO_KEY)
 
Perhaps I'm missing something?!?



It's not as simple as your code actually doing to what it needs to do. :)

It doesn't do what it needs to do as we're not aiming to implement 
IAnnotations here, but whatever the factory is implementing. I also 
would like to avoid having to specify for_, as the factory should 
already specify this information.


But it's definitely simpler, if, as you do, know the zope.interface 
and zope.component APIs, and how various things can be used as 
decorators. I hadn't used them yet.


Yesterday I had something that worked if I specified both 'for' and 
'implements' in ZCML; it was pretty close to what you had without the 
decorator bits. I modified it today using your decorator idea and it 
appears to work now:


def factory(factory, name, key):
@zope.component.adapter(
list(zope.component.adaptedBy(factory))[0])
@zope.interface.implementer(
list(zope.interface.implementedBy(factory))[0])
def getAnnotation(context):
annotations = IAnnotations(context)
try:
return annotations[key]
except KeyError:
result = factory()
annotations[key] = result
zope.app.container.contained.contained(
result, context, name)
return result
# Convention to make adapter introspectable
# (XXX where is this used? is this necessary at all?)
getAnnotation.factory = factory
return getAnnotation

You can use this with the following Python code and ZCML:

class MyAnnotation(Persistent):
implements(interfaces.IFoo)
adapts(interfaces.IBaz)

getMyAnnotation = annotation.factory(MyAnnotation, 'my_annotation',
'some_key')

adapter factory=.module.getMyAnnotation trusted=yes /

I hope I can still make the requirement for name and key go away.

In many ways this behaves very similarly to the adapter ZCML directive 
(as I did peek at its implementation :).


I realize I may be in the minority on this particular mailing list, 
but to me the implementation of this code wasn't pretty simple. If 
this is the way we are going to encourage people to build higher level 
abstractions for definition, we may lose some of them.


Regards,

Martijn



Hi,
excuse me, but can someone explain what problem the pattern / workaround 
is supposed to fix, does it create and return a default annotation value 
in case an annotation key does not exist? shouldn't the annotation 
machinery be fixed instead to provide getAnnotation(..., default=...) ?


/JM
___
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: a new zcml directive?

2006-03-16 Thread Jean-Marc Orliaguet

Martijn Faassen wrote:


Jean-Marc Orliaguet wrote:
[snip]



excuse me, but can someone explain what problem the pattern / 
workaround is supposed to fix, does it create and return a default 
annotation value in case an annotation key does not exist? shouldn't 
the annotation machinery be fixed instead to provide 
getAnnotation(..., default=...) ?



I thought I described it in my initial post.

I was looking for a way to register annotations for objects (and 
create them if they aren't there yet) without having to write fairly 
long bits of code for each annotation factory.


I just want to be able to say:

myannotation = IFoo(obj)

where IFoo is the interface of an annotation of the obj. The only 
place I worry about it being an annotation is in the registration 
code. No need to import anything else from that package. Whether it 
needs to create a new annotation or get an existing one is an 
implementation detail.


Regards,

Martijn



OK, basically you mean that the 'annotations' given in your original 
post should implement a 'setdefault' method?


regards
/JM
___
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: a new zcml directive?

2006-03-16 Thread Jean-Marc Orliaguet

Martijn Faassen wrote:


Jean-Marc Orliaguet wrote:
[snip]

OK, basically you mean that the 'annotations' given in your original 
post should implement a 'setdefault' method?



I don't see how that would help - you'd still end up writing a factory 
that uses the setdefault, right?


I don't want to keep repeating factory code each time I want to do 
this, including factory code that calls IAnnotations(), uses 
setdefault() or anything else. I just want to say, I want to make an 
adapter that uses this standardized factory code. How the factory code 
does this is not very interesting, it's just that I don't want to keep 
writing it over and over.


Regards,

Martijn



OK, you could pass the interface of the factory to the getter method and 
let it create the object based on this information. That wouldn't be 
exactly like setdefault(), but at least the factory code would be in the 
called method, not in the caller.


If I remember correctly the pattern I'm using (which I still think is 
OK) is to register a factory as a global utility and look up the factory 
by its interface.


so for instance to create a style or type IStyle, I register:

 cpsskins:setting
 name=style
 schema=.style.IStyle
 factory=.style.StyleFactory
 /

with:

def setting(_context, name=u'', schema=None, factory=None):
...
   provideUtility(factory, IFactory, name)

then the annotation getter can contain a 'factory = getUtility(IFactory, 
name)'


regards
/JM

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



Re: [Zope3-dev] what is ZCML?

2006-03-15 Thread Jean-Marc Orliaguet

Jim Fulton wrote:



I'd also like to acknowledge Tres' point about high-level non-Python
definition mechanisms for things like forms and schemas.  I agree
with him that such facilities could be a good thing.  I may disagree
with him on whether these should be ZCML. I definately don't think
that they should be.



it depends a lot on the availability of softwares and of standards used 
to create such definitions.


Julien has done some work on using XML schemas in zope3 as you know:
http://blogs.nuxeo.com/sections/blogs/julien_anguenot/2005_08_19_xml-schema-support-on
http://svn.nuxeo.org/trac/pub/browser/z3lab/zope/xmlschema/trunk/demo/

XForms could be a good choice for defining forms too.

I'm using JSON for MVC definitions, because they can be used in 
Javacript without much fuss.

YAML seems to be easy to read  too, etc.
SVG can be investigated too for defining layouts, graphical objects etc.

this is really an area where one should look to see what already exists.

sorry if I'm off-topic.

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



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jean-Marc Orliaguet

Jim Fulton wrote:



Yup.

BTW, a general thing to keep in mind:

- Indirection and abstraction are inherently bad because they
  hide things. :)
  (This is a corolary of explicit is better than implicit.)

- But indirection and abstraction can provide benefits that outweight
  their inherent bad-ness.

Whenever we consider ptoviding a high-level/automated facility, we have
to weigh the benefit against the inherient badness.
[...]

Jim



yes, except that ZCML adds strictly no abstraction compared to what 
would have been written in python. It only paraphrases python by 
hiding lines of code. When I look at a zcml directive I often have to 
read that handler's code to see what it actually does and I have to find 
the objects, classes in files, .. that it handles.


that's 2 indirections, but no abstraction

Abstraction would in the case of ZCML mean that paths to python modules 
and classes would be hidden, that objects (adapters, pages, menus) could 
be given a shorter name that I could use inside ZCML for configuration 
purposes without registering these names in zope, it would mean that I 
could group directives together in a set and apply rules to it without 
always refering to the location of each individual object on the 
filesystem, that I wouln't have to do a grep on all zcml files when I 
move or rename files (I would register paths only once) ... It would 
mean that I could register all images inside a folder without listing 
them all one by one.


This would be the beginning of something called 'abstraction', but 
that's still far away from it :-).


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



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jean-Marc Orliaguet

Jim Fulton wrote:


Jean-Marc Orliaguet wrote:


Jim Fulton wrote:



Yup.

BTW, a general thing to keep in mind:

- Indirection and abstraction are inherently bad because they
  hide things. :)
  (This is a corolary of explicit is better than implicit.)

- But indirection and abstraction can provide benefits that outweight
  their inherent bad-ness.

Whenever we consider ptoviding a high-level/automated facility, we have
to weigh the benefit against the inherient badness.
[...]

Jim



yes, except that ZCML adds strictly no abstraction compared to what 
would have been written in python.  It only paraphrases python by

hiding lines of code.



I was refering to high-level ZCML, such browser:page, browser:menu, etc
vs low-level directives like adapter.

Jim



I would say that they paraphrase more lines of code than the low-level 
ones, but they fundamentally add no extremely valuable abstraction since 
a page is an alias for a multiadapter, a menu registers utilities, 
interfaces, .. . Anyway these are the ones that should be moved out of 
ZCML I guess since they are so site or application specific that it is 
difficult to be reuse them as components in other setups. But after 
rereading your mail it seems that this is what you said in it.


simply put, high-level ZCML would be for me being able to associate a 
collection of resources to a given skin in a global way, or saying that 
a given LDAP directory should be plugged into a given authentication 
service, but without specifying LDAP port, servers, when doing the 
connection (because I have an object in ZCML that stands for the LDAP 
directory and another one that refers to the authentication service)


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



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jean-Marc Orliaguet

Jim Fulton wrote:


Jean-Marc Orliaguet wrote:






I was refering to high-level ZCML, such browser:page, browser:menu, etc
vs low-level directives like adapter.

Jim



I would say that they paraphrase more lines of code than the 
low-level ones, but they fundamentally add no extremely valuable 
abstraction since a page is an alias for a multiadapter, a menu 
registers utilities, interfaces, ..



Wrong.  the page directive defines a class and combines multiple
configurations.  This is definately a higher level of abstraction.




OK, but that's not violent abstraction. For a python programming, 
going to ZCML does feel like wow, I can do some high-level 
configuration of my application, we are still configuring fairly 
low-level components (pages, menus, views ...), they still need to be 
configured on a higher level for the application to start working. The 
effort is not necessarily justified compared with how views for instance 
are declared inline with the code. By looking at 
zope/app/publisher/browser/viewmeta.py it is clear that most of the code 
is there handle all the different page registration options (templates, 
attributes, security, ..).


the fact that the abstraction done in ZCML does not succeed in hiding 
information is an issue, IMO this is because the directives in ZCML 
correspond to low-level objects and the objects' internal way of 
functioning is getting too much exposed  (not enough encapsulation) as 
its the case with browser:page. 


/JM


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



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jean-Marc Orliaguet

Jim Fulton wrote:


Shane Hathaway wrote:




+1.  When I learn a skill, it is at first completely explicit, and as 
the skill becomes predictable and reliable, it gradually becomes 
implicit.  If I kept everything explicit, I would hinder myself from 
building higher level skills.


So explicit is better than implicit until a sufficiently tight 
abstraction comes about.  Take memory management: yesterday it was 
explicit (malloc/free); today it's mostly implicit (garbage 
collection). Garbage collection is both an abstraction, since 
programmers no longer manage memory directly, and an indirection, 
since programmers now use APIs that call malloc and free.  We all 
agree GC is good, so explicit is definitely not always better than 
implicit.



Thanks for explaining Explicit is better than implicit,
except when it's not.



which is strictly equivalent to Implicit is better than explicit, 
except when it's not. :-) and when it's not ... explicit is better.


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



Re: [Zope3-dev] what is ZCML?

2006-03-14 Thread Jean-Marc Orliaguet

Zachery Bir wrote:


On Mar 14, 2006, at 4:31 PM, Jean-Marc Orliaguet wrote:

which is strictly equivalent to Implicit is better than explicit,  
except when it's not. :-) and when it's not ... explicit is better.



Clearly arbitraritude is better than claritization, except when it  
is. Or maybe: a desire to argue pedantics is better than a desire to  
write code (and configuration wink).


Zac



yes, there is a lot of truth in what you wrote, and the opposite too.. 
maybe the zope philosophical findings should be published in a book :-)


/JM
___
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: Mandatory Viewing!

2006-03-07 Thread Jean-Marc Orliaguet

Paul Everitt wrote:


Shane Hathaway wrote:


Stephan Richter wrote:

My vision for the WebDev project is that you can develop WebDev 
packages using Zope 2 like features, but the result of the Web 
development can be generated into a real Python package.



That might work, but the story breaks down if the developer can't 
switch *back* to TTW development.  Have you addressed that?



Does the story break down?  The guy at NASA raved about ArchGenXML 
going from picture to pixels w/ a bunch of zeros for LOC etc.


Clearly this guy didn't just fall off the turnip truck.  Even if he 
*is* glossing over the subtleties, developer mindshare has a tinge of 
such gloss.  Geez, Rails clearly says their scaffolding isn't meant to 
replace understanding, but that hasn't stopped the O'Reilly machine 
from doing a hark-the-heralds on the breakthrough technology.


So yes, the story breaks down.  But after the newcomer has confidence 
and might not need to go back to the TTW approach.  The alternative is 
something perhaps too hard to start (from their perspective).


--Paul



Hi there :-)

I'd like to comment on the screencast, the story is not so much about 
TTW functionality, the screencast clearly emphasizes on:


1) few lines of code (this requires some implicit context in which the 
script is executed, there is no need to pull too much information to 
make it work)
2) no server restart (this means that the script is well encapsulated 
from the rest of the system, it can be reloaded without registering 
again 100 adapters, pages, and resources). the application knows what to 
do when the content of the script changes and it won't break.
3) no or very little configuration (same as 1, but also it means no 
indirections as in the zcml configs, the script only needs to exist for 
the app server to know what to do with it).


if all this can achieved on the filesystem, there is no reason to do it 
TTW. Then adding the possibility to edit scripts TTW is great too, but 
it is secondary.


what I want as a web designer /application developer is to be able to 
modify resources (scripts, images, styles, portlets, page layouts...) on 
the filesystem without restarting zope, I want the resources that I 
create TTW to be easily exported to the filesystem, I want to be able to 
customize resources that are on the filesystem and edit them TTW, with 
as little ceremony as possible ...


I did something in that spirit but on the *application* layer, this is 
much easier since only one type of object in the application (called 
'resource') need to support TTW-editing  / filesystem-editing / 
importing / exporting / customizing / reloading, ...
here is the screencast 
http://www.z3lab.org/sections/front-page/design-features/ttw-vs-filesystem/


I'm not sure if this can be generalized to an entire application for all 
types of objects (adapters, utilities, components, events, ...), 
actually I doubt it, this is why I believe that it is up to the 
application to provide that kind of functionality (not the server). But 
the server can make it easier for the application to implement features 
like these.


regards
/JM
___
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: [Zope-dev] Two visions

2006-03-05 Thread Jean-Marc Orliaguet

Rob Jeschofnik wrote:


Jim Fulton wrote:



I think a lack of a realistic vision means that we are pulling in
different directions.  I think this is causing a lot of harm.


I think the crux of the issue here is that presently, we do not have a 
consistent answer to the question What is `Zope'?. I think what Jim 
is attempting is to solve this problem.



I don't think the crux is that one doesn't know what it is. Zope as an 
application server with a set of libraries somehow independent of the 
server should be good enough, unless one is writing an ontological essay?


The main issue is that different development models and different 
architectures are used in zope2, in zope3 and now possibly if the set 
of libraries approach is promoted because such notions as ZODB, 
acquisition, ZPT will be decoupled there will be yet another development 
pattern.


So to write a tutorial or some documentation on how to develop for zope, 
you'll have to think of the three scenarios, or target audiences: the 
zope2 developer, the zope3 developer and the python developer. The 
difficulty is in finding a common approach in which all three 
development philosophies do not stand in opposition which one another. 
So maybe instead of starting with the differences, on should emphasize 
the aspects that they have in common, and one will be able to called 
that zope.


/JM
___
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: The vision thing

2006-03-05 Thread Jean-Marc Orliaguet

Max M wrote:


Geoff Davis wrote:


Jeff Shell has posted some thought-provoking pieces on his blog that are
relevant to Jim's recent attempt to better articulate a vision for Zope:

http://griddlenoise.blogspot.com/2006/03/zope-crisis-of-faith-coming-this-march.html 



http://griddlenoise.blogspot.com/2006/03/crisis-of-faith-messengers-have-been.html 





Griddle *Noise* and thats exactly what it is... noise.

He is probably following the discussions on the lists, and then he is 
publishing his view on them on his blog instead of participating in 
the dicsussion.





That's unfair. Jeff is actively participating on the list. Which list 
are you refering to, BTW? He has posted about 10 mails on the two 
visions thread in the past 2 days.


He is just another developer who wants Zope to consists of only those 
elements that he is insterrested in.




but that's a perfectly valid concern. Zope needs some more decoupling of 
its components.


/JM
___
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: [Zope-dev] Re: Two visions

2006-02-28 Thread Jean-Marc Orliaguet

Martijn Faassen wrote:


Philipp von Weitershausen wrote:
[snip]


I would vote for spelling out Zed (which would also be a little easier
to google but might create trademark problems). The namespace package
could either be 'z' or 'zed'.

Then again, I really should take Jim's side and stay out of naming
decisions.



Let's please not have a naming discussion again. I think renaming Zope 
3 is really bad marketing myself and naming discussions mostly a waste 
of time...


Regards,

Martijn



please, not Z, it is an oscar-winning film from the 70's about political 
corruption, military coup d'état, ..

http://www.bbc.co.uk/bbcfour/cinema/features/z.shtml

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



[Zope3-dev] Re: Namespaces considered harmful [Was: tal:define=... considered harmful?]

2006-02-17 Thread Jean-Marc Orliaguet

Stefan H. Holek wrote:

My take is that it's not the TAL features (tal:define, python:,  
whatever) that invite misuse, but the available namespaces.


I have ported ZPT to Django [1][2] and found the experience  
surprisingly refreshing. Django naturally does not have anything like  
container or context in the Zope sense. And by Django policy,  
templates don't even get to see the request. The namespace Zope PTs  
call options becomes the sole, top-level namespace in Django PTs.


This very effectively keeps me from pulling-in anything not provided  
by the view in the first place. Everything -- even functions I want  
to call in, say, conditions -- has to be added by the view. The  
result is clean and fast templates.


Stefan

[1] http://www.djangoproject.com
[2] http://zope.org/Members/shh/DjangoPageTemplates/1.0.2/readme.txt




Yes, that's true, the thread later evolved towards the same conclusion 
(removing namespaces in TAL). If the template needs to pull data from 
different objects, tools or databases directly, then the template/view 
is doing the job of the model.


However the opposite is also true:
the model should not do the job of the view and send information about 
how data should be formatted:


for instance, the model can specify that an item is selected:

  items: [{'id': 1, 'selected': true}]

but not:

  items: [{'id': 1, 'font-style': 'bold'}]

for that matter,  python:  expressions are important to keep in order 
to be able to map 'selected' to 'font-style: bold' (which is pure 
presentation logic).


tal:define is OK if it handles presentation data that only the 
template/view is concerned with.


/JM



original message:


On 11. Feb 2006, at 21:03, Jean-Marc Orliaguet wrote:

I almost felt that something was missing, because I'm so used to  
inserting tal:define in page templates. But now I realize that  
this is a mistake.


There was a discussion recently on the list about python  expressions 
being a bad idea, think twice I would say that  tal:define is much 
worse:


When writing templates, the temptation is great to insert a  
tal:define to pull some data into the view which is not directly  
available in the model represented by the view. But the idea with a  
template is that it should represent some data using some markup.  
The data is supposed to be already available in some context. If  the 
presentation layer needs to cook some extra data, it means  that  
there isn't enough presentation data in the first place.



--
Anything that happens, happens.  --Douglas Adams




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



[Zope3-dev] unicode bug in the TAL interpreter

2006-02-16 Thread Jean-Marc Orliaguet


Hi!

there is a bug in TAL interpreter (zope2.8 / zope2.9), the following markup

div tal:attributes=a python:'é'; b python:u'é'.../div

(which mixes unicode- and non unicode-encoded attributes) generates an 
exception::


   result = self.pt_render(extra_context=bound_names)
 File /home/jmo/zope-2.9-cps/Products/CMFCore/FSPageTemplate.py, line 
134, in pt_render

   result = FSPageTemplate.inheritedAttribute('pt_render')(
 File 
/usr/local/Zope-2.9.0/lib/python/Products/PageTemplates/PageTemplate.py, 
line 104, in pt_render

   tal=not source, strictinsert=0)()
 File /usr/local/Zope-2.9.0/lib/python/TAL/TALInterpreter.py, line 
238, in __call__

   self.interpret(self.program)
 File /usr/local/Zope-2.9.0/lib/python/TAL/TALInterpreter.py, line 
281, in interpret

   handlers[opcode](self, args)
 File /usr/local/Zope-2.9.0/lib/python/TAL/TALInterpreter.py, line 
357, in do_startTag

   self._stream_write(_nulljoin(L))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 3: 
ordinal not in range(128)


it is not necessarily an issue in a pure zope2.8 environment (actually 
the bug was first discovered under zope2.9/Five) but on the migration 
path to zope3 the mixing of unicode and non unicode strings coming from 
different software generations may be a real issue.


/JM

___
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: Re: tal:define=... considered harmful?

2006-02-16 Thread Jean-Marc Orliaguet

Martijn Faassen wrote:



I don't think it has an implementation of string TALES expressions.

It's parsing anything that's actually *inside* the attributes you add 
on HTML with tal, such as detecting whether a TALES expression type 
identifier is used ('string:' or 'python:', say), or 'structure', and 
the right splitting of tal:repeat=foo bar (into 'foo' and 'bar'), 
and semicolons for multiple attributes with tal:attributes, and so on. 
I just literally ported that code to javascript from Zope's 
implementation  so it follows the established rules pretty well.




OK, now I get it :-)

in the CTAL implementation this is done for each type of rule 
(ctal:content, ctal:attributes, ...) using  ctal.eval_expr() or 
ctal.get_nameexpr() or eval_pathexpr(). Could be good to have a single 
method for parsing the expressions.



[snip]

More in general, it's possible that some template will receive two 
sets of data that's quite separate from each other. I like 
namespaces then too. You can of course always argue that such a 
template should be factored into multiple smaller ones, though the 
question remains how they'd each receive only their data and not the 
rest.




what I mean it that the structures can always be merged before they 
are passed to the template, then the data can be organized as:


data = {
 items: [ ...],
 people: [],
 somemoredata: {}
}

ZPT does a mapping between several data structures (context, request, 
view ...) and the variables with the same name in TAL, which results 
in several namespaces. Such variables are very platform-dependent and 
a templating language basically needs only one data structure to do 
the rendering..



I'm not sure I understand fully... Perhaps you mean this:

A pattern in templating is to prepare the data fully in nested 
dictionaries and lists with simple strings and integers inside before 
the data is pushed along to a template, as opposed to the template 
pulling it out of request and context and view individually (with 
method calls, often). Perhaps you are referring to this pattern. I 
like this pattern, as it has positive qualities concerning 
debuggability, modularity, loose coupling and makes possible various 
performance optimizations.


XSLT and ClearSilver are templating languages which have this pattern. 
TAL can be made to follow this pattern with some small modifications.


Regards,

Martijn



Yes, that's what I mean. Clearsilver is a good example. There are 
several advantages:


- the data structures are platform-independent (they can be encoded in 
JSON, C, python), and they can be easily converted from one language to 
another, even to and from XML,  this simplifies the transport too (e.g. 
in Ajax, webservices)


- the template does less, it does not need to know anything about zope, 
it works faster, the data access from inside the template is not an 
access to the ZODB ...


- it is possible to create a simple schema definition from the data 
structure itself (this is what I've done in the Ajax toolkit I'm writing)

 for instance from:

 data {
   personid: 123,
   name: bill
   info: {..},
   phonenumbers: []
 }

 one can deduce a simple schema like:

 schema = {
   personid: int,
   name: string,
   info: dict,
   phonenumbers: list
 }

 of course this works only on the first-level of the structure, but 
this is enough in many use cases to make sure that an integer field for 
example does not all of a sudden become a list. This can be used to 
enforce a storage policy.


Regards
/JM

___
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: Re: tal:define=... considered harmful?

2006-02-16 Thread Jean-Marc Orliaguet

Paul Winkler wrote:


On Thu, Feb 16, 2006 at 07:06:03PM +0100, Jean-Marc Orliaguet wrote:
 

Yes, that's what I mean. Clearsilver is a good example. There are 
several advantages:


- the data structures are platform-independent (they can be encoded in 
JSON, C, python), and they can be easily converted from one language to 
another, even to and from XML,  this simplifies the transport too (e.g. 
in Ajax, webservices)


- the template does less, it does not need to know anything about zope, 
it works faster, the data access from inside the template is not an 
access to the ZODB ...


- it is possible to create a simple schema definition from the data 
structure itself (this is what I've done in the Ajax toolkit I'm writing)
   



Another advantage:

- the template itself is truly platform-independent

... which is attractive in mixed-platform environments.

The StringTemplate guy has an interesting take on
templating and model/view separation:
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf

Particularly the stuff about the five rules implied by
strict model-view separation.

 



that's very interesting, what's missing is a javascript port. But 
conceptually the idea is:
write your template once and deploy it on your server, on your client, 
in your UNIX scripts, etc.. (that's basically the idea with XSLT, except 
that not many feel that XSL is easy to write).


I think that the principles stated in that article, of clean separation 
between model and view (called encapsulation) are more important than 
the  template's actual syntax. But the syntax is important too since 
it's humans who write templates ..


/JM

___
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: tal:define=... considered harmful?

2006-02-15 Thread Jean-Marc Orliaguet

Benji York wrote:


Martijn Faassen wrote:

Right, that was my motivation too - I googled around for 
javascript-based templating languages but realized there wasn't 
really anything. Of course XSLT can be used this way too, but TAL is 
kinda neat too. Still, I couldn't think of much practical use for 
this. Perhaps in this AJAXy world this has changed.



Personally I'm very excited about ctal (and like the name too).  
Getting data objects from the server and feeding them to templates on 
the client seems like a nice way to do AJAXy things.



yep, you can also use TAL (ZPT) to create CTAL templates; that's the 
reason why I think the namespace is ctal:... and not tal:..., otherwise 
it could as well have been called tal:... and the template be stored in 
a string.


then there are different usage patterns,
personally I download the template from the server when the page is 
getting initialized (using asynchronous Ajax.request) and I store the 
source in a javascript variable in a widget class. To render the 
template I apply the transformation whenever the data changes. It makes 
it possible to refresh widgets, otherwise you'd have to refresh the page 
or redo an Ajax.request.


here is the part of the code that does the rendering:

render: function(data) {
 if (this.source) {
   var node = document.createElement(div);
   node.innerHTML = this.source;
   ctal.process_ctal(node, data);
   var old_html = this.widget.innerHTML;
   var new_html = node.innerHTML;
   if (new_html != old_html) {
 this.widget.innerHTML = node.innerHTML;
   }
 }
}

the performance is quite fine actually, but since this is event-driven I 
should first check that the data really has been changed before firing a 
modified event, to avoid rendering the template for nothing.


I think 'ctal' is fine too. (client tal)

/JM
___
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: Re: tal:define=... considered harmful?

2006-02-15 Thread Jean-Marc Orliaguet

Balazs Ree wrote:


On Wed, 15 Feb 2006 16:41:36 +0100 Martijn Faassen wrote:
 


A separate svn project would be nice. I'm sure z3lab is open; it's also
welcome under the z3 base on codespeak.
   



I will then check it in to one of those; seriously, I can't decide which
location would be more proper as a home. The z3base seems more generic to
me, however the other ajax stuff is already in z3lab. (except AZAX, which
has the kukit part stored on codespeak.)

I am facing the same decision at where to bring in the jsonserver
(a.k.a. json-rpc) product which would be a complete zope2-zope3 product
merge.

 



sure, whatever


Are you interested in recovering some of there Zope TAL based regex stuff
from Sapling? I'd be happy to merge it in. ctal doesn't appear to have
this yet. 
   



I must have a look, of course any enhancement would be great - and since
the main user at the moment is Jean-Marc, I would be interested in his
opinion.

 



if it doesn't slow things down or add features that are not really 
needed, I think it's fine, but maybe an explanation would be good as to 
what it does?


BTW one enhancement that I was thinking of was the ctal:attributes=... 
stuff, I find the i18n:attributes=... approach more intutive since it 
is possible to write code as if it was HTML first, insert the variables 
where they should be and then specify afterwards which attributes are to 
be replaced:


a href=item/url ctal:attributes=href.../a

instead of:

a href= ctal:attributes=href item/url.../a

(which removes an indirection)

the ZPT tal:attributes=... syntax forces me to think to much

but that's just a personal opinion

I really think that the best way to add features is to create a sample 
applications and see what's missing in the language or what feels 
unnatural or too complicated to achieve, but basically if a missing 
feature forces you to move the logic to the data model, it is definitely 
not a missing feature. I believe that ZPT is too much of a scripting 
language.


also I think that one namespace is enough (no context/title, 
request/user), but use title and user instead ... extra namespaces 
in a template are a sign that the view has not done a good job at 
preparing a data structure for the template to render it.



'ctal' is a somewhat confusing name by the way, you'd think it
was TAL implemented in C, another interesting project I've dabbled with on
and off in the past.
   



I agree but if we change the name we should do it right now. What name
(prefix) would you suggest? Only thing, it needs to be different from
tal (since it must allow mixing the two namespaces in the same page) and
I personally would also be against jtal. ctal was meant to stand for
client tal but indeed it might not be the finest choice.

 


that's what I guessed too, do I win something ? :-)

/JM

___
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: Re: tal:define=... considered harmful?

2006-02-15 Thread Jean-Marc Orliaguet

Martijn Faassen wrote:



if it doesn't slow things down or add features that are not really 
needed, I think it's fine, but maybe an explanation would be good as

to what it does?



It basically does the same thing as ctal does, except less (no
tal:repeat for instance, though I did have a simple tal:define), and it
isn't going anywhere. I dabbled with it a few years ago as I thought it
was an interesting idea and I just wanted to play a bit with javascript.

It had unit tests, and the regex stuff that I was referring to may be
interesting - it ports the regexes from Zope's TALES to Javascript so
that the parsing of tales expressions works the same.

This is the module that has the regex bits, ported directly, if I 
recall correctly, from Zope's python code:


https://infrae.com/svn/sapling/trunk/zpt/talparser.js



OK I see, it's the variable substitution;

string:${name}/${address} ..

the question is what this is not better computed in the model. If it's 
just for presentation it's fine (e.g. adding a colon between two fields),


but then one could (even should) write:

span.../span: span.../span

but if the data is supposed to be a URL or something meaningful for the 
entire application then there's a problem, because it's the template 
that creates the data and the rest of the application has strictly no 
access to it (at least in the MVC model where the view observes the 
model and not the opposite).




[snip]


I really think that the best way to add features is to create a
sample applications and see what's missing in the language or what
feels unnatural or too complicated to achieve, but basically if a
missing feature forces you to move the logic to the data model, it is
definitely not a missing feature. I believe that ZPT is too much of a
scripting language.



Sure. I'm not sure whether the regexes are useful, just would be nice if
they didn't go to waste after all. :)

also I think that one namespace is enough (no context/title, 
request/user), but use title and user instead ... extra

namespaces in a template are a sign that the view has not done a good
job at preparing a data structure for the template to render it.



Hm. If I'm rendering a bunch of records to a HTML table, say, I'd 
prefer my records to be in a list, and the records themselves give 
access to further details.


More in general, it's possible that some template will receive two 
sets of data that's quite separate from each other. I like namespaces 
then too. You can of course always argue that such a template should 
be factored into multiple smaller ones, though the question remains 
how they'd each receive only their data and not the rest.


Regards,

Martijn



what I mean it that the structures can always be merged before they are 
passed to the template, then the data can be organized as:


data = {
 items: [ ...],
 people: [],
 somemoredata: {}
}

ZPT does a mapping between several data structures (context, request, 
view ...) and the variables with the same name in TAL, which results in 
several namespaces. Such variables are very platform-dependent and a 
templating language basically needs only one data structure to do the 
rendering..


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



[Zope3-dev] Re: tal:define=... considered harmful?

2006-02-13 Thread Jean-Marc Orliaguet

Tonico Strasser wrote:


Hi Jean-Marc!

I agree that a view should not be able to modify the data model. But I 
think tal:define is a must have :)


For example: I need tal:define to define names for generic macros:

ul tal:define=list main_navigation
  li metal:use-macro=macros/li_repeat/
/ul

The 'li_repeat' macro expects the name 'list'.

Tonico



That's exactly what I'm saying: if templates did not try to create their 
own data layer, the 'li_repeat' macro could get the data from the model 
(instead it has to rely on cross-template communication)


that's an anti-pattern which is the consequence of having introduced 
tal:define. :-)


/JM
___
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: tal:define=... considered harmful?

2006-02-13 Thread Jean-Marc Orliaguet

Tonico Strasser wrote:


(Again with the right quote, sorry.)

Jean-Marc Orliaguet wrote:

That's exactly what I'm saying: if templates did not try to create 
their own data layer, the 'li_repeat' macro could get the data from 
the model (instead it has to rely on cross-template communication)


that's an anti-pattern which is the consequence of having introduced 
tal:define. :-)



Hm. How else would you use the _same_ macro with different names in 
the same template?


Tonico



tal:define is used here to pass parameters to the macro. In ZPT this 
is done implicitly, which is why macros specify a list a variables that 
must be defined.


In other language this is done explictly. (cf. XSLT xsl:with-param ...)

If it was done explicitly in ZPT it could look like:

 li metal:use-macro=macros/li_repeat metal:with-params=items1 /
 li metal:use-macro=macros/li_repeat metal:with-params=items2 /

best


/JM
___
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: tal:define=... considered harmful?

2006-02-13 Thread Jean-Marc Orliaguet

Tres Seaver wrote:


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Tonico Strasser wrote:

 


I'm interested in your opinion about parameters for macros.

Do you think this is explicit enough?:

ul tal:define=list main_navigation
 li metal:use-macro=macros/li_repeat/
/ul

Or do you think explicit parameters would make things clearer?:

ul
 li metal:use-macro=macros/li_repeat
 metal:with-params=list main_navigation/
/ul
   



I don't favor explict arguments for macros, becaued I don't think they
are functions.  I normally document the expected names in a comment in
the supplying template (outside the macro itself).


Tres.
 



except that this is not about physically passing data to the macro as if 
it was a function (or updating some stack), this is about telling the 
macro from where to pull the data.


for instance if you have a data structure:

data = {
 'items1': [...]
 'items2': [...]
}

you'd write:

li metal:use-macro=macros/li_repeat  metal:with-params=items1 /

provided that the 'li_repeat' macro needs a data structure of the same 
type as 'items1'.


in the current implementation one template provides data for another 
template acting as some sort of proxy for the model (which translates 
into complicated dependency chains since there is no reason to proxy 
data only once).


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



Re: [Zope3-dev] tal:define=... considered harmful?

2006-02-13 Thread Jean-Marc Orliaguet

Martijn Faassen wrote:


Jean-Marc Orliaguet wrote:

I've being working on integrating Balazs Ree's CTAL interpreter 
recently (added tests, fixes, etc.). CTAL is the equivalent of TAL 
but for javascript.



I just googled around for this, and couldn't find it, but I'm 
intrigued. Any link?


A few years ago on a whim I started developing 'sapling', TAL for 
javascript, but never got very far. It's here:


https://infrae.com/viewvc/sapling/trunk/

Perhaps some of the code would be useful to you; regular expression 
parsing for TAL and such in javascript is in there.


It was a whim, as I didn't figure there would be much practical use 
for it. Could you go into more details on how you think you'd use this?


Regards,

Martijn



It is so new that google hasn't found it yet :-) Balazs mailed me the 
code last week.


here is the code I'm working on. Balazs was talking about putting it in 
a repository since several projects might need it.

http://svn.z3lab.org/trac/z3lab/log/cpsskins/branches/jmo-perspectives/ui/framework/ctal.js

note that MochiKit has something similar but not as advanced (without 
unit tests) and that doesn't work on Opera 
(http://www.mochikit.com/examples/ajax_tables/index.html )


best
/JM
___
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: tal:define=... considered harmful?

2006-02-12 Thread Jean-Marc Orliaguet

Balazs Ree wrote:


Sat, 11 Feb 2006 21:03:21 +0100 keltezéssel Jean-Marc Orliaguet azt
írta:
 


I almost felt that something was missing, because I'm so used to inserting
tal:define in page templates. But now I realize that this is a mistake.

There was a discussion recently on the list about python expressions being
a bad idea, think twice I would say that tal:define is much worse:
   



I would also be interested on what the general opinion about this; I also
agree that in case of AJAX if the server prepares all the data that needs
to be inserted to the page (which is a Good Thing to do) there is not much 
need to use defines. Also I use the same design pattern a lot when

implementing custom widgets on the server side; that is, I try to move all
the logic out of the template and into the view methods.

However I think that the bad idea is not tal:define itself but the use (or
abuse) of expressions. For me tal:define is mainly a way to give
expression results a name and (re)use them in the template elsewhere. So I
would not restrict the use of tal:define but rather discourage the use of
expressions themselves.

Personally I feel that some simple overviewable string expressions in
a define (or directly in a content or replace) don't do much harm but then
I would probably even try to avoid those if possible. For me it is mostly
a matter of finding the right balance between readability and performance;
I almost always prefer the first one and do a good design right away. But
as far as ctal is concerned, I would consider adding ctal:define to
the implementation.

 



Hi!

I think it all depends on the model that you are implementing.

In a straightforward client / server model (the server provides data, 
the client renders data) it is pretty harmless to use tal:define, 
because the communication is like a point-to-point channel (only 2 parts 
are in relation). The extra data layer created by tal:define in the 
template is transient, it is a bit like a scaffolding, that gets removed 
after the template has been rendered.


This pattern is used and abused in zope2, zope3 page templates (just 
consider the amount of tal:define declarations at the beginning of 
each page template). Strangely enough zope3 seems to not use this 
functionality as much. Personally I have found that it has always been 
possible to move all presentation data to the view, which very little 
effort.


In the MVC model however (which I'm currently implementing see:  [1] [2] 
for some background info ) this would be a disaster, because the view 
would have a way of directly modifying the data model, bypassing 
everything else. I have added a test in CTAL to make sure that the data 
structure does not get modified during the rendering (it used to get 
modified by the variables in the tal:repeat loop for instance [3]) 
Anyway If two views are observing the same data, the reason that the 
views get automatically refreshed when the data is changed is because 
the model takes care of notifying the views (i.e. the observers) that 
the data has changed.


So if I modify the data from inside the template, neither the model 
machinery (storage adapters, event services) nor the controller will be 
notified that something has changed, and the MVC implementation will 
just fail. The only way to modify data is via: model.setData(data)


However I see python:... or javascript:... expressions more like a 
convenient way of writing expressions when the TAL syntax does not fix it.


best
/JM

[1] http://csis.pace.edu/~bergin/mvc/mvcgui.html
[2] http://www.socketsoftware.com/downloads/community/MVCinSwing.ppt
[3] http://svn.z3lab.org/trac/z3lab/changeset/2364

___
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: tal:define=... considered harmful?

2006-02-12 Thread Jean-Marc Orliaguet

kit BLAKE wrote:


In 'normal' tal we often refactor our defines to improve efficiency.
When something is called more than once in a template, we define it at
the beginning, and then use it multiple times. This improves
performance dramatically of course.
kit


--
kit BLAKE
Infrae · infrae.com · +31 10 243 7051
Hoevestraat 10 · 3033GC · Rotterdam · The Netherlands
___
 



In that case it's fine because the modifications of the data structure 
are local inside the template. The data structure rendered by the view 
does not get modified. Ideally you can always prepare the data structure 
so that it already contains inside a dictionary the results you want to 
display , it is always possible to do it.


however it is not OK when things start looking like:

tal:define=dummy python: context['item'] == sometool.getNewData()

and the context or the request gets overridden.

Templates are not supposed to exchange data directly with one another. I 
reckon that if tal:define is used, then the template should not have 
write-access to the data model at all.


/JM
___
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: tal:define=... considered harmful?

2006-02-12 Thread Jean-Marc Orliaguet

Andreas Jung wrote:




--On 12. Februar 2006 19:18:51 +0100 Max M [EMAIL PROTECTED] wrote:



a href=#
tal:attributes=href here/absolute_url;
title here/title;
id here/getId
tal:content=here/TitleTitle/a


I could write this:

a href=here/absolute_url id=here/getId title=here/Title
tal:attributes=href; id; title
tal:content=here/TitleTitle/a



That's really syntactical sugar. The purpose of the tal: names is clearly
to tell the parser to do _something_ with the value of an attribute. Now
should a parser guess if the value of an attribute is something to be 
processed or not? -1 for such ideas.


-aj



That's more or less what i18n:attributes=attr1 attr2 ... does already.

We continued the discussioned off-list earlier, and one idea that came 
up was:


what do we need to carry along the context, here, request, view 
variables ... instead of having a single namespace, i.e. if I pass 
{'title': 'some title'} to the template, it is tempting to be able to write:


  div tal:content=titletitle comes here/div

instead of:

  div tal:content=here/titletitle comes here/div

one of the reasons for adding the 'here' namespace is that 'title' could 
as well be a local variable. But if tal:define is not implemented that 
is not an issue anymore since there are no local variables. That's what 
other template languages do by the way,  I guess that CTAL will simplify 
things too by exposing a single data structure to the user where 
everything is merged already.


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



[Zope3-dev] tal:define=... considered harmful?

2006-02-11 Thread Jean-Marc Orliaguet


Hi!

I've being working on integrating Balazs Ree's CTAL interpreter recently 
(added tests, fixes, etc.). CTAL is the equivalent of TAL but for 
javascript. For the record MochiKit also has something equivalent called 
MochiTAL that supports tal:content and tal:repeat.


Anyway, CTAL implements all familiar instructions (tal:repeat, 
tal:condition, tal:omit-tag, tal:replace, tal:attributes) except one 
which is ... tal:define. There is also the equivalent of python:... 
which naturally becomes javascript:...


I almost felt that something was missing, because I'm so used to 
inserting tal:define in page templates. But now I realize that this is 
a mistake.


There was a discussion recently on the list about python expressions 
being a bad idea, think twice I would say that tal:define is much worse:


When writing templates, the temptation is great to insert a tal:define 
to pull some data into the view which is not directly available in the 
model represented by the view. But the idea with a template is that it 
should represent some data using some markup. The data is supposed to be 
already available in some context. If the presentation layer needs to 
cook some extra data, it means that  there isn't enough presentation 
data in the first place.


Also in a situation where serveral views observe the same model, all 
views must have access to the same information. A view cannot hold a 
private data layer.


Some argued that python expressions in ZPT are bad. Why are they? If 
there is no tal:define to put the expressions into what can go wrong?


The question about separating presentation from data has nothing to do 
with *how you access the data* ( via tal:content=item/url or via 
tal:content=python: item['url'] ) it has to do with *where you put the 
data*.


here is the test file to get an idea of what CTAL can do:
http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/ui/framework/tests/unit/cpsskins_ctal_test.html

best
/JM

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



[Zope3-dev] [ANIM] Compound storages (cpsskins)

2006-02-05 Thread Jean-Marc Orliaguet





Hi!

Here is an implementation of "compound storages" in CPSSkins (this
concerns the CPSSkins AJAX toolkit only so it also applies to Zope3 in
general, or to any other server that can handle JSON requests and
responses).

First of all, this is a great step towards simplifying the development
of AJAX applications since it provides a complete abstraction between
the model and the storage. The development model gets shifted from
writing code in _javascript_ that moves data around places to defining a
consistent data model. It is not necessarily easier unless one is used
to creating application by first creating a model as opposed to
starting by creating skins.

Background:
A data model needs some form of storage. There are many types of
storages (persistent, volatile, with synchronous access, with
asynchronous access, fast, slow, with low latency, with high
latency...). 
An AJAX application needs different types of storages to manipulate
data locally, to store the results of some user action on a server, to
provide temporary persistence for instance when editing a document, ...
There isn't one type storage that is best suited for everything.
 
In the CPSSkins AJAX toolkit, there are three types of base storages
available: the RAM storage, the local storage (cookie-based), and the
remote storage (that uses accessors to get and set data via a remote
server, e.g. Zope3).

A problem that occurs in the MVC model when many types of storages are
available is that since a given view (a widget) can only observe a
single model,  all the data will have to be stored in the same place
and in the same way unless there is an indirection between the model
and the storage(s). 

Solution:
The "compound storage" makes it possible to combine several models to
set their respective storages in common. The "compound storage" is
similar to a RAID controller: it uses several storages to create what
looks like a single storage, also it dispatches the I/O to the
different storages.

In the current implementation, the storages communicate with the
compound storage and the compound storage communicates with the model
using a simple event system (publish-subscribe with a extra message).

When some data gets stored in a given storage, an event is sent to the
subscribers (e.g. the compound storage). The event then gets propagated
to the model which relays the event to the view(s) which in turn get
updated. This is completely event-driven, so no "user-space" controller
is involved. The advantage is that it can occur asynchronously.

The compound storage defines a list of partitions. Each partition
corresponds to the storage associated to a given model. The data stored
in a model is accessed according to a schema which means that storages
are protected against data corruption (such as changing the type of a
field, or adding an unknown field).

There is a lot of complexity in the toolkit implementation, but this is
as much complexity that gets hidden from the application: the
controller simply needs to set data in the model it doesn't have to
know anything about ajax.requests or cookies. I've started writing a
simple live chat application, and all in all the entire application
code consists in about 40 lines of code in zope3 and in a 3Kb page
template.

The model definition can be created TTW, since the data is represented
in JSON data structures, it involves no _javascript_. The only part that
is _javascript_-heavy is the part that renders the widget, but there will
be widget libraries.

The animation:
http://www.z3lab.org/sections/front-page/design-features/compound-storages

The toolkit code:
http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/ui/framework/cpsskins.js

The code in Zope3:
http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/ui/framework/tests/zope3/functional/quiz/browser.py

The page template:
http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/ui/framework/tests/zope3/functional/quiz/cpsskins_quiz.pt

    
Here is the text seen in the animation:

CPSSkins: storage adapters
A storage adapter can be specified in the model
definition to describe how the model will access the data. 
There are 4 types of storages available:

  RAM
  Local (stores the data in cookies)
  Remote (accesses a remote server)
  Compound (a combination of several storages)



RAM storage
In a RAM storage the data is entirely stored in
the client's memory. The server is never accessed. There is no data
persistence.


Local storage
In a local storage the data is stored in a cookie
on the client. The server is never accessed. There is data persistence
as long as the cookie does not expire.
Remote storage
In this example the data is stored on the server
inside the session. This provides some persistence which means that the
page can be reloaded or the user can leave and return to the page and
the current data will be restored. 
An extra delay has been added when retrieving and when storing 

[Zope3-dev] [ANIM] panels / sub-perspectives

2006-01-05 Thread Jean-Marc Orliaguet


Hi!

I cross-post this time, since this is just a incredibly simple and 
powerful pattern (IMHO) to create single page interfaces in Ajax (with 
panels, popup windows, sub-panels) with stricly no programming involved.
Basically all elements are placed on a same page and they are shown / 
hidden based on the current perspective. Panels can load pages from 
other panels and perspectives can be nested.


the animation:
http://www.z3lab.org/sections/front-page/design-features/sub-perspectives-panels

the explanation:
http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2006_01_05_panels-perspectives

Regards

/JM

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



Re: [Zope3-dev] xml import / export in z2 z3

2005-12-07 Thread Jean-Marc Orliaguet

Martijn Faassen wrote:


Andreas Jung wrote:

I'm about to write an xml importer for importing simple data 
(properties,
dictionaries). Exporting is easy, importing is trickier because a 
parser

is required.

Is there any prefered framework for doing such things in zope3 (zope2)?




Sax or DOM...it depends on the usecase and the algorithmic approach 
you take. Sax is fast but you have to build your own datastructures, 
DOM is slow, takes a lot of memory but it gives you a tree to perform 
any fancy operation on it..



DOM is also not particularly Pythonic (neither is SAX, but it is 
relatively simple at least). You could also look into ElementTree (or 
lxml, which implements that API too). ElementTree (though not yet 
lxml) also introduces iterparse, which is a kind of streaming version 
of the ElementTree API.


ElementTree's API is a much nicer way to work with XML from Python 
than DOM. Also it's more lightweight than even MiniDOM.


Regards,

Martijn



thanks for the info Martijn, I'm going to look at it.

I've done some work with ElementTree for CPSIO, and I haven't found it 
very easy to use because of all the extra namespace URI, and xpath stuff 
used for the tree navigation (xpath_findall, ..) which seem to get in 
the way. Also it could be that I find the DOM approach easier since I'm 
used to it in javascript already.


the question is also about being able to reuse parts of the 
export/import code of CMFSetup / GenericSetup and possibly simplify the 
zope2 - zope3 migration of existing applications.


best
/JM


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



[Zope3-dev] xml import / export in z2 z3

2005-12-06 Thread Jean-Marc Orliaguet

Hi!

I'm about to write an xml importer for importing simple data 
(properties, dictionaries). Exporting is easy, importing is trickier 
because a parser is required.


Is there any prefered framework for doing such things in zope3 (zope2)?

CMFSetup uses sax, GenericSetup uses sax too. ZCML relies on sax... Does 
it mean that writing a sax parser is the way to go, (again this is very 
simple data) or is there any other library recommended in the context of 
zope?


I have no problem switching between setup applications, but writing a 
parser is a bit of pain, so I'd like not to have to redo that part too 
often.


Best
/JM
___
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: Ajax in Zope 3

2005-12-06 Thread Jean-Marc Orliaguet

Tarek Ziadé wrote:


Florent Guillaume wrote:

 


Tarek Ziadé wrote:

   


Hi all,

Some UI works have been done lately around and in Zope 3.  I am thinking
about the work that has been done at Neckar sprint (Zope3.org website,
Viewlets, etc..),  and on projects like CPSSkins for Z3 at ECM.

I am planning to work on UI things as well, and on Ajax things in
particular, both for Zope 2 and Zope 3 applications, and trying to
choose the right Javascript toolkit for this.

Before starting it up, I was thinking that it would be nice if the whole
Z3 community would be using the same toolkit, and maybe, even integrate
it into Z3 itself.

This would allow developers to start some js things today under Z2/Five
and port them. This would also probably lead into a Z3 way to do ajax
and javascript things.

What people think ?

If this sounds like a good Idea, I would like to start a Z3 proposal on
this topic, and contribute on its integration in Z3.

 


Myself I absolutely love the approach taken by CrackAjax
(http://www.aminus.org/blogs/index.php/phunt/2005/10/06/subway_s_new_ajax_framework)


I'm sure lots could be improved like improving python-javascript
translation, allowing for explicit javascript when really needed,
improving the testability, etc.
   



Yes it needs inprovment indeed: the problem I had with this approach at
this time is that the python written that is meant to be translated in
js via an ast engine. it makes the Python code looks like pseudo-javascript.

see in this example:
http://svn.subway.python-hosting.com/crackajax/trunk/itunes.py

the update_list() is using things like document.getElementById() and
the 'document' variable is not existing at all in python side, if i get
it right.

I was wondering in fact what was the benefit of doing it, beside having
a strong aversion of doing js coding (and that aversion can be
really improved by using toolkits like mochikit)

Tarek

 




I haven't done it yet, but I'd like to see what patterns Ruby-on-Rails, 
and other frameworks (e.g . TurboGears) are using, and why it makes such 
a difference in terms of productivity.


one of the important factors that I've noticed tend to complicate the 
code uselessly are:


* the lack of transparency when dealing with client-side and server-side 
data structures (the need to convert data back and forth)
* the need to temporary store and pass data in an artificial way 
(through URL parameters, storing temporary data in the request, inside 
javascript temporary objects)
* representing a same thing with different names, for instance there are 
in zope3 many options for naming objects:


 - using one-word strings or strings without spaces (works best in 
URLs, good as nicknames)
 - using dotted names (less ambiguous than short strings because of the 
namespace)
 - using zope interfaces (works best with z3 components, adapters, 
utilities - useless in javascript)

 - using unique ids (intids)
 - using object names inside containers
 - using interface identifiers ( IFoo.__identifier__ ) ...
 - using interface names ( IFoo.__class__.__name__ )

once you've solved these issues, the rest is much easier.

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



Re: [Zope3-dev] xml import / export in z2 z3

2005-12-06 Thread Jean-Marc Orliaguet

Andreas Jung wrote:




--On 6. Dezember 2005 16:46:02 +0100 Jean-Marc Orliaguet 
[EMAIL PROTECTED] wrote:



Hi!

I'm about to write an xml importer for importing simple data 
(properties,

dictionaries). Exporting is easy, importing is trickier because a parser
is required.

Is there any prefered framework for doing such things in zope3 (zope2)?



Sax or DOM...it depends on the usecase and the algorithmic approach 
you take. Sax is fast but you have to build your own datastructures, 
DOM is slow, takes a lot of memory but it gives you a tree to perform 
any fancy operation on it..


-aj



now I've tried both, DOM (minidom) works the best by far for small 
objects (that's by the way used in CMFSetup too). Updating global 
datastructures from events with Sax is a pain...


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



[Zope3-dev] Re: [Nuxeo-checkins] r30260 - in CPSSkins/trunk: . skins/cpsskins_cmf

2005-12-04 Thread Jean-Marc Orliaguet

Florent Guillaume wrote:

Redirecting to a relative url is illegal in the HTTP spec. You must  
always use a fully qualified url.


Florent


+redirect_url = REQUEST['HTTP_REFERER'] or '.'
+RESPONSE.redirect(redirect_url)




OK, but can you raise that one zope3-dev? It is used all over the place 
in the zope3 code as a standard way or doing redirection, just do a grep on:


$ grep -r  response.redirect Zope3/src

I checked the redirect() method in publisher/http.py and it just sets 
the Location to what it is told to ('.', 'somemethod.html')


/JM
___
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: [Nuxeo-checkins] r30260 - in CPSSkins/trunk: . skins/cpsskins_cmf

2005-12-04 Thread Jean-Marc Orliaguet

Jean-Marc Orliaguet wrote:


Florent Guillaume wrote:

Redirecting to a relative url is illegal in the HTTP spec. You must  
always use a fully qualified url.


Florent


+redirect_url = REQUEST['HTTP_REFERER'] or '.'
+RESPONSE.redirect(redirect_url)





OK, but can you raise that one zope3-dev? It is used all over the 
place in the zope3 code as a standard way or doing redirection, just 
do a grep on:


$ grep -r  response.redirect Zope3/src

I checked the redirect() method in publisher/http.py and it just sets 
the Location to what it is told to ('.', 'somemethod.html')


/JM


OK, that's the one in Zope3/src/zope/publisher/browser.py that is used...

   def redirect(self, location, status=None):
   base = getattr(self, '_base', '')
   if base and isRelative(str(location)):
   l = base.rfind('/')
   if l = 0:
   base = base[:l+1]
   else:
   base += '/'
   location = base + location
  
   # TODO: HTTP redirects must provide an absolute location, see
   #   
http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.30
   #   So, what if location is relative and base is unknown?  
Uncomment

   #   the following and you'll see that it actually happens.
   #
   # if isRelative(str(location)):
   # raise AssertionError('Cannot determine absolute location')
  
   return super(BrowserResponse, self).redirect(location, status)


/JM


___
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: Contained events interface inheritance order

2005-11-30 Thread Jean-Marc Orliaguet

Florent Guillaume wrote:

Well I don't want to appear to defend Apple Mail too much here, but  
splitting a URL after a / can be seen as a natural location.


And in any case this wouldn't be a problem if Mozilla coders weren't  
lazy :-) (decoding rfc3676 (which is nearly 2 years old now) is  
trivial when you already do rfc2646 (format=flowed))


Or just buy a Mac ;)

Florent



don't rush for the mac yet: -) this should be in one of the latest 
thunderbird versions.

https://bugzilla.mozilla.org/show_bug.cgi?id=231701

/JM

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



Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation

2005-11-25 Thread Jean-Marc Orliaguet

Martin Aspeli wrote:



I think there are two cases: The first is the tinkerer, who  
wants  to customise primarily the template as easily as possible,  
preferably  TTW.


OK, I buy this. You want to be able to modify resources, try  
different options ...  Then you might want to export them the  
filesystem.



Absolutely. The export part is important, too. :)



And the import too.. from the filesystem to the memory before you do the 
customization. Currently this is done via ZCML, but for resources this 
is not always optimal, so currently resources are imported using an 
xmlpickle.

http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/configuration/resources/metaconfigure.py




The serious developer wants to customise/override the whole view.



there I'm dubious. Serious developers would have a better time  
writing the code directly in python on the filesystem.



I agree, totally. However, such developers may still want to re-use  
as much as possible of other people's work, e.g. by overriding only  
those parts of the UI they want to change. Most Plone skin products  
work this way, at least - provide a custom stylesheet, override a few  
templates that are included from main_template etc.


OK, but I would count them as serious site designers not as serious 
developers. Doing site design shouldn't require so much developer 
knowledge (python, ZPT, ZCML, HTML...). Application design on the other 
hand requires that type of knowledge, but only for the application logic 
(not so much for the visual part).


the pattern used in cpsskins which may also be useful in plone is to 
separate between resources and settings:


- resources are just objects in the ZODB that users can play with 
(customize, modify, ..)
- settings embed resources and they are registered by site managers 
centrally. It means that get an official status


resources can become settings, and settings can be used as resource 
factories.


for instance a page designer may create a new style of box (a resource) 
and if the style is retained as the default box style for the site, 
the site designer will be able to take the resource and create a setting 
out of it and call it the default box style.


other users will be able to use the box style setting and create their 
own resource out of it, customize it, and so on.


I think that you need to define in Plone what belongs to the application 
and what belongs to the user.


the approach in cpsskins is to write the UI components (portlets,  
widgets) on the filesystem and to combine them through the web. I  
don't see the point in having a 100% TTW approach. Some of the  
components need only be written (dropdown menus, boxes, ..). and  
they should not be changed afterwards



Should is relative, though. I totally agree that the composition  
use case is strong, probably much stronger. But the question is, how  
small are your components? And how hard is it to provide new ones?  
Like Erik said, he wants to customise what's inside  
global_contentmenu. We didn't make that piece small enough for him to  
customise without writing some code. And of course, if we end up with  
one .pt for each div, it'll be unmanageable. So there will always  
be some need for tinkering with templates. And the tinkerer type  
new/quickdirty developer wants to be able to do that without having  
to learn an obscure and complex stack.




this is covered, I'm going to start writing the tutorial part for how to 
create new widgets next week and add it to:

http://www.medic.chalmers.se/~jmo/Zope3/ecm/cpsskins/README.html

It is fairly easy to write new widgets, this is done in python, the only 
difficulty is how to manage everything around it (registration, 
combination of portlets and widgets ..)

http://svn.z3lab.org/trac/z3lab/file/cpsskins/branches/jmo-perspectives/engines/default/filters/widget/widgets.py

however there is a use case which is not currently covered: it's  the 
ability to write the control part of the MVC trough the web.


but again you can also customize parts of the view (e.g. scripts)   
in the same way as you'd customize the template You still don't  have 
to customize the entire view.



Indeed. I think this is probably covered by existing technology (not  
that I know enough about it to be totally sure of all the  
implications). It's the tinkerer group I'm trying to speak up for,  
because frankly they don't read these lists, but they are a very  
important influx into our communities, and we need not to drive them  
away.



absolutely



To be honest, I haven't played with it sufficiently to know all  
its  capabilities, but it seems likely that unless you can edit  
every bit  of every part of the UI, right down to each tag, and  
changing logic  (e.g. when to display a particular part) as well  as 
presentation,  someone will come up with some use case they  
desperately need.




this is covered already and in a more flexible and point-and-click  
way than 

Re: [Zope3-dev] Retaining ease of customisation

2005-11-24 Thread Jean-Marc Orliaguet

Stephan Richter wrote:


On Wednesday 23 November 2005 16:41, Martin Aspeli wrote:
 

I think there needs to be a solution for making quick, preferably TTW  
customisation of UI templates. As Tres pointed out, this shouldn't add a  
performance overhead and lead to maintenance woes for those who know what  
they're doing. Ideally, the site admin should be able to switch this off.  
Or even, the view creator should have to turn it on (e.g. by using a ZCML  
directive that makes a template TTW customisable. Or something). I know  
this strays away from best practice, that people will slap in crazy  
python: statements in TAL etc. Having a way of dumping this stuff to  
real views would be good, even necessary. But I think ignoring these  
users because the approach that's most accessible to them doesn't fit with

 the purity of our framework will seem to them elitist, and it'll probably
drive more people to ruby-on-rails, who sell themselves on how easy it is
to get started.
   



You should have a look at CPSSkins for Zope 3 (developed by the Z3ECM 
project).


Regards,
Stephan
 



Hi Martin, Stefan!

There's a lot of work going on just to solve these issues (TTW / 
filesystem, customization, creating settings, exporting resources to the 
filesystem, ..), but on an application level and not in the way you 
think. What is made customizable is not an entire template, but only the 
resources used by the template. Also the page composition is done 
entirely TTW. So the need for a template to create an manage entire 
sites disappears.


see for instance:
Unified model for managing application resources
http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_11_10_unified-model-for

The separation of concerns (the site manager manages filesystem and TTW 
resources, page designer manages pages, content  author manages content 
, ...):

http://www.z3lab.org/sections/front-page/design-features/editing-screens/

Using ZPT pages to create portlets through-the-web
http://www.z3lab.org/sections/front-page/design-features/custom-portlet/

my impression is that if you want TTW editing you'll have to do it on an 
application level using what's available in the framework (utilities, 
ZPT, ...) Zope3 allows you to do this already and in a much cleaner way 
than with zope2..


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



Re: [Zope3-dev] Retaining ease of customisation

2005-11-24 Thread Jean-Marc Orliaguet

Martijn Faassen wrote:



my impression is that if you want TTW editing you'll have to do it on 
an application level using what's available in the framework 
(utilities, ZPT, ...) Zope3 allows you to do this already and in a 
much cleaner way than with zope2..



That's great! How to make this work in the context of a Zope 2/CMF 
setup, the one Martin is working in? Remember the legacy codebase 
here; it's not an option to throw it out just like that.



Hi,
through Five I guess :-) I don't have the competence though or the exact 
vision on how to do it. What I'm doing though as a matter of philosophy 
is to stick as much as possible to standard Zope3 concepts (adapters, 
utilities, ZCML, event subscribers, views, ...), to make the backporting 
from zope3 to zope2 easier.


The difficulty is to do the first plug into zope2, but then since the 
application make a *huge* abstraction of what's underneath it shouldn't 
make much of a difference if it's plone, cps, zope3. The zope2 version 
was already trivially ported between CMF, CPS2, CPS3, Plone1, Plone2, .. 
thanks to the abstraction.


The task of porting CPSSkins for Zope 3 into Plone seems a bit 
daunting at first. I'm sure there are bits and pieces that can perhaps 
be taken without the whole framework though. Where should people start 
to look?


Regards,

Martijn


It's very much a prototype right now which does a lots of things, but a 
lot of the work is still being done on a conceptual level. The best 
contribution right now is in term of use cases, design, separation of 
roles, workflows, use of resources (I'm not convinced about Martin's TTW 
approach to TTW views for instance), and in basic framework modules 
(such as exporting data from ZODB to the filesystem, etc.. such as 
fsync, or any CMFSetup type of IO function that would be shared between 
Zope2 and Zope3)


regards /JM


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



Re: [Zope3-dev] RFC: Reunite Zope 2 and Zope 3 in the source code repository

2005-11-24 Thread Jean-Marc Orliaguet

Martijn Faassen wrote:


Jean-Marc Orliaguet wrote:
[snip]

It is a bit like this: the zope2 community wants the zope3 technology 
and zope3 wants the zope2 community.



I like this analysis. :)

I think the question about the technology should be treated as such 
on a technical level, by bridging the technical gap (Five, common 
repositories, writing tutorials for zope2 developers, collaborating 
on common modules, adapting zope2 concepts like TTW editing to Zope3 
but without reproducing the zope2 skin and templates mess, etc).


But the question about the communities involves more complicated 
aspects, i.e. marketing issues, licenses, competition, strategies, 
etc. The repository is not the answer. This has to be solved on a 
higher level, Zope Foundation, updated ZPL license, ... where a 
social contract is agreed on.



Be careful with what you're implying with words: marketing aspects 
more complicated than code, higher level, etc. I don't necessarily 
agree with the underlying assumptions.


While I fully support efforts surrounding the Zope Foundation, I 
really think that this is not the right level to solve community 
issues. A Foundation can make social contracts all they like, for 
instance, but if people in the community don't follow them, nothing 
will happen.


Marketing issues and strategies are frequently happening a bit more 
subtly than you seem to say here. The difference between the 
technical and the community level is far less clear than you make 
it seem.


Five, for instance, is *not* just a technical project. It never has 
been. Five is a community project at least as much, to change people's 
*minds*, to merge communities, to change the shape of the Zope 
business, as much as it's to make technical changes. That's why 
there's talks given about conferences, for instance. These things go 
hand in hand.


Merging the repositories is also not just technical. It's clear enough 
that it's not -- the discussion in this thread is not about technical 
issues *at all*. They're about impact on the people involved in Zope 2 
and Zope 3 development.


So let's not pretend that everything can be solved on a technological 
level even though lots of it can ..



We're in open source. Our solutions are frequently technological *and* 
community-based. That's the point of open source. Let's not 
artificially separate the two issues.


Regards,

Martijn



Hi Martijn,

I think you're mixing the notions of community and of community of 
interests.


I don't think that the goal is to merge communities, the goal is to make 
good software and not have different entities fight on framework 
technologies. It is to stir common *interests* in the technology.


On the technical level CMF is used by many, but still different 
communities. Five is a community project used by different communities. 
This also shows that technology merge does not entail community merge, 
because everyone comes with different goals, backgrounds, and this is sound.


Python is a community project, not everyone who uses python is in the 
same community (reads the same mailing-lists, go to the same 
conferences, develop with zope or twisted, ) even though there is a 
strong community of interests.


I think that you want technology merge in the first place, and not force 
people into communities through technology.


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



Re: [Zope-CMF] Re: [Zope3-dev] Retaining ease of customisation

2005-11-24 Thread Jean-Marc Orliaguet

erik wrote:


Hi,

 


HI!


I'm just a tiny little bit confused here, what is a view and what is a resource 
- in Zope2 and in Zope3 ? ;-)

 

there's a notion of resource already in Zope3 that encompasses: images, 
files and templates


in cpsskins (zope3) the notion also encompasses more cpsskins-specific 
objects such as styles, perspective, access keys, portlets, ... 
resources are registered as utilities (and called settings to have 
more meta-information about the resource)


in cpsskins (zope2) resources would be the palettes, styles and 
images.


The idea is that a resource is used by the application in the way that 
the application chooses to use them, but unlike a view it has no 
specific view logic associated with it. A view in zope3 is linked to 
some presentation logic, i.e. an object is being presented, viewed for 
instance in a browser . So a view is noth a context  (the object viewed) 
+ a request (the user's context).


In zope2 a view would grossly correspond to a ZPT and some pythonscripts 
related to a class, but there is no explicit view registration.



Maybe I just don't know enough about Zope3 (or 2), but to me what JM calls a 
view is a resource, and vice versa... anyway, I think it's a good idea to have 
the conceptual discussion now based on use cases, and here's my 2 cents. 
Hopefully someone can then explain what's what.

 


yes, see above, others may have more details...


I'm playing around with Plone2.1 and CPSSkins at the moment. Plone has some 
very nice new features like LinguaPlone and the new extended content_actions 
bar (the bar containing the dropdown menus for workflow actions, 
cut/copy/paste, add content and manage translations etc.).

 

these would be achieved with a portlet (actions) and a widget (dropdown 
menubar) in cpsskins.



The page I would like to construct in CPSSkins has for the sake of argument 
only horizontal sections - no slots - and using todays Plone it looks like this:

---TOP SECTION-
[logo]   [search box]
acute;
BREADCRUMBS | USER+GLOBAL+SITE ACTIONS

---OBJECT CONTROL SECTION-

[object / folder action tabs]

[content action menus bar]

-MAIN SECTION---
[document title]  [document action]

[document description]

[document body]

[content byline] [history thingy]

[discussions]



(to me that's a view, but correct me if I'm wrong)
 



this would be called a page in cpsskins, but the idea is the same. The 
information stored in the page is used to create the final view.



Now, what I would like to do, is to split document actions and content bar, and 
move the elements around.

My problem today is, that the Plone content bar is heavily hard coded, and 
allthough I can insert it in a CPS slot templet, I can't control the styles 
used to render it through CPS's normal styling mechanism. And, I can only use 
the complete content bar or none of it, where I would like to exclude the 
cut/copy/paste-dropdown menu and put these back into folder contents.
 



this is because the Plone version of CPSSkins directly calls the Plone 
template macro that draws the bar ... Since there's no separation 
between style and widget, there's nothing to do except to edit the CSS 
file by hand. The zope3 version of cpsskins separates:


- portlet
- widget
- style

but not the zope2 version. In the case of CPS3 this involved the 
creation of a new product: CPSPortlets that only takes care of rendering 
the portlet (semantically) with a given widget but not rendering the 
portlet's style.


The document actions, on the other hand, can be inserted in a slot templet by defining document_actions as the slot to included. But by doing this I can only display the actions in text, and not by their icons... 
[...]

Oh - and then Plone's isEditable condiition should ofcorse be a condition I can apply to any of my 
templets, in the same manner as I today can apply an if authorized or is anonymous condition to 
control whether to display a templet or not in CPSSkins... also the object/displayContentsTabs condition 
springs to mind here... and there are probably more or there will be, so these conditions should be easy to integrate 
as extensions to CPSSkins' existing conditions.

 


the idea is that you'd define:

- the actions to display and group them in a category (currently this 
cannot be done TTW in zope3 ...)


then you'd put together:

- the action portlet (displaying the actions by category)
- the widget (horizontal drop down bar)
- the style to use (green, blue ...)

So what I believe is missing is maybe a minimal framework that Plone could have used to produce the individual resources for each action presentation type, so that these resources could be used in their purest form out side of the very-hard-to-figure-out Plone GUI...  


Well, back to the resource/view debate; is what I'm 

[Zope3-dev] unique intids rationale

2005-11-22 Thread Jean-Marc Orliaguet


Hi!

what is the rationale between the unique integer ids utility and the 
usage policy?


more specifically: why are newly added objects registered in *all* 
IntIds utilities? It does not make sense if the utility is registered 
locally. If they are local they should not be concerned with objects 
added elsewhere than outside their scope.


can it be turned off in the application?

regards
/JM

.../Zope3/src/zope/app/intid/__init__.py

def addIntIdSubscriber(ob, event):
   A subscriber to ObjectAddedEvent
 
   Registers the object added in all unique id utilities and fires

   an event for the catalogs.
   

   utilities = tuple(zapi.getAllUtilitiesRegisteredFor(IIntIds))

   if utilities: # assert that there are any utilites
   key = IKeyReference(ob, None)
   # Register only objects that adapt to key reference
   if key is not None:
   for utility in utilities:
   utility.register(key)
___
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: unique intids rationale

2005-11-22 Thread Jean-Marc Orliaguet

j.kartnaller wrote:


This has already been added to the bug collector :
http://www.zope.org/Collectors/Zope3-dev/466

Jürgen

Jean-Marc Orliaguet wrote:



Hi!

what is the rationale between the unique integer ids utility and the 
usage policy?


more specifically: why are newly added objects registered in *all* 
IntIds utilities? It does not make sense if the utility is registered 
locally. If they are local they should not be concerned with objects 
added elsewhere than outside their scope.


can it be turned off in the application?

regards
/JM



Hi!
It seems to be another problem here, since local intids utilities behave 
like global ones - if I get the code correctly, the same objects are 
registered in *all* intids utilities. At some point this leads to race 
conditions, when objects have not yet been created or they get deleted, 


regards
/JM

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



[Zope3-dev] __init__.py interfaces.py guidelines?

2005-11-21 Thread Jean-Marc Orliaguet


Hi!

are there any guidelines / best practises for setting the contents of 
__init__.py, interfaces.py, and the packages that they import or that 
they expose? there are too many alternatives and too many ways of ending 
up doing circular imports and I'd like to have a consistent pattern for 
reducing that risk.


but there doesn't seem to be a 100% clear pattern to follow when looking 
at the zope3 code base:


some packages in have all the implementation code in __init__.py, others 
have it in a file and the imports are done in __init__.py, others import 
files starting with an underscore (to make them private I suppose).


some packages have an interfaces.py file others have a interfaces 
folder, others have the interface definitions in the implementation code 
itself ...


Jim mentioned to me that only public and official interface definitions 
should be listed in 'interfaces', the others should be defined inline 
with the implementation - are there guidelines to follow?



I like the inline option because it reduces the amount of imports and 
the risk for import cycles. Does it mean that interfaces should be 
defined inline with the code and those that are official be imported 
from intertaces.py? It sounds like a good pattern.


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



Re: [Zope3-dev] __init__.py interfaces.py guidelines?

2005-11-21 Thread Jean-Marc Orliaguet

Martijn Faassen wrote:


Hi there,


Hi Martijn,


Jean-Marc Orliaguet wrote:

some packages have an interfaces.py file others have a interfaces 
folder, others have the interface definitions in the implementation 
code itself ...



The pattern changed over time during Zope 3 development. In my current 
opinion, interfaces.py should usually be able to accomodate all the 
interfaces of a package. If interface definitions are to be 'private' 
then they can be in the implementation code, but such privacy is very, 
very rare in practice.


Jim mentioned to me that only public and official interface 
definitions should be listed in 'interfaces', the others should be 
defined inline with the implementation - are there guidelines to follow?



Don't know. I think the best rule would be to make the interface 
public unless you have a very good reason not to do so, not the other 
way around.



This is where I'm standing: I have lots of interfaces that don't make an 
API. There are used by a bunch of classes to make it possible to 
register adapters, interface types, utilities, etc. There are more or 
less like marker interfaces, or schema definitions that are not supposed 
to be used publicly.


They are private interfaces that are used to glue together components 
but in a way internal to the application. By having them in 
interfaces.py I feel that I'm making them more official than they need 
to be, they're is some sort of extra ceremony in it.


For the public API, it feels like the right place to have them, but it 
is a commitment as well, and there is no way to make a statement like 
don't use these interfaces, they are subject to changes. I don't like 
the underscore imports either.


I think there should be two different patterns based on the nature of 
the interfaces that get defined (private / public)


regards
/JM


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



Re: [Zope3-dev] __init__.py interfaces.py guidelines?

2005-11-21 Thread Jean-Marc Orliaguet


OK, so to summarize this  thread:

- __init__.py files are empty

  unless for the convenient import of other modules located in the same 
package or in a subpackage?


- public interfaces are stored in interfaces.py

- private interfaces are written along with the implementation code

- what about file names with an underscore at the beginning? They are 
used in zope.schema for instance


- what about import paths inside a same package: relative or absolute?

   from mypackage.interfaces import ISomeInterface
or:
   from interfaces import ISomeInterface

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



Re: [Zope3-dev] __init__.py interfaces.py guidelines?

2005-11-21 Thread Jean-Marc Orliaguet

Jim Fulton wrote:


Jean-Marc Orliaguet wrote:



OK, so to summarize this  thread:

- __init__.py files are empty

  unless for the convenient import of other modules located in the 
same package or in a subpackage?



Actually, primarily for convenient import by external packages.



yes indeed, but no cross imports between packages that are siblings.

and in both cases the import is done using absolute paths.





- public interfaces are stored in interfaces.py

- private interfaces are written along with the implementation code

- what about file names with an underscore at the beginning? They are 
used in zope.schema for instance



A Python convention is that a leading underscore indicates privateness.



but it doesn't inforce it, so another social contract for interfaces like:
interfaces.py means public, otherwise it means private might do as 
well.



- what about import paths inside a same package: relative or absolute?

   from mypackage.interfaces import ISomeInterface
or:
   from interfaces import ISomeInterface



Absolute always.  Until the Python import mechanism is fixed, *always*
use absolute imports.

Jim


that's definitely not the way it is currently...

do a:

$ grep -r from interfaces import Zope3/src

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



Re: [Zope3-dev] __init__.py interfaces.py guidelines?

2005-11-21 Thread Jean-Marc Orliaguet

Jim Fulton wrote:





yes indeed, but no cross imports between packages that are siblings.



Huh? Why? I'm not at all sure I know what you mean.



the question is what relation between the importer and the imported are 
OK: if I add such imports in __init__.py, I should only import from 
packages located in the same folder or in subfolders but not  from 
sibling folders or from parent folders.


with a directory structure like:

root/

- packageA
 |__ packageB

- packageC

in packageA.__init__.py it is OK  to add:

   from root.packageA.somefile import somemodule

to make it possible for external packages to import somemodule as:

   from root.packageA import somemodule

it is OK to write in packageA.__init__.py :

   from root.packageA.packageB.somefile import someothermodule

to import it as:

   from root.packageA import someothermodule

but it is not OK to put the same imports in packageC (a sibling), which 
be some sort or cross import between packages that are not parent / 
child to one another. This easily leads to circular imports.


so what I mean is : parents import from children to make it possible for 
external packages to import directly from the parents.


/JM




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



Re: [Zope3-dev] __init__.py interfaces.py guidelines?

2005-11-21 Thread Jean-Marc Orliaguet


There is another place where there seems to be two different patterns too:

sometimes we have:

  import zope.schema
  name = zope.schema.TextLine(...)

and sometimes:

  from zope.schema import TextLine
  name = TextLine(...)

any reason to use one or the other (speed, verbosity, avoiding circular 
imports, ...) ?


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



Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...

2005-11-13 Thread Jean-Marc Orliaguet
Helmut Merz wrote:

Anyway, what we are talking about are not references.
  


The approach is quite different: references start from the objects
themselves that they connect to other objects using one-way relations (a
pointer, an arrow). The application has to know how to interpret the
references. I don't think that you can build a robust relation engine
only with that.

Relations start from the top: you first define an ontology (a set of
general predicates) that you use to relate the objects of your
application. This is a conceptual schema. Here is the cpsskins ontology:
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/ontology.py

The relation engine then manages all the necessary references, but the
application does not need to know about the references at all. The
interaction with the relation engine is done only via the ontology.

To compare with python: references are to relations what methods are to
classes. A set of unrelated methods doesn't make a model, similarly a
set of loose references doesn't make an ontology.

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



Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...

2005-11-12 Thread Jean-Marc Orliaguet
Helmut Merz wrote:

Am Freitag, 11. November 2005 18:00 schrieb Jean-Marc Orliaguet:

  

I was thinking more about the policy of assigning unique ids
to objects in a relation. It's the application that really
should decide about that policy.



in fact the unique ids aren't assigned to the objects (the 
objects aren't touched at all) by the IntIds utility - if you 
have registered a local IntIds utility they are just created in 
the utility driven by the IObjectAdded event. So this IntIds 
stuff should not interfere with anything else and the 
application should not be concerned at all about it.
  


The good thing about IntIds is that it leaves the objects untouched, the
bad thing is that it creates a hard coupling between the integer id that
is used to *refer* to the object and the key that is used to *represent*
the object in the relation. These are really two different aspects.

In cpsskins when objects are set in relation, it is the application's
responsibility to tell the engine how objects will be identified in the
relation, i.e. with a unique id (IntIds), or with a URI or a with a name
(that may be share between several objects) ... The relation engine then
stores this key as well as an internal reference to the object.

so for each object put in relation we have:
- a key (used by the application to query the engine)
- a reference to the object (used internally by the relation engine to
get the object)

the application only sees the keys until the objects get dereferenced.

But no 1:1 mapping between the key and the object is imposed by any
external IntIds utility. Which make it possible to ask the engine: give
me all the portlets associated to the 'left' slot even though the
'left' slot is materialized in more than one instance.

In your implementation only objects that are identified uniquely can be
put in relation, and it doesn't seem to be a design choice other than a
limitation imposed by the catalog.

http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/j
mo -perspectives/storage/relations.py


I read this, and it indeed gave me the impression that it
might be a not so bad idea to use a catalog ;-)
  

well, you haven't written the catalog indexes yet :-)



I needn't because I just use the FieldIndex from zope.index.

  


I understand, but the idea is to index relations, not simply the
references between in the objects put in relation. My impression is that
you are thinking of a reference engine rather than a relation engine
with the difference compared to the Archetype's engine that references
are stored outside the objects.

/JM

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



Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...

2005-11-12 Thread Jean-Marc Orliaguet
Helmut Merz wrote:

Am Samstag, 12. November 2005 18:00 schrieb Jean-Marc Orliaguet:

  

My 
impression is that you are thinking of a reference engine
rather than a relation engine 



Maybe I just don't see the difference... (There is one, of 
course, but I doubt it is really of relevance in a practical 
context. )

Helmut
  


A relation contains several references:
   
a relation between A, B and C involves 7 references:

A with itself
B with itself
C with itself
A with B
B with C
C with A
A with B with C

But a set of references don't make explicit relations, unless the
application know how to interpret the references.

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



Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...

2005-11-11 Thread Jean-Marc Orliaguet
Helmut Merz wrote:

Hi,

there are quite a few solutions out there in the Zope world that 
allow the management of relations or references between objects. 
So I have been working with the reference engine provided by 
Archetypes (as part of Plone) for nearly two years now; and I 
also had a look at some proposals on zope.org and 
implementations that are available in the Zope 3 packages from
SchoolTool and CPSSkins.

I have to confess that I was not really happy with any of these 
proposals or solutions - a feeling that we may discuss in more 
detail, the main point being just that I wanted to have 
something simple that is nevertheless flexible enough to 
accommodate to various needs.

So I came up with the following stuff (mainly combining concepts 
by Jean-Marc Orliaguet and implementation ideas from Archetypes 
1.3) :

A relation is an object providing the IRelation interface. This 
has got two attributes ('first', 'second' - dyadic relation) or 
three ('first', 'second', 'third' - triadic relation). (You may 
ignore triadic relations if you don't think you need them.)

If I now create corresponding classes (DyadicRelation, 
TriadicRelation) I can assign the objects taking part in a 
relation directly to these attributes of the relation. (Note 
that the objects taking part in a relation are not touched at 
all.) In fact I create a class for each kind of relation (each 
relationship or predicate or whatever you like to call it)
I want to use.

So the question arises what to do with the relation objects? The 
point here is not so much where to store them but how to make 
sure that we can find them. So we need a registry for relations 
- interface IRelationsRegistry.

This has three methods:

- register(relation)
- unregister(relation)
- query(**kw)

The keyword arguments to the query() method may be:

- relationship=... - a relation class (we can also work with
 named predicates - see below)
- first=... - an object
- second=... - an object
- third=... - an object

One can combine those arguments at will to search for all 
relations of the relation class specified (if given) with the 
given values for the attributes. The list may be extended if you 
use relation classes with additional attributes you want to 
search for.

(For details have a look at the README.txt and other files on 
http://svn.cy55.de/viewcvs/Zope3/src/cybertools/trunk/relation 
or check it out via 
svn co svn://svn.cy55.de/Zope3/src/cybertools/trunk/relation)

You see that this looks very much like a catalog search - so why 
not implement the relations registry as a subclass of 
zope.app.catalog.catalog.Catalog?

OK, so the RelationsRegistry class is derived from Catalog, and 
of course it is a local utility. The indexes are just FieldIndex 
objects, using an adapter to provide unique ids for the objects 
involved via the IntIds utility; the same is done for providing 
ids for the relation objects themselves. The relationship is 
mapped to the full module path + class name of the relation 
class.

An interesting consequence of this is that the relation objects 
are not explicitly stored somewhere, the only reference to them 
is via the IntIds utility. Thus you are free to store them in 
some container or even make them first class content objects if 
you want - but you needn't.

The whole stuff is flexible enough to be extended as needed, e.g. 
with special registry classes used via named utilities, 
additional attributes on relations (easily indexable in the 
registry); it could be wrapped in a richer and more 
application-oriented API, etc.

It is also possible to use named predicates (with URIs or strings 
like '_ is child of _') instead of different relation classes to 
represent relationships (this is shown by an example at the end 
of the README.txt).


So what do you think? - any feedback and suggestions welcome...

I'd also gladly write a proposal (if I get write access to the 
wiki ;-)) and of course change the license from GPL to ZPL if 
this would be considered useful.

Helmut

  


Hi Helmut!

I can tell you about the design decisions made in the case of the
relation tool included in CPSSkins. They don't necessarily appear in the
code itself in an obvious way.

1) separate storage from storage policy

the relation storage stores what it is told to store, as long as the
objects are Relatable they can be stored. The storage policy (using
unique ids or not, etc..) is the responsibility of the application
itself. To impose a unique id policy when storing elements would be a
mistake in my opinion (in the case of cpsskins it wouln't work either).

2) keep the relation storage index as small as possible.
 
Do not index predicates, the same predicates are used in too many
relations, the size of the index ould just increase dramatically.
Instead only index the elements that are inside the relation, the
chances that the same elements are related in many different ways are
very low.

cf.
http://www.z3lab.org

Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...

2005-11-11 Thread Jean-Marc Orliaguet
Reinoud van Leeuwen wrote:

On Fri, Nov 11, 2005 at 03:50:25PM +0100, Helmut Merz wrote:
  

A relation is an object providing the IRelation interface. This 
has got two attributes ('first', 'second' - dyadic relation) or 



I've done this kind of thing in relational databases. Problem with 'first' 
and 'second' is that it seems to imply some order. And if I try to find 
all relations from an object I allways have to compare my ID to either 
first or second.

I solved my problem by chopping a relation into three parts: the relation 
itself and both endpoints. In my database this generated an extra table 
(and some more work when writing queries), but the solution became more 
generic and flexible in the end.

(See the database diagram on 
http://www.drbob.org/datamodel/drbob_datamodel.htm . The two endpoints of 
a relation are stored in two object_link records, the relation itself in 
one link record.) 

  


Hi!

I think that you want 1 relation that consists of:
- the elements in the relation (the relates)
- the predicate

then you can chop the relations into piece when you index it, but not
before.

a relation is by definition 1 entity, if you start storing 2 items to
represent a single relation, you will have problems looming ahead when
it comes to managing the different parts of the relation. For instance
if you store A - B and B - A to represent A - B, you will have to
destroy A - B if you remove B - A.

This is why I use real triadic relations to avoid having complicated
constructions based on  dyadic relations that only make sense when
they're taken together. When I destroy a triadic relation between 3
objects, this is done in one take, not three takes.

then order in a relation is important:

A kills B

is not the same as:

B kills A

of course if the predicate is :

   __ is like __

it appears as though order is not important, but it is a question of
semantics, not a question of logic. A relation engine is not supposed to
know about semantics.

/JM

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



Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...

2005-11-11 Thread Jean-Marc Orliaguet
Reinoud van Leeuwen wrote:

On Fri, Nov 11, 2005 at 04:44:47PM +0100, Jean-Marc Orliaguet wrote:
  

Reinoud van Leeuwen wrote:



On Fri, Nov 11, 2005 at 03:50:25PM +0100, Helmut Merz wrote:
 

  

A relation is an object providing the IRelation interface. This 
has got two attributes ('first', 'second' - dyadic relation) or 
   



I've done this kind of thing in relational databases. Problem with 'first' 
and 'second' is that it seems to imply some order. And if I try to find 
all relations from an object I allways have to compare my ID to either 
first or second.

I solved my problem by chopping a relation into three parts: the relation 
itself and both endpoints. In my database this generated an extra table 
(and some more work when writing queries), but the solution became more 
generic and flexible in the end.

(See the database diagram on 
http://www.drbob.org/datamodel/drbob_datamodel.htm . The two endpoints of 
a relation are stored in two object_link records, the relation itself in 
one link record.) 

 

  

Hi!

I think that you want 1 relation that consists of:
- the elements in the relation (the relates)
- the predicate

then you can chop the relations into piece when you index it, but not
before.

a relation is by definition 1 entity, if you start storing 2 items to
represent a single relation, you will have problems looming ahead when
it comes to managing the different parts of the relation. For instance
if you store A - B and B - A to represent A - B, you will have to
destroy A - B if you remove B - A.

This is why I use real triadic relations to avoid having complicated
constructions based on  dyadic relations that only make sense when
they're taken together. When I destroy a triadic relation between 3
objects, this is done in one take, not three takes.

then order in a relation is important:

A kills B

is not the same as:

B kills A

of course if the predicate is :

   __ is like __

it appears as though order is not important, but it is a question of
semantics, not a question of logic. A relation engine is not supposed to
know about semantics.



OK. In a relational database you can solve the 'one entity stored in 
different tables' with triggers. But this discussion is not about a RDBMS 
;-)

As long as the relations you propose have a direction ('kills') it makes 
sense to stored them as 'first' and 'second' somewhere. But when the 
direction is symetrical ('is like') this implementation does not feel 
right. Of course it is possible in Python to make a class around it, but 
still if a piece of code wants to find all related objects it has to 
search both the 'first' and the 'second' field.

That sounds less generic than it could be in my opinion.
  


In any case it is the responsibility of the application to define its
ontology. The relation engine shouldn't make any assumptions in that area.

if the relation is symmetrical, there are 2 relations:

A is like B

means:

   A resembles B

and

   B resembles A( or A __ is resembled by __ B )

which you can express as a compound predicate:

is_like = CompoundPredicate(Predicate('_ resembles _', '_ is
resembled by _'))

and do a query with:

relations.search(predicate=is_like, first=A)

to get all the B:s in relation with A independently of the position.


Then most of the relations do have a direction ( __ has author __, __
was modified by __,  ...)

/JM


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



Re: [Zope3-dev] Yet Another Relations (aka Reference) Engine...

2005-11-11 Thread Jean-Marc Orliaguet
Helmut Merz wrote:

Am Freitag, 11. November 2005 16:11 schrieb Jean-Marc Orliaguet:

  

Hi Helmut!



Hi Jean-Marc,

thanks for your remarks,

just before going into more detail: My primary concern was the 
API - it would really fine if there could be a simple (as simple 
as possible but not simpler) standard set of (low-level) 
interfaces on which to build (defining semantically richer 
interfaces) and for which to provide implementations (depending 
on the needs of the application).

The implementation with the catalog should serve as a (again 
fairly simple but working) example and a proof of concept; I 
think I would be just lucky if it would show up as really 
useful ;-) (but maybe...)

  


Hi,

a common interface could be useful indeed.

I can tell you about the design decisions made in the case of
the relation tool included in CPSSkins. They don't necessarily
appear in the code itself in an obvious way.

1) separate storage from storage policy

the relation storage stores what it is told to store, as long
as the objects are Relatable they can be stored. The storage
policy (using unique ids or not, etc..) is the responsibility
of the application itself. To impose a unique id policy when
storing elements would be a mistake in my opinion (in the case
of cpsskins it wouln't work either).



The only prerequisite for using the IntIds utility is that the 
objects are persistent (provide IPersistent). If one wants to 
relate objects that are not persistent or have relations that 
for some reason can't be persistent you can't use the catalog 
approach because the catalog depends on IntIds.

So the catalog-based implementation won't be usable for relations 
between in-memory objects (like views, adapters and related 
stuff), that's true.
  


I was thinking more about the policy of assigning unique ids to objects
in a relation. It's the application that really should decide about that
policy.

2) keep the relation storage index as small as possible.

Do not index predicates, the same predicates are used in too
many relations, the size of the index ould just increase
dramatically. Instead only index the elements that are inside
the relation, the chances that the same elements are related
in many different ways are very low.

cf.



http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_08_27_triadic-relations/
  

http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo
-perspectives/storage/relations.py



I read this, and it indeed gave me the impression that it might 
be a not so bad idea to use a catalog ;-)

  


well, you haven't written the catalog indexes yet :-)

And Lennart wrote a piece about the kinds of problems you'll run into if
you don't optimize them for relations. You'll end up with intersections
of huge sets:
http://blogs.nuxeo.com/sections/blogs/lennart_regebro/2005_08_29_indexing-events

I don't know about using the zc.catalog for indexing
relations, you could end up in huge indexes and very slow
queries.



This is one of my concerns, too, but I'm fairly optimistic: the 
catalog indexes store a common string to be indexed only once, 
so having identical ; I'm working with the Archetypes reference 
engine (that uses - at least in this respect - the same kind of 
catalog indexes) in situations with many thousands of objects 
and didn't get problems of this kind.

  

By looking at the code, Archetypes does not store relations, it stores
'references' (and backward references) which consist in a target object
and a predicate ('relationship') in the objects themselves . I guess
that objects are indexed in the catalog. So the relation is stored
implicitly but there is no explicit relation object to start with. So
the model is a bit different I guess.

3) don't make the API for querying the storage be too
intelligent,



The query() method using the catalog's searchResults() / apply() 
methods was the dumbest one I could thing of ;-)

  

 to create complex queries, create complex predicates instead,
i.e.

   - predicates that combine several predicates
   - proxy predicates (when the predicate is evaluated at
runtime and a method is specifed instead)

cf



http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/relations/__init__.py
  

if you need to do really complex queries, do several
queries and filter out the results afterwards  in you
application unless you're fine with ending up with a huge
catalog index.



To be honest, I never thought about complex queries as I just 
want to find e.g. the subtasks of a task and the resources 
allocated to it - maybe my use case is just somewhat simple.

OTOH: An advantage of using a catalog are the - as I think - 
fairly efficient set operations on search results for the 
indexes...

Helmut
  

This opens the door to a combinational explosion. The number of
relations between objects literally explodes unless you carefully choose
the relation predicates. The catalog

Re: [Zope3-dev] i18n:translate and tal:content should not use template domain

2005-11-09 Thread Jean-Marc Orliaguet
Dmitry Vasiliev wrote:

 Jim Fulton wrote:


 IMO, if a template an element with both i18n:translate and tal:content
 and the value inserted is not a message id, the template's domain will
 be used.  This seems like a bad idea.  It can hide failures to provide
 message ids because everything ultimately gets a domain.  I'm working on
 tools to help people see when text hasn't been internationalized and the
 implicit use of of the template's domain makes these tools less useful.

 Basically, the domain given in the template source applies to the source
 only and shouldn't be used for data coming from elsewhere.

 I propose that we should never use the templates domain when
 inserting data
 via tal:content.  Note however, if the tal expression results in the
 use of the
 template's example text, the templates domain should be used.

 Thoughts?


 Maybe we should translate *only* a message id values in case of
 i18n:translate and tal:content/tal:replace and print a warning for any
 other values? Moreover it's Zope-3.1 behavior. For Zope-3.2 there was
 a bug report at http://www.zope.org/Collectors/Zope3-dev/455 partially
 fixed by me. Now I'm not sure the fix was a good idea. Main
 disadvantage I see is that it leads to bad i18n style for users.


Hi!

there are cases where you need to evaluate an expression to get the
msgid for instance in:

there is a workaround, but it is very inelegant:
http://svn.nuxeo.org/trac/pub/changeset/27505

the translation could be done in python, but I guess you would need to
create special i18n views whose sole purpose would be to translate
information that's already available.

the risk would be that users start translating msgid in python code that
is not meant to be presented in a view.

/JM


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



Re: [Zope3-dev] i18n:translate and tal:content should not use template domain

2005-11-09 Thread Jean-Marc Orliaguet
Jim Fulton wrote:

 Jean-Marc Orliaguet wrote:
 ...

 there are cases where you need to evaluate an expression to get the
 msgid for instance in:

 there is a workaround, but it is very inelegant:
 http://svn.nuxeo.org/trac/pub/changeset/27505

 the translation could be done in python, but I guess you would need to
 create special i18n views whose sole purpose would be to translate
 information that's already available.

 the risk would be that users start translating msgid in python code that
 is not meant to be presented in a view.


 Nobody is objecting to getting message ids from exceptions, 

'expressions' you mean?

 They should be
 message ids though, not strings.  I think we need to work with strings,
 but have tools to aid developers in detecting when they've used strings
 rather than message ids.

and a message id would be a string with characters in lowercase without
spaces but maybe with underscores or dots?

this is important to know I think, because I'd like to be able to
translate interfaces names, dotted names..

/JM

 Jim

___
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: How does the rotterdam skin work?

2005-10-24 Thread Jean-Marc Orliaguet
Jim Fulton wrote:

 Jean-Marc Orliaguet wrote:


 Hi!
 the problem is not in the skin itself, but in the model  used to create
 skins. Filesystem-based skins that depend on ZPT macros are doomed by
 definition, unless they are designed to cover most of the site layouts
 you'll find on the internet (for instance the Plone skin is quite
 generic). But maintaining such a generic skin (HTML + CSS) is a lot
 of work.


 While I wouldn't put it *quite* so harshly, I agree.

 Also there is a problem with the target audience: ZPT programmers are
 not always good graphic designers and UI/ graphic designers are not
 always good at ZPT / python.


 ZPT isn't supposed to be grouped with Python. ZPT was definately designed
 for Web Designers -- people who use tools like Dreamwever.  Except for
 the macro
 issue, ZPT has been pretty (as opposed to completely) sucessful in our
 experience.  One thing I'd definately do differently if I could go back
 in time to when we invented ZPT is I would absolutely not include python
 expressions.  In generally, I would have made them computationally less
 powerful.  Our intent was definately that people would not do complex
 computations in ZPT but people have definately abused the power we've
 provided.

 I think the biggest problem with the ZPT macro approach to look and feel
 concerns are not separated.  CPSSkins deals with this in it's own way.
 I'd like to see an approach for people not using CPSSkins. :)  I think
 that
 this will involve some sort of post-publishing phase in the publication
 process.

 Jim



Sure, the separation between content and presentation is very clean in
ZPT (assuming python: expressions did not exist..:-) ). The difference
in the two approaches are more deeply grounded I think:

- the page template model starts from the idea of individual web pages
(easy to understand for a web designer) that expands into a whole site
by creating abstractions such as 'page headers', 'slots', etc.. The
starting point is a web *page* which becomes a generic 'template', and
eventually a site as a collection of published objects that use the same
templates. The process is from the particular to the general, the
'template' make it possible to do the transition.

- with cpsskins, the process goes the other way: from general to
particular. The difficulty lies instead in creating particular pages
that do not follow any given pattern. The logic is close to the
development of an application UI that tries to emulate web sites.
 
/JM
___
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: How does the rotterdam skin work?

2005-10-24 Thread Jean-Marc Orliaguet
Jim Fulton wrote:

 Paul Winkler wrote:

 Hi Jim, just de-lurking for a moment:

 On 10/24/05, Jim Fulton [EMAIL PROTECTED] wrote:
   I think the biggest problem with the ZPT macro approach to look
 and feel

 concerns are not separated.  CPSSkins deals with this in it's own way.



 I couldn't quite parse that.  What is not separated from what?


 Sorry, I assumed too much context.

 At a minimum, the concerns of the page author are not separated from the
 concerns of the site designer. Put another way, the concerns of the
 person
 creating the content well are mixed up with the concerns of people
 creating the
 O-wrap.  There are probably other concerns that should be separated
 too.

 Jim


To put it differently: with page templates you try to separate concerns,
by splitting things into: content, presentation, portlets, viewlets,
macros, local variations in the presentation (put your concept here)
using the TAL language. But what you start from is in fact a HTML page.

In cpsskins you start from the individual concepts (portlets, widgets,
styles, slots, pages, themes, perspectives. ...) that can be related in
different ways and the job of the rendering engine is create a
particular composition based on the instructions given by different
categories of users (UI designers. site designer, application designers,
users, .. )

/JM


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



[Zope3-dev] views have no __page_attribute__ ?

2005-10-04 Thread Jean-Marc Orliaguet

Hi!

I've encountered a problem when trying to render views (there is no
problem with rendering pages), but for instance with the '+' view that
is defined in app/container/browser/configure.zcml

  view
  for=zope.app.container.interfaces.IContentContainer
  name=+
  menu=zmi_actions title=Add
  class=zope.app.container.browser.adding.ContentAdding
  permission=zope.ManageContent
  allowed_attributes=addingInfo isSingleMenuItem hasCustomAddView

page name=index.html  template=add.pt /
page name=action.html attribute=action /

  /view


when called with:

markup = view()

['view' being the 'view' variable gotten from ZPT)

results in the following error message:

...
markup = view()
  File /home/jmo/Zope3/src/zope/app/publisher/browser/viewmeta.py,
line 445, in __call__
attr = self.__page_attribute__
AttributeError: '+' object has no attribute '__page_attribute__'

because the __call__ method of
zope.app.publisher.browser.viewmeta.simple expects views and pages to
have a page attribute:

def __call__(self, *a, **k):
# If a class doesn't provide it's own call, then get the attribute
# given by the browser default.

attr = self.__page_attribute__


With the '+' view described above, there is a default page attribute to
use for displaying the view ('index.html') and but no page attribute
explicitly assigned.

The following patch fixes the problem, but I'm afraid that I'm missing
something: are views supposed to have a '__page_attribute__' or not?


Index: app/publisher/browser/viewmeta.py
===
--- app/publisher/browser/viewmeta.py   (revision 38719)
+++ app/publisher/browser/viewmeta.py   (working copy)
@@ -275,6 +275,8 @@
 required[pname] = permission
 
 pages[pname] = attribute
+if pname == 'index.html':
+cdict['__page_attribute__'] = attribute
 
 # This should go away, but noone seems to remember what to do. :-(
 if hasattr(class_, 'publishTraverse'):



/JM

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



Re: [Zope3-dev] views have no __page_attribute__ ?

2005-10-04 Thread Jean-Marc Orliaguet
Jim Fulton wrote:

 Jean-Marc Orliaguet wrote:

 ...

 With the '+' view described above, there is a default page attribute to
 use for displaying the view ('index.html') and but no page attribute
 explicitly assigned.

 The following patch fixes the problem, but I'm afraid that I'm missing
 something: are views supposed to have a '__page_attribute__' or not?


 They are only supposed to ave a page attribute if they are pages. :)

 The directive above creates a view *with pages*.  This means that the
 view itself should not a page and is not intended to be callable.

 Bottom line: views created this way are not callable and are not directly
 renderable.

 There's a bit more complexity than I'd like in these view directives.
 This is
 why, more and more, I tend to *define* views in Python and just
 register them
 with the adapter or view directive.  I still do often find it useful
 to register
 views with the view directive, mainly so I can avoid having to mention
 IBrowserRequest.

 Jim


OK, so the 'view' object set in page templates is not the object to call
for rendering the page.

All in all, I managed to render the '+' view by calling the 'template'
object and passing the 'view' as the instance parameter

 markup = template(instance=view)

instead of calling the 'view' directly with:

 markup = view()

This seems to be generic enough

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



[Zope3-dev] '+' view (sequel)

2005-10-04 Thread Jean-Marc Orliaguet

Hi!

the '+' view now works fine in cpsskins :-), the only problem is that it
also reveals a user interface issue nicely hidden in the original
Rotterdam skin :-) namely that the menu actions are still visible when
the url ends with .../@@+ and the action item urls are not normalized. A
second click on the 'Add' action sends the user to:

.../folder/@@+/@@+

with a The page that you are trying to access is not available error.

the same goes with other actions, for instance:

.../folder/@@+/@@find.html instead of .../folder/@@find.html

BrowserMenuItem.selected() contains the code necessary to normalize
action urls, why not use it in actions returned by getMenu() too?

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



Re: [Zope3-dev] views have no __page_attribute__ ?

2005-10-04 Thread Jean-Marc Orliaguet
Jim Fulton wrote:

 Jean-Marc Orliaguet wrote:

 Jim Fulton wrote:


 Jean-Marc Orliaguet wrote:


 ...

 With the '+' view described above, there is a default page
 attribute to
 use for displaying the view ('index.html') and but no page attribute
 explicitly assigned.

 The following patch fixes the problem, but I'm afraid that I'm missing
 something: are views supposed to have a '__page_attribute__' or not?



 They are only supposed to ave a page attribute if they are pages. :)

 The directive above creates a view *with pages*.  This means that the
 view itself should not a page and is not intended to be callable.

 Bottom line: views created this way are not callable and are not
 directly
 renderable.

 There's a bit more complexity than I'd like in these view directives.
 This is
 why, more and more, I tend to *define* views in Python and just
 register them
 with the adapter or view directive.  I still do often find it useful
 to register
 views with the view directive, mainly so I can avoid having to mention
 IBrowserRequest.

 Jim



 OK, so the 'view' object set in page templates is not the object to call
 for rendering the page.


 Uh, normally the page template renders the page.

 Different views are constructed differently.  Views created
 with the page directive and views created with a view directive
 without page subdirectives *can* be called to render pages --
 basically because they *are* pages.  OTOH a view directive with
 page subdirectives is meant to be traversed to get to it's pages,
 which then can be called.

 All in all, I managed to render the '+' view by calling the 'template'
 object and passing the 'view' as the instance parameter


 markup = template(instance=view)


 I'm confused. Aren't you already in the template?

 Jim



well sort of: I do start from a standard template (the original
browser/skin/template.pt) that contains the macro -page definition, the
head markup, and the actual call to the theme renderer in the body
part of the template.

metal:block define-macro=page
metal:block define-slot=doctype
html
headCSS / JS comes here/head
body tal:content=python: theme.render(...) /
/html

 then I pass the:
- context
- view
- template

 to theme.render(...)

then the renderer in python takes care of rendering for the main content
area that would have been displayed otherwise. So I have to re-render
the page in its original context.

It works apparently with:

 template(instance=view) ..

/JM

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



[Zope3-dev] Re: Content provider API

2005-09-25 Thread Jean-Marc Orliaguet
Roger Ineichen wrote:

Hi together

I added a proposal where is important for the CPSSkin work and the
zope.app.viewlet implementation.
Can you take a look at it and tell me what do you think about.

I hope it will be possible to implement a generic lookup concept
in page templates where we can use for CPSSkin or the viewlet
implementation form Stephan. 

I have some need for such a base API in the Tiks framework and
plan to implement this at the Neckar sprint if possible.

Proposal
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ContentProv
iderAPIForSkins

Regards
Roger Ineichen

  


Hi Roger,

If I got it right, you are proposing a generic API, a generic lookup
mechanism to find the objects located in a given region of a page (i.e.
a slot in cpsskins) that could be used by any portlet, viewlet,
pagelet provider and that is independent of the implementation (viewlet,
pagelet, portlet, ...)?

It could be that the viewlet implementation is already covered by the
notion global portlet in cpsskins and that the use of slots in that
case is redundant, since cells (columns) in cpsskins can act as
containers already. So my question is: will there be some support for
more contextual lookup mechanisms in the API that you are proposing, or
will the same set of objects always be displayed inside the same region?

Anyway, if the goal is to reuse portlets, viewlets, ... written for
other applications inside cpsskins there are two options:

1) one is to create a third type of slot (beside the by-folder, and
the by-perspective kind of slot), this one relying on an API external
to cpsskins to collect the viewlets.

  As far as I know any lookup mechanism will work in cpsskins as far as
the objects located in the IRegion (slot) are uniquely identified. They
do not need to be ordered; indeed cpsskins separates the lookup
mechanism from the actual portlet display, which means that what is
called weight in the viewlet implementation (a very approximate
replacement of the notion of order) is neither stored in the objects
themselves nor inside the slot but in the slot's *display*. The display
acts as a sort of visual proxy for the slot's content and portlet
ordering is managed there instead.

2) I think that TTW development is very important when doing page
design. So I'm currently working on refactoring the Custom portlet
implementation In the current implementation the Custom Portlet looks
for a ZPT, DTML, PythonScript object (or any object with a location that
can be rendered) and renders it (see [1]). I want to extend the
implementation to make it possible for page designers to write the
template or script code directly in a text area and specify the format
(ZPT, DTML, ..). Then the Custom portlet will create a template with the
text code on-the-fly and render it. This is the equivalent of TTW
programming, but without the need to use the ZMI.

  In that case the ZPT code written for the viewlets, pagelets, ...
could be pasted directly in the text area of the Custom Portlet. Of
course, the custom portlets can then be duplicated, modified, stylized,
placed anywhere on the page. This solution would I think be more
appealing for page designers since they won't need to get access to the
file system to write the code.


[1]
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/portlets/custom/__init__.py

regards /JM


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



[Zope3-dev] Re: Content provider API

2005-09-25 Thread Jean-Marc Orliaguet
Roger Ineichen wrote:

Hi Jean Marc 
...


  

Hi Roger,

I propose,

Regions and their lookup are a concept on the ZPT level,
 implementations like CPSSkin or viewlets use this ZPT API 

Let's say a region defines a area in a page template. This area
will lookup 'html fragment' and render them within the page template.

For the lookup of 'html fragment' in a region we need a component
how knows about to collect such 'html fragment'.

Can you agree if I say the region is defined in the page template 
and the lookup component is registred as a adapter for:

(context, request, view, region)  

This would make it possible to register lookup mechanism depending 
on the objects context, the view we are browsing and the region we are
accessing.

Can you agree if I say that this concept is a base concept of the 
page template and only used from CPSSkin and viewlets instead 
that CPSSkin and viewlet define their own lookup concept.

CPSSkin or viewlet will ues this API for interact in the right way 
in a ZPT.

  


OK, I see. The think is that CPSSkins does not use zope page templates
at all for rendering the page, but page templates can be used as sources
of input, whatever lookup mechanism you choose will do, since the
context, request, view, ... variables will be passed during the rendering.

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



[Zope3-dev] typo in zope/app/i18n/browser/synchronize.py

2005-09-19 Thread Jean-Marc Orliaguet
FYI, there is a typo in:

Index: zope/app/i18n/browser/synchronize.py
===
--- zope/app/i18n/browser/synchronize.py(revision 38532)
+++ zope/app/i18n/browser/synchronize.py(working copy)
@@ -117,7 +117,7 @@
 if connected:
 fmsgs = self._connection.getMessagesFor(self.sync_languages)
 else:
-fmdgs = []
+fmsgs = []
 
 return self.context.getMessagesMapping(self.sync_languages,
fmsgs)


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



[Zope3-dev] i18n in ZPT half-broken?

2005-09-19 Thread Jean-Marc Orliaguet

Hi! I'm having trouble getting strings to be translated using
tal:content=variable or tal:replace=variable

  p i18n:translate= i18n:domain=zopeEverybody/p

yield (in French):

  pTous/p


but:

  p i18n:translate= i18n:domain=zope tal:content=string:Everybody /

gives:

  pEverybody/p

which means that the content is not translated.

as a workaround:

  p i18n:translate= i18n:domain=zopetal:block
content=string:Everybody//p

works, since it yields:

  pTous/p


according to the documentation, i18n:translate= tal:content=...
should translate the evaluated content.
http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/ZPTInternationalizationExamples
 
it works in Zope2, why is it different here?

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



Re: [Zope3-dev] i18n in ZPT half-broken?

2005-09-19 Thread Jean-Marc Orliaguet
Fred Drake wrote:

On 9/19/05, Jean-Marc Orliaguet [EMAIL PROTECTED] wrote:
  

Hi! I'm having trouble getting strings to be translated using
tal:content=variable or tal:replace=variable


...
  

according to the documentation, i18n:translate= tal:content=...
should translate the evaluated content.


...
  

it works in Zope2, why is it different here?



This is a bug.  What version of Zope 3 are you using?  It would be
good if we could track down when the bug was introduced.

At any rate, a collector issue should be filed for this:

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


  -Fred

  


Hi!

I'm using the trunk (from 1 hour ago ..). I'm filing a bug ..

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



[Zope3-dev] Re: most specific interface?

2005-09-16 Thread Jean-Marc Orliaguet
Philipp von Weitershausen wrote:

Florent Guillaume wrote:
  

Philipp von Weitershausen wrote:



   from zope.app.content.interfaces import IContentType
   from zope.app.file.interfaces import IFile
   from zope.interface import directlyProvides
   directlyProvides(IFile, IContentType)
  

Watch out! directlyProvides is evil, it *replaces* the interfaces
provided by something. Here, if IFile implemented something else, it
would be lost.

You should always use:

  directlyProvides(ob, ISomething, directlyProvidedBy(ob))

(Or use a convenience method to do that, I'm not sure if alsoProvides()
was ever implemented.)



Yes, alsoProvides() is available in Zope 3.1. So,

   alsoProvides(ob, ISomething)

is the shorter spelling of Florent's line above.

Philipp


  


does alsoProvides() check for interfaces already listed?

apparently not:

interface/declarations.py:

def alsoProvides(object, *interfaces):
   ...
directlyProvides(object, directlyProvidedBy(object), *interfaces)

what happens if you write:

 alsoProvides(ob, ISomething)
 alsoProvides(ob, ISomething)

will ISomething be provided twice? this could be a memory leak in that case.

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



Re: [Zope3-dev] Resource Library Proposal

2005-09-16 Thread Jean-Marc Orliaguet
Gary Poster wrote:


 On Sep 16, 2005, at 5:20 PM, Garrett Smith wrote:

 That's right. But the view can solve these problems easily without  a
 lot of other stuff like yet-another-ZCML directive and  automagical
 transformation of the HTML head element.

 ...


 This is a trivial change to the existing Zope code.


 Agreed that if that is all you need, your solution is very reasonable 
 and less intrusive.  The story becomes more interesting if your main 
 view class has no idea if there is a widget (or something else that 
 needs some JS/CSS) on it.

 Maybe you don't have this use case, in which case you don't need to 
 worry about it.  Your solution works fine for the non-composed-page 
 (i.e., not portlets and not dynamically assembled a la CPSSkins) case.

 Gary


Hi!

I agree, it feels more confortable to push the JS/CSS content into the
head markup than pulling it from inside a ZPT, or a script.

the idea is that adding content into the head must be easily done  at
any stage of a pipeline. I don't see how the ZPT solution that you are
describing Garett could work in cpsskins, since there is no obvious list
of widget inside a flat page view.

there is no such thing as:

for widget in self.widgets()

since getting the list of widgets done is in a recursive tree traversal
process, with relation queries, adapter lookups, etc.

in terms of performance, it would mean that the page would have to be
rendered twice (once for the page's content and another time for the
head). This is what is done in the zope2 version of CPSSkins, and it is
not a very elegant solution.

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



[Zope3-dev] Re: most specific interface?

2005-09-13 Thread Jean-Marc Orliaguet
Philipp von Weitershausen wrote:

Jean-Marc Orliaguet wrote:
  

is the order of the list of interfaces implemented by an object subject
to internal changes?

I have identified the need for such a pattern:

iface = object.interface()

with:

class someObject(object):
implements(IMainInterface, ISecondaryInterface, ...)
def interface():
Return the most specific interface implemented by the element.
return list(providedBy(self))[0]

to be able in that case to get access to the first interface implemented
by an object, as a sort of main object type.



We usually do this differently. If some interfaces are special types
(e.g. IFile is a content type) then we have this interface provide
ISpecialType (e.g. IFile provides IContentType). ISpecialType is an
interface extending IInterface.

Then, no matter where in the list of provided interfaces the type is, it
can be fetch with queryType. Let's take the IFile example from above and
set it up as a content type:

   from zope.app.content.interfaces import IContentType
   from zope.app.file.interfaces import IFile
   from zope.interface import directlyProvides
   directlyProvides(IFile, IContentType)
...

Philipp
  


I see, this is clever, and it simplifies the code.

the idea is that you define as many categories as you need: IMetaType,
ISomeCategory, IWidgetType ... and you create relations between
interfaces with:

directlyProvides(IFile, IContentType)

as if you had a relation tool, then every object that implements IFile
(no matter in what position) will have the IFile content type?

But where do you put the 'directlyProvides' statement? in the class :

class SomeClass:

implements(ISpecialFile, IFile)
directlyProvides(IFile, IContentType)

or in the code? as with:

class SomeClass:

def someMethod(self):
if this_is_a_file_after_all:
directlyProvides(IFile, IContentType)

does it apply to the class in which the code is located in that case? I
suppose that the directlyProvide statement executed last is the one that
matters?

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



  1   2   >