[Zope-PTK] Wizards design (continued)

[kamon.ayeva@bureauveritas.com]

Hi,

On 03/25 Andrew Wilcox <circle@gwi.net> wrote:
>Portal objects could implement Buildable themselves,

[KA] I understand with Andrew M. Kuchling's response that we should take
'Objects' and not specifically 'Portal objects'. Right ?

>or if they didn't want
to deal with issues of being in an incomplete state, a helper class could
implement Buildable on behalf of a portal object.

>A Buildable object would be stored either in the session, or in a private
member's area of the ZODB.

[KA] Can we say 'Wizard-aware object' to use some interesting concepts from
the ZCatalog API ? I see the object having the  behavior because it
inherits from a class Wizard-aware.
Then wizards are created like Z Search interfaces, but more complicated due
to wizard requirements.

>[snip implementation explanation]

>So, let's see, the Buildable interface would need to provide for:

 * Storing one or more properties at a time
 * Reporting on invalid property values in a *standard* way
 * Once all the properties had been entered, reporting on
     whether the object as a whole is valid
 * Instantiating the object in the ZODB
 * For when you want to edit an existing object, making a
     working copy of the object in either the session
     or a user's private "construction yard" area of the ZODB.

[OK] In non-PTK applications, this means that you need to provide the
'user's private area' facility. This may be adding a constraint to
developers... but, Hmm, one may say If you want to have a powerfull site
and you need things like letting people upload large files, then you want
to implement either a complete PTK product or at least the 'user's private
area' facility in the ZODB.

>...hmm, anything else?


>Is Buildable doing a good job fitting into a
model/view/controller(presenter) architecture Jeffrey?
>>>I have not yet understood this design pattern, so...
I don't know if I missed a mail, but I have not seen Jeffrey's answer ?

Kamon
kayeva@hotmail.com