headers
Geoff Davis | 1 May 2003 14:58

Re: CMFMember

Yeah, I think that should be possible.  If you use ApeLib, it might even be
pretty easy.

-- 

Geoff Davis
http://www.geoffdavis.net

<sean.upton@...> wrote in message
news:AA7A72A46469D411B8B300508BE329500AE4D719@...
> Quick question: Insofar as Archetypes will support mapping of storage for
> field objects, might it be possible to support other backends for member
> data storage such as relational databases or LDAP?  I'm in the process of
> working on a project that manages users with a RDB backend and a custom
user
> folder and memberdata tool - in future incarnations of this project it
would
> be nice to be able to workflow the users.
>
> Sean
>
> -----Original Message-----
> From: Geoff Davis [mailto:geoff@...]
> Sent: Tuesday, April 29, 2003 3:14 PM
> To: Plone Developers
> Subject: [Plone-developers] CMFMember
>
>
> Hi all--
>
(Continue reading)

Permalink | Reply | 501 comments |
headers
Norfleet, Sheppard S. | 1 May 2003 17:14

Per Stage Review State


As you know, for each portal content item there are three versions; one in
dev stage, one in review stage, and one in the production stage (assuming
you propagated all the way to production). The problem is that for all three
of the items(one for each stage) there is only one review state.  

SIDEBAR:(I have modified Plone and Plonestaging so that the states and the
stages are linked as follows: dev={pending,
vis,priv,review(new),rejected(new),published};  review =
review,rejected,published; production=published) :ENDSIDEBAR

So if I change the review state on the dev stage, the production stage
changes as well, that is not a good thing.   Heres why: 

After a document has made it to the production stage it should stay
"published" even though on the development stage the same item may be
pending.  Consider an item that is at revision 10 on dev stage and visible,
revision 8 on review stage in review state, and revision 5 on the production
stage and published.  changes and updates flow only in  one direction from
develpment to production.   You don't change published versions of
documents, you change revisions in the private or visible state, once the
pending->review->published process starts the portal content cannot be
modified again unless rejected or retracted.

Hopefully you see now why I think having separate review states for each
stage is important.  My problem is that lack of familiarity with the guts of
Zope and Plone and was wondering where I should look to make the changes
needed to provide review states for each stage.

One possibility I was considering was making a property called reviewstate
(Continue reading)

Permalink | Reply | 1 comment |
headers
alan runyan | 1 May 2003 21:50

Re: Per Stage Review State

look at portal_workflow.  that controls everything.

>
> As you know, for each portal content item there are three versions; one 
> in
> dev stage, one in review stage, and one in the production stage (assuming
> you propagated all the way to production). The problem is that for all 
> three
> of the items(one for each stage) there is only one review state.
>
> SIDEBAR:(I have modified Plone and Plonestaging so that the states and 
> the
> stages are linked as follows: dev={pending,
> vis,priv,review(new),rejected(new),published};  review =
> review,rejected,published; production=published) :ENDSIDEBAR
>
> So if I change the review state on the dev stage, the production stage
> changes as well, that is not a good thing.   Heres why:
>
> After a document has made it to the production stage it should stay
> "published" even though on the development stage the same item may be
> pending.  Consider an item that is at revision 10 on dev stage and 
> visible,
> revision 8 on review stage in review state, and revision 5 on the 
> production
> stage and published.  changes and updates flow only in  one direction 
> from
> develpment to production.   You don't change published versions of
> documents, you change revisions in the private or visible state, once the
> pending->review->published process starts the portal content cannot be
(Continue reading)

Permalink | Reply | 0 comments |
headers
panjunyong | 4 May 2003 08:15

a patch for archetypes

I tried archetypes these days. I like it very much.

I found BaseObject's processForm function can be refined.

1. a bug in current cvs:

  line 297-298, BaseObject.py :

    if data: fields += schema.filterFields(metadata=0)
    if metadata: fields += schema.filterFields(metadata=1)

  It should be:

    if data: fields += schema.filterFields(isMetadata=0)
    if metadata: fields += schema.filterFields(isMetadata=1)

  'metadata' is not a attribute of Field. It should be 'isMetadata'.

2. It is better to add 'request' argument to method 'processForm' and
'_prcessForm', just like method 'validate'. This would make 'processForm'
more flexible. I need the feature to update two objects in one form.

  As follows:

    def processForm(self, request=None, data=1, metadata=0):
        """Process the schema looking for data in the form"""
        self._processForm(request=request, data=data, metadata=metadata)

    def _processForm(self, request=None, data=1, metadata=None):
        if request is None:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alexander Limi | 4 May 2003 16:18
Favicon
Gravatar

Re: another Visual Editor

On Sat, 26 Apr 2003 21:04:00 +0200, Achim Maisenbacher 
<achim@...> wrote:

> I found this http://www.interactivetools.com/products/htmlarea/
>
> There's a version of the htmlarea which works on mozilla >= 1.3 and ie 
> >=5.5
>
> htmlArea License (based on BSD license) so its free...
>
> perhaps you can check it and integrate it in Archetypes. I'm going to do 
> it for my own widgets, its very easy to use.

Yes, we've been eyeing this software for quite some time, and I'm currently 
looking for funding so we can make it an integral part of Plone (with 
image/linkbrowser) etc.

I will keep you updated on the progress.

--

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Alexander Limi | 4 May 2003 16:20
Favicon
Gravatar

Re: another Visual Editor

On Sat, 26 Apr 2003 21:04:00 +0200, Achim Maisenbacher 
<achim@...> wrote:

> I found this http://www.interactivetools.com/products/htmlarea/
>
> There's a version of the htmlarea which works on mozilla >= 1.3 and ie 
> >=5.5
>
> htmlArea License (based on BSD license) so its free...
>
> perhaps you can check it and integrate it in Archetypes. I'm going to do 
> it for my own widgets, its very easy to use.

Yes, we've been eyeing this software for quite some time, and I'm currently 
looking for funding so we can make it an integral part of Plone (with 
image/linkbrowser) etc.

I will keep you updated on the progress.

--

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 1 comment |
headers
robert | 4 May 2003 18:02
Picon
Favicon

Re: Re: another Visual Editor

I am using htmlaerea together with plone now for some time.
It is very easy to integrate.
Maybe we can make add it to plone "officaly" during the plone sprint in padua.
Robert
Am Sonntag, 4. Mai 2003 16:20 schrieb Alexander Limi:
> On Sat, 26 Apr 2003 21:04:00 +0200, Achim Maisenbacher
>
> <achim@...> wrote:
> > I found this http://www.interactivetools.com/products/htmlarea/
> >
> > There's a version of the htmlarea which works on mozilla >= 1.3 and ie
> >
> > >=5.5
> >
> > htmlArea License (based on BSD license) so its free...
> >
> > perhaps you can check it and integrate it in Archetypes. I'm going to do
> > it for my own widgets, its very easy to use.
>
> Yes, we've been eyeing this software for quite some time, and I'm currently
> looking for funding so we can make it an integral part of Plone (with
> image/linkbrowser) etc.
>
> I will keep you updated on the progress.

--

-- 
mit freundlichen Grüssen

Robert Rottermann
www.redCOR.ch
(Continue reading)

Permalink | Reply | 0 comments |
headers
alan runyan | 5 May 2003 02:02

DTML Compatibility

we are at canada sprint.
slowly looking into fixing up header.pt.. it seems
we will have to break DTML compatibility in 1.1
;-( the 1.0x series will continue w/ DTML compatibiltiy.

please scream loudly if this disturbs you.

~runyaga

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
alan runyan | 5 May 2003 07:26

CMF1.4/Plone HEAD

Sidnei,

in Portal.py you setInstanceVersion to 1.0.1
(in your last checkin?) by doing this we do not
run the migraitons from beta2 all the way to 1.0.1.
a by product of that is folder_rename_form is 
not added to portal_properties/form_properties -
which makes renameing not work which in turn
makes alex very unhappy ;-(.  

all jokes aside.. this is a significant problem because
it seems migrations are being overloaded a tad too
much and re: housing configuration for each version as well
as responsible for migrating from version X to Y.

sooo.. we need to come up with a sensible way to do
migrations from here on out as well as come up with a
standard way to add base functionality to a plone version.

AndyM is going to do a PLIP on migrations to try to fix this.
but we need some brain juices dedicated to it...

~runyaga

-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
Permalink | Reply | 0 comments |
headers
Dario Lopez-Kästen | 5 May 2003 08:51
Picon
Picon
Favicon

Re: DTML Compatibility

[sent this to alan directly by mistake, was meant for the list]

----- Original Message ----- 
From: "Dario Lopez-Kästen" <dario@...>
To: "alan runyan" <runyaga@...>
Sent: Monday, May 05, 2003 8:48 AM
Subject: Re: [Plone-developers] DTML Compatibility

> ----- Original Message ----- 
> > slowly looking into fixing up header.pt.. it seems
> > we will have to break DTML compatibility in 1.1
> > ;-( the 1.0x series will continue w/ DTML compatibiltiy.
> >
> > please scream loudly if this disturbs you.
> >
> > ~runyaga
>
> hm... what does it mean to break DTML-compatibility? I have DTML-app I
have
> just started to migrate to use Plone and I am not comfortable with ZPT.
Does
> this mean I have to stick to 1.0x?
>
> /dario
>
> - --------------------------------------------------------------------
> Dario Lopez-Kästen, IT Systems & Services Chalmers University of Tech.
>

-------------------------------------------------------
(Continue reading)

Permalink | Reply | 0 comments |

Gmane