Reinhard Poetz wrote:
Anyway, as we agreed that 2.2 should come soon, I don't think it's worth
doing the refactoring.
Agreed.
> And if somebody really want's to use the new
rhino version too, he can simply exchange the libraries manually. The
only drawback is that this is an "all or nothing" dec
Le 24 janv. 05, à 07:47, Reinhard Poetz a écrit :
...Anyway, as we agreed that 2.2 should come soon, I don't think it's
worth doing the refactoring. And if somebody really want's to use the
new rhino version too, he can simply exchange the libraries manually.
The only drawback is that this is an
Carsten Ziegeler wrote:
Hello,
what do you think of a 2.1.7 release in the near future - middle of
February for example?
Are there any outstanding issues (apart from the usual suspects of course)?
Just for the records: Rhino hasn't been updated in 2.1.X yet. As it introduces
some backwards incom
Daniel Fagerstrom wrote:
So the question is, should we focus on making the FOM the main way of
accessing things in Cocoon or should we focus on IMs.
Carsten's suggestion IIUC is to focus on the FOM, something that I agree
completely with.
I agree with this too.
If we do that we should have some
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
I have done some progress in refactoring JXTG and would like to
summarize the current state and direction for those interested. I'm not
repeating things that are actively discussed in other threads.
Goal
The goal with the refactoring is to factor out things that are useful in
other context
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Your (and others) work is needed, so that we can make the
refactored JXTG stable enough for production use soon.
I've been trying to t
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:
>
> ...
>
> But it wasn't clear to me what the use case does.
>
>> I also had several
>> cases where I wanted the numbering to be consistent across several
>> forEach calls and also had to implement hacks.
>
Couldn't say better :-). That's a good abstract of what this
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Your (and others) work is needed, so that we can make the
refactored JXTG stable enough for production use soon.
I've been trying to trace down the problem with
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
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
BURGHARD Éric wrote:
Variable nature and scope (kind of non-mutable that you can overwrite
?),
but someone could tell me this a feature :-). Perhaps i've miss
something,
but look what i need to do to retrieve a value incremented inside a
forEach
lo
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
oceatoon wrote:
Daniel Fagerstrom wrote:
I agree with that the behaviour is weird, but it is designed to be that
way. What happens is that your data is always placed in the session data
in the servlet. But then the request object, session objects etc are
placed in a different place if you use them
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
Leszek Gawron wrote:
I am trying to track the differences in behaviour in JXTG when running
from flowscript or from standalone pipeline. Is there any testing
support to simulate calling a flowscript function (and an appropriate
pipeline later on of course)?
I have found a callFunction method in
I am trying to track the differences in behaviour in JXTG when running
from flowscript or from standalone pipeline. Is there any testing
support to simulate calling a flowscript function (and an appropriate
pipeline later on of course)?
--
Leszek Gawron [EMA
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Your (and others) work is needed, so that we can make the
refactored JXTG stable enough for production use soon.
I've been trying to trace down the problem with non working dynamic
To whom it may engage...
This is an automated request, but not an unsolicited one. For
more information please visit http://gump.apache.org/nagged.html,
and/or contact the folk at [EMAIL PROTECTED]
Project cocoon-block-template has an issue affecting its community integration.
This issu
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
They should, but I don't see how that is related to getNode/getValue?
jx:set/@value uses getNode and jx:set/* executes the body and put the
result in a DOM.
I see. I wasn't aware of the exact implementation here. Sorry for the
noise.
I have finally
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
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Leszek Gawron wrote:
Daniel Fagerstrom wrote:
Your (and others) work is needed, so that we can make the refactored
JXTG stable enough for production use soon.
I've been trying to trace down the problem with non working dynamic
macro test case. Funny t
22 matches
Mail list logo
