cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From BURGHARD √Čric <>
Subject Re: servicemanager and jxtg (was: WishFull thinking JX and SessionContext Authentication)
Date Mon, 24 Jan 2005 14:49:55 GMT
Daniel Fagerstrom wrote:

> You should care:
>, at least if you
> want to avoid extensive flaming ;)

Thanks for the warning. But i don't see any differences :-( Do you ?
Sylvain's macro had namespace too (mazzocchi 2nd condition).
targetNamespace is part of a macro definition no ? The only difference is
the implementation language (jx vs java), or am i missing something ?

>> Now i'm very suprised with this java taglibs aversion (not yours :-).
>> When you look at sylvain's code, for example, he needed to do something
>> that he couldn't express with jexl or jxtemplate (a form is not a kind
>> expression, anyway). So he put an xmlconsumer in the $cocoon map, add an
>> helper class plus some jx blackmagic (not a criticism, i find that smart
>> and very usefull), but he certainly could do that, much more efficiently
>> and understandable, with a well defined jx taglibs API (again i'm happy
>> with current implementation and thanksfull to you cocoon community, just
>> want to understand).
> Ok, I happen to have some strong opinions about this that certainly not
> is shared by all people in the community. First I think that CForms is
> great in many ways and does an excelent job. But IMO its architecture is
> a severe mixture of concerns and rather monolitic. There is no clear
> separation between model, view and control. IMO it should never have
> emited any SAX events at all. Producing XML is a concern for the view
> layer e.g. a set of JXTG macros. If it had been a "passive" model it
> would have been much easier to write the JXTG macros and no hacks would
> have been required.

Don't know enough about CForm architecture (i just wrote some validator),
but i'm totally agree with the sax parts.

> In general I believe that if you have a model that is hard to write a
> view against it is better to write an adapter in Java that makes it more
> "viewable", than doing a lot of programming in the template, I think it
> gives better SOC.

Sure. That's why we definitively need some plugin architecture around jx
interpretor (call it taglib or not ;-) (<- just let me put my antiflaming
armor :-)

>> I thought about just accessing some components functionnalities like
>> getting
>> an instance of ContextManager for retrieving  the dom of a session
>> context (just getters). I know that i can do that with flow, but most of
>> our pages are standalone (ie flow is reduce to a unique SendPage).
> I agree that flow currently is inconvinient to use for such cases. But I
> think that rather than solving this by having all sorts of control
> functionality in the view we should make flow easier to use for such
> cases. I think that a (flow)script action as I described in
> and
> that others also have proposed, would decrese peoples reluctance in
> using flow for somple cases. I mean writing:
> doIt() {
>    return { data: entityFromDatabase(),
>             skin: request.getParameter( "skin" )};
> }
> and
> <match pattern="foo">
>    <call function="doIt"/>
>    <generate type="jx" src="foo"/>
>     ...
> </match>

I prefer that than nothing. That's remind me another point that i would like
to talk about: passing other things than string in the sitemap. The
solution would be quite similar than yours.

<match pattern="foo">
   <generate type="jx" src="foo"/>
       <map:parameter name="data" dom="{mycomp:mygetter('foo',$bar)}"

It certainly need more work to implement, but think of the ability to pass
(explicitly) objects references (perhaps restricted to string and dom)
between sitemap, flow and jx. This way, no more hack needed for template,
no need for servicemanager either, the cycle would be closed. No need for
$session too because you could pass it explicitly to your template without
having to remember that it uses something in session without knowing what
exactly. All would go though components.

> shouldn't feel like an impossible task.
> We could also have something like the pluggable object model that
> Carsten proposed.
> Of course you can, but I don't want to deliver the rope that our users
> can hang them selves in.

Yeah but cocoon is not yet accessible to people which know nothing about
SoC. For the rest of us, it's quite easy to make ropes from strings and
bridges from ropes without breaking SoC. That's why (IMO) an extension API
for jx would be very convenient to encapsulate such "magic" to future
lambda user, without exposing the whole cocoon OM directly (or the sax
stream ;-) in jxtg (as it already is when you look at cforms

>> I was
>> really disapointed as user, after discovering how flow and jxtg were tied
>> together (you can pass object references !), when i realized that the
>> $cocoon objects were in fact totaly different between the 2
>> environnements.
> So was I, hopefully it will work much better in the refactored JXTG.

Thanks. At least for session, context and all that stuff (but your trick
with $session address our issue in jxtg 1.0).

>> I think that the continuations facility is strong enough to enforce
>> people using flow for logics. For the rest (and because they are so tied)
>> keep the OM homogeneous between jx and flow, and let people choose. I
>> don't want to go through flow, if i don't need continuations (ie. no
>> logics), just to retrieve some basic data via components.
> No, I just don't see the reason why we should have easy access to all
> the side effect things in flow, the getters should be enough IMO.

I agree (sitemap solution ?).

> Wouldn't accessing your data oject in a one line (flow)script action as
> described above and viewing it in JXTG be a clean solution?

If i can't see what data is needed by my template directly in the sitemap, i
would prefer looking in one file than two. In the current cocoon state, the
flow solution is the cleanest, sure, and we all know that before begining
this thread, but certainly not the most logical, and at least the one that
bring the most fuzziness around.

>> Now when i'm happy with my jx:macros
>> (which are tags), i could choose to implement them in java (taglibs :-),
>> and/or share a component (which give access somehow to somedata) for
>> reusing code (efficiently) between my jx and my flow.
> Might be reasonable, but I got so much flaming when I proposed that so I
> don't feel like pushing it anymore.

Perhaps the shift (introduced IMO by cform jx), was not clear at this time.
I just feel very uncomfortable with current interactions between sitemap,
jx, xslt and flow, because i really feel that only little things could
bring homogenous behaviors.


View raw message