Re: Transparent and automatic AJAX support for CForms
Great initiative! Sylvain Wallez wrote: Hi all, I've been thinking for a few weeks to add AJAX support to CForms. Ajax is the current buzzword in the blogosphere since Google maps [1] started and the folks at Adaptivepath found this name for the XmlHttpRequest + JS + XML combo [2]. snip/ Two days hacking, most of which dedicated to writing client-side JS and solving cross-browser compatibility problems and here we are: adding ajax=true on ft:form-template turns on the magic. I was just wondering if you considered using any of the cross-browser libraries for doing the XHR stuff? Dojo [http://dojotoolkit.org/intro_to_dojo_io.html] Sarissa [http://sarissa.sourceforge.net/doc/] I guess the problem with Sarissa is the licensing, it´s GPL'ed :( Best regards, Mats
Re: Problem with sharing sessions/ multithreading
1. Is it my imagination or was the same message posted 5 times? Nope, that was real ...plus the direct To:s method from all your actions to get the document. It should do something like: Don't want to be picky ...but better don't use DCL http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html cheers -- Torsten signature.asc Description: OpenPGP digital signature
Re: Java components in blocks
On 16 Apr 2005, at 12:43, Torsten Curdt wrote: Reading these discussions after the fact, having Blocks provide only sitemap components seems to make a lot of sense ...not to me - sorry. But maybe I just missed something. Pier is totally right: we have two different concerns. One is the pipeline services interface and one is the component interface of a block. But reducing a block just to it's pipeline services basically gives us virtual sitemap components on steroids. What about its dependencies? Well, IIUC one argument in this discussion was that the dependency will be satisfied through a pipeline service - not through a component. Block A: provides: a pipeline service to transform xml requires: a pipeline service to transform xml with a STX stylesheet Block B: provides: a pipeline service to transform xml with a STX stylesheet Hmm... As far as I can see, intra-block dependancy is available only through interface blocks, right? So, the Forrest block, requires the ForrestSkin interface, and this is injected into it by creating a new instance of the CocoonSkin (a block which implements ForrestSkin). So, now we end up with a problem: if to provide the pipeline service to transform XML, my CocoonSkin uses an XSLT, this block will depend on the XSLTTransformer, if it uses STX it will depend on the STXTransformer, if it uses XSLT2.0 and XQUERY I might want to use SaxonTransformer version 8.0 or greater... You see that if a block needs to specify its COMPONENT requirements (not BLOCK requirements) only through interface, we'll end up having one interface block probably per each implementation block... Mess... If we separate blocks and components, at this point, we can carve into stone that block requirements _must_ go through interfaces, components, actually are a completely different beast. A block exposing a PDF serializer for BOOK.DTD documents might require specifically a version of FOP, because its stylesheet works around some bugs into that particular implementation... Pier
Re: Java components in blocks
On 16 Apr 2005, at 13:56, Daniel Fagerstrom wrote: Torsten Curdt wrote: Reading these discussions after the fact, having Blocks provide only sitemap components seems to make a lot of sense ...not to me - sorry. But maybe I just missed something. Pier is totally right: we have two different concerns. One is the pipeline services interface and one is the component interface of a block. But reducing a block just to it's pipeline services basically gives us virtual sitemap components on steroids. What about its dependencies? Well, IIUC one argument in this discussion was that the dependency will be satisfied through a pipeline service - not through a component. Block A: provides: a pipeline service to transform xml requires: a pipeline service to transform xml with a STX stylesheet Block B: provides: a pipeline service to transform xml with a STX stylesheet So block B does not provide the component with hint stx but a service that could be anything doing the job satisfying the dependency. Ok. Now what about the component dependencies? Let's say in order to implement the transform-via-stx service block B requires a component of hint stx. Since the block B has its own component manager and the component stx being declared in the block's sitemap all is left is a java class level dependency to the stx implementation. Now the question is - will the block B provide the stx jar? Let's say yes for the moment. So what if the transform-via-stx component needs another component? We could list all the required component in the components section for that very block. ...but still the classes need to be available! What if the classes are in a different block? Essentially this means to me: As long as we don't want to ship every block with every component it requires I cannot see how we can get around of having blocks also expose component services. The idea is that if you have a component that you want to be able to use in several places, you package it in a certain way. Then the improved component handling system that Pier feel the itch to build can found its jar in some repository somwhere, reolve its dependencies and offer a shielded parent classloader with the depndencies you have asked for. I don't know the exact details about Pier's vison about this, but you can take a look at the kernel in whiteboard for part of it and Maven is also a part of the equation for downöloading and dependency reolution. My vision is quite simple... How many _COMPONENT_ interfaces we need for Cocoon? Probably 3: Generator Transformer Serializer (well, you might have another 2 or 3 of them but do you see the point?) How many _BLOCK_ interfaces can we have on the other hand? ForrestSkin, WebMailRepository, hundreds. Then, if each implementation of a block interface is allowed to say To provide this transformer pipeline service I need the SQL transformer component, the XSLT component and STX component (all those three simply implement the component Transformer Java interface, the problem of dependancy resolution is so easy from both sides: On the block side, you can completely ignore classloaders and java code, on the component side, you're pretty much sure that the number of component interfaces is not going to be so big and so volatile in terms of version numbers (and therefore simplifies the classloading structure). I mean, the problem right now is not that we have two versions of the o.a.c.s.Serializer (Java) interface, but that we _need_ to have in the same Cocoon two versions of Fop implementing the _same_precisely_exact_ Java interface... See what I mean? Pier
Re: [RT] what about cocoon on a diet?
On 16 Apr 2005, at 16:06, Stefano Mazzocchi wrote: But Flair is 30Kb and Cocoon is 15Mb. Even shrunk, 4Mb is still too much. Damn, how did you do that? My super-shrunk Cocoon for VNU is 20736 kb, and I can't find a way to squeeze it down further. Pier
Re: Transparent and automatic AJAX support for CForms
Mats wrote: Great initiative! Sylvain Wallez wrote: Hi all, I've been thinking for a few weeks to add AJAX support to CForms. Ajax is the current buzzword in the blogosphere since Google maps [1] started and the folks at Adaptivepath found this name for the XmlHttpRequest + JS + XML combo [2]. snip/ Two days hacking, most of which dedicated to writing client-side JS and solving cross-browser compatibility problems and here we are: adding ajax=true on ft:form-template turns on the magic. I was just wondering if you considered using any of the cross-browser libraries for doing the XHR stuff? Dojo [http://dojotoolkit.org/intro_to_dojo_io.html] Yes. Very interesting but seemed to much complex for the current need. But it's under my radar for some more complicated stuff ;-) Sarissa [http://sarissa.sourceforge.net/doc/] I guess the problem with Sarissa is the licensing, it´s GPL'ed :( Good guess... Sylvain -- Sylvain WallezAnyware Technologies http://apache.org/~sylvainhttp://anyware-tech.com Apache Software Foundation Member Research Technology Director
RE: Problem with sharing sessions/ multithreading
could you please let me know more about DCL? and regarding posting 5 times.. that was done by mistake. thanks Kiran Kumar (502) 696-7203 -Original Message- From: Torsten Curdt [mailto:[EMAIL PROTECTED] Sent: Sunday, April 17, 2005 7:18 AM To: dev@cocoon.apache.org Subject: Re: Problem with sharing sessions/ multithreading 1. Is it my imagination or was the same message posted 5 times? Nope, that was real ...plus the direct To:s method from all your actions to get the document. It should do something like: Don't want to be picky ...but better don't use DCL http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html cheers -- Torsten
Re: Java components in blocks
Pier Fumagalli wrote: My vision is quite simple... How many _COMPONENT_ interfaces we need for Cocoon? Probably 3: Generator Transformer Serializer (well, you might have another 2 or 3 of them but do you see the point?) Please take a look at the Portal and then explain how the above works for that. There are a heck of a lot more components that someone building a portal needs to configure besides these. Sitemap components are only uses in Cocoon Portlets. While each Portal request is fired off by the PortalGenerator, it invokes a lot of elements that are configured by whoever puts together the portal. Ralph
Re: Problem with sharing sessions/ multithreading
Kumar, Kiran wrote: could you please let me know more about DCL? Did you have a look into the javaworld article? cheers -- Torsten signature.asc Description: OpenPGP digital signature
RE: Problem with sharing sessions/ multithreading
Hi ,, thanks for the quick response..
I have coded this DCL logic and I am testing this and let you know.
1. there was some issue with my inbox and it posted somany times
2. yes. multiple users login at the same time and get the same DOM.
but when I refresh the page the xml and screen is OKthis is the
trick part of the whole problem. which I never understood
I hope the DCL fixes this??
part of the solution I had found was to use Filter to filter all the
requests as below
public void doFilter(
ServletRequest request,
ServletResponse response,
FilterChain filterChain) {
try {
request.setCharacterEncoding(GB2312);
((HttpServletResponse)
response).setHeader(Cache-control,no-cache);
((HttpServletResponse) response).setHeader(Pragma,
No-cache);
((HttpServletResponse)
response).setHeader(Expires, 0);
filterChain.doFilter(request, response);
} catch (ServletException sx) {
filterConfig.getServletContext().log(sx.getMessage());
} catch (IOException iox) {
filterConfig.getServletContext().log(iox.getMessage());
}
}
-
regarding the Question 2 a), some part of the XML never changes.
The other part changes based on the user actions.
I am going through 15-20 database files to build part one and
atleast 5-6 database files to build the part 2.
so when login, I build both parts but do not refresh the first part
as student does not change it.
thanks
Kiran Kumar (Raj)
(502) 696-7203
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 17, 2005 1:34 AM
To: dev@cocoon.apache.org
Subject: Re: Problem with sharing sessions/ multithreading
1. Is it my imagination or was the same message posted 5 times?
2. If I understand correctly, the problem is that multiple users are
getting the same DOM object?
a. Question: Why do you have two actions that do essentially the
same thing?
b. By the way, even though you declared them ThreadSafe they clearly
are not. It is possible for the web-browser to issue two requests at
the same time to Cocoon for the same user, depending on how the html
page is constructed, in which case both of these actions could execute
at the same time.
c. What is the purpose of synchronizing the object returned by
newInstance? That is a local variable and if each call to newInstance
returns a different object, this will accomplish nothing. If you want to
serialize the call to newDocument then you should refactor this whole
block of code in a method in a utility class and then always call that
method from all your actions to get the document. It should do something
like:
private static final String LOCK = Lock;
Document getDocument()
{
Request request = ObjectModelHelper.getRequest(objectModel);
Session session = request.getSession(true);
Document doc = (Document)session.getAttribute(myAttribute);
if (doc == null)
{
// It is possible for more than one thread to get here at
the same time with doc == null
syncronize(LOCK);
{
// So check again. Only the first caller should
actually create the document.
doc = (Document)session.getAttribute(myAttribute);
if (doc == null)
{
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
doc = dbf.newDocumentBuilder().newDocument();
session.setAttribute(myAttribute, doc);
}
}
}
return doc;
}
RE: Problem with sharing sessions/ multithreading
yes I did thanks Kiran Kumar (502) 696-7203 -Original Message- From: Torsten Curdt [mailto:[EMAIL PROTECTED] Sent: Sunday, April 17, 2005 11:47 AM To: dev@cocoon.apache.org Subject: Re: Problem with sharing sessions/ multithreading Kumar, Kiran wrote: could you please let me know more about DCL? Did you have a look into the javaworld article? cheers -- Torsten
Re: Problem with sharing sessions/ multithreading
Torsten Curdt wrote:
Don't want to be picky ...but better don't use DCL
http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html
cheers
Thanks, that article wasn't too helpful in figuring out why the
technique doesn't work. However, it refreences an article from Alan
Holub that does. From his description, the following version of the DCL
should work fine. I'm not sure the function actually has to be static.
From what I could tell synchronized should be sufficient.
Document getDocument()
{
Request request = ObjectModelHelper.getRequest(objectModel);
Session session = request.getSession(true);
Document doc = (Document)session.getAttribute(myAttribute);
if (doc == null)
{
// It is possible for more than one thread to get here at
the same time with doc == null
syncronize(LOCK);
{ // So check again. Only the first caller should
actually create the document.
doc = (Document)session.getAttribute(myAttribute);
if (doc == null)
{
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
doc = buildDocument(dbf);
session.setAttribute(myAttribute, doc);
}
}
}
return doc;
}
private static synchronized Document
buildDocument(DocumentBuilderFactory dbf)
{
return dbf.newDocumentBuilder().newDocument();
}
--
Torsten
RE: Problem with sharing sessions/ multithreading
here's what I did. and changing all the code to use this.
==
private static final String LOCK = Lock;
public Document getDocument(Map objectModel,String attrname)
throws ParserConfigurationException
{
Request request = ObjectModelHelper.getRequest(objectModel);
Session session = request.getSession(true);
Document doc = (Document)session.getAttribute(attrname);
if (doc == null)
{
// It is possible for more than one thread to get here at
// the same time with doc == null
synchronized(LOCK)
{
// So check again. Only the first caller should
// actually create the
document.
doc = (Document)session.getAttribute(attrname);
if (doc == null)
{
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
doc = dbf.newDocumentBuilder().newDocument();
session.setAttribute(attrname, doc);
}
}
}
return doc;
}
=
but why do we need static method?? please guide me
thanks
Kiran Kumar (Raj)
(502) 696-7203
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 17, 2005 12:27 PM
To: dev@cocoon.apache.org
Subject: Re: Problem with sharing sessions/ multithreading
Torsten Curdt wrote:
Don't want to be picky ...but better don't use DCL
http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html
cheers
Thanks, that article wasn't too helpful in figuring out why the
technique doesn't work. However, it refreences an article from Alan
Holub that does. From his description, the following version of the DCL
should work fine. I'm not sure the function actually has to be static.
From what I could tell synchronized should be sufficient.
Document getDocument()
{
Request request = ObjectModelHelper.getRequest(objectModel);
Session session = request.getSession(true);
Document doc = (Document)session.getAttribute(myAttribute);
if (doc == null)
{
// It is possible for more than one thread to get here at
the same time with doc == null
syncronize(LOCK);
{ // So check again. Only the first caller should
actually create the document.
doc = (Document)session.getAttribute(myAttribute);
if (doc == null)
{
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
doc = buildDocument(dbf);
session.setAttribute(myAttribute, doc);
}
}
}
return doc;
}
private static synchronized Document
buildDocument(DocumentBuilderFactory dbf)
{
return dbf.newDocumentBuilder().newDocument();
}
--
Torsten
RE: Problem with sharing sessions/ multithreading
also in the following pipeline, how can I display a html page after the
homepage action is called?
map:handle-errors
map:select type=exception
map:when test=processing
map:act type=home-page
right
here I need to call a HTML page
/map:act
/map:when
/map:select
/map:handle-errors
thanks
Kiran Kumar (Raj)
(502) 696-7203
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 17, 2005 12:27 PM
To: dev@cocoon.apache.org
Subject: Re: Problem with sharing sessions/ multithreading
Torsten Curdt wrote:
Don't want to be picky ...but better don't use DCL
http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html
cheers
Thanks, that article wasn't too helpful in figuring out why the
technique doesn't work. However, it refreences an article from Alan
Holub that does. From his description, the following version of the DCL
should work fine. I'm not sure the function actually has to be static.
From what I could tell synchronized should be sufficient.
Document getDocument()
{
Request request = ObjectModelHelper.getRequest(objectModel);
Session session = request.getSession(true);
Document doc = (Document)session.getAttribute(myAttribute);
if (doc == null)
{
// It is possible for more than one thread to get here at
the same time with doc == null
syncronize(LOCK);
{ // So check again. Only the first caller should
actually create the document.
doc = (Document)session.getAttribute(myAttribute);
if (doc == null)
{
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
doc = buildDocument(dbf);
session.setAttribute(myAttribute, doc);
}
}
}
return doc;
}
private static synchronized Document
buildDocument(DocumentBuilderFactory dbf)
{
return dbf.newDocumentBuilder().newDocument();
}
--
Torsten
RE: Problem with sharing sessions/ multithreading
looks like the Filter works but not all the time..
private FilterConfig filterConfig;
//Handle the passed-in FilterConfig
public void init(FilterConfig filterConfig) {
this.filterConfig = filterConfig;
}
//Process the request/response pair
public void doFilter(
ServletRequest request,
ServletResponse response,
FilterChain filterChain) {
try {
request.setCharacterEncoding(GB2312);
((HttpServletResponse)
response).setHeader(Cache-control,no-cache);
((HttpServletResponse) response).setHeader(Pragma,
No-cache);
((HttpServletResponse)
response).setHeader(Expires, 0);
filterChain.doFilter(request, response);
} catch (ServletException sx) {
filterConfig.getServletContext().log(sx.getMessage());
} catch (IOException iox) {
filterConfig.getServletContext().log(iox.getMessage());
}
}
//Clean up resources
public void destroy() {
Is there any thing else I need to do to make this filter not Cache all time.
In test, till now I was logging as the same user in 2 systems , logout,
access account, hit back button and login again.
It displays the correct information.
now I switched users after logout.. and it displays correct information. But
the problem is when I hit refresh, it displayed the information of the
previous user..
any clues on this
thanks
Kiran Kumar (Raj)
(502) 696-7203
-Original Message-
From: Kumar, Kiran
Sent: Sunday, April 17, 2005 12:47 PM
To: 'dev@cocoon.apache.org'
Subject: RE: Problem with sharing sessions/ multithreading
also in the following pipeline, how can I display a html page after the
homepage action is called?
map:handle-errors
map:select type=exception
map:when test=processing
map:act type=home-page
right
here I need to call a HTML page
/map:act
/map:when
/map:select
/map:handle-errors
thanks
Kiran Kumar (Raj)
(502) 696-7203
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 17, 2005 12:27 PM
To: dev@cocoon.apache.org
Subject: Re: Problem with sharing sessions/ multithreading
Torsten Curdt wrote:
Don't want to be picky ...but better don't use DCL
http://www.javaworld.com/javaworld/jw-05-2001/jw-0525-double.html
cheers
Thanks, that article wasn't too helpful in figuring out why the
technique doesn't work. However, it refreences an article from Alan
Holub that does. From his description, the following version of the DCL
should work fine. I'm not sure the function actually has to be static.
From what I could tell synchronized should be sufficient.
Document getDocument()
{
Request request = ObjectModelHelper.getRequest(objectModel);
Session session = request.getSession(true);
Document doc = (Document)session.getAttribute(myAttribute);
if (doc == null)
{
// It is possible for more than one thread to get here at
the same time with doc == null
syncronize(LOCK);
{ // So check again. Only the first caller should
actually create the document.
doc = (Document)session.getAttribute(myAttribute);
if (doc == null)
{
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
doc = buildDocument(dbf);
session.setAttribute(myAttribute, doc);
}
}
}
return doc;
}
private static synchronized Document
buildDocument(DocumentBuilderFactory dbf)
{
return dbf.newDocumentBuilder().newDocument();
}
--
Torsten
Re: Problem with sharing sessions/ multithreading
Kumar, Kiran wrote:
here's what I did. and changing all the code to use this.
==
private static final String LOCK = Lock;
public Document getDocument(Map objectModel,String attrname)
throws ParserConfigurationException
{
Request request = ObjectModelHelper.getRequest(objectModel);
Session session = request.getSession(true);
Document doc = (Document)session.getAttribute(attrname);
if (doc == null)
{
// It is possible for more than one thread to get here at
// the same time with doc == null
synchronized(LOCK)
{
// So check again. Only the first caller should
// actually create the
document.
doc = (Document)session.getAttribute(attrname);
if (doc == null)
{
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
doc = dbf.newDocumentBuilder().newDocument();
session.setAttribute(attrname, doc);
}
}
}
return doc;
}
=
but why do we need static method?? please guide me
As Alan Holub pointed out, the JVM does not guarantee that the
constructor for the Document returned by the call to newDocument() may
not have been run at the time the Document object refrerence is assigned
to the session attribute. Simply putting the call to newDocument()
inside its own synchronized block should address that problem.
Ralph
Re: Problem with sharing sessions/ multithreading
Kumar, Kiran wrote: also in the following pipeline, how can I display a html page after the homepage action is called? map:handle-errors map:select type=exception map:when test=processing map:act type=home-page right here I need to call a HTML page /map:act /map:when /map:select /map:handle-errors Kumar, Please try to limit how much of previous messages you quote. In the case above, create a resource definition and then call it inside your map:act. Ralph
RE: Problem with sharing sessions/ multithreading
I will try this.. because.. after using this utility class, I see sharing
sessions more often. when I switched the users in the same browser.
thanks
Kiran Kumar (Raj)
(502) 696-7203
-Original Message-
From: Ralph Goers [mailto:[EMAIL PROTECTED]
Sent: Sunday, April 17, 2005 1:07 PM
To: dev@cocoon.apache.org
Subject: Re: Problem with sharing sessions/ multithreading
Kumar, Kiran wrote:
here's what I did. and changing all the code to use this.
==
private static final String LOCK = Lock;
public Document getDocument(Map objectModel,String attrname)
throws ParserConfigurationException
{
Request request = ObjectModelHelper.getRequest(objectModel);
Session session = request.getSession(true);
Document doc = (Document)session.getAttribute(attrname);
if (doc == null)
{
// It is possible for more than one thread to get here at
// the same time with doc == null
synchronized(LOCK)
{
// So check again. Only the first caller should
// actually create the
document.
doc = (Document)session.getAttribute(attrname);
if (doc == null)
{
DocumentBuilderFactory dbf =
DocumentBuilderFactory.newInstance();
doc = dbf.newDocumentBuilder().newDocument();
session.setAttribute(attrname, doc);
}
}
}
return doc;
}
=
but why do we need static method?? please guide me
As Alan Holub pointed out, the JVM does not guarantee that the
constructor for the Document returned by the call to newDocument() may
not have been run at the time the Document object refrerence is assigned
to the session attribute. Simply putting the call to newDocument()
inside its own synchronized block should address that problem.
Ralph
RE: Sharing sessions.. change to JDK1.5
but I am in trouble now as I cannot switch to 1.5 until some more time. It might take some time to migrate existing applications to 1.5. by the way we deploy the java on websphere AS400 thanks Kiran Kumar -Original Message- From: Torsten Curdt [mailto:[EMAIL PROTECTED] Sent: Sunday, April 17, 2005 1:14 PM To: Kumar, Kiran Subject: wrong mailing list? Kiran, Again: I don't really think the lock will solve your problem. This only helps if you have concurrent threads accessing the same session. Check the relation of the thread and the session id. As for the DCL: AFAIK this can *not* be solved in any (secure) way due to JVM internals - I though the article made that clear. The only way to do proper synchronization is synchronize all access ...or use Dough's concurrent utils (which are now also part of java 1.5) cheers -- Torsten
Re: Java components in blocks
Ralph Goers wrote: Pier Fumagalli wrote: My vision is quite simple... How many _COMPONENT_ interfaces we need for Cocoon? Probably 3: Generator Transformer Serializer (well, you might have another 2 or 3 of them but do you see the point?) Please take a look at the Portal and then explain how the above works for that. There are a heck of a lot more components that someone building a portal needs to configure besides these. Sitemap components are only uses in Cocoon Portlets. While each Portal request is fired off by the PortalGenerator, it invokes a lot of elements that are configured by whoever puts together the portal. Don't have time to take any detailed look at the portal ATM, but I give my view on the main concepts and then you can see if they seem to help your use case. In the original proposal was the idea that a block exposes both sitemap functionality and components. Our current idea is that we, at least initially handles the two areas separately. Let us for concretness call the sitemap aspect a block and the component aspect a bundle. Bundles --- A bundle contains one or more components and some meta info. The meta info can be about dependecies on components in other bundles it could also contain default configurations and possibly other stuff. There might be special interface bundles that only contain the apis. A bundle would typically be a jar and we would store them in repositories like ibiblio.org. We could use Maven for downloading them and resolve the dependencies and e.g. Pier's kernel for managing them an providing classloader shielding. A large part of our current blocks would be bundles rather than blocks. Most of the portal would probably be packaged as a bundle. Component management is not my main expertise, but I wouldn't be supprised if much of what we need in this area already is developed in some other projects. Blocks -- Blocks are at the sitemap level. It is like a small configurable and possibly extendable webapp the can be used as part of user webapps. Its main communication line with the rest of the application is the block protocol, it takes an URI and a request object and returns a response object. You can use it internally and/or mount its URI space so that Cocoon expose it to the external world. A block can also expose sitemap components. A block can depend on components from bundles but it doesn't expose components (at least we hope that it will be enough). A block can contain own Java code for internal use. Block can be full application frameworks like Forrest, Lenya, Linotype and possibly a portal application. A WebDAV repository could be packaged as a block. A set of webservices could also be packaged as a block. Blocks can also be smaller and more specialized things like skins or the examples Pier gave. Maybe prtlets could make sense as blocks. A large application block probably is put together from a number of small blocks. Blocks are of course also packaged, distributed and dependency resolved much like the bundles above. --- o0o --- So WDYT, does this make sense for your use cases? /Daniel
Re: Java components in blocks
On 17 Apr 2005, at 16:44, Ralph Goers wrote: Pier Fumagalli wrote: My vision is quite simple... How many _COMPONENT_ interfaces we need for Cocoon? Probably 3: Generator Transformer Serializer (well, you might have another 2 or 3 of them but do you see the point?) Please take a look at the Portal and then explain how the above works for that. There are a heck of a lot more components that someone building a portal needs to configure besides these. Sitemap components are only uses in Cocoon Portlets. While each Portal request is fired off by the PortalGenerator, it invokes a lot of elements that are configured by whoever puts together the portal. Reading through the portal (I'm no expert here), I can't really understand what ties the Portal (Pluto, and all that lot), with a Cocoon block... I think this is more in the ballpark of components rather than Cocoon blocks and pipeline services. But again, I might be wrong... Someone care to explain Pier
Re: [CocoonInAction] 2 new articles
Sylvain Wallez wrote: Look at this page : http://www.orbeon.com/community/cocoon I don't know exactly if all this information is verified, but I think this type of comparison is a good point. We looked at it, and some points in this comparison are clearly wrong. Sorry to interfere on Cocoon's dev list: I admit that I keep an eye on it, especially when I see the name of my company and product :-) Be assured that this email is written in all friendliness. As Sylvain mentioned, we met once, and I have met Bertrand (who like me operates out of Switzerland) a couple of times now, and I have no reason to believe that these two Cocoon-ers in particular are anything but great people. I would like to say that after this Orbeon PresentationServer (OPS) / Cocoon comparison was first mentioned in cocoon-dev, when it was still called the OXF platform, we got some feedback and promptly updated the page. But it's not the first time since then that I read on cocoon-dev that the comparison is incorrect / unfair / evil / heretic (because it dares pretend that something out there may do some things better than Cocoon!) - ok, I am making that up, but that's a little how it looks to me. But we have yet to get a single feedback email telling us exactly what's wrong with the current version. I don't believe the comparison can be all wrong, or even all unfair, even if there is certainly subjectivity in it, and even if we mainly mention OPS's strengths rather than weaknesses. Just looking at the main points we make: o Our belief that XForms is an excellent choice is subjective, but there are some good arguments for XForms, server-side and client-side (hey, I am giving a talk about server-side XForms at XTech 2005), and we hope to convince people who think the same to use OPS. That's not denying Sylvain's excellent work on Cocoon Forms. o We do strongly believe that the XML pipeline language in OPS beats the ... out of Cocoon pipelines ;-) By the way we now have a draft spec hosted at W3C: http://www.w3.org/Submission/2005/SUBM-xpl-20050411/ We encourage any person dealing with XML (including Cocoon-ers) to have a look at it and to submit feedback on the ops-xpl mailing-list (which intends to discuss XPL 100% independently from OPS): http://forge.objectweb.org/mail/?group_id=168 o The separation of concerns issues have been discussed on cocoon-dev by fervent Cocoon-ers: the sitemap for example is quite a mixup of different things. Of course there is some separation of concern in Cocoon, there is no denying this, but for example OPS separates clearly the concept of sitemap + page flow (which we call page flow because it declares pages as well as the relationship between them) from pipelines; the OPS page flow clearly separates page views and page models, and encourages developers to follow this model. Hence the claim that OPS has greater separation of concerns. o The OPS platform consistency has been defended on this very mailing-list by Cocoon-ers who have read the OPS documentation and/or tried the platform. On the other side I have read here from how Cocoon can be a complex web of different things that are difficult to sort out. I don't think that it is unfair for us to mention that we believe that more consistency is a benefit, and to claim that OPS has more of it. o Declarative Page Flow. Ok this is arguable, as some people will love Cocoon's JavaScript-based (and more programmatic) approach, which is very flexible and a very interesting model. So far we believe that the more declarative you get, the better. o Commitment to XML standards. See the XForms section. And also, we love having XML Schema and Relax NG tightly integrated with pipelines. We also believe that it is important to integrate XSLT 2.0 and XPath 2.0 early. So we encourage users, through documentation, tutorial and examples, to use those technologies, and that's what I call being committed to XML standards. And we also believe that this has benefits. o Minimal need for Java code. Most of the applications you build with OPS don't require any Java code. From what I've heard, Cocoon's approach is still a little different. I guess sitemap actions are pretty obsolete by now, but they are there and people keep talking about them; same for XSP. I write Java code on a daily basis, but I do think that reducing the need for Java code in the presentation layer is a very sound approach, and my definite impression is that Cocoon doesn't go as far as OPS in this respect. Follows on the comparison page a matrix comparing individual features. Maybe that's where there are issues? Then please, let us know (or let me know directly) where the problems are. It's going to be more productive than labeling the comparison matrix as unfair. Anyway, the goal of this long list was to make it a little clearer where the comparison matrix and claims in favor of OPS come from. I hope I have succeeded.
Re: Sharing sessions.. change to JDK1.5
Kumar, Kiran wrote: From: Torsten Curdt The only way to do proper synchronization is synchronize all access ...or use Dough's concurrent utils (which are now also part of java 1.5) but I am in trouble now as I cannot switch to 1.5 until some more time. It might take some time to migrate existing applications to 1.5. by the way we deploy the java on websphere AS400 You can use the concurrent utils without going to java 1.5, as far as I know... they are packaged with cocoon now. But they come as standard with java 1.5. Ben
Re: [CocoonInAction] 2 new articles
Wow wow wow... I didn't intend to trigger some kind of civil war ;o) I think that what you say, Erik, makes sense but do you really think it's the right place for that kind of advocacy. I mean... what would you think if you were in your bank talking with your banker and someone from the competitor bank on the other side of the road enters and gives arguments for his own products. Even if some are true, none of them seem fair to me. Personaly I don't think that this is the ideal spot for such a discussion. Maybe you could have made comments on Cocoon In Action website, directly related with the article at the origin of this subject, by reviewing the article of posting comments on forums. Or maybe direct emails to people concerned (like Sylvain for example). Anyway, as I said this was not my first intention, I didn't want to bring that kind of comparison to this list which is (if I remember well) dedicated do Cocoon development. So I sincerely hope that this conversation will not degenerate into some kind of ideological argue. -- Sebastien ARBOGAST
RE: Sharing sessions.. change to JDK1.5
does any give me an overview of what exactly I need to on using concurrent utils to create non-shareable DOM objects thanks Kiran Kumar (Raj) -Original Message- From: Ben Pope [mailto:[EMAIL PROTECTED] Sent: Sunday, April 17, 2005 2:44 PM To: dev@cocoon.apache.org Subject: Re: Sharing sessions.. change to JDK1.5 Kumar, Kiran wrote: From: Torsten Curdt The only way to do proper synchronization is synchronize all access ...or use Dough's concurrent utils (which are now also part of java 1.5) but I am in trouble now as I cannot switch to 1.5 until some more time. It might take some time to migrate existing applications to 1.5. by the way we deploy the java on websphere AS400 You can use the concurrent utils without going to java 1.5, as far as I know... they are packaged with cocoon now. But they come as standard with java 1.5. Ben
Re: Sharing sessions.. change to JDK1.5
Kumar, Kiran wrote: does any give me an overview of what exactly I need to on using concurrent utils to create non-shareable DOM objects We're probably in the wrong place to be discussing general concurrent programming issues. Try here for a basic guide to the concurrent package: http://java.sun.com/developer/JDCTechTips/2005/tt0216.html#1 I haven't really been following your thread here as it's not really presented in an easy-to-read format, so I'm not sure what you require. If you want to create a non-shareable DOM object don't give the other threads access to it! If you want to protect it from concurrent access, whilst allowing multiple threads to access it, at different times, then semaphores are probably what you're after. Ben
Re: [CocoonInAction] 2 new articles
Well, different people have different needs and different visions on how to develop applications. There is no right or wrong. The comparison at orbeons site may or may not be correct, but Erik and the developers over at Orbeon are trying to market their product. In doing that they made a comparison that, in my view, isn´t particularly objective. A lot of statements about cocoon have no description of the functionality or the possibilities, instead they focus on Not recommended, yes, but limited, possible but not encouraged, Undocumented. May be possible with TrAX. To me this is pure marketing junk. :) However, Erik has the right to voice his opinion on this list as has everyone else. I may not agree with him and I believe most of his claims that Orbeon is a better tool than Cocoon are based on his subjective views and nothing else. I certainly don´t want you to get offended by this mail, Erik. I merely wanted to point that people have different perspectives on things, there are probably things that are great about Orbeon and there are probably things about Cocoon that suck. However, a more in-depth comparison between the two would be interesting, maybe you could describe the process you used when you did your comparison? Best regards, Mats
Re: [CocoonInAction] 2 new articles
Mats wrote: A lot of statements about cocoon have no description of the functionality or the possibilities, instead they focus on Not recommended, yes, but limited, possible but not encouraged, Undocumented. May be possible with TrAX. To me this is pure marketing junk. :) It's interesting to know that this is the effect that comparison matrix can have. This said, I will stop mentioning the name of our project here. As Sebastien pointed out, it is a Cocoon development mailing-list. I just wanted to react to the criticism that the comparison had wrong points, and mention my frustration of not hearing specifics. Now I have heard a couple, and will try to act on that. But keep in mind that it is a very difficult exercise to compare technological solutions, and it is even more difficult to do so without being criticized. I certainly don´t want you to get offended by this mail, Erik. Not at all! -Erik
Re: [CocoonInAction] 2 new articles
Sebastien Arbogast wrote: Anyway, as I said this was not my first intention, I didn't want to bring that kind of comparison to this list which is (if I remember well) dedicated do Cocoon development. So I sincerely hope that this conversation will not degenerate into some kind of ideological argue. Don't worry, this is not going to happen. But I don't think it was out of line from my part to react in this mailing-list: I reacted directly to a particular criticism, and after all this list is public. Also, I have little hope of convincing hardcore Cocoon developers to switch to anything else. This said, don't you think that whether XForms is important or not to Cocoon, whether Cocoon pipelines should be improved or not, etc. are in fact subjects relevant to cocoon-dev? I believe there could be very sound discussions about this on this mailing-list (discussions to which I would refrain to participate because of my obvious bias). Going back into hiding now ;-) -Erik
Re: [CocoonInAction] 2 new articles
Erik Bruchez wrote: Sylvain Wallez wrote: Look at this page : http://www.orbeon.com/community/cocoon I don't know exactly if all this information is verified, but I think this type of comparison is a good point. We looked at it, and some points in this comparison are clearly wrong. Sorry to interfere on Cocoon's dev list: I admit that I keep an eye on it, especially when I see the name of my company and product :-) Be assured that this email is written in all friendliness. As Sylvain mentioned, we met once, and I have met Bertrand (who like me operates out of Switzerland) a couple of times now, and I have no reason to believe that these two Cocoon-ers in particular are anything but great people. I would like to say that after this Orbeon PresentationServer (OPS) / Cocoon comparison was first mentioned in cocoon-dev, when it was still called the OXF platform, we got some feedback and promptly updated the page. But it's not the first time since then that I read on cocoon-dev that the comparison is incorrect / unfair / evil / heretic (because it dares pretend that something out there may do some things better than Cocoon!) - ok, I am making that up, but that's a little how it looks to me. But we have yet to get a single feedback email telling us exactly what's wrong with the current version. I guess it's because that would lead us to a useless bikeshedding war between comparisons. I don't believe the comparison can be all wrong, or even all unfair, even if there is certainly subjectivity in it, and even if we mainly mention OPS's strengths rather than weaknesses. That is the exact definition of a marketing document rather than an objective comparison ;-) Just looking at the main points we make: o Our belief that XForms is an excellent choice is subjective, but there are some good arguments for XForms, server-side and client-side (hey, I am giving a talk about server-side XForms at XTech 2005), and we hope to convince people who think the same to use OPS. That's not denying Sylvain's excellent work on Cocoon Forms. IMO you did a very good job at making XForms a strong marketing item for OPS (XForms comes first in OPS docs, before the pipeline language!). But your implementation is very far from being compliant to the W3C spec, and the way you use it mixes concerns (see pipeline data below). o We do strongly believe that the XML pipeline language in OPS beats the ... out of Cocoon pipelines ;-) I admit XPL is elegant (and I told you so). There are a few points that hinder this elegance though: - it's hard to read, as it contains a lot of references to tie inputs to outputs - serializers mix concerns by defining both the XML to binary conversion (the actual serialization) and the destination of the serialized data. snip/ o The separation of concerns issues have been discussed on cocoon-dev by fervent Cocoon-ers: the sitemap for example is quite a mixup of different things. Of course there is some separation of concern in Cocoon, there is no denying this, but for example OPS separates clearly the concept of sitemap + page flow (which we call page flow because it declares pages as well as the relationship between them) from pipelines; the OPS page flow clearly separates page views and page models, and encourages developers to follow this model. Hence the claim that OPS has greater separation of concerns. So what is the map:flow about? Defining page flow controllers. It is declared in the sitemap because the sitemap is the entry point of every request coming into the system, and because sitemaps also define subcomponents in a large application. Now OPS also has its mixing of concerns in the pipeline data where a single document mixes everything: xforms instance, description of the request, page data, etc. o The OPS platform consistency has been defended on this very mailing-list by Cocoon-ers who have read the OPS documentation and/or tried the platform. On the other side I have read here from how Cocoon can be a complex web of different things that are difficult to sort out. I don't think that it is unfair for us to mention that we believe that more consistency is a benefit, and to claim that OPS has more of it. Yes, Cocoon is inconsistent in some places. But this inconsistency comes from the incredible amount of features it provides and the fact that it was built by a large group of developpers. o Declarative Page Flow. Ok this is arguable, as some people will love Cocoon's JavaScript-based (and more programmatic) approach, which is very flexible and a very interesting model. So far we believe that the more declarative you get, the better. FYI, we discussed here back in 2002 something called flowmap for months without coming to a satisfying solution, when someone came with flowscript. And programmatic page flow offers a tremendous power without much price. Any declarative page flow XML language ends up with control structure
Re: [CocoonInAction] 2 new articles
On Dom, 17 de Abril de 2005, 13:52, Sebastien Arbogast dijo: Wow wow wow... I didn't intend to trigger some kind of civil war ;o) I think this is not going to happen. AFAIK, Erick point is: Cocoon community often say the comparison matrix is not fair. OK, lets fix it. And I think this is a correct approach. This is truly fair. As other pointed out, lets better tell him where we think this is not fair. I think that what you say, Erik, makes sense but do you really think it's the right place for that kind of advocacy. I mean... what would you think if you were in your bank talking with your banker and someone from the competitor bank on the other side of the road enters and gives arguments for his own products. Even if some are true, none of them seem fair to me. We are not bankers. This is a public list. If we want to improve cocoon, lets hear what other have to said. :-) Personaly I don't think that this is the ideal spot for such a discussion. Sorry, but if not here, then where? This is the best place to discuss this. This is the official cocoon dev community mail list, I don't want to subscribe to other place or googling to know about this. Maybe you could have made comments on Cocoon In Action website, directly related with the article at the origin of this subject, by reviewing the article of posting comments on forums. Or maybe direct emails to people concerned (like Sylvain for example). Are you doing the same advocacy that you critized few lines above? ;-) Anyway, as I said this was not my first intention, I didn't want to bring that kind of comparison to this list which is (if I remember well) dedicated do Cocoon development. To me comparison is part of development. A path to improve or enhance whatever piece of code? That is good after all. ;-) So I sincerely hope that this conversation will not degenerate into some kind of ideological argue. Nope. I will like to hear Erick points and to make better the matrix posted on the orbeon website. Best Regards, Antonio Gallardo
Re: [CocoonInAction] 2 new articles
Erik Bruchez wrote: [snip] I don't believe the comparison can be all wrong, or even all unfair, even if there is certainly subjectivity in it, and even if we mainly mention OPS's strengths rather than weaknesses. Well, tell you what: rule number one of any CTO/CIO is never to believe in what a web site says about their own products, especially when comparing to other things in either speed or functionality. No matter how honest, one's view is biased. I suggest people to stop pointing fingers and move on. At the end of the day, Orbeon feels the need to draw a matrix chart and we don't. I'm sure they would be happier the other way around ;-) Just looking at the main points we make: o Our belief that XForms is an excellent choice is subjective, but there are some good arguments for XForms, server-side and client-side (hey, I am giving a talk about server-side XForms at XTech 2005), and we hope to convince people who think the same to use OPS. That's not denying Sylvain's excellent work on Cocoon Forms. o We do strongly believe that the XML pipeline language in OPS beats the ... out of Cocoon pipelines ;-) Oh, that's a bold statement :-) By the way we now have a draft spec hosted at W3C: http://www.w3.org/Submission/2005/SUBM-xpl-20050411/ We encourage any person dealing with XML (including Cocoon-ers) to have a look at it and to submit feedback on the ops-xpl mailing-list (which intends to discuss XPL 100% independently from OPS): eheh, one step up and two step back. Your pipeline language feels turing complete (haven't proved it but I think it's duable), if that is what you mean by beating the ... out of, well, we have a different definition of '...' :-) Pipeline components as first class citizens in a programming language have been something I've been thinking about for years and recently even more with Ugo's attempts to rewrite the sitemap syntax as a Groovy extension. I do see value in more expressive power, but I also see a lot of danger in introducing turing completeness in an XML syntax. Everytime I see if or foreach I puke. XSLT made that mistake first and now everybody is trying to make the same mistake. I do believe that one day cocoon will unify flowscript and sitemap and it won't probably be an XML thing (no, not even RDF), but some sort of scripting language (probably syntax sugar around groovy or javascript)... but there are a lot of ifs between now and then and don't worry, we'll keep an eye on that because there is a lot to learn from other people's mistakes ;-) http://forge.objectweb.org/mail/?group_id=168 o The separation of concerns issues have been discussed on cocoon-dev by fervent Cocoon-ers: the sitemap for example is quite a mixup of different things. Of course there is some separation of concern in Cocoon, there is no denying this, but for example OPS separates clearly the concept of sitemap + page flow (which we call page flow because it declares pages as well as the relationship between them) from pipelines; the OPS page flow clearly separates page views and page models, and encourages developers to follow this model. Hence the claim that OPS has greater separation of concerns. my SoC is bigger than yours. ROTFL, I think I have a new entry in my top 10 BS list. - o - Ok, people, enough bikeshedding. Let's get back to work. -- Stefano.
RE: [CocoonInAction] 2 new articles
my SoC is bigger than yours. Ok, people, enough bikeshedding. Let's get back to work. And all this because of an introduction to a Cocoon tutorial. Now I remember why I didn't want to write this part in the first place. Let's SHOW Cocoon's features and let everyone judge for themselves whether they want to use Cocoon or anything else. If we do it well, it'll attract the people willing to work with it and shy away those who prefer something else. Bye, Helma
Re: [CocoonInAction] 2 new articles
Sylvain Wallez wrote: That is the exact definition of a marketing document rather than an objective comparison ;-) Then I agree, it is a marketing document ;-) This is just an impossible task: when you are so into a platform or technology, how can you be actually fair to others, in spite of your efforts? Then if you were not that much into it, you would not see any benefit in comparing it with others. Validation should rather come from third-parties, but then how do you make such third-parties aware of what makes your platform different? That's a catch-22 :-) IMO you did a very good job at making XForms a strong marketing item for OPS (XForms comes first in OPS docs, before the pipeline language!). But your implementation is very far from being compliant to the W3C spec I reckon. Working on it though... I admit XPL is elegant (and I told you so). There are a few points that hinder this elegance though: - it's hard to read, as it contains a lot of references to tie inputs to outputs Debatable... But it's a little bit like variables in Java or XSLT, for example. - serializers mix concerns by defining both the XML to binary conversion (the actual serialization) and the destination of the serialized data. This has actually been fixed since then, with a split between converters and serializers. BTW this is not directly related to XPL, rather to the way it is used, the bottom line being that XPL only deals with XML infosets and doesn't know natively about text or binary. So what is the map:flow about? Defining page flow controllers. It is declared in the sitemap because the sitemap is the entry point of every request coming into the system, and because sitemaps also define subcomponents in a large application. Sounds good. Now OPS also has its mixing of concerns in the pipeline data where a single document mixes everything: xforms instance, description of the request, page data, etc. I don't think I agree with that. Those are usually available as separately named pipeline inputs and outputs (therefore separate documents / XML infosets), or requested with particular XML processors (components). If you need the result of all of those in a page view, then you may want to aggregate them. But the best practice is to create a nice page model document which contains exactly the information that needs to be presented in the page view. Yes, Cocoon is inconsistent in some places. But this inconsistency comes from the incredible amount of features it provides and the fact that it was built by a large group of developpers. Granted. -Erik
Re: [CocoonInAction] 2 new articles
A fast checking to the matrix in: http://www.orbeon.com/community/cocoon Pipeline language/Iterations -- In cocoon is posible with flow. Web Application/XForms support -- We don't nothing propetary, we are an OS project. Perhaps non-standard is a better definition for Cforms. Languages/XSLT 2.0 -- Saxon. Languages/JSP -- not encouraged, we have an special JSP block! Languages/Groovy -- built-in. Language/Javascript server side -- built-in. Document formats/PDF support -- In 2 trhough XSL-FO in 2 flavors: iText and FOP. Database support -- Built-in O/R mapping support for Apache OJB. You can also use Hibernate. Best Regards, Antonio Gallardo. On Dom, 17 de Abril de 2005, 16:56, Erik Bruchez dijo: Sylvain Wallez wrote: That is the exact definition of a marketing document rather than an objective comparison ;-) Then I agree, it is a marketing document ;-) This is just an impossible task: when you are so into a platform or technology, how can you be actually fair to others, in spite of your efforts? Then if you were not that much into it, you would not see any benefit in comparing it with others. Validation should rather come from third-parties, but then how do you make such third-parties aware of what makes your platform different? That's a catch-22 :-) IMO you did a very good job at making XForms a strong marketing item for OPS (XForms comes first in OPS docs, before the pipeline language!). But your implementation is very far from being compliant to the W3C spec I reckon. Working on it though... I admit XPL is elegant (and I told you so). There are a few points that hinder this elegance though: - it's hard to read, as it contains a lot of references to tie inputs to outputs Debatable... But it's a little bit like variables in Java or XSLT, for example. - serializers mix concerns by defining both the XML to binary conversion (the actual serialization) and the destination of the serialized data. This has actually been fixed since then, with a split between converters and serializers. BTW this is not directly related to XPL, rather to the way it is used, the bottom line being that XPL only deals with XML infosets and doesn't know natively about text or binary. So what is the map:flow about? Defining page flow controllers. It is declared in the sitemap because the sitemap is the entry point of every request coming into the system, and because sitemaps also define subcomponents in a large application. Sounds good. Now OPS also has its mixing of concerns in the pipeline data where a single document mixes everything: xforms instance, description of the request, page data, etc. I don't think I agree with that. Those are usually available as separately named pipeline inputs and outputs (therefore separate documents / XML infosets), or requested with particular XML processors (components). If you need the result of all of those in a page view, then you may want to aggregate them. But the best practice is to create a nice page model document which contains exactly the information that needs to be presented in the page view. Yes, Cocoon is inconsistent in some places. But this inconsistency comes from the incredible amount of features it provides and the fact that it was built by a large group of developpers. Granted. -Erik
Re: [CocoonInAction] 2 new articles
Antonio Gallardo wrote: A fast checking to the matrix in: http://www.orbeon.com/community/cocoon Antonio: enough. Let's move on. -- Stefano.
