Mailing-List: contact dev-help@cocoon.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cocoon.apache.org
Received-SPF: neutral (hermes.apache.org: local policy)
Mime-Version: 1.0 (Apple Message framework v619)
In-Reply-To: <ct37l2$n8n$1@sea.gmane.org>
References: <cstjmv$6iq$1@sea.gmane.org> <41F279A6.7020704@nada.kth.se>
 <csu7ct$kpi$1@sea.gmane.org> <41F37683.9090203@nada.kth.se>
 <ct0hge$udh$1@sea.gmane.org> <41F3EDFE.70505@nada.kth.se>
 <F2D7D294-6DC7-11D9-9957-000393B3DE96@hard-bop.com>
 <ct37l2$n8n$1@sea.gmane.org>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Message-Id: <EDD1E264-6E3F-11D9-9957-000393B3DE96@hard-bop.com>
Content-Transfer-Encoding: quoted-printable
From: Glen Ezkovich <glen@hard-bop.com>
Subject: Re: servicemanager and jxtg (was: WishFull thinking JX and
 SessionContext Authentication)
Date: Mon, 24 Jan 2005 13:41:23 -0600
To: dev@cocoon.apache.org


On Jan 24, 2005, at 10:27 AM, BURGHARD =C9ric wrote:

> Glen Ezkovich wrote:
>
>> I think the important thing to remember is that JXTG should be used=20=

>> for
>> injecting data. Regardless of whether it is called directly through=20=

>> the
>> sitemap or through flow it should allow access in a consistent way to
>> session, request and other objects that are necessary to injecting=20
>> data
>> into the view. If you need to look up data from a database or other
>> source, authenticate users or make decisions on what data to present,
>> it should be done before using JXTG.
>>
>
> Injecting data is the point, but for me "looking up data from a=20
> database" is
> quite like "injecting data". Just it's not from session but who cares.
> Passing through flow for something that has nothing to do with logic,=20=

> and
> because it's not in session, just let me think that there should=20
> certainly
> exist a better way.

Flow is not just about logic its about control. Flow is one of Cocoon's=20=

controllers. The controllers role is to mediate between the view and=20
the model. Data access is a concern for the model not the view. I'm not=20=

sure why if you have static data you would need flow or JXTG. If your=20
data is dynamic and needs to be accessed on a per request basis then=20
you have entered the realm of the model. Flow is one method (and the=20
recommended method) to access the data contained in the model.

>
>>
>> Since CForms is an integral part of Cocoon, maybe it is time to =
handle
>> them directly in JXTG and not with macros. I don't know.
>>
>
> So move forms block to core or move jxtg to forms ? In fact i'm quite
> satisfied with your answer because it shows clearly that there's some
> needle in the foot of jx. Perhaps it's time to define a plugin API=20
> around
> jxtg so you could preserve actual block separation (which i found=20
> really
> great).
>
>>
>> Why not just use a generic function and pass parameters from the
>> sitemap?
>>
>
> I know how to factor things. It's not a matter of some sort of naming
> conventions (call your flow function with the same prefix than your jx=20=

> and
> your pipeline).

Thats not what I meant. One flow function gets passed URLs for files or=20=

DBs or whatever declared as sitemap parameters.

>  The point is to go through flow without really needing it
> (in the SoC sens if we're both agree that flow is dedicated to logic).=20=

> But
> sure i need to, if things stay like that.
>

Flow can be used for very simply things or very complex things. Its=20
there, use it. And Flow its not just dedicated to logic its dedicated=20
to playing the role of the controller in an MVC implementation.

>>> 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?
>>
>> I think this should be obvious, but then again, it obviously isn't.=20=

>> ;-)
>> Even plain old flow is cleaner. I guess some people just like xml
>> better then javascript. ;-0 Maintaining one file instead of two is
>> obviously simpler. The price is a more complex file and in this
>> particular case a more complex system to learn. Complexity cannot be
>> removed, only shifted. IMO, a simple templating language is what we
>> should be aiming for. The methods cocoon provides for data access are
>> sufficient and simple enough for most use cases.
>>
>
> Sorry. I was warned ;-). The templating will stay exactly the same.=20
> Not more
> or less complex, at least for users. Just extensible. Sylvain is not=20=

> the
> only one on the earth who had good reasons to "extend" jx (by good i
> suppose that cforms macros are on the repository not only because=20
> sylvain
> is a comiter :-), and we are quite agree to say that he did it by the
> cleanest way he could (but IMO not the cleanest due to design flaws).
>
>>
>> I don't want to restart the discussion on taglibs, but there is an
>> existing method to do this. Its using flow and JXTG. I don't really=20=

>> see
>
> Nothing new, we all know that. That's not the issue.
>
>> what the big deal is with having two files. A change in how or where
>> (URL) data is accessed does not have an effect on how or where in the
>> template it gets injected and vice versa. The fact that one does not
>> affect the other shows clearly that these are separate concerns.
>>
>
> What's the big deal of having just one file instead of two, specially=20=

> if the
> refactor needed to do that doesn't compromise simplicity nor break the=20=

> SoC
> paradigm ?

But it does. Thats where we disagree.

>
>>>
>>> Might be reasonable, but I got so much flaming when I proposed that=20=

>>> so
>>> I don't feel like pushing it anymore.
>>
>> Good. :-P
>>
>
> Sad to be flamed for such things. (But i'm smiling anyway ;-). Please=20=

> push
> it, i'll push it with you. I feel that good ideas seems to emerge from=20=

> this
> discussion.
>
>
>
>

Glen Ezkovich
HardBop Consulting
glen at hard-bop.com
http://www.hard-bop.com


A Proverb for Paranoids:
"If they can get you asking the wrong questions, they don't have to=20
worry about answers."
- Thomas Pynchon Gravity's Rainbow