Re: Adding the sitemap path to Cocoon's Request object
Gianugo Rabellino wrote: SNIP/ I am very bad in naming stuff, but I would say that something like getSitemapPath() could do the trick. Hmm, did you have a look at the Request interface in 2.2: /** * p * Returns the path to the sitemap of the requested resource as interpreted * by the sitemap. * For example, if your webapp is mounted at webapp and the HTTP request * is for webapp/foo, this method returns webapp/. Consequently, if the * request is for foo, this method returns the empty string. * /p * * @return a codeString/code containing the path to the sitemap * @since 2.2 */ String getSitemapPath(); Is this what you're looking for :) Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [OT] Personal news
Bertrand Delacretaz wrote:
Le 13 févr. 05, à 17:43, Reinhard Poetz a écrit :
...If you want to find out more about my work or me, have a look at
my new website (it's running on Cocoon 2.2) and my weblog
(http://www.poetz.cc/weblog/).
Subscribed, thanks for the news!
Subscribed? I can't find the RSS feed. Reinhard?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [OT] Personal news
Le 14 févr. 05, à 09:40, Sylvain Wallez a écrit : ...Subscribed? I can't find the RSS feed. Reinhard? hmmm...Monday over there hey? Look under All poetz.cc channels that you can subscribe. [RSS] at http://www.poetz.cc/weblog/ -Bertrand ;-) smime.p7s Description: S/MIME cryptographic signature
Re: Adding the sitemap path to Cocoon's Request object
On Mon, 14 Feb 2005 09:29:08 +0100, Carsten Ziegeler [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: SNIP/ I am very bad in naming stuff, but I would say that something like getSitemapPath() could do the trick. Hmm, did you have a look at the Request interface in 2.2: String getSitemapPath(); Is this what you're looking for :) D'OH! OK, I'm going to write 200 times every committer is supposed to check out 2.2 as well as a punishment. So, let's change the question: what's wrong in backporting this functionality to 2.1? Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: Dependencies
I pretty much use maven.xml much like a build.xml and have hadn't any real issues, you don't even need to use the ant tags namespace. Its not a question of maven, the problem I'm trying to get around is a checkout and build style build with no additional hoops to jump through. I know you guys seem to think that cocoon is in someway a better kettle of fish to struts, but checkout struts out of cvs and build look no hoops!!!. The don't let you friends commit to projects or something to that effect I noticed on this list was frankly laughable. Ant or maven cocoon needs building from source, rather than describe this as a bug with cocoon, you say its nothing to do with you and just define another hoop. Ant or maven the first step would be to have the dependencies for a release builds available on a maven style repository. Then the src of cocoon could be compiled against that, at the very least when the ant/maven file downloads the source it could be just the source and not a bunch of jar files in CVS. I'll investigate further and see if I can get some time to submit each of the dependencies to ibiblio. Basically I want to get the hoop-jumping down to pointing to the cocoon source and build (a project with a standard directory struture). Mark On Mon, 14 Feb 2005 00:46:58 +, Paul Russell [EMAIL PROTECTED] wrote: On Sun, 13 Feb 2005 19:26:44 -0500, Stefano Mazzocchi [EMAIL PROTECTED] wrote: Ralph Goers wrote: I believe what you are suggesting would require that the Cocoon build be converted to use Maven. While I personally would welcome that, this has been discussed before and for some reason several committers won't support that. Sorry. I was the one pushing back for that. Since then I've taken a deep review of Maven and I like some of the archiectural concepts. So, saying no way is a little bit too much. I would welcome if somebody tried and did it and it worked. I would tend to agree - I've used maven a little recently, despite initially disliking it, and I have to say, it works. There are significant chunks of it I still don't like (personally, I think it needs significant re-design -- I'd prefer to see it built on top of a proper plug-in architecture like Hivemind), but it does do the job well, providing you use it for what it's designed for: building one thing at a time. Try and use it the way you'd use Ant, and you're in for a bumpy ride. Personally, I've started about 5 projects internally using Maven in as many months, and none using raw Ant during the same period. But I have no energy/time/will/itch-to-scratch to do it myself. Same problem here :( Paul
Re: [OT] Personal news
On Mon, 14 Feb 2005 09:43:21 +0100, Bertrand Delacretaz [EMAIL PROTECTED] wrote: Le 14 févr. 05, à 09:40, Sylvain Wallez a écrit : ...Subscribed? I can't find the RSS feed. Reinhard? hmmm...Monday over there hey? Look under All poetz.cc channels that you can subscribe. [RSS] at http://www.poetz.cc/weblog/ It has to be monday over here as well. This is my source of the snippet, nothing I can really use: pAll apoetz.cc channels/a that you can subscribe. [RSS]/p And, meanwhile, all my best wishes as well Reinhard :-) Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance: http://www.orixo.com (blogging at http://www.rabellino.it/blog/)
Re: [OT] Personal news
Le 14 févr. 05, à 09:56, Gianugo Rabellino a écrit : ...It has to be monday over here as well. This is my source of the snippet, nothing I can really use: pAll apoetz.cc channels/a that you can subscribe. [RSS]/p Funny, here it is a href=/weblog/channels?l=enpoetz.cc channels/a that you can subscribe. [RSS]/p So a link to http://www.poetz.cc/weblog/channels?l=en -Bertrand smime.p7s Description: S/MIME cryptographic signature
[2.2] Proxies for pooled components
I just finished the work on creating proxies for pooled components. Now this is a feature that was missing in Avalon since it's creation. Why? In theory the client code for components should not need to know if the component it uses are thread safe or pooled. In fact if you're developing a thread safe component, you need to know if the components you're using are thread safe or not. In the first case, you can simply look them up in service(), in the latter you have to lookup the component (and release it) each time you use the component. So, finally I added the creation of proxies to our core. This is transparent to the client code and from a user POV you don't have to change anything. Now you can simply look up all components in service() and everything should work fine - the code isn't tested that much, but seems to work. Enabling it will hopefully find all open issues. I guess that one of the first replies to this mail will be someone stepping up and telling that pooled components are bad anyway and we should use a factory approach for pooled components (this would also reduce configuration time) etc. I'm not against doing that, but pooled components are realitity *today* and it's really annoying while implementing own thread safe components to take care of this issues. With proxies these problems go away. Additionally, proxies for pooled components open the road for setter/construction based injection, perhaps we will use that in the future... Of course, there is one drawback with proxied components: performance. I haven't done any tests there, but imho it's more important to have a working implementation than to have a buggy one that is a little bit faster. Anyways, it is possible to avoid creating proxies for pooled components if you think it's useful for your component. By specifing the attribute model with the value non-thread-safe-pooled, no proxy is created and the old behaviour is used: component role= class= model=non-thread-safe-pooled logger=../ A further optimization is that all sitemap components (generators, transformers, serializers, readers and pipelines) are used the old way : no proxy is created for them as they are dynamically assembled on each request. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Adding the sitemap path to Cocoon's Request object
Gianugo Rabellino wrote: On Mon, 14 Feb 2005 09:29:08 +0100, Carsten Ziegeler [EMAIL PROTECTED] wrote: Gianugo Rabellino wrote: SNIP/ I am very bad in naming stuff, but I would say that something like getSitemapPath() could do the trick. Hmm, did you have a look at the Request interface in 2.2: String getSitemapPath(); Is this what you're looking for :) D'OH! OK, I'm going to write 200 times every committer is supposed to check out 2.2 as well as a punishment. So, let's change the question: what's wrong in backporting this functionality to 2.1? :) My opinion is we shouldn't change contracts in maintenance releases. As backporting would change the request interface, I think we shouldn't do it. If we change contracts inbetween, we could imho just skip the versioning schema and simply use month/year as the release version :) But that's just my opinion about it. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
DO NOT REPLY [Bug 33545] - [Enh] Make StatusGenerator show Cocoon version information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33545. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33545 --- Additional Comments From [EMAIL PROTECTED] 2005-02-14 11:03 --- First of all, sorry, I overlooked that the Cocoon version had been added December 22nd. I was accidentally trying with the 2.1.6 release which did not yet have it in. But it's true, besides the Cocoon version (which is quite important and basic info if you look at a server from the outside) it would make sense to know the versions of libraries. I have mentioned Xerces and Xalan for their prominent role, but I still wonder if we could just use the Classloader to iterate all JAR files and expose version information from the Manifest (if it is in there). -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is.
[RT] Moving blocks out of the core
The more I think about it, I come to the conclusion that moving the blocks out of the core seems to be a good way to procede. (Moving files with SVN is easy and the history etc. is preserved). (Of course we should only move things for 2.2 - 2.1.x should be left untouched) Now one benefit of course is that our core gets smaller, but that's not really a reason to move things. But if we move the blocks, we *have to* think about a simple but working solution for configuration and dependencies. What do you think about the following idea: - Each block has the same structure as it has now, so we just move things. - We don't care which build system is used to build a block. - The result of a block build is a war file (cocoon block archive) - We change *our* blocks to use maven - We provide a simple deploy tool (ant task, maven plugin whatever) that takes a cocoon block archive and simply extracts it's content into the webapp directory (libs go to WEB-INF/lib etc.) - No hot deployment for now. - We require that each block has a configuration file for components that is in the xconf directory and this file is named BLOCKNAME.xconf. - The component configuration file includes all *.xconf files of the blocks required - no auto configuration for now. - Each block has an own gump descriptor and we could use this descriptor to add the dependencies to the xconf. - We provide a simple possibility that builds all available blocks (like we do today) and deploys them into the webapp. This ensures that apart from checking out, building a full cocoon (or a version with selected blocks) is still as easy as it is today. I think these are minimal changes that can be done very quickly. Using own blocks is simple as well: build an archive and use the deploy task. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
DO NOT REPLY [Bug 33556] New: - ArrayIndexOutOfBoundsException using string(.) .
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
http://issues.apache.org/bugzilla/show_bug.cgi?id=33556.
ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND·
INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=33556
Summary: ArrayIndexOutOfBoundsException using string(.) .
Product: Cocoon 2
Version: 2.1.6
Platform: PC
OS/Version: Linux
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: general components
AssignedTo: dev@cocoon.apache.org
ReportedBy: [EMAIL PROTECTED]
When using string(.) in dynamicaly generated xsl, it raise a
ArrayIndexOutOfBoundsException.
using document(.) is not working neither, even if when giving full cocoon:/ uri,
it work well.
platform is newly installed debian sarge.
Cocoon 2.1.6 installed on debian Tomcat 4.1.31-2
Cocoon policy in tomcat :
grant {
permission java.security.AllPermission;
}
--
Sitemap :
map:match pattern=easyCreaDoc-Extranet/*_conf.xsl
map:generate src=easyCreaDoc-Extranet/{1}.conf/
map:transform src=easyCreaDoc-Extranet/conf_to_xsl.xsl/
map:serialize type=xml/
/map:match
map:match pattern=easyCreaDoc-Extranet/*.conf
map:generate src=easyCreaDoc-Extranet/{1}.data/
map:transform src=cocoon:/easyCreaDoc-Extranet/{1}_conf.xsl/
map:serialize type=xml/
/map:match
-
test.conf
?xml version=1.0 encoding=UTF-8?
template_content
images-collection name=Photos de gare
image name=Lampadaires value=BU2.gif/
image name=Horloge de gare value=BO8.gif/
image name=Deux horloges de gare value=BO7.gif/
/images-collection
image-data name=Image principale default-image=Lampadaires
collection=Photos de gare editable=true/
image-data name=logo sncf default-image=Logo SNCF editable=false
image name=Logo SNCF value=sncf.gif/
/image-data
/template_content
--
test.data
?xml version=1.0 encoding=ISO-8859-15?
template_content
image-data name=Image principale value=Lampadaires/
image-data name=logo sncf value=Logo SNCF/
/template_content
--
conf_to_xsl.xsl
?xml version=1.0 encoding=UTF-8?
!--
Ce fichier XSL crée un fichier XSL à partir du fichier de configuration d'un
document EasyCreaDoc Extranet.
Le fichier XSL obtenu permettra d'intégrer les données utilisateur d'un
document EasyCreaDoc Extranet en tenant
compte des valeurs par défaut des données.
Le fichier résultant de l'intégration des données utilisateurs au fichier de
configuration sera un fichier de configuration
dont les valeurs par défaut sont les valeurs données par l'utilisateur.
--
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform; version=1.0
xmlns:axsl=http://www.w3.org/1999/XSL/TransformAlias;
xsl:output
method=xml
indent=yes
encoding=UTF-8/
xsl:namespace-alias stylesheet-prefix=axsl result-prefix=xsl/
xsl:template match=/
xsl:apply-templates select=template_content/
/xsl:template
xsl:template match=template_content
axsl:stylesheet version=1.0
axsl:template match=/
axsl:apply-templates select=template_content/
/axsl:template
axsl:template match=template_content
template_content
xsl:apply-templates/
/template_content
/axsl:template
!-- Ce template affiche une image. --
axsl:template match=image-data
axsl:param name=default-image/
axsl:param name=collection select=-1/
axsl:param name=editable select='false'/
axsl:variable name=value select=@value/
axsl:commentaxsl:value-of select=string(.) //axsl:comment
axsl:if test=$collection != -1
axsl:if
test=document('cocoon:/easyCreaDoc-Extranet/sncf_conf.xsl')/axsl:stylesheet/axsl:[EMAIL
PROTECTED]'template_content']/template_content/[EMAIL PROTECTED]/[EMAIL
PROTECTED]
image-data name=[EMAIL PROTECTED] default-image=[EMAIL
PROTECTED]
collection=[EMAIL PROTECTED] editable=true/
/axsl:if
/axsl:if
/axsl:template
/axsl:stylesheet
/xsl:template
xsl:template match=fonts-collection
xsl:copy-of select=./
/xsl:template
xsl:template match=images-collection
xsl:copy-of select=./
/xsl:template
xsl:template match=colors-collection
xsl:copy-of select=./
/xsl:template
xsl:template match=image-data
axsl:apply-templates select=.//[EMAIL PROTECTED]'[EMAIL PROTECTED]']
axsl:with-param name=default-image select='[EMAIL PROTECTED]'/
xsl:if test=@collection
axsl:with-param
Re: Real blocks - What have we reached so far?
On 13 Feb 2005, at 15:39, Carsten Ziegeler wrote: There is one question we have to ask ourselves: what is the target release for real blocks? I think we agreed that it is *not* 2.2, so I'm not sure if we should introduce the blocks.xml in 2.2. I see the potential danger that this is a signal to introduce blocks in 2.2 already and then this might delay a first release of 2.2 for a long time. Nah, I wouldn't feel they're an appropriate target for 2.2. IMVHO there's still a _lot_ to think about the structure of real blocks and how that impacts cocoon Being (probably) the only user of the kernel ATM, there are still several issues that personally I feel must be fixed, in the core of the idea of blocks themselves... I can't yet quite put my finger on what's wrong, but definitely there is something in the current code I don't like, something structurally flawed... But that's only my 0.02 £... Pier smime.p7s Description: S/MIME cryptographic signature
Re: [2.2] Proxies for pooled components
Carsten Ziegeler wrote:
I just finished the work on creating proxies for pooled components.
Now this is a feature that was missing in Avalon since it's creation.
Why? In theory the client code for components should not need to know
if the component it uses are thread safe or pooled. In fact if you're
developing a thread safe component, you need to know if the components
you're using are thread safe or not. In the first case, you can simply
look them up in service(), in the latter you have to lookup the
component (and release it) each time you use the component.
So, finally I added the creation of proxies to our core. This is
transparent to the client code and from a user POV you don't have to
change anything. Now you can simply look up all components in
service() and everything should work fine - the code isn't tested that
much, but seems to work. Enabling it will hopefully find all open issues.
I guess that one of the first replies to this mail will be someone
stepping up and telling that pooled components are bad anyway and we
should use a factory approach for pooled components (this would also
reduce configuration time) etc. I'm not against doing that, but pooled
components are realitity *today* and it's really annoying while
implementing own thread safe components to take care of this issues.
With proxies these problems go away.
First question, but not the one you expected ;-)
Can you explain what these proxies are for exactly? Is it to avoid
lookup/release at each usage? If yes, how/when are the components
actually put back in the pool (sorry, not much time to look at the code
ATM)?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [RT] Moving blocks out of the core
Carsten Ziegeler wrote: The more I think about it, I come to the conclusion that moving the blocks out of the core seems to be a good way to procede. (Moving files with SVN is easy and the history etc. is preserved). (Of course we should only move things for 2.2 - 2.1.x should be left untouched) Now one benefit of course is that our core gets smaller, but that's not really a reason to move things. But if we move the blocks, we *have to* think about a simple but working solution for configuration and dependencies. +1000 And hopefully people that develops external blocks e.g. Stefano with Linotype and maybe the Forrest and Lenya communities will be active in geting the requirements right. What do you think about the following idea: - Each block has the same structure as it has now, so we just move things. Yes, some handling of tags and branches of the invidual blocks are needed though. - We don't care which build system is used to build a block. +1 - The result of a block build is a war file (cocoon block archive) +1 - We change *our* blocks to use maven +0, seem like a separate concern to me, or will it simplify things? - We provide a simple deploy tool (ant task, maven plugin whatever) that takes a cocoon block archive and simply extracts it's content into the webapp directory (libs go to WEB-INF/lib etc.) - No hot deployment for now. +1 - We require that each block has a configuration file for components that is in the xconf directory and this file is named BLOCKNAME.xconf. - The component configuration file includes all *.xconf files of the blocks required - no auto configuration for now. - Each block has an own gump descriptor and we could use this descriptor to add the dependencies to the xconf. Would prefer if it was synchronized with Reinhard's work, but its as always up to the implementor to decide wats worthwhile. - We provide a simple possibility that builds all available blocks (like we do today) and deploys them into the webapp. This ensures that apart from checking out, building a full cocoon (or a version with selected blocks) is still as easy as it is today. +1 I think these are minimal changes that can be done very quickly. Please go ahead, IMO this is far more important than everything else on our todo lists. I think this will lead to all kinds of positive things for making development more scalable, community groth, decreasing percieved complexity, make it easier to decrease real complexity ;) etc. Using own blocks is simple as well: build an archive and use the deploy task. Carsten /Daniel
RE: Dependencies
I wrote a wiki page on that topic shortly after it was discussed on the user mailing list. http://wiki.apache.org/cocoon/HowToBuildAndDeployCocoonWithMaven Hope this help. Eric PS: Sorry for my bad English. -Original Message- From: Stefano Mazzocchi [mailto:[EMAIL PROTECTED] Sent: Sunday, February 13, 2005 7:27 PM To: dev@cocoon.apache.org Subject: Re: Dependencies Ralph Goers wrote: I believe what you are suggesting would require that the Cocoon build be converted to use Maven. While I personally would welcome that, this has been discussed before and for some reason several committers won't support that. Sorry. I was the one pushing back for that. Since then I've taken a deep review of Maven and I like some of the archiectural concepts. So, saying no way is a little bit too much. I would welcome if somebody tried and did it and it worked. But I have no energy/time/will/itch-to-scratch to do it myself. Hope this helps clarifying my position. -- Stefano.
Re: [2.2] Proxies for pooled components
Sylvain Wallez wrote: Carsten Ziegeler wrote: First question, but not the one you expected ;-) :( ;) Can you explain what these proxies are for exactly? Is it to avoid lookup/release at each usage? If yes, how/when are the components actually put back in the pool (sorry, not much time to look at the code ATM)? Oh, sure, totally forgot about it: yes, the proxies manage the lookup/release. When you look up a pooled component, you get a proxy. The first time, you invoke a method on this proxy, the real component is looked up inside proxy and then used. The component is stored locally in the proxy and the proxy uses a thread local variable. So if different threads use the same proxy, they get different instances. If there were two lookups, two proxies are created and each proxy has its own thread local. Everything is cleaned up by the end of the request. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: Real blocks - What have we reached so far?
Daniel Fagerstrom wrote: It seem like Vadim have started the work in among other places o.a.c.components.treeprocessor.sitemap.SitemapLanguage, what is the current state Vadim? You are probably referring to the changes for VPCs. Status as well as code is here: http://svn.apache.org/viewcvs.cgi/cocoon/trunk/src/java/org/apache/cocoon/generation/VirtualPipelineGenerator.java?rev=76198view=markup Status is simple example works, more work in TODOs Vadim
Re: [RT] Moving blocks out of the core
Carsten Ziegeler wrote: The more I think about it, I come to the conclusion that moving the blocks out of the core seems to be a good way to procede. (Moving files with SVN is easy and the history etc. is preserved). (Of course we should only move things for 2.2 - 2.1.x should be left untouched) Now one benefit of course is that our core gets smaller, but that's not really a reason to move things. What exactly does this mean? That the cocoon download does not contain any blocks? If users have to now selectively download blocks in addition to the cocoon core I think you'll just end up with a bunch of frustrated users. If, on the other hand, the core consisted of little more than what is needed to build the webapp and downloaded all the jars for the blocks then you'd have something. Ralph
[ann] Open Source CMS Daisy 1.2 released
Adding onto the Valentine's Day festivities, Outerthought released Daisy 1.2 today. Daisy is an Open Source content management system, composed of a standalone, ReST-accessible repository server, and a powerful, Cocoon-based Wiki-on-steroids editing and publishing application. New in this release are: In the Daisy Wiki: * an easy-to-use graphical site navigation tree editor to define site hierarchies and navigation * user self-registration with password and account reminder * a general document commenting facility with public and private comments * enhanced support for human-readable website URLs In the repository: * comprehensive support for arbitrary-sized document parts (or BLOBs), with streaming support both on front- and backend (making Daisy capable of hosting media libraries) * generalized database access layer to easily run Daisy on top of any standards-conforming relational database engine * improved full-text indexing support for MS Office document formats And of course, many other minor feature enhancements, issue fixes and performance improvements have been implemented as well. For the next release (summer 2005), planned features are: * publish-only website publishing for easy publication of non-editable Daisy sites (using the Wiki as a powerful editing application) * Daisy Books: management and production of manuals and paper documentation * more sophisticated repository versioning and querying * support for facetted classification and navigation using Daisy's metadata support * furthermore, we expect to upgrade Daisy's internals to reflect the current state of the art in component containers and messaging frameworks Daisy is available under the Apache License 2.0 from http://cocoondev.org/daisy/, with commercial support services available from http://outerthought.org/daisy.html Enjoy, /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source Java XMLAn Orixo Member Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: [RT] Moving blocks out of the core
Carsten Ziegeler wrote: The more I think about it, I come to the conclusion that moving the blocks out of the core seems to be a good way to procede. (Moving files with SVN is easy and the history etc. is preserved). (Of course we should only move things for 2.2 - 2.1.x should be left untouched) Now one benefit of course is that our core gets smaller, but that's not really a reason to move things. But if we move the blocks, we *have to* think about a simple but working solution for configuration and dependencies. What do you think about the following idea: - Each block has the same structure as it has now, so we just move things. - We don't care which build system is used to build a block. - The result of a block build is a war file (cocoon block archive) - We change *our* blocks to use maven - We provide a simple deploy tool (ant task, maven plugin whatever) that takes a cocoon block archive and simply extracts it's content into the webapp directory (libs go to WEB-INF/lib etc.) - No hot deployment for now. - We require that each block has a configuration file for components that is in the xconf directory and this file is named BLOCKNAME.xconf. - The component configuration file includes all *.xconf files of the blocks required - no auto configuration for now. - Each block has an own gump descriptor and we could use this descriptor to add the dependencies to the xconf. - We provide a simple possibility that builds all available blocks (like we do today) and deploys them into the webapp. This ensures that apart from checking out, building a full cocoon (or a version with selected blocks) is still as easy as it is today. I think these are minimal changes that can be done very quickly. Using own blocks is simple as well: build an archive and use the deploy task. +1 -- Stefano.
DO NOT REPLY [Bug 33545] - [Enh] Make StatusGenerator show Cocoon version information
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33545. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33545 --- Additional Comments From [EMAIL PROTECTED] 2005-02-14 17:38 --- In the case of the libraries it is harder. Not all jars have in MANIFEST.MF the version number. Also is important to note that the user can use saxon. The question here is if JAXP allow us to retrieve the name and version of the current Java XSLT Procesor. The same apply to Xerces. -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee. You are on the CC list for the bug, or are watching someone who is.
Re: [RT] Moving blocks out of the core
Carsten Ziegeler wrote:
The more I think about it, I come to the conclusion that moving the
blocks out of the core seems to be a good way to procede.
(Moving files with SVN is easy and the history etc. is preserved).
(Of course we should only move things for 2.2 - 2.1.x should be left
untouched)
Now one benefit of course is that our core gets smaller, but that's not
really a reason to move things.
But if we move the blocks, we *have to* think about a simple but working
solution for configuration and dependencies.
What do you think about the following idea:
- Each block has the same structure as it has now, so we just move things.
- We don't care which build system is used to build a block.
- The result of a block build is a war file (cocoon block archive)
- We change *our* blocks to use maven
- We provide a simple deploy tool (ant task, maven plugin whatever) that
takes a cocoon block archive and simply extracts it's content into the
webapp directory (libs go to WEB-INF/lib etc.) - No hot deployment for now.
- We require that each block has a configuration file for components
that is in the xconf directory and this file is named BLOCKNAME.xconf.
- The component configuration file includes all *.xconf files of the
blocks required - no auto configuration for now.
- Each block has an own gump descriptor and we could use this descriptor
to add the dependencies to the xconf.
- We provide a simple possibility that builds all available blocks (like
we do today) and deploys them into the webapp. This ensures that apart
from checking out, building a full cocoon (or a version with selected
blocks) is still as easy as it is today.
I think these are minimal changes that can be done very quickly.
Using own blocks is simple as well: build an archive and use the deploy
task.
Carsten
I'm going to comment on this tomorrow.
--
Reinhard Pötz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
CForms: ScriptableWidget?
I'm wondering if we need the ScriptableWidget class? We recently decided to not support the syntactic sugar flow could provide. I can't find any reference where this class is used. So can we just delete it? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de
Re: [OT] Personal news
Gianugo Rabellino wrote:
On Mon, 14 Feb 2005 09:43:21 +0100, Bertrand Delacretaz
[EMAIL PROTECTED] wrote:
Le 14 févr. 05, à 09:40, Sylvain Wallez a écrit :
...Subscribed? I can't find the RSS feed. Reinhard?
hmmm...Monday over there hey?
Look under All poetz.cc channels that you can subscribe. [RSS]
at http://www.poetz.cc/weblog/
It has to be monday over here as well. This is my source of the
snippet, nothing I can really use:
pAll apoetz.cc channels/a that you can subscribe. [RSS]/p
And, meanwhile, all my best wishes as well Reinhard :-)
Ciao,
Really strange. Maybe a Xalan bug because a stylesheet rewrites all links.
Anyway, http://www.poetz.cc/weblog/all?as=rss should be the link you're looking
for.
http://www.poetz.cc/weblog/channels has a list with all available channels.
--
Reinhard Pötz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [OT] Personal news
Stefano Mazzocchi wrote:
Sylvain Wallez wrote:
Reinhard Poetz wrote:
As some of you have asked me off-list about my job and my plans I
want to answer in public. In October last year I quit my job at my
former company (a SAP consulting company where I worked as freelancer
about 20 hours a week) and I decided to concentrate 100 % on
training, consulting and coaching services around web applications
(especially Cocoon and J2EE), software engineering and incorporating
open source.
There are some further plans but they need more time before they are
ready to be announced in public :-)
This (my current work _and_ my future plans) also means that I can
dedicate much more time to the Cocoon project. Look at
http://www.poetz.cc/opensource/agenda to find out more about my
current plans. I'm trying to keep this document up to date.
If you want to find out more about my work or me, have a look at my
new website (it's running on Cocoon 2.2) and my weblog
(http://www.poetz.cc/weblog/).
I wish you the best for this job, and I'm happy that it will allow you
to get more involved in Cocoon!
Not a job in the meaning of working for an employer but as independant
consultant/trainer/coach :-)
Same here!
Thank you all!
--
Reinhard Pötz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
DO NOT REPLY [Bug 33569] New: - http://www.fivestaralliance.com Five Star Alliance -- Search and Book the World's Finest Hotels
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=33569. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=33569 Summary: http://www.fivestaralliance.com Five Star Alliance -- Search and Book the World's Finest Hotels Product: Cocoon 2 Version: Current SVN 2.2 Platform: All URL: http://www.fivestaralliance.com OS/Version: All Status: NEW Severity: enhancement Priority: P2 Component: Documentation AssignedTo: dev@cocoon.apache.org ReportedBy: [EMAIL PROTECTED] URL: http://www.fivestaralliance.com Title: Five Star Alliance -- Search and Book the World's Finest Hotels Description: Online Luxury Hotel Reservation Service Quoin built a sophisticated ecommerce site for Five Star Alliance, an online service to search and book luxury hotel travel. We collaborated with the client to produce a site that exhibits extraordinary performance and a user-friendly design. The prominent features of the site include intuitve tools for searching luxury hotels by name, location, features, and amenities. A Virtual Travel Agent is also available to guide users through a step-by-step process for finding a hotel.. Our project team worked with the client to implement a range of techniques for search engine optimization, including generating metadata from dynamic page content, creating search results pages which can be cached, and using simple static URIs to support page indexing. A key part of the system architecture was integration with a third-party information service, which required use of an XML-based API for requesting hotel information, rates, and reservations. The 15-week project demonstrated our capability to provide on-time delivery of a fixed-cost project. Quoin continues to implement enhancements and give ongoing support for this system. Technologies: J2EE, Apache Cocoon, CForms, JUnit, CSS, Javascript, XHTML, PostgresSQL, Apache Ant, CVS, Quoin Delivery Process Please contact: [EMAIL PROTECTED] -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug, or are watching the assignee.
Re: [RT] Moving blocks out of the core
Le 14 févr. 05, à 11:14, Carsten Ziegeler a écrit : ...I think these are minimal changes that can be done very quickly... Then big +1, having a smaller core is also important for the *perception* of Cocoon being the lean and mean tool that it is. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: CForms: ScriptableWidget?
Carsten Ziegeler wrote:
I'm wondering if we need the ScriptableWidget class? We recently
decided to not support the syntactic sugar flow could provide. I can't
find any reference where this class is used. So can we just delete it?
It's used in Form.js for form.model. The trick (or hack, or
inconsistency) is that
defineClass(org.apache.cocoon.forms.flow.javascript.ScriptableWidget);
in Form.js defines a JS class named Widget (see
ScriptableWidget.getClassName()).
This class will go away with form.model.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [2.2] Proxies for pooled components
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
First question, but not the one you expected ;-)
:( ;)
Can you explain what these proxies are for exactly? Is it to avoid
lookup/release at each usage? If yes, how/when are the components
actually put back in the pool (sorry, not much time to look at the
code ATM)?
Oh, sure, totally forgot about it: yes, the proxies manage the
lookup/release. When you look up a pooled component, you get a proxy.
The first time, you invoke a method on this proxy, the real component
is looked up inside proxy and then used. The component is stored
locally in the proxy and the proxy uses a thread local variable. So if
different threads use the same proxy, they get different instances. If
there were two lookups, two proxies are created and each proxy has its
own thread local.
And what if there are several lookups for the same role within the same
thread? Is the same component used? That may lead to strange behaviours
with stateful components (and if they are pooled, it's because they are
stateful), as the state will be shared between the different usage
locations of the component, which are very likely to not know each other.
This is certainly an interesting feature, but I'm not sure it will be
usable with that many components.
WDYT? Do you have some uses cases?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: [2.2] Proxies for pooled components
Sylvain Wallez wrote: Carsten Ziegeler wrote: Sylvain Wallez wrote: First question, but not the one you expected ;-) :( ;) Can you explain what these proxies are for exactly? Is it to avoid lookup/release at each usage? If yes, how/when are the components actually put back in the pool (sorry, not much time to look at the code ATM)? Oh, sure, totally forgot about it: yes, the proxies manage the lookup/release. When you look up a pooled component, you get a proxy. The first time, you invoke a method on this proxy, the real component is looked up inside proxy and then used. The component is stored locally in the proxy and the proxy uses a thread local variable. So if different threads use the same proxy, they get different instances. If there were two lookups, two proxies are created and each proxy has its own thread local. And what if there are several lookups for the same role within the same thread? Is the same component used? No no, it is not - these are different components. That may lead to strange behaviours with stateful components (and if they are pooled, it's because they are stateful), as the state will be shared between the different usage locations of the component, which are very likely to not know each other. As these are different components, I don't see a problem here. This is certainly an interesting feature, but I'm not sure it will be usable with that many components. WDYT? Do you have some uses cases? Sure: developing an own thread safe component that uses other components. With proxies you can simply lookup all components in the service() method and use them. Without proxies you can lookup other thread safe components in service() but pooled components have to be looked up each time they're used. So this simplifies component development. And as I indicated, it also opens the road for constructor/setter based injection as injected components need to be thread safe. Usually pooled components are not thread safe, proxied pooled components are. Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
Re: [2.2] Proxies for pooled components
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
First question, but not the one you expected ;-)
:( ;)
Can you explain what these proxies are for exactly? Is it to avoid
lookup/release at each usage? If yes, how/when are the components
actually put back in the pool (sorry, not much time to look at the
code ATM)?
Oh, sure, totally forgot about it: yes, the proxies manage the
lookup/release. When you look up a pooled component, you get a
proxy. The first time, you invoke a method on this proxy, the real
component is looked up inside proxy and then used. The component is
stored locally in the proxy and the proxy uses a thread local
variable. So if different threads use the same proxy, they get
different instances. If there were two lookups, two proxies are
created and each proxy has its own thread local.
And what if there are several lookups for the same role within the
same thread? Is the same component used?
No no, it is not - these are different components.
That may lead to strange behaviours
with stateful components (and if they are pooled, it's because they
are stateful), as the state will be shared between the different
usage locations of the component, which are very likely to not know
each other.
As these are different components, I don't see a problem here.
This is certainly an interesting feature, but I'm not sure it will be
usable with that many components.
WDYT? Do you have some uses cases?
Sure: developing an own thread safe component that uses other
components. With proxies you can simply lookup all components in the
service() method and use them.
Without proxies you can lookup other thread safe components in
service() but pooled components have to be looked up each time they're
used.
I see. So there's a different proxy returned at each call to lookup(),
and that proxy has its own ThreadLocal to track actual components. IIRC,
Hivemind provides this. Don't know about Spring, but it certainly could
be done with a custom BeanFactory.
So this simplifies component development. And as I indicated, it also
opens the road for constructor/setter based injection as injected
components need to be thread safe.
I remember of some people having some OutOfMemoryError exceptions when
using some RequestLifeCycle components in complicated pipelines
involving many subrequests, because the RLC components weren't released
even if they actually were no more useful. Automatic pool management may
lead to the same kind of problems, don't you think?
Or what we need is that the proxy tracks some methods that indicate end
of use of the proxied component that can then go back to the pool before
the end of the request (e.g. connection.close() or
contenthandler.endDocument())
But all this will complexify a lot the small CoreManager and I'm
wondering if this is a good idea to write yet another dependency
injection container when some widely used ones already exist. Ask Ugo,
which one he prefers ;-)
Usually pooled components are not thread safe, proxied pooled
components are.
Yup. Cool.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: svn commit: r151736 - in cocoon/trunk: ./ lib/ lib/optional/ src/blocks/javaflow/ src/blocks/javaflow/WEB-INF/xconf/ src/blocks/javaflow/java/org/apache/cocoon/components/flow/java/ src/blocks/javaflow/samples/ src/blocks/paranoid/java/org/apache/cocoon/servlet/ src/webapp/WEB-INF/ src/webapp/WEB-INF/compile/ src/webapp/WEB-INF/compile/org/ src/webapp/WEB-INF/compile/org/apache/cocoon/components/flow/java/ src/webapp/WEB-INF/compile/org/apache/cocoon/forms/flow/java/ src/webapp/WEB-INF/compile/org/apache/cocoon/samples/flow/java/ src/webapp/WEB-INF/src/
cocoon/trunk/lib/optional/commons-javaflow-0.1-dev.jar (with props) cocoon/trunk/lib/optional/commons-jci-0.1-dev.jar (with props) Snapshot jars should have timestamp in the file name, as we agreed (and for SVN snapshots, imho, revision number). Sorry, I am a lazy bastard ;-) ...will fix that on the next upgrade. I think using a revision number makes the most sense. We should use this approach for all snapshot jars that come from svn. cheers -- Torsten signature.asc Description: OpenPGP digital signature
Re: Status new Cocoon documentation
Reinhard Poetz wrote:
Last week Upayavira and I spent some time to overhaul the structure of the
two
document repositories:
- http://brutus.apache.org/docs/build/cocoon-doco-2-2/
- http://brutus.apache.org/docs/build/cocoon-doco-global/
We think that it covers all Cocoon relevant topics and is a good starting
point
to evaluate and move over all existing documents. As this will be a lot of
work
we need all the help we can get.
Check out http://wiki.apache.org/cocoon/CocoonDocumentationSystemHowTo what
you
have to do actually.
Apart from helping to move over docs into our new repositories, my next
steps
are to:
1. finish my work on forrest repositories (comment and metadata part)
2. make the two repositories (currently they are in
http://svn.a.o/r/a(cocoon/whiteboard/doc-repos) the official doc
repositories
of Cocoon 2.2 and move them over to the appropriate places (I will call
for a
vote on this very soon)
Here is one thing that i cannot grasp yet:
How will the automatically generated Sitemap Component Documentation
(i.e. the old /userdocs/) fit in with these static repositories?
Currently we need to run 'build docs' to prepare them, then do 'forrest'.
http://cocoon.apache.org/2.1/plan/review-sitemap-docs.html
--David
3. call for help on [EMAIL PROTECTED] (writing docs)
4. work the online editor for docs (Jeremy, thanks again for your work on
how
to access SVN using webdav!!!)
--
Reinhard P?tz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
cocoon-reload bug
latest checkout from 2.2, turn allow-reload true in web.xml and when I hit a page with 'cocoon-reload=true' I get an IllegalStateException: The cocoon-ehcache-4 Cache is not alive. which goes away as soon as I reload it. I can't be the only one hitting this how do you guys develop on cocoon without reloading? -- Stefano.
Re: Adding the sitemap path to Cocoon's Request object
Carsten Ziegeler wrote:
Gianugo Rabellino wrote:
On Mon, 14 Feb 2005 09:29:08 +0100, Carsten Ziegeler
[EMAIL PROTECTED] wrote:
Gianugo Rabellino wrote:
SNIP/
I am very bad in naming
stuff, but I would say that something like getSitemapPath() could do
the
trick.
Hmm, did you have a look at the Request interface in 2.2:
String getSitemapPath();
Is this what you're looking for :)
D'OH! OK, I'm going to write 200 times every committer is supposed to
check out 2.2 as well as a punishment.
So, let's change the question: what's wrong in backporting this
functionality to 2.1?
:) My opinion is we shouldn't change contracts in maintenance releases.
+1
As backporting would change the request interface, I think we shouldn't
do it. If we change contracts inbetween, we could imho just skip the
versioning schema and simply use month/year as the release version :)
But that's just my opinion about it.
--
Reinhard Pötz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: Real blocks - What have we reached so far?
Pier Fumagalli wrote:
On 13 Feb 2005, at 15:39, Carsten Ziegeler wrote:
There is one question we have to ask ourselves: what is the target
release for real blocks? I think we agreed that it is *not* 2.2, so
I'm not sure if we should introduce the blocks.xml in 2.2. I see the
potential danger that this is a signal to introduce blocks in 2.2
already and then this might delay a first release of 2.2 for a long time.
Nah, I wouldn't feel they're an appropriate target for 2.2.
That is Carsten's and my opinion too.
IMVHO
there's still a _lot_ to think about the structure of real blocks and
how that impacts cocoon
can you elaborate on a _lot_? I'm Just curious to get a sense of the to be
expected workload :-)
--
Reinhard Pötz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [RT] Moving blocks out of the core
Ralph Goers wrote:
Carsten Ziegeler wrote:
The more I think about it, I come to the conclusion that moving the
blocks out of the core seems to be a good way to procede.
(Moving files with SVN is easy and the history etc. is preserved).
(Of course we should only move things for 2.2 - 2.1.x should be left
untouched)
Now one benefit of course is that our core gets smaller, but that's
not really a reason to move things.
What exactly does this mean? That the cocoon download does not contain
any blocks?
It's too early for this step. This requires a working distribution mechanism
(see the BlockDeployer --
http://svn.apache.org/repos/asf/cocoon/whiteboard/block-deployer/)
If users have to now selectively download blocks in
addition to the cocoon core I think you'll just end up with a bunch of
frustrated users. If, on the other hand, the core consisted of little
more than what is needed to build the webapp and downloaded all the jars
for the blocks then you'd have something.
I propose having a very small distribution (Cocoon core + core blocks which are
IMO CocoonForms, Templating and JavaFlow) and a complete distribution with all
blocks included.
--
Reinhard Pötz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [RT] Moving blocks out of the core
Carsten Ziegeler wrote:
The more I think about it, I come to the conclusion that moving the
blocks out of the core seems to be a good way to procede.
(Moving files with SVN is easy and the history etc. is preserved).
(Of course we should only move things for 2.2 - 2.1.x should be left
untouched)
Now one benefit of course is that our core gets smaller, but that's not
really a reason to move things.
But if we move the blocks, we *have to* think about a simple but working
solution for configuration and dependencies.
What do you think about the following idea:
- Each block has the same structure as it has now, so we just move things.
- We don't care which build system is used to build a block.
- The result of a block build is a war file (cocoon block archive)
- We change *our* blocks to use maven
- We provide a simple deploy tool (ant task, maven plugin whatever) that
takes a cocoon block archive and simply extracts it's content into the
webapp directory (libs go to WEB-INF/lib etc.) - No hot deployment for now.
- We require that each block has a configuration file for components
that is in the xconf directory and this file is named BLOCKNAME.xconf.
- The component configuration file includes all *.xconf files of the
blocks required - no auto configuration for now.
- Each block has an own gump descriptor and we could use this descriptor
to add the dependencies to the xconf.
- We provide a simple possibility that builds all available blocks (like
we do today) and deploys them into the webapp. This ensures that apart
from checking out, building a full cocoon (or a version with selected
blocks) is still as easy as it is today.
I think these are minimal changes that can be done very quickly.
Using own blocks is simple as well: build an archive and use the deploy
task.
Look at http://svn.apache.org/repos/asf/cocoon/whiteboard/block-builder/, which
provides nearly everything you describe above. Additionally it resolves
dependencies between blocks which makes it possible to work on a single block
without taking care of other, non-related blocks.
The only prerequisite is a descriptor file like block.xml that consists of
- general meta information (author, license, ...)
- required blocks
- required libraries
block.xml is versioned by a doctype like http://apache.org/cocoon/blocks/1.0.
This information isn't useful right now but will help the future
Block*Deployer* to indentify if a block and a Cocoon core version fit together.
If nobody objects I would setup the BlockBuilder for Cocoon 2.2 and for the
portal block (+ all blocks it depends on) over the next weekend. Afterwards we
can evaluate if _we_ like it or not.
Until now I've hesitated to propose using the BlockBuilder because I've thought
that it requires a fully useable deployment tool. But if we follow Carsten's
idea of a simple deployment tool (unpacking) this isn't a problem any more.
WDYT?
--
Reinhard Pötz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Re: [2.2] Dynamic xconf try to open non-existing files (bug?)
Daniel Fagerstrom wrote:
Carsten Ziegeler wrote:
Daniel Fagerstrom wrote:
I would prefer generating gump.xml from block.xml. It will be easier to
develop and deploy (external) blocks if all info about them is contained
within the block. Also it is better to have a block.xml format that not
is dependent on gump's format as it allow us to put all info that we
want to have about blocks in that file.
IIRC we went for the gump solution as we where concerned about the lack
of robustness in generating the gump.xml on demand. Also the gump format
was close enough for our needs back then. But now I think that the
centralized gump.xml is in the way for a smooth evolution towards real
blocks. The robustness issue can maybe be handled in other ways, e.g.
compile time checks of the block.xml, so that no one happens to check in
a faulty block.xml that kills the compilation.
Thinking further about it: could not the blocks be own Gump sub projects
that depends on Cocoon core? If that is possible it would only be
necessary to have a list of the blocks that we want to have checked by
Gump, no need for a centralized list containing all block dependencies.
I think we should really start and move all blocks out of the core
(for 2.2 - 2.1.x should stay as is) and then it would make sense for
me to have
an own gump descriptor for each block.
+1
I think part of the work concerning design and implementation of
compiling blocks based on a blocks descriptor is allready done by
Reinhard in http://wiki.apache.org/cocoon/BlockBuilder and
http://svn.apache.org/viewcvs.cgi/cocoon/whiteboard/block-builder/.
Reinhard, needs to be done to achive that?
see my other mail - if nobody objects I will setup the block-builder in Cocoon
2.2 over the weekend. Then we can decide if we like it or not.
I also agree that it's better to generate the gump descriptor from the
block descriptor than vice versa. If we go this road, there is only
one issue to solve: how does Cocoon know which blocks are available?
Just scanning the src/blocks directory isn't enough. Blocks can be
anywhere in the file system. The current build system is able to
include blocks from any location.
That's the task for Reinhard's block deployer, but as it AFAIU is
targeted more for real blocks than for the current ones, it might be
overly ambitious to start using it now.
The design of the block deployer could cover the blocks that we have now too.
But the implementation isn't far enough.
In the mean time, replacing the
blocks.properties with a list of paths to the blocks that one want to
use might be enough.
We also need to decide where we should put the blocks in the SVN, we
could follow Reinhard's approach in the block-builder and moving the
trunk/src/blocks/ directory to the top level and inserting a trunk
directory:
/cocoon/blocks/forms/trunk/
...
However IMO we should as a service to our users and ourselves, be a
little bit more explicit in how much trust one can put in the various
blocks and have something like:
core-blocks
supported-blocks
unsupported-blocks
Where everything goes to unsupported-blocks and promotion to core and
supported is based on votes. OTH, moving the blocks out of trunk and
indicating community support level are different concerns so we could do
one at a time and I think moving out the blocks should have highest
priority.
WDYT?
What about
/cocoon/blocks/core/
/cocoon/blocks/supported/
/cocoon/blocks/unsupported/
I like the structure but which one of the three directories would be the
appropriate one for the templating block?
--
Reinhard Pötz Independant Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
Building webapp resources
Hello My appologies for asking aquestion not directly related to the development of cocoon but I need some authoritive input on an issue. I'm working on a project where my predecesors deemed it nessesary to have individual build processes for each sub directory/module in the webapp. The build process does nothing more than merge various sitemap fragments into a a single sitemap file. There's little to be gained and the rationalisation could/should take place by using the sitemap heirarchy rather than merging like this. Now my question is what views do you have regarding this sort of nonesense. To my mind while MVC might be maintained in terms of the where all the code is and how it interacts, the practical implications are that a site builder/editor cant work on the resources without building the project. I'd like to confirm that cocoon developers consider it good practice to have the web app resources as relativly static and inituitive for site builders/editors to work on non java stuff without getting bogged down in crack induced sub builds. Again I know this isn't a cocoon dev question but your input will be invaluable. Mark
