Conal Tuohy wrote:
Leszek Gawron wrote:
If I follow what you propose my model would have to covert every
wikified string property even if view does not need it. This
No ... only that it should be ABLE to convert the property to a DOM whenever the view DOES need it. If your view never requests i
Leszek Gawron wrote:
> If I follow what you propose my model would have to covert every
> wikified string property even if view does not need it. This
No ... only that it should be ABLE to convert the property to a DOM whenever the view
DOES need it. If your view never requests it then the con
Conal Tuohy wrote:
-Original Message-
From: Leszek Gawron
My question is: why do you call a wiki parser a "model
aspect" if in my
example I have to pass it for EVERY model? It looks more like a view
plugin really.
Where should you draw the line between model and view?
In the case of
> -Original Message-
> From: Leszek Gawron
> My question is: why do you call a wiki parser a "model
> aspect" if in my
> example I have to pass it for EVERY model? It looks more like a view
> plugin really.
Where should you draw the line between model and view?
In the case of JXTG,
Ugo Cei wrote:
Il giorno 11/ago/04, alle 10:00, Leszek Gawron ha scritto:
- I end up inserting a wiki parser in user session and referencing it
in jx template via:
${cocoon.session.wikify( activity.task.project.description,
cocoon.consumer) }
Same for any other formatter or presentational macro (
Il giorno 11/ago/04, alle 10:00, Leszek Gawron ha scritto:
- I end up inserting a wiki parser in user session and referencing it
in jx template via:
${cocoon.session.wikify( activity.task.project.description,
cocoon.consumer) }
Same for any other formatter or presentational macro (like link
deco
Conal Tuohy wrote:
-Original Message-
From: Leszek Gawron [mailto:[EMAIL PROTECTED]
assume you have a collection of Projects. Each project has a
project.description property. This property contains a string
that can
be parsed by a wiki parser and generate html out of it. How would you
> -Original Message-
> From: Leszek Gawron [mailto:[EMAIL PROTECTED]
> assume you have a collection of Projects. Each project has a
> project.description property. This property contains a string
> that can
> be parsed by a wiki parser and generate html out of it. How would you
> imple
Leszek Gawron wrote:
Joerg Heinicke wrote:
Why JXTG sucks? Because it's to powerful!
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
(It's not the first time that it is posted here.)
Jörg
I'll read the document and have more comments tomorrow.
Browsing over the PDF, ahh, "recusively-enume
Joerg Heinicke wrote:
Why JXTG sucks? Because it's to powerful!
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
(It's not the first time that it is posted here.)
rules:
view cannot modify the model
view cannot perform computations upon dependent data values
view cannot compare dependent dat
Why JXTG sucks? Because it's to powerful!
http://www.cs.usfca.edu/~parrt/papers/mvc.templates.pdf
(It's not the first time that it is posted here.)
rules:
view cannot modify the model
view cannot perform computations upon dependent data values
view cannot compare dependent data values
view cannot m
Just "Jelly"!
It has all functionality that JXTG gives you, plus the fact that you can
build your own tags either as classes or as macros!
On Tue, 2004-08-10 at 16:14, Antonio Gallardo wrote:
> Nuno Santos dijo:
> > JXTG is a nice templating tool, but very limited! Why should we be stuck
> > to
Leszek Gawron wrote:
Is anybody interested in FreeMarker integration with cocoon? There is no
single word (Oh there are some freemarker occurences but they do not
stick to the subject) about FreeMarker on the cocoon-dev list. It is BSD
style licensed so there is no problem with shipping it with
Nuno Santos dijo:
> JXTG is a nice templating tool, but very limited! Why should we be stuck
> to it if we have a more powerfull templating stuck in the scratchpad?
Please, can explain more what we have there? Just curious.
Best Regards,
Antonio Gallardo
JXTG is a nice templating tool, but very limited! Why should we be stuck
to it if we have a more powerfull templating stuck in the scratchpad?
--
Nuno Santos <[EMAIL PROTECTED]>
Electroplus, lda
Leszek Gawron wrote:
Ugo Cei wrote:
Il giorno 10/ago/04, alle 11:13, Leszek Gawron ha scritto:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macro in jxtg):
I don't think it's the view's responsibilit
Ugo Cei wrote:
Il giorno 10/ago/04, alle 11:13, Leszek Gawron ha scritto:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macro in jxtg):
I don't think it's the view's responsibility to parse XML. Parse
Antonio Gallardo wrote:
Leszek Gawron dijo:
I have implemented only a few small projects using jxtg and found some
live examples of these limitations:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macr
Il giorno 10/ago/04, alle 11:13, Leszek Gawron ha scritto:
1. you cannot parse string from your model as xml, had do use session
hacks to do that ( put flowscript function into session, use it via
macro in jxtg):
I don't think it's the view's responsibility to parse XML. Parse it in
the flow
Leszek Gawron dijo:
> I have implemented only a few small projects using jxtg and found some
> live examples of these limitations:
> 1. you cannot parse string from your model as xml, had do use session
> hacks to do that ( put flowscript function into session, use it via
> macro in jxtg):
Antonio Gallardo wrote:
Hi Lezsek:
I will talk about my own experience. We already build 2 fairly
semi-complex forms intensive applications with CForms + JX Template
Generator. The idea is that JXG is used only for some special view
purposes. You "prepare" the data on a java class and JXT just show
Hi Lezsek:
I will talk about my own experience. We already build 2 fairly
semi-complex forms intensive applications with CForms + JX Template
Generator. The idea is that JXG is used only for some special view
purposes. You "prepare" the data on a java class and JXT just show them.
We also use it t
Tony Collen wrote:
Leszek Gawron wrote:
Is anybody interested in FreeMarker integration with cocoon? There is
no single word (Oh there are some freemarker occurences but they do
not stick to the subject) about FreeMarker on the cocoon-dev list. It
is BSD style licensed so there is no problem
Leszek Gawron wrote:
Is anybody interested in FreeMarker integration with cocoon? There is no
single word (Oh there are some freemarker occurences but they do not
stick to the subject) about FreeMarker on the cocoon-dev list. It is BSD
style licensed so there is no problem with shipping it with
Is anybody interested in FreeMarker integration with cocoon? There is no
single word (Oh there are some freemarker occurences but they do not
stick to the subject) about FreeMarker on the cocoon-dev list. It is BSD
style licensed so there is no problem with shipping it with cocoon I think.
To
25 matches
Mail list logo
