On 1/4/06, Doug Chestnut <[EMAIL PROTECTED]> wrote:
> Andreas Hartmann wrote:
> > Josias Thoeny wrote:
> >>> That is certainly a good idea regarding performance, but maybe it's
> >>> not the best way from a SoC point of view. Would an additional i18n
> >>> transformation step (i18n:date pattern="" src-pattern="") be an option?
> > Another option would be an i18n:date module, source
> > and target patterns could be configured in cocoon.xconf:
> > <component-instance name="i18n-iso8601-rfc822>
> > <pattern in="yyyy-mm-dd ..."
> > out="ddd, dd mmm ..."/>
> > </component-instance>
> >
> > {i18n-iso8601-rfc822:{page-envelope:document-lastmodified}}
> Thanks for the replys. It seems like the "date-converting input-module"
> option might be the best for the sake of reuse. We certainly don't want
> to have to deal with this in each input module (not sure if there are
> any other lenya input modules dealing with dates, but there might be at
> some point).
Can we make the module a generic "function" ability? Can it accept
multiple parameters?
{function:functionName:parameter1:parameter2,...}
{function:convert-iso8602-rfc822:{page-envelope:document-lastmodified}}
{function:substring-before:mylongstring:ring} = "mylongst"
{function:substring:mylongstring:1:{function:indexof:mylongstring:o}} = "myl"
(Do we use 0 or 1 as the first character?)
I had several issues that could have been quickly solved by "standard"
functions such as string manipulation in the XMAPs. I am certain that
if such a framework exists, it will quickly be filled with most of the
"standards".
solprovider
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
