On Wed, 2006-01-04 at 18:28 -0500, [EMAIL PROTECTED] wrote:
> 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".
I agree that it would be nice have e.g. string functions in the sitemap.
But it seems to me this approach would mean to invent a new expression
language. I'm not sure if that's a good idea, because cocoon contains a
lot of expression languages already (Xpath, JEXL, etc).
XPath can be used in input-modules, and you can for example do string
operations by (mis-)using any input module which extends
AbstractJXPathModule [1]. An example with the SessionModule:
{session:substring-after('{page-envelope:document-id}','/')}
Note: this expression has nothing to do with the session, it just uses
the xpath capability of the session module.
It would be easy to turn this into a cleaner solution by using a new
input module which extends AbstractJXPathModule instead of the session
module.
Probably this approach is not very useful for more complicated stuff
like a date conversion.
What about using xpath for simple things and specific modules for more
complicated tasks?
WDYT?
Josias
[1] http://cocoon.apache.org/2.1/apidocs/index.html
>
> solprovider
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
