Return-Path: 
 <cocoon-dev-return-17939-apmail-xml-cocoon-dev-archive=xml.apache.org@xml.apache.org>
Delivered-To: apmail-xml-cocoon-dev-archive@xml.apache.org
Received: (qmail 17749 invoked by uid 500); 19 Oct 2001 22:34:52 -0000
Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
list-help: <mailto:cocoon-dev-help@xml.apache.org>
list-unsubscribe: <mailto:cocoon-dev-unsubscribe@xml.apache.org>
list-post: <mailto:cocoon-dev@xml.apache.org>
Reply-To: cocoon-dev@xml.apache.org
Delivered-To: mailing list cocoon-dev@xml.apache.org
Received: (qmail 17723 invoked from network); 19 Oct 2001 22:34:47 -0000
From: "Vadim Gritsenko" <vadim.gritsenko@verizon.net>
To: <cocoon-dev@xml.apache.org>
Subject: RE: [RT] New validator and propagator infrastructure
Date: Fri, 19 Oct 2001 18:33:32 -0400
Message-ID: <002a01c158ee$159128e0$7da4558b@vgritsenkopc>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook, Build 10.0.2616
Importance: Normal
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2600.0000
In-Reply-To: <20011019194447.A1786@renie.dyndns.org>
X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N

> -----Original Message-----
> From: Martin Man [mailto:Martin.Man@seznam.cz]
> Sent: Friday, October 19, 2001 1:45 PM
> To: cocoon-dev
> Subject: [RT] New validator and propagator infrastructure
> 
> hi all,
> 	in response to well-known action flood we have seen over past
> days(weeks) I'd like to propose rewrite of validator actions. The
result
> should be one "validator" action which will do the work of all
existing
> validator actions and maybe even more. I think we should do this
before
> 2.0final, because it's not more than cleanup work... and I'm
volunteering to
> do it actually but first to hear some comments...

Glad to hear it :)
Here some suggestions about propagator...

<snip/>

> 2. Propagator (creator)
> -----------------------
>     propagators were initialiy intended to ease the creation of
various
> parameters from sitemap, e.g.
> 
>     <map:act type="propagator">
>         <parameter name="store-to" value="session"/> <!-- request,
cookies -->
>         <parameter name="value" value="{1}"/>
>     </map:act>

How about action with different direction: propagate values from
request/session/cookies into sitemap? I found that this is very useful
action (is this only for me???)
I use this pair of actions (from request/session/cookies into map and
vice versa) heavily to personalize user experience on my site (pure data
publishing). If you are interested I can send you my variants of
actions.

Vadim

> 2.1. Where to store (propagate)
> -------------------------------
>  - to session attributes
>  - to request attributes
>  - to cookies
> 
>     note that we can store arbitraty objects to session/request
attributes and
> strings to cookies. because brace expressions {name} are actualy
objects taken
> from map, we have to convert them to strings before storing into
cookies, I
> think we anyway use it for strings...
> 
> 
> I'd like to see your comments and suggestions as well as existing
experience
> with validator/authenticator/propagator actions that we now have for
almost 4
> months. All those changes I'd like to do as soon as RequestContext
will be
> available (and I'm sure it will be ;-)
> 
> P.S. note that I left aside formval logischeet which surely will need
the
> appropriate changes as well, please attach comments/experience to this
> topic as well (some new ideas Christian ???)
> 
> 
> thanx for reading so far,
> martin
> --
> 2CC0 4AF6 92DA 5CBF 5F09  7BCB 6202 7024 6E06 0223
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
> For additional commands, email: cocoon-dev-help@xml.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org