Thorsten Scherler wrote:
> El lun, 03-04-2006 a las 12:34 +0100, Upayavira escribió:
>> Thorsten Scherler wrote:
>>> El lun, 03-04-2006 a las 09:00 +0100, Upayavira escribió:
David Crossley wrote:
> Upayavira wrote:
>> Sylvain Wallez wrote:
>>> Carsten Ziegeler wrote:
Sylv
El lun, 03-04-2006 a las 12:34 +0100, Upayavira escribió:
> Thorsten Scherler wrote:
> > El lun, 03-04-2006 a las 09:00 +0100, Upayavira escribió:
> >> David Crossley wrote:
> >>> Upayavira wrote:
> Sylvain Wallez wrote:
> > Carsten Ziegeler wrote:
> >> Sylvain Wallez wrote:
> >>>
Thorsten Scherler wrote:
> El lun, 03-04-2006 a las 09:00 +0100, Upayavira escribió:
>> David Crossley wrote:
>>> Upayavira wrote:
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>> Sylvain Wallez wrote:
>>> Hmm... the current CLI uses Cocoon's links view to crawl the website. So
>
El lun, 03-04-2006 a las 09:00 +0100, Upayavira escribió:
> David Crossley wrote:
> > Upayavira wrote:
> >> Sylvain Wallez wrote:
> >>> Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
> > Hmm... the current CLI uses Cocoon's links view to crawl the website. So
> > although the new craw
David Crossley wrote:
> Upayavira wrote:
>> Sylvain Wallez wrote:
>>> Carsten Ziegeler wrote:
Sylvain Wallez wrote:
> Hmm... the current CLI uses Cocoon's links view to crawl the website. So
> although the new crawler can be based on servlets, it will assume these
> servlets to ans
Upayavira wrote:
> Sylvain Wallez wrote:
> > Carsten Ziegeler wrote:
> >> Sylvain Wallez wrote:
> >
> >>> Hmm... the current CLI uses Cocoon's links view to crawl the website. So
> >>> although the new crawler can be based on servlets, it will assume these
> >>> servlets to answer to a ?cocoon-vie
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
>> Sylvain Wallez wrote:
>>
>
>>> Hmm... the current CLI uses Cocoon's links view to crawl the website. So
>>> although the new crawler can be based on servlets, it will assume these
>>> servlets to answer to a ?cocoon-view=links :-)
>>>
>> H
Sylvain Wallez wrote:
> Carsten Ziegeler wrote:
> In the case of Forrest, you're probably right. Now the links view also
> allows to follow links in pipelines producing something that's not HTML,
> such as PDF, SVG, WML, etc.
Yepp.
>
> We have to decide if we want to loose this feature.
Right. So
Carsten Ziegeler wrote:
> Sylvain Wallez wrote:
>
>> Hmm... the current CLI uses Cocoon's links view to crawl the website. So
>> although the new crawler can be based on servlets, it will assume these
>> servlets to answer to a ?cocoon-view=links :-)
>>
> Hmm, I think we don't need the lin
Sylvain Wallez wrote:
> Upayavira wrote:
>
>> Ah, I wasn't getting that subtle. I was simply saying that I can agree
>> with using the servlet API for _all_ environments. The CLI becomes
>> nothing more than a custom servlet container that uses a servlet to
>> generate its pages.
>>
>> In fact, ha
Upayavira wrote:
> Ah, I wasn't getting that subtle. I was simply saying that I can agree
> with using the servlet API for _all_ environments. The CLI becomes
> nothing more than a custom servlet container that uses a servlet to
> generate its pages.
>
> In fact, having said that, it becomes yet a
Carsten Ziegeler wrote:
> Upayavira wrote:
>> David Crossley wrote:
>>> Carsten Ziegeler wrote:
I can't speak for Daniel, but my idea/suggestion was to forget about the
different environments and let Cocoon always run in a servlet container.
The CLI would then be kind of a http clien
Upayavira wrote:
> David Crossley wrote:
>> Carsten Ziegeler wrote:
>>> I can't speak for Daniel, but my idea/suggestion was to forget about the
>>> different environments and let Cocoon always run in a servlet container.
>>> The CLI would then be kind of a http client which starts up jetty and
>>>
David Crossley wrote:
> Carsten Ziegeler wrote:
>> I can't speak for Daniel, but my idea/suggestion was to forget about the
>> different environments and let Cocoon always run in a servlet container.
>> The CLI would then be kind of a http client which starts up jetty and
>> then generates the site
El vie, 31-03-2006 a las 14:32 +1100, David Crossley escribió:
> Carsten Ziegeler wrote:
> >
> > I can't speak for Daniel, but my idea/suggestion was to forget about the
> > different environments and let Cocoon always run in a servlet container.
> > The CLI would then be kind of a http client whic
David Crossley wrote:
Carsten Ziegeler wrote:
I can't speak for Daniel, but my idea/suggestion was to forget about the
different environments and let Cocoon always run in a servlet container.
The CLI would then be kind of a http client which starts up jetty and
then generates the site using htt
Carsten Ziegeler wrote:
>
> I can't speak for Daniel, but my idea/suggestion was to forget about the
> different environments and let Cocoon always run in a servlet container.
> The CLI would then be kind of a http client which starts up jetty and
> then generates the site using http requests. This
Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
>> David Crossley wrote:
>>
>>
>>> Hi Daniel, sorry i cannot understand that last sentence.
>>> Would you please re-phrase it.
>>>
>>> We currently have the three ways:
>>>
>>> 'forrest run'
>>> Starts its packaged Jetty and uses Forrest/Cocoon a
Carsten Ziegeler skrev:
David Crossley wrote:
Hi Daniel, sorry i cannot understand that last sentence.
Would you please re-phrase it.
We currently have the three ways:
'forrest run'
Starts its packaged Jetty and uses Forrest/Cocoon as a webapp.
'forrest war'
Builds a projectName.war ready
David Crossley wrote:
> Hi Daniel, sorry i cannot understand that last sentence.
> Would you please re-phrase it.
>
> We currently have the three ways:
>
> 'forrest run'
> Starts its packaged Jetty and uses Forrest/Cocoon as a webapp.
>
> 'forrest war'
> Builds a projectName.war ready for deplo
On Thu, Feb 02, 2006 Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
> >Daniel Fagerstrom wrote:
> >>AFAIK you can't call filters and listeners from within servlets, so they
> >>are at the servlet container level, and I don't see how a block would
> >>need them. A block could certainly need so
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
AFAIK you can't call filters and listeners from within servlets, so they
are at the servlet container level, and I don't see how a block would
need them. A block could certainly need something that a listener put in
a context attribute or that a
Reinhard Poetz skrev:
Daniel Fagerstrom wrote:
Upayavira skrev:
Daniel Fagerstrom wrote:
Upayavira wrote:
...
We can also release with non OSGi blocks. The blocks are ongoing work,
the most important thing that lacks is "two level configuration". As
discussed before the component configur
Sylvain Wallez wrote:
> Sorry, but I still fail to see how this changes anything. It makes it
> easier to develop with Cocoon as using the standard servlet API rather
> than with a "proprietary clone" eases the learning process and
> facilitates the integration with 3rd-party libraries. But does
Daniel Fagerstrom wrote:
>> For me these things make more sense for a higher
>> version than 2.2. I would love to get 2.2 out today with the main
>> changes being ECM++ and the Maven build.
>
> I'm not so certain about this anymore as you can see in my answer to
> Upayavira. But go ahead and writ
Daniel Fagerstrom wrote:
>
> AFAIK you can't call filters and listeners from within servlets, so they
> are at the servlet container level, and I don't see how a block would
> need them. A block could certainly need something that a listener put in
> a context attribute or that a filter did to
Daniel Fagerstrom wrote:
Upayavira skrev:
Daniel Fagerstrom wrote:
Upayavira wrote:
...
It starts to look like a 3.0 rather than a 2.2 and my personal goal is
to implement the whole blocks design including OSGi. OTH I try to not
hinder the possibility for a 2.2 release, given that someone
Sylvain Wallez skrev:
Daniel Fagerstrom wrote:
Sylvain Wallez skrev:
...
Now Cocoon is much more than a web framework, as we discussed in the
"necessary mutation" thread:
- a servlet
- a component container
- a controller
- a pipeline engine
- many blocks built on top of one of the above.
The
Carsten Ziegeler skrev:
Sylvain Wallez wrote:
Hmm... Not sure if I misunderstood or not. I'm ok to have a CLI-based
implementation of the servlet API, but having the Cocoon CLI launching
an internal Jetty for this really seems wrong to me. Forrest is already
a large beast, now if you say that
Daniel Fagerstrom wrote:
Sylvain Wallez skrev:
...
Now Cocoon is much more than a web framework, as we discussed in the
"necessary mutation" thread:
- a servlet
- a component container
- a controller
- a pipeline engine
- many blocks built on top of one of the above.
The CocoonBean used by the
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Hmm... Not sure if I misunderstood or not. I'm ok to have a CLI-based
implementation of the servlet API, but having the Cocoon CLI launching
an internal Jetty for this really seems wrong to me. Forrest is already
a large beast, now if you say th
Sylvain Wallez skrev:
...
Now Cocoon is much more than a web framework, as we discussed in the
"necessary mutation" thread:
- a servlet
- a component container
- a controller
- a pipeline engine
- many blocks built on top of one of the above.
The CocoonBean used by the CLI is actually parallel
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
Agree, but as people (you included) had valid reasons for not going that
far in 2.2, I suggest something less radical this time, as I want to get
rid of the problem of calling servlets from within Cocoon already in 2.2.
Yes, true, I had reason
Upayavira skrev:
Daniel Fagerstrom wrote:
Upayavira wrote:
...
It starts to look like a 3.0 rather than a 2.2 and my personal goal is
to implement the whole blocks design including OSGi. OTH I try to not
hinder the possibility for a 2.2 release, given that someone is prepared
to spearhead it.
On 1/30/06, Carsten Ziegeler <[EMAIL PROTECTED]> wrote:
>
> Now, if I'm the only one thinking that removing the whole env
> abstraction makes sense, I'll shut up for now.
Nope. Makes perfect sense to me, please continue on this crusade.
--
Peter Hunsberger
Sylvain Wallez wrote:
>
> Hmm... Not sure if I misunderstood or not. I'm ok to have a CLI-based
> implementation of the servlet API, but having the Cocoon CLI launching
> an internal Jetty for this really seems wrong to me. Forrest is already
> a large beast, now if you say that generating a si
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Sorry, what do you mean by "web framework"? Isn't it already one? Or do
you mean "servlet"?
Cocoon is currently a mixture. It's mostly used as a web framework
through a servlet, but for example if you're using the cli you don't
have a web
Daniel Fagerstrom wrote:
> Agree, but as people (you included) had valid reasons for not going that
> far in 2.2, I suggest something less radical this time, as I want to get
> rid of the problem of calling servlets from within Cocoon already in 2.2.
Yes, true, I had reasons against doing radical
Sylvain Wallez wrote:
>
> Sorry, what do you mean by "web framework"? Isn't it already one? Or do
> you mean "servlet"?
>
Cocoon is currently a mixture. It's mostly used as a web framework
through a servlet, but for example if you're using the cli you don't
have a web framework or a web server o
Daniel Fagerstrom wrote:
> Upayavira wrote:
>
>> Daniel Fagerstrom wrote:
>>
>>
>>> Carsten Ziegeler skrev:
>>>
>
> ...
>
First, I'm still not sure if this should go into the current 2.2 code
base, but apart from that I now think we should even be more radical in
this area
Upayavira wrote:
Daniel Fagerstrom wrote:
Carsten Ziegeler skrev:
...
First, I'm still not sure if this should go into the current 2.2 code
base, but apart from that I now think we should even be more radical in
this area and remove the whole environment abstraction completly and
make
Daniel Fagerstrom wrote:
> Carsten Ziegeler skrev:
>
>> Daniel Fagerstrom wrote:
>>
>>> I suggested that we should ditch our environment abstraction and
>>> replace it with the javax.servlet.http set of interfaces, as one step
>>> in simplifying Cocoon in
>>> http://marc.theaimsgroup.com/?t=113432
Sylvain Wallez skrev:
...
AFAIU, what Daniel is proposing is to add an "extends" statement to our
environment interfaces, which are very close to the standard
javax.servlet ones. Just like we did with Cocoon's SourceResolver
extending Excalibur's SourceResolver.
Exactly
/Daniel
Carsten Ziegeler skrev:
Daniel Fagerstrom wrote:
I suggested that we should ditch our environment abstraction and replace
it with the javax.servlet.http set of interfaces, as one step in
simplifying Cocoon in
http://marc.theaimsgroup.com/?t=11343238821&r=1&w=2.
The result of the discussi
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
I suggested that we should ditch our environment abstraction and replace
it with the javax.servlet.http set of interfaces, as one step in
simplifying Cocoon in
http://marc.theaimsgroup.com/?t=11343238821&r=1&w=2.
The result of the discu
Daniel Fagerstrom wrote:
> I suggested that we should ditch our environment abstraction and replace
> it with the javax.servlet.http set of interfaces, as one step in
> simplifying Cocoon in
> http://marc.theaimsgroup.com/?t=11343238821&r=1&w=2.
>
> The result of the discussion was that the
I suggested that we should ditch our environment abstraction and replace
it with the javax.servlet.http set of interfaces, as one step in
simplifying Cocoon in
http://marc.theaimsgroup.com/?t=11343238821&r=1&w=2.
The result of the discussion was that there are some "extras" in our
interfa
47 matches
Mail list logo
