cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Royal <pro...@managingpartners.com>
Subject Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Date Mon, 08 Oct 2001 14:13:35 GMT
At 02:24 PM 10/6/2001 +0200, you wrote:
>Also, I've never seen a case where the need for dynamically generated
>pipelines could not be solved with more carefully designed static
>pipelines.
>
>However, if you have any example that proves me wrong, I'll be happy to
>reconsider my position.

Here's my example, if it doesn't prove you wrong, I'd love to know how else 
I could implement it :)

The dynamically generated piece of pipeline that I'm using is for i18n 
transformation. We are using cocoon as the basis for our web-based 
application, and each data-entry form is represented by an XSP file. We 
also have an object-model in the back end to describe the business systems. 
Each XSP form gives an entry point to edit the object model at a specific 
point. So each form could operate on an object, its parents, some of its 
children, and maybe some FK-type relatives.

The translation steps that we go through are:
generate i18n elements ->
form-specific translations ->
regenerate i18n ->
primary object translations ->
(repeat for each linked child/parent/etc: generate i18n elements -> linked 
object translations) ->
regenerate i18n for any non-translated items ->
default-catch all translations (common terms like address, phone#, etc).

This lets us override translations for any more specific use of an 
object.  Say you have a Customer that has Locations. On a Location edit 
screen the "description" attribute of the Location may be translated as 
"Description". But if you are on a Customer screen that has a  Foreign-Key 
link to a primary location, you may want to translate the "description" 
attribute of that location as "Primary Location Description".

The pipeline to display a form to a user has no concept as to which objects 
it is operating on. It is very simple: 
Generate->Translate->Serialize.  Currently I am the one that created the 
dynamic pipeline and maintains the sitemap, so I don't have an SoC concern. 
The user that creates forms doesn't mess with the sitemap at all.

I don't want to have to make a bunch of different pipelines, and while I 
could fold my translations into a single transformer, I saved time by just 
using the existing i18n transformer and some XSLT stylesheets. Since this 
is a somewhat intensive operation, this is why I am going to move away from 
generating the data for the form in the generate step, to inserting it 
after the translation has taken place. That way the translated forms could 
be cached.

I guess what it comes down to is that the SoC argument changes depending on 
what the creation is. For those of us that are developing applications with 
Cocoon, we might not want to separate concerns as much :)

I hope I've explained myself well.
-pete

-- 
peter royal -> proyal@managingpartners.com
managing partners, inc. -> http://www.managingpartners.com


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


Mime
View raw message