You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@cocoon.apache.org by Ross Burton <bu...@dcs.kcl.ac.uk> on 2000/01/11 20:41:50 UTC

Thoughts...

Hi,

Today while laying in the bath - which is recognised as a means towards
great thinking :-)  - I was pondering about Cocoon, specifically what could
be done with XSP and the soon-to-be-implemented sitemap.

1) Cocoon needs more output formats: plain text, RTF and TIFF/PNG would be
very nice.  Then Cocoon can output most useful formats: XML, HTML, PDF, RTF,
raw text and images.

2) Would dynamic document translation be possible?  My thoughts are that a
user requests a document, then either through the HTTP headers or a argument
in the URL it is translated into another language using something similar to
Alta Vista's Babel Fish.  A very nice feature point IMHO.

3) A XSP taglib to do directory/file management (listing directories,
getting file information) would be handy.

4) The sitemap needs comprehensive user-agent matching - In my opinion it's
not the browser the sitemap needs to concern itself with, it's the
capabilites of that browser.  Knowing that the user is using IE means that
you can probably use CSS, knowing that it is IE3 on the Mac means that you
really shouldn't...  Taking pointers from M$ IIS and PHP's browscap file,
knowledge of the users ability for JavaScript, CSS1, CSS2, Java etc. means
stylesheets can be more general.

When I find the time (not now - I have three of my finals in 2 days) I'll
probably implement some of (1), play with (3) to learn XSP and think about
(4) until the sitemap is implemented.

Regards,
Ross Burton
IT'z Interactive



Re: Java 2 dependencies(Compile problems)

Posted by Joshua Lucas <jo...@stonecottage.com>.
If that's the case, then then shouldn't the building of XSP be a different
target in build.xml.  That way, everyone wins.. (I think)


josh
----- Original Message -----
From: Ted <te...@gs2admin1.e-meet.com>
To: <co...@xml.apache.org>
Sent: Tuesday, January 11, 2000 1:21 PM
Subject: Re: Java 2 dependencies(Compile problems)


> I am developing in Voice Markup Language, and I *DO* need the URLDecoder
> class which is implemented in Java 2 only. (In fact, we had to upgrade
> all servers to be able to do this). Although the consensus in this list
> seems to be compatibility with 1.1, I think that those who wish to
> deploy the most recently added XSP functionality should use Java 2.
>
> Ricardo, back me up on this one :-)
>
> Ted
>
> Joshua Lucas wrote:
> >
> > I am having probelm compiling the latest from CVS.  I had updated then
had
> > problems so I went back and checked everything out.  I believe the
problem
> > is that some code related to XSP is using Java 2 methods and classes.
> >
> > Here are the errors:
> >
/usr/home/jolucas/xml-cocoon/build/src/org/apache/cocoon/processor/xsp/XSPUt
> > il.java:376:
> > Undefined variable or class name: URLDecoder
> >     return URLDecoder.decode(text);
> >            ^
> >
/usr/home/jolucas/xml-cocoon/build/src/org/apache/cocoon/processor/xsp/langu
> > age/java/XSPClassLoader.java:83:
> > Method getParent() not found in class
> > org.apache.cocoon.processor.xsp.language.java.XSPClassLoader.
> >           ClassLoader cl = getParent(); // Hmmm...
> >
> > Is Java 2 now a requirement?  I looked back through the archives and
didn't
> > find anything but maybe I missed it.
> >
> > thanks,
> > josh
>


Re: Java 2 dependencies(Compile problems)

Posted by Stefano Mazzocchi <st...@apache.org>.
Zvi Avraham wrote:
> 
> Hi,
> 
> If the only problem is URLDecoder,
> then I wrote one for Java 1.1 long time ago,
> I can contribute it. Other dirty solution is just to take it from Java 2 and
> decompile :)

X-Mozilla-Status: 0009t all of us have done it in the past anyway ... :)

People, there are nice URLutil stuff in JServ, if I remember right...

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------



Re: Java 2 dependencies(Compile problems)

Posted by Stefano Mazzocchi <st...@apache.org>.
Zvi Avraham wrote:
> 
> Hi,
> 
> If the only problem is URLDecoder,
> then I wrote one for Java 1.1 long time ago,
> I can contribute it. Other dirty solution is just to take it from Java 2 and
> decompile :)

Kind of illegal :) but all of us have done it in the past anyway ... :)

People, there are nice URLutil stuff in JServ, if I remember right...

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------



Re: Java 2 dependencies(Compile problems)

Posted by Ted <te...@gs2admin1.e-meet.com>.
The final word. 
Thanks (...but those new collection classes are again out of
reach...sigh...)

Ricardo Rocha wrote:
> 
> XSP will be written all in JDK1.1, no Java2 dependencies.
> This will take place during the next few days. Classes and
> methods used by XSP and introduced in Java2 (Stack,
> URLDecoder) will be replaced by equivalent JDK1.1 forms.

RE: Java 2 dependencies(Compile problems)

Posted by Ricardo Rocha <ri...@apache.org>.
XSP will be written all in JDK1.1, no Java2 dependencies.
This will take place during the next few days. Classes and
methods used by XSP and introduced in Java2 (Stack,
URLDecoder) will be replaced by equivalent JDK1.1 forms.

Re: Java 2 dependencies(Compile problems)

Posted by Zvi Avraham <zv...@netmanage.co.il>.
Hi,

If the only problem is URLDecoder,
then I wrote one for Java 1.1 long time ago,
I can contribute it. Other dirty solution is just to take it from Java 2 and
decompile :)

Zvi

Ted wrote:

> I am developing in Voice Markup Language, and I *DO* need the URLDecoder
> class which is implemented in Java 2 only. (In fact, we had to upgrade
> all servers to be able to do this). Although the consensus in this list
> seems to be compatibility with 1.1, I think that those who wish to
> deploy the most recently added XSP functionality should use Java 2.
>
> Ricardo, back me up on this one :-)
>
> Ted
>
> Joshua Lucas wrote:
> >
> > I am having probelm compiling the latest from CVS.  I had updated then had
> > problems so I went back and checked everything out.  I believe the problem
> > is that some code related to XSP is using Java 2 methods and classes.
> >
> > Here are the errors:
> > /usr/home/jolucas/xml-cocoon/build/src/org/apache/cocoon/processor/xsp/XSPUt
> > il.java:376:
> > Undefined variable or class name: URLDecoder
> >     return URLDecoder.decode(text);
> >            ^
> > /usr/home/jolucas/xml-cocoon/build/src/org/apache/cocoon/processor/xsp/langu
> > age/java/XSPClassLoader.java:83:
> > Method getParent() not found in class
> > org.apache.cocoon.processor.xsp.language.java.XSPClassLoader.
> >           ClassLoader cl = getParent(); // Hmmm...
> >
> > Is Java 2 now a requirement?  I looked back through the archives and didn't
> > find anything but maybe I missed it.
> >
> > thanks,
> > josh


Re: Java 2 dependencies(Compile problems)

Posted by Michael Engelhart <me...@earthtrip.com>.
on 1/11/00 3:21 PM, Ted at ted@gs2admin1.e-meet.com wrote:

> I am developing in Voice Markup Language, and I *DO* need the URLDecoder
> class which is implemented in Java 2 only. (In fact, we had to upgrade
> all servers to be able to do this). Although the consensus in this list
> seems to be compatibility with 1.1, I think that those who wish to
> deploy the most recently added XSP functionality should use Java 2.
> 
> Ricardo, back me up on this one :-)
> 
> Ted
I think a 1.1 compatible version of this class should be written and added
to the org.apache.cocoon package so that we don't break 1.1 systems just for
one URLDecoder.decode() method call.

Mike


Re: Java 2 dependencies(Compile problems)

Posted by Ted <te...@gs2admin1.e-meet.com>.
I am developing in Voice Markup Language, and I *DO* need the URLDecoder
class which is implemented in Java 2 only. (In fact, we had to upgrade
all servers to be able to do this). Although the consensus in this list
seems to be compatibility with 1.1, I think that those who wish to
deploy the most recently added XSP functionality should use Java 2.

Ricardo, back me up on this one :-)

Ted

Joshua Lucas wrote:
> 
> I am having probelm compiling the latest from CVS.  I had updated then had
> problems so I went back and checked everything out.  I believe the problem
> is that some code related to XSP is using Java 2 methods and classes.
> 
> Here are the errors:
> /usr/home/jolucas/xml-cocoon/build/src/org/apache/cocoon/processor/xsp/XSPUt
> il.java:376:
> Undefined variable or class name: URLDecoder
>     return URLDecoder.decode(text);
>            ^
> /usr/home/jolucas/xml-cocoon/build/src/org/apache/cocoon/processor/xsp/langu
> age/java/XSPClassLoader.java:83:
> Method getParent() not found in class
> org.apache.cocoon.processor.xsp.language.java.XSPClassLoader.
>           ClassLoader cl = getParent(); // Hmmm...
> 
> Is Java 2 now a requirement?  I looked back through the archives and didn't
> find anything but maybe I missed it.
> 
> thanks,
> josh

Java 2 dependencies(Compile problems)

Posted by Joshua Lucas <jo...@stonecottage.com>.
I am having probelm compiling the latest from CVS.  I had updated then had
problems so I went back and checked everything out.  I believe the problem
is that some code related to XSP is using Java 2 methods and classes.

Here are the errors:
/usr/home/jolucas/xml-cocoon/build/src/org/apache/cocoon/processor/xsp/XSPUt
il.java:376:
Undefined variable or class name: URLDecoder
    return URLDecoder.decode(text);
           ^
/usr/home/jolucas/xml-cocoon/build/src/org/apache/cocoon/processor/xsp/langu
age/java/XSPClassLoader.java:83:
Method getParent() not found in class
org.apache.cocoon.processor.xsp.language.java.XSPClassLoader.
          ClassLoader cl = getParent(); // Hmmm...


Is Java 2 now a requirement?  I looked back through the archives and didn't
find anything but maybe I missed it.


thanks,
josh


Re: Thoughts...

Posted by Pierpaolo Fumagalli <pi...@apache.org>.
Stefano Mazzocchi wrote:
> 
> As for images, Pier and I proposed the NRG language for raster image
> creation and Pier implemented it into Stylebook. The FOP project is
> currently thinking of incorporating it into its codebase, so we might
> end up using FOP for that also.

FYI... I will be working on NRG, separating it from StyleBook and making
it a stand alone thing like FOP this month. This is a requirement for
the Exoffice guys, and I can't say "no" to friends :) ....

	Pier :)

-- 
--------------------------------------------------------------------
-          P              I              E              R          -
stable structure erected over water to allow the docking of seacraft
<ma...@betaversion.org>    <http://www.betaversion.org/~pier/>

Re: Thoughts...

Posted by Stefano Mazzocchi <st...@apache.org>.
Ross Burton wrote:
> 
> > > 1) Cocoon needs more output formats: plain text, RTF and TIFF/PNG would
> be
> > > very nice.  Then Cocoon can output most useful formats: XML, HTML, PDF,
> RTF,
> > > raw text and images.
> 
> > Ummm... I say this as nicely as possible, so as not to offend... are you
> > sure you are up on what XSL/T does?  Cocoon is limited in its output
> > formats only by how well you can transform the XML you give it.
> > Certainly some binary data such as PDF relies on additional programs,
> > but if it can be represented by hand, it can be transformed to that
> > representation.  Now if you are talking about writing additional
> > formatting-objects... go for it, but that's way beyond our scope here...
> 
> I was thinking of XSL:FO to RTF mainly, implemented as a Formatter in a
> similar manner to FOP.

Others have expressed this intention in the FOP mail list but nobody has
done it. This is not something that Cocoon should go over, IMO.
 
> I really would like RTF creation, that way a document can be produced which
> MS Word will open easily, fully formatted.  HTML is not a sensible solution.

I agree but this is different enough to belong there.

As for images, Pier and I proposed the NRG language for raster image
creation and Pier implemented it into StylebX-Mozilla-Status: 0009s
currently thinking of incorporating it into its codebase, so we might
end up using FOP for that also.
 
But it's too early to tell, but I want image generation, that's for
sure.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------



Re: Thoughts...

Posted by Stefano Mazzocchi <st...@apache.org>.
Ross Burton wrote:
> 
> > > 1) Cocoon needs more output formats: plain text, RTF and TIFF/PNG would
> be
> > > very nice.  Then Cocoon can output most useful formats: XML, HTML, PDF,
> RTF,
> > > raw text and images.
> 
> > Ummm... I say this as nicely as possible, so as not to offend... are you
> > sure you are up on what XSL/T does?  Cocoon is limited in its output
> > formats only by how well you can transform the XML you give it.
> > Certainly some binary data such as PDF relies on additional programs,
> > but if it can be represented by hand, it can be transformed to that
> > representation.  Now if you are talking about writing additional
> > formatting-objects... go for it, but that's way beyond our scope here...
> 
> I was thinking of XSL:FO to RTF mainly, implemented as a Formatter in a
> similar manner to FOP.

Others have expressed this intention in the FOP mail list but nobody has
done it. This is not something that Cocoon should go over, IMO.
 
> I really would like RTF creation, that way a document can be produced which
> MS Word will open easily, fully formatted.  HTML is not a sensible solution.

I agree but this is different enough to belong there.

As for images, Pier and I proposed the NRG language for raster image
creation and Pier implemented it into Stylebook. The FOP project is
currently thinking of incorporating it into its codebase, so we might
end up using FOP for that also.
 
But it's too early to tell, but I want image generation, that's for
sure.

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<st...@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------
 Come to the first official Apache Software Foundation Conference!  
------------------------- http://ApacheCon.Com ---------------------



Re: Thoughts...

Posted by Ross Burton <bu...@dcs.kcl.ac.uk>.
> > 1) Cocoon needs more output formats: plain text, RTF and TIFF/PNG would
be
> > very nice.  Then Cocoon can output most useful formats: XML, HTML, PDF,
RTF,
> > raw text and images.

> Ummm... I say this as nicely as possible, so as not to offend... are you
> sure you are up on what XSL/T does?  Cocoon is limited in its output
> formats only by how well you can transform the XML you give it.
> Certainly some binary data such as PDF relies on additional programs,
> but if it can be represented by hand, it can be transformed to that
> representation.  Now if you are talking about writing additional
> formatting-objects... go for it, but that's way beyond our scope here...

I was thinking of XSL:FO to RTF mainly, implemented as a Formatter in a
similar manner to FOP.

I really would like RTF creation, that way a document can be produced which
MS Word will open easily, fully formatted.  HTML is not a sensible solution.

[snip - user agent detection]
> We talked earlier about implementing something like that.  If you have
> the bandwidth, go for it!

Cool - I'll play with XSP over the weekend.

Ross Burton

"Thirty days with a crew of viral masochists and a ship that thinks it's a
cuddly toy."
 - Diziet Embless Sma, 'Use of Weapons' - Iain M. Banks

Slipstream: http://come.to/slipstream
The Culture: http://come.to/theculture
ICQ: 5167146



Re: Thoughts...

Posted by Brett McLaughlin <bm...@algx.net>.
Ross Burton wrote:
> 
> Hi,
> 
> Today while laying in the bath - which is recognised as a means towards
> great thinking :-)  - I was pondering about Cocoon, specifically what could
> be done with XSP and the soon-to-be-implemented sitemap.
> 
> 1) Cocoon needs more output formats: plain text, RTF and TIFF/PNG would be
> very nice.  Then Cocoon can output most useful formats: XML, HTML, PDF, RTF,
> raw text and images.

Ummm... I say this as nicely as possible, so as not to offend... are you
sure you are up on what XSL/T does?  Cocoon is limited in its output
formats only by how well you can transform the XML you give it. 
Certainly some binary data such as PDF relies on additional programs,
but if it can be represented by hand, it can be transformed to that
representation.  Now if you are talking about writing additional
formatting-objects... go for it, but that's way beyond our scope here...

> 
> 2) Would dynamic document translation be possible?  My thoughts are that a
> user requests a document, then either through the HTTP headers or a argument
> in the URL it is translated into another language using something similar to
> Alta Vista's Babel Fish.  A very nice feature point IMHO.

Again, this is about XSL, not Cocoon in particular.  You may want to
check out more on XSL and what it does: http://www.w3.org/XSL.  Cocoon
already can decide on what stylesheets to apply based on request
headers, etc.  You just have to have the right stylesheet to apply for
what you want.

> 
> 3) A XSP taglib to do directory/file management (listing directories,
> getting file information) would be handy.

This is not a bad idea ;-)

> 
> 4) The sitemap needs comprehensive user-agent matching - In my opinion it's
> not the browser the sitemap needs to concern itself with, it's the
> capabilites of that browser.  Knowing that the user is using IE means that
> you can probably use CSS, knowing that it is IE3 on the Mac means that you
> really shouldn't...  Taking pointers from M$ IIS and PHP's browscap file,
> knowledge of the users ability for JavaScript, CSS1, CSS2, Java etc. means
> stylesheets can be more general.

We talked earlier about implementing something like that.  If you have
the bandwidth, go for it!

> 
> When I find the time (not now - I have three of my finals in 2 days) I'll
> probably implement some of (1), play with (3) to learn XSP and think about
> (4) until the sitemap is implemented.

Go for it, but I'm not sure you are clear on what (1) really means,
IMHO.  Might want to check out XSL/T more.

-Brett

> 
> Regards,
> Ross Burton
> IT'z Interactive