Re: [Zope3-dev] Re: tal:define="..." considered harmful?
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?
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: ... instead of: ... (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?
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:
...: ...
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] unicode bug in the TAL interpreter
Hi!
there is a bug in TAL interpreter (zope2.8 / zope2.9), the following markup
...
(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?
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?
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
[Zope3-dev] Re: Namespaces considered harmful [Was: tal:define="..." considered harmful?]
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
Re: [Zope3-dev] Re: [Zope-dev] Re: Two visions
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
Re: [Zope3-dev] Re: [Zope-dev] Two visions
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: [Zope-dev] Two visions
Jim Fulton wrote: Martijn Faassen wrote: Jim Fulton wrote: [snip] I think that having one name for two radically different, though related, things is very confusing. There are really 2 main technologies that people care about: 1. The Zope app server. This is characterized by things like an object file system, through-the-web scripting and/or development, pluggable course-grained add-ons, etc. I must warn you that what you call 'app server' is not what I call app server; I believe that using the word appserver for this set of technologies could be very confusing to people. I believe Zope 3 is an application server. I believe, say, Django is an application server too, even though as far as I know it lacks an object file system and through the web scripting. Can we find another word for what you mean? I wasn't trying to define app server. I was describing the Zope app server. Jim why not say that the Zope application server is based on the Z Foundation Libraries (ZFL) ? "Z" can be interpreted as being short name for "Zope" without creating a new name for it. which can also be interpreted as the libraries used by the zope foundation software (ZF)? /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
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: Mandatory Viewing!
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] what is ZCML?
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?
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?
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?
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?
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 ). 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] what is ZCML?
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] Re: a new zcml directive?
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') 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?
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?
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: 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] zope.configuration
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
[Zope3-dev] set of interfaces?
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
[Zope3-dev] unregistering global utilities?
Hi Is there any reason for not being able to unregister global utilities? Usually there are registered at startup in ZCML, but they can also be registered programatically with provideUtility(). let's say that the startup process is done and my application wants to load new global utilities. If global utilities are used for registering global resources inside the application they might as well be unregistered when the application new longer needs them. just wondering, is it a technical limitation or is it the kind of thing one wouldn't want to do? /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)
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 IP
[Zope3-dev] [ANN] CPSSkins4Five and CPS4/Z3ECM Paris sprint report
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] getInterface()'s context parameter
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] registration of local utilities through-the-web
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
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
Re: [Zope3-dev] help with directlyProvides
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
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] SimpleKeyReference
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] Re: help with directlyProvides
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 >>> import zope.interface >>> class IMarker(zope.interface.Interface): ... """Marker interface""" ... >>> zope.interface.directlyProvides(f, IMarker) >>> list(zope.interface.directlyProvidedBy(f)) [] >>> 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
Re: [Zope3-dev] help with directlyProvides
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 >>> import zope.interface >>> class IMarker(zope.interface.Interface): ... """Marker interface""" ... >>> zope.interface.directlyProvides(f, IMarker) >>> list(zope.interface.directlyProvidedBy(f)) [] >>> 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 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: 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
[Zope3-dev] zope3 bug day?
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] registration of local utilities through-the-web
answering to: http://www.zope.org/Collectors/Zope3-dev/597 sorry I can't reply online (I don't have the permissions): there are two possibilities: - register a '@@registration.html' for objects that implement Components (this is what I did in http://svn.z3lab.org/trac/z3lab/changeset/3088). However it must be made in the application itself and it takes a while (at least it did for me) to find out why the registration mechanism does not work. An exception saying: "an object cannot be registered in itself" would help. - fix the registration page/view zope3 and make sure that getSiteManager() does not return the object that one is trying to register. I can add a fix, and a test, i.e. using the parent object, OK? if sm == self.context: sm = component.getSiteManager(getParent(self.context)) that ought to be generic enough 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?
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] selecting the translation domain in ZCML
Hi! there is currently one i18n ZCML directive for registering translations: 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: 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
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
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
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] Re: selecting the translation domain in ZCML
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.: Bank 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: Please go to the bank and get some money 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
Re: [Zope3-dev] selecting the translation domain in ZCML
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:
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] adaptation based on class rather than interface
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] Re: adaptation based on class rather than interface
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
[Zope3-dev] Re: adaptation based on class rather than interface
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 mar
Re: [Zope3-dev] Re: adaptation based on class rather than interface
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: adapter registration question
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
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: adapter registration - sort of works :-S
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: relational data
Michel Pelletier wrote: >>Message: 7 >>Date: Wed, 04 May 2005 08:17:09 +0200 >>From: "Achim Domma (Procoders)" <[EMAIL PROTECTED]> >>Subject: [Zope3-dev] relational data >>To: zope3-dev@zope.org >>Message-ID: <[EMAIL PROTECTED]> >>Content-Type: text/plain; charset=ISO-8859-1; format=flowed >> >>Hi, >> >>I'm evaluating ZOPE for some projects we might have to implement. ZODB >>looks very nice for storing object hierarchies but I don't understand >>how to store relational data. >> >>For example, f I store people and qualified realations between them, I >>usally have a table 'person' which hold the person records, >>'relation_type' which hold the possible relations and >>'person_person_relation' which holds the ids of the related persons and >>the id of the type of the relation. >> >>I don't see how I would store something like this in ZODB and I want to >>understand if it's better to stick with a relational database for such a >>case. Or is there a solution, which I might not see at the moment? >> >>This should be no criticism, I only want to understand what Zope is good >>for and where something else might suite my needs better. >> >> > >ZODB does not strictly require hierarchical object graphs, that's a >Zopeism, ZODB will allow you to construct arbitrary object graphs. >Given that it can store "relations" as well as it can store any other >object. Storing references like you describe can be done easily in ZODB. >There are three existing systems like this to my knowledge. > >Although the terminology differs depending on what system you are >looking at, I'll use RDF terms here, subject (referer), predicate >(reference) and object (referent). So if your relationship is "Bob >likes Mary" then 'Bob' is the subject, 'likes' is the predicate, and >'Mary' is the object. This subject/predicate/object model goes by many >names but for the sake of discussion lets call it SPO. > >Storing these references can be done any number of ways, but in ZODB I >have seen two ways, the first is from Zemantic (http://zemantic.org/) >which is a very early Zope 3 product that stores RDF. Zemantic lets you >store and query SPO relations (called "triples" in RDF). Each subject, >predicate, and object is stored in a multi-dimensional ZODB BTree. > >The second is Archetype references (for Zope 2) that use a ZCatalog to >store basically a very similar data structure to what Zemantic uses, a >three column "table" (constructed of ZCatalog indexes) that index the >relationships in each dimension. Archetype references are pretty mature >and offer more features than Zemantic that go beyond RDF, but as of now >it's Zope 2 only. > >The third framework comes with the SchoolBell Zope 3 product I have no >experience with and I don't know exactly how it stores its data, but I >suspect it is less "bleeding edge" than Zemantic (I can say that with >some confidence because I am in the middle of upgrading Zemantic to >rdflib 2.1, which is pretty radically different than 2.0). > >Or, of course, you can just use a relational database which might give >you more piece of mind. > >Hope that helps, > >-Michel > > > Hi Michel! I believe that there are different usages of relationships. The one is to store information into databases in format such as RDF with the ability to do advanced queries (Zemantic). That is the Semantic Web approach, ontologies, the idea of a universal way of representing knowledge, etc.. This involves the existence of a standard language to represent objects and the relationships between them. The other usage is the ability to connect objects together and move some of the logic from the object to the relationship itself, i.e. more or less the Schoolbell approach. Relationships changes trigger events that allow other objects to react to these changes. One of the biggest problems when you're creating a relation between two objects through references is how to deal the case where one of the objects gets deleted, copied, renamed, duplicated, etc.? Implementing this on an object level is difficult because it means that the object must know about the nature of the other objects that it will be related too and it must know how to deal with changes done on these objects. One the related object is changed it is also the relationship that is changed, and when you create the relationship in the first place, you must also tell: what happens if the relationship is modified? Otherwise you'll get orphans, dead links, cycles (if you connect A to B, B to C and then C to A, and try to dereference A) .. 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: [Zope3 / ECM] : Project launched !
Paul Everitt wrote: > Maik Röder wrote: > >> Hi, >> >>> - to unify the whole Zope/CMS-involved community to drastically reduce >>>waste of resources (doing twice or more equivalent components / >>>features). >> >> >> >> How do you plan to keep the project apart from the interests of Nuxeo? > > > Although Julien's intro said Paris and on behalf of Nuxeo, the Z3 ECM > project is a joint collaboration between CPS, Silva, Plone, and any > other CMS or individual developer that wants to work together for the > move to Zope 3. > > We've all made a very strong effort to collaborate and not promote our > individual projects ahead of the common goal. The Zope track at > EuroPython will promote this idea of working together, as will the > planned Z3 ECM sprint the weekend before the conference. > > So far things have gone well for this as a group effort: the panel > discussion closing last year's conference, Philipp and Martijn's Z3 > Base from last year, a sprint that Jim led and all the projects > attended in Vienna, a sprint in Paris that had people from all > projects participate. > > It's now time to start pitching in some resources and getting some > things done. Nuxeo is in the lead on this part. I'm planning to do a > two-day workshop at sprint. We are actively hoping to line up the > shared goals with individual goals. > > --Paul > Hi! I don't understand the concept of being 'neutral' in this context, at this given stage it just means soft consensus when what should be encouraged is initiative. In the commercial world when companies cooperate they make their brand appear clearly on the front page to mean that they support and initiative and this reassures customers. cf. http://www.sun.com/ Here we are supposed to have the notion of cooperation diluted in some sort of undefined abstract notion of cooperation between anonymous participants that have to leave their badge at the entrance. In terms of marketing this is a very bad move because it shows that no one is willing to step forward, commit and endorse the project. We should instead put the logos of the companies that contribute with code, design etc... this will incite others to join. 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: [Zope3 / ECM] : Project launched !
Maik Röder wrote: > Hi, > >> Here we are supposed to have the notion of cooperation diluted in some >> sort of undefined abstract notion of cooperation between anonymous >> participants that have to leave their badge at the entrance. > > Hi! > When I say neutral, I mean "not dominated by the interests of one > company". > This won't happen if different partners are willing to commit and have their logo displayed --- not as an advertisement, but as an endorsement.. Everyone does that in the Java world, why should it be different here? I was thinking more of a consortium, a community of common interests ... > I could rephrase my question to: > > "How do you make sure that people don't get the impression that the > project is in the hand of a company, and not in the hands of a > healthy community? Do you plan to create dome kind of community > foundation?" > >> In terms of >> marketing this is a very bad move because it shows that no one is >> willing to step forward, commit and endorse the project. > > > Before endorsing the project I just need to be sure that there is > a healthy community. > catch-22 :-) to have a healthy community you need a project that is not just vapourware and more than just people with good intentions who'll wait until others do something. You need commitment from all parts. the whole process is currently based on fear, driven by reaction. this is human psychology. The discussion about the community is not the real issue: - if others do something and I don't do anything I'll be left outside and I won't have decision power. - as long as no one does anything, I'm not outside, but nothing happens... Good, I'll wait and hope that it will continue. this is the opposite of a community, this is disguised individualism. >> We should instead put the logos of the companies that contribute with >> code, design etc... this will incite others to join. > > > That would be great. > > Best regards, > > Maik Röder 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] [Zope3 / ECM] : send your logo.
Hi! the front page is going to be updated with the logos of companies / universities / associations ... that are taking part in the project. please send a logo and a link (url)! the recommended size is approx 160x80 px: 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] events: getting the context of objects
Hi! I want to get the location about created object through event notifications, but there is never enough context (there is "Not enough context to determine location root", ...) def objectCreated(event): """event handler """ object = event.object locatable = IPhysicallyLocatable(object, None) if locatable is not None: path = locatable.getPath() What is missing? /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] events: getting the context of objects
Stephan Richter wrote: >On Friday 20 May 2005 06:15, Jean-Marc Orliaguet wrote: > > >>I want to get the location about created object through event >>notifications, but there is never enough context (there is "Not enough >>context to determine location root", ...) >> >> > >At the time an object is created it has no location, since it has not been >added to anything. You really want to listen to the ObjectAddedEvent, which >is triggered when an object is added to a container. > >Regards, >Stephan > > and Roger Ineichen wrote: >Hi Jean-Marc >Created object don't have a ILocation. >They have to be added first to a container. >Use ObjectAddedEvent for get a object with a ILocation. >Regards >Roger Ineichen Thanks! you saved me a lot of time! /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: [Zope3-Users] To Subclass, or to Adapt?
Hi! concerning subclassing vs adapting, these are really different things, arent' they? my understanding (from a semiotic point of view) is that subclassing is about the classification of objects (taxonomy), and that adapting is about the representation of objects. subclassing a car is a vehicle, the class of cars is a subclass of the class of vehicles, and so on. The difficulty is in defining categories of objects, in the conceptualization (what is a "user", what is a "group", what is a "container", what is a "page", what is a "portlet" ... ?) and in relating the concepts together. That takes a lot of time, unless your concepts are already very well-defined. Once you've defined your concepts, you cannot change them because all concepts derived from them will be changed too. adapting here you are re-presenting something, you are not dealing with the original object at all, you are dealing with a representation of the object. Say an actor is representing Hamlet, when doing a theater adaptation of the piece, the original character "Hamlet" is not changed. Since you are not changing the object being adapted you can do many different adaptations (TV, theater, novel, etc). Views are typically adapters, they are the sign of the object being adapted, they are different representations of the same thing. annotations this is metadata, information about the object. That's also a representation of the object, although its stored on the object itself (creation date, author, etc). I suppose that you store there information that cannot be computed directly from the object. Otherwise you'd use an adapter (ISize, etc.). You wouldn't store the size of an object as an annotation. What I don't like about annotations is that the information is stored on the object itself. That's why I'm using relations in cpsskins (http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/storage/relations.py) instead of using annotations even for trivial things such has whether an object is visible or not. If metadata is "external" information about the object, a sum of knowledge about the object then it should not be stored on the object itself, although it's clear that it pertains to the object. But what happens when you are storing a relation, say "object X __ has style ___ Y " ? is the style metadata? NO it's not, it is just that the object is in relation with another object (a style) and the relation (a dyadic relation) is external to *both* of them. Even for monadic relations (X __ is visible, X __ has expired), the relation is *external* to the object. So instead: every object has a unique id (IntId) and the relations between the objects are relations between object ids, which means that I can modify the relations between the objects without changing the objects themselves. This is why I believe that annotations are like adapters all about representation and if adapters are kept separate from the object being adapted then annotations should be kept separate 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] annotations and relations
Derrick Hudson wrote:
>On Fri, Aug 12, 2005 at 03:07:33PM +0200, Jean-Marc Orliaguet wrote:
>
>| What I don't like about annotations is that the information is stored on
>| the object itself.
>
>FYI the annotations framework can be used while storing the annotation
>elsewhere. For example
>
> http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Book/principalannotation.html
>
>
>| That's why I'm using relations in cpsskins
>|
>(http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/storage/relations.py)
>| instead of using annotations even for trivial things such has whether an
>| object is visible or not.
>[...]
>
>I'll have to research this some more. It sounds like some interesting
>ideas on how to organize and manage the data.
>
>-D
>
>
>
Hi Derrick!
maybe I didn't explain what the actual issue is:
The problem is not whether the annotation data is stored *elsewhere* but
whether the annotation data is "tied" with object or not.
If it is tied with the object, then whenever you use annotations to
store a relation between several objects, you have to store the relation
twice if the relation is dyadic, to be able to do a reverse lookup:
cf. zope.app.dublincore.dcterms
"Relation.Requires": ("dcterms:requires", ""),
"Relation.Is Required By": ("dcterms:isRequiredBy", ""),
You'd store
"Relation.Requires"__ B in A
and
"Relation.Is Required By" __ A in B
So storing dyadic relations as annotations is a bit of a hack.
Schoolbell relationships also store dyadic relations as annotations,
that takes twice as much information as is actually needed.
However if you do not tie the relation with the objects of the relation
(the relates), then you need to store the relation only *once*, because
if you have a first that "Relation.Requires" a second, then you can
lookup the seconds that are "Relation.Is Required By"the first, by using
the same "Relation.Requires" predicate.
The issue become even more complicated with triadic relations (a
relation between 3 objects). The classical hack consists in storing 3
dyadic relations between 3 objects, i.e. in the end 6 times as much
information as is actually required and it's logically incorrect too
(since you can't build genuine triadic relations with help of a
combination of dyadic relations). RDF does something called
"reification" to simulate triadic relations.
Anyway the bottomline is that an enormous amount of information has to
be duplicated for nothing.
cheers
/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: annotations and relations
Derrick Hudson wrote: >On Fri, Aug 12, 2005 at 07:54:21PM +0200, Jean-Marc Orliaguet wrote: >| Derrick Hudson wrote: >| >| >On Fri, Aug 12, 2005 at 03:07:33PM +0200, Jean-Marc Orliaguet wrote: >| > >| >| What I don't like about annotations is that the information is stored on >| >| the object itself. >| > >| >FYI the annotations framework can be used while storing the annotation >| >elsewhere. For example >| > >http://www.zope.org/Wikis/DevSite/Projects/ComponentArchitecture/Zope3Book/principalannotation.html >| > >| > >| >| That's why I'm using relations in cpsskins >| >| >(http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/storage/relations.py) >| >| instead of using annotations even for trivial things such has whether an >| >| object is visible or not. >| >[...] >| > >| >I'll have to research this some more. It sounds like some interesting >| >ideas on how to organize and manage the data. > >| Hi Derrick! >| >| maybe I didn't explain what the actual issue is: >| >| The problem is not whether the annotation data is stored *elsewhere* but >| whether the annotation data is "tied" with object or not. > >Ahh, I see. That is a little bit different. > >| If it is tied with the object, then whenever you use annotations to >| store a relation between several objects, you have to store the relation >| twice if the relation is dyadic, to be able to do a reverse lookup: > >Yeah, like the classic doubly-linked list. > >I'll definitely have to take a look at this relations tool and see how >it works. Thanks for explaining that. > >-D > > Hi Derrick, If you need to do really advanced queries (cf. semantic web) then Zemantic is much better (http://zemantic.org/) the relation store I'm using is a minimal, light-weight implementation for connecting components as opposed to organizing content using a simple ontology [2]. Hence relation lookups are not much more advanced than adapter lookups, the most advanced query I've add to deal with so far uses a predicate composed of several predicates [1]. The idea is the same as using adapters to connect components, except that in this case the relations between the components change all the time, so using adapters is not really appropriate, and nothing is being adapted either. [1] http://svn.nuxeo.org/trac/pub/changeset/25812 [2] http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-ajax-integration/ontology.py?rev=25814 /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] local portlets and perspectives
Hi! Somehow related to the discussion on optimizing catalog queries, I have been thinking about how to best implement local portlets in cpsskins in terms of scalability, performance and functionality. The implementation is heavily dependent on being able to performance effective catalog queries (it is OK to wait 2 seconds in an ECMS to search 1 million documents, but it is not OK to have to wait 2 seconds to render a page containing portlets). Here is the proposal: http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_08_24_local-portlets It is built on the notion of "Perspective" (see the link) and on the idea of querying the catalog using triadic relations instead of joining sets of query results based on dyadic predicates (such as with RDF). 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] [DRAFT] local portlets and perspectives
Gary Poster wrote: > > On Aug 24, 2005, at 2:24 PM, Jean-Marc Orliaguet wrote: > >> >> Hi! >> >> Somehow related to the discussion on optimizing catalog queries, I have >> been thinking about how to best implement local portlets in cpsskins in >> terms of scalability, performance and functionality. The implementation >> is heavily dependent on being able to performance effective catalog >> queries (it is OK to wait 2 seconds in an ECMS to search 1 million >> documents, but it is not OK to have to wait 2 seconds to render a page >> containing portlets). >> >> Here is the proposal: >> http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/ >> 2005_08_24_local-portlets >> >> It is built on the notion of "Perspective" (see the link) and on the >> idea of querying the catalog using triadic relations instead of joining >> sets of query results based on dyadic predicates (such as with RDF). > > Hi Gary! > I need to read more to have a more complete reply (though I'm hoping > Benji will do it for me, since he knows more about CPSSkins than I), > but here are a few responses, based on reading it and talking it over > with Benji. > > Your overall model is interesting to me because it goes a good way to > unifying the various portlet use cases. I know of six categories: > page designer wants to fill slots for a site; page designer wants to > fill slots for a section of a site; page designer wants to fill slots > for a page on a site; user wants to fill slots for a site; user wants > to fill slots for a section of a site; and user wants to fill slots > for a page on a site. The section and page use cases might be > collapsed technically, but have a different feel to a user, IMO, and > so should be separated. Combining these into a unified model is > impressive and cool. > > I worry that the description does not get into the possible UI > expectation differences between a page designer and a user, and > between working on a site or section versus a single page. These > seem like tricky UI bits to get right to me. I'd be interested in > seeing a discussion of your thoughts of the UI from this perspective, > especially in regards to showing a user, within an editing screen, > which portlets are being edited from a page perspective, from a per- > user perspective, from a section perspective, and so on. It seems > like it could cause information overload. > I'll get back to this part in a mail later since the answer is longer. But basically: - there is a separation between page designer (theme designer) space and user space. Page designers add portlets into cells and users add portlets to slots. A same theme can have several pages, and pages can be associates to sections of the site. A page is a page (not a perspective). Perspectives are only for portlets in slots. - the main idea with perspectives is that you can group contextual information into a few categories: 1) let us say for instance: the category of users that have just logged in for the first time. These users would see the site from "the first login perspective", maybe be presented with a "Welcome" portlet. 2) a "perspective designer" (in this case an application designer) would in a blog application create a "Blog perspective" for users, where they'd see the blog categories, the archived blogs, etc. Currently this is done in CPSBlog by creating local portlets for every user which is not very efficient in terms of scalability. 3) in a webmail application the "perspective designer" would set up an INBOX portlet, a toolbox portlet for sending mail, etc. as a result the end user would move from a "blog" perspective to a "webmail" perspective even maybe by staying in the same folder (which is not easy to implement with the notion portlets associated to sections of a site) This shows that the notion of sections of a site is not appropriate for local portlets, it is better to use a more general concept such as the one as Perspective. Also if there are many sections in a site, there are in comparison very few perspectives. In fact when it comes to the question of the visibility of portlets (visible in some folders of the site) this will be done by using a visibility filter (the infrastructure is already implemented cf. http://www.z3lab.org/sections/front-page/white-papers/draft-renderer/downloadFile/attachedFile/renderer-architecture.png) Hence for a given user there won't typically be more than 4 or 5 perspectives in the portal. I have prototype soon ready, that will become clearer with an animation. > The 'perspective' idea is a good concept for the discussion (and I > used the word above), but
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Michel Pelletier wrote: >On Wed, 2005-08-24 at 15:28 -0400, [EMAIL PROTECTED] wrote: > > > >>Message: 5 >>Date: Wed, 24 Aug 2005 20:24:30 +0200 >>From: Jean-Marc Orliaguet <[EMAIL PROTECTED]> >>Subject: [Zope3-dev] [DRAFT] local portlets and perspectives >> >> > > > > >>It is built on the notion of "Perspective" (see the link) and on the >>idea of querying the catalog using triadic relations instead of joining >>sets of query results based on dyadic predicates (such as with RDF). >> >> > >I've been looking for more info on Peirce relations since you mentioned >them to me in Paris, but I haven't found much. This is a good one I've >found so far: > >http://www.angelfire.com/md2/timewarp/peirce.html > >I like: > >"""According to Peirce, ‘meaning’ is a triadic relation between a sign, >an object, and an interpretant. This triadic relation is not reducible >to a set of dyadic relations between a sign and an object or between an >object and an interpretant (CP 1.345). Meaning is never reducible to >Firstness or Secondness, but can only be a ‘genuine’ Thirdness. A >general meaning can always be found in ‘genuine’ triadic relations, but >can never be found in ‘degenerate’ triadic relations which have lost >their Thirdness.""" > >Word. But it sounds to me from the description that follows that RDF is >a triadic relation, but I'm no semiotic phenomenologist. Do you know of >more references on this subject? > >Another thought, can a Peirce relation be meta-encoded in RDF? > >-Michel > > > Hi Michel! You would need a quadruple store in that case (see the previous mail) - a triple store is not enough, since in the triple store one place is already taken by the predicate. if you have (Subject, Predicate, Object) in RDF here you have: - monadic relation: (first, predicate) - dyadic relation: (first, second, predicate) - triadic relation: (first, second, third, predicate) then not necessary all triadic relations are genuine, but at least there are three elements in them and a unity which a combination of dyadic relations won't give you. see also: http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/doc/peirce-relations.txt /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] [DRAFT] local portlets and perspectives
Michel Pelletier wrote: >On Thu, 2005-08-25 at 04:10 +0200, Jean-Marc Orliaguet wrote: > > > >>You would need a quadruple store in that case (see the previous mail) - >> >> > >rdflib.Graph is actually a quadruple store. Many users still say >TripleStore because that was the old class name, but most RDF systems, >rdflib included, have grown a concept called "context" a quad-element >that lets you assign context to a triple, sparql calls this the >"source", and some people say that it is used to track the "provenance" >of a triple. Perhaps this is similar to the triadiac relations. > > > OK, but the idea is that you can choose the elements in the relation, if one them is set in advance, this is just an extra parameter that is stored. >>if you have (Subject, Predicate, Object) in RDF >> >>here you have: >>- monadic relation: (first, predicate) >>- dyadic relation: (first, second, predicate) >>- triadic relation: (first, second, third, predicate) >> >> > >Ok, so in RDF a dyadic relationship is (DocumentURI, dc:title, "Expense >Report"), what would a similar triadic relationship be? > > >-Michel > > (SellerURI, merchandiseURI, BuyerURI, "Sale Transaction") in a sale transaction a seller sells some merchandise to a buyer the relation involves three dyadic relations: - a relation between the seller and the buyer, - a relation between the seller and the merchandise - a relation between the merchandise and the buyer but the transaction involves all three elements taken together, not any two of the three taken separately. let's put it that way: you can store dyadic relations in you database and do queries to guess who the buyer is in a given transaction, who the seller is and what the sold item is, but this will never represent the transaction itself. everything that involves some sort of agreement, laws, regulations, general concepts is triadic. Remove the agreement and the dyadic relations will fall. one practical example is the one of a feeback loop. If you try to decompose it into dyadic relations the feedback loop will stops working because all three elements must be taken together (see the second part of the message in this thread too: http://suo.ieee.org/email/msg10941.html ) an adapter is involved in a triadic relation too, when you declare the adapter you have to specify the interface adapted, the interface implemented and the factory. remove any of the three elements and the "adapter" relation will make no sense. BTW adapter are stored in zcml as triadic predicates: 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: [DRAFT] local portlets and perspectives
Olivier Grisel wrote: > Jean-Marc Orliaguet wrote: > >> >> (SellerURI, merchandiseURI, BuyerURI, "Sale Transaction") >> > Let's rewrite this relation to a prolog equivalent fact: > transaction(SellerURI, merchandiseURI, BuyerURI, "Sale Transaction"). > > There is no primary key in that relation. We could add one such as > TransactionURI for instance : > > transaction(TransactionURI, SellerURI, merchandiseURI, BuyerURI, "Sale > Transaction"). > > In this case we could rewrite this fact without loss of information > using only binary relations/predicates by projecting it: > > transactionSeller(transactionURI, SellerURI), > transactionMerchandise(transactionURI, merchandiseURI), > transactionBuyer(transactionURI, buyerURI), > transactionType(transactionURI, "Sale Transaction"). > > This description is then equivalent and RDF friendly. However it > requires the introduction of a primary key which was implicit in the > first description and is much more verbose. > > In the portletInPerspective example, one would similarly need to > introduce a primary key to be able to describe the same facts using > bianry relations only and thus being able to use a rdflib graph to > store and query the local/contextual porlets layouts. > > -- > Olivier > Hi Olivier! If you use a primary key to collect all the dyadic relations into a unique relation, then you have implicitly created a triadic relation (identified by the key), except that you also explicitly enumerate the underlying relations. So in the end you'll have to store: the primary key + 3 dyadic relations between 6 elements. best 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: [DRAFT] local portlets and perspectives
Olivier Grisel wrote: > Jean-Marc Orliaguet wrote: > >> If you use a primary key to collect all the dyadic relations into a >> unique relation, then you have implicitly created a triadic relation >> (identified by the key), except that you also explicitly enumerate the >> underlying relations. So in the end you'll have to store: the primary >> key + 3 dyadic relations between 6 elements. > > > Yes, I was just saying that is possible to use only binary relations > throutgh projections on a pure expressive power viewpoint by using > theprimary key trick. In practice, this might seriously impact the > perfomance of the data model since it implies a lot of join operations > where a single select should be sufficient. > > Furthermore, using binary projections instead of n-ary predicates make > it much harder to a human to quickly understand the model. > > Regards, > > -- > Olivier > the thing is that even logically there *is* a triadic relation created by the fact that there is a primary key. Just as when you write: the adapter is registered with a discriminator, isn't it? that's what you call the "primary key". the "primary key trick" is not a trick, because you have actually created a triadic relation by connecting 3 elements together. Without this key, you couln't build a triadic relation with help of the dyadic relations only because the unity of the relation would be missing. /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] [DRAFT] local portlets and perspectives
Hi! concerning perspectives, what would be the use cases? I talked with Eric, we came up with: activity-driven perspectives: --- - browsing perspective (going through folders, finding documents, ..) - dashboard perspective (tasks list, documents to review, etc..) - collaboration perspective (diffing content, svn, synchronising content, etc) - contributing perspective (document creation, publication, ..) - ... => it is the application / workflow that sets the perspective location-based perspectives: --- - when entering a given section of the site, a new set of portlets is displayed in some of the page's slots - the user's home folder/ perspective with the ability to rearrange portlets within some limits. => it is the site location that sets the perspective the roles would be divided in: - - theme / page designer (responsible for preserving the site's design, corporate profile, logotype, etc..). - content designer (responsible for adding portlet content to the site using images, text, putting ads on the front page, etc) - perspective / UI designer (responsible for visually placing activity portlets inside a given application, action portlets, navigation portlets) --- the configuration would be saved in zcml as part of the application. - user (wants to re-arrange portlets on the work space / create new portlets cf. google news portal) any comment / ideas? /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: Zope3-dev Digest, Vol 25, Issue 37
Michel Pelletier wrote: >>From: Olivier Grisel <[EMAIL PROTECTED]> >>Subject: [Zope3-dev] Re: [DRAFT] local portlets and perspectives >> >> > > > >>>(SellerURI, merchandiseURI, BuyerURI, "Sale Transaction") >>> >>> >>> >>Let's rewrite this relation to a prolog equivalent fact: >>transaction(SellerURI, merchandiseURI, BuyerURI, "Sale Transaction"). >> >>There is no primary key in that relation. We could add one such as >>TransactionURI for instance : >> >>transaction(TransactionURI, SellerURI, merchandiseURI, BuyerURI, "Sale >>Transaction"). >> >>In this case we could rewrite this fact without loss of information >>using only binary relations/predicates by projecting it: >> >>transactionSeller(transactionURI, SellerURI), >>transactionMerchandise(transactionURI, merchandiseURI), >>transactionBuyer(transactionURI, buyerURI), >>transactionType(transactionURI, "Sale Transaction"). >> >>This description is then equivalent and RDF friendly. However it >>requires the introduction of a primary key which was implicit in the >>first description and is much more verbose. >> >> > >I think the original triadic statement can be encoded with one rdf >triple + context in rdflib: > >Graph.add((SellerURI, merchandiseURI, BuyerURI), TransactionURI) > >Where TransactionURI is the context. I'm still feeling that these two >models are either equivalent, or there is some property of triadic >relations that I just don't "get" yet. This paper: >http://www.cs.indiana.edu/pub/techreports/TR606.pdf also appears (from >reading the first five pages) to state that reified RDF triples *are* >Peirce relations, which seems to make sense as they are statements about >statements, although I can't claim to really understand the guts of the >paper. > >I want to reiterate to you guys that I'm not trying to be argumentative >or prove that one thing is better than the other, I take a deep interest >in these subjects and I want to know as much as possible about them. >But unfortunately I think we've strayed off the topic for this list. > >-Michel > > > Hi Michel, the whole issue with RDF I think is: many who build representational models have noticed that the (subject, object, predicate) triad is not sufficiently flexible to represent knowledge that has to do with laws, agreements, abstract concept, regularity, phenomena that evolve with time, etc. All these phenomena cannot be represented by using a long chain of dyadic predicates. By adding new dyadic relations into the graph you are not adding more information into the model, you are just adding more data. Every language on Earth uses verbs that correspond to monadic, dyadic or triadic predicates. No verb in any language uses predicates with four terms. It means that with 3 kinds of predicates you can express just any idea, but that you cannot with dyadic predicates only express all ideas. For some reason, RDF was designed on the basis of dyadic predicates (subject, object). It also means that there is a whole category of phenomena that cannot be represented in RDF-based models, and that you will have to use a language such as Python on top the model to add the missing relations. You can use adapters, for instance; these are great triadic relations. The only valid solution would be to break the RDF model and introduces quads, but this would also mean breaking existing software and lose interoperability with the triple model. No one is willing to do this, so instead you'll find such fixes as: - reification (turning an abstract concept into a concrete thing), i.e. since a triadic idea cannot be modelled using a combination of dyads, we will give it a name, and then we will be able to say: "there is a transaction", "the transation has a buyer", "the transaction has a seller", etc. - adding a "context", i.e a fourth element, and use it to refer to the relation: graph.add(triple, context) which is a variation on the reification method, but maybe easier to use. All of this is meant to fix a model on an API level without breaking it, but it is still dyadic relations that are used to refer to other dyadic relations ... Basically: if you add the thing that is missing, you break the model.. 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: Zope3-dev Digest, Vol 25, Issue 37
Benji York wrote: > Jean-Marc Orliaguet wrote: > >> the whole issue with RDF I think is: many who build representational >> models have noticed that the (subject, object, predicate) triad is not >> sufficiently flexible to represent knowledge that has to do with laws, >> agreements, abstract concept, regularity, phenomena that evolve with >> time, etc. > > > Can you give an example of one of these pieces of knowledge? Yes: "John gives a book to Mary" means more than a dyadic relation followed by another: "John drops the book" and "Mary picks the book" it means that there is an agreement between John and Mary that the book is indefinitely hers (which '__ gives __ to ___' signifies). A notion of a transfer of the right of property, which no combination of dyadic predicates can express because all three elements in the relation must be taken in the same act. If you store the relations "John drops the book" and "Mary picks the book" how will you know if the book belongs to Mary and belonged to John before it was given to her? You could add "the book belongs to John" "the book belongs to Mary", add some date information, add the fact that the action is a gift (reification), ... all the pieces still have to be put together. This will need to be interpreted in a language (or a query language that does unions, intersections, ..) that knows how to put the pieces together. The model is very verbose is not explicit at all. "Joe prefers apples to cookies" cannot be expressed as a mere combination of: - "Joe likes apples" - "Joe likes cookies" - "apples are prefered to cookies" (i.e. by whom?) The last proposition is incorrect outside the context of "Joe prefering apples to cookies". So if you add such a relation to your storage without the context, you introduce a proposition that has no meaning. - a feedback loop is another one that cannot be expressed as a combination of dyads, since all 3 entities in the loop cooperate simultaneously. - zope adapters cannot be expressed by combining dyadic predicates only. When you look up an adapter you must pass the context AND the new interface. All three entities must be treated together. This could be a good exercice to convert the zcml declaration of adapters to a RDF schema and do something with it ... /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: Zope3-dev Digest, Vol 25, Issue 37
Benji York wrote: > Jean-Marc Orliaguet wrote: > >> Benji York wrote: >> >>> Can you give an example of one of these pieces of knowledge? >> >> >> "John gives a book to Mary" > > >> If you store the relations "John drops the book" and "Mary picks the >> book" how will you know if the book belongs to Mary and belonged to John >> before it was given to her? You could add "the book belongs to John" >> "the book belongs to Mary", add some date information, add the fact that >> the action is a gift (reification), ... all the pieces still have to be >> put together. This will need to be interpreted in a language (or a query >> language that does unions, intersections, ..) that knows how to put the >> pieces together. The model is very verbose is not explicit at all. > > > I assume you mean "no combination of dyadic predicates using only > John, the book, and Mary as subjects and objects". If so, I agree. > > We're drifting fatally off topic here, but: Just as there are some > statements that cannot be expressed as dyadic predicates, are there > also those which cannot be expressed as triadic predicates? > > "John gives a book to Mary in exchange for 5 euros" > > If you store the relations "John gives a book to Mary" and "Mary gives > 5 euros to John" how will you know that the 5 euros were payment for > the book? Now we'll really off-topic, but well: Actually there is a theorem (called the "reduction thesis", hinted by Peirce 100 years ago, and proved first in 1988) that says that even though no combination of dyadic relations can be used to build a genuine triadic relation, any relation of adicity > 3 can be built by combining triadic relations. Here is a quote that I found (CP. 6 is Collected Papers of C.S Peirce vol6): CP 6.323. A tetradic, pentadic, etc. relationship is of no higher nature than a triadic relationship; in the sense that it consists of triadic relationships and is constituted of them. But a triadic relationship is of an essentially higher nature than a dyadic relationship, in the sense that while it involves three dyadic relationships, it is not constituted by them. If A gives B to C, he, A, acts upon B, and acts upon C; and B acts upon C. Perhaps, for example, he lays down B, whereupon C takes B up, and is benefited by A. But these three acts might take place without that essentially intellectual operation of transferring the legal right of possession, which axiomatically cannot be brought about by any pure dyadic relationships whatsoever. Here is the example that you took, analysed into 6 triadic relations: --- START QUOTE --- Peirce: CP 7.537 There are no more Kainopythagorean categories than these three. For the first category is nonrelative experience, the second is experience of a dyadic relation, and the third is experience of a triadic relation. It is impossible to analyze a triadic relation, or fact about three objects, into dyadic relations; for the very idea of a compound supposes two parts, at least, and a whole, or three objects, at least, in all. On the other hand, every tetradic relation, or fact about four objects can be analyzed into a compound of triadic relations. This can be shown by an example. Suppose a seller, S, sells a thing, T, to a buyer, B, for a sum of money, M. This sale is a tetradic relation. But if we define precisely what it consists in, we shall find it to be a compound of six triadic relations, as follows: Peirce: CP 7.537 1st, S is the subject of a certain receipt of money, R, in return for the performance of a certain act As; Peirce: CP 7.537 2nd, This performance of the act As effects a certain delivery, D, according to a certain contract, or agreement, C; Peirce: CP 7.537 3rd, B is the subject of a certain acquisition of good, G, in return for the performance of a certain act, Ab; Peirce: CP 7.537 4th, This performance of the act Ab effects a certain payment, P, according to the aforesaid contract C; Peirce: CP 7.537 5th, The delivery, D, renders T the object of the acquisition of good G; Peirce: CP 7.537 6th, The payment, P, renders M the object of the receipt of money, R. Or we may define a sale as the execution of contract of sale. The contract of sale has two clauses. The first clause provides for a giving and a receiving. The giving is by the seller of the commodity; the receiving is by the buyer of the same commodity. The second clause provides for a giving and a receiving. The giving is by the buyer of the price; the receiving is by the seller of the same price. The execution is of the first clause and of the second, etc. But I do not think this latter definition as good as the other, since it introduces several unnecessary elements an
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Hi! >> >> Somehow related to the discussion on optimizing catalog queries, I have >> been thinking about how to best implement local portlets in cpsskins in >> terms of scalability, performance and functionality. The implementation >> is heavily dependent on being able to performance effective catalog >> queries (it is OK to wait 2 seconds in an ECMS to search 1 million >> documents, but it is not OK to have to wait 2 seconds to render a page >> containing portlets). >> >> Here is the proposal: >> http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_08_24_local-portlets >> >> >> It is built on the notion of "Perspective" (see the link) and on the >> idea of querying the catalog using triadic relations instead of joining >> sets of query results based on dyadic predicates (such as with RDF). > > > I'd like to make some substantive comments on the proposal. My initial > reaction is that the solution proposed is very complex and I'm not at all > clear about the problem it solves. :) > > I think I need to understand how themes work in CPS skins. In > particular, > I need to understand the relationships between themes, pages, sections, > cells, global portlets and local portlets. Your proposal is based on > but doesn't really describe most of these concepts. Can you recommnd > some documentation? > > Jim > Hi Jim, here are the concepts defined: - A *theme* is a visual unity, when you go from cnn.com to bbc.co.uk you see that sites are using different themes. The includes, colors, styles, icons, etc. - Inside a same theme there are *pages*, pages use the styles defined in the theme, but the layout may be different (3 columns -> 2 columns) from one page to another. The rationale is that when you create a new page, you want to be able to reuse the same styles. typically there is: the front page, the section page, the login page ... - a *section* of a site is not specific to cpsskins, it can be a folder, a project room, a workspace, cnn.com has "World", "U.S", "Weather", etc. - *cells* are layout elements in a page that could be also called "columns", the left column can contain navigation portlets, the right column can contain ads, the main column usually the document being looked at. - *global portlets* are part of a page, they are placed in cells. i.e. if a page is displayed and the portlet is in the page, then the portlet will be displayed. Typically global portlets are: the logotype, some navigation portlet. Only theme designers can manage global portlets. They make the theme's skeleton. - *slots* are placeholders that can contain portlets. A theme designer will add slots to a theme, but it's not up to him/her to define which portlets will be displayed in the slot. The theme design will decide what style the portlets inside the slots will have. - local portlets are placed in slots by the users themselves. here is an illustration: on the chalmers website here is the front page: - http://www.medic.chalmers.se/~jmo/Zope3/chalmers-1.png here is the same page with the slots, global portlets and local portlets shown: - http://www.medic.chalmers.se/~jmo/Zope3/chalmers.png - global portlets are represented in orange, no user that is not theme designer is allowed to modify them - the slots are represented by areas with a red border. - the local portlets are represented in violet. users who work with content can modify them and add new ones into the slots. here the template uses with Chalmers institutions: - http://www.medic.chalmers.se/~jmo/Zope3/tme.png content creators can only add content inside the predefined slots, which guarantees that the graphic profile is preserved. What problem perspectives solves? -- local portlets are currently stored in local folders in a .cps_portlets container with the name of the slot in which they are located. It means that the user has to go into a given folder, add a portlet into a slot and the portlet will be visible starting from this folder. After a while there are 100 of portlets scattered around the entire site, some in /sections/A, some in /sections/A/B some in / ... there is no grouping of portlets. we find out that what users actually want to do is to define a set of portlets that will be shown in a given section of the site (eg. in 'education', in 'research', ...) and only there. This is somehow done when portlets are stored in folders, but it is very difficult to group the portlets together, because there is no notion of "group of portlets" displayed in given context. so basically the notion of perspective is just a way of grouping portlets together and give a name t
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: >> >> Hi Jim, here are the concepts defined: > > > It's too bad these aren't defined in a more perminent and referenceable > location. > >> - A *theme* is a visual unity, when you go from cnn.com to bbc.co.uk you >> see that sites are using different themes. The includes, colors, styles, >> icons, etc. > > > > >> - Inside a same theme there are *pages*, pages use the styles defined in >> the theme, but the layout may be different (3 columns -> 2 columns) from >> one page to another. The rationale is that when you create a new page, >> you want to be able to reuse the same styles. >> >>typically there is: the front page, the section page, the login >> page ... > > > A page, as defined here, seems to be a template, as opposed to a page > with > a particular URL. I take it all section index.html pages use the same > theme pages. The use of the term "page" here seems unfortunate. If a > section > has a page for searching, would that also use the section page from > the theme? > Or would that use some other theme page? > a page has a "template" like a Zope Page Template, that would correspond to the idea of layout. it's as unfortunate as a name as the directive that is associated to a browser view, and a page template. But the idea is the same. it is more like a browser page than a site's page in any case.. i.e. a page that you see in your browser, the same "page" as in "PageMaker", a canvas, a template, etc.. > I think this is a critival point. When I visit a URL on a section, say: > > .../mysection/foo.html > > what determines which theme page is used? > there is a negociation, a default theme page to fall back to, but you can specify the page to use in many ways; through a URL parameter, ?page=frontpage, through a cookie, through a session variable, by adding a subscriber to IBeforeTraverse and set the page to a "calendar" page if you enter a part of the site that has to doing with calendaring application... >> - a *section* of a site is not specific to cpsskins, it can be a folder, >> a project room, a workspace, cnn.com has "World", "U.S", "Weather", etc. >> >> - *cells* are layout elements in a page that could be also called >> "columns", the left column can contain navigation portlets, the right >> column can contain ads, the main column usually the document being >> looked at. > > > So a single cell can contain multiple portlets? yes > I assume that they need not > be layed out soley in columns. > if the portlets are to be presented horizontally then it's the cell's layout that takes over. The notion of cell is about logical containment not about presentation, however cells have a layout. Cell elements need a view to be displayed that involves the cell's layout. with a text renderer the cell is the same, but the cell's rendering is different from the one of a web browser. >> - *global portlets* are part of a page, they are placed in cells. i.e. >> if a page is displayed and the portlet is in the page, then the portlet >> will be displayed. Typically global portlets are: the logotype, some >> navigation portlet. Only theme designers can manage global portlets. >> They make the theme's skeleton. > > > So a theme page has some cells that are each filed with 0 or more > global portlets? yes > >> - *slots* are placeholders that can contain portlets. A theme designer >> will add slots to a theme, but it's not up to him/her to define which >> portlets will be displayed in the slot. The theme design will decide >> what style the portlets inside the slots will have. > > > Is a slot a kind of portlet? from the cell's perspective yes, in the sense that it is contained in the cell like global portlets. but if you compare slots and portlets then no it's not a portlet, a slot refers to portlets, and a slot without portlets to refer to will not display anything. however the portlets inherit the format properties associated to slots. so you can see slots as a collection of portlets that share properties. > Does a slot go into a cell? yes, like global portlets > Do pages contain both slots and cells? Or do pages contain > cells, which can contain either slots or global portlets? pages contain cells, that contain global portlets, or that contain slots that refer to local portlets slots and global portlets can be found inside a same cell > >> - local portlets are placed in slots by the users themselves. > > > > >> here is an illustration: >> >> on the chalmers website here is the front page: >> - http://www.medic.chalmers.se/~jmo/Zope3/chalmers-1.png >> >> here is the same page with the slots, global portlets and local portlets >> shown: >> - http://www.medic.chalmers.se/~jmo/Zope3/chalmers.png >> >> - global portlets are represented in orange, no user that is not theme >> designer is allowed to modify them >> - the slots are represented by areas with a red border. >> - the local portlets are represented in violet. users who work with >> content can modify the
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jean-Marc Orliaguet wrote: > >a page has a "template" like a Zope Page Template, that would correspond >to the idea of layout. > >it's as unfortunate as a name as the directive that is >associated to a browser view, and a page template. But the idea is the same. > >it is more like a browser page than a site's page in any case.. i.e. a >page that you see in your browser, the same "page" as in "PageMaker", a >canvas, a template, etc.. > > > exactly as it says on the PageMaker product website, actually """Quickly lay out publications by creating frames to hold text and graphics, applying master pages to apply different page designs within a single publication, and using layers to set up a single file for multiple versions of a publication.""" cf. http://www.adobe.com/products/pagemaker/overview.html the term "master page" is less ambiguous maybe. But it's definitely not a page in the sense of "the concrete page of a book", but instead the design, the form of a page of a book, that by extension became "the front page", the "chapter page". If you work with content it definitely means a different thing. /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] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> >> a page has a "template" like a Zope Page Template, that would correspond >> to the idea of layout. > > > Sure, but It still seems that a "theme page" fills the same role as a > template, in that it is meant to be used for many different page. > > Let me put this another way. When you define a theme page, you aren't > saying anything about URLs. > exactly, the page <-> URL associating is done later on during page rendering. There could be a page <-> view association too, or a page <-> hour of the day association,.. >> >> it's as unfortunate as a name as the directive that is >> associated to a browser view, and a page template. But the idea is >> the same. > > > Not quite, AFAICT. browser:page actually defines a page (e.g. > "foo.html") > relative to an object type. yes, but the object type is independent of the URL too, just like a theme page says nothing about what it will be applied to... > >> it is more like a browser page than a site's page in any case.. i.e. a >> page that you see in your browser, the same "page" as in "PageMaker", a >> canvas, a template, etc.. > > > I don't understand this. By "browser page", do you mean it is like > a page as defined by the zcml browser:page directive? Or like a > page that is displayed in a browser? > I mean, in the sense that the page applies to a whole class of things, not to a particular individual instanciated object in the site. >> >>> I think this is a critival point. When I visit a URL on a section, >>> say: >>> >>> .../mysection/foo.html >>> >>> what determines which theme page is used? >>> >> >> >> there is a negociation, a default theme page to fall back to, but you >> can specify the page to use in many ways; through a URL parameter, >> ?page=frontpage, through a cookie, through a session variable, by adding >> a subscriber to IBeforeTraverse and set the page to a "calendar" page if >> you enter a part of the site that has to doing with calendaring >> application... > > > Does the page ever depend on the thing being traversed? Is there > a point where you'd say: > > "when traversing an IBar with the name foo.html, use the theme page >named 'splat'"? > it would be the application's responsibility to override the default page to use, as it is done with the default skin. I think that schoolbell calendar application does that when the user enters a calendar application site. it is very much like skin negociation, there is a page used by default, but it can be changed on-the-fly. > I'm having a hard time understanding the relationship between > objects, URLs and theme pages. > > Jim > it's not implemented yet in the Zope3 version (the only thing there is currently effective is the default page), I'd like this feature to be pluggable like the ISkin way of choosing a skin. in the zope2 version there are 5 or 6 ways of setting the page as described in: http://www.medic.chalmers.se/~jmo/CPS/CPSSkins-Book.pdf under the chapter: "USING SEVERAL THEMES INSIDE THE SAME PORTAL" in any case, there is no hardcoded link between pages and the content of the site. /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] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Jim Fulton wrote: >> > ... > >>> Not quite, AFAICT. browser:page actually defines a page (e.g. >>> "foo.html") >>> relative to an object type. >> >> >> >> >> yes, but the object type is independent of the URL too, just like a >> theme page says nothing about what it will be applied to... > > > But browser:page *does* specify the object type. When I use browser:page > to define foo.html for IContact objects, I am causing contacts to have > that > page and not impacting any non-contact objects. ok, if you mean that a page in cpsskins is not concerned about what object it will be associated with, then that's true. however the association will have to be done in some way, otherwise only the default page will always be displayed. So the difference is that cpsskins separates the declaration of the page from the context in which the page will be used. but the page will still have to be associated with some IContact, or with some part of the site, or with anything that can be associated with it otherwise it will never get a chance to be displayed. > >> >> >> it's not implemented yet in the Zope3 version (the only thing there is >> currently effective is the default page), I'd like this feature to be >> pluggable like the ISkin way of choosing a skin. >> >> in the zope2 version there are 5 or 6 ways of setting the page as >> described in: >> http://www.medic.chalmers.se/~jmo/CPS/CPSSkins-Book.pdf >> >> under the chapter: >> "USING SEVERAL THEMES INSIDE THE SAME PORTAL" >> >> in any case, there is no hardcoded link between pages and the content of >> the site. > > > I'm sorry, I still don't understand. > > Lets say I have a content object, say a poll. Now, I want that > poll to have a number of pages: > > - index.html > > This page displays the poll question and collects input. > If the user has already taken the poll, it indicates as much > and initializes the input to their previous answer. If they > submit input, it overrides their old input with their new input. > > - report.html shows poll results > > - edit.html allows the poll question to be edited. > > Now, How would I create these pages with CPSSkins? > it would not be concerned with index.html / report.html / edit.html AT ALL. you would just place a "Main Content Portlet" in the middle of the page and let the application underneath take care of rendering the poll screens. cf http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/portlets/macroslot/__init__.py the portlet renders the current view that gets inserted it into the theme at the location of the portlet. cpsskins does not do form rendering, document editing, or such things that are already done with page templates. the rendering of such pages is delegated to the application for instance. > Do I define each of these pages in a theme? > you don't, you only put a single portlet in the middle of the theme page that will render them, as a main macro-slot would do. > Or, perhaps, the theme pages are only used to provide a > a master page with a space for rendering individual page > content. Are theme pages used like page macros in Zope 3 > or like Zope2's standard_template? > > Jim yes, inside the theme you leave a "window area" to display views from the application you're designing a theme for. You can use the zwiki application under cpsskins already, although cpsskins knows nothing about wiki pages. /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] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > >> >> it would not be concerned with index.html / report.html / edit.html >> AT ALL. >> >> you would just place a "Main Content Portlet" in the middle of the page >> and let the application underneath take care of rendering the poll >> screens. >> >> cf >> http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/portlets/macroslot/__init__.py >> >> the portlet renders the current view that gets inserted it into the >> theme at the location of the portlet. > > > Let me try to rephrase this: The portlet renders the current view. > It renders it into the location of the portlet within the theme-defined > page. :) > yes > Where does it get the current view? Is it normally passed in? By whom? from the original theme renderer's template.pt (associated to the cpsskins skin). It gets propagated all the way from the view to the portlet, through the page, cells, etc. as a keyword parameter that the renderer can use at any time. the orginal context is also propagated. cf. in http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/trunk/browser/skin/template.pt >> >> yes, inside the theme you leave a "window area" to display views from >> the application you're designing a theme for. You can use the zwiki >> application under cpsskins already, although cpsskins knows nothing >> about wiki pages. > > > OK, I get it. So this this is all about defining what Tres likes to > call the "O wrap". The stuff that is drawn around the application > generated markuo and that, through CSS styles, images, etc, has > some influence on how the markup is displayed. > yes, CPSSkins was created from the beginning as a simple replacement of main_template before all the theme / page distinctions were introduced. the breakthrough difference in the zope3 version is that the main content area (inside the O wrap) can be rendered directly in python. > So, what if I wanted to use portlets within one of my application > views? Does CPSSkins let me do that too? > > Jim > yes, these would be application-specific portlets, as the ones used in a calendar application for instance showing a monthly agenda. The portlet gets access to the current view object, to the current page location (renamed from 'context_obj' to 'location'). So as soon as you can produce some data from that you have a portlet that can be put inside a theme page. it is not recommended to render portlets directly in HTML though (except for the main content portlet), since cpsskins takes care of formatting and displaying the data using widgets. /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] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> >> yes, these would be application-specific portlets, as the ones used in a >> calendar application for instance showing a monthly agenda. The portlet >> gets access to the current view object, to the current page location >> (renamed from 'context_obj' to 'location'). So as soon as you can >> produce some data from that you have a portlet that can be put inside a >> theme page. > > > I don't understand this. Does the application page use a theme page > to render it's output, which then gets inserted into the o-wrap produced > by another theme page? Or does it use a different o-wrap theme-page > which includes the portlets it wants to be displayed? > > Or, put another way, which of the following strategies are used: > > Option 1. > > We render the master page (o wrap), which calls the view. The view > then > finds another theme page that has portlets it wants. The view renders > this theme page and returns the result to the calling master page, > which then > renders the whole page. > > or > > Option 2: > > When we display the view, we select a different master page than the > usual > one. This special master page has portlets that the view wants to > be displayed. > > or none of the above? :) > > Jim > an application designer would have two choices: 1) provide views just like any zope3 does already, and use cpsskins to decorate the page with portlets around the main view, very much like the current ZMI interface, with breadcrumbs, some navigation, some actions, with the difference that there is no need to write CSS since there is already a style editor that takes care of that. also the portlets can be moved on the canvas without touching any main_template.pt or zpt. 2) write portlets instead of views, that will be placed on a page as any portlet would. One could write an XForm rendering portlet (Julien is working on something like this), or a document portlet that renders some document, etc.. but then we get back to the original subject of the discussion: once you have application specific portlets, you need to introduce the notion of perspective (or contextual usage) otherwise you won't be able to know when to display them. for instance it is OK to display an action portlet on every screen of a portal because there will always be an action to show and action items are highly contextual, but for some portlets or groups of portlets that are too specifically tied to a given activity in the application, this won't do. remember that unlike the objects in no portlets is associated to object types, portlets are associated to cells (global portlets) or to slots (local portlets) So the idea behind perspectives (as in Eclipse SDK) is to create a sort of contextual usage but for local portlets that can be used by the application to update the interface according to the current activity of the user. /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] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Jim Fulton wrote: >> >> >>> Jean-Marc Orliaguet wrote: >>> >>> >>>> yes, these would be application-specific portlets, as the ones used >>>> in a >>>> calendar application for instance showing a monthly agenda. The >>>> portlet >>>> gets access to the current view object, to the current page location >>>> (renamed from 'context_obj' to 'location'). So as soon as you can >>>> produce some data from that you have a portlet that can be put >>>> inside a >>>> theme page. >>> >>> >>> >>> I don't understand this. Does the application page use a theme page >>> to render it's output, which then gets inserted into the o-wrap >>> produced >>> by another theme page? Or does it use a different o-wrap theme-page >>> which includes the portlets it wants to be displayed? >>> >>> Or, put another way, which of the following strategies are used: >>> >>> Option 1. >>> >>> We render the master page (o wrap), which calls the view. The view >>> then >>> finds another theme page that has portlets it wants. The view renders >>> this theme page and returns the result to the calling master page, >>> which then >>> renders the whole page. >>> >>> or >>> >>> Option 2: >>> >>> When we display the view, we select a different master page than the >>> usual >>> one. This special master page has portlets that the view wants to >>> be displayed. >>> >>> or none of the above? :) >>> >>> Jim >>> >> >> >> an application designer would have two choices: > > > I guess these are both in the "none of the above" catagory. :) > > or both, given that they annihilate one another : -) >> 1) provide views just like any zope3 does already, and use cpsskins to >> decorate the page with portlets around the main view, very much like the >> current ZMI interface, with breadcrumbs, some navigation, some actions, >> with the difference that there is no need to write CSS since there is >> already a style editor that takes care of that. >> also the portlets can be moved on the canvas without touching any >> main_template.pt or zpt. > > > But this doesn't let me use portlets in the main view. What if I > wanted my results page in the poll example to use a particular portlet. > Is there a way to do that? yes, but with: - a "poll results" portlet - some information that says when to show the portlet (cf perspectives) you'd need a "poll" perspective to control which portlets to display. the fact that the main area is taken by the macro-slot portlet with the risk that it will render the original template view is not a problem since you can place it inside a slot and turn it into a local portlet. from the "poll" perspective you'd decide not to display the main-macro portlet, since another portlet is taking care of displaying the results. > >> 2) write portlets instead of views, that will be placed on a page as any >> portlet would. One could write an XForm rendering portlet (Julien is >> working on something like this), or a document portlet that renders some >> document, etc.. >> >> but then we get back to the original subject of the discussion: once >> you have application specific portlets, you need to introduce the notion >> of perspective (or contextual usage) otherwise you won't be able to know >> when to display them. >> >> for instance it is OK to display an action portlet on every screen of a >> portal because there will always be an action to show and action items >> are highly contextual, but for some portlets or groups of portlets that >> are too specifically tied to a given activity in the application, this >> won't do. >> >> remember that unlike the objects in no portlets is >> associated to object types, portlets are associated to cells (global >> portlets) or to slots (local portlets) >> >> So the idea behind perspectives (as in Eclipse SDK) is to create a sort >> of contextual usage but for local portlets that can be used by the >> application to update the interface according to the current activity of >> the user. > > > So, my results page, instead of being a normal view is a portlet. > Suppose > that my original goal in my results page was to display the results along > with so
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> >> >> in that case, using a portlet to display the poll results might not be >> the best solution, > > > Right, but then what if, when displaying the poll results, I wanted to > use some > other portlet. Perhaps I have a portlet that lists the top 10 polls > and I want to display that within the content well (inside the > o wrap) when I display my results. > If it's just a matter of visual layout, you only need to add a slot inside your theme just below or above the main-macroslot where you can put the poll portlet (main top, and main bottom slot) as you'd find in any zpt-based template. not everything needs to be placed in the main O > Limiting portlets to master pages (o wrap) seems to me to be a needless > and complicating limitation. > > ... > >> then the actual question is: why should a page in a zope3 application >> only display one view of an object at a time? i.e. the main view? when I >> read my mail I have 4 different views of my mailbox, not just the text >> contained in the mail ... > > > Exactly. So, perhaps I have a mailbox. The main view for the mailbox > uses 3 portlets: > > - a mailbox listing portlet > > - a portlet that lists all my mailboxes > > - a portlet that displays a selected message > > Why can't I specify these three portlets in the definition of my > mailbox view? Why should I have to tease them into the master page? > > I'd like to be able to design my individual application pages > and the master page independently. If I can only display portlets > in master pages, then either: > > 1. I can't use them when designing individual application pages, or > > 2. I have to sneak the contents of my applications into the master pages, >which seems to be a far more complicated model, conceptually, let > alone >computationally. > > Jim > all you need to know when you design your application is the name of the slot in which the portlet will be displayed (right slot, left slot, etc.) This was already the case CMF's main_template.pt where slot names where hardcoded. then in a zcml declaration of the perspective you can specify the slot in which the portlet will be displayed. in some way you'll have to tell *where* the portlets will be located on the page, this is what you do with the "fill-slot" use-macro attribute independently of how the application is written, I don't see how to skip that part and if it's done in zcml then it's better than having it hardcoded in the page templates by all means... /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] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Jim Fulton wrote: >> >> >>> Jean-Marc Orliaguet wrote: >>> >>> >>>> >>>> in that case, using a portlet to display the poll results might not be >>>> the best solution, >>> >>> >>> >>> Right, but then what if, when displaying the poll results, I wanted to >>> use some >>> other portlet. Perhaps I have a portlet that lists the top 10 polls >>> and I want to display that within the content well (inside the >>> o wrap) when I display my results. >>> >> >> If it's just a matter of visual layout, you only need to add a slot >> inside your theme just below or above the main-macroslot where you can >> put the poll portlet (main top, and main bottom slot) as you'd find in >> any zpt-based template. > > > But then, I have to much with the theme just to get my page to > come out the way I want. > > But, maybe it's not a good idea to use the same mechanisms > for the o wrap and the content well. More on this later. > > >> >>> Limiting portlets to master pages (o wrap) seems to me to be a needless >>> and complicating limitation. >> > > Or maybe a good idea ... > >>> ... >>> >>> >>>> then the actual question is: why should a page in a zope3 application >>>> only display one view of an object at a time? i.e. the main view? >>>> when I >>>> read my mail I have 4 different views of my mailbox, not just the text >>>> contained in the mail ... >>> >>> >>> >>> Exactly. So, perhaps I have a mailbox. The main view for the mailbox >>> uses 3 portlets: >>> >>> - a mailbox listing portlet >>> >>> - a portlet that lists all my mailboxes >>> >>> - a portlet that displays a selected message >>> >>> Why can't I specify these three portlets in the definition of my >>> mailbox view? Why should I have to tease them into the master page? >>> >>> I'd like to be able to design my individual application pages >>> and the master page independently. If I can only display portlets >>> in master pages, then either: >>> >>> 1. I can't use them when designing individual application pages, or >>> >>> 2. I have to sneak the contents of my applications into the master >>> pages, >>> which seems to be a far more complicated model, conceptually, let >>> alone >>> computationally. >>> >>> Jim >>> >> >> all you need to know when you design your application is the name of the >> slot in which the portlet will be displayed (right slot, left slot, >> etc.) This was already the case CMF's main_template.pt where slot names >> where hardcoded. >> >> then in a zcml declaration of the perspective you can specify the slot >> in which the portlet will be displayed. >> >> in some way you'll have to tell *where* the portlets will be located on >> the page, this is what you do with the "fill-slot" use-macro attribute > > > But I want to control where the portlet will go in the content well, not > in the o wrap. > > It could be argued that different mechanisms should be used for the > o-wrap, > content well, and end-user portlets (ala JSR 168). This gets back to > Gary's point the other day that there are different actors and use cases > that *could* be unified, but that maybe it's not a good idea to, from > a UI > perspective. > > Site designers define the o-wrap (possibly many). When they design > the o wraps, > they define the position of the content well and other portlets, and > they can > also define slots where content managers can place additional portlets. > (I suppose an o wrap could define 0 or more content wells). > > Page designers (for specific applications) design pages that go in the > content well (or maybe content wells). When designing the contents of > the content well, they too might want a system that lets then combine > page or content components (ala the email interface). > > Content managers have some UI for arranging portlets within slots. > > End users might have portlets that they can arrange within slots as > well (ala JSR 168). (BTW, we find the use of the word portlets > for JSR 168 portlets and for the things that site designers, > page designers and content managers drag around to be pretty > confusing.) > > Anyway, at this point, I think I
[Zope3-dev] [INFO] updated relation store in cpsskins
Hi!
I've updated the relation store's index in cpsskins to support wildcards
on triadic relations.
http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_08_27_triadic-relations
It gives extremely good scalability from 1 to 10+ users (the script
used to measure query times is attached in the mail and in the 0.035 ms
a third of the time stands for function call overhead)
It seems that looking up an index key in a python dictionary is faster
than lookup up an the same key from an OOBTree, I haven't tried with
IOBTrees though.
regards
/JM
import time
from storage.relations import RelationStorage
from cpsskins.relations import TestRelate as Relate
from cpsskins.relations import Predicate, TriadicRelation
storage = RelationStorage()
precision = 10
def perf_1(n):
predicate = Predicate('_ as portlet _ from perspective _ ')
# create 10 portlets in a same slot from 10 different perspectives
slot= Relate('main slot')
for v in range(n):
portlet = Relate('portlet %s' % str(v))
perspective = Relate('perspective %s' % str(v))
storage[str(v+n)] = TriadicRelation(predicate, slot, portlet, perspective)
# get the list of portlets in the slot
t1 = time.clock() # START
for count in range(precision * 1000):
a = storage.search(predicate=predicate, second=portlet)
t2 = time.clock() # STOP
print '%s, %s ms, %s' % (
len(storage), str(round((t2-t1)/precision, 4)), len(storage._relates)
)
if __name__ == '__main__':
perf_1(1)
perf_1(9)
perf_1(90)
perf_1(900)
perf_1(9000)
perf_1(9)
___
Zope3-dev mailing list
Zope3-dev@zope.org
Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Zope3-dev] [INFO] updated relation store in cpsskins
Jean-Marc Orliaguet wrote: >Hi! > >I've updated the relation store's index in cpsskins to support wildcards >on triadic relations. > > > > > for count in range(precision * 1000): > a = storage.search(predicate=predicate, second=portlet) > > > > > actually it should read: storage.search(predicate=predicate, first=slot, third=perspective) but the timing is the same /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] [PROTOTYPE] Portlet perspectives
Hi! I've just uploaded an animation and posted a blog, to show how I envision the concept of "perspective". BLOG: http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_08_28_perspectives-in-cpsskins ANIMATION: http://www.z3lab.org/sections/front-page/design-features/portlet-perspectives (For demo purposes, some of the portlets shown are just mockup images taken from various existing applications.) I'm convinced that this is a real killer :-) 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] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > ... > >> What problem perspectives solves? >> -- > > > I think I'm ready to respond to this now. I hope, with your current > thinking that this is still relevent. > good :-) >> local portlets are currently stored in local folders in a .cps_portlets >> container with the name of the slot in which they are located. > > > So, .cps_portlets is a container with an item for each slot, which, is, > itself a container? Then users add items to this container to add > portlets? that's the Zope2 implementation of local portlets. It has advantages: - the role for managing portlets is the same as the role for managing content in a folder - portlets are visible starting from the folder in which they are stored physically. the drawbacks: - portlets get scattered all over the site, there is no unity. - it is not possible to create a portlet set without first creating the folder in which they'll reside - users must have permission to write in the container to add folders, hence they must have access to the folder - difficult import / export - a traversal is needed from the current folder to the root of the site to determine which portlets will be displayed - portlet ordering is a pain since there is no unique set of portlet. > >> It means that the user has to go into a given folder, add a portlet into >> a slot and the portlet will be visible starting from this folder. After >> a while there are 100 of portlets scattered around the entire site, some >> in /sections/A, some in /sections/A/B some in / ... >> >> there is no grouping of portlets. >> >> we find out that what users actually want to do is to define a set of >> portlets that will be shown in a given section of the site (eg. in >> 'education', in 'research', ...) and only there. > > > Meaning not in subfolders? probably in subfolders too, depending on where the perspective will be used (most certainly starting from a given section of a site, until it is overridden by another perspective) -- this is a separate issue though, since a perspective is not tied to a given folder, object type when it is defined.. > > > This is somehow done > >> when portlets are stored in folders, but it is very difficult to group >> the portlets together, because there is no notion of "group of portlets" >> displayed in given context. > > > I don't know what you mean by "grouping portlets", or why it is a good > thing. > I mean creating sets of portlets: the set of portlets used in a blog, in a calendar, in a section of a site and being able to treat them as a group. This is for the same reason that user folders have groups of users. >> so basically the notion of perspective is just a way of grouping >> portlets together and give a name to that collection, so that a user can >> decide: when I'm in this section of the site, I want to show this set of >> portlets. > > > This doesn't seem consistent with your current notion of perspectives. in what sense? again there are two separate notions: - the notion of perspective - the notion of applying a given perspective to a given context. > >> In an application, this makes it possible to keep the portlets used by >> the application (action portlets, navigation portlets) separate from >> decoration portlets. > > > I'n not sure what you mean. By "application", do you mean the content > management application, as opposed to the end-user content-delivery > application? > I mean a webmail application, a calendar application, a web publishing application. Currently the portlets used in a CMF site for instance are of two kinds: 1) portlets that are used by the web publishing application (workflow actions), login link... 2) portlets that show content (latest news, info text, ...) the site visitors are usually not interested in 1) >> currently we manage the separation by using different themes (one for >> the external site, and one for the "back office"), the slots names are >> different, so the portlets in the backoffice on not visible on the >> external site. > > > And how is this solution undersireable? these portlets are associated to different activities and they are usually meant to be seen by different target audiences. > >> Also we have problem when a same slot is present in many pages, the >> users think that they are add portlets only on a given page, while they >> end up also being visible in other pages. > > > I'm not sure what you mean by page here. Do you mean theme/master pages > or web pages? > >
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > ... > >> By using "perspectives" end-users can also use the portlet editor to >> move portlets on the canvas (as in the google news portal), > > > By end-users, do you mean content managers? Or end-users of the > content? > > Why do they need perspectives to do this? > > Do you envision them being able to control the order of > the portlets? Yes, I think that Rob mentionned that there was such a use case where you had customers who wanted to control the way portlets were disposed on the screen on an individual basis. Generally speaking, portlets are associated to slots but the ordering information is neither stored in the portlet itself nor in the slot, but in a "display element". There are as many display elements associated to a given slot as there are perspectives. In this way visual ordering is not a problem, and it should also be possible to place the portlets inside the slot's display canvas on using (x, y) coordinates. I don't know about a use case for this unless maybe in the content well, I think you mentionned something about this in a previous mail? > > > all that is > >> needed is a portal page with three slots in it > > > Why is the number of slots important? > > ... It's not --- it was an example, it is the number of slots used in google's news portal ... > >> This is what I meant with having a "unifying concept". And that sounds >> very unifying to me already. > > > Perspectives, if I understand how you are describing them, and how > Eclipse describes them, > http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html, > > are simple separate applications. They are different ways of working > on content > based on tasks. They could be provided with perspectives, or, more > simply, > with different collections of web pages, using different styles. I > don't understand the benefit you think they provide nor do I see how > they unify anything. I'm going to put a diagram online showing what they add in terms of separating responsability in the design of a web application, web sites, ... The idea is that the three roles: - theme designer (creates themes, styles, etc...) - programmer (creates portlets, special views for some object types, ...) - application / UI designer (puts all the pieces together) are completely orthogonal. With this you can ask a group of graphic designers to work on some graphic designer for an application, or a site. They'll be able to work on their own without interfering with programmers. They'll create a couple of master pages, they'll place slots inside the pages. This is where their responsibility ends. simultaneously you can ask a group of programmers to create portlets (page fragments) that define the functionality of the site / application. then the application designers, UI designers, website content creators are able to put everything together be creating perspectives. They'll be able to do this before the site with all its content (folder, etc...) even exists. Bottom line: there is a very clear separation of roles. You can't do this today, because the roles are too intertwined. /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] [DRAFT] local portlets and perspectives
Jim Fulton wrote:
> Jean-Marc Orliaguet wrote:
> ...
>
>> This is what I meant with having a "unifying concept". And that sounds
>> very unifying to me already.
>
>
> Perspectives, if I understand how you are describing them, and how
> Eclipse describes them,
> http://www.eclipse.org/articles/using-perspectives/PerspectiveArticle.html,
>
> are simple separate applications. They are different ways of working
> on content
> based on tasks. They could be provided with perspectives, or, more
> simply,
> with different collections of web pages, using different styles. I
> don't understand the benefit you think they provide nor do I see how
> they unify anything.
I've read the article, it is clear to me that the main idea is to be
able to reuse components, not to create a collection of web pages just
to present an application from a slightly different perspective. With 3
master pages and a set of 5 perspectives you get 15 combinations. That
would be 15 pages in html to maintain.
The main idea is to define visibility in a coherent way, not with a
series of CSS hacks (hidden {display:none}), ..., , scattered around 100 page
templates... or by using visibility conditions in the portlets own code.
the assumption is that portlet visibility is not a propriety of
*individual* portlets, but this is something that is related to some
activity of the user, or some usage context.
I think that Eric summarized this quite clearly in his blog:
"""
What for ?
Imagine that when writing a new component, you also can easily define
perspective. Let's take an example : a blog application. Well you can
define a "Blog Perspective" that would be activated when accessing to a
blog and that would arrange the portal to offer a "blog view" putting
portlets in right places. WIth this and the whole CPSSkins machinery, it
would be very easy to define interfaces that can adapt to user's activity.
The same approach would also work for webmail, calendar, collaborative
work, personal portal dashboard, etc. The application would then only
define portlets and perspectives (no more pages, view, whatever :-).
>From the user point of view, it would really improve the usability and
how it the portal can adapt itself to his need. The user would also be
albe to define its own perspectives (like it's dashboard) and switch
between them.
It would be new approach in the design of web applications, that would
allow to think them as user-oriented applications and not as a chains of
html pages.
"""
The idea is to move away from the website approach to designing web
applications, with the endless poliferation of templates and macros. I
fully agree though that this is a change from the page / view approach.
/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] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> >> >> Yes, I think that Rob mentionned that there was such a use case where >> you had customers who wanted to control the way portlets were disposed >> on the screen on an individual basis. > > > This gets to a terminology problem. JSR 168 defines portlets to > mean something quite different. In particular, JSR 168 specifies > portlets that are used by end users, by which I mean the final users, > as opposed to content managers, of a site to control what they > personally see on a site. This is what Rob was refering to. > (BTW, we would prefer that the term "portlet" be used to talk > about portlets as defined by JSR 168.) > > Your local portlets are used by content managers to define > content to appear in the o-wrap, based on site location. no, they are used by end-users as well -- this is already the case in the Zope2 version of cpsskins -- inside the perspective that they have permission to work in. this is where I don't understand how you can with a view / adapter / page template paradigm get the JSR 168 portlets to fit in. Views, adapters are for programmers, not for end-users, not even for content creators. > >> Generally speaking, portlets are associated to slots but the ordering >> information is neither stored in the portlet itself nor in the slot, but >> in a "display element". There are as many display elements associated to >> a given slot as there are perspectives. > > > You still seem to have the desire have portlet assignment apply to a > a folder and to subfolders, with subfolders being able to add > portlet definitions. As you pointed out in another note, this makes > order control challenging. > > You introduce new term "display element", but you don't say enough > about what it does. I'm happy to let that pass. ;) this is the required element that makes portlets ordering not challenging anymore. But this is another issue.. > >> In this way visual ordering is not a problem, and it should also be >> possible to place the portlets inside the slot's display canvas on using >> (x, y) coordinates. I don't know about a use case for this unless maybe >> in the content well, I think you mentionned something about this in a >> previous mail? > > > I also mentioned that there are several distinct activities that I > think should remain distinct. In particular, and I think you agreed, > the system we are discussing here should not try to address the content > well. it depends on what the content well looks likes, if the content well consists of 6 portlets, side by side or one below the other, then this is not a problem to let the cpsskins layout mechanism take care of that. I'm still not sure about what you put inside the content well, this is why. if the content well contains a document with some advanced layout and a lot of widgets then this is outside the scope of the cpsskins layout renderer. > >> Bottom line: there is a very clear separation of roles. You can't do >> this today, because the roles are too intertwined. > > > I just don't see perspectives adding anything here. The application > designer can just as easily use different master pages for different > activities/tasks and assigne different portlets to different slots > in the different master pages. > this is what we do already.. but this is clumsy. Because it forces us to design a new page just for some portlets that should be hidden. Maintaining a page, with the styles, layouts, etc takes more time than maintaining a perspective that only consists of a list of portlets assigned to some slots. > I see some negatives with perspectives: > > - They introduce a need for some complex infrastructure. > what do you mean by "complex"? have you seen the prototype? for a user it does not seem too complex: - choose a perspective - add portlets to it - assign the perspective to some context > - It's not clear what impact they have on URLs. If, for > example, perspectives are set via cookies or session > data, then both bookmarking and caching become more complicated. > what about skins? > - By introducing modes, I worry that they will make it > harder to talk about and teach systems build with them. > > Jim > what should we say about skins then? they introduce exactly the same "problems". However they exist in Zope3. a perspective is a skin but for the portlets in a page. If you think that perspectives are too complex then the skins mechanism should be reconsidered... /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] [DRAFT] local portlets and perspectives
Jim Fulton wrote:
> Jean-Marc Orliaguet wrote:
>
>> Jim Fulton wrote:
>>
>>
>> I've read the article, it is clear to me that the main idea is to be
>> able to reuse components, not to create a collection of web pages just
>> to present an application from a slightly different perspective.
>
>
> OK, then we have very different perspectives on perspectives.
> I see eclipse perspectives as primarily a way to tailor the UI
> to the task at hand, which, BTW, I don't see as simply
> persenting an application from slightly different perspectives.
>
for me the Eclipse definition is a subset of what I mean. I took it as
an inspiration, the application of perspective needs not be restricted
to UI tasks. Again a perspective can be seen as a skin for portlets. It
is as if you'd claim that skins can only be used in some situations and
not in others..
>
> > With 3
>
>> master pages and a set of 5 perspectives you get 15 combinations. That
>> would be 15 pages in html to maintain.
>
>
> Perhaps, although it's not clear to me that separate perspectives
> would want to share the same master pages. To be honest, it's
> not clear to me that different applications would/should want to mess
> with the o-wrap in the first place.
>
Use case: you are looking at a site from some "external website"
perspective (cf. zope.org) you want to change the content of some
document. So you need to interact with an action box that is invisible
to anonymous users, and interact with a navigation portlet to find
documents. Are you going to create a new zope.org page for that? Or just
switch to the "web publisher" perspective?
>> The main idea is to define visibility in a coherent way,
>
>
> We're both in favor of that.
>
>
good, I think that it is about time we find areas of agreements ..
>> not with a
>> series of CSS hacks (hidden {display:none}), > tal:condition="not:first_login" >..., , scattered around 100 page
>> templates... or by using visibility conditions in the portlets own code.
>
>
> I wasn't suggesting that. I was suggesting a model where separate
> applications didn't share the same layout for parts that were
> application specific.
they don't have too, you can switch the page (theme page) just like you
switch perspectives ..
pages and perspectives are orthogonal, they have to be combined but the
combination is not determined in advance.
the combination of 2 orthogonal concepts is worth a lot in terms of
productivity. It is like the separation of form and content.
>
>> the assumption is that portlet visibility is not a propriety of
>> *individual* portlets, but this is something that is related to some
>> activity of the user, or some usage context.
>
>
> This implicit assignment of portlets to slots worries my, both from
> the point of implementation complexity and understandability.
For the user this could not be simpler in terms of UI. This is how
newspaper CMSs work already, cf Polopoly (www.polopoly.se) used in many
Swedish sites (cf. www.dn.se, www.svt.se) There are templates with slots
(equivalent of pages in cpsskins) and there are sets of portlets
assigned to slots. The perspective in Polopoly for each slot is even
written using URLs, you can change it directly in the URL. In the end,
and this is where I'm trying to get at: a site is a combination of pages
and perspectives (the two notions being 100% orthogonal)
when it comes to the implementation, I don't see how saving portlets in
folders is better. I still don't understand how you can have 1 users
add portlets inside a same slot and manage portlet order easily.
>
>> I think that Eric summarized this quite clearly in his blog:
>>
>> """
>> What for ?
>>
>> Imagine that when writing a new component, you also can easily define
>> perspective. Let's take an example : a blog application. Well you can
>> define a "Blog Perspective" that would be activated when accessing to a
>> blog and that would arrange the portal to offer a "blog view" putting
>> portlets in right places. WIth this and the whole CPSSkins machinery, it
>> would be very easy to define interfaces that can adapt to user's
>> activity.
>> The same approach would also work for webmail, calendar, collaborative
>> work, personal portal dashboard, etc. The application would then only
>> define portlets and perspectives (no more pages, view, whatever :-).
>>
>>> From the user point of view, it would really improve the usability and
>>
>> how it the portal can adapt itself to his need. The user would also be
>> albe to define its own perspec
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Hi! >> >> Somehow related to the discussion on optimizing catalog queries, I have >> been thinking about how to best implement local portlets in cpsskins in >> terms of scalability, performance and functionality. The implementation >> is heavily dependent on being able to performance effective catalog >> queries (it is OK to wait 2 seconds in an ECMS to search 1 million >> documents, but it is not OK to have to wait 2 seconds to render a page >> containing portlets). >> >> Here is the proposal: >> http://www.z3lab.org/sections/blogs/jean-marc-orliaguet/2005_08_24_local-portlets >> >> >> It is built on the notion of "Perspective" (see the link) and on the >> idea of querying the catalog using triadic relations instead of joining >> sets of query results based on dyadic predicates (such as with RDF). > > > Well, after our various discussions, I think I understand what this > is about. > > I have the following suggestions: > > - I think the perspective idea has a lot of merit, however, I'd > like it to be optional. In particular, I'd like to be able to use > CPS Skins without having to use perspectives. > that's possible, when you can more you can less (or differently) > - You said that cells can be filled with portlets or with slots. > Why not make a slot another kind of portlet? Then people could > introduce new slot types and innovations without affecting the > rest of CPS Skins. > yes, this is a possible extension, it is also possible to create a new types of objects that fits your needs that are neither slots nor portlets but that are contained inside cells. why not create a portlet that does what you want? the main formal difference between slots and portlets is that slots are inner nodes (physically or virtually contain other objects) and that portlets are node leaves (must render some data). here is the actual base classes: http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/elements/__init__.py this is important for the theme editor. if the new type of object that you are thinking of work like an inner node, then it's a slot otherwise it's a portlet. basically if the "slot" that you're thinking about contains portlets then it's a sort of slot not a sort of portlet. > - Use of the term "portlet" here leads to confusion with JSR 168 > portlets, which are different. I would prefer to see a different > term used for what CPS calls portlets. Absent that, we'll need to > find some modifiers to disambiguate. > > Jim > yes, any term, "boxes" are not OK, since they refer to the portlet's display (view) with the frame and the decorations but any term that is understood by users / developers is ok. /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] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Jim Fulton wrote: > > > ... > >>> - They introduce a need for some complex infrastructure. >>> >> >> what do you mean by "complex"? have you seen the prototype? for a user >> it does not seem too complex: >> >> - choose a perspective >> - add portlets to it >> - assign the perspective to some context > > > I meant to reply to this in my last note. > > I wasn't talking about the user experience, I was talking about the > underlying implementation. You require a centralize database of triads > with a scalable query engine. This seems rather complex to me. > > Jim > Yes, if you store portlets in local folders (this is what you were thinking about?) you won't have the same scalability problems unless you have to traverse 20 folders from the site root to the current folder. This is a trade-off. This is how it was implemented in CPSSkins (Zope2) inspired from the earlier implementation (CPSBoxes). The simplicity of the implementation in terms of storage has meant some very difficult issues to solves in terms of user interface. So now I'm willing to invest some time in finding a generic way of storing triadic relations in a storage. For me it is more important to allow users to place portlets anywhere in the site (on the front page, etc...), even if the site exists already or not, but I agree that it should be possible to use the local folder storage approach in the Zope3 version too. Technically speaking there is nothing that prevents the creation of varieties of slots that save portlets in local folders. /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] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> >> >> basically if the "slot" that you're thinking about contains portlets >> then it's a sort of slot not a sort of portlet. > > > Cool. So we can define new slot-like things (for example, > for JSR 168-style slots) and use your slots or not, as we wish. > > In particular, we can use CPS skins without being forced to > install triad registries unless we want to use your slots. > In that case it is possible to plug in other relation store backends (e.g RDF) that do not support genuine triadic predicates, which means that only "local folder" types of slots will be available, but some relation storage is required for the dyadic relations between elements and styles, widgets... because the relations between the elements are not stored on the elements themselves. > >>> - Use of the term "portlet" here leads to confusion with JSR 168 >>> portlets, which are different. I would prefer to see a different >>> term used for what CPS calls portlets. Absent that, we'll need to >>> find some modifiers to disambiguate. >>> >>> Jim >>> >> >> >> yes, any term, "boxes" are not OK, since they refer to the portlet's >> display (view) with the frame and the decorations but any term that is >> understood by users / developers is ok. > > > Cool. "Pagelets"? > > Jim > yes, I re-read http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and while going through the different definitions I saw that not two implementations are done in the same way, which is fine. The important aspect is that "portlets" or "pagelets" as they are implemented in cpsskins separate model and view. They implement the "data model" part only, not the view itself, which is done later by widget, layout and style filters inside the rendering engine. Of course it is possible for a "pagelet" to render HTML directly and consider the HTML produced as data (that's a question of semantic), but then other rendering engines (text-based, SVG, RSS, ATOM, etc.) won't be able to do anything with the HTML data that they get. Anyway, pagelets or portlets whatever they called and no matter what data they produce (structured data or raw HTML) must be "pipe-able" through the rendering engine, i.e. they must return some data, the more "ready HTML" the data is the less reusable it will be. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
Re: [Z3lab] Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Tonico Strasser wrote:
> Hi!
>
> Jean-Marc Orliaguet schrieb:
>
>> Anyway, pagelets or portlets whatever they called and no matter what
>> data they produce (structured data or raw HTML) must be "pipe-able"
>> through the rendering engine, i.e. they must return some data, the more
>> "ready HTML" the data is the less reusable it will be.
>
>
> Pipe-able, hmm. I think, *if* we could do define-slot and fill-slot
> stuff in Python code that would be very nice. We would have a "page"
> object that can "pipe" page components together.
>
yes, this is what cpsskins does:
- the "define-slot" is just a "cpsskins:slot" with a name identifier
('left', 'right', 'main' ...) which means that can be used on several pages.
- the "fill-slot" part has been the subject of the discussion the past
week in the "perspective" thread.
Currently the plan is to support the "perspective" way of filling slots
(1 perspective = 1 set of portlets) and the "local folder" way of
filling a slot, i.e. traversing the site starting from the site root to
the current folder, gathering all the portlets stored in each folder on
the path and displaying them into the slot that they belong to.
here is how the renderer works:
http://www.z3lab.org/sections/front-page/white-papers/draft-renderer/downloadFile/attachedFile/renderer-architecture.png
starting from the top node in the theme tree:
A) is the node a leaf?
=> YES: then render the node according to B)
=> NO: get the list of child nodes in the correct order, for every
node go to A)
B) for every filter associated to the node:
- is the filter is the first in the chain?
=> YES: then get the data from the leaf (getDisplayData())
=> NO: use the output of the previous filter in the chain and feed
it into the current filter
- if the filter is the last in the filter chain for that node, feed
the filtered data into the next renderer.
In this way, believe it or not, you can by changing a few lines in a
zcml file render a "theme editor" with all the AJAX stuff
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/configuration/engines/editor/configure.zcml
or an HTML page ready to be displayed on a web page:
http://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/configuration/engines/default/configure.zcml
90% of all the components are reused, simply they are wired together
differently.
> A simple example with boxes (sorry, Zope 2 script, don't kill me):
>
> ##
> page = context.Page(template=container.ZPT_A)
>
> # aggregate macro-defs from other page template
> page.macros.update(container.ZPT_B.macros)
>
> # create list of Box instances (not rendered HTML)
> b1 = container.box_a('demo', 'Demo', condition=some_condition)
> # box 2 takes b1 as input
> b2 = container.box_b('foo', 'Foo', some_arg=b1)
>
> left_boxes = [b1, b2]
>
> # make boxes available in PTs as 'lboxes'
> page.lboxes = left_boxes
>
> # now we have aggregated all informations
> # ready to render
>
> # calls pt_render of ZPT_A with extra context
> return page.render()
>
> ##
>
> ZPT_A:
>
>
>
>
>
> ZPT_B:
>
>
>
>
>
>
> box_repeat macro:
>
> metal:define-macro="box_repeat"
> tal:repeat="box lboxes"
> tal:attributes="id box/id">
> tal:content="box/title"/>
> metal:use-macro="box/macros/body|default"/>
>
>
> Just for your inspiration.
>
> Tonico
>
>
yes, this is the ZPT way of doing it :-)
/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: [Z3lab] Re: [DRAFT] local portlets and perspectives
Tonico Strasser wrote: > Jean-Marc Orliaguet schrieb: > >> yes, this is the ZPT way of doing it :-) > > > Yes, I find ZPT is very suited for this stuff becuase it has that slot > thing. That wouldn't be possible with e.g. DMTL I think. Do CPSSkins > support other template languages than ZPT? > > Tonico python is supported, xml/xslt is supported, DTML, C, ... as long as some method can be called and provide some data that makes sense for a filter. This is not the case by the way with ZPT fill-slot macros, you can't just render a "fill-slot" without having the corresponding "define-slot" /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] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Jim Fulton wrote: >> >> >>> Jean-Marc Orliaguet wrote: >>> >>> >>>> >>>> basically if the "slot" that you're thinking about contains portlets >>>> then it's a sort of slot not a sort of portlet. >>> >>> >>> >>> Cool. So we can define new slot-like things (for example, >>> for JSR 168-style slots) and use your slots or not, as we wish. >>> >>> In particular, we can use CPS skins without being forced to >>> install triad registries unless we want to use your slots. >>> >> >> >> In that case it is possible to plug in other relation store backends >> (e.g RDF) that do not support genuine triadic predicates, which means >> that only "local folder" types of slots will be available, but some >> relation storage is required for the dyadic relations between elements >> and styles, widgets... because the relations between the elements are >> not stored on the elements themselves. > > > Sigh. Is this documented anywhere? Currently the application adds relations into the relation store using a relation tool, there is not definite documented interface though, since not all the use cases are defined yet: https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/relations/tool.py The idea is to allow any relation store back-end (RDF, SQL, ..) to be plugged in. If the relation information was stored in the elements themselves (e.g. annotations, attributes, ...) this would make it very difficult to move the storage from the ZODB. this is more a design feature than an implementation feature. >> >> yes, I re-read >> http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and >> while going through the different definitions I saw that not two >> implementations are done in the same way, which is fine. >> >> The important aspect is that "portlets" or "pagelets" as they are >> implemented in cpsskins separate model and view. >> They implement the "data model" part only, not the view itself, which >> is done later by widget, layout and style filters inside the rendering >> engine. > > > I'd like to understand how this works. > > Jim A portlet / pagelet generates some data (a list of menu items, for instance) as a data structure in python. - the data goes through a widget filter that convert the data into HTML. Depending on what widget is being used, the same data is displayed differently (vertical list, horizontal list, drop-down list...). - a style filters add the style information (class="..."), the portlet can then be displayed in HTML if other combinations of filters are used (a RSS filter for instance), the same data is displayed in RSS instead of HTML. which is shown on the following diagram: https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.png and documented here: https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt /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] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> >> this is more a design feature than an implementation feature. > > > Could you explain *why* you need relations? > > yes, because adapters provide flexible relations between *components* (interfaces, classes), but not between *content* objects. I want to be able to say (or the user) - this portlet uses this widget - this portlet uses this style not for a *class* of portlets, but for *instances* of classes. Adapters connect interfaces, not instances. to sum up: for exactly the same reason as why Zope2 moved to a component-based architecture, but for the content this time. I want to be able to connect content objects (portlets, styles, widgets, layouts) in a flexible way. and by the way it works, so why explain why you need something when it works as expected? >> >>>> yes, I re-read >>>> http://mail.zope.org/pipermail/zope3-dev/2004-December/012852.html and >>>> while going through the different definitions I saw that not two >>>> implementations are done in the same way, which is fine. >>>> >>>> The important aspect is that "portlets" or "pagelets" as they are >>>> implemented in cpsskins separate model and view. >>>> They implement the "data model" part only, not the view itself, which >>>> is done later by widget, layout and style filters inside the rendering >>>> engine. >>> >>> >>> >>> I'd like to understand how this works. >>> >>> Jim >> >> >> >> >> A portlet / pagelet generates some data (a list of menu items, for >> instance) as a data structure in python. >> >> - the data goes through a widget filter that convert the data into HTML. >> Depending on what widget is being used, the same data is displayed >> differently (vertical list, horizontal list, drop-down list...). >> >> - a style filters add the style information (class="..."), >> >> the portlet can then be displayed in HTML >> >> if other combinations of filters are used (a RSS filter for instance), >> the same data is displayed in RSS instead of HTML. > > > Why would you want to generate RSS in a portlet? the portlet data is used for syndication in RSS / ATOM too in a RSS rendering engine (the [RSS] orange button). if the portlet already renders HTML, there is no way to convert HTML to RSS. > >> which is shown on the following diagram: >> https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.png >> >> >> and documented here: >> https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt >> > > > So > > - You get a widget of a particular type. > > - You adapt the widget (with a request) to get a widget filter. > > - You call the portlet to get some data. > > - You call the widget filter with the data to get HTML markup. > this is just one example of a rendering engine (the HTML rendering engine) > I guess the widget filter somehow decides how to generate HTML based > on the widget and data. Similarly, it somehow chooses a style. > It's unclear how this is working. > the widget knows nothing about the style that is going to be applied afterwards. The portlet <-> style connection is a relation defined in the relation store. > Can you say why you chose this division of labor? > it is one example of a chain of filters that covers most of the use cases to create HTML pages. Since the engine definition is defined in a zcml file it can be changed easily. I could go into the details of the design, but since it works as expected ... > I agree that, given a model where portlets only generate data, "pagelett" > is not a good name. Perhaps "applet" would be a better name. > > IMO, the choice of the term "widget" is unfortunate, both because it > clashes > with the Zope 3 use of the term and because it clashes with common > usage in > GUIS, where widgets are responsible for UI generation, whereas here, > AFAICT, > widgets are responsible for UI specification in some fashion. > > Here's an alternate suggestion that follows Zope 3 style a bit more: > > - We have applets that provide application functionality. These are > like your portlets. > > - We define layout types. These extend something like ISubPage (as > defined in > formlib). Alternatively, we use named adapters. > what is a layout type? > - We adapt the applets with the request to the layout type: > > view = component.queryMultiAdapter((applet, request
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > >> Jim Fulton wrote: >> >> >> - this portlet uses this widget > > > I'm confused. In the doctest you pointed out: > > https://svn.nuxeo.org/trac/pub/file/z3lab/cpsskins/branches/jmo-perspectives/doc/portlet-rendering.txt > > > the portlet and widget are wired up by hand, not by lookup AFAICT. > sorry this is a doctest that does not take into account relations. It only describes the way in which elements are rendered, i.e. moving from content -> view, from data to HTML. >> - this portlet uses this style >> >> not for a *class* of portlets, but for *instances* of classes. Adapters >> connect interfaces, not instances. > > > Then why not just store the style in the portlet? > Again you are making the assumption that a portlet *has* a style. If the portlet is rendered in RSS it has no style ... Also this is as bad as storing browser view related attributes in a content class - otherwise we are back to the Zope2 old days, where every possible attribute was stored on the objects themselves. Then OK: if you store the style attribute on the portlet itself, I suppose that this information will be indexed and cataloged. In what way is it different from having a separate relation store that does not duplicate information? Honestly, Zope3 makes some sort of schizofrenic separation between content and view, in a way that you sometimes cannot get access to the request object because you haven't adapted (context, request). the Zope3 philosophy has to be coherent: if you create a waterproof separation between components, then having a waterproof separation between content elements, i.e. portlets / widgets / styles / layout / visibility options / caching parameters is just as important. > >> to sum up: for exactly the same reason as why Zope2 moved to a >> component-based architecture, but for the content this time. I want to >> be able to connect content objects (portlets, styles, widgets, layouts) >> in a flexible way. >> >> and by the way it works, so why explain why you need something when it >> works as expected? > > > Because to decide if I want to use it, I need to evaluate the > architecture: > > - I need to know if there are hidden costs that aren't apparent in > demos and small scale. > > Your solution requires a potentially large centralized indexing > structure. > I don't like large centralized indexing structures. They are necessary > sometimes, but I don't want to use them if I can avoid it. > I don't know about yours, but I guess that you will store all the information in the portal catalog? what is the difference? > - Your system defines a framework that I'll need to understand if > we want to use it. I need to understand if developers will find it > easy to use > the number one target audience is end-users, and application developers. The Zope2 version is already appealing to both users and developers. At the university we can't afford to create a product that only developers understand. Content creators, graphic designers don't think as developers, they see things differently and this is what I'm trying to integrate into cpsskins, i.e. *their* knowledge. > >>>> if other combinations of filters are used (a RSS filter for instance), >>>> the same data is displayed in RSS instead of HTML. >>> >>> >>> >>> Why would you want to generate RSS in a portlet? >> >> >> the portlet data is used for syndication in RSS / ATOM too in a RSS >> rendering engine (the [RSS] orange button). > > > Is this a case where you are using a portlet as an application > component outside the context of a page? > yes, of course, content is often syndicated. Creating a syndication adapter that gathers data, extract data and renders it in RSS when you only need to create a filter and add /++engine++rss/ in the url is worth a lot. >>> >>> - We define layout types. These extend something like ISubPage (as >>> defined in >>> formlib). Alternatively, we use named adapters. >>> >> >> what is a layout type? > > > The thing you specify with the widget keyword argument to the Widget > contructor in the doctest you sent. > OK, this is not really important, this is only used by the vocabulary items to not propose a "box layout" to a user when it makes no sense to apply a "box layout" to an element. This is just a way of categorizing widgets / layouts. >>> - We adapt the applets with the request to the layout type: >>> >>> view = component.queryMultiAdapter((applet, request), >>> IDropDownList) >&g
[Zope3-dev] Re: [Z3lab] Why use relations?
Janko Hauser wrote: > > Am 31.08.2005 um 10:25 schrieb Jean-Marc Orliaguet: > >> Hi ! >> >> I have been thinking about Jim's question: "why do you need >> relations?". >> Some obvious answers came first others emerged later on, now I think >> that most of them are emerged, so I'll try to summarize them by >> order of >> importance (to me): > > > I'm in support of most of your points, although I do not see that the > catalog is actually proposed as an alternative. Jim's suggestions > were more directed to store things in each other. Or reference them > somehow, but not by an indirection with a central index. > HI! My intuition is that if you store "things in each other" you have implicitly created an index as soon as the objects get cataloged. Usually you start storing information about other objects in the objects themselves thinking: "my application will only need to work that way, the information belongs here ..." Later on, some use case forces you to think differently and use a different approach, e.g. containment, traversals, acquisition (if the information is not there, then look for it there instead ...) Then you see: this is too slow, I need to create an index in the catalog.. But this is another discussion that has more to do with the actual implementation of the application than some explicit design. >> I think that it is important for the Z3ECM project to state why to use >> relations? Jim's question was very pertinent. > > > Actually in the frame of the Z3ECM project I really do not see, how > we can not use an "explicit" relation system. On the other hand, much > of this discussion was crossposted also to z3-dev, which means, that > not everything in the z3-core should start to be dependent on a > relation system. And an important of part also of z3-core is the > creation of UI for the applications. > > Zope is all about object relations all the time, the most obvious is > the parent, child relation. Another is the interface relation > expressed in ZCML. The dependance on containment made many Z2 > products difficult to reuse, because one needed to pull things out > from some other application container. I see relations as an > important way out of this. They support the notion of small, dumb > objects, which are assembled by adapters to bigger parts. > > If they are needed for a proposed UI system I can not judge, as I > haven't installed and looked at it. > > __Janko > > Yes, I know that there is no such thing in Zope3 currently, and that containment works best on tree-like structures and that it is not the answer to everything :-) But shouldn't there be an interface definition for plugging in / querying different relation stores in the same way? It is weird to think: Z3ECM needs it, but Zope3 does not need it (at least define a base interface would help make different implementation compatible ...) the question is much wider than the UI system issue. /JM I quote the original message, maybe I should have sent it to zope3-dev also: === QUOTE == Hi ! I have been thinking about Jim's question: "why do you need relations?". Some obvious answers came first others emerged later on, now I think that most of them are emerged, so I'll try to summarize them by order of importance (to me): 1/ Being able to create new functionality in the application without changing the schema of the content objects. In cpsskins the content classes (pages, cells, slots, portlets, styles, widgets, layouts, perspectives, ...) are minimal: they have a title (if needed), a unique ID automatically generated by IntIds, a type, if they need to be classified in subtypes, and that's all. For instance to create the new functionality "perspective" I added a new content class (Perspective) and a new kind of relation (hasPortletFromPerspective), but I did not modify the schemas of existing content classes. So new functionality in the application means: - new relation predicates or - the same relations and elements, but connected differently. a lot of time spent on refactoring of an application comes from having to modify the schema of classes to add new functionality to the application and update all the code in python / zpt, create migration scripts... this follows the DRY (don't repeat yourself) concept, on content objects, i.e. don't write more code if you can re-use already existing objects but connect them differently. Zope3 implements this idea on a component level by using adapters. 2/ Explicit relations vs implicit relations. The relations between the elements are *explicit*, as opposed to the relations implicitly stored in an object catalog (e.g. z3 catalog) th
Re: [Zope3-dev] [DRAFT] local portlets and perspectives
Jim Fulton wrote: > Jean-Marc Orliaguet wrote: > ... > >> Also this is as bad as storing browser view related attributes in a >> content class - otherwise we are back to the Zope2 old days, where every >> possible attribute was stored on the objects themselves. > > > There are advantages in storing data on the object, if you can do it > in a controlled way. I understand and agree that you don't want the > implementation of portlets to know about (depend on) styles. Zope 3 > provides a mechanism, annotations, for storing data on an object > without affecting the object's implementation. > here is the use case: - the style of portlets located in slots is associated to the slot (not to the portlets). Why? because content creators focus on content not on CSS styles, when they add a portlet into a slot someone else has already designed the style for the portlet. - the same goes with widgets (the actual presentation of portlets) here is an animation that demonstrates the idea: http://www.z3lab.org/sections/front-page/design-features/slot-formats - the default behaviour for portlets is to inherit formats (styles, widgets, etc) from the slots. - it means that slots (not portlets) should in principle store the format information. - but if you do this (store the style information on slots), there is no way to override slot styles in some given context or perspective only. Maybe you want your end-users to be able to customize the color of the boxes? If you store the information in the slot, there is no way to display portlet boxes in a slightly different way (e.g. add min/max buttons on boxes) - so basically if you store some style information on some given content class (portlet, slot, ...) you will already have shot yourself in the foot, after the third use case only:-) This is why cpsskins uses the notion of "display", which is an object that stores all format information (style, widget presentation, visibility, ...) Different displays can be associated to a same slot or a same portlet. >> Then OK: if you store the style attribute on the portlet itself, I >> suppose that this information will be indexed and cataloged. In what way >> is it different from having a separate relation store that does not >> duplicate information? > > > Why would it be indexed? Why would I advocate one centralized storage > scheme over another? I don't like centralized data structures. They are > necessary sometimes. do you mean that all information is stored on objects and that you don't index the information in any catalog to get access to it fast? how many pages per second can you render? > >> Honestly, Zope3 makes some sort of schizofrenic separation between >> content and view, in a way that you sometimes cannot get access to the >> request object because you haven't adapted (context, request). > > > I don't really understand what you are objecting to. Requests are > necessary for user interaction. Why should anything but presentation > code have access to the request? We obtain presentation code > by adapting the request. Why would you want the request elsewhere? > How is this schizophrenic? This could be the subject of another thread, but basically I end up in some cases having to pass the request object to methods (as in Zope2) because the code is neither 100% presentation nor pure content. Maybe I'm doing things in the wrong way ... I need to implement a Read / Write containers (slots) that since that are Containers know nothing about requests, but also need to get some information stored in the request to decide how to store the information. .. >> the Zope3 philosophy has to be coherent: if you create a waterproof >> separation between components, then having a waterproof separation >> between content elements, i.e. portlets / widgets / styles / layout / >> visibility options / caching parameters is just as important. > > > Agreed. I'm slowly getting an inkling of what your architecture is and is > trying to achiev. As I learn more, I'm liking many aspects. > >>>> to sum up: for exactly the same reason as why Zope2 moved to a >>>> component-based architecture, but for the content this time. I want to >>>> be able to connect content objects (portlets, styles, widgets, >>>> layouts) >>>> in a flexible way. >>>> >>>> and by the way it works, so why explain why you need something when it >>>> works as expected? >>> >>> >>> >>> Because to decide if I want to use it, I need to evaluate the >>> architecture: >>> >>> - I need to know if there are hidden costs that aren't apparent in >>> demos and small scale. >&
[Zope3-dev] Re: [Z3lab] Support for relations in Zope
Dario Lopez-Kästen wrote: > Jim Fulton wrote: > >> Jean-Marc Orliaguet wrote: >> >>> Janko Hauser wrote: >>> >>>> I'm in support of most of your points, although I do not see that >>>> the catalog is actually proposed as an alternative. Jim's >>>> suggestions were more directed to store things in each other. Or >>>> reference them somehow, but not by an indirection with a central >>>> index. >>> >> >> >> Thanks Janko. :) >> >> >>> My intuition is that if you store "things in each other" you have >>> implicitly created an index as soon as the objects get cataloged. >> >> >> >> I don't see how. You only have indexes for the information that gets >> cataloged. Janko summarized my position very well. >> >> I'll note that I'm not opposed to "relations". I'm not even opposed >> to a centralized store for relations. I am inclined to limit their use >> to where they are needed and in leveraging the component architecture >> to make it easy to change one's mind. >> > > Caveat: I have not really followed the thread to it's full extent, nor > have I done any significant work on/with Zope3 yet; consequently > (sp?), I am not sure if the "things" mentioned above are general > things, i.e. arbitrary objects, or only "things" specific to portlets, > and the models related to this particular problem. Also I am no ZODB > expert. > > With that in mind, I offer my sincere apologies if I am beating a dead > horse or missing the point entirely. The discussion above triggered my > curiosity about relation-support in Zope, being the reason I write > this :-) > > So here is my take on relations and Zope: > > In general, I would like to see Zope have some way to, or provide > basic support for applications to, create relations between objects - > the term "relation" is in this context defined losely as the most > basic idea of relation. No need for ACID, foreing constraints, etc. > Just plain old simple "X is related to Y, and it is expressed as Z" > without any particular meaning of what the relation X-Y means - that > interpretation would be up to the particular application being built, > and Z would be the actiual "implementation", oway of actually creating > the X-Y relation. > > I have several use cases where the basic Zope relationship between > objects, containment, is too limited and just cannot be applied. > > The ZODB, AFAIK, supports only relations by interpreting containment > as a kind of relation, and the way to access an object is to traverse > to it from the root. While it is possible to create relations between > objects allready in Zope, these objects either cannot be > moved/deleted, nor can they be renamed if we want to maintain the > relation. > > I believe that if Zope is to provide support for relations (which I > would like to see :) it needs to have more plumbing to help sort out > some practical problems that exist. > > To avoid the "oops, object moved - relation broke" problem, a simple, > yet I belive totally sufficient, solution is to implement a > centralised index of _all_ objects. Each and every object in the ZODB, > without exception, is indexed and may be referenced by looking it up > in the index. This implies at least the following changes: > > - this "master" index is maintained automagically. It is always there > and is being constantly updated, whether you want/use it or not. > > - objects will have to be tagged with a unique internal id, UUID, > read-only, somewhat similar to the concept of ROW-IDs in relational > databases. This is not the id of an object as we know it now, where we > can rename an object, thus changing it's ID. This is a > system-maintained, read-only id, guaranteed to be unique in the ZODB > (read "unique across mounted ZODB storages" as well). This UUID is > what the master index uses to reference objects. > > - all object manipulation commands need to be enhanced so as to > support the "master" index. If I create/rename/move/delete/and-so-on > an object, then the "master" index is updated accordingly, > transparently. Note that the master index not necessarily needs to > support undoing (in fact it may just be plain wrong for it to support > undoing). It just has to reflect the current state of the ZODB and no > more. > > Using this we can then create relations (implementation agnostic) > between arbitrary objects with the help of the "master" index using > the objects'
[Zope3-dev] path adapters
Hi! I have been scratching my head on this one, there is something counter-intuitive in the way path adapters are used in ZPT. If I have a path adapter declared as: and Displayable:getDisplay takes an optional argument for a ZPT programmer, it seems natural to write: tal:define=" displayable nocall:context/displayable; display python: displayable.getDisplay(param);" but when I do this I get: raise TraversalError(name) TraversalError: 'displayable' this only solution I found was to write: tal:define="getDisplay nocall:context/displayable/getDisplay; display python: getDisplay(param);" But it means that I have to adapt the same object each time, why can't the adapted object be a variable? /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
[Zope3-dev] [DOC] cpsskins rendering architecture
Hi! I have summarize how the rendering engine in cpsskins in built, from content, display and format elements to filters, rendering engines: http://www.z3lab.org/sections/documentation/cpsskins-rendering with lots of diagrams and explanations. This part of the architecture has stabilized. /JM ___ Zope3-dev mailing list Zope3-dev@zope.org Unsub: http://mail.zope.org/mailman/options/zope3-dev/archive%40mail-archive.com
