Re: getting an object x in an external method that can be passed as context to ContentInit( ... ).initialize(context)

I am resending this message because one of gmail's servers seem to be
blacklisted and the original message got bounced.

---------- Forwarded message ----------
From: Enrique Pérez Arnaud <[email protected]>
Date: 02-dic-2005 20:16
Subject: Re: [Archetypes-devel] Re: getting an object x in an external
method that can be passed as context to ContentInit( ...
).initialize(context)
To: Martin Aspeli <[email protected]>
Cc: archetypes-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org


2005/12/2, Martin Aspeli <[email protected]>:
>
>
> > Suresh's answer sounds much better than my solution, that I give
> > below.
>
> What you're doing is quite crazy (and a little bit cool). I haven't played
> with ATSchemeEditorNG, but I thought that it would be a way to achive this
> type of thing, without any crazy on-the-fly content creation.

At first that is what I did: Like GenericPloneContent, which, as far
as content creation goes, and as far as I can understand, is to call
manage_addTypeInformation from CMFCore.TypesTool with the id of the
new content type and the typeinfo_name of a precreated type. What this
seems to achieve is to have different instances of this precreated
type with different schemas; the portal factory is asked to create
typeA or typeB, and what it creates is an instance of the precreated
type with schema A or schema B, which are managed by ATSE's
SchemaEditorTool. I haven't investigated GenericPloneContent further,
because it doesn't seem to work with Plone-2.1.1 (always an error on
generating new "content types": "unsubscriptable object". I think it
works with Plone-2.0.4, though.) Anyway, I managed to get the previous
framework going (on 2.1.1): I was able to create new "content types"
on instantiation of the folderish schemaEditor-based precreated type,
and could manage their schemata through the instances of this
folderish type, and could add instances of this new types to the
folderish objects. However, these new "content types" would not appear
in the list of possible "portal type constraint" of Relation's
rulesets, and would not appear in several other lists which I don't
recall now. Like they are not truly content types all the way. That's
why I decided to create them on the fly. I now think that probably I
could have put them in some other list, or have made them inherit some
interface, that would add them to the lists I need; but before blindly
going back to that road, I need, either some pointer, or to exhaust
the one I am upon. I must find out wether this "on the fly creation of
content types" is possible (and that's the end of the road) or not
(and why not).

>
> A few other points:
>
>  - Subclass RichDocument and modify the schema and whatever else you need,
> don't copy the source. This makes it easier to re-use.

Then you should have written "Howto to subclass RichDocument and ..."
;-) You are absolutely right, but at the same time as writing my
would-be-product, I was learning by going through your excelent howto.
On further thought, I am totally wrong: I guess I could have gone
through your howto subclassing from RichDocument.

>
>  - If you must create classes on the fly, my guess would be that you'd have to
> do what __init__.py in a typical product does when the content object is being
> created. Whether this works outside Zope startup, I have no idea. You'd also
> need to cache that somehow and run it during __init__.py on the generator
> product as well.

I see what you mean. My next step is to research this.
>
>  - Install.py does a lot of things. You probably dont' need to register skin
> directories, for one thing. About the rest of what it does, you'll have to
> understand it and do it on a case-by-case basis.

Yes, I have done it that way, the new content types would in principle
inherit and acquire the skins, I have gone through install slowly (I
think.)
>
>  - You won't need external methods (they are a pain). Any filesystem code
> (i.e. not a pyscript in skins/<yourproduct>/*.py) can do the kinds of things
> Install.py's install() method does. Hence, you could do this e.g. in a tool or
> a method on your parent type.

Well I guess all the code could be in the mutator that triggers the
creation of new content. I moved it out of there at one point for
mistaken reasons.
>
>  - It'd be better if you coded in English, since most developers are English.
> I can't follow your examples because I don't speak Spanish (?), and hence I'll
> never be able to help you with your code... Also, the python syntax is in
> English, and you seem to speak it quite well, so...

Sorry about that. I thought of s/// the spanish, but then I thought
that the etymology of most terms I was using was the same for both
languages (content - contenido, object - objeto, install - instalar,
context - contexto, class - clase, archetype - arquetipo, documento,
imagen...) The only spanish terms that don't follow this rule are, I
think, "almacen" which means storeroom, and "cosa" which means thing.
>
>  - I still thing this is nuts :-)

The objective is an image storing system, one that can have many
images and retrieve them in a way as rich as possible. The images
would be grouped in objects, and the classes of these objects would be
defined by the user. A Hotel object would have a schema reflecting its
stars, number of rooms, address, phone, web page, etc; A Room's, its
beds, size, bath, floor, views... Then an "is a room of" relation
would establish a link between both groups of images, a relation of
"is located in" would establish a link between hotel and town, and so
on, so that you might surf through the images by logical connections.
This deployment might serve for a tourism agency, that can accumulate
hundreds of thousands of pictures. A news agency might have as objects
events, people, photo sessions... and so on. On top of this, there
would be a tree of categories that can link to any type of content,
and a full text search.



--
Enrique Pérez
[email protected]


-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?  Stop!  Download the new AJAX search engine that makes
searching your log files as easy as surfing the  web.  DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_idv37&alloc_id865&op=click