Five/Z3 vs. Plone/AT round 2

Hi guys,

I'm quite happy with the amount of discussion my last post on this  
generated, so let's try something a bit more concrete. As some of you  
know, I want to try to refactor PloneJobBoard  
(https://svn.plone.org/svn/collective/PloneJobBoard/trunk) to take  
advantage of Five and some of the new technologies. I had a very  
instructive chat with Alec and Rob today, and I'd like to present some of  
the thinking to come out of that for you all to rip apart. Hopefully, this  
will serve as a useful use-case and focal point for some of these  
discussions.

First, a disclaimer: Rob rightly points out that we don't really know how  
all of this is going to work, and there are several missing pieces. I'm  
not going to promote anything that may turn into a support burden in the  
future. Instead, I want to see how this may work, and help plug the gaps.  
An "Evolved AT" and a complete "new" framework is probably months if not  
years away. I truly do hope that someone steps up and drives both the  
continuation of this discussion and the ensuing implementation. I'm  
certainly interested in being part of that. But until that happens, it's  
important to see what's available now, and what can be made possible with  
a minimum of effort.

So - some background. PloneJobBoard looks like this:

   +-(> CategoryAccessMixin <)-+
   |                           |
   |                           |
   |                           |
   |                           |
  Category  <>----->*  SubCategory  <>---->*  Board
                         <>    *                *
                          \    ^                ^
                           \   |                |
                            +--+                |
                                                o
                         Response  *<-----<> Posting

Key: <>--->* one-to-many aggregation (folderish parent/child)
      o---->* one-to-many reference (multivalued reference field)
      ----(>  inheritance (mix-in classes)

That picture says, a Category contains any number of nested  
sub-categories, which can contain any number of boards. Categories have  
some fields provided via CategoryAccessMixin that let the administrator  
setting up categories and board create rules like "Postings must refer to  
at least/at most/exactly one board in this (sub-)category". There is also  
the possibility of restricting use of a board based on the poster's role.  
These are acquired/inherited if they are not set for a sub-category.

Postings are created by regular users e.g. in their home folders, and  
refer to boards via a multi-valued reference field with a custom widget  
and valiator that enforces the aforementioned CategoryAccessMixin  
constraints. Hence, administrators can build structures for categories and  
boards like:

   Location <<category, required, single-valued>>
      USA <<subcategory>>
         ....
      UK <<subcategory>>
         London <<board>>
         Midlands <<board>>
         ....
      ...

   Skills <<category, required, multi-valued>>
     Zope <<subcategory>>
        Plone <<board>>
        Zope 3 <<board>>
        ...
     PHP
        ...
     ...

When creating a job posting, you may be required to select exctly one  
Location and at least one Skill. When a Posting is published, it will show  
up on the relevant boards, via AT back-references (actually, a query on  
UID).

Anonymous users or logged-in members can respond to published Postings  
(subject to permissions, of course), which they find by browsing  
Categories and Boards. A Posting is folderish with a number of Responses  
that can be created by anonymous and contains contact details (pre-filled  
for members), some extra information and an uploaded CV file. Once saved,  
it is viewable and editable only by the owner of the parent Posting. This  
requires a lovely soup of portal_factory, global permissions,  
workflow-managed permissions, worklow auto-transitions, local roles and  
other fun stuff.

Now, the aim here is to see how Five/Z3 can help. I'm not worried about  
migration or breaking things, but I want something that's deliverable and  
usable now/in the near future. However, out of this should come some  
thinking on where the pain remains, where migration paths may be made  
avaiable in the future to a better way of doing things etc.

This is my current thinking. Your input, suggestions and ridicule is  
highly appreciated:

  o Use Z3 interfaces for IJobBoardCategory, IJobBoard,  
IJobBoardRestrictions (for CategoryAccessMixin's functionality - things  
like isSingleSelect() or isRequired()), IJobPosting and IJobResponse

  o Either let the AT types above directly be the adapters for these  
interfaces (i.e. they "adapt" the AT schema/fields/ZODB storage to the  
interface) OR have some intermediary adapter classes between the AT type  
and the interfaces. I'm unsure what the benefits of each approach would  
be, though.

  o Rewrite CategoryAccessMixin as an adapter from a Category or  
SubCategory (not sure we'll still need the distinction between category  
and sub-category anymore) to an IJobBoardRestrictions.

Working in terms of interfaces here should make the code cleaner. It  
should also make it possible to interact with other types of job board  
implementations, e.g. from a relational database. It should hopefully also  
simplify code a bit.

  o Use a utility to provide the  
find-relevant-job-board-categories-and-validate service. Recall that both  
the custom reference widget that relates postings to boards (Posting  
o--->* Board) and the validator for this that ensures the  
CategoryAccessMixin stuff is honoured need to find all categories and  
boards and figure out what the user must and can select. Currently, this  
is done with a catalog query in the widget and the validator that finds  
the job boards, figures out restrictions, gets titles and descriptions and  
constructs the appropriate UI and validation logic. However, this  
introduces a dependency on these things being content objects in the  
catalog. I'm not quite sure how this may work, though. Some unanswered  
questions:

	- If the standard implementation does a catalog search for JobBoards,  
could you potentially adapt catalog search results (brains) to  
IJobBoardRestrictions? Or would this only work on full objects? Use  
decorators around the catalog bains perhaps? Would it be better to adapt  
these inside the utility and return the adapted objects, or to let the  
calling code in the widget and validator do that?

	- The utility would probably need to return both IJobBoardRestrictions  
and a least the Title and Description of the job board. Is this best  
handled with getting two adapters for the same object (i.e. the brain or  
whatever else is returned by the utility?), or via interface inheritance  
or something else? Title and Description probably don't belong in  
IJobBoardRestriction.

This utility could probably also be used to provide the backreference  
search in the Board view that finds the published postings that refer to a  
given board. Again, it'd be nice if this could avoid waking up all those  
objects but still provide some abstraction via an IJobPosting.

  - Use Five views for the job posting views.

	- Could we use a view for the custom (Archetypes) widget as well? This  
would be quie useful, as there's a lot of logic here to provide the proper  
UI based on the CategoryAccessMixin-cum-IJobBoardRestriction rules.

  - The Response business badly needs an add-form, and can be quite basic  
otherwise. Basically, it'd need:

	- The possibility for anonymous to add responses

	- The ability to upload files

	- Some more rules around who can add responses: a logged-in member should  
only be allowed to add a response once, after which time the add-response  
functionality should disappear

	- Once a response is added, it should only be viewable to the owner of  
the parent posting

	- A response should be viewable as a single item, or as an aggregate  
(e.g. a csv export)

	- It should be possible for the parent posting owner to delete and edit  
responses to correct errors etc.
	
	- It would be really cool if the creator of the posting could define a  
number of additional fields to add to a response so as to capture  
posting-specific information. Not really feasible at present, though,  
unless Z3 has some tricks up its sleeve?

I've spoken to Alec Mitchell about his plone_schemas product  
(https://svn.plone.org/svn/collective/plone_schemas/trunk/), and I'm  
tempted to use this for responses, basically making the responses Z3  
content.

Finally, I'm wondering if Fate can provide some wins for the other content  
types, e.g. to get proper add forms. Not having any documentation or  
sample code, Fate is a bit of a black box still.

Okay, that's about as far as I've managed to come in my head to date. What  
do you all think?

Martin



-------------------------------------------------------
This SF.Net email is sponsored by the JBoss Inc.  Get Certified Today
Register for a JBoss Training Course.  Free Certification Exam
for All Training Attendees Through End of 2005. For more info visit:
http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click