[Zope-CMF] SearchableText, custom subfolders, 2 data streams.

[Ignacio Valdes]

Tres Seaver wrote:

> Ignacio Valdes wrote:
> >
> > Hello all, I'm actually getting somewhere with my portal app, here's some stumper(to me) questions:
> >
> > 1) Does the SearchableText python script have to reside in the
> > PortalPollProductClass? Can it be relocated to a local spot such as in
> > portal_skins/custom?
>
> It can be, although there is good reason to put it on the class:
> class methods are more "tightly bound" to the object than skin
> methods.  If you put in in 'portal_skins/custom', then it will
> be acquirable by *all* objects in the portal (those which don't
> have a "real" method of that name, anyway);  I doubt that this
> is what you intend.
>
>

This is admittedly something of a kludge I'm making brought about by my relationship with my ISP so that
I don't have to ask him for intervention when I need to change something that is not in my space such as
product installation. Thus some of these 'odd' ways of doing things.

>
> > 2) Is there a way to group methods in a subfolder of 'custom'?  I was
> > able to move my modified PortalPollProduct methods to
> > portal_skins/custom, but can't gather them in a portal subfolder because
> > Zope seems unable to find them in a subfolder to portal_skins/custom.
>
> We would need to think about this before proceding;  perhaps it
> would make sense to be able to group skin methods by "type
> object" ID, and have the skins tool automagically search for
> such a subfolder in each "regular" skins folder?
>

As above, unless there is a different way of doing this, it would be beneficial since I won't be able to
modify my custom product methods directly in the class when I move it to my ISP.

>
> > 3) I am modifying the Portal Poll product such that I'm adding
> > properties other than the stock ones such as documentationURL. I would
> > also like to use the standard metadata fields since they already hold
> > title, description, etc. So I need to have all of these data fields on
> > one input form, but then split them up to go to their appropriate
> > places: title, desc-->metadata and  documentationURL-->PortalPoll
> > propertysheet.
>
> I don't quite get this -- why don't you want to edit the
> "poll-specific" data on its own view, and the standard metadata
> on the stock 'metadata_edit_form'?
>

Hmm, you have a point, perhaps I can put it into a two part form. The idea is to have all of my
additional fields on one form so that I don't duplicate fields such as title, description and
contributors.  BTW, is the 'Subject' field operated on by special routines? i.e. is there catalog
functions that are specific to 'Subject' or are does Zcat work on all metadata equally?

>
> You can create a single method as the POST target, and then have
> it update both the metadata and the poll properties::
>
>   context.editMetadata( REQUEST[ 'title' ], .... )
>   pps = context.propertysheets.PortalPollProperties
>   pps.manage_changeProperites( REQUEST )
>

Good, the above is a lot cleaner.

Thanks,

-- IV