RE: [RT] Improving Sitemap and Flowscript

[Carsten Ziegeler]

Stefano Mazzocchi wrote:
>
>   Virtual Pipeline Components
>   ---
>


+5, the only thing I'm not sure about is the syntax in the sitemap, you
propose:

>
>  
>
>
>  

because in order to work correctly you have to define the file generator
as usual:



The src of the above statement points to a class where the src attribute of
the
transformer above points to a file, so wouldn't it be better to write:
>
>  
>
>
>  

and "reuse" the "pipeline syntax". I'm not sure which one is better, but I
really like that you don't propose using a different components section
in the sitemap for Virtual Pipeline Components, map:virtual-generator etc.

One thing missing is passing information from the pipeline to the
components.
For example if you write this pipeline:


  
...

I assume that the src info and the parameters are passed to the "real"
generator which in this case is the file generator. Is it possible to pass
info to the other components as well, so can I pass a parameter to the
xslt transformer?
I'm not sure if this is needed (or if it's FS); I have not thought about it
but it
immediately came up my mind :)

Carsten

[RT] Implementing Cocoon Blocks

[Stefano Mazzocchi]

This is a collection of (more or less) random thoughts about the 
implementation of Cocoon Blocks that I collected while talking with 
Ricardo and Sylvain IRL.

Please note that anything proposed here, while organic and workable, is 
not to be considered carved in stone, but rather a suggestion on how to 
move forward.

 - o -

Design Constraints
--
1) impact on back compatibility should be minimal, optimally none. that 
is: everything that worked before the introduction of blocks should 
continue to work with no required changes [this will reduce migration 
issues]

2) the implementation should be incremental and evolutionary. no 
radical changes in the cocoon architecture should be created [this will 
reduce the amount of code to write and also provide better regression]

3) the CVS tree should be buildable at all times [this will be enforced 
by an evolutionary approach to the implementation]

4) security of the architecture for block managing and deploying is a 
*TOP* priority and should be introduced up front.

5) deployment should be system administrator-friendly. that is, should 
*NOT* require GUIs or webapps (even if it should allow them to be 
possible)

 - o -

The overall architecture

Let's start with the first requirement: security.

Blocks are functional components at the webapp level. If a user is able 
to change the block wiring, the user is, potentially, able to execute 
his/her own code with the same security level of the entire cocoon 
application.

For this reason, the block wiring information should be located in a 
configuration file that is "read-only" by cocoon and "read/write" by 
the block deployer.

  ++  ++
  | cocoon | <--- [File System] <---> | block deployer |
  ++  ++
Note that the block deployer *could* be anything (a CLI, a webapp, an 
eclipse plugin). The above meets our second requirement: user 
friendlyness for all types of users.

Also note that it meets, potentially, the ability for the system 
administrators to perform actions such as 'staging' and 'cluster 
replication' by simply performing a file copy. Cocoon should be able to 
reload the block wiring information if this is changed.

In order to improve security and avoid DoS, there is *no way* for the 
block deployer to signal directly information to the cocoon instance 
(and no way for the cocoon instance to modify the wiring information or 
to communicate directly with the block deployer). Everything is 
performed thru the use of the file system.

The block deployer
--
The block deployer architecture is the following

  ++ +--+
  | +---+  | |  |
 [FS] <>| FS Driver |  | <-> |  User Interface  |
  | +---+  | |  |
  || +--+
  |  block |
  |services|
  ||
  |  +-+   |
  | +-+|   |
  | | Locator |+   |
  | +-+|
  +--^-+
 |
 V
block library
which is composed by four main parts:

 1) the file system driver: the part responsible for reading/writing 
the block wiring information and block configurations, to extract the 
files from the blocks distrubution archives and physically deploy the 
extracted files on the file system. There is no need for polymorphism 
for this part since there needs to be a solid file system contract 
between this driver and the cocoon block manager (included inside 
cocoon) which will need to read the block wiring info and locate the 
files on the file system.

 2) the block locator: the part responsible for locating the metadata 
associated with a given block identifier and thus, provide enough data 
for the block services and the user interface to drive the installation 
process. This part needs polymorphism. Potential implemenation of this 
locator are:

   a) "file system"-based locator: the block metadata and location 
information is stored in a file on disk.

   b) "network service"-based locator: the block metadata is provided 
by a network service (for example, a web service).

The block deployer can use multiple locators at the same time, in a 
cascading way: it should be possible to configure the block deployer 
with the kind of location services and provide a priority for which one 
to use. This allows, for example, to provide an architecture for block 
discovery that could work like this:

  block deployer ---> company block library -> cocoon official library

[a collection of blocks is called a "block library". the application 
that, given a block identifier, looks up its m

Re: [RT] Starting 2.2

[Stefano Mazzocchi]

On Wednesday, Aug 13, 2003, at 22:04 Europe/Rome, Tony Collen wrote:

Joerg Heinicke wrote:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=106077110314347&w=2
Stefano:
"the road to real blocks: how to build it minimizing the impact on
the existing code and with complete back compatibility (yes, it's
possible!)"
Here's my own Mini-RT:

If you've used a BSD, you've quite possibly run into what's known as 
_ports_.  Ports is really cool, and for anyone who doesn't know what 
it is, here's a little description.
Yes. BSD ports or Debian APT has been influencing the design of blocks 
since day one.

Ports is a big directory skeleton which usually sits in /usr/ports.  
It is organized in a hierarchy, so you end up with a directory 
structure like /usr/ports/games, /usr/ports/mail, /usr/ports/irc, etc.
I strongly dislike the taxonomy approach. Because finding agreement on 
where to place a block will be hard in several cases. But this is an 
issue that will be addressed by the block librarian.

Under each category is another directory for each program which 
belongs to it, so /usr/ports/games/fortune, etc.  Now the cool thing 
is that each program directory contains a makefile, unified diffs, and 
a list of repositories where the software resides. (FTP, WWW, etc)
I have presented a much more abstract way of achiving the same 
functionality using pluggable locators and non-locating identifiers.

When you run make, it automatically downloads the software from the 
repository, and patches the software specifically for BSD.  Even 
cooler, is that it automatically takes care of dependencies 
recursively.  Once all the dependencies are done, the software is 
built.  There are several other commands, such as "make install" or 
"make clean" which does the usual expected chores.
We (luckily!) don't need all this. java can be shipped precompiled and 
blocks will be configured by the block deployer.

The only downfall is that you have to keep the directory skeleton up 
to date.  FreeBSD does this over CVS.   Very handy.
Handy, but painful because it mixes concerns between cataloging and 
location. We should avoid this.

Now, imagine this applied to Cocoon and blocks.  If we distributed a 
"core" Cocoon, we could dramatically cut down the typical amount of 
code that gets distributed.
absolutely, this is one of the goals.

  If we wanted the PDF block installed, all we would do is go to 
$cocoon_src/blocks/pdf/ and type build install.
that would be an improvement on what we have today, but it's poor 
compared to what I want to achieve with blocks (see my latest RT on 
this)

 It would download the PDFSerializer, and realize that the FOP jars 
are required, and download them.   We could also come up with some 
"block packages" that are geared towards some basic tasks, i.e. blocks 
which are grouped together to accomplish some goal.. sort of how the 
more popular Linux distros have a "workstation", "server", "basic", 
"everything" install.
Yes, "block bundles" will be available and will be the preferred way of 
downloading complex software (say forrest, linotype or lenya) on top of 
cocoon.

That's my RT, I hope I didn't spoil anything anybody was saving :)
Not at all. Thanks much for the info, but everything you want will be 
there and much more ;-)

--
Stefano.

DO NOT REPLY [Bug 18131] - The Cocoon Servlet does not shutdown properly under Tomcat

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=18131

The Cocoon Servlet does not shutdown properly under Tomcat

[EMAIL PROTECTED] changed:

   What|Removed |Added

   Platform|PC  |All



--- Additional Comments From [EMAIL PROTECTED]  2003-08-19 18:12 ---
Doesn't seem to be PC only, so I changed Platform to All.

What's the status on the Excalibur Event fix?

Jeff

Re: Config File Proposal (was... sort of...: [ANN] Apache Cocoon 2.1 Released - binary??)

[Stefano Mazzocchi]

On Sunday, Aug 17, 2003, at 00:58 Europe/Rome, Jay Freeman ((saurik)) 
wrote:

The #1 thing that would help me start using Cocoon is orthogonal to a
binary/source distribution issue (and I'll note my preference is 
towards
binary on this axis).

I agree with you (and the previous arguments, I read through the entire
thread that was linked to) that taking Cocoon and getting it into a 
state
where I can start making changes to it is one of the most irritating 
steps
to getting Cocoon working. However, 2.1 hasn't changed this all that
terribly much. (If you look at this e-mail and go "oh, he doesn't know 
how
to use the build environment", please skip to "[START HERE]" later in 
the
post before making a snap judgement on my point. If you want to just 
see
what I'm proposing, skip to [PROPOSAL], although that skips part of the
explanation of "why?".)
Have you read the "Cocoon Block" design RT?

--
Stefano.

Re: [OT] Build Time

[Stefano Mazzocchi]

On Saturday, Aug 16, 2003, at 01:28 Europe/Rome, Vadim Gritsenko wrote:

Can cost of synchronized() statement differ highly under optimizeit 
comparing with regular jvm?
very likely on hotspot since hotspot is turned off on debug mode.

--
Stefano.

Re: accessing sitemap parameters in a flow script

[Stefano Mazzocchi]

On Friday, Aug 15, 2003, at 23:49 Europe/Rome, Sylvain Wallez wrote:

Andreas Hartmann wrote:

Sylvain Wallez wrote:

[...]


  

function foo(bar) {
...
}


This syntax turns named parameters in the sitemap into positional 
parameters of the function. This is likely to cause very confusing 
bugs when someone considers that sitemap parameters are name 
value-pairs, which they basically are. Note also that it's the 
*only* place in the sitemap where parameter order is important.

IMO, the use of cocoon.parameters should be encouraged. Furthermore, 
cocoon.parameters is the only way to pass sitemap parameters to a 
continuation.


Thanks, that's good to know!
I really thought it was a name-value mapping.


And this really demonstrates how dangerous can be this translation to 
positional parameter ;-)
why don't we fix this, then?

--
Stefano.

Re: [RT] Views for readers

[Stefano Mazzocchi]

On Thursday, Aug 14, 2003, at 16:02 Europe/Rome, Bertrand Delacretaz 
wrote:

Le Jeudi, 14 aoû 2003, à 15:53 Europe/Zurich, Sylvain Wallez a écrit :

...But shouldn't we keep labels that are already used into pipelines 
? E.g :




If it's this way I'd prefer "unless-label" in map:read to make it 
clear.

Or maybe

  

would do, meaning "use this unless any views are requested"
(and * would be the only allowed value).
Ah, and this is very easily implementable ;-)
Quickquick, do it before the FS police hears us ;-)
Gotcha! I dislike having a map:read before a map:generator. Try again.

Seriously, I find this useful for indexing and other purposes 
(gettting meta-information about binary files, images, etc for 
example).
wait wait wait wait this is exactly what JSR-170 is doing.

They are preparing for public review shortly, please let's way until 
they are out before touching this at the sitemap level!!!

--
Stefano.

Re: [RT] Views for readers

[Stefano Mazzocchi]

On Thursday, Aug 14, 2003, at 14:22 Europe/Rome, Sylvain Wallez wrote:

Jeff Turner wrote:



Isn't the problem there that a  is a whole little pipeline 
unto itself?  If it were broken into two atomic operations:



then we could have a  using a 
content-aware pipeline, and everything would work.

I have the feeling that handling non-XML content in Cocoon is Just 
Wrong, and that  is just a hack.  The fact that it doesn't 
integrate with Views is a symptom of this.  In a theoretically pure 
world, we'd either make Cocoon an XML-only framework and kill 
, or make Cocoon a generic data pipelining framework 
capable of handling and transforming binary content.

Well it's a RT after all.. ;)

Content-aware and binary pipelines in the same post? Wow! Yes, it's 
definitely a RT ;-P
I am against to both content-aware selection and binary pipelines.

I still have to see a need for them that cannot be solved with 
machinery already in place or with the newly proposed RequestFactories.

--
Stefano.

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/environment/commandline LinkSamplingEnvironment.java

[joerg]

joerg   2003/08/19 16:27:03

  Modified:src/java/org/apache/cocoon/environment/commandline
LinkSamplingEnvironment.java
  Log:
  organize imports: removed unused imports, replaced * with explicite classes
  
  Revision  ChangesPath
  1.5   +7 -4  
cocoon-2.1/src/java/org/apache/cocoon/environment/commandline/LinkSamplingEnvironment.java
  
  Index: LinkSamplingEnvironment.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/environment/commandline/LinkSamplingEnvironment.java,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- LinkSamplingEnvironment.java  17 Aug 2003 13:43:00 -  1.4
  +++ LinkSamplingEnvironment.java  19 Aug 2003 23:27:03 -  1.5
  @@ -50,13 +50,16 @@
*/
   package org.apache.cocoon.environment.commandline;
   
  -import java.io.*;
  +import java.io.BufferedReader;
  +import java.io.ByteArrayInputStream;
  +import java.io.ByteArrayOutputStream;
  +import java.io.File;
  +import java.io.IOException;
  +import java.io.InputStreamReader;
   import java.net.MalformedURLException;
  -import java.util.ArrayList;
   import java.util.Collection;
   import java.util.HashSet;
   import java.util.Map;
  -import java.util.Set;
   
   import org.apache.avalon.framework.logger.Logger;
   import org.apache.cocoon.Constants;
  
  
  

DO NOT REPLY [Bug 22498] - [PATCH] Bugs in configuration-handling in LuceneIndexTransformer

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=22498

[PATCH] Bugs in configuration-handling in LuceneIndexTransformer

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution||FIXED



--- Additional Comments From [EMAIL PROTECTED]  2003-08-19 23:10 ---
Ok, patch applied.

cvs commit: cocoon-2.1/src/blocks/lucene/java/org/apache/cocoon/transformation LuceneIndexTransformer.java

[joerg]

joerg   2003/08/19 16:04:04

  Modified:src/blocks/lucene/java/org/apache/cocoon/transformation
LuceneIndexTransformer.java
  Log:
  clean up
  
  Revision  ChangesPath
  1.8   +7 -3  
cocoon-2.1/src/blocks/lucene/java/org/apache/cocoon/transformation/LuceneIndexTransformer.java
  
  Index: LuceneIndexTransformer.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/lucene/java/org/apache/cocoon/transformation/LuceneIndexTransformer.java,v
  retrieving revision 1.7
  retrieving revision 1.8
  diff -u -r1.7 -r1.8
  --- LuceneIndexTransformer.java   19 Aug 2003 01:34:20 -  1.7
  +++ LuceneIndexTransformer.java   19 Aug 2003 23:04:04 -  1.8
  @@ -182,10 +182,14 @@
* Called when the pipeline is assembled.
* The parameters are those specified as child elements of the
*  element in the sitemap.
  + * These parameters are optional: 
  + * If no parameters are specified here then the defaults are 
  + * supplied by the component configuration.
  + * Any parameters specified here may be over-ridden by attributes
  + * of the lucene:index element in the input document.
*/
   public void setup(SourceResolver resolver, Map objectModel, String src, 
Parameters parameters)
   throws ProcessingException, SAXException, IOException {
  -// TODO: We don't need all this stuff
   setupConfiguration = new IndexerConfiguration(
   parameters.getParameter(ANALYZER_CLASSNAME_PARAMETER, 
configureConfiguration.analyzerClassname),
   parameters.getParameter(DIRECTORY_PARAMETER, 
configureConfiguration.indexDirectory),
  @@ -389,7 +393,7 @@
   
   Attributes atts = tos.getAttributes();
   boolean attributesToText = atts.getIndex(LUCENE_URI, 
LUCENE_ELEMENT_ATTR_TO_TEXT_ATTRIBUTE) != -1;
  -for (int i = 0; atts != null && i < atts.getLength(); i++) {
  +for (int i = 0; i < atts.getLength(); i++) {
   // Ignore Lucene attributes
   if (LUCENE_URI.equals(atts.getURI(i)))
   continue;
  
  
  

Re: [RT] Improving Sitemap and Flowscript

[Tony Collen]

Miles Elam wrote:
Stefano Mazzocchi wrote:
&snip;

the default sitemap is too verbose and this scares people away. I 
would like to move the default sitemap component definitions into the 
cocoon.xconf.

Note that with blocks, the definitions of those components will be in 
the block.xconf as well and this will be aggregated by the block manager.


Except for the fact that cocoon.xconf is too verbose and this scares 
people away.  While for the most part the contents of cocoon.xconf have 
no direct impact on the sitemap, the components are intimately tied.  


Not to mention being able to inherit components from super-sitemaps.  I 
use this all the time and I'd hate to see this go away.

- Tony

Re: [RT] Improving Sitemap and Flowscript

[Christian Haul]

Stefano Mazzocchi wrote:
 Virtual Pipeline Components
 ---


I'm all in favour of this since the topic came up first. Unfortunatly, I 
haven't found the time investigating an implementation but I believe 
this should be straight forward.

Although we're not (yet) discussing implementation details, I would like 
to suggest to wrap those pipeline fragments as Avalon components. I 
believe this will become handy with blocks as we only need to expose 
components from a block

 Moving Sitemap components into cocoon.xconf
 ---
the default sitemap is too verbose and this scares people away. I would 
like to move the default sitemap component definitions into the 
cocoon.xconf.

Note that with blocks, the definitions of those components will be in 
the block.xconf as well and this will be aggregated by the block manager.
We had this already at some time. Cutting the complexity is good. 
Perhaps we should follow the idea of splitting cocoon.xconf and root 
sitemap.xmap into two files each, one for the defaults and one (empty) 
for customization.


 Pluggable Request Factories
 ---


OK

  Interception in Flowscript
 
While writing flowscripts, you realize how many things can be applied to 
many of the various flowscript functions that are called by the sitemap. 
In Linotype, I ended up using the ability that javascript gives you of 
using functions as native objects and then invoquing them by passing a 
modified argument vector.

It came to me that what I did with linotype was a really-poor-man 
interception mechanism. Interception is the ability to "intercept" a 
method call and execute some code before or after the execution of the 
intercepted method.

Interception is the simplest form of the aspect orientation.

Adding interception mechanism to the flowscript requires three changes, 
two in the FOM, one (more important!) in the javascript syntax:

 1) the addition of a function call to the "cocoon" object, which 
indicates that intercepting function calls should be imported.

 cocoon.apply("blah.js");

where "blah.js" contains the intercepting functions.

 2) the addition of a function call to context that continues the 
intercepted invocation:

  ...
  continueExecution(arguments);
  ...
 3) the introduction of wildcars for function names.

 function get*() {
   ...
 }
the above seems rather accademic, so allow me to write an example where 
the use of aspect-oriented flowscript would shine.

Something that can be modelled very well as an aspect is 
authentication/authorization (aka login) because it's not something that 
is part of the webapp (at least, it shouldn't be!) but it's something 
that is "wrapped" around it to allow people to access it without the 
proper authorization.
Here I like to disagree, sort of. While I agree that authentication is a 
good use case for AOP, I don't come to the same conclusion. In fact, by 
using an action to protect a complete URI space very much the same can 
be achieved. I know, actions are not liked by everyone, but this is one 
of the best applications for them.

So, please provide a more convincing use case for the introduction of 
AOP in Cocoon ;-)

	Chris.

--
C h r i s t i a n   H a u l
[EMAIL PROTECTED]
fingerprint: 99B0 1D9D 7919 644A 4837  7D73 FEF9 6856 335A 9E08

Re: Classloading from flow (was [Fwd: RE: Calling Java classes from(JXForms) javascript - can you? how?])

[Sylvain Wallez]

There's absolutely no reason that could lead classes to be loaded from 
the sitemap directory: Cocoon does not define any classloader, except 
the XSP classloader (which doesn't use the sitemap directory).

So classloading is performed by the servlet engine, meaning jar files in 
WEB-INF/lib and classes in WEB-INF/classes.

So point 1/ about Packages.dir.dir.class is valid, but point 2/ is not.

Sylvain

Geoff Howard wrote:

Here's a message from users where a guy figured out that his class had 
to be under the current sitemap context directory to be found by flow.

- Is this a correct explanation of the current state?
- Is this the way it should work?  Shouldn't classes/jars in WEB-INF 
be found as well?

Geoff

 Original Message 
Subject: RE: Calling Java classes from (JXForms) javascript - can you? 
how?
Date: Tue, 19 Aug 2003 13:41:58 -0400
From: Chris Clark <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>

I figured it out!  Just in case anyone else needs to know...

1) use Packages.dir.dir.class
e.g.
var MyClass = new Packages.com.domain.name.MyJavaClass();

2) The directories messed me up a bit.  For Java actions, the class 
files default to WEB-INF/classes.  In order to get the javascript to 
run, I had to put the package directory under my sitemap directory.

e.g.
Sitemap in:
c:\cocoon-2.1m2\build\webapp\myweb
Class files in:
c:\cocoon-2.1m2\build\webapp\mywebb\com\domain\name
Took a bit to figure it out, but it's working now.  :)


-Original Message-
From:Chris Clark Sent:Tuesday, August 19, 2003 8:42 AM
To:[EMAIL PROTECTED]
Subject:Calling Java classes from (JXForms) javascript - can you? 
how?

I'm using javascript with the JXForms and I'd like to call a Java 
function from within the flowscript.
Something like:

sendView(url1)
sendView(url2)
if (something updated in the model)
  call a member function from a Java class
Is this possible?  If so, how do you do it?

Looking at the samples it appears as if the Form class is being used 
within the jxform.js so I think you can do, but my javascript skills 
aren't at the point where I can figure out how.

Any tips, links to references, etc. would be really appreciated.

Thanks,
Chris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]






--
Sylvain Wallez  Anyware Technologies
http://www.apache.org/~sylvain   http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }

Re: Flow + Hibernate sample offer

[Stefano Mazzocchi]

On Friday, Aug 15, 2003, at 14:45 Europe/Rome, Vadim Gritsenko wrote:

Jeremy Quinn wrote:


BTW: The Hibernate guys are now aware of the license problem, and 
seem to be
willing to offer their api under a less restrictive license.


That is good news ...


Some BSD-like license for redistributing their binary code would be 
just what we need. We don't need BSD-like license for their source 
code, it still could be (L)GPL.
You can't release a binary with an open source license and the code 
with another one. it's just plain silly to call open source a binary, 
don't you think?

--
Stefano.

Re: [RT] Views for readers

[Stefano Mazzocchi]

On Thursday, Aug 14, 2003, at 21:44 Europe/Rome, Andreas Hochsteger 
wrote:

Hi!

Sorry, but this discussion seems to tell us one thing:
The current sitemap syntax and cocoon processing model is not really
suitable for such kind of processing.
I completely agree.

All this reminds me of a proposal (which was actually a RT) I've sent
back in January this year, where I proposed a more intuitive and
flexible pipeline concept.
Maybe more flexible (and this is half of what FS is!) but more 
intuitive?

I don't want to say, that this would be the solution to all problems 
and
I definitely made some mistakes because I didn't know that much of the
cocoon internals at the time of writing, but I think it's time to take 
a
second look at it.
Until I'm around, any proposal to make cocoon more suitable for binary 
pipelines will receive a -1 from me (vote, not veto! remember)

So here's the link:
http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=104482372430759&w=2
Again, please don't be so harsh concerning mistakes, but I think there 
are
many ideas included, which give some food for thought.
the main idea of this thread and Nicola's thoughts and Jeff's proposal 
is that cocoon should be instrumented to allow more binary process.

I strongly disagree.

Cocoon should process XML and focus on that. Other systems (a content 
repository, for example) should process the binaries (at creation time! 
not at publishing time!)

Say "no" to woodo!

--
Stefano.

Re: [RT] Views for readers

[Stefano Mazzocchi]

On Thursday, Aug 14, 2003, at 21:10 Europe/Rome, Vadim Gritsenko wrote:

PS Keep sitemap syntax clean! Say "No!" to woodo!
Amen!

--
Stefano.

Re: [RT] Views for readers

[Stefano Mazzocchi]

On Thursday, Aug 14, 2003, at 19:07 Europe/Rome, Miles Elam wrote:

Vadim Gritsenko wrote:

Here is another wild (or not?) thought.


Not so wild to me.

All this discussion comes down to the requirement of generating some 
XML out of the content usually served by the reader, if that's 
possible (and it is possible for some of the types of the content), 
in order to feed this XMLized content into the view. This generated 
XML is somewhat "equivalent" to the binary represenation for the 
purpose of view building. So, I'm going to the conclusion that some 
types of readers can be paired with the generator producing 
"equivalent", but XMLized, content. The best place to indicate such 
pairing is the time when you declare a reader:




The syntax looks a bit ugly to me, but the idea seems much more sane 
to me.

PS: Modifying sitemap syntax to allow reader/generator pairs with 
some "unless" attrbiutes looks awful to me.


Complete agreement.  One of the reasons for the sitemap (*the* 
reason?) is for the simple and easy management of a site.  Some recent 
proposals seem to be pushing in the direction of Apache HTTPd's 
mod_rewrite;  A lot of flexibility by adding "just one more > construct."

From the mod_rewrite page:

   "The great thing about mod_rewrite is it gives you all the
   configurability and flexibility of Sendmail. The downside to
   mod_rewrite is that it gives you all the configurability and
   flexibility of Sendmail."
   -- Brian Behlendorf
   Apache Group
   "Despite the tons of examples and docs, mod_rewrite is voodoo.
   Damned cool voodoo, but still voodoo."
   -- Brian Moore
   [EMAIL PROTECTED]
It'd be a shame if the sitemap became a cousin to mod_rewrite despite 
the cool voodoo.
I can hardly agree more!

- Miles Elam

P.S.  I shudder to think of what will happen to search index creation 
times when multi-megabyte Word documents and the like are sent down 
the pipe.  The parsers, however efficient they may turn out to be, 
will still have to contend with seemingly endless streams of seemingly 
pointless formatting cruft.  I'm sure we've all seen 10MB files that 
would be <100K in proper HTML I'm sure.  Ah well...'tis the cost of 
progress, I guess.
cocoon is not about binary and should *NOT* touch them. Readers were 
implemented as helpers. multi-views for binary files belong to the 
repository level, not to the publishing level!!!

I haven't read all email left (300 more to go after 5 days of offline) 
but I strongly hope you haven't implemented this or I'll scream!!!

--
Stefano.

Re: [RT] Improving Sitemap and Flowscript

[Miles Elam]

Stefano Mazzocchi wrote:

I propose the creation of "virtual pipeline components" by aggregating 
two or more components into a virtual one.


Love it.  Love it.  Love it!

  Moving Sitemap components into cocoon.xconf
 ---
the default sitemap is too verbose and this scares people away. I 
would like to move the default sitemap component definitions into the 
cocoon.xconf.

Note that with blocks, the definitions of those components will be in 
the block.xconf as well and this will be aggregated by the block manager.


Except for the fact that cocoon.xconf is too verbose and this scares 
people away.  While for the most part the contents of cocoon.xconf have 
no direct impact on the sitemap, the components are intimately tied.  
What is the problem with specifying a new file like "components.xconf" 
or specifying it in the sitemap?  For example

http://apache.org/cocoon/sitemap/1.0";>
 
 ...

Doesn't RelaxNG allow differing element content depending on attribute 
value?  (I think so.)  This would allow validation for this example and 
putting component definitions in the map:components element as it is today.

In other words, if the components are in the sitemap.xmap file, nothing 
changes;  But in the cases where having the components in a separate 
file make sense, it is clear where these definitions are located.  (An 
often overlooked issue.)

Imagine this:  A new user fires up Cocoon and wonders where the sitemap 
components are defined or, more likely, wonders what sitemap components 
are available.  Off goes a question to the mailing list.  (People don't 
read docs, remember?  ;-)  An option here would be to add a comment here 
to the effect of "Sitemap component definitions are in 
WEB-INF/cocoon.xconf."  So the newbie goes to cocoon.xconf and is 
confronted with not just the sitemap component definitions, but all of 
the components in use by the system and their configurations, roles, 
etc.  The complexity and intimidation is still there, just shifted off 
to another file.

- or -

A new user fires up Cocoon and wonders where the components are defined 
or, more likely, wonders what components are available.  At the top of 
the sitemap in the map:components element is a reference to the file 
that contains the definitions (and only the definitions).

Am I completely off-base here?

  Pluggable Request Factories
 ---
Cocoon needs a simple way to deal with complex HTTP usages, such as 
binary uploading, XML-RPC, WebDAV or SOAP.


Indeed.

After a lot of discussion with Sylvain and input from many other 
people, I propose the introduction of a new sitemap element named 
"map:adaptRequest" that works by adapting the Request object into a 
more specific object that will parse the request and provide API-level 
access to the request.


Very nice!


  Interception in Flowscript
 
While writing flowscripts, you realize how many things can be applied 
to many of the various flowscript functions that are called by the 
sitemap. In Linotype, I ended up using the ability that javascript 
gives you of using functions as native objects and then invoquing them 
by passing a modified argument vector.

It came to me that what I did with linotype was a really-poor-man 
interception mechanism. Interception is the ability to "intercept" a 
method call and execute some code before or after the execution of the 
intercepted method.


Interesting...

 1) the addition of a function call to the "cocoon" object, which 
indicates that intercepting function calls should be imported.

 cocoon.apply("blah.js");

where "blah.js" contains the intercepting functions.

 2) the addition of a function call to context that continues the 
intercepted invocation:

  ...
  continueExecution(arguments);
  ...
 3) the introduction of wildcars for function names.

 function get*() {
   ...
 }




Is only one interception possible?  Authentication is one use case for 
an interception.  Authorization could be another.  I'm sure there are 
others.  Would multiple calls to cocoon.apply(...) be possible?  Would 
they be order dependent?

Also, am I correct in the assumption that the wildcard is intended to 
match target functions?  Doesn't that tie the two files too closely 
together?  Or is this a change to the sitemap calling syntax.  Does the 
sitemap call getwhatever(...), a get* function intercepter catches it 
and then eventually passes the call down to whatever(...)?

- Miles Elam

RE: Classloading from flow (was [Fwd: RE: Calling Java classes from (JXForms) javascript - can you? how?])

[Reinhard Pötz]

> -Original Message-
> From: Geoff Howard [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, August 19, 2003 9:29 PM
> To: [EMAIL PROTECTED]
> Subject: Classloading from flow (was [Fwd: RE: Calling Java 
> classes from (JXForms) javascript - can you? how?])
> 
> 
> Here's a message from users where a guy figured out that his 
> class had 
> to be under the current sitemap context directory to be found by flow.
> 
> - Is this a correct explanation of the current state?
> - Is this the way it should work?  Shouldn't classes/jars in 
> WEB-INF be 
> found as well?

For me everythink works well. Classes in WEB-INF/classes are found.

Cheers,
Reinhard

> 
> Geoff
> 
>  Original Message 
> Subject: RE: Calling Java classes from (JXForms) javascript - 
> can you? how?
> Date: Tue, 19 Aug 2003 13:41:58 -0400
> From: Chris Clark <[EMAIL PROTECTED]>
> Reply-To: [EMAIL PROTECTED]
> To: <[EMAIL PROTECTED]>
> 
> I figured it out!  Just in case anyone else needs to know...
> 
> 1) use Packages.dir.dir.class
> e.g.
> 
> var MyClass = new Packages.com.domain.name.MyJavaClass();
> 
> 2) The directories messed me up a bit.  For Java actions, the class 
> files default to WEB-INF/classes.  In order to get the javascript to 
> run, I had to put the package directory under my sitemap directory.
> 
> e.g.
> Sitemap in:
> c:\cocoon-2.1m2\build\webapp\myweb
> 
> Class files in: c:\cocoon-2.1m2\build\webapp\mywebb\com\domain\name
> 
> Took a bit to figure it out, but it's working now.  :)
> 
> 
> > -Original Message-
> > From:   Chris Clark 
> > Sent:   Tuesday, August 19, 2003 8:42 AM
> > To: [EMAIL PROTECTED]
> > Subject:Calling Java classes from (JXForms) javascript 
> - can you? how?
> > 
> > I'm using javascript with the JXForms and I'd like to call a Java 
> > function from within the flowscript. Something like:
> > 
> > sendView(url1)
> > sendView(url2)
> > if (something updated in the model)
> >   call a member function from a Java class
> > 
> > Is this possible?  If so, how do you do it?
> > 
> > Looking at the samples it appears as if the Form class is 
> being used 
> > within the jxform.js so I think you can do, but my 
> javascript skills 
> > aren't at the point where I can figure out how.
> > 
> > Any tips, links to references, etc. would be really appreciated.
> > 
> > Thanks,
> > Chris
> > 
> > 
> -
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> -
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> 
> 
> 
> 

Re: Test

[Berin Loritsch]

Tony Collen wrote:

Berin Loritsch wrote:

My messages seem to be getting swallowed in Cyberspace.  You can 
disregard
this message.



i had this problem too, i sent a message to users@ and never saw it again!
It was a bunch of virii overloading the mail servers.  ~ 27,000 mails with
100k attachments==bad news.
--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin

Re: Test

[Tony Collen]

Berin Loritsch wrote:
My messages seem to be getting swallowed in Cyberspace.  You can disregard
this message.


i had this problem too, i sent a message to users@ and never saw it again!

tony

Classloading from flow (was [Fwd: RE: Calling Java classes from (JXForms)javascript - can you? how?])

[Geoff Howard]

Here's a message from users where a guy figured out that his class had 
to be under the current sitemap context directory to be found by flow.

- Is this a correct explanation of the current state?
- Is this the way it should work?  Shouldn't classes/jars in WEB-INF be 
found as well?

Geoff

 Original Message 
Subject: RE: Calling Java classes from (JXForms) javascript - can you? how?
Date: Tue, 19 Aug 2003 13:41:58 -0400
From: Chris Clark <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
To: <[EMAIL PROTECTED]>
I figured it out!  Just in case anyone else needs to know...

1) use Packages.dir.dir.class
e.g.
var MyClass = new Packages.com.domain.name.MyJavaClass();

2) The directories messed me up a bit.  For Java actions, the class 
files default to WEB-INF/classes.  In order to get the javascript to 
run, I had to put the package directory under my sitemap directory.

e.g.
Sitemap in:
c:\cocoon-2.1m2\build\webapp\myweb
Class files in:
c:\cocoon-2.1m2\build\webapp\mywebb\com\domain\name
Took a bit to figure it out, but it's working now.  :)


-Original Message-
From:	Chris Clark 
Sent:	Tuesday, August 19, 2003 8:42 AM
To:	[EMAIL PROTECTED]
Subject:	Calling Java classes from (JXForms) javascript - can you? how?

I'm using javascript with the JXForms and I'd like to call a Java function from within 
the flowscript.
Something like:
sendView(url1)
sendView(url2)
if (something updated in the model)
  call a member function from a Java class
Is this possible?  If so, how do you do it?

Looking at the samples it appears as if the Form class is being used within the jxform.js so I think you can do, but my javascript skills aren't at the point where I can figure out how.

Any tips, links to references, etc. would be really appreciated.

Thanks,
Chris
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

[RT] Improving Sitemap and Flowscript

[Stefano Mazzocchi]

 Virtual Pipeline Components
 ---
Currently, people abuse the map:resource part of the sitemap to create 
pipeline fragments to call. This was introduced by the TreeProcessor 
implementation of the sitemap but map:resources were *not* designed to 
be pipeline fragments but entire pipelines.

It has been identified in several circumstances (but mostly dealing 
with blocks) that the need to use pipeline fragments is required.

I propose the creation of "virtual pipeline components" by aggregating 
two or more components into a virtual one. An example is

 

  
   


   
   

 

   
   

 
 

   
  

As you can see from the example, with virtual components, we can:

 1) reuse pipeline fragments as they were one component.
 2) overload existing components with additional functionality
 3) specify the src of a general purpose component (for example, xslt) 
and reuse that particular instance as a component. [useful for 
precompilation of general purpose transformations or for reusing 
pipeline services implemented by blocks]

The virtual compoments can include any other sitemap component but:

 1) for generators, all but serializers
 2) for transformers, all but generators and serializers
 3) for serializers, all but generators
and, obviously, the order is important.

   - o -

 Moving Sitemap components into cocoon.xconf
 ---
the default sitemap is too verbose and this scares people away. I would 
like to move the default sitemap component definitions into the 
cocoon.xconf.

Note that with blocks, the definitions of those components will be in 
the block.xconf as well and this will be aggregated by the block 
manager.

- o -

 Pluggable Request Factories
 ---
Cocoon needs a simple way to deal with complex HTTP usages, such as 
binary uploading, XML-RPC, WebDAV or SOAP.

After a lot of discussion with Sylvain and input from many other 
people, I propose the introduction of a new sitemap element named 
"map:adaptRequest" that works by adapting the Request object into a 
more specific object that will parse the request and provide API-level 
access to the request.

For example, in case of file upload,

 
  
   
  
 
the upload() function will be passed a UploadRequest object which 
extends Request and will be 'upcasted' by the script that uses it.

The same thing can happen for WebDAV or SOAP, where specific 
protocol-specific Request handlers will be passed and will be used by 
the script.

Note that upcasting requires a contract between the request object user 
and the sitemap writer. We believe this to be reasonable.

NOTE: the above removes the need for the pipeline extractor *and* 
removes the need for pipe-aware selectors. In fact, pipe-aware 
selection is not required if the proper information is extracted from 
the pipeline and made available to the environment. Instead of using 
extraction, the request is adapted by a specific request factory.

The factories are made part of the sitemap components


 ...
 
  
   true
   100
   ...
  
 
 ...

this also solves the issue with

 1) uploading granularity
 2) mailet request handling (that can be made a special request factory 
and evolve independently from our environment)

   - o -

  Interception in Flowscript
 
While writing flowscripts, you realize how many things can be applied 
to many of the various flowscript functions that are called by the 
sitemap. In Linotype, I ended up using the ability that javascript 
gives you of using functions as native objects and then invoquing them 
by passing a modified argument vector.

It came to me that what I did with linotype was a really-poor-man 
interception mechanism. Interception is the ability to "intercept" a 
method call and execute some code before or after the execution of the 
intercepted method.

Interception is the simplest form of the aspect orientation.

Adding interception mechanism to the flowscript requires three changes, 
two in the FOM, one (more important!) in the javascript syntax:

 1) the addition of a function call to the "cocoon" object, which 
indicates that intercepting function calls should be imported.

 cocoon.apply("blah.js");

where "blah.js" contains the intercepting functions.

 2) the addition of a function call to context that continues the 
intercepted invocation:

  ...
  continueExecution(arguments);
  ...
 3) the introduction of wildcars for function names.

 function get*() {
   ...
 }
the above seems rather accademic, so allow me to write an example where 
the use of aspect-oriented flowscript would shine.

Something that can be modelled very well as an aspect is 
authentication/authorization (aka login) because it's not something 
that is part of the webapp (at least, it shouldn't be!) but it's 
something that

Status of Woody?

[Timothy Larson]

What is the current status of Woody?
I am running the nightly snapshot from 19-Aug-2003 03:17.
http://cvs.apache.org/snapshots/cocoon-2.1/cocoon-2.1_20030819101653.tar.gz
Several of the samples do not work:
  "Various" -- adds blank rows to "Firstname Lastname..." table at the bottom.
  "XML Binding" -- Cannot add or remove contacts
  "Bean Binding" -- Cannot add or remove contacts
I know development is ongoing.  Are these samples just not updated yet to
match the code changes, or am I encountering Woody errors?

--Tim Larson


__
Do you Yahoo!?
The New Yahoo! Search - Faster. Easier. Bingo.
http://search.yahoo.com

cvs commit: cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/layout/renderer/aspect/impl CompositeContentAspect.java WindowAspect.java DefaultCopletAspect.java TabContentAspect.java

[cziegeler]

cziegeler2003/08/19 07:09:34

  Modified:src/blocks/portal/java/org/apache/cocoon/portal/util
CopletDataReferenceFieldHandler.java
ParameterFieldHandler.java
CopletInstanceDataFieldHandler.java
AspectDataFieldHandler.java
AttributesFieldHandler.java
CopletBaseDataReferenceFieldHandler.java
CopletDataFieldHandler.java
CopletInstanceDataReferenceFieldHandler.java
ConfigurationFieldHandler.java
CopletBaseDataFieldHandler.java
ReferenceFieldHandler.java
   
src/blocks/portal/java/org/apache/cocoon/portal/layout/renderer/aspect/impl
CompositeContentAspect.java WindowAspect.java
DefaultCopletAspect.java TabContentAspect.java
  Added:   src/blocks/portal/java/org/apache/cocoon/portal/util
AbstractFieldHandler.java
  Log:
  Removing use of deprecated code; removing duplicate code
  
  Revision  ChangesPath
  1.4   +1 -4  
cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/util/CopletDataReferenceFieldHandler.java
  
  Index: CopletDataReferenceFieldHandler.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/util/CopletDataReferenceFieldHandler.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- CopletDataReferenceFieldHandler.java  10 Jul 2003 13:16:56 -  1.3
  +++ CopletDataReferenceFieldHandler.java  19 Aug 2003 14:09:34 -  1.4
  @@ -62,9 +62,6 @@
*/
   public class CopletDataReferenceFieldHandler extends ReferenceFieldHandler {
   
  -public void checkValidity(Object object) {
  -}
  -
   public Object getValue(Object object) {
   CopletData copletData = ((CopletInstanceData) object).getCopletData();
   if (copletData != null) {
  
  
  
  1.4   +2 -6  
cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/util/ParameterFieldHandler.java
  
  Index: ParameterFieldHandler.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/util/ParameterFieldHandler.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- ParameterFieldHandler.java10 Jul 2003 13:16:55 -  1.3
  +++ ParameterFieldHandler.java19 Aug 2003 14:09:34 -  1.4
  @@ -55,7 +55,6 @@
   import java.util.Map;
   
   import org.apache.cocoon.portal.layout.Parameters;
  -import org.exolab.castor.mapping.FieldHandler;
   import org.exolab.castor.mapping.MapItem;
   
   /**
  @@ -65,11 +64,8 @@
* 
* @version CVS $Id$
*/
  -public class ParameterFieldHandler implements FieldHandler {
  +public class ParameterFieldHandler extends AbstractFieldHandler {
   
  -public void checkValidity(Object object) {
  -}
  -
   public Object getValue(Object object) {
   HashMap map = new HashMap();
   Iterator iterator =
  
  
  
  1.4   +2 -6  
cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/util/CopletInstanceDataFieldHandler.java
  
  Index: CopletInstanceDataFieldHandler.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/util/CopletInstanceDataFieldHandler.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- CopletInstanceDataFieldHandler.java   10 Jul 2003 13:16:56 -  1.3
  +++ CopletInstanceDataFieldHandler.java   19 Aug 2003 14:09:34 -  1.4
  @@ -56,7 +56,6 @@
   
   import org.apache.cocoon.portal.coplet.CopletInstanceData;
   import org.apache.cocoon.portal.profile.impl.CopletInstanceDataManager;
  -import org.exolab.castor.mapping.FieldHandler;
   
   /**
* Field handler for CopletInstanceData instances.
  @@ -65,10 +64,7 @@
* 
* @version CVS $Id$
*/
  -public class CopletInstanceDataFieldHandler implements FieldHandler {
  -
  -public void checkValidity(Object object) {
  -}
  +public class CopletInstanceDataFieldHandler extends AbstractFieldHandler {
   
   public Object getValue(Object object) {
   Map map = ((CopletInstanceDataManager) object).getCopletInstanceData();
  
  
  
  1.4   +4 -6  
cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/util/AspectDataFieldHandler.java
  
  Index: AspectDataFieldHandler.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/util/AspectDataFieldHandler.java,v
  retrieving revision 1.3
  retrieving revision 1.4
  d

Test

[Berin Loritsch]

My messages seem to be getting swallowed in Cyberspace.  You can disregard
this message.
--

"They that give up essential liberty to obtain a little temporary safety
 deserve neither liberty nor safety."
- Benjamin Franklin

[RT] towards perfect application framework

[Leszek Gawron]

This will be long.

Here are some of my thought concerning building a proper web application (framework).
Please mind that I started from the position of PHP user that barely knew Java
and MVC concept. The second part is the reason why I wrote this post so if you
do not have time just skip the part one

* PART ONE *
* Title: How I became a cocoon user * 
First I started to use cocoon in quite a PHP + templates style. I mean I've
been using pipelining in cocoon just to provide the website with a common
look. I've been handling the forms myself, which means managing the whole
state machine with hidded input fields and so on.

The actions at the time were a bliss. Especially when XSP action was
introduced. When you do not know how to work with a bean model XSP action +
ESQL is really a helpful thing.

Then the problems came:
  - there were just too many actions
  - the sitemap language was a nightmare ( as matches, selectors and other
sitemap components are just enough for document rendering, I think that
coding "flow" in the sitemap was even a step backward from the ease I had
in PHP). Especially when action-sets disappeared in 2.1 :)
  - when the SimpleFormTransformer was intruduced it was much easier (and
cleaner) to fill the form with values but still it was not what tigers
like the most.
  - my software users (and me really too) would like the software to present
more advanced GUI - the most simple GUI there is is not usually ergonomic
enough.

At the time cocoon flow started to emerge and the potential was (is) huge. It
was really nice to move all the logic to javascript code. I am still at the
stage that I find calling actions from flow very useful. Maybe it should be all
placed in business logic classes but as I said: up till now XSP action + ESQL
rock!

Today I am still coding my software the way I described (do not know how to do
it the other way) so I started to fill a little stressed about the fact that
it is not way I should do it.

* PART TWO *
* Title: toward the perfect web application and why such lame as me couldn't
* achieve it with cocoon in it's current state
* Title 2: a taste for even more

Some of my research thoughts (this is the main purpose of this mail):

flow + persistence + woody is not enough to create a full blown web 
application. Why? Just because web application is (according to me and my 
current knowledge state):

1. data model
2. business logic (in specific database actions)
3. flow (which pages are shown, what actions are being fired)
4. GUI

ad 1. We can build various data models in cocoon (beans, xml). That's fine. 
There is always some "but": the support for persistence is quite none. 
All the samples use the "temporary" solution creating sesions only for
their own purpose. Some Avalon component would be needed I think (I am still
digging into Avalon lifecycle - it's not easy). The rest would be a piece of 
cake.

ad 2. We can code business logic in components, actions
ad 3. flow is flow :) we got it

WE DO NOT HAVE GUI FRAMEWORK!

While Woody is nice and a "great leap for mankind" it's not enough to build a 
full blown up GUI.

While looking for Eclipse plugins I have found a commercial package called 
W4Toolkit (http://www.w4toolkit.com). It is i think similar to .NET philosophy 
but coded entirely in Java. Please mind that I do not want to advertise any of 
the products. I am just pointing ideas ( I do not even like both :) ) 

Both .NET and W4Toolkit:
  - abstract coding web applications completely. While in .NET you can use 
  ASP.NET pages which mix HTML with web controls, in W4Toolkit you have only 
  Java objects. Both give user a set of controls like: 
  - menu
  - tree control
  - panel
  - tabbed pane
  - standard form controls like edits, listbox, selects and so on.
  
This is the first step: provide user with controls that would allow him to build 
a complete GUI ( implementing a tree control, either server side or client side 
is not easy) 

Second thing to do is to provide user with an invensive event model. For those: 

  - .NET uses single hidden input which stores a page state ( binary form ) - 
  really stupid from my point of view - for some pages the page content is a few 
  kilobytes while state takes nearly 50 kB
  
  - W4Toolkit uses JavaScript intensively. Not a good idea in some environments 
  also, but it allows to do quite anything concerning events - you can render a 
  submit button as an image or a link, you can trigger an event while expanding 
  a tree )
  
What are the biggest pros of unified GUI framework? 
 - you abstract web programming even more. Writing a web application with a rich 
 GUI would feel like writing a Java Swing application. There are even layout 
 managers in W4Toolkit so you can do panel.add( control, layout.NORTH );

 - you do not respond to "low level" submit names, hidden inputs and other weird 
 techniques but just HANDLE THE EVENT ! It is not so big problem to handle 
 events if a

RE: Release 2.1.1?

[Reinhard Pötz]

> From: Joerg Heinicke 

> Carsten Ziegeler wrote:
> > It seems that we should make a 2.1.1 release soon due to some 
> > bugs/problems.
> > 
> > Now, what do you think if we apply/process all patches entered in 
> > bugzilla for 2.1.1 as well? A patch can either be applied 
> or closed if 
> > it's obsolete etc.
> > 
> > Carsten
> 
> +1 making 2.1.1 a bugfix release

+1 from here too. I started yesterday to work off the flow related
bugzilla entries.

Reinhard

cvs commit: cocoon-2.1/src/blocks/portal/conf portal.samplesxconf

[cziegeler]

cziegeler2003/08/19 02:18:17

  Modified:src/blocks/portal/conf portal.samplesxconf
  Log:
  Fixing conf
  
  Revision  ChangesPath
  1.3   +1 -1  cocoon-2.1/src/blocks/portal/conf/portal.samplesxconf
  
  Index: portal.samplesxconf
  ===
  RCS file: /home/cvs/cocoon-2.1/src/blocks/portal/conf/portal.samplesxconf,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -u -r1.2 -r1.3
  --- portal.samplesxconf   29 Jul 2003 06:30:06 -  1.2
  +++ portal.samplesxconf   19 Aug 2003 09:18:17 -  1.3
  @@ -1,6 +1,6 @@
   
   
  -
  +
   


  
  
  

Re: Release 2.1.1?

[Joerg Heinicke]

Carsten Ziegeler wrote:
It seems that we should make a 2.1.1 release soon due to some
bugs/problems.
Now, what do you think if we apply/process all patches entered
in bugzilla for 2.1.1 as well? A patch can either be applied or
closed if it's obsolete etc.
Carsten 
+1 making 2.1.1 a bugfix release

Joerg

--
System Development
VIRBUS AG
Fon  +49(0)341-979-7419
Fax  +49(0)341-979-7409
[EMAIL PROTECTED]
www.virbus.de

Release 2.1.1?

[Carsten Ziegeler]

It seems that we should make a 2.1.1 release soon due to some
bugs/problems.

Now, what do you think if we apply/process all patches entered
in bugzilla for 2.1.1 as well? A patch can either be applied or
closed if it's obsolete etc.

Carsten 

Carsten Ziegeler 
Open Source Group, S&N AG
http://radio.weblogs.com/0107211/

DO NOT REPLY [Bug 21848] - [PATCH] 'host' pattern for CocoonLogFormatters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21848

[PATCH] 'host' pattern for CocoonLogFormatters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

DO NOT REPLY [Bug 21848] - [PATCH] 'host' pattern for CocoonLogFormatters

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG 
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND 
INSERTED IN THE BUG DATABASE.

http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21848

[PATCH] 'host' pattern for CocoonLogFormatters

[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

cvs commit: cocoon-2.1/src/java/org/apache/cocoon/util/log XMLCocoonLogFormatter.java CocoonLogFormatter.java

[cziegeler]

cziegeler2003/08/19 01:43:00

  Modified:.status.xml
   src/java/org/apache/cocoon/util/log
XMLCocoonLogFormatter.java CocoonLogFormatter.java
  Log:
 
   Applying patch for using 'host' in the logging patterns.
 
  
  Revision  ChangesPath
  1.127 +4 -1  cocoon-2.1/status.xml
  
  Index: status.xml
  ===
  RCS file: /home/cvs/cocoon-2.1/status.xml,v
  retrieving revision 1.126
  retrieving revision 1.127
  diff -u -r1.126 -r1.127
  --- status.xml19 Aug 2003 01:36:30 -  1.126
  +++ status.xml19 Aug 2003 08:43:00 -  1.127
  @@ -189,6 +189,9 @@
 
   

  +   
  + Applying patch for using 'host' in the logging patterns.
  +   
  
Lucene block: LuceneIndexTransformer configuration fixed.
  
  
  
  
  1.2   +28 -2 
cocoon-2.1/src/java/org/apache/cocoon/util/log/XMLCocoonLogFormatter.java
  
  Index: XMLCocoonLogFormatter.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/util/log/XMLCocoonLogFormatter.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- XMLCocoonLogFormatter.java9 Mar 2003 00:09:44 -   1.1
  +++ XMLCocoonLogFormatter.java19 Aug 2003 08:43:00 -  1.2
  @@ -88,6 +88,7 @@
* rtime : outputs the relative time ().
* throwable : outputs the exception ().
* priority : outputs the priority ().
  + * host : outputs the request host header ().
* 
*
* @author mailto:[EMAIL PROTECTED]">Peter Donald
  @@ -111,6 +112,7 @@
   protected final static int TYPE_CLASS= 7;
   protected final static int TYPE_CLASS_SHORT= 8;
   protected final static int TYPE_THREAD= 9;
  +protected final static int TYPE_HOST  = 10;
   
   public final static String[] typeStrings = new String[] {"uri", // 0
"category",  // 1
  @@ -121,7 +123,8 @@
"priority",  // 6
"class",// 7
"class:short", // 8
  - "thread"};  // 9
  + "thread",   // 9
  + "host"};   // 10
   
   protected final static String EOL = System.getProperty("line.separator", "\n");
   protected final SimpleDateFormat dateFormatter = new 
SimpleDateFormat("(-MM-dd) HH:mm.ss:SSS");
  @@ -215,6 +218,12 @@
   sb.append(event.getPriority().getName());
   sb.append("").append(EOL);
   break;
  +
  +case TYPE_HOST:
  +sb.append("");
  +sb.append(getHost(event.getContextMap()));
  +sb.append("");
  +break;
   }
   }
   sb.append("");
  @@ -243,6 +252,23 @@
   return result;
   }
   
  +private String getHost(ContextMap ctxMap) {
  +String result = "Unknown-host";
  +
  +if (ctxMap != null) {
  +Object context = ctxMap.get("objectModel");
  +if (context != null && context instanceof Map) {
  +// Get the request
  +Request request = ObjectModelHelper.getRequest((Map)context);
  +if (request != null) {
  +result = request.getHeader("host");
  +}
  +}
  +}
  +
  +return result;
  +}
  +
   /**
* Find the request id that is being processed.
*/
  
  
  
  1.2   +29 -1 
cocoon-2.1/src/java/org/apache/cocoon/util/log/CocoonLogFormatter.java
  
  Index: CocoonLogFormatter.java
  ===
  RCS file: 
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/util/log/CocoonLogFormatter.java,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -u -r1.1 -r1.2
  --- CocoonLogFormatter.java   9 Mar 2003 00:09:44 -   1.1
  +++ CocoonLogFormatter.java   19 Aug 2003 08:43:00 -  1.2
  @@ -87,12 +87,14 @@
   protected final static int TYPE_CLASS  = MAX_TYPE + 1;
   protected final static int TYPE_URI= MAX_TYPE + 2;
   protected final static int TYPE_THREAD = MAX_TYPE + 3;
  +protected final static int TYPE_HOST   = MAX_TYPE + 4;
   
   protected final static String  TYPE_CLASS_STR   = "class";
   protected final static String  TYPE_CLASS_SHORT_STR = "short";
   
   protected final static String  TYPE_URI_STR = "uri";
   protected final static String  TYPE_THREAD_STR  = "thread";
  +protected final static String  TYPE_HOST_STR= "host";
   
   protected final SimpleDateFormat dateFormatter = new 
SimpleDateFormat("(-MM-dd) HH:mm.ss:SSS");