Test of the new mailinglists.
Carsten
to the new one, so receiving mails should work without any
problems. However, if you want to send a message to the
list, please consider the new names.
If you experience any problems, please let us now.
Carsten
Carsten Ziegeler
Open Source Group, SN AG
http://radio.weblogs.com/0107211/
David Crossley wrote:
I question why you want to use the new DTDs that are under development
at Forrest. In Cocoon we still use the document-v10 DTDs for all of the
xdocs. Do you really need the document-v1[12] DTDs or can you suffer the
current one?
Our doc writer did choose that :)
There
David Crossley wrote:
We also do some specific validation of certain core configuration
using RELAX NG and the Jing task. This works fine for validating
the cocoon.roles file (note it has an internal DTD subset). We were
also doing some experimental validation of other files, such as
David Crossley wrote:
Bugger. I was going to look into the Jing code because that would be the
ideal - make Jing use the xml-commons entity resolver. I see that there
is a newer Jing available - will investigate sometime.
Great ;)
Anyway, what do you think of the other issue - the idea of
David Crossley wrote:
- I think we should remove all
the doc handling from cocoon. By this I mean the subsitemap we currently
have that generates the docs on the fly in the built webapp. I
hope to move this to forrest as well.
I agree. However, what do you mean by move this to forrest?
Reinhard Pötz wrote:
The Cocoon object of the FOM has the method
Component getComponent(id)
It should return any component but no sitemap components. This means we
only return components defined in the roles file(s). How can we check if
it is an allowed component?
Any ideas?
I think
Geoff Howard wrote:
Do we want to force people to edit cocoon.xconf to call their own business
components from the flow? I thought Stefano proposed checking for
SitemapModelComponent and disallowing it? Would that prevent looking up
a transformer, but allow looking up a legitimate component
Hi,
I currently have a problem generating the cocoon site with forrest.
I get the following error:
---
* [0]
- [broken page] index.html -
No pipeline matched request: tab.xml
Total time: 0 minutes 5 seconds
I'm using latest forrest from cvs and I
Jeff Turner wrote:
Cocoon overrides the main Forrest sitemap
(src/documentation/sitemap.xmap), which means that every time the Forrest
CVS sitemaps change, the Cocoon one would need synching. To avoid this,
there is a 'stable' tag on Forrest, the theory being that Cocoon docs
should always
David Crossley wrote:
Why do we need DTDs to be included here? If they need to be in Cocoon
CVS, then shouldn't they be in WEB-INF/entities.
The validate-xdocs task validates all our documents and uses the
DTDs from the documentation directory. As the old document-10 dtd
was already there,
If noone is against it, I will request for moving the mailing-lists
tomorrow (before the beta release).
I think we have to move these mailinglists:
[EMAIL PROTECTED] - [EMAIL PROTECTED]
[EMAIL PROTECTED] - [EMAIL PROTECTED]
[EMAIL PROTECTED] - [EMAIL PROTECTED]
Did I forget anything?
Carsten
Stefano Mazzocchi wrote:
It is with real pleasure that I announce that three cocoon committers
were elected members of the ASF in the last round of votation
that ended
today.
Vadim, Sylvain and Carsten (in alphabetical order by their last names)
Hoping that they will accept the
Bertrand Delacretaz wrote:
Le Mardi, 24 juin 2003, à 08:31 Europe/Zurich, Carsten Ziegeler a écrit
:
If noone is against it, I will request for moving the mailing-lists
tomorrow (before the beta release).
Do you plan a document explaining the move and how to find the old and
new
David Crossley wrote:
Carsten Ziegeler wrote:
Bertrand Delacretaz wrote:
snip/
Do you plan a document explaining the move and how to find the old and
new archives?
No :( - to be honest, I haven't thought about the archives. I thought
that the archives would be somehow moved
Nicola Ken Barozzi wrote:
Jeff Turner wrote, On 24/06/2003 13.38:
As most of you probably saw, there's a thread on cocoon-dev suggesting
that Forrest ought to be a Cocoon subproject, with the
consensus being it
makes sense.
AFAICT the only practical difference would be that
Vadim Gritsenko wrote:
!-- blob pseudo protocol --
-protocol name=blob
class=org.apache.cocoon.components.source.impl.BlobSourceFactory/
+component-instance name=blob
class=org.apache.cocoon.components.source.impl.BlobSourceFactory/
Why this change? Anyways,
Hi Team,
where is 2.1beta1? - Well, due to some lack of time, I will
be doing the release either on friday or on monday - I actually
prefer monday as I don't like releasing something on fridays.
Anyway, also this sounds like a bad news (another delay), it's
actually a good one! This gives us
+1
Carsten
Reinhard Pötz wrote:
If I understand this correctly I get with
source.getValidity()
the SourceValidity.
Yes.
But if I call e.g. cocoon://blablalba.xml this
method returns null. The default pipe is the caching pipe
and I use it with
map:pipeline
...
/map:pipeline
If I resolve a
I would call it a bug :(
Carsten
-Original Message-
From: Klaus Bertram [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2003 4:48 PM
To: cocoon-dev
Subject: BUG or feature?
Hi all,
is it an bug or an feature that the whole javadocs for the block classes
are not created by
-Original Message-
From: Rob Johnston [mailto:[EMAIL PROTECTED]
Sent: Tuesday, June 17, 2003 8:11 PM
To: [EMAIL PROTECTED]
Subject: Why does moving the portal-fw from samples break it?
(PortalManager not found on 'save')
I've attempted to move the portal-fw sample from the
Jeff Turner wrote:
I'm not too sure of this commit. The problem is that
AbstractSAXTransformer's
debug-level logging is so verbose that it swamps the debug logs
of its children
with stuff like this:
DEBUG (/forrest/body-index.html): BEGIN endTransformingElement
uri=, name=link,
Thanks Sylvain and Nathaniel for the points, I added them to our updating
docu.
If you know some more incompatible changes, please either edit directly
the updating doc or send a simple patch.
Thanks
Carsten
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent:
So, from the response I guess we go for recompiling.
If someone is against this, please stand up now :)
Carsten
Nicola Ken Barozzi wrote:
Well, there is a way out, but I don't know if we want to do it. It's
based on - ok, I'll say that word - an AOP interceptor mechanism(hehehe
a big wording for a simple concept).
Basically, we would have to use our own classloader in the
ComponentManager, and make it
as we are
compatible on the source level)?
Carsten
Carsten Ziegeler
Open Source Group, SN AG
http://radio.weblogs.com/0107211/
Stefano Mazzocchi wrote:
2) small to big - give users the least possible freedom based on some
required functionality and grow as the users express their needs.
+1
Carsten
Andrew Savory wrote:
On Sat, 14 Jun 2003, Joerg Heinicke wrote:
[ ] Release Cocoon 2.1 /immediately/.
[+1 ] Release Cocoon 2.1 beta 1 /immediately/ (24th of June).
[ ] Release further milestones while implementing the FOM.
[+1 ] Release Cocoon 2.0.5 as soon as possible.
Carsten, I
Geoff Howard wrote:
At 02:20 AM 6/16/2003, you wrote:
Hi,
I think I found a showstopper for 2.1 :( :
2.1 is not binary compatible to 2.0.x - if you compile a (sitemap)
component using 2.0.x and put this into 2.1 it will in most cases
fail to run. As a simple example, you can use the
Stefano Mazzocchi wrote:
1) I will try to patch the FOM for the proposed plan for June 24th.
+1 :)
2) If I can't do it, we release with what we have and we state loud and
clear that the FOM contract should be considered unstable and that might
change in future releases.
What do you
Joerg Heinicke wrote:
So we only have one option: release Cocoon 2.1 as soon as possible :-)
Ok, there are some other options this vote is about:
[ ] Release Cocoon 2.1 /immediately/. Carsten suggested the 24th of
June as target date for a first beta release
Berin Loritsch wrote_
Fortress allows us to do a number of really cool things that are
not available in the ECM. One of them is to no longer require the
accursed Roles file. Adding new user components to Cocoon and
having the configuration able to use those components directly
is just as
on the 24th of June. (Then if
required one more beta and then final with two or three weeks inbetween).
What do you think?
Carsten
Carsten Ziegeler
Open Source Group, SN AG
http://radio.weblogs.com/0107211/
Upayavira
On 13 Jun 2003 at 8:35, Carsten Ziegeler wrote:
AFAIK, the only real thing missing for 2.1 is the FOM implementation.
The question is now, is someone already working on it resp. should we
wait for the release until it's finished?
What is actually required to fix the FOM
Stephan Michels wrote:
On Fri, 13 Jun 2003, Carsten Ziegeler wrote:
AFAIK, the only real thing missing for 2.1 is the FOM implementation.
The question is now, is someone already working on it resp. should
we wait for the release until it's finished?
I think we should set a date now
Upayavira wrote:
I think its refactoring and adding some functionality. As a starting
point you can look at this thread:
http://marc.theaimsgroup.com/?t=10540178951r=1w=2
I remember reading that. What I wanted to know is exactly how one
would go about
updating the FOM.
If all
Vadim Gritsenko wrote:
So my question is, why don't we use this implementation, to make Cocoon
more scalable? ;-)
You can. Have you tried it yet?
I guess what Volker means is adding your new implementation from the
scratchpad to excalibur store (btw, you have the commit rights for
What has to be done to update to the released excalibur
datasource 1.1?
Carsten
Carsten Ziegeler
Open Source Group, SN AG
http://radio.weblogs.com/0107211/
After updating to the latest cvs I get an infinite loop in the
new portal demo:
http://localhost:/samples/portal/portal
I guess this is caused by the recent changes to the source
resolving.
Any clues?
Carsten
Carsten Ziegeler
Open Source Group, SN AG
http://radio.weblogs.com/0107211/
Carsten Ziegeler wrote:
After updating to the latest cvs I get an infinite loop in the
new portal demo:
http://localhost:/samples/portal/portal
I guess this is caused by the recent changes to the source
resolving.
Any clues?
It seems that the current implementation of the source
Sylvain Wallez wrote:
What about using the two ;-)
1/ test if the URI is absolute. For this, you can use Excalibur's
SourceUtil.getScheme() which performs a strict control on scheme syntax
without using a regexp.
2/ if not, use the regexp only on the part before the '?' (BTW, if '?'
is
Bruno Dumon wrote:
On Tue, 2003-06-10 at 10:02, Carsten Ziegeler wrote:
Sylvain Wallez wrote:
What about using the two ;-)
1/ test if the URI is absolute. For this, you can use Excalibur's
SourceUtil.getScheme() which performs a strict control on
scheme syntax
without using
Bruno Dumon wrote:
Yep, after trying it out I saw it too.
Anybody working on this already? (or can I do it?)
No, I'm not :) so: go for it ;)
Carsten
Bruno Dumon wrote:
On Tue, 2003-06-10 at 11:16, Carsten Ziegeler wrote:
Bruno Dumon wrote:
Yep, after trying it out I saw it too.
Anybody working on this already? (or can I do it?)
No, I'm not :) so: go for it ;)
done :-)
Yes, it works now!
Thanks
Carsten
Joerg Heinicke wrote:
But there is another reason for this mail: Now with the current XSLTC we
can switch to it as default processor in 2.0 too, can't we?
I'm currently -1 on this because imho xsltc has not proven to be 100%
working and I think we should at least in 2.0.x have a fully
Joerg Heinicke wrote:
But it's obvious we have a more or less bad bug handling. Most of the
bugs are not even ASSIGNED, so nobody can really see if it's only a bug
report of a user or a confirmed bug. Why don't we accept or reject a bug
within a month at the latest.
And the patches? Why
Sylvain Wallez wrote:
I don't like all those static methods that hardcode more and more logic,
and even less when they lookup some components...
Why aren't these methods part of a CocoonResolver component that would
extend Excalibur's SourceResolver with some XML-related features ?
You
Bertrand Delacretaz wrote:
Le Mardi, 3 juin 2003, à 08:06 Europe/Zurich, Carsten Ziegeler a écrit :
...I think this is plain simple - as long as noone of the committers
has
time for it and has fun in doing so, nothing will happen
Yes, but I think Joerg has a point too: more comments
Antonio Gallardo wrote:
Le Mardi, 3 juin 2003, à 08:06 Europe/Zurich, Carsten Ziegeler a écrit :
...I think this is plain simple - as long as noone of the committers
has time for it and has fun in doing so, nothing will happen
Hi:
but we also must think in users that use his time
Sylvain Wallez wrote:
I don't know if this should be an independent component, or one that
extends the SourceResolver.
Ah ok, by independent component I meant a component that extends
perhaps the SourceResolver component from Avalon, but can still be
looked up using a component manager. So
Andreas Kuckartz wrote:
But what about a bug handling guideline?
Is there something similar for the Apache community in general?
This is what I think is needed - and can be a result of this thread.
I'm not against such a guideline and it might help in this case. So +1.
But even with
Bertrand Delacretaz wrote:
Le Mardi, 3 juin 2003, à 11:33 Europe/Zurich, Steven Noels a écrit :
...20138 [PATCH] AntBuildGenerator
- Bertrand? (I'm -0 on adding such hacks onto Cocoon, but anyhow)...
Dunno about hacks - an AntBuildGenerator block certainly triggers some
FS alarms here,
The safest way is to lookup/release a component every time you
need it, so the fragmentextractor uses the correct approach.
If you know that the component you want to use is ThreadSafe
and will always be ThreadSafe than you can optimize your code
and lookup the component only once - this
There is already such a component, the cinclude transformer uses this
for the caching. It should be easy to use that component in the
xinclude transformer as well.
PS: Could you please not include the PGP signature in your posts to
this list. It makes reading your mails very hard. Thanks.
Torsten Knodt wrote:
On Sunday 01 June 2003 15:51, Carsten Ziegeler wrote:
CZ The safest way is to lookup/release a component every time you
CZ need it, so the fragmentextractor uses the correct approach.
CZ If you know that the component you want to use is ThreadSafe
CZ and will always
Torsten Knodt wrote:
Yes, I know. But it'S still to much coding for it in the
CIncludeTransformer.
Components which need the content of a source, should simply get
it, and not
think about caching. It's not their job. Caching is needed in to
many places.
All places which use sources,
Vadim Gritsenko wrote:
Now, the optimization I was refering to can only take place *if* you
know which implementation for a component is really used and *if*
this specific implementation is ThreadSafe. This is a dangerous
assumption! If you assume a component is implemented in a thread safe
Stefano Mazzocchi wrote:
Cool. Sounds like many people are liking this ideas.
But let's defer this for post-2.1 when I will have more sitemap-based RT
to throw in.
This makes me a little bit curious :) - but, yes it's for post-2.1
Carsten
AFAIK, the only open issue for making a beta is the FOM, right?
I would suggest, that we make a milestone three on the 10th of
June unless the FOM API is stable. If it's stable by then,
we could make a beta 1 then.
What do you think?
Carsten
Carsten Ziegeler
Open Source Group, SN AG
http
Stefano Mazzocchi wrote:
I mean, when something is in there for ages and noone maintains it
or uses it, it is pretty useless. What do you think?
yes and no. i would think that leaving stuff on the scratchpad doesn't
really hurt anybody. I would suggest, instead, to keep it as a
scratchpad
+1 for the FOM as discussed for now.
Ok, this is a little bit OT, but I have to respond :)
Stefano Mazzocchi wrote:
map:serializer name=xhtml
map:transformer type=link-translation/
map:serializer type=xhtml/
map:serializer
map:match pattern=...
map:generate src=.../
Stefano Mazzocchi wrote:
Here is what I propose to move:
1) ImageReader
2) Paginator
3) JXTemplate*
+1
anything else?
Do we have any policy when to blast things from the scratchpad,
I mean, when something is in there for ages and noone maintains it
or uses it, it is pretty useless.
Sylvain Wallez wrote:
Ah, I understand. Clever solution.
But once again, I prefer to avoid automagic implicit behaviour of the
sitemap engine, and encourage people to migrate to writing a
map:generate in their error handling and consider implicit generator
and 'type' attributes on
Which version of Cocoon do you use?
Carsten
-Original Message-
From: Leszek Gawron [mailto:[EMAIL PROTECTED]
Sent: Tuesday, April 01, 2003 4:59 PM
To: [EMAIL PROTECTED]
Subject: global sitemap variables bug.
What I found may be a bug in {global:XXX} input module
First the
+1
Carsten
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
RT-starts/
This revives an idea I had a long time ago when writing the
treeprocessor : parent-aware components.
The elements in the map:component part of the sitemap are
ComponentSelectors (CS) with a special behaviour :
Great! I wanted to propose exactly the same next week,
you must read my mind sometimes :)
So, a big +1 for only a source dist.
Carsten
-Original Message-
From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 23, 2003 3:25 PM
To: Apache Cocoon
Subject: [proposal] a
+1
Carsten
-Original Message-
From: Diana Shannon [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 23, 2003 4:08 PM
To: [EMAIL PROTECTED]
Subject: Re: [vote] Geoff Howard as Cocoon committer
On Sunday, March 23, 2003, at 08:55 AM, David Crossley wrote:
I propose Geoff
+1
Carsten
-Original Message-
From: Diana Shannon [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 23, 2003 11:21 PM
To: [EMAIL PROTECTED]
Subject: Re: [vote] Andrew Savory as Cocoon committer
On Sunday, March 23, 2003, at 08:22 AM, David Crossley wrote:
I propose Andrew
Hi,
is it possible to setup a PMC mailing list, like other projects already did.
So we could - if the need arises - discuss PMC topics in privat?
(Don't get worried, I currently do have no need for it)
Carsten
Carsten Ziegeler
Open Source Group, SN AG
http://radio.weblogs.com/0107211/
Hi Stephan,
you don't have to ask for changes (if they make sense). I don't
own the code :)
So, making the code more understandable is good.
From: Stephan Michels [mailto:[EMAIL PROTECTED]
can I move the part where you generate the validity objects
into a separate method, like
Stephan Michels wrote:
Hmm, I'll think that I'm not the only one, who went into the trap. You're
right returning a null validity hurts the contract, this will cause an
exception. But a NPE in isValid() doesn't help searching the problem.
Yes, but adding it in add().
Carsten
Torsten Curdt wrote:
Hurray!
By using composition rather than inherritance I removed the
the dependency to the jvm. No split code anymore :)
Thanks for pointing me on that Berin.
Everything *should* work as before. And at least on
my machine the samples are working.
Please test!
Carsten Ziegeler wrote:
Could please everyone add (his) open issues for a 2.1b1 release
to the todo.docs? So, we have one single source of information.
Has everyone updated the todo.xml? Is anything missing?
Carsten
Sylvain Wallez wrote:
But won't work :-(
:)
Why ? Well, yes, a sitemap element = a builder class. But the
configuration file that defines them is used to feed a
ComponentSelector, which will try to load the class and the result is
that you will get an Exception in the initialization phase
, if the
required builder class is not available.
The flow would still be configured in the tree processor configuration
and I can leave out everything of the flow stuff if I don't need it.
And in addition: the dummy implementation can give meaningful error
messages.
What do you think?
Carsten
Carsten
Vadim Gritsenko wrote:
One word: CacheableProcessingComponent. IIRC, cache was aware of
cacheable serializers some time ago. The only missing piece is to add
SitemapModelComponent support for Serializers.
Yes, the caching algorithm queries serializers if they support caching
since more
Could please everyone add (his) open issues for a 2.1b1 release
to the todo.docs? So, we have one single source of information.
Thanks
Carsten
Carsten Ziegeler
Open Source Group, SN AG
http://radio.weblogs.com/0107211/
Unico Hommes wrote:
OK. I think I'll wait for SourceResolving to have solidified into
a proper release.
The source resolving should be solidifed now; I don't expect any
changes before a release of the sourceresolving package
which will happen sometime soon.
Carsten
Carsten Ziegeler
Open
From: Pier Fumagalli [mailto:[EMAIL PROTECTED]
Carsten Ziegeler [EMAIL PROTECTED] wrote:
Could please everyone add (his) open issues for a 2.1b1 release
to the todo.docs? So, we have one single source of information.
b implies beta... We go straight to beta without an alpha
Stefano Mazzocchi wrote:
Why can't se simply postpone module-creation this after 2.1? I don't
think it's worth delaying further for a simple 50kb less of cocoon.jar
I agreed that we move this issue into 2.2 or whatever and that this
should not delay 2.1 - so for me, it's pretty clear that
Vadim Gritsenko wrote:
Stefano Mazzocchi wrote:
Vadim Gritsenko wrote:
It's already not easy to separate! I can think of how to resolve
issue 1 (dedicated FlowObjectModelHelper: ugly, but works)
yuck!
So, what do we do? Carsten, may I have your blessing for adding helper
Jeremy Quinn wrote:
You will find a excalibur-xmlutils jar with the date of today 20030317.
If you have this jar, then you're upto date.
My fresh checkout has given me 'excalibur-xmlutil-20030313.jar' so this
may be where the problem lies.
Strange. It seems that Eclipse 2.1RC2 has the
Jeremy Quinn wrote:
On Monday, March 17, 2003, at 07:33 AM, Carsten Ziegeler wrote:
Hi Jeremy,
can you please turn on debug logging and post what the new
resolver logs on startup?
Hi Carsten,
I made this change in web.xml :
init-param
param-namelog-level/param
Stefano Mazzocchi wrote:
For 2.1 we have some additional points in our todo list in cvs
that have to be solved before a final release.
Bring them on.
From the todo.xml (perhaps some of them are obsolete; perhaps some are not
so
important):
action context=code assigned-to=CZ
Redesign
Jeremy Quinn wrote
Sorry, I was a little bit unprecise. You have to set the loglevel in
the
logkit.xconf - change the setting for core and for manager from ERROR
to DEBUG. You will find the messages in the core.log.
OK, hope this helps . no hits, just the startup.
Yes, that's
Jeremy Quinn wrote:
I just did a fresh update (to the version that made the log I just sent
you), but this was all I got :
P blocks.properties
P build.xml
P src/scratchpad/webapp/samples/imagereader/sitemap.xmap
So either I am up to date WRT this particular code, or I have a
Hi Jeremy,
can you please turn on debug logging and post what the new
resolver logs on startup?
Carsten
-Original Message-
From: Jeremy Quinn [mailto:[EMAIL PROTECTED]
Sent: Friday, March 14, 2003 5:45 PM
To: [EMAIL PROTECTED]
Subject: Re: Finishing Deprecation Package
On
Stefano Mazzocchi wrote:
SNIP/
So, perhaps Sylvain has a clever idea on how to implement this in the
treeprocessor.
I think that using xconftool is enough.
Yes, after thinking about it, for now we even don't need the xconftool
but a clever exception handling/message.
(Sylvain, correct
Stefano Mazzocchi wrote:
Oh, that's no problem for me.
Carsten, you propsed the move: what's your feeling about this?
Ok, I think moving actions and xsp is not necessary as they
were included in 2.0 already anyway.
2.1 is the first release with flow, so moving this into a block
before it's
Vadim Gritsenko wrote:
Excellent! I've grepped sources, seen those awful
((Environment)resolver) type casts, and I think that we have to get rid
of this ASAP.
We need to remove the type casts. Yes!
Practical proposal:
* Add flow-continuation to the objectModel, and getter method to
David Crossley wrote:
Now, there is something wrong with this approach. We can easily
change (which should be the 'correct' solution) that a path
starting with / is treated as an absolute path. So
if you want to load from the context directory, you have
to specify WEB-INF/.. instead of
I just did a fix for absolute paths on windows. All your
tests work for me on w2k.
Carsten
Nicola Ken Barozzi wrote:
Well, the fact is that some parts reference the CocoonServlet, and the
StreamGenerator is usable only on Servlets! Ok, this has already been
discussed, so I think we should get to a conclusion here.
Proposal:
1) move all environments in separate
Stefano Mazzocchi wrote:
These RT propose two things:
1) move out flow as a block
2) make the sitemap syntax pluggable
Yes, but I see 1) as a need and would be happy about 2).
- people use cocoon in a non-servlet environment and would like to see
all servlet hooks removed
Yes.
Stefano Mazzocchi wrote:
But: during the last two years, from time to time I had the need
to extend the sitemap syntax, because that would have made some things
much more easier. As it was not possible, we used some other methods
like actions etc.
Having a solid contracts doesn't mean we
version.
So, is anyone against changing from 1.2 to 1.3? If not,
I will change the docs etc. tomorrow.
Carsten
Carsten Ziegeler
Open Source Group, SN AG
dangers, so this
is only a thought.
Anyway, regardless how it is solved, I would like to have the flow
separated into a block.
What do you think?
Carsten
Carsten Ziegeler
Open Source Group, SN AG
Hi Sylvain,
please use the latest version of 2-1 as it's very difficult (if not
impossible) to reproduce your problem. The cvs repositories changed etc.
Please try it again with the latest cvs and I can then see how to help
you.
Carsten
Carsten Ziegeler
Open Source Group, SN AG
Sylvain Wallez wrote:
I'm thinking since last year about making the sitemap syntax pluggable,
so the basic idea is to install an own block that adds more syntax and
features to the sitemap. With that implemented, it would be easy
to make flow an own block.
I remember a discussion about
1 - 100 of 1387 matches
Mail list logo
