Re: JIRA "unification" proposal

Thanks for the update Cedric,
I don't think that should be an open issue. I just saw this commit comment
http://mail-archives.apache.org/mod_mbox/cocoon-cvs/200809.mbox/%3C20080911163750.7A39F2388986 <at> eris.apache.org%3E

Which refers to the Ajax block (and I use JX forms, that seem to
depend on that)

K<o>
Chief Screencaster at http://plan-b-for-openoffice.org/ - a site
powered by Apache Cocoon 2.1.

On 2/28/12 4:10 AM, Cédric Damioli wrote:
> Hi,
> 
> Unfortunately I don't had enough time to do this in the past
> weeks. I'd also like to have a stable 2.1.12 release soon, but I
> must admit that I've never used Dojo-related features in Cocoon
> 2.1.x. BTW, I just take a look at open JIRA issues targeted for
> 2.1.12 and nothing seems to be related to Dojo
> 
> Regards, Cédric
> 
> Le 27/02/2012 22:16, Kaj Kandler a écrit : On 1/3/12 6:18 AM,
> Cédric Damioli wrote:

c3 - I18nTransformer and xhtml markup in properties

Hi all,

we are using the i18n transformer in our app but now we need to add
xhtml tags in the resource bundle. However I tried with 

message.test2 = This is "<h2>message.test3</h2>"
message.test3 = This is "&lt;h2&gt;message.test4&lt;/h2&gt;"

but the problem is that is does not get parsed correctly.

Can it be that our c3 transformer does not support that ATM?

TIA for any infos.

salu2
--

-- 
Thorsten Scherler <thorsten.at.apache.org>
codeBusters S.L. - web based systems
<consulting, training and solutions>
http://www.codebusters.es/

Re: c3 - I18nTransformer and xhtml markup in properties

On 01/03/2012 18:41, Thorsten Scherler wrote:
> Hi all,
>
> we are using the i18n transformer in our app but now we need to add
> xhtml tags in the resource bundle. However I tried with 
>
> message.test2 = This is "<h2>message.test3</h2>"
> message.test3 = This is "&lt;h2&gt;message.test4&lt;/h2&gt;"
>
> but the problem is that is does not get parsed correctly.
>
> Can it be that our c3 transformer does not support that ATM?

Hi Thorsten,
I think that the usage you report above was never tried with C3
I18NTransformer; anyway, do you think it's correct to include markup in
a language catalog? Would this mean that markup is language-dependent?

Regards.

--

-- 
Francesco Chicchiriccò

Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/

Re: c3 - I18nTransformer and xhtml markup in properties

Re: c3 - I18nTransformer and xhtml markup in properties

On 03/02/2012 09:27 AM, Francesco Chicchiriccò wrote:
> On 01/03/2012 18:41, Thorsten Scherler wrote:
>> Hi all,
>>
>> we are using the i18n transformer in our app but now we need to add
>> xhtml tags in the resource bundle. However I tried with
>>
>> message.test2 = This is "<h2>message.test3</h2>"
>> message.test3 = This is "&lt;h2&gt;message.test4&lt;/h2&gt;"
>>
>> but the problem is that is does not get parsed correctly.
>>
>> Can it be that our c3 transformer does not support that ATM?
> Hi Thorsten,
> I think that the usage you report above was never tried with C3
> I18NTransformer; anyway, do you think it's correct to include markup in
> a language catalog? Would this mean that markup is language-dependent?
>
> Regards.
>

We are developing an app for a client in Switzerland where we need to 
support de, en, fr and it. Some markup is indeed language-dependent like 
some links. However in case of some system messages we need to use some 
<strong> ... markup within the i18n values.

In old 18n transformer that had always been supported and IMO is a basic 
feature for the i18n. I need to have a closer look into the i18n 
transfomer where to implement it.

salu2

--

-- 
Thorsten Scherler<scherler.at.gmail.com>
codeBusters S.L. - web based systems
<consulting, training and solutions>

http://www.codebusters.es/

CachingServletServiceSerializer

Re: CachingServletServiceSerializer

Hi Javier,
from a very first look your approach seems very interesting: could you
please file an issue on JIRA and attach your patch there? Thanks.

I might b wrong, but it seems to me that Cocoon 3.0 could also benefit
entirely from your patch.

Regards.

On 05/03/2012 14:50, Javier Puerto wrote:
> Hello Cocoon developers,
>
> We are using Apache Cocoon 2.2 for a project and I've found a
> bottleneck in our template system. We use servlet service components
> to render our pages in the same way you can see for Style Block. The
> current Cocoon Welcome block is an example.
>
> This way of rendering is very useful but as currently the servlet
> services components doesn't implement CacheableServiceComponent
> interface, all the request will be processed completely at the end.
>
> For our usecase, here is an example:
>
> <map:match pattern="x">
>   <map:generate ...
>   <map:transform ...
>   <map:include ...
>   <map:serialize type="servletService">
>     <map:parameter name="service"
> value="servlet:style:/service/common/simple-page2html"/>
>   </map:serialize>
> </map:match>
>
> The most expensive part is the serialization process because we use
> i18n, Link rewriter and some transformations. We can configure
> everything to be cacheable but at the end, the serialization process
> must be performed entirely. I've simply extended the current
> ServletServiceSerializer in CachingServletServiceSerializer adding the
> cache key as requested service URL and NOPValidity as validity object.
> This approach has a problem, due to the nature of the servlet service
> components we need to move all the dynamically generated content from
> our GUI block since if we detect that the content hasn't changed, the
> CachingServletServiceSerializer will not perform any process and will
> return the cached content. Also, as there's a little hack for
> serializer output mime type, if you want to use the new component you
> must set the serialization content type explicitly. See
> http://article.gmane.org/gmane.text.xml.cocoon.devel/73261
>
> <map:match pattern="x">
>   <map:generate ...
>   <map:transform ...
>   <map:include ...
>   <map:serialize type="caching-servletService" mime-type="text/html">
>     <map:parameter name="service"
> value="servlet:style:/service/common/simple-page2html"/>
>   </map:serialize>
> </map:match>
>
> For our usecase seems to fit well and will allow us to enable the
> powerful cocoon caching system for a lot of pages. IMO, it's a problem
> when you want to use the ServletServiceSerializer to have a clean and
> common output for the template system and you can't use the caching
> even with static files.
>
> Attached is the patch for cocoon-servlet-service-components block.
>
> Salu2.
--

-- 
Francesco Chicchiriccò

Apache Cocoon PMC and Apache Syncope PPMC Member
http://people.apache.org/~ilgrosso/

[jira] [Created] (COCOON-2320) CachingServletServiceSerializer

CachingServletServiceSerializer
-------------------------------

                 Key: COCOON-2320
                 URL: https://issues.apache.org/jira/browse/COCOON-2320
             Project: Cocoon
          Issue Type: Improvement
          Components: * Cocoon Core, - Servlet service framework
    Affects Versions: 2.2-dev (Current SVN)
            Reporter: Javier Puerto
            Priority: Minor

Hello Cocoon developers,

We are using Apache Cocoon 2.2 for a project and I've found a bottleneck in our template system. We use
servlet service components to render our pages in the same way you can see for Style Block. The current
Cocoon Welcome block is an example.

This way of rendering is very useful but as currently the servlet services components doesn't implement
CacheableServiceComponent interface, all the request will be processed completely at the end.

For our usecase, here is an example:

<map:match pattern="x">
  <map:generate ...
  <map:transform ...
  <map:include ...
  <map:serialize type="servletService">
    <map:parameter name="service" value="servlet:style:/service/common/simple-page2html"/>
  </map:serialize>
</map:match>

The most expensive part is the serialization process because we use i18n, Link rewriter and some
transformations. We can configure everything to be cacheable but at the end, the serialization process
must be performed entirely. I've simply extended the current ServletServiceSerializer in
CachingServletServiceSerializer adding the cache key as requested service URL and NOPValidity as
validity object. This approach has a problem, due to the nature of the servlet service components we need
to move all the dynamically generated content from our GUI block since if we detect that the content hasn't
changed, the CachingServletServiceSerializer will not perform any process and will return the cached
content. Also, as there's a little hack for serializer output mime type, if you want to use the new
  component you must set the serialization content type explicitly. See http://article.gmane.org/gmane.text.xml.cocoon.devel/73261

<map:match pattern="x">
  <map:generate ...
  <map:transform ...
  <map:include ...
  <map:serialize type="caching-servletService" mime-type="text/html">
    <map:parameter name="service" value="servlet:style:/service/common/simple-page2html"/>
  </map:serialize>
</map:match>

For our usecase seems to fit well and will allow us to enable the powerful cocoon caching system for a lot of
pages. IMO, it's a problem when you want to use the ServletServiceSerializer to have a clean and common
output for the template system and you can't use the caching even with static files.

Attached is the patch for cocoon-servlet-service-components block.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

[jira] [Updated] (COCOON-2320) CachingServletServiceSerializer

     [
https://issues.apache.org/jira/browse/COCOON-2320?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Javier Puerto updated COCOON-2320:
----------------------------------

    Attachment: CachingServletServiceSerializer.patch

Patch to add CachingServletServiceSerializer.

> CachingServletServiceSerializer
> -------------------------------
>
>                 Key: COCOON-2320
>                 URL: https://issues.apache.org/jira/browse/COCOON-2320
>             Project: Cocoon
>          Issue Type: Improvement
>          Components: * Cocoon Core, - Servlet service framework
>    Affects Versions: 2.2-dev (Current SVN)
>            Reporter: Javier Puerto
>            Priority: Minor
>         Attachments: CachingServletServiceSerializer.patch
>
>
> Hello Cocoon developers,
> We are using Apache Cocoon 2.2 for a project and I've found a bottleneck in our template system. We use
servlet service components to render our pages in the same way you can see for Style Block. The current
Cocoon Welcome block is an example.
> This way of rendering is very useful but as currently the servlet services components doesn't implement
CacheableServiceComponent interface, all the request will be processed completely at the end.
> For our usecase, here is an example:
> <map:match pattern="x">
>   <map:generate ...
>   <map:transform ...
>   <map:include ...
>   <map:serialize type="servletService">
>     <map:parameter name="service" value="servlet:style:/service/common/simple-page2html"/>
>   </map:serialize>
> </map:match>
> The most expensive part is the serialization process because we use i18n, Link rewriter and some
transformations. We can configure everything to be cacheable but at the end, the serialization process
must be performed entirely. I've simply extended the current ServletServiceSerializer in
CachingServletServiceSerializer adding the cache key as requested service URL and NOPValidity as
validity object. This approach has a problem, due to the nature of the servlet service components we need
to move all the dynamically generated content from our GUI block since if we detect that the content hasn't
changed, the CachingServletServiceSerializer will not perform any process and will return the cached
content. Also, as there's a little hack for serializer output mime type, if you want to use the n
 ew component you must set the serialization content type explicitly. See http://article.gmane.org/gmane.text.xml.cocoon.devel/73261
> <map:match pattern="x">
>   <map:generate ...
>   <map:transform ...
>   <map:include ...
>   <map:serialize type="caching-servletService" mime-type="text/html">
>     <map:parameter name="service" value="servlet:style:/service/common/simple-page2html"/>
>   </map:serialize>
> </map:match>
> For our usecase seems to fit well and will allow us to enable the powerful cocoon caching system for a lot of
pages. IMO, it's a problem when you want to use the ServletServiceSerializer to have a clean and common
output for the template system and you can't use the caching even with static files.
> Attached is the patch for cocoon-servlet-service-components block.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

Re: CachingServletServiceSerializer