cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BURGHARD Éric <eric.burgh...@systheo.com>
Subject sitemap, jx and flow design (was: servicemanager and jxtg)
Date Tue, 25 Jan 2005 01:03:30 GMT
Stefano Mazzocchi a écrit

> 
> The problem is to separate concerns. We aim to have a template language
> that we can give to graphic designers and therefore they will be given
> the page and the variables that contain the dynamic data they need to
> present. No other information is required for them to accomplish their
> task.
>
> This is IoC at the template level and all the information on "how to
> populate the context" is somewhere else (at the 'controller' level).
> 
> By placing even a single <sql:query>select * from users</sql:query> in
> the template you are breaking this isolation because now template
> designers need to know the structure of the database (and they don't!),
> so this resorts in having two people having to maintain the same page.
>

This is exactly what i'm talking about. I never wanted to put such "low
level" things inside the template directly. I was just talking about the
possibility for a developper to add some tags (macros or other) precisely
for his designers so they don't have to know the database structure.

For example a <my:UserProfile /> (or even better <my:get from="userprofile"
what="telephone"/>) is sufficient to retrieve the user profile from the
xmldatabase (designers obviously don't know where the data come from). The
job is done in an included jx:macro, or even better in a java component so
i can reuse this code in flow (if it can serve somehow for some kind of
logic inside the pages flow).

I don't need flow here, it's a pure template (SoC).

In fact, for doing this i would have 3 solutions:

1) access the servicemanager and write some (ugly) xml jx code.  With the
help of various components, access the data, return a dom or a string. For
not disapointing my designers, encapsulate all that ugly stuff in a
jx:macro in a separate file. Not really good but better than nothing. Not
possible without blackmagic. I have no access to servicemanager under jx.

2) extend jx and suply my own tags, exactly the same solution as jx:macros
but in java. As an avalon component my tag library would have full access
to the servicemanager. I could reuse some part of my component under flow
if necessary. Better than 1) but not possible too: there's no extension API
to JX.

3) use the sitemap to pass parameters and use the rich input module library.
IMO the the best solution, but  impossible for a real use case. Because i
can only pass strings, i need to pass hundreds of parameters where a single
dom would have suffice.

So this let me making several observations from the actual design:

1) JX and Flow are so tied that you can pass object from one to another. The
sitemap, which play a side role (pipeline->Flow, Flow->pipeline) and
central role (Flow SendPage->pipeline->JXTG) is curiously excluded from the
conversation (it don't speak the same language: it can only pass strings as
parameters).

2) but JX and Flow are not so well tied (from a user point of view), as OM
between JX and Flow are completely different (perhaps more homogene with
jxtg 2.0 but not exactly the same as i could understand). I can access to
servicemanager from flow but not from JX.

3) CForm "extend" jx by the mean of some macros (tags with their own
namespace), but apparently we (cocoon users) are not allowed to do that (no
extension API) even if cforms macros have been said to be really convenient
(ie other things than forms could be implemented and provide the same
convenience without breaking SoC). We are not allowed either to mention the
word "taglib" even if it's one ;-)

Without a clean API, sylvain had to do some blackmagic inside macros and
added an xml consumer in the jx $cocoon map. What happen to the beloved SoC
if i can screw up the sax flow directly from jxtg (the designer land
tool) ?

Ok i'm joking a little, but i Just wanted to show that a taglib (please
don't flame me :-), could be usefull here and would help to not break SoC
if your will is to allow extensions like cforms in jx.

Conclusion. If i could pass other things than strings in the sitemap you
could remove (deprecate ;-) the $session, $cocoon and all that stuff from
jx and keep it minimal (Just keep variables). I see explicitly from the
sitemap what i use in my template or in my flow. Define a tag architecture
so that blocks like forms can plug cleany into the sax generation of jx.

Otherwise, please (poor user request :-), keep the OM homogeneous between JX
and Flow and let me separate my concerns by accessing the servicemanager.

> So, normally, this ends up having a pipeline, one person manages the
> generator the other manages the transformer, but at this point, the
> contract between the two gets bigger than a simple template context.
> 

We are all agree.

WAIMS (where am i missing something ? :-)

WDYT ?


Mime
View raw message