cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: RT - Tree Traversal Implementation of Sitemaps and XSP
Date Sun, 14 Oct 2001 20:30:39 GMT
Peter Royal wrote:
> 
> 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 :)

Hopefully this helps a bit.

> The dynamically generated piece of pipeline that I'm using is for i18n
> transformation. 

Ok.

> 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.

Ok, think about it: you are not doing anything really dynamic since you
can describe the above pipeline without requiring any conditional (if
this do that, etc..).

The pipeline you describe is, therefore, static, not meaning that the
content it generates doesn't change with time, but that its behavior,
the way the resource are generated don't change with time.

> 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.

Ok, but my concerns still remain: if one of your pipeline component must
react on some parameter to change its behavior, is not by changing the
sitemap to allow dynamic use of an existing component, my proposed
strategy would be to extend an existing component and make it more
dynamic, rather than modifying the way the pipelines are composed in
order to obtain the same effect.

> I don't want to have to make a bunch of different pipelines, and while I
> could fold my translations into a single transformer

You said it: I could fold my translations into a single transformer: you
are a java programmer right? why don't you write your own transformer
that implements the behavior you want?

I hear you saying: but with the sitemap would be easier. It might be,
but this is not a good reason to start adding semantics to the sitemap
that would easily turn it into a procedural language.

It's the same issue with Ant build files: tasks should contain dynamic
logic and bahavior should be fixed in component composition.

It's also the same as inlike dynamic code regeneration, a trick that
assembly coders use to optimize their code by readapting dynamically the
code by rewriting the memory cell right before the processor executes
it.

Almost everybody today knows this is shooting yourself in the foot big
time.

, 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 :)

Well, you should anyway: it allows parallel work not only from different
people, but also organizes better the work that one person should do. In
short, one mistake you make in one concern area don't reflect in the
other as much as the contracts are not changed.

In short, crosscutting concerns is a way to work twice when you could
work once.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



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


Mime
View raw message