David Crossley wrote:
Ross Gardler wrote:
My point is that I can already do the this same processing with:
...
Does xi:include enable documents to be handled
with the Cocoon cache? When that included document
changes, does Cocoon contine to use the cached content
rather than reloa
Diwaker Gupta wrote:
On Saturday 30 July 2005 3:22 pm, Ross Gardler wrote:
/feeds/somefeed.xml
My point is that I can already do the this same processing with:
...
All that I can see that is changing is that in views the included src is
identified
Diwaker Gupta wrote:
On Saturday 30 July 2005 4:38 pm, Ross Gardler wrote:
...
o unification: most of the work on views so far has focused on XHTML.
again, i'm having a hard time envisioning a unified framework that
integrates all input/output formats.
This was touched on at ApacheCon. in f
Ross Gardler wrote:
>
> My point is that I can already do the this same processing with:
>
> ...
>
>
>
>
Does xi:include enable documents to be handled
with the Cocoon cache? When that included document
changes, does Cocoon contine to use the cached content
rather than reloading?
On Saturday 30 July 2005 3:22 pm, Ross Gardler wrote:
> >
> >
> >> nugget="get.nugget.feeder">
> > /feeds/somefeed.xml
> >
> >
> >
>
> My point is that I can already do the this same processing with:
>
>...
>
>
>
>
>
> All that I can see that i
On Saturday 30 July 2005 4:38 pm, Ross Gardler wrote:
> > o naming and terminology: what is a view? what is a template? given the
> > same content (generated by some "template"), are there different "views"
> > for each output type?
>
> This was discussed at the hackathon, and I just sent a mail to
Diwaker Gupta wrote:
Forgive me for being obtuse, but I completely missed the "change in procesing
paradigm" part :-) I mean, were you talking about a conceptual paradigm
shift, or an implementation detail? Conceptually, IIUC, we still follow a
dispatcher-view patter, no?
See my overlapping e
Thorsten Scherler wrote:
I replied in a another response with respect to the processing paradigm.
This response is about a different issue, hence the change in subject.
The business helper that we have are best described by our most famous
contract.
/feeds/somefeed.xml
Thorsten Scherler wrote:
forrest:views will change the way we are processing a request.
Please explain why your example below changes the *way* we process a
request:
/feeds/somefeed.xml
My point is that I can already do the this same processing with:
.
Forgive me for being obtuse, but I completely missed the "change in procesing
paradigm" part :-) I mean, were you talking about a conceptual paradigm
shift, or an implementation detail? Conceptually, IIUC, we still follow a
dispatcher-view patter, no? I mean Forrest has been about separating con
G'day devs,
for now we limited views to templates in our discussion *but* what I
recommend is more then this templating part of forrest:views.
forrest:views will change the way we are processing a request. I
designed it after the Dispatcher View J2EE design pattern [1].
"Dispatcher View
Context
11 matches
Mail list logo
