On Jan 24, 2005, at 11:15 AM, Stefano Mazzocchi wrote:
BURGHARD Éric wrote:
Injecting data is the point, but for me "looking up data from a
database" is
quite like "injecting data".
Not for me. Read why below.
Just it's not from session but who cares.
Passing through flow for something that has no
On Jan 24, 2005, at 10:27 AM, BURGHARD Éric wrote:
Glen Ezkovich wrote:
I think the important thing to remember is that JXTG should be used
for
injecting data. Regardless of whether it is called directly through
the
sitemap or through flow it should allow access in a consistent way to
session, re
BURGHARD Éric wrote:
Injecting data is the point, but for me "looking up data from a database" is
quite like "injecting data".
Not for me. Read why below.
Just it's not from session but who cares.
Passing through flow for something that has nothing to do with logic, and
because it's not in session
Glen Ezkovich wrote:
> I think the important thing to remember is that JXTG should be used for
> injecting data. Regardless of whether it is called directly through the
> sitemap or through flow it should allow access in a consistent way to
> session, request and other objects that are necessary t
Daniel Fagerstrom wrote:
> You should care:
> http://marc.theaimsgroup.com/?t=11021071981&r=2&w=2, 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).
targetNam
I think the important thing to remember is that JXTG should be used for
injecting data. Regardless of whether it is called directly through the
sitemap or through flow it should allow access in a consistent way to
session, request and other objects that are necessary to injecting data
into the
BURGHARD Éric wrote:
Daniel Fagerstrom wrote:
It's strange, because I think that sylvain, with his cforms jx macros
shows how usefull could be a taglib for templating purpose.
We are certainly going to keep macros. The question was rather if we
should have some mechanisms so that it would be easy
Daniel Fagerstrom wrote:
>> It's strange, because I think that sylvain, with his cforms jx macros
>> shows how usefull could be a taglib for templating purpose.
>
> We are certainly going to keep macros. The question was rather if we
> should have some mechanisms so that it would be easy to add o
oceatoon wrote:
Then I think that it shouldn't be part of the JXTG code but rather part
of the TemplateObjectModelHelper or some supporting classes, that in
turn are used by JXTG. This way it could be used outside JXTG.
Wouldn't it be better if JXTG supported input modules with syntax
like:
{im:mod
Leszek Gawron wrote:
> BURGHARD Éric wrote:
>> hi,
>>
>> What about giving access to the servicemanager inside jxtg. We could add,
>> that way, various macros to access components directly (authentication,
>> sourceresolver, session, ...).
>>
>> regards
>>
> I think you're trying to break SoC h
BURGHARD Éric wrote:
Daniel Fagerstrom wrote:
During the "JXTG 2.0 (just say no!)" (you find links to it in
http://wiki.apache.org/cocoon/Templates), many people where negative to
the idea of developing JXTG in a "taglib" direction. We decided that
JXTG should focus on templating and that more prog
BURGHARD Éric wrote:
hi,
What about giving access to the servicemanager inside jxtg. We could add,
that way, various macros to access components directly (authentication,
sourceresolver, session, ...).
regards
I think you're trying to break SoC here. Why don't you access the
components from flow?
> Then I think that it shouldn't be part of the JXTG code but rather part
> of the TemplateObjectModelHelper or some supporting classes, that in
> turn are used by JXTG. This way it could be used outside JXTG.
>
> Wouldn't it be better if JXTG supported input modules with syntax
> like:
>>
Daniel Fagerstrom wrote:
> During the "JXTG 2.0 (just say no!)" (you find links to it in
> http://wiki.apache.org/cocoon/Templates), many people where negative to
> the idea of developing JXTG in a "taglib" direction. We decided that
> JXTG should focus on templating and that more programatic stuf
Carsten Ziegeler wrote:
Leszek Gawron wrote:
don't we have a pluggable object model ? :))
function doIt() {
var objectModel = {};
objectModel.pluggedIn1 = entityFromDatabase();
objectModel.pluggedIn2 = request.getParameter( "skin" );
cocoon.sendPage( "view/myview.jx", objectModel );
}
Other
Leszek Gawron wrote:
don't we have a pluggable object model ? :))
function doIt() {
var objectModel = {};
objectModel.pluggedIn1 = entityFromDatabase();
objectModel.pluggedIn2 = request.getParameter( "skin" );
cocoon.sendPage( "view/myview.jx", objectModel );
}
Other data that is not direct
oceatoon wrote:
do you mean input modules would be pluggable objects and we could create our
own object to be used ? but in that case why not simply create another IM?
And IM are quite usefull all over cocoon, don't you think?
IM are usefull, no doubt and yes it could be done with input modules. I
BURGHARD Éric wrote:
hi,
What about giving access to the servicemanager inside jxtg. We could add,
that way, various macros to access components directly (authentication,
sourceresolver, session, ...).
During the "JXTG 2.0 (just say no!)" (you find links to it in
http://wiki.apache.org/cocoon/Temp
Leszek Gawron wrote:
Leszek Gawron wrote:
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Carsten Ziegeler wrote:
oceatoon wrote:
This is wishfull thinking and probably no news to those
refactoring JX. But
access to the session context object like the session-context
input module
would be great (li
hi,
What about giving access to the servicemanager inside jxtg. We could add,
that way, various macros to access components directly (authentication,
sourceresolver, session, ...).
regards
Leszek Gawron wrote:
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Carsten Ziegeler wrote:
oceatoon wrote:
This is wishfull thinking and probably no news to those refactoring
JX. But
access to the session context object like the session-context input
module
would be great (like for example with th
Carsten Ziegeler wrote:
Leszek Gawron wrote:
Carsten Ziegeler wrote:
oceatoon wrote:
This is wishfull thinking and probably no news to those refactoring
JX. But
access to the session context object like the session-context input
module
would be great (like for example with the authentication cont
Carsten Ziegeler wrote:
> Leszek Gawron wrote:
>> Carsten Ziegeler wrote:
>>
>>> oceatoon wrote:
>>>
This is wishfull thinking and probably no news to those refactoring
JX. But
access to the session context object like the session-context input
module
would be great (like
Leszek Gawron wrote:
Carsten Ziegeler wrote:
oceatoon wrote:
This is wishfull thinking and probably no news to those refactoring
JX. But
access to the session context object like the session-context input
module
would be great (like for example with the authentication context). I
have
found othe
Carsten Ziegeler wrote:
oceatoon wrote:
This is wishfull thinking and probably no news to those refactoring
JX. But
access to the session context object like the session-context input
module
would be great (like for example with the authentication context). I have
found other post asking about an
oceatoon wrote:
This is wishfull thinking and probably no news to those refactoring JX. But
access to the session context object like the session-context input module
would be great (like for example with the authentication context). I have
found other post asking about and for this sort of functio
This is wishfull thinking and probably no news to those refactoring JX. But
access to the session context object like the session-context input module
would be great (like for example with the authentication context). I have
found other post asking about and for this sort of functionality. it would
27 matches
Mail list logo
