Vadim Gritsenko wrote:
>
> If you think about it, views do not have any parameters
> passed to them.
> As a result, all resources which view uses are defined within
> view itself, within sitemap where is is defined, so all view
> resources must be resolved relative to the sitemap where view
Sylvain Wallez wrote:
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
...and how will relative sources be resolved in an inherited view
called from a VSC defined in a parent sitemap?
:-D
or maybe it should be :-(
If you think about it, views do not have any parameters passed to
them. As a result
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
...and how will relative sources be resolved in an inherited view
called from a VSC defined in a parent sitemap?
:-D
or maybe it should be :-(
If you think about it, views do not have any parameters passed to
them. As a result, all resources which
Vadim Gritsenko wrote:
Carsten Ziegeler wrote:
Imagine a VSC using a view is used in a sub sitemap :)
Can't... Can you explain how VSC can use a view? No component
currently is able to use a view, IIUC.
Ok, I used the wrong wording : it should be "a VSC defined in a parent
sitemap has a label t
Carsten Ziegeler wrote:
...and how will relative sources be resolved in an inherited
view called from a VSC defined in a parent sitemap?
:-D
or maybe it should be :-(
If you think about it, views do not have any parameters passed to them.
As a result, all resources which view uses are defined wi
Carsten Ziegeler wrote:
Imagine a VSC using a view is used in a sub sitemap :)
Can't... Can you explain how VSC can use a view? No component currently
is able to use a view, IIUC.
Or, do you mean, VSC containing view labels? Labels are passive by
themselves so there is no problem with that - vie
Carsten Ziegeler wrote:
...and how will relative sources be resolved in an inherited
view called from a VSC defined in a parent sitemap?
:-D
or maybe it should be :-(
:) ..eh.. :(
I think more and more that this VSC concept is way too complex. If
we have such a problem to find a good solutio
> >Sure. I suggested this a long time ago (and I think I wasn't
> the only
> >one).
> >*If* we implement virtual sitemap components we need
> inheritable views
> >anyway. Imagine a VSC using a view is used in a sub sitemap :)
> >
> >
>
> ...and how will relative sources be resolved in an inh
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
M2:
- Virtual Sitemap Components
M3:
- Inheritable Views (hmm, where this came from?)
I remember a few discussions. Maybe Carsten can help here.
Sure. I suggested this a long time ago (and I think I wasn't the
only one).
*If* we implement
Reinhard Poetz wrote:
> > M2:
> > - Virtual Sitemap Components
> > M3:
> > - Inheritable Views (hmm, where this came from?)
>
>
> I remember a few discussions. Maybe Carsten can help here.
>
Sure. I suggested this a long time ago (and I think I wasn't the
only one).
*If* we implement virtual s
Sylvain Wallez wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
I also want to split up Cocoon as discussed by Unico and me a few
weeks ago
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109025350512527&w=2)
Are you preparing a list of classes which would go to spi /
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
I also want to split up Cocoon as discussed by Unico and me a few
weeks ago
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109025350512527&w=2)
Are you preparing a list of classes which would go to spi / api / common
(core) /
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
I also want to split up Cocoon as discussed by Unico and me a few
weeks ago
(http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109025350512527&w=2)
Are you preparing a list of classes which would go to spi / api / common
(core) / internal? Or you want
Reinhard Poetz wrote:
I also want to split up Cocoon as discussed by Unico and me a few weeks
ago (http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=109025350512527&w=2)
Are you preparing a list of classes which would go to spi / api / common
(core) / internal? Or you want to prepare the list after
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
>>>
What is a realistic date for the final release? December _this_
year? Then we could have M2 in October, RC1 by the end of November
and if necessary a RC2 before the final 2.2 release.
WDOT?
Not sure a
Reinhard Poetz wrote:
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
>>>
What is a realistic date for the final release? December _this_ year?
Then we could have M2 in October, RC1 by the end of November and if
necessary a RC2 before the final 2.2 release.
WDOT?
Not sure about others, but it seem
Vadim Gritsenko wrote:
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
We have started to discuss the roadmap for 2.2 some time ago and the
starting point is in this document:
/cocoon/src/documentation/xdocs/plan/roadmap.xml
Found also:
http://cocoon.apache.org/2.1/plan/release.html
http://coc
Reinhard Poetz wrote:
Carsten Ziegeler wrote:
We have started to discuss the roadmap for 2.2 some time ago and the
starting point is in this document:
/cocoon/src/documentation/xdocs/plan/roadmap.xml
Found also:
http://cocoon.apache.org/2.1/plan/release.html
http://cocoon.apache.org/2.1/plan/
Ugo Cei wrote:
> Il giorno 02/ago/04, alle 09:19, Carsten Ziegeler ha scritto:
>
> > But I think we shouldn't forget about 2.1.6; merging all
> the nice bug
> > fixes we already have in 2.2 into 2.1.x is imho currently as
> > important.
>
> We could dedicate the next FirstFriday (Aug. 6th) t
Il giorno 02/ago/04, alle 09:19, Carsten Ziegeler ha scritto:
But I think we shouldn't forget about 2.1.6; merging all the nice
bug fixes we already have in 2.2 into 2.1.x is imho currently
as important.
We could dedicate the next FirstFriday (Aug. 6th) to it. WDYT?
--
Ugo Cei - http://beblogging.c
Reinhard Poetz wrote:
>
> Thank you.
> The document doesn't contain a scheduled release date for M1.
> I know it's difficult to say when which parts will be ready.
> But if we committers say which parts we are working on and
> when things will be ready we get a sense for a timeline.
>
Yes.
Carsten Ziegeler wrote:
Reinhard Poetz wrote:
After agreeing on the things that we want to become part of
Cocoon 2.2, we should define milestones so that our users
have an idea where we want to go and when we think we will arive.
Thoughts?
We have started to discuss the roadmap for 2.2 s
Reinhard Poetz wrote:
> After agreeing on the things that we want to become part of
> Cocoon 2.2, we should define milestones so that our users
> have an idea where we want to go and when we think we will arive.
>
> Thoughts?
>
We have started to discuss the roadmap for 2.2 some time ago and
23 matches
Mail list logo
