upayavira2003/07/01 22:03:52
Modified:src/documentation/xdocs/userdocs/concepts book.xml
modules.xml
Added: src/documentation/xdocs/userdocs/concepts redirection.xml
Log:
Added docs on redirection
Fixed typo in modules doc
Please review this
se IMO.
Thanks. Just wanted to check.
Regards, Upayavira
in
building the pipeline.
Can you guarantee that cocoon.process() will not complete until both sub-pipelines
have completed their work?
I'll take a bit of a look into the pipeline building code (if I can find it) to see
what I can
work out.
This approach excites me. With help, I'd like to see if I can make it happen.
Regards, Upayavira
, do you really want to expose your stylesheets to the public, which you're doing
if you use HTTP?!?!? )
Regards, Upayavira
On 1 Jul 2003 at 17:41, Olivier Billard wrote:
> Thanks (again :) !) Sylvain !
>
> It seems that you're right...
> The effect is still n
upayavira2003/07/01 05:37:48
Modified:src/documentation/xdocs/userdocs/concepts persistence.xml
Log:
Fixing broken link in CVS, reported as Bug 21218 by cgaffga at triplemind.com.
Does the site now need to be rebuilt?
Upayavira
Revision ChangesPath
1.2 +1
hen restored, all
transparently?
So you would have to consciously code your components to use either of these
interfaces, otherwise you'll have to manually release them before creating a
continuation.
Upayavira
le to do this today with other components and
> skillful pipeline writing? For doing it at the beginning or at the end
> of a request it's possible to have an entry-point pieline that has pre
> and post processing, but to add stuff *inside* other pipelines? I
> think it cannot be done today.
I'm afraid you left me completely behind there. I've not really yet understood what
AOP is, and your ideas go far further than my Cocoon implementation skills currently
allow.
I'd quite like to find something that can be implemented reasonably short term, and
then explore these more far-reaching ideas as time passes (and as the size and
capacity of my brain increases).
Are you guys interested for the time being in a LinkGatheringTransformer as
described above? Or is there something not too far away that we can do now to
gather links?
Regards, Upayavira
On 29 Jun 2003 at 8:40, [EMAIL PROTECTED] wrote:
...
> Revert the previous revision. It is the concern of the stylesheets
> to show the release status.
...
> -
> +
Should this be @[EMAIL PROTECTED]
Regards, Upayavira
rent link
gatherer) and one which consumes a links namespace (which allows complete
control over your followed links, just like the links view), I think we've got the
best of
both worlds. An empty bath with a baby in it :-)
Regards, Upayavira
g, and the latter providing a method to do complex
link
management.
Another question - do we still leave link view (two pass) link following in the CLI?
Or
does this method deprecate and thus replace it?
Thanks for engaging with me on this - I appreciate it.
Regards, Upayavira
On 28 Jun 2003 at 18:45, Jeff Turner wrote:
> On Sat, Jun 28, 2003 at 07:29:49AM +0100, Upayavira wrote:
> > On 28 Jun 2003 at 11:59, Jeff Turner wrote:
> ...
> > Okay. For the CLI, the cli.xconf file is the equivalent of the
> > web.xml and the user agent.
> >
&g
d namespace.
> I hope I've convinced you :) Certainly for simpler needs, hardcoding
> a LinkGathererTransformer is fine, but in general (and I hope where
> Forrest is going) we need the full power of a link view.
I've always been convinced - just don't like the double pass.
Regards, Upayavira
I think there's a place for both, but I'd like to get it
upayavira2003/06/27 11:31:42
Modified:src/java/org/apache/cocoon Main.java
Log:
Fixing imports
Revision ChangesPath
1.9 +8 -2 cocoon-2.1/src/java/org/apache/cocoon/Main.java
Index: Main.java
upayavira2003/06/27 08:10:03
Modified:src/webapp sitemap.xmap
Log:
Adding status codes to element
Revision ChangesPath
1.23 +4 -2 cocoon-2.1/src/webapp/sitemap.xmap
Index: sitemap.xmap
gt; > > exactly what should happen when a broken link is found.
> > Here's the
> > > > interface as it is at the moment:
> > > >
> > > > public interface BeanListener {
> > > > public void pageGenerated(String uri, int linksInPage, int
> > > > pagesRemaining);
> > > > public void messageGenerated(String msg);
> > > > public void warningGenerated(String uri, String warning);
> > > > public void brokenLinkFound(String uri, String message); }
> > >
> > > Ah good, this also works towards making CocoonBean thread
> > safe. I like
> > > it.
> >
> > I'm glad. It doesn't yet work, but I'll commit it when it does.
It is now committed. Do take a look (and let me know of any problems).
Regards, Upayavira
upayavira2003/06/27 06:50:38
Modified:src/java/org/apache/cocoon Main.java
src/java/org/apache/cocoon/bean CocoonBean.java
Added: src/java/org/apache/cocoon/bean BeanListener.java
Log:
Added 'BeanListener' interface for CocoonBean to report back
enough to add error codes (404 and 500) to the block in the built webapp's sitemap? Seems kinda obvious thing to do to
me.
Regards, Upayavira
e exactly what should happen
> > when a broken link is found. Here's the interface as it is at
> > the moment:
> >
> > public interface BeanListener {
> > public void pageGenerated(String uri, int linksInPage,
> > int pagesRemaining);
> > public void messageGenerated(String msg);
> > public void warningGenerated(String uri, String warning);
> > public void brokenLinkFound(String uri, String message); }
>
> Ah good, this also works towards making CocoonBean thread safe. I like
> it.
I'm glad. It doesn't yet work, but I'll commit it when it does.
> > I look forward to your initialisation patch.
>
> It may take some time.
That's fine, my stuff may well take time too.
Regards, Upayavira
rrest doesn't yet use the xconf functionality in the CLI, so won't be able
to
do this yet.
I hope I'm making sense and that I'm not completely off-beam.
Regards, Upayavira
on the database that takes a long to generate.
My aim is to serve the poor (!), if you handle the content-intensive sites, we'll
cover a
lot of bases!
> UH> > Great! We could eventually also supply a way to delete remote
> UH> > resources when they no longer exist locally.
>
> Applause!
That and not generating cached pages would be cool.
Regards, Upayavira
e moved the broken link reporting into Main, so that the bean simply
reports a broken link, leaving it to the user to decide exactly what should happen
when a broken link is found. Here's the interface as it is at the moment:
public interface BeanListener {
public void pageGenerated(String uri, int linksInPage, int pagesRemaining);
public void messageGenerated(String msg);
public void warningGenerated(String uri, String warning);
public void brokenLinkFound(String uri, String message);
}
I look forward to your initialisation patch.
Regards, Upayavira
CLI.
>
> To enable this method, users just need to do this:
>
> - go in the dist/shbat dir
> - edit forrest.build.xml
> - insert the following line in the Cocoon args:
>
Or start using the cli.xconf file - it'll give finer grained control as the CLI
improves.
Regards, Upayavira
tead of one. Isn't the correct solution to fix caching so that 99%
> of the processing between foo.html and foo.html?cocoon-view=links is
> shared? If caching worked properly, why would requesting the link
> view take much more time?
Alternatively we could try Vadim's comment on using a CachingPoint pipeline.
Thoughts?
Upayavira
fe method to
> do the main job -- serve requests.
That is the sort of thing that Unico is talking about adding. It isn't there at the
moment,
but should be usable in that way, really.
Regards, Upayavira
f designing it, it
stands
the chance to become a key part of Cocoon. I've got a Cocoon based site that is
basically static, but makes use of Cocoon caching. But even that is overkill. Why not
just upload the site to the server and run the publish service? Or run the publish
service locally and have the publish service upload it for you. To an FTP server, to a
CVS server, to a...
Then all you need is Cocoon, or Apache, to serve static content.
(I've got some code (that doesn't yet work) that'll make the bean only generate pages
that haven't changed. That'd make the publishing service even more powerful if we
can get it working).
Keep this coming, I'm enjoying this...
Regards, Upayavira
upayavira2003/06/25 00:40:22
Modified:.status.xml
Log:
Added CVS tag and added completed action for permanent redirects
Revision ChangesPath
1.62 +5 -0 cocoon-2.1/status.xml
Index: status.xml
upayavira2003/06/24 08:20:29
Modified:src/java/org/apache/cocoon/components/treeprocessor/sitemap
RedirectToNodeBuilder.java RedirectToURINode.java
src/java/org/apache/cocoon/environment
ForwardRedirector.java
the Cocoon instances we were discussing before. On the other hand,
> http being a request-response type of affair, the browser response is
> not well defined. There's also the additional complexity added to the
> core of Cocoon.
To my mind, the browser response in such a situation is a report saying whether or
not the generation of pages was successful.
I would say there's two sides to the approach I would recommend: small steps, and
keep it compatible where possible. Let's identify small ways we can get the
functionality we want, whilst respecting the interfaces that others are quite possibly
using. So, what first small steps would assist you in your work?
Regards, Upayavira
not_ cache the new page. So 302's put an
extra load on the server and all elements downstream of it as the pages are not
cached.
And that's why 301s are better if the page has moved permanently, but 302s
are fine for a temporary change.
Thanks, Upayavira
h my observation, just say so and I'll
> withdraw to my cave. ;-)
Just to clarify - Stefano was only suggesting removing input/output modules from
FOM, not Cocoon or the sitemap (where they are appropriate).
Do your comments still stand?
Regards, Upayavira
x27;ve added info to the wiki
> > (wiki.cocoondev.org/Wiki.jsp?page=CommandLine), see section
> > 7, that explains them a bit more.
>
> Ah that is a very helpful page. The Target class definitely seems to
> cover my use case.
Great. Glad to hear my ideas work for you!
Regards, Upayavira
Chris,
Fantastic! What a productive evening! It's good to know where this revised FOM is,
should I find anything that's not right. I'll try to switch my flow apps over to it
and get
trying it out.
Regards, Upayavira
On 20 Jun 2003 at 1:42, Christopher Oliver wrote:
> I
ector' interface,
perhaps adding a sendPermanentRedirect() method. But then there's quite a lot of
code that would need to be changed - i.e. all of the classes that implement
Redirector.
Any thoughts? Would it be useful?
Regards, Upayavira
ould be done on the bean iteself to extend
> > its functionality - and this would make it more useful to
> > Bean and to CLI users alike.
Have you looked at the Target class? Does it seem helpful? I've added info to the wiki
(wiki.cocoondev.org/Wiki.jsp?page=CommandLine), see section 7, that explains
them a bit more.
> I'm glad to help!
Great.
Upayavira
t could be done on the bean iteself to extend its functionality - and
this would make it more useful to Bean and to CLI users alike.
I'd love to have someone helping me on it!
Regards, Upayavira
from Avalon and use it to write to the maillet's
> > own output stream.
> >
> > Make sense?
>
> Yes that was about what I had in mind. I'll prepare a patch as soon as
> I have something and commit it to bugzilla.
Great.
Upayavira
Make sense?
Regards, Upayavira
On 18 Jun 2003 at 11:41, Unico Hommes wrote:
> Hi all,
>
> I'd like to override getCocoon method in CocoonServlet in order to
> allow another subsystem than the servlet create and manage Cocoon.
> This so that the same Cocoon instance can be shared amon
Stefano,
Can you say how you plan to build this FOM? You've specified what is needed, but
not _how_ you think it should be done.
Is it possible that others could help, and thus get it done quicker? Especially if you
say
how it should be done.
Regards, Upayavira
On 16 Jun 2003 at
I had this problem when using Cocoon from within IntelliJ Idea and JDK 1.3. I can
confirm that this has fixed it.
Well done for fixing this. I can now debug in 1.3 again!
Regards, Upayavira
On 16 Jun 2003 at 9:07, Rob Johnston wrote:
> On Mon, 16 Jun 2003, Stephan Michels wr
eters?
I've never used it, but I believe you can do {request:queryString} or something like
that to get the query string out of the request object. Then you do something like
Now I've not tested that, nor used it, so I don't know if I've got my names right or
wrong, but the principle is there.
Regards, Upayavira
upayavira2003/06/16 03:44:54
Modified:src/webapp/samples/hello-world samples.xml sitemap.xmap
Added: src/webapp/samples/hello-world/content hello_zip.xml
Log:
Added zip sample to hello world samples
Revision ChangesPath
1.9 +5 -1 cocoon-2.1/src/webapp
processed as a request for dialog/login
> and all subsequent URLs he gets will start with dialog/
>
> Many different request parameters can be sent to the login page.
You can do:
Does that help you?
Upayavira
On cocoon-users, Matthias Stoeckel has just submitted a patch to add a zip
sample to the 'hello world samples'. Is it reasonable enough for me to add it?
Thanks, Upayavira
> OK, thanks. Now what I need is a way to do forwarding.
> I started looking at using some other framework because of this.
How does forwarding differ from redirection?
What specifically are you trying to achieve?
Upayavira
used), then that's not so hard.
But how about when we need to restrict access to a method in the FOM that we want
to be accessible in the class otherwise?
Has anyone worked out how this might be done?
Upayavira
upayavira2003/06/13 05:05:54
Modified:src/webapp/stylesheets/system error2html.xslt
Log:
Correcting broken FAQ link
Revision ChangesPath
1.7 +1 -1 cocoon-2.1/src/webapp/stylesheets/system/error2html.xslt
Index: error2html.xslt
. (Then if
> required one more beta and then final with two or three weeks
> inbetween).
Sounds almost necessary! Having the milestones has enabled me to start using 2.1,
for live sites, and it works fine. Having beta, then release will have the same effect
for
more people.
Regards, Upayavira
upayavira2003/06/12 06:23:58
Modified:src/documentation/xdocs/userdocs/selectors
requestparameter-selector.xml
Log:
Fixing minor typos
Revision ChangesPath
1.2 +3 -3
cocoon-2.1/src/documentation/xdocs/userdocs/selectors
I can add here is that, in Tomcat on Windows, Cocoon works with JDK 1.3 and
1.4. However, when debugging in Intelli-J IDEA, it only works with 1.4. 1.3 gives this
same NoSuchMethodError. I've just worked around it myself by switching to 1.4, but
this is a luxury not everyone will have.
Upayavira
t.
How do I make the LinkGatherer have minimal impact upon caching? Can I set it
to 'ignore this component', or have I done the right thing by setting it to always
return VALID. Is it okay that getKey() always returns the same thing (i.e. the string
"valid")?
Thanks in advance,
Upayavira
> I found we can download Linotype by getting the url correct;-)
> http://www.betaversion.org/~stefano/software/linotype/linotype_1.0.tar
> .gz
>
> or start at http://www.betaversion.org/~stefano/ and click on Software
> and then Linotype.
Ah! Splendid!
Thanks, Upayavira
you want me to show you how? :)
Go for it!
Upayavira
now, and change the
references?
Upayavira
the contants into Main? Or the Bean and change all references?
Where should they go?
Regards, Upayavira
ination, e.g:
> And one more thing... CocoonBean.java, line 166: error text does not
> make much sense in Bean context (what is "-d"? :), this text is
> appropriate in Main.java.
Yup. Should be an exception and Main reports it.
> And System.exit should be replaced with
> exception, I guess you already know this.
Eventually.
Thanks, Upayavira
; >
>
> Comments are not wrong... Those constants should be moved. Eventually.
> After 2.1 release, may be?
But what about the dependencies upon them that are outside the scope of the CLI?
Upayavira
w.
Slow to reply, or slow to understand? ;-)
I didn't remove it in the end, because it would have taken quite a bit of plumbing to
work around its non-presence (in order to at least keep the CLI interface the same).
Perhaps I should deprecate it and remove it later?
Thanks again.
Upayavira
> > Fair enough. I've moved it back.
>
> Found another one: Constants.DEFAULT_WORK_DIR is used by
> src/test/org/apache/cocoon/components/resolver/test/ResolverImplTestCa
> se.java
I've moved the lot back. Obviously the comments that I based my move upon were
wrong!
Regards, Upayavira
upayavira2003/06/04 07:19:10
Modified:src/java/org/apache/cocoon Constants.java
src/java/org/apache/cocoon/bean CocoonBean.java
Log:
Moved all comments back from CocoonBean to Contants. Oh well.
Revision ChangesPath
1.7 +21 -1 cocoon-2.1/src/java
Christian,
> > cocoon-2.1/src/java/org/apache/cocoon/bean/helpers - New directory
>
> Would CocoonBean.INDEX_URI be the same as Constants.INDEX_URI?
> CocoonProcessorDelegate in scratchpad seems to miss this constant
Fair enough. I've moved it back.
Upayavira
Christian,
> > cocoon-2.1/src/java/org/apache/cocoon/bean/helpers - New directory
>
> Would CocoonBean.INDEX_URI be the same as Constants.INDEX_URI?
> CocoonProcessorDelegate in scratchpad seems to miss this constant
Fair enough. I've moved it back.
Upayavira
upayavira2003/06/04 06:48:50
Modified:src/java/org/apache/cocoon Constants.java
src/java/org/apache/cocoon/bean CocoonBean.java
Log:
Returning INDEX_URI to Constants.java (from CocoonBean.java)
Revision ChangesPath
1.6 +11 -5 cocoon-2.1/src/java
rvices etc?
>
>
>
>
>
>
And then you add that transformer into a view, so you can access
page.html?cocoon-view=validate
to find out whether the page validates. That'd be neat.
Upayavira
upayavira2003/06/04 02:23:03
cocoon-2.1/src/java/org/apache/cocoon/bean/helpers - New directory
upayavira2003/06/04 02:25:53
Modified:.cli.xconf
src/java/org/apache/cocoon Cocoon.java Constants.java
Main.java
src/java/org/apache/cocoon/bean CocoonBean.java
src/java/org/apache/cocoon/environment
estDir("built/dest/");
> >
>
> CocoonBean was introduced just recently and we had no single beta
> release yet, so I think it's ok to break this interface. If method
> setDestDir is not necessary anymore, feel free to remove it.
It is particularly the removal of the Destination interface that breaks the interface.
However, removing the setDestDir will certainly make a cleaner interface. I'll do that.
Thanks for your comments.
Upayavira
ing access to some nice new
ModifiableSources.
I'll update the Wiki (with a new 2.1 doc and a CocoonBean page too) soon.
I hope you all like it.
Regards, Upayavira
Ias,
I would very much like to get Stefano's original, however in the meantime your link is
very helpful.
Regards, Upayavira
> I'd like to give you the link
> http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105220850428292&w=2 .
> I hope it still can be
Dear All,
I would like to download and try Linotype, but can't find it. The page at:
http://www.betaversion.org/~stefano/dist/linotype_1.0.tar.gz
doesn't work. Anyone know where I can find it?
Regards, Upayavira
Stefano,
I'm afraid your interesting post ended prematurely here:
>
>
>
>
>
Do you have the rest?
Regards, Upayavira
Unavailable() to be configurable (write out or not),
> but I don't know if maybe there are other errors that write directly.
Sounds easy enough.
> 4 is quite important from a user perspective, but maybe it takes some
> time to do.
>
> Feel really free in doing what you need/prefer, especially if other
> things take you too much time.
Progress will be slow, but I'll keep you posted.
Upayavira
> Do you know the Ant mapper
> (http://ant.apache.org/manual/CoreTypes/mapper.html)?
> Perhaps a similar facility can be used.
No, it looks interesting. I'll look into it.
Upayavira
so
> cocoon.process("whatever", "context://xdocs/content/foo.xml") (for a
> deployed webapp) and even cocoon.process("whatever",
> "cvs://my-module/foo")
>
> How does it sound ?
Sounds even better to me.
Upayavira
s documentation. It
> > doesn't even have getOutputStream().
>
> WriteableSource does.
Small point: In 2.1 it is now ModifiableSource (Writable source is depracated).
Upayavira
stination
> 6) others
>
> Feel free to do whatever in whatever order you prefer, this is just
> what IMVHO is the priority. 1+2 are needed BTW so that crawlers see
> broken links correctly, otherwise the site seems ok but instead the
> broken links are there.
Do you have ideas as to how to do these (i.e. 1-4)? 5 is of greatest importance to
me, but if I can understand what is involved in the others, then I can always have a
go.
Regards, Upayavira
like:
cocoon.process("whatever", resolver.getSource("file://blah"));
Regards, Upayavira
On 28 Mar 2003 at 11:44, David Crossley wrote:
> Upayavira wrote:
> > I am working on the CLI. I currently get an error when running
> > it in Idea (which worked fine before): 'no protocol:
> > characters.ent'. It would appear to be something wrong with entity
&
the source of this error?
Regards, Upayavira
coon can't find one of its standard components. Make sure you
have all of the components (generators, transformers, etc) installed in your root
sitemap. Otherwise, you'll get that error.
Regards, Upayavira
and you'll get the Batik block complaining about a missing jar.
I
didn't work that one out i'm afraid.
Upayavira
27; principle.
> This is not so hard to implement and would be even easier to use than
> what we have now.
Great! Do others think this is worth doing?
Upayavira
king with
Cocoon, but didn't have the confidence to make those first few jumps?
Upayavira
f I'm a 'typical' user.
I agree with whoever it was that said that this needs to be approached as a
psychological issue, not so much a technical one.
Regards, Upayavira
s:
* the CLI working within the binary distribution
* the CocoonBean (and hence CLI) using ModifiableSources rather than its
own Destination objects.
But cannot add them to todo.xml. I don't know if people consider them sufficiently
important to go into 2.1b.
Regards, Upayavira
The CLI works fine from the batch file, but gives an exception when I run it from in
IDEA. I've done what I remember to be the usual: build clean, checking I've got all
the
latest jars in my classpath. Any ideas what might be causing the following exception?
java.lang.AbstractMethodError:
org/
ntributions are always very interesting and
> well accepted :-D
Rest assured, I won't work on my suggested ideas until I've dealt with the problem
you relate - I was just wanting to make my concerns/wishes public, that's all.
Regards, Upayavira
e is a ModifiableSource), and if people agree that this is a good idea,
then it is worth doing before release, as afterwards we'd need to honour the
'Destination' interface.
I'm prepared to work on both, and have ideas...
Regards, Upayavira
t routes through that flow, in an easily managable way.
I've no idea how achievable that would be, as I've never played with flow myself, but
just adding sessions back in seems like a major opportunity missed.
Regards, Upayavira
oon
> switch as Avalon is doing to commons-cli).
Let me know when we're ready to do so, and I'll happily send in a patch to move to
the commons-cli.
> So I would not want to need to include that jar just for the "bean".
> So I'd keep them still separate but with one dependent on another.
Fair enough.
Upayavira
but seeing as the cli uses the bean, surely the CLI environment should
be replaced with a 'more generic' bean-environment, rather than there being one of
each.
Upayavira
> Ok. So we have some. I'll have a look at this.
Great. I'd be pleased to hear what you find.
> Ah, and there's no need to CC me privately as I closely monitor this
> list ;-)
Ok. My benevolent emailer does this for me without asking!!
Upayavira
hy, but it was beyond my current expertise (probably
because I don't have Avalon source installed). And the CLI certainly shouldn't need to
know about servlet stuff.
Regards, Upayavira
ransformer can't find its source files.
Upayavira
le site without NPEs).
I've got further ideas for the CLI, which I'll mention separately.
Regards, Upayavira
Jetty is
using (it's not in WEB-INF/work/cache-dir as web.xml would suggest).
Any ideas?
Upayavira
't help.
Regards, Upayavira
> I got a strange exception from the DOMStreamer.
>
I have got a similar error. I get this when using the HTMLGenerator.
Upayavira
==
Exception in thread "main" java.lang.reflect.InvocationTargetException:
java.lang.NoSuchMethod
Nicola Ken wrote:
> So, from quick glance, it seems that the way it's done is IMHO the
> right way.
Glad you think so!
> Upayavira wrote in bugzilla:
> "
> This code appears to try to check pages that begin with #, javascript:
> or http://. I plan to prevent this, an
the Cocoon core, a bit more substantial within
CocoonBean.java.
Regards, Upayavira
ch page only
once, which is great.
So what now? Is anyone interested in seeing it?
Regards, Upayavira
1 - 100 of 131 matches
Mail list logo
