Servlets, Sitemaps, and Spring in trunk
Hi everyone, I've been looking at trunk to find out how things work these days and it looks great, but I am a bit confused. It seems like the blocks can register their own servlet to handle requests, is that true? There is a suspicious xml file in META-INF/cocoon/spring in each sample. But how does spring, or is it avalon, know that this servlet should be used at all? Through DispatcherServlet? It doesn't seem to work right now though, at least not if I use the cocoon-webapp. Is there an easy way to make it work? I'm trying to do some json stuff, so a detour through cocoon would not be so great. Thanks for the help! Bye, Max
Re: [vote] Jeroen Reijn as a new Cocoon committer
Andrew Savory wrote: Hi, I'd like to propose Jeroen Reijn as a Cocoon committer. Definitely +1! Bye, max
Re: RFC: CForms Roadmap
Hi everyone, This is very interesting! I would love to help, but I have like 5 projects going on in the university and otherwise... However, two of them are geared at the web, so this might be interesting to investigate. By the way, has anything improved authentication-wise in Cocoon? I haven't quite followed the development in the last few months, but with the real blocks and so on, it's getting more interesting for the kind of web application I have in mind. (for which I would use struts2 otherwise *shiver*) Anyway, I can't commit much time right now, but I'll definitely have a look when I get home! Bye, and take care! max Jeremy Quinn wrote: Hi All Now that Cocoon 2.1.11-dev runs Dojo 0.4.1, I think we have a solid platform to complete the modernisation of CForms client-side code. I hope the main outcomes of this will be : Leaner: only the resources that are used will be loaded by cforms Richer: more interactive widgets with wider x-platform support Cleaner: eliminate most of the messy script tags scattered through our forms Simpler: use more html templates to simplify our xslt (and simpler to adapt the widgets) Here is a list of specific goals I would love us to achieve for the next release. I hope to be working on this stuff, you would be very welcome if you'd like to join in If you would like to take on something from this list (or something I missed out) please discuss it on the dev list so no-one is duplicating effort. Replacements : Date/Time widget : replace MattKruse stuff with Dojo's implementation. Help validation popups: replace MattKruse stuff with a new Dojo implementation. Tabs: replace with Dojo Tabs RichText: replace htmlarea with Dojo Editor, using a new fi:styling, so htmlarea can still be used MultiValue Editor: re-implement as a Dojo widget MultiList (OptionTransfer) Selector: replace with a new Dojo widget Maps: not even sure our current one is working, replace with Dojo (Yahoo and Google) Possible Additions : Easy graphically rich buttons, dialogs, menus etc. Charts to plot user data Colour picker Re-sizable textarea Sliders: graphical selector for number ranges etc. Spinner: adjust values up and down with ± buttons Validation: plug in client-side validation where common datatypes exist between CForms and Dojo, make new ones Issues: We need to do this work in such a way that has the absolute minimum impact on existing cforms projects. eg. adapting Dojo widgets to work the CForms way and not the other way around. We need to make it easier to customise the style, layout and behaviour of our supplied widgets. We are probably going to have issues with i18n and l10n. Dojo is only just starting to deal with this area, while CForms has always delt with it. Dojo, performs i18n on the client instead of on the server as cforms does. Very few of Dojo's widgets are i18n enabled yet. Dojo uses a different format of i18n message dictionary than we do (all of this is kind of obvious). Most of the work above will involve either extending existing dojo widgets or making new ones. We ought to be adding i18n/l10n as we go along. We need to decide whether we want to keep our message dictionary format (transforming it on the fly for dojo) or start using Dojo's format (for widget internals). What did I miss out ? I hope this whets your appetite ! Let's get on with the replacements first !! WDYT ? regards Jeremy
RE: [Vote] Ard Schrijvers as a new Cocoon committer
I want to propose Ard Schrijvers as a new Cocoon committer. Please cast your votes! definitely +1! max
RE: [RT] Mini-Cocoon
Hi! I really like the idea to make cleancut interfaces between core components and factoring them out. What I would really look forward to would be an abstraction of the processor level. That would allow us to do cool rails-like things by implementing an MVC processor :). Berin hat this idea a while ago [1]. Having a processor implementation would allow us to simply map:mount an mcv component into publishy sitemap uri spaces, for example for the ever-recurring polls and so on, while not polluting the sitemap language. Flowscript might be ok for smaller controlling needs, but I think a dedicated java implementation would go a long way. Think of debugging for one thing. Integrating Javaflow would be nice though for the stateful controllers. Bye! max [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112869422207312w=2 -Original Message- From: Daniel Fagerstrom [mailto:[EMAIL PROTECTED] Sent: Saturday, April 15, 2006 14:01 To: dev@cocoon.apache.org Subject: Re: [RT] Mini-Cocoon Bertrand Delacretaz skrev: Hi Don, Le 14 avr. 06 à 21:13, Don Brown a écrit : ... - We only need transformers and serializers, the framework would handle the generation (implicitly a SAX parser generator would be used to process the response's outputstream) - Ideally no additional dependencies - The pipeline impl should be small, and focused - Very little to no additional configuration for the user. A set of transformers and serializers would be defined somewhere, and stacks, or statically defined pipelines. No selectors, matchers, or other sitemap capabilies would be needed. .. What you suggest echoes our discussions from a last December [1], and I think there's definite interest in our community to see Cocoon delivered in smaller independent packages. At least at the talking about it level...but let's hope your message prompts some people to stand up. Maybe some of the people working on 2.2 can comment about this? How could the new structure of 2.2 help using our sitemap components outside of Cocoon? Personally I'd love to help, but to be realistic I won't be able to commit serious time to such a project in the next few weeks. Except maybe mentoring or co-mentoring a Summer Of Code project to experiment with refactoring some of our sitemap components to be usable in a lighter environment. -Bertrand [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113380354129554w=2 Splitting Cocoon core is on my todo-list, I wrote something about it a while ago: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=113682736011081w=2. An important question is of course what blocks to split core into and what the contracts should be for these blocks. /Daniel
RE: CachingSource
Hi!
Core would be best as it is very general and all the cache related things are
there as well.
I can do it today, but what about the codefreeze?
Btw, Jeremy, I don't think the caching source factory is dependent on the
eventcache block. AFAIR, it talks to the Cache interface.
max
-Original Message-
From: Reinhard Poetz [mailto:[EMAIL PROTECTED]
Sent: Friday, March 31, 2006 13:24
To: dev@cocoon.apache.org
Subject: Re: CachingSource
Jeremy Quinn wrote:
Hi All
I was wondering what happened to the CachingSource?
I used to be in the scratchpad.
Has another technique replaced this?
I am using 2.1.9-dev. I would like to force cache
(time-based) some
calls to a Webservice API, that are otherwise uncachable. I
was hoping
to do something like :
caching:cocoon:/call-the-api-blah-blah
Any suggestions ?
any takers to move the CachingSource into a block or core?
--
Reinhard Pötz Independent Consultant, Trainer (IT)-Coach
{Software Engineering, Open Source, Web Applications, Apache Cocoon}
web(log): http://www.poetz.cc
___
Telefonate ohne weitere Kosten vom PC zum PC:
http://messenger.yahoo.de
RE: [vote] Niclas Hedhman as a new Cocoon committer
Please cast your votes. +1 max
RE: [vote] Simone Gianni as a new Cocoon committer
Please cast your votes. +1 max
jdk 5 needed to build trunk?
Hi! I have a problem building trunk right now, o.a.c.blocks.BlockConnection uses the java.net.URL API from Java 5. URL.toURI() doesn't exist in 1.4.2. Can I replace it by new URI(url.toString())? Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
RE: error handling causes NPE? (was: error handling in aggregations)
Hi! Yes, I'll change the one in trunk as well today. It's funny, because I only use the ContentAggregator, the XMLSerializer and the FileGenerator. I have to investigate a little more in which configuration this actually happens, but I am fairly sure that the ContentAggregator (the only place where a SitemapSource is used) releases everything correctly. Since this only seems to happen when an Exception is thrown during processing, I thought that maybe there is an error deeper in the error handling code. Something like a missing finally... The error is rather hard to notice because if you use cocoon servlet, it actually doesn't show it. I noticed it in my little test project. I hope it's again something I did wrong, I'll keep you guys up to date. max -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 09:59 To: dev@cocoon.apache.org Subject: Re: error handling causes NPE? (was: error handling in aggregations) Max Pfingsthorn schrieb: Hi! Err, guys, can it be that the sources aren't released correctly after a ProcessingException during pipeline execution? I get the same NPE I did when I didn't release a sitemap source correctly a while ago after I apply this patch to 2.1.8... Any ideas? Usually the pipeline components release the sources in their recycle() method. So could it be that you have a buggy component in your pipeline? PS: Can you apply your changes to the ContentAggregator to trunk as well, please? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
RE: error handling causes NPE? (was: error handling in aggregations)
Hi! I know, but I haven't quite been able to use the samples. The changes to AbstractCachingProcessingPipeline are extensive and I wouldn't feel comfortable patching the trunk version without testing it first. (Changes to DefaultContentAggregator were very minor). Can someone point me to a guide how to get the samples running in trunk? max -Original Message- From: Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED] Sent: Wednesday, March 22, 2006 16:54 To: dev@cocoon.apache.org Subject: Re: error handling causes NPE? (was: error handling in aggregations) * Max Pfingsthorn: Yes, I'll change the one in trunk as well today. Hello Max, While you're at it, there's also the AbstractCachingProcessingPipeline that needs an update in trunk. TIA, -- Jean-Baptiste Quenot http://caraldi.com/jbq/
RE: [Vote] Release plan for 2.1.9
So the proposed plan to release 2.1.9 is: - Start code freeze on the 31st of March - Release on the 6th of April (if nothing bad happens) +1 max
RE: error handling in aggregations
Hi!
Yes, this works well. I've tested it and with 'when=external' on
'map:handle-errors', it does stop the serializer from dumping the data before
the error page. Also, 'when=internal' works wonderfully inside the aggregate!
I would be all for this change before 2.1.9 comes out. If noone objects, I'll
commit it within the hour.
max
-Original Message-
From: Bruno Dumon [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 19, 2006 14:33
To: dev@cocoon.apache.org
Subject: Re: error handling in aggregations
On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote:
Hi All
Investigating this further, I came up with this simplest possible
sitemap to reproduce the problem :
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:generators default=file
map:generator name=file label=content
logger=sitemap.generator.file pool-grow=4 pool-max=32 pool-
min=4 src=org.apache.cocoon.generation.FileGenerator/
/map:generators
map:serializers default=xml
map:serializer name=xml logger=sitemap.serializer.xml
mime-type=text/xml pool-grow=4 pool-max=32 pool-min=4
src=org.apache.cocoon.serialization.XMLSerializer/
/map:serializers
map:matchers default=wildcard
map:matcher logger=sitemap.matcher.wildcard
name=wildcard
src=org.apache.cocoon.matching.WildcardURIMatcher/
/map:matchers
map:pipes default=noncaching
map:pipe logger=sitemap.pipes.noncaching
name=noncaching
src=org.apache.cocoon.components.pipeline.impl.NonCachingProc
essingPipe
line
parameter name=outputBufferSize value=32768/
/map:pipe
/map:pipes
/map:components
map:pipelines
map:pipeline internal-only=false type=noncaching
map:match pattern=test
map:aggregate element=site
map:part element=content1 src=nothing.xml/
map:part element=content2 src=nothingelse.xml/
/map:aggregate
map:serialize type=xml /
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
I set this up as the top-level sitemap, loaded by cocoon.xconf.
I access the url and I get this :
$ curl http://localhost:/test
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//
sitehtmlheadtitleResource Not Found/titlestyle!--body
{ background-color: white; color: black; font-family: verdana,
helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px
20px 0px;
border-width: 0px 0px 1px 0px; border-style: solid; border-color:
#336699;}p.footer { color: #336699; border-width: 1px 0px 0px 0px;
border-style: solid; border-color: #336699; }span {color: #336699;}
pre {padding-left: 20px;}a:link {font-weight: bold; color:
#336699;}
a:visited {color: #336699; }a:hover {color: #80; background-
color: #80;}a:active {color: #00;}--/style/
headbodyh1Resource Not Found/h1pspanMessage:/span
Resource Not Found/ppspanDescription:/span The requested
resource quot;/testquot; could not be found/ppspanSender:/
span org.apache.cocoon.servlet.CocoonServlet/ppspanSource:/
span Cocoon Servlet/pp class='footer'a href='http://
cocoon.apache.org/'Apache Cocoon 2.1.9-dev/p/body/html
Two outputs
First the content of the failed aggregation :
sitecontent1//site
Then the generic error message.
If I now comment out the line parameter name=outputBufferSize
value=32768/ from the map:pipe. then I only get the
error message.
I have tested this in 2.1.7 -- 2.1.9-dev.
I suspect this did not occur in 2.1.6.
Is this a bug, or is it what I should expect to happen if
an output
buffer is configured?
Hi Jeremy,
Given the streaming nature of the SAX pipeline, buffering the complete
output at the end of the pipeline is indeed the only way to reliably
recover from exceptions that might happen during its
execution. This is
not necessarily bad, as whatever other way you would solve this, you
would need to temporarily store the data in one way or another to be
able to recover from errors.
There's a little bit more to it though. In case of an error the output
your pipeline is quite small:
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//site
which is much less then your buffer size of 32768, so normally Cocoon
should still be able to reset the output before generating the error
page.
Someone asked the exact same question a week or two ago on the users
list, at which time I had a quick look into this. The cause
is that the
ContentAggregator class, which does the aggregation, will
still generate
the endDocument event in case an exception occurs. IMO, it
should not do
this (unless it would also catch the exception). Here is the relevant
fragment:
try {
SourceUtil.parse(this.manager, part.source,
error handling causes NPE? (was: error handling in aggregations)
Hi!
Err, guys, can it be that the sources aren't released correctly after a
ProcessingException during pipeline execution? I get the same NPE I did when I
didn't release a sitemap source correctly a while ago after I apply this patch
to 2.1.8...
Any ideas?
max
-Original Message-
From: Max Pfingsthorn
Sent: Tuesday, March 21, 2006 16:33
To: dev@cocoon.apache.org
Subject: RE: error handling in aggregations
Hi!
Yes, this works well. I've tested it and with
'when=external' on 'map:handle-errors', it does stop the
serializer from dumping the data before the error page. Also,
'when=internal' works wonderfully inside the aggregate!
I would be all for this change before 2.1.9 comes out. If
noone objects, I'll commit it within the hour.
max
-Original Message-
From: Bruno Dumon [mailto:[EMAIL PROTECTED]
Sent: Sunday, March 19, 2006 14:33
To: dev@cocoon.apache.org
Subject: Re: error handling in aggregations
On Sun, 2006-03-19 at 12:10 +, Jeremy Quinn wrote:
Hi All
Investigating this further, I came up with this simplest
possible
sitemap to reproduce the problem :
?xml version=1.0?
map:sitemap xmlns:map=http://apache.org/cocoon/sitemap/1.0;
map:components
map:generators default=file
map:generator name=file label=content
logger=sitemap.generator.file pool-grow=4 pool-max=32 pool-
min=4 src=org.apache.cocoon.generation.FileGenerator/
/map:generators
map:serializers default=xml
map:serializer name=xml
logger=sitemap.serializer.xml
mime-type=text/xml pool-grow=4 pool-max=32 pool-min=4
src=org.apache.cocoon.serialization.XMLSerializer/
/map:serializers
map:matchers default=wildcard
map:matcher logger=sitemap.matcher.wildcard
name=wildcard
src=org.apache.cocoon.matching.WildcardURIMatcher/
/map:matchers
map:pipes default=noncaching
map:pipe logger=sitemap.pipes.noncaching
name=noncaching
src=org.apache.cocoon.components.pipeline.impl.NonCachingProc
essingPipe
line
parameter name=outputBufferSize value=32768/
/map:pipe
/map:pipes
/map:components
map:pipelines
map:pipeline internal-only=false type=noncaching
map:match pattern=test
map:aggregate element=site
map:part element=content1 src=nothing.xml/
map:part element=content2 src=nothingelse.xml/
/map:aggregate
map:serialize type=xml /
/map:match
/map:pipeline
/map:pipelines
/map:sitemap
I set this up as the top-level sitemap, loaded by cocoon.xconf.
I access the url and I get this :
$ curl http://localhost:/test
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//
sitehtmlheadtitleResource Not
Found/titlestyle!--body
{ background-color: white; color: black; font-family: verdana,
helvetica, sanf serif;}h1 {color: #336699; margin: 0px 0px
20px 0px;
border-width: 0px 0px 1px 0px; border-style: solid;
border-color:
#336699;}p.footer { color: #336699; border-width: 1px 0px
0px 0px;
border-style: solid; border-color: #336699; }span {color:
#336699;}
pre {padding-left: 20px;}a:link {font-weight: bold; color:
#336699;}
a:visited {color: #336699; }a:hover {color: #80; background-
color: #80;}a:active {color: #00;}--/style/
headbodyh1Resource Not Found/h1pspanMessage:/span
Resource Not Found/ppspanDescription:/span The requested
resource quot;/testquot; could not be
found/ppspanSender:/
span
org.apache.cocoon.servlet.CocoonServlet/ppspanSource:/
span Cocoon Servlet/pp class='footer'a href='http://
cocoon.apache.org/'Apache Cocoon 2.1.9-dev/p/body/html
Two outputs
First the content of the failed aggregation :
sitecontent1//site
Then the generic error message.
If I now comment out the line parameter
name=outputBufferSize
value=32768/ from the map:pipe. then I only get the
error message.
I have tested this in 2.1.7 -- 2.1.9-dev.
I suspect this did not occur in 2.1.6.
Is this a bug, or is it what I should expect to happen if
an output
buffer is configured?
Hi Jeremy,
Given the streaming nature of the SAX pipeline, buffering
the complete
output at the end of the pipeline is indeed the only way to reliably
recover from exceptions that might happen during its
execution. This is
not necessarily bad, as whatever other way you would solve this, you
would need to temporarily store the data in one way or another to be
able to recover from errors.
There's a little bit more to it though. In case of an error
the output
your pipeline is quite small:
?xml version=1.0 encoding=ISO-8859-1?sitecontent1//site
which is much less then your
[jira] Commented: (COCOON-1794) [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding
[ http://issues.apache.org/jira/browse/COCOON-1794?page=comments#action_12369430 ] Max Pfingsthorn commented on COCOON-1794: - Actually, I meant to implement this in the repeater binding. You are right though, positioning is important and makes sense. However, I would rather do it somehow like this: previousContext = nil for each row in repeater do context = getRowContext(row) if(context==null) insertAfterBinding.saveFormToModel(row,previousContext) context = getRowContext(row) if(row.isUpdated() || row.isCreated()) rowBinding.saveFormToModel(row,context) else deleteRowBinding.saveFormToModel(row,context) Insert after binding would work for both xml and beans. In the beans case, we could add a new object (like the InsertBeanJXPathBinding) and shift the ones below the one to insert after down. [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding - Key: COCOON-1794 URL: http://issues.apache.org/jira/browse/COCOON-1794 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Suzan Foster Attachments: repeater-binding-patch.txt This patch corrects the following issues: - Namespaced back-end XML model not correctly binding to the repeaters child widgets. - Nodes bound to row widgets not being reordered according to row position on save. Files affected: - JXPathBindingBase: - member applyLeniency changed from private to protected. - member applyNSDeclarations changed from private to protected. - RepeaterJXPathBinding: - constructor changed for passing a binding for moveRow. - applyLeniency and applyNSDeclarations applied to created relative contexts. - member moveRowBinding added. - method getMoveRowBinding added. - doSave changed to incorporate the use of moveRowBinding. - RepeaterJXPathBindingBuilder: - buildBinding changed to incorporate the construction of moveRowBinding. Files added: - MoveNodeJXPathBinding. - MoveNodeJXPathBindingBuilder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1794) [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding
[ http://issues.apache.org/jira/browse/COCOON-1794?page=comments#action_12369434 ] Max Pfingsthorn commented on COCOON-1794: - Okay, fine. They only thing I would like to accomplish, and which is important to VNU and Hippo as well, is that this repeater would work without an enclosing element for the rows. This is currently not the case, and this is also not fixed by your patch. Actually, your patch will make it worse as you assume that the parent element will only have the repeater's rows as children. If you just move a row element after the ith element of the parent, bad things can happen (in terms of document validity). Our concern is to have a schema validateable output from cforms. This includes namespaces and element ordering, especially with repeaters without their own parent element. Imagine something like this: doc meta titlebla/title /meta content psome paragraph/p /content content psome other paragraph/p /content link/link link/link /doc For the content and link elements, we want to use a repeater and not have contents after links in the output, which does happen now. I've been thinking about it myself, and your patch just seemed like a good idea to discuss a little. Actually, now, the only thing that we have to do to fix this is to make an InsertAfterNodeJXPathBinding, and in the loop where new rows get inserted, use that one which takes the previous row's node and inserts a node after that one. This way, we will keep everything neatly aligned and no moving is necessary, right? [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding - Key: COCOON-1794 URL: http://issues.apache.org/jira/browse/COCOON-1794 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Suzan Foster Attachments: repeater-binding-patch.txt This patch corrects the following issues: - Namespaced back-end XML model not correctly binding to the repeaters child widgets. - Nodes bound to row widgets not being reordered according to row position on save. Files affected: - JXPathBindingBase: - member applyLeniency changed from private to protected. - member applyNSDeclarations changed from private to protected. - RepeaterJXPathBinding: - constructor changed for passing a binding for moveRow. - applyLeniency and applyNSDeclarations applied to created relative contexts. - member moveRowBinding added. - method getMoveRowBinding added. - doSave changed to incorporate the use of moveRowBinding. - RepeaterJXPathBindingBuilder: - buildBinding changed to incorporate the construction of moveRowBinding. Files added: - MoveNodeJXPathBinding. - MoveNodeJXPathBindingBuilder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1794) [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding
[ http://issues.apache.org/jira/browse/COCOON-1794?page=comments#action_12369441 ] Max Pfingsthorn commented on COCOON-1794: - Hmm.. not so sure. What I did now was to implement an InsertAfterNodeJXPathBinding which is used instead of InsertNodeJXPathBinding in fb:on-insert-row. The next thing is a bit hacky: The RepeaterJXPathBinding knows about the InsertAfterNodeJXPathBinding and uses the path of the previously inserted or last accessed row so that the new node is created right after that one. It does work, but it's not as clean as I'd like. The tricky thing is, you need to supply another context to the binding for relative positioning. This sort of positioning functionality is just not implemented and it is really hard and awkward to force it into the doSave(Widget, Context) method. Why do you need an absolute positioning though? They only thing you do now in your MoveNodeJXPathBinding is move all rows up to the top of their enclosing element. They will still be in order they were in the form. Before, they were as well, just as many rows as were newly created were on the bottom of the enclosing element. This does not hurt at all if you have an enclosing element only for the rows. Your addition would not reorder them, as far as I can see. Can you show your usecase to make this clearer? [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding - Key: COCOON-1794 URL: http://issues.apache.org/jira/browse/COCOON-1794 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Suzan Foster Attachments: repeater-binding-patch.txt This patch corrects the following issues: - Namespaced back-end XML model not correctly binding to the repeaters child widgets. - Nodes bound to row widgets not being reordered according to row position on save. Files affected: - JXPathBindingBase: - member applyLeniency changed from private to protected. - member applyNSDeclarations changed from private to protected. - RepeaterJXPathBinding: - constructor changed for passing a binding for moveRow. - applyLeniency and applyNSDeclarations applied to created relative contexts. - member moveRowBinding added. - method getMoveRowBinding added. - doSave changed to incorporate the use of moveRowBinding. - RepeaterJXPathBindingBuilder: - buildBinding changed to incorporate the construction of moveRowBinding. Files added: - MoveNodeJXPathBinding. - MoveNodeJXPathBindingBuilder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1794) [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding
[ http://issues.apache.org/jira/browse/COCOON-1794?page=comments#action_12369471 ] Max Pfingsthorn commented on COCOON-1794: - Sorry, that is not right. The repeater will _always_ save rows in order, the only thing that is appended are placeholders to extend the list. Actually, your usecase should work right now without changes to the repeater binding (other than the ones for the namespaces) since you use a wrapper element. My change is that new placeholder elements for rows are appended to the bulk of existing row elements instead of at the end of the parent element. That keeps chunks of row data together instead of splitting them when no wrapper element is available. Your move binding will actually never do anything, as you pointed out, because the rows are saved in order. Of course, the only thing you have to do is to assign new ids to new rows, but I guess you already took care of that. [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding - Key: COCOON-1794 URL: http://issues.apache.org/jira/browse/COCOON-1794 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Suzan Foster Attachments: repeater-binding-patch.txt This patch corrects the following issues: - Namespaced back-end XML model not correctly binding to the repeaters child widgets. - Nodes bound to row widgets not being reordered according to row position on save. Files affected: - JXPathBindingBase: - member applyLeniency changed from private to protected. - member applyNSDeclarations changed from private to protected. - RepeaterJXPathBinding: - constructor changed for passing a binding for moveRow. - applyLeniency and applyNSDeclarations applied to created relative contexts. - member moveRowBinding added. - method getMoveRowBinding added. - doSave changed to incorporate the use of moveRowBinding. - RepeaterJXPathBindingBuilder: - buildBinding changed to incorporate the construction of moveRowBinding. Files added: - MoveNodeJXPathBinding. - MoveNodeJXPathBindingBuilder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1794) [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding
[ http://issues.apache.org/jira/browse/COCOON-1794?page=comments#action_12369260 ] Max Pfingsthorn commented on COCOON-1794: - This is an interesting topic. However, retrospectively moving the rows around doesn't seem to be the best way to solve this. Instead, the InsertNodeJXPathBinding should know to insert a node after another (or before). I'm having a look into it right now as we have the same problem. Additionally, we should try to stay backward compatible with the repeater definition and we shouldn't break being able to bind to beans. Keeping it consistent between XML and JavaBeans bindings might be a problem as beans don't support moving children around after they are added. And requiring a move binding which doesn't exist for beans of course makes the repeater unusable for that case. I would put some XML specific code in to the RepeaterJXPathBinding if the insertBinding is a InsertNodeJXPathBinding. That way, we can ensure the relative AND absolute positioning of the XML elements created by the binding. By absolute I mean this: We often use the repeater without an enclosing context for each row. New rows will always end up in the end of the document (or enclosing element), not after the bulk of other rows, which can be a big problem if you need to validate the resulting xml. So, I'll be working on some specific hacks to make this work for XML and not break it for beans without influencing the configs. [PATCH] Propagation of namespaces to a repeaters child bindings and implementation of a move-node binding - Key: COCOON-1794 URL: http://issues.apache.org/jira/browse/COCOON-1794 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.1.9-dev (current SVN) Reporter: Suzan Foster Attachments: repeater-binding-patch.txt This patch corrects the following issues: - Namespaced back-end XML model not correctly binding to the repeaters child widgets. - Nodes bound to row widgets not being reordered according to row position on save. Files affected: - JXPathBindingBase: - member applyLeniency changed from private to protected. - member applyNSDeclarations changed from private to protected. - RepeaterJXPathBinding: - constructor changed for passing a binding for moveRow. - applyLeniency and applyNSDeclarations applied to created relative contexts. - member moveRowBinding added. - method getMoveRowBinding added. - doSave changed to incorporate the use of moveRowBinding. - RepeaterJXPathBindingBuilder: - buildBinding changed to incorporate the construction of moveRowBinding. Files added: - MoveNodeJXPathBinding. - MoveNodeJXPathBindingBuilder. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: environment errors
Dear all, sorry for this noise... It was my fault. I didn't release a source properly in one of my generators... Jean-Baptiste, maybe you have the same problem? Bye! max -Original Message- From: Max Pfingsthorn Sent: Thursday, March 02, 2006 13:10 To: dev@cocoon.apache.org Subject: RE: environment errors ...nevermind. that didn't do the trick. max -Original Message- From: Max Pfingsthorn Sent: Thursday, March 02, 2006 13:05 To: dev@cocoon.apache.org Subject: RE: environment errors Carsten Ziegeler [mailto:[EMAIL PROTECTED] Max Pfingsthorn schrieb: Hi! Okay, I traced this one to the o.a.c.environment.wrapper.EnvironmentWrapper thank god for debuggers). That one does not implement release(Source) itself, so the superclass is used, but since it is a wrapper, it is not initialized to have a source resolver itself! I am not sure what this class is used for, but can I just forward the call to the wrapped environment like some of the other methods do? Hmm, no, I think this is then just a workaround for the real problem. If the source resolver is null in release it either means that the resolveURI was never called before, so a source is tried to be released on a different env than it was looked up from. Or in the other case, finishProcessing() has been called prior to the release method. Then the order of method calls is wrong. Can you come up with a test case? Well, there are two errors here, actually. The one Jean-Baptiste commented on and the one I traced. Both are very similar, and seem to be caused by a similar problem... In Cocoon.process, in the last finally block, we call CocoonComponentManager.leaveEnvironment(); CocoonComponentManager.endProcessing(environment, key); leaveEnvironment pops the environment stack while endProcessing will call release (which in turn calls recycle) on all components, which in turn calls CocoonComponentManager.removeFromAutomaticRelease(Component) which tries to acces the environment stack, which is empty. The other error is caused by endProcessing calling env.finishingProcessing(); before desc.release();. Okay, I think I got it now. The CocoonComponentManager.addComponentForAutomaticRelease will actually add this component to the root environment (line 464, in 2.1.8) because it does stack.get(0), which is the lowest stack item. This happens for each sitemap source in the init() method. Since env.finishingProcessing() is called by each sitemap source (through CocoonComponentManager.leaveEnvironment()) and removeFromAutomaticRelease() is done after all the processing, the environment the components from the deeper sitemap sources will already have been ended. It would be better to add them to the top of the stack. I think this would solve both problems, because both occur in EnvironmentDescription.release(). I'll try to come up with a simple test case, but right now I have a headache from two days of sitting in front of the debugger... I'll let you know if changing this one line in CocoonComponentManager.addComponentForAutomaticRelease helped. Actually its changing final EnvironmentStack.Item objects = (EnvironmentStack.Item)stack.get(0); into final EnvironmentStack.Item objects = (EnvironmentStack.Item)stack.get(); I'll take some painkillers now. max
RE: Cocoon developers opensource license YourKit Java Profiler
Hello! Yes, please, I would like one :) Thanks! max -Original Message- From: David Crossley [mailto:[EMAIL PROTECTED] Sent: Thursday, March 02, 2006 23:33 To: dev@cocoon.apache.org Subject: Re: Cocoon developers opensource license YourKit Java Profiler David Crossley wrote: Cocoon developers who would like to use YourKit Java Profiler during their work on the Cocoon project, are entitled to an Open Source license. Here is their response to my request for clarification. I defined exactly what we mean by developer and committer and then asked what was their meaning ... developer is a person who will use profiler during his work in Forrest/Cocoon project. Last call. Any more Cocoon developers wanting a license key? -David
RE: repository block
Hi! Okay, for the WebDAVSource, or any Inspectable and Traverseable source, you will get an InspectableTraversableCachingSource from the CachingSourceFactory. This source will actually put SourceProperty objects in a map for its cached response. The cached response is Serializable, but not the elements in that map, so ObjectOutputStream.writeObject() fails. This only happens when the in-memory part of the Cache which uses the EHDefaultStore becomes too full and loads objects off to disk. Here is the exception we get: 2006-02-28 12:03:57,173 ERROR net.sf.ehcache.store.DiskStore cocoon-ehcache-1Cache: Could not write elements to disk cache java.io.NotSerializableException: org.apache.cocoon.components.source.helpers.SourceProperty at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1054) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) at java.util.HashMap.writeObject(HashMap.java:980) at sun.reflect.GeneratedMethodAccessor789.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at java.io.ObjectStreamClass.invokeWriteObject(ObjectStreamClass.java:809) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1296) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1332) at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1304) at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1247) at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1052) at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:278) at net.sf.ehcache.store.DiskStore.flushSpool(DiskStore.java:515) at net.sf.ehcache.store.DiskStore.spoolThreadMain(DiskStore.java:488) at net.sf.ehcache.store.DiskStore.access$600(DiskStore.java:89) at net.sf.ehcache.store.DiskStore$SpoolThread.run(DiskStore.java:755) max -Original Message- From: Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED] Sent: Thursday, March 02, 2006 16:59 To: dev@cocoon.apache.org Subject: Re: repository block * Max Pfingsthorn: I want to refactor the repository block so that SourceProperty is an interface. Or at least implement readObject() and writeObject(), so it can be serialized. SourceProperty not being Serializable makes the WebDAVSource (and any other which implements InspectableSource) not cacheable via the CachingSourceFactory from the scratchpad. Hello Max, Does CachingSourceFactory give an error? How do you observe that WebDAVSource is not cacheable? -- Jean-Baptiste Quenot http://caraldi.com/jbq/
RE: environment errors
Carsten Ziegeler [mailto:[EMAIL PROTECTED] Max Pfingsthorn schrieb: Hi! Okay, I traced this one to the o.a.c.environment.wrapper.EnvironmentWrapper thank god for debuggers). That one does not implement release(Source) itself, so the superclass is used, but since it is a wrapper, it is not initialized to have a source resolver itself! I am not sure what this class is used for, but can I just forward the call to the wrapped environment like some of the other methods do? Hmm, no, I think this is then just a workaround for the real problem. If the source resolver is null in release it either means that the resolveURI was never called before, so a source is tried to be released on a different env than it was looked up from. Or in the other case, finishProcessing() has been called prior to the release method. Then the order of method calls is wrong. Can you come up with a test case? Well, there are two errors here, actually. The one Jean-Baptiste commented on and the one I traced. Both are very similar, and seem to be caused by a similar problem... In Cocoon.process, in the last finally block, we call CocoonComponentManager.leaveEnvironment(); CocoonComponentManager.endProcessing(environment, key); leaveEnvironment pops the environment stack while endProcessing will call release (which in turn calls recycle) on all components, which in turn calls CocoonComponentManager.removeFromAutomaticRelease(Component) which tries to acces the environment stack, which is empty. The other error is caused by endProcessing calling env.finishingProcessing(); before desc.release();. Okay, I think I got it now. The CocoonComponentManager.addComponentForAutomaticRelease will actually add this component to the root environment (line 464, in 2.1.8) because it does stack.get(0), which is the lowest stack item. This happens for each sitemap source in the init() method. Since env.finishingProcessing() is called by each sitemap source (through CocoonComponentManager.leaveEnvironment()) and removeFromAutomaticRelease() is done after all the processing, the environment the components from the deeper sitemap sources will already have been ended. It would be better to add them to the top of the stack. I think this would solve both problems, because both occur in EnvironmentDescription.release(). I'll try to come up with a simple test case, but right now I have a headache from two days of sitting in front of the debugger... I'll let you know if changing this one line in CocoonComponentManager.addComponentForAutomaticRelease helped. Actually its changing final EnvironmentStack.Item objects = (EnvironmentStack.Item)stack.get(0); into final EnvironmentStack.Item objects = (EnvironmentStack.Item)stack.get(); I'll take some painkillers now. max
RE: environment errors
...nevermind. that didn't do the trick. max -Original Message- From: Max Pfingsthorn Sent: Thursday, March 02, 2006 13:05 To: dev@cocoon.apache.org Subject: RE: environment errors Carsten Ziegeler [mailto:[EMAIL PROTECTED] Max Pfingsthorn schrieb: Hi! Okay, I traced this one to the o.a.c.environment.wrapper.EnvironmentWrapper thank god for debuggers). That one does not implement release(Source) itself, so the superclass is used, but since it is a wrapper, it is not initialized to have a source resolver itself! I am not sure what this class is used for, but can I just forward the call to the wrapped environment like some of the other methods do? Hmm, no, I think this is then just a workaround for the real problem. If the source resolver is null in release it either means that the resolveURI was never called before, so a source is tried to be released on a different env than it was looked up from. Or in the other case, finishProcessing() has been called prior to the release method. Then the order of method calls is wrong. Can you come up with a test case? Well, there are two errors here, actually. The one Jean-Baptiste commented on and the one I traced. Both are very similar, and seem to be caused by a similar problem... In Cocoon.process, in the last finally block, we call CocoonComponentManager.leaveEnvironment(); CocoonComponentManager.endProcessing(environment, key); leaveEnvironment pops the environment stack while endProcessing will call release (which in turn calls recycle) on all components, which in turn calls CocoonComponentManager.removeFromAutomaticRelease(Component) which tries to acces the environment stack, which is empty. The other error is caused by endProcessing calling env.finishingProcessing(); before desc.release();. Okay, I think I got it now. The CocoonComponentManager.addComponentForAutomaticRelease will actually add this component to the root environment (line 464, in 2.1.8) because it does stack.get(0), which is the lowest stack item. This happens for each sitemap source in the init() method. Since env.finishingProcessing() is called by each sitemap source (through CocoonComponentManager.leaveEnvironment()) and removeFromAutomaticRelease() is done after all the processing, the environment the components from the deeper sitemap sources will already have been ended. It would be better to add them to the top of the stack. I think this would solve both problems, because both occur in EnvironmentDescription.release(). I'll try to come up with a simple test case, but right now I have a headache from two days of sitting in front of the debugger... I'll let you know if changing this one line in CocoonComponentManager.addComponentForAutomaticRelease helped. Actually its changing final EnvironmentStack.Item objects = (EnvironmentStack.Item)stack.get(0); into final EnvironmentStack.Item objects = (EnvironmentStack.Item)stack.get(); I'll take some painkillers now. max
RE: environment errors
Hi! Okay, I traced this one to the o.a.c.environment.wrapper.EnvironmentWrapper (thank god for debuggers). That one does not implement release(Source) itself, so the superclass is used, but since it is a wrapper, it is not initialized to have a source resolver itself! I am not sure what this class is used for, but can I just forward the call to the wrapped environment like some of the other methods do? max Number two: This one seems to be caused by a missing source resolver, which I cannot imagine at all. Why would the environment wrapped by the MutableEnvironmentFacade not be initialized correctly (i.e. have no source resolver)? java.lang.NullPointerException at org.apache.cocoon.environment.AbstractEnvironment.release(Abst ractEnvironment.java:565) at org.apache.cocoon.environment.wrapper.MutableEnvironmentFacade .release(MutableEnvironmentFacade.java:308) at org.apache.cocoon.transformation.TraxTransformer.recycle(TraxT ransformer.java:548) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingP ool.put(InstrumentedResourceLimitingPool.java:407) at org.apache.avalon.excalibur.component.PoolableComponentHandler .doPut(PoolableComponentHandler.java:212) at org.apache.avalon.excalibur.component.ComponentHandler.put(Com ponentHandler.java:425) at org.apache.avalon.excalibur.component.ExcaliburComponentSelect or.release(ExcaliburComponentSelector.java:307) at org.apache.cocoon.components.ExtendedComponentSelector.release (ExtendedComponentSelector.java:300) at org.apache.cocoon.components.ExtendedComponentSelector.release (ExtendedComponentSelector.java:297) at org.apache.cocoon.components.ExtendedComponentSelector.release (ExtendedComponentSelector.java:297) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeli ne.recycle(AbstractProcessingPipeline.java:732) at org.apache.cocoon.components.pipeline.impl.BaseCachingProcessi ngPipeline.recycle(BaseCachingProcessingPipeline.java:77) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProc essingPipeline.recycle(AbstractCachingProcessingPipeline.java:993) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingP ool.put(InstrumentedResourceLimitingPool.java:407) at org.apache.avalon.excalibur.component.PoolableComponentHandler .doPut(PoolableComponentHandler.java:212) at org.apache.avalon.excalibur.component.ComponentHandler.put(Com ponentHandler.java:425) at org.apache.avalon.excalibur.component.ExcaliburComponentSelect or.release(ExcaliburComponentSelector.java:307) at org.apache.cocoon.components.ExtendedComponentSelector.release (ExtendedComponentSelector.java:300) at org.apache.cocoon.components.ExtendedComponentSelector.release (ExtendedComponentSelector.java:297) at org.apache.cocoon.components.EnvironmentDescription.release(Co coonComponentManager.java:678) at org.apache.cocoon.components.CocoonComponentManager.endProcess ing(CocoonComponentManager.java:243) at org.apache.cocoon.Cocoon.process(Cocoon.java:719) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet. java:1154) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.do Filter(WebApplicationHandler.java:830) at nl.hippo.util.ResponseEncodingFilter.doFilter(ResponseEncoding Filter.java:36) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.do Filter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebAp plicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler .java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebAppl icationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListene r.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534)
repository block
Hi! I want to refactor the repository block so that SourceProperty is an interface. Or at least implement readObject() and writeObject(), so it can be serialized. SourceProperty not being Serializable makes the WebDAVSource (and any other which implements InspectableSource) not cacheable via the CachingSourceFactory from the scratchpad. Anyone against that? Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
environment errors
(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Number two: This one seems to be caused by a missing source resolver, which I cannot imagine at all. Why would the environment wrapped by the MutableEnvironmentFacade not be initialized correctly (i.e. have no source resolver)? java.lang.NullPointerException at org.apache.cocoon.environment.AbstractEnvironment.release(AbstractEnvironment.java:565) at org.apache.cocoon.environment.wrapper.MutableEnvironmentFacade.release(MutableEnvironmentFacade.java:308) at org.apache.cocoon.transformation.TraxTransformer.recycle(TraxTransformer.java:548) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.put(InstrumentedResourceLimitingPool.java:407) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut(PoolableComponentHandler.java:212) at org.apache.avalon.excalibur.component.ComponentHandler.put(ComponentHandler.java:425) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release(ExcaliburComponentSelector.java:307) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:300) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:297) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:297) at org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.recycle(AbstractProcessingPipeline.java:732) at org.apache.cocoon.components.pipeline.impl.BaseCachingProcessingPipeline.recycle(BaseCachingProcessingPipeline.java:77) at org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.recycle(AbstractCachingProcessingPipeline.java:993) at org.apache.avalon.excalibur.pool.InstrumentedResourceLimitingPool.put(InstrumentedResourceLimitingPool.java:407) at org.apache.avalon.excalibur.component.PoolableComponentHandler.doPut(PoolableComponentHandler.java:212) at org.apache.avalon.excalibur.component.ComponentHandler.put(ComponentHandler.java:425) at org.apache.avalon.excalibur.component.ExcaliburComponentSelector.release(ExcaliburComponentSelector.java:307) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:300) at org.apache.cocoon.components.ExtendedComponentSelector.release(ExtendedComponentSelector.java:297) at org.apache.cocoon.components.EnvironmentDescription.release(CocoonComponentManager.java:678) at org.apache.cocoon.components.CocoonComponentManager.endProcessing(CocoonComponentManager.java:243) at org.apache.cocoon.Cocoon.process(Cocoon.java:719) at org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154) at javax.servlet.http.HttpServlet.service(HttpServlet.java:802) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at nl.hippo.util.ResponseEncodingFilter.doFilter(ResponseEncodingFilter.java:36) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1530) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1482) at org.mortbay.http.HttpServer.service(HttpServer.java:909) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:982) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
RE: making pipelines wait for each other
Hello everyone! I have a working solution for this now. It uses the store to share locks (objects the threads call wait() and notify() on). It works quite beautifully, for both pipelines and readers. I played around a bit with the eventcache samples for testing (it already had an artificially slowed down generator) and around 60 sequentially opened firefox tabs return the same time after the first request is done :D Same with a reader. I'm trying to apply the same to trunk now... have to orient myself first though, got a bit confused by the whole mavenation thing.. max -Original Message- From: Max Pfingsthorn Sent: Monday, February 06, 2006 12:10 To: dev@cocoon.apache.org Subject: RE: making pipelines wait for each other I think this topic has been discussed several times, so you might want to search through the archives to see what others did say about it. I had a look and the only thing I found was a conversation in the beginning of 2004 about eventcaching and the CachedSource [1]. Unico started it back then, but it was about asynchronously recreating sources instead of making pipelines wait if another is already recreating the same content. I think I will try the approach I outlined before and see what happens :) Bye! max [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107822781408011w=2
making pipelines wait for each other
Hello! I am not sure what has been done about this so far, but we are still experiencing some not-so-great behavior from the CachingPipeline: We have some pipelines which take a long time to complete processing, like generating a homepage from many different sources. We see that if a second request for exactly the same pipeline comes in before the first request is done, it takes again as long because the first pipeline did not put its result in the cache yet and it is recomputed. This is quite obvious, but hurts our performance a lot. I was thinking that we might implement some thread synchronization by sharing some objects and calling wait() and notify() on them. First I thought putting an empty CachedResponse into the Cache when we start generating the data. Any pipeline trying to access that CachedResponse will notice that it is empty and call wait() on it. As soon as the first pipeline is done saving its content to the cache, it calls notify(). Then I remembered that the Cache puts these on disk, and I am not sure what happens to the locks when an object is serialized... So, what about doing the same with a store instead? We push an empty response into a store, preferrably a transient, in-memory one without size limits, and do the same as I outlined above. WDYT? Would that solve it? Is there a better way? Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
RE: making pipelines wait for each other
-Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Monday, February 06, 2006 11:35 To: dev@cocoon.apache.org Subject: Re: making pipelines wait for each other Max Pfingsthorn wrote: Hello! ... WDYT? Would that solve it? Is there a better way? I think this topic has been discussed several times, so you might want to search through the archives to see what others did say about it. We usually solve this problem by pre-caching, so before the first real user can invoke the pipeline, we already invoked it (using cron etc.) and therefore the content is always cached. Yes, that is one solution, but we have dynamic content, and a vast range of possible http requests, so we can't precompute everything. Additionally, when content changes while cocoon is running, it is still possible to get this effect while the background task refreshes the cache... Unless we do some double buffering, i.e. keep the previous cachedresponse valid while we recreate the content. I'll have another look through the archive before I take some steps to solve this. max
RE: making pipelines wait for each other
I think this topic has been discussed several times, so you might want to search through the archives to see what others did say about it. I had a look and the only thing I found was a conversation in the beginning of 2004 about eventcaching and the CachedSource [1]. Unico started it back then, but it was about asynchronously recreating sources instead of making pipelines wait if another is already recreating the same content. I think I will try the approach I outlined before and see what happens :) Bye! max [1] http://marc.theaimsgroup.com/?l=xml-cocoon-devm=107822781408011w=2
RE: making pipelines wait for each other
-Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Monday, February 06, 2006 12:06 To: dev@cocoon.apache.org Subject: Re: making pipelines wait for each other Le 6 févr. 06, à 10:44, Max Pfingsthorn a écrit : ...We see that if a second request for exactly the same pipeline comes in before the first request is done, it takes again as long because the first pipeline did not put its result in the cache yet and it is recomputed. This is quite obvious, but hurts our performance a lot... FYI, a while ago I had some performance issues and I was wondering what happens if you're using a front-end cache (mod_cache, Squid or something): do these caches optimize simultaneous requests by making all but one wait until the first response is generated? In the end my issues where much more stupid than that (some pages were not stored in the front-end cache due to incorrect headers), so I didn't analyze in detail and don't have the answer. From your analysis it sounds like what you're seeing is really Cocoon-specific, but I thought I'd share my questioning, in case you're using a front-end cache as well. Yes, we are using squid in front of cocoon, but we are seeing the same problem anyway. It doesn't seem like squid has any options to configure this kind of behaviour... Bye! max
RE: svn commit: r372535 - /cocoon/trunk/cocoon-forms/cocoon-forms-impl/src/main/java/org/apache/cocoon/forms/samples/bindings/CustomValueWrapBinding.java
Hi!
Thanks for fixing this so fast!
It should have gone into the AbstractCustomBinding though, in order not to
break other custom bindings. Libraries are of no interest to custom bindings
anyway. Fixing this (and the typo) now... (making extra sure I don't break
stuff again).
Bye!
max
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Sent: Thursday, January 26, 2006 16:00
To: cvs@cocoon.apache.org
Subject: svn commit: r372535 -
/cocoon/trunk/cocoon-forms/cocoon-forms-impl/src/main/java/org
/apache/co
coon/forms/samples/bindings/CustomValueWrapBinding.java
Author: cziegeler
Date: Thu Jan 26 06:59:30 2006
New Revision: 372535
URL: http://svn.apache.org/viewcvs?rev=372535view=rev
Log:
Fix compilation problems
Modified:
cocoon/trunk/cocoon-forms/cocoon-forms-impl/src/main/java/org/
apache/cocoon/forms/samples/bindings/CustomValueWrapBinding.java
Modified:
cocoon/trunk/cocoon-forms/cocoon-forms-impl/src/main/java/org/
apache/cocoon/forms/samples/bindings/CustomValueWrapBinding.java
URL:
http://svn.apache.org/viewcvs/cocoon/trunk/cocoon-forms/cocoon
-forms-impl/src/main/java/org/apache/cocoon/forms/samples/bind
ings/CustomValueWrapBinding.java?rev=372535r1=372534r2=37253
5view=diff
==
---
cocoon/trunk/cocoon-forms/cocoon-forms-impl/src/main/java/org/
apache/cocoon/forms/samples/bindings/CustomValueWrapBinding.ja
va (original)
+++
cocoon/trunk/cocoon-forms/cocoon-forms-impl/src/main/java/org/
apache/cocoon/forms/samples/bindings/CustomValueWrapBinding.ja
va Thu Jan 26 06:59:30 2006
@@ -18,6 +18,7 @@
import org.apache.cocoon.forms.binding.AbstractCustomBinding;
import org.apache.cocoon.forms.binding.Binding;
import org.apache.cocoon.forms.binding.BindingException;
+import org.apache.cocoon.forms.binding.library.Library;
import org.apache.cocoon.forms.formmodel.Widget;
import org.apache.cocoon.forms.util.DomHelper;
import org.apache.commons.jxpath.JXPathContext;
@@ -96,4 +97,15 @@
throw new BindingException(Could not create
instance of CustomValueWrapBinding. ,e);
}
}
+
+public Library getEnclosingLibary() {
+// TODO Auto-generated method stub
+return null;
+}
+
+public void setEnclosingLibary(Library lib) {
+// TODO Auto-generated method stub
+
+}
+
}
RE: caching for source objects?
-Original Message- From: Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 24, 2006 18:40 To: dev@cocoon.apache.org Subject: Re: caching for source objects? * Carsten Ziegeler: Max Pfingsthorn schrieb: I've run into some problems with performance (in general) and I noticed that source objects are not cached... This is not so nice since, for example, WebDAVSources are quite expensive to instantiate. I think we have a CachingSource implementation somewhere (scratchpad?) which can be used as a wrapper around any other source implementation. I think this one will fit your use case. CachingSource builds a new Source object every time, that costs a lot for SitemapSource. I'm currently looking for a way to cache the Source objects (that could be configurable with a new request parameter), not only the cached response. The problem is that I don't want to end up with a lots of unreleased sources. The best would be to release sources unused for a certain period of time. Is that possible? Releasing sources is not really a problem. When you get the source from the cache (be it either the serialized one from the Cache or the object itself from the Store), you can ask it for the validity and check it. If it's not valid, release it and make a new one, otherwise use the one you got. There might be a problem with EventCaching this way, since the eventaware code doesn't know about releasing sources (yet). I made an EventAware MRUMemoryStore recently (not sure if I committed it..), so its method to process event caching events can be adjusted to check if the object to be removed is a source and release it first. I'm not sure, but I also think its possible to overload the remove() method of the MRUMemoryStore instead and also catch other evictions. max
svn weirdness
Hi! I just did an update of my 2.1.x branch and (even after svn cleanup), svn complains: svn: Failed to add directory 'src\blocks\validation': object of the same name already exists Did someone make it external or something? Should I delete that dir and do another svn up? Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
on another note: error in QuartzDriverDelegate.java
Hi! Found something in the current svn 2.1.x branch: cocoon-2.1.x\src\blocks\cron\java\org\apache\cocoon\components\cron\QuartzDriverDelegate.java:528: cannot resolve symbol symbol : method updateSchedulerState (java.sql.Connection,java.lang.String,long) location: interface org.quartz.impl.jdbcjobstore.DriverDelegate return delegate.updateSchedulerState(arg0, arg1, arg2); ^ Did someone forget to add a new quartz jar or committed this by accident? Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
[forms] aggregate field
Hello! Is there any special reason the AggregateField does not initialize its children when it is initialized itself? This is the cause for https://issues.apache.org/jira/browse/COCOON-1739... If noone shouts at me in the next hour, I will commit the change so that selection-lists, initial values and required fields work again in AggregateFields. Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
[jira] Assigned: (COCOON-1739) Selection list within aggregatefield is ignored
[ http://issues.apache.org/jira/browse/COCOON-1739?page=all ] Max Pfingsthorn reassigned COCOON-1739: --- Assign To: Max Pfingsthorn Selection list within aggregatefield is ignored --- Key: COCOON-1739 URL: http://issues.apache.org/jira/browse/COCOON-1739 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8 Reporter: Niels van Kampenhout Assignee: Max Pfingsthorn If an aggregatefield contains a field with a selection list, this selection list is ignored and does not show up in the form. See sample http://localhost:/samples/blocks/forms/aggregate/example (click Switch). The Enter Month field is has a selection-list in the form definition, but in the form it is a free text input field. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1739) Selection list within aggregatefield is ignored
[ http://issues.apache.org/jira/browse/COCOON-1739?page=all ] Max Pfingsthorn closed COCOON-1739: --- Fix Version: 2.2-dev (Current SVN) 2.1.9-dev (current SVN) Resolution: Fixed AggregateField did not initialize its children properly. Fixed it by calling initialize() on children as well. Selection list within aggregatefield is ignored --- Key: COCOON-1739 URL: http://issues.apache.org/jira/browse/COCOON-1739 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8 Reporter: Niels van Kampenhout Assignee: Max Pfingsthorn Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) If an aggregatefield contains a field with a selection list, this selection list is ignored and does not show up in the form. See sample http://localhost:/samples/blocks/forms/aggregate/example (click Switch). The Enter Month field is has a selection-list in the form definition, but in the form it is a free text input field. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Commented: (COCOON-1688) Error in the CForms Library samples
[ http://issues.apache.org/jira/browse/COCOON-1688?page=comments#action_12363966 ] Max Pfingsthorn commented on COCOON-1688: - I've allowed only new's to have a : in their id field, because they may reference classes in libraries directly. Please check if this sample works now.. Apparently there is something wrong with the help popups now. Same for the calendar. Error in the CForms Library samples --- Key: COCOON-1688 URL: http://issues.apache.org/jira/browse/COCOON-1688 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Helma van der Linden Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form1.flow shows: java.lang.Exception: A widget name cannot contain ':' as this conflicts with library prefixes, at file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/samples/blocks/forms/library/forms/form1_model.xml:24:30 context://samples/blocks/forms/library/forms/form1_model.xml - 24:30 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Closed: (COCOON-1688) Error in the CForms Library samples
[ http://issues.apache.org/jira/browse/COCOON-1688?page=all ] Max Pfingsthorn closed COCOON-1688: --- Fix Version: 2.2-dev (Current SVN) 2.1.9-dev (current SVN) Resolution: Fixed Assign To: Max Pfingsthorn I fixed it, at least the bug mentioned here. Will make another bug for the sample itself. Error in the CForms Library samples --- Key: COCOON-1688 URL: http://issues.apache.org/jira/browse/COCOON-1688 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.9-dev (current SVN) Reporter: Helma van der Linden Assignee: Max Pfingsthorn Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) http://cocoon.zones.apache.org/demos/21branch/samples/blocks/forms/library/form1.flow shows: java.lang.Exception: A widget name cannot contain ':' as this conflicts with library prefixes, at file:/home/cdemos/demos/21branch/BRANCH_2_1_X/build/webapp/samples/blocks/forms/library/forms/form1_model.xml:24:30 context://samples/blocks/forms/library/forms/form1_model.xml - 24:30 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] Assigned: (COCOON-1734) Forms library not honouring cross-referencing classes
[ http://issues.apache.org/jira/browse/COCOON-1734?page=all ] Max Pfingsthorn reassigned COCOON-1734: --- Assign To: Max Pfingsthorn Forms library not honouring cross-referencing classes - Key: COCOON-1734 URL: http://issues.apache.org/jira/browse/COCOON-1734 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Assignee: Max Pfingsthorn See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112774826126525w=4 We also encountered a problem with classes: if a library defines several cross-referencing classes (i.e. class A has a fd:new id=B and class B has a fd:new id=A), then the second fd:new fails because it searches in the current form whereas it should search in the originating definition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: on another note: error in QuartzDriverDelegate.java
-Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Wednesday, January 25, 2006 17:15 To: dev@cocoon.apache.org Subject: Re: on another note: error in QuartzDriverDelegate.java Max Pfingsthorn wrote: Hi! Found something in the current svn 2.1.x branch: cocoon-2.1.x\src\blocks\cron\java\org\apache\cocoon\component s\cron\QuartzDriverDelegate.java:528: cannot resolve symbol symbol : method updateSchedulerState (java.sql.Connection,java.lang.String,long) location: interface org.quartz.impl.jdbcjobstore.DriverDelegate return delegate.updateSchedulerState(arg0, arg1, arg2); ^ Did someone forget to add a new quartz jar or committed this by accident? Yes, $ svn log lib/optional/quartz-1.5.1.jar -- -- r371244 | antonio | 2006-01-22 03:08:44 -0600 (dom, 22 ene 2006) | 1 line Update quartz to 1.5.1. -- -- Do you have this jar in you repo? Aha, its here now. I did a completely new checkout like Daniel suggested and it also solved this problem. Quite confusing when svn up doesn't work properly! Thanks for your help! max
[jira] Closed: (COCOON-1734) Forms library not honouring cross-referencing classes
[ http://issues.apache.org/jira/browse/COCOON-1734?page=all ] Max Pfingsthorn closed COCOON-1734: --- Fix Version: 2.2-dev (Current SVN) 2.1.9-dev (current SVN) Resolution: Fixed Changed the way widgets and bindings remember their library, so it works now. Have a look at the library/forms/form1_model.xml and included libraries (also the binding) from the forms samples for some hints for usage. I made a simple recursive definition in a library (two classes refer to each other like in your example), and it works. Forms library not honouring cross-referencing classes - Key: COCOON-1734 URL: http://issues.apache.org/jira/browse/COCOON-1734 Project: Cocoon Type: Bug Components: Blocks: Forms Versions: 2.1.8, 2.2-dev (Current SVN), 2.1.9-dev (current SVN) Reporter: Jean-Baptiste Quenot Assignee: Max Pfingsthorn Fix For: 2.2-dev (Current SVN), 2.1.9-dev (current SVN) See http://marc.theaimsgroup.com/?l=xml-cocoon-devm=112774826126525w=4 We also encountered a problem with classes: if a library defines several cross-referencing classes (i.e. class A has a fd:new id=B and class B has a fd:new id=A), then the second fd:new fails because it searches in the current form whereas it should search in the originating definition. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
caching for source objects?
Hello everyone! I've run into some problems with performance (in general) and I noticed that source objects are not cached... This is not so nice since, for example, WebDAVSources are quite expensive to instantiate. Would it be a good idea in general if we subclassed the excalibur source resolver's resolveURI() method to add some caching (and delayed release) of the sources, say, using the o.a.excalibur.store.impl.MRUMemoryStore? WDYT? Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
RE: caching for source objects?
-Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Tuesday, January 24, 2006 13:07 To: dev@cocoon.apache.org Subject: Re: caching for source objects? Max Pfingsthorn schrieb: Hello everyone! I've run into some problems with performance (in general) and I noticed that source objects are not cached... This is not so nice since, for example, WebDAVSources are quite expensive to instantiate. Would it be a good idea in general if we subclassed the excalibur source resolver's resolveURI() method to add some caching (and delayed release) of the sources, say, using the o.a.excalibur.store.impl.MRUMemoryStore? I think we have a CachingSource implementation somewhere (scratchpad?) which can be used as a wrapper around any other source implementation. I think this one will fit your use case. Yes, I saw that one, and it works pretty well. But I thought it would be nicer to have a less intrusive and transparent way of doing the caching... With the CachingSourceFactory, you have to use two protocols, the caching one and the one you actually want to use. So you end up with something like: caching:file://foo.xml Having a way to swap implementations of the SourceResolver and transparently have source caching for every source you use (the ones that produce a non-null cache key, of course) would be nice... Maybe we can take the implementation of the CachingSource/Factory and encapsulate it in a CachingSourceResolver? max
RE: [vote] moving the template block in 2.1
[x] move template block to 2.1 and keep the old implementation [ ] move template block to 2.1 and trash the old implementation [ ] don't move template block to 2.1 max
RE: [VOTE] Stable CForms
Antonio Gallardo [mailto:[EMAIL PROTECTED]: Vadim Gritsenko wrote: We need official vote to mark CForms stable, so let's start it. Please vote to mark CForms as stable, to be included in imminent 2.1.9 release: [ ] +1, Let's do it! [ ] 0, What is CForms? [ ] -1, It's not stable, because... I am +1. Also we need to fix the cforms libraries. They are broken now. I'm +1, too. Can you tell me whats wrong? As far as I can see, there is COCOON-1688, and the class resolution issue for including stuff recursively from libraries. Anything else? Bye! max
[jira] Closed: (COCOON-1608) Missing Dependency in Webdav block
[ http://issues.apache.org/jira/browse/COCOON-1608?page=all ] Max Pfingsthorn closed COCOON-1608: --- Fix Version: 2.1.9-dev (current SVN) Resolution: Fixed Assign To: Max Pfingsthorn (was: Cocoon Developers Team) Fixed that one unintentionally by adding the jdom dependency in gump.xml (see http://marc.theaimsgroup.com/?l=xml-cocoon-cvsm=113535168516659w=2) Missing Dependency in Webdav block -- Key: COCOON-1608 URL: http://issues.apache.org/jira/browse/COCOON-1608 Project: Cocoon Type: Bug Components: Blocks: WebDAV Versions: 2.1.8 Environment: Operating System: other Platform: Other Reporter: Gavin Carothers Assignee: Max Pfingsthorn Fix For: 2.1.9-dev (current SVN) Trace Back: [exec] java.lang.NoClassDefFoundError: org/jdom/input/DOMBuilder [exec] at org.apache.webdav.lib.BaseProperty.getPropertyAsString(BaseProperty.java:129) [exec] at org.apache.webdav.lib.WebdavResource.processProperty(WebdavResource.java:4911) [exec] [exec] java.lang.NoClassDefFoundError: org/jdom/input/DOMBuilder [exec] at org.apache.webdav.lib.BaseProperty.getPropertyAsString(BaseProperty.java:129) [exec] at org.apache.webdav.lib.WebdavResource.processProperty(WebdavResource.java:4911) [exec] at org.apache.webdav.lib.WebdavResource.setWebdavProperties(WebdavResource.java:1066) [exec] at org.apache.webdav.lib.WebdavResource.setNamedProp(WebdavResource.java:968) [exec] at org.apache.webdav.lib.WebdavResource.setBasicProperties(WebdavResource.java:912) [exec] at org.apache.webdav.lib.WebdavResource.setProperties(WebdavResource.java:1894) [exec] at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1301) [exec] at org.apache.webdav.lib.WebdavResource.init(WebdavResource.java:223) [exec] at org.apache.cocoon.components.source.impl.WebDAVSource.initResource(WebDAVSource.java:212) [exec] at org.apache.cocoon.components.source.impl.WebDAVSource.exists(WebDAVSource.java:410) at org.apache.webdav.lib.WebdavResource.setWebdavProperties(WebdavResource.java:1066) [exec] at org.apache.webdav.lib.WebdavResource.setNamedProp(WebdavResource.java:968) [exec] at org.apache.webdav.lib.WebdavResource.setBasicProperties(WebdavResource.java:912) [exec] at org.apache.webdav.lib.WebdavResource.setProperties(WebdavResource.java:1894) [exec] at org.apache.webdav.lib.WebdavResource.setHttpURL(WebdavResource.java:1301) [exec] at org.apache.webdav.lib.WebdavResource.init(WebdavResource.java:223) [exec] at org.apache.cocoon.components.source.impl.WebDAVSource.initResource(WebDAVSource.java:212) [exec] at org.apache.cocoon.components.source.impl.WebDAVSource.exists(WebDAVSource.java:410) Patch to gump.xml === --- gump.xml(revision 290444) +++ gump.xml(working copy) @@ -1157,6 +1157,7 @@ library name=commons-httpclient/ library name=jakarta-slide-webdavlib/ +library name=jdom/ work nested=build/cocoon-@@DATE@@/blocks/webdav/dest/ work nested=build/cocoon-@@DATE@@/blocks/webdav/test/ -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [VOTE] green light for flattening repo structure in trunk
...Please cast your votes : [ +1] flatten the structure and pave the way for a 2.2 release [ ] no because Max
RE: rejuvenating the webdav block
Geoff Howard [mailto:[EMAIL PROTECTED] wrote: On 12/20/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: On another note: I need the eventcaching block for webdav, but that one only needs jms in one class, and databases in the samples. So, I'll work on the dependency issue there instead of in the webdav block directly. ... The eventcache is needed for more advanced caching. The components need to know about it to be able to construct the right Validity objects for Source.getValidity(). We found out that eventcaching is really key for good performance of the website, so I would consider it a good kind of dependency. Of course, the eventcaching block depending (indirectly) on the database block is a bit silly. Yes, these dependencies were always somewhat painful - as we discussed before [1]. It's only the samples that cause the dependency on the database block IIRC. There was some work being done on samples dependencies I think - or were samples being separated into samples blocks perhaps? That would cure this. I see you've implemented some of this in webdav - did you manage to avoid a dependency on the database block somehow? Yes, well, at least directly. The webdav block now depends only on repository and eventcache, not on database. However, eventcache still depends on database. I was thinking about the same thing, meaning to make a new block for the eventcache samples. That has been done for other blocks and would take care it, as you said. However, I don't know if its worth it in the 2.1 branch. Compiling a few more classes doesn't hurt too much for now. It would make more sense and be worth it for 2.2 as it is supposed to be released semi-soon, right? max [1] http://marc.theaimsgroup.com/?t=11325928653r=1w=2
RE: [RT] Simplifying component handling
... What's the contract for the auto-wiring? Just assuming ClassA and ClassB have public static fields called ROLE? Sounds somewhat strange. No, the contract would be to search for a component which is registered using the ClassA as the role name. Actually ClassA and ClassB are two interfaces. Hmm, so what do you do about the hints? Often enough, I see o.a.c.something.SomeInterface/hint (like o.a.c.caching.Cache/EventAware) in cocoon. This wouldn't work with your assumptions of always using FQCNs as service names. max
RE: webdav block broken in 2.1 branch.
Hi everyone! Sorry, that was me. Thanks for fixing it, Carsten! And yes, it was the right solution. Bye and happy new year! max -Original Message- From: Antonio Gallardo [mailto:[EMAIL PROTECTED] Sent: Saturday, December 31, 2005 13:48 To: dev@cocoon.apache.org Subject: webdav block broken in 2.1 branch. Hi: I just updated from the SVN. I tried to make a full build. I got: cocoon-block-webdav-compile: Compiling 10 source files to /home/agallardo/svn/cocoon-2.1/build/cocoon/blocks/webdav/dest /home/agallardo/svn/cocoon-2.1/src/blocks/webdav/java/org/apac he/cocoon/components/source/impl/WebDAVSource.java:596: cannot resolve symbol symbol : method newWebDAVSource (org.apache.webdav.lib.WebdavResource,org.apache.commons.httpc lient.HttpURL,java.lang.String,org.apache.avalon.framework.log ger.Logger) location: class org.apache.cocoon.components.source.impl.WebDAVSource WebDAVSource src = WebDAVSource.newWebDAVSource(resources[i], ^ 1 error Best Regards, Antonio Gallardo.
repository block - RepositorySourceFactory
Dear All, I thought it might be a good idea to make repository handling in cocoon a little easier. For that, I would like to extend the Repository interface with a getSource(String uri, Map params) method so that the RepositorySourceFactory could use it to get a source from a repository. Right now RepositorySourceFactory doesn't do much else than wrapping another source in RepositorySource, so something more useful might be nice. It would be very useful to configure a repository location once and then call something like repository:somename:/a/path/to/a/resource or, with a default repository: repository:/a/path/to/a/resource and get the right credentials, protocol, base path, and such. That's what we do at Hippo (in our own very homegrown kind of way) and it has been working very well. The nice thing would be though that it would work for any Repository implementation afterwards (even though there is only WebDAVRepository right now). Maybe the JCR stuff can be adapted as well (a o.a.c.components.repository.Repository adaptor to javax.jcr.Repository). WDYT? Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
RE: rejuvenating the webdav block
Dear all, I've just committed some changes to the 2.1 branch. The implementation of the eventcaching for WebDAVSource and DASLTransformer is complete and tested (with slide 2.1 as the webdav server). I'll have some more time to spend on it first thing in 2006. Merry Christmas! max -Original Message- From: Max Pfingsthorn Sent: Wednesday, December 21, 2005 12:04 To: dev@cocoon.apache.org Subject: RE: rejuvenating the webdav block Hi! Can you show me a block (or some sort of description of how it should look like) so I can rearrange the structure accordingly? I read the mavenization threads, but it seems all a bit fuzzy right now. Does anyone know how a proper block should definitely look like? max -Original Message- From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] Sent: Friday, December 16, 2005 12:48 To: dev@cocoon.apache.org Subject: Re: rejuvenating the webdav block On 12/16/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Dear Cocooners, I would like to start rejuventating the webdav block. We have some code to do cool things like event caching and a more general purpose WebDAVTransformer (which can also do propfind, proppatch, etc). If you know anything you would like to see in the webdav block, please say so now. Maybe I can work it in! Lovely! You might also want, while you're at it, considering the new block layout so that it will be easier to build it as a block proper. I might also have some stuff to commit (flowscript support, basically): will get back with that ASAP. 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: [vote] Jean-Baptiste Quenot as new Cocoon committer (was Re: Problem with CachingPointProcessingPipeline)
Please cast your votes! +1, welcome! Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
RE: rejuvenating the webdav block
Hi! Can you show me a block (or some sort of description of how it should look like) so I can rearrange the structure accordingly? I read the mavenization threads, but it seems all a bit fuzzy right now. Does anyone know how a proper block should definitely look like? max -Original Message- From: Gianugo Rabellino [mailto:[EMAIL PROTECTED] Sent: Friday, December 16, 2005 12:48 To: dev@cocoon.apache.org Subject: Re: rejuvenating the webdav block On 12/16/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Dear Cocooners, I would like to start rejuventating the webdav block. We have some code to do cool things like event caching and a more general purpose WebDAVTransformer (which can also do propfind, proppatch, etc). If you know anything you would like to see in the webdav block, please say so now. Maybe I can work it in! Lovely! You might also want, while you're at it, considering the new block layout so that it will be easier to build it as a block proper. I might also have some stuff to commit (flowscript support, basically): will get back with that ASAP. 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: rejuvenating the webdav block
Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED] wrote: * Max Pfingsthorn: - Currently, there is no way to access older revisions of a source, you have to guess In the WebDAV jargon, this is the REPORT method. Maybe we can call that getRevisionHistory() to be protocol-independant? Yes, okay. ... On another note: I need the eventcaching block for webdav, but that one only needs jms in one class, and databases in the samples. So, I'll work on the dependency issue there instead of in the webdav block directly. Did you find out why the eventcache block is needed? And BTW is it really useful to have 3 different blocks: webdav, slide, repository? And there's also the jcr block, which has very similar features. Hmm, as I see it the repository block is a generalization, and the webdav block is an implementation of a specific repository, meaning a webdav one. I haven't looked at the jcr block, but it should be one implementation as well. The slide block actually uses an embedded slide instance instead of via the webdav protocol. The eventcache is needed for more advanced caching. The components need to know about it to be able to construct the right Validity objects for Source.getValidity(). We found out that eventcaching is really key for good performance of the website, so I would consider it a good kind of dependency. Of course, the eventcaching block depending (indirectly) on the database block is a bit silly. I didn't notice the SlideSource, don't really know why we use WebDAVSource instead of SlideSource in our project. Maybe because SlideSource has nothing to do with WebDAV, it only handles a local repository? Exactly. max
RE: rejuvenating the webdav block
Hi!
Thanks, I would have missed the versioning in the source. Unfortunately, there
are some incompatibilities between the existing VersionableSource interface
from the repository block and what can be done via WebDAV.
Some issues:
- Resources in WebDAV are not versioned by default [1]
- Currently, there is no way to access older revisions of a source, you have to
guess
- No way to make new revision either (in webdav via checkin/out)
So, seeing the current shortcomings and inadequacies of the VersionableSource
interface and seeing that SlideSource is the only implementing class, I would
propose the following:
I would refactor the interface to something like this:
public Interface VersionableSource {
boolean isVersioned();
boolean startVersioning();
String getSourceRevision();
String getLatestSourceRevision();
Map getSourceRevisions(); (renders the version tree, maybe there is a better
way)
boolean checkout();
boolean uncheckout();
boolean checkin();
}
Other than that, I would also like to add a removeSourceLocks(SourceLock)
method in LockableSource.
On another note: I need the eventcaching block for webdav, but that one only
needs jms in one class, and databases in the samples. So, I'll work on the
dependency issue there instead of in the webdav block directly.
WDYT?
max
[1] http://www.ietf.org/rfc/rfc3253.txt
-Original Message-
From: Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED]
Sent: Friday, December 16, 2005 17:51
To: dev@cocoon.apache.org
Subject: Re: rejuvenating the webdav block
* Max Pfingsthorn:
I would like to start rejuventating the webdav block. We have
some code to do cool things like event caching and a more
general purpose WebDAVTransformer (which can also do propfind,
proppatch, etc).
If you know anything you would like to see in the webdav block,
please say so now. Maybe I can work it in!
Hello Max,
Thank you for taking care of the WebDAV block. We wish to have
versioning support in WebDAVSource: checkin(), checkout(), lock(),
unlock(), versionControl(), and so on.
Is there an open-source implementation for that?
--
Jean-Baptiste Quenot
Systèmes d'Information
ANYWARE TECHNOLOGIES
Tel : +33 (0)5 61 00 52 90
Fax : +33 (0)5 61 00 51 46
http://www.anyware-tech.com/
rejuvenating the webdav block
Dear Cocooners, I would like to start rejuventating the webdav block. We have some code to do cool things like event caching and a more general purpose WebDAVTransformer (which can also do propfind, proppatch, etc). If you know anything you would like to see in the webdav block, please say so now. Maybe I can work it in! Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
RE: Cocoon NG vision: focusing on the primary functionality
Hi! Very nice task :D Here is my vision, given these constraints: The next Cocoon should be boiled down to the basics most people need, and it would do what Cocoon 2 does best: XML processing. However, it would also allow for a more application-oriented (i.e. object oriented, not procedual or scripty) way of developing, using an MVC-based approach. Having said this, the next Cocoon would consist of: - Only POJOs (possibly shipping with some Dependency Injection based container, but being _independent_ of it) - Nice and consistent seperation of interfaces and implementations - e.g. sourceresolver, caching, processor, etc. - also includes auxiliary services, like logging interfaces - A flexible plugin model (possibly uses OSGI, but more for its classloading and class visibility features) - plugins may provide new implementations of any interface in the core or other plugins - Interfaces to processing implementations, plus core-ish plugins: - A similar pipeline (possibly pull-based) architecture as Cocoon 2 (only processing, not sitemaps) - A new MVC architecture (with no limitations on the model by e.g. assumed persistence solutions) - A generic sitemap api for the processing implementations (enables dynamic pipelines, and a flexible sitemap language) - An authentication architecture which integrates with the processing architecture - A default servlet adapter for the Cocoon application This would mean a very tiny, error-unprone core, easy extensions, independence of IoC containers and their quirks, support for both great Cocoon 2 features plus new web-application oriented features and more flexible authentication. Also supports coding according to Marc's layers. Just my very own vision. max -Original Message- From: hepabolu [mailto:[EMAIL PROTECTED] Sent: Thursday, December 08, 2005 10:37 To: dev@cocoon.apache.org Subject: Cocoon NG vision: focusing on the primary functionality Guys, reading the threads on Cocoon NG (Cocoon X? ;-) ) I get the feeling that, although much is said, you're more or less running around the heart of the matter without actually getting there. So maybe this little exercise might help: What should be the first functionality of Cocoon NG if you are allowed to work on it only once and have to leave it in a useable state? More elaborate: you have a reasonable but short period of time to start with a clean slate. You can either start from scratch or haul in existing stuff from Cocoon 2.X. You should deliver something useful, i.e. solid, functional software, even if you will never be able to revisit this project again. Yet it should be flexible/well-designed enough to be extended/expanded should there be time and resources. Extra constraint: it should be compatible with Cocoon 2.X, either through backward compatibility or through a well-defined conversion process. If not, it should be documented why this is still useful. If all this applies, what is it that Cocoon NG does? Bye, Helma
Standalone components?
Hi! I've had a bit of trouble with components that are not referenced by others. I need to start (i.e. service, configure, initialize, etc) a component once the container is started. Can I do this somehow? I noticed an attribute called activation (next to logger) which can be set to inline in cocoon.xconf, but that doesn't seem to work. Xdoclet tags for avalon like @x-avalon.lifestyle type=singleton and things don't do it either (yes, I do extract the metadata in my build process). My specific usecase is: I have a component which is not really a service as other components don't depend on it. This component subscribes itself as a listener of another component, and according to events acts on yet another component. I want to use this to consume event messages (from the eventcache block) and notify an object model, which is reachable through another component. Any ideas? Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
RE: Standalone components?
Thanks! I'll try that. max -Original Message- From: Torsten Curdt [mailto:[EMAIL PROTECTED] Sent: Friday, December 02, 2005 12:59 To: dev@cocoon.apache.org Subject: Re: Standalone components? Hi! I've had a bit of trouble with components that are not referenced by others. I need to start (i.e. service, configure, initialize, etc) a component once the container is started. Can I do this somehow? Not sure whether I understand the exact problem but threadsafe components are started on container startup. cheers -- Torsten
RE: event aware object cache?
Geoff Howard [mailto:[EMAIL PROTECTED] wrote: On 11/21/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Hi Cocooners! I have a question: I couldn't find a nice EventAware object cache in Cocoon, the eventcache block only implements the o.a.c.caching.Cache which I need to pass a byte array. Serializing/deserializing is not really an option for me. What I would like is a (not necessarily persistent) EventAware cache for objects used for form my responses of a generator. I could imagine that this sort of cache might be useful for others as well. If so, and it is not implemented yet, I would like to go ahead and do so. WDYT? Does anyone have any pointers for me? Hmm, it's been a while since I've looked at this and the code base WRT the Cache/Store code has changed since in a way I didn't keep fully abreast of. The original intention of the EventAware code was to do exactly what you wanted. IIRC the Cache used to have a transient front-end backed by a persistent backend transparently. Since then the terminology and code was changed I think to have Stores be transient and Cache persistent. I see, so your suggestion would be to implement an EventAware MRUMemoryStore? And maybe also make the EHDefaultStore EventAware? I guess for that, an EventAwareManager would be required cause right now the JMSEventMessageListener looks up the EventAware cache by itself instead of getting a list of EventAwares and calling processEvent on them. One big problem though: Stores are deprecated... :( For your need, it may only be necessary to factor the relevant code out of the Cache to a more generic place where both Store and Cache can take advantage of it. Not sure if that is necessary. I can see that the functionality is rather the same, but making a wrapper around the ehcache Cache or something like that seems a little weird cause we would dictate which cache implementation to use. Maybe the EventAware interface is enough, but add a manager for them? I guess we could provide ready wrappers around different implementations, WDYT? I can't give it a lot of time at the moment, but do want to help make sure this is generally useful. Can you provide some more details of the problem as it exists now to help me get up to speed quickly? My problem is that I need to generate xml ( obviously ;) ), but the xml tree represents a directory tree on a webdav server. So, I don't need to walk over all collections to generate my xml, just over the ones that changed. For that, I'd like to keep two things in memory: A list of children per node and a set of attributes per node. These might not be Serializable (right now I just stuff the AttributesImpl object into a map)... So, what I want is a way to remove these two from the cache/store if a corresponding event comes in so they are regenerated, but I don't have to rebuild the complete structure. Another usecase in favor of having a general EventAwareManager to keep track of EventAware instances would be to have a way to notify a business object model when the backend changes, or generally notify it via JMS. We'll be running into that soon over here, so it would be nice to get some ground work done. WDYT? max
RE: event aware object cache?
Geoff Howard [mailto:[EMAIL PROTECTED] wrote: On 11/23/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: Geoff Howard [mailto:[EMAIL PROTECTED] wrote: On 11/21/05, Max Pfingsthorn [EMAIL PROTECTED] wrote: ... I missed the deprecation of the Stores discussion. Do you have some pointers in the dev list archives? Oh, no, nevermind. The Store interfaces moved into excalibur(?), but the stores in general aren't deprecated... My mistake. Would it be sufficient to configure JMSEventMessageListener with a list of EventAwares? If the EAManager is necessary, I guess it would have to be configured with such a list unless you can think of a way for it to discover all EventAwares in the system? Well, I was thinking of registering event awares with that manager so its more up to the components... Then again, if you have multiple jms providers, you might want to listen to a specific topic, or only forward events to a subset of EAs... Its hard to do this kind of thing with lookup IoC. Also, its a tradeoff between configuring the connections between source and sink of the events (e.g. the path between the jms listener and the cache) as roles to look up or as some sort of routing configuration. We could do this by: 1. Letting event awares choose sources/topics to listen to 2. Configuring a name per event source Then, a listener can say, I want to listen to topic foo, no matter where from, or even listen to bar only from source baz and bas. WDYT? ... Another usecase in favor of having a general EventAwareManager to keep track of EventAware instances would be to have a way to notify a business object model when the backend changes, or generally notify it via JMS. We'll be running into that soon over here, so it would be nice to get some ground work done. That is outside the original intention but should work. There may be some odd block dependencies if someone wants to do that but not use an EventAwareCache, they could wind up requiring both the JMS block and the EventAware block anyway. If you can see a way to allow your use-case but avoid that false dependency, that'd be great. I don't really see that problem as you still have to configure which cache to use in your cocoon.xconf. Otherwise, if you want to use jms/eventaware, of course you need both blocks... I don't really understand the false dependency, can you explain? max
RE: event aware object cache?
Geoff Howard [mailto:[EMAIL PROTECTED] wrote: ... Would it be sufficient to configure JMSEventMessageListener with a list of EventAwares? If the EAManager is necessary, I guess it would have to be configured with such a list unless you can think of a way for it to discover all EventAwares in the system? Well, I was thinking of registering event awares with that manager so its more up to the components... Then again, if you have multiple jms providers, you might want to listen to a specific topic, or only forward events to a subset of EAs... Its hard to do this kind of thing with lookup IoC. Also, its a tradeoff between configuring the connections between source and sink of the events (e.g. the path between the jms listener and the cache) as roles to look up or as some sort of routing configuration. We could do this by: 1. Letting event awares choose sources/topics to listen to 2. Configuring a name per event source Then, a listener can say, I want to listen to topic foo, no matter where from, or even listen to bar only from source baz and bas. WDYT? Yes, that sounds about right though I haven't fully thought it through. Okay. What about routing tables? Like the one shown under Internet Routing - Internal Routing Tables in [1], we could make a list of routing rules: Source | Topic | Listener - foo| bar | baz means topic bar from source foo should be delivered to listerner baz * | barr | baz baz should also get any message with topic barr from any source foo| * | foolist foolist listens to any topic from source foo foo| bing | *foo distributes any bing message to any listener foobar | * | *foobar distributes any message to any listener * | bang | *bang messages are always delivered to all listeners from any source * | * | bazz bazz listens to any message Now, this table can be configured for the EventAwareManager in cocoon.xconf. I would also add methods such that listeners can add/remove rules, or have some way to do this during runtime in any case. Maybe with an interface using cforms? :D Covers all cases, right? ... Another usecase in favor of having a general EventAwareManager to keep track of EventAware instances would be to have a way to notify a business object model when the backend changes, or generally notify it via JMS. We'll be running into that soon over here, so it would be nice to get some ground work done. That is outside the original intention but should work. There may be some odd block dependencies if someone wants to do that but not use an EventAwareCache, they could wind up requiring both the JMS block and the EventAware block anyway. If you can see a way to allow your use-case but avoid that false dependency, that'd be great. I don't really see that problem as you still have to configure which cache to use in your cocoon.xconf. Otherwise, if you want to use jms/eventaware, of course you need both blocks... I don't really understand the false dependency, can you explain? I thought I had remembered that the EventAware interfaces and implementations were all in the two blocks, but now that I think of it, I guess EventAware itself is in core? I just switched to a new laptop recently and don't even have a local copy of the source on it yet. EventAware, EventAwareCacheImpl, EventRegistry, JMSEventMessageListener, etc are all in the eventcache block. JMSEventMessageListener extends AbstractMessageListener from the jms block. I just don't see how you can use the eventcache or eventaware block without needing the jms block... at least right now. Maybe we can factor out an interface for a generic EventSource which associates with the EventAwareManager (or maybe EventMultiplexer?) to deliver events? Then the jms block can provide a jms implementation of it (the JMSEventMessageListener) and there you go, blocks decoupled! :) WDYT? Anyway, it's almost certainly not important to consider at the moment. Okay. Am I ready to roll, then? max [1] http://www.scit.wlv.ac.uk/~jphb/comms/iproute.html
RE: event aware object cache?
Geoff Howard [mailto:[EMAIL PROTECTED] wrote: ... Source | Topic | Listener - foo| bar | baz means topic bar from source foo should be delivered to listerner baz * | barr | baz baz should also get any message with topic barr from any source foo| * | foolist foolist listens to any topic from source foo foo| bing | *foo distributes any bing message to any listener foobar | * | *foobar distributes any message to any listener * | bang | *bang messages are always delivered to all listeners from any source * | * | bazz bazz listens to any message Gotcha. If you have a need for this now, great - seems like maybe YAGNI would apply otherwise. Yeah.. Had a slight ring of overkill to it... ... Am I ready to roll, then? max I'd say so! Great! I'll keep you posted on my progress :) max
event aware object cache?
Hi Cocooners! I have a question: I couldn't find a nice EventAware object cache in Cocoon, the eventcache block only implements the o.a.c.caching.Cache which I need to pass a byte array. Serializing/deserializing is not really an option for me. What I would like is a (not necessarily persistent) EventAware cache for objects used for form my responses of a generator. I could imagine that this sort of cache might be useful for others as well. If so, and it is not implemented yet, I would like to go ahead and do so. WDYT? Does anyone have any pointers for me? Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
Re: [cforms] - fd:suggestion-list released in 2.1.8?
On 11/20/05 10:28 AM, Antonio Gallardo [EMAIL PROTECTED] wrote: ... About Dojo, one of the concerns is that it takes longer initializing on the client. Maybe it is just due the internet wire. Let me explain, seems like dojo use a load on demand scheme to load the required JS files, hence it connects back to the server and this takes time, making the initialization slower. A bug or a feature? Dunno Dojo has a compressor which is supposed to speed up javascript initialization. See [1]. Not sure if it takes care of making dynamic loads static, but that would be nice. ... Then the question is. How we will approach? A. Having our own AJAX code in cocoon B. Using one of the AJAX frameworks outthere. I prefer to go for A. until the dust go out in the AJAX world. Seems like every week is an annuncement of a new AJAX framework now! But if B. is the way to go, then please share with us wich one is the best for us. I would definitely go with B. Personally, I think maintaining such a library would just be way too much work. Seeing what sort of people work on Dojo, we probably can be sure that it will be around and maintained for a while. ... -- 0 - Also, with the suggestion-list we can also create a new multivalue widget rendering. One without an selection-list but with one suggestion-list using AJAX. Usecase: You need to define a group of 10 users from a list of 200+ potential users. Is this too specialized or do you think it makes sense? I like the idea. You mean sort of by populating a list with entries from a suggestion-list? Bye! max [1] http://dojotoolkit.org/docs/compressor_system.html
RE: svn commit: r330598 - /cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Hi!
I actually like this for exactly the reason Giacomo pointed out. The thing I am
always afraid of is vulnerability to malicious requests, which this actually
prevents.
This is in itself not a template (i.e. rendering) option but changes the model
on the fly, which can be considered as a view of the model, so I would think
it does belong into the template.
Alternatively, you can of course take care of this in your flowscript which
calls the template pipeline in the first place, but then you have to know the
correct ID of the widget, which can be rather hard, especially if you use
libraries or some other way to generate forms.
So, in general, +1 for this change.
max
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] Behalf
Of Giacomo Pati
Sent: Thursday, November 10, 2005 13:36
To: dev@cocoon.apache.org
Subject: Re: svn commit: r330598 -
/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/genera
tion/JXMac
rosHelper.java
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Ok, lets discuss this :-) maybe there are other ways to do it.
The use case to this is:
a) Suppose you have a repeater showing some informations.
b) Suppose the users viewing that information can have different role.
Now, depending on the role the user has
1) he may not see some of the rows (which would be
filtered out before
passing it to the template of course)
2) he may see some of the row (output state)
3) he may even edit some of the rows (input state)
How would you accomplish this in a repeater without enabling the
template to change the state in the repeater according to the role of
the viewing user (which is passed down the pipeline)?
Using widgets per role is very ugly (I've tried that) and may
complicate
validation of not displayed widgets in a row.
Any suggestion would be welcome otherwise I'd like to have
that change
going into the repository (this or the following release).
IIRC there is no place other than the template to handle the repeater
model content associated to a widget.
Thanks and ciao
Giacomo
On Thu, 3 Nov 2005, [EMAIL PROTECTED] wrote:
Date: Thu, 03 Nov 2005 18:17:42 -
From: [EMAIL PROTECTED]
Reply-To: dev@cocoon.apache.org
To: cvs@cocoon.apache.org
Subject: svn commit: r330598 -
/cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/genera
tion/JXMacro
sHelper.java
Author: sylvain
Date: Thu Nov 3 10:17:39 2005
New Revision: 330598
URL: http://svn.apache.org/viewcvs?rev=330598view=rev
Log:
Reverting r328311: allowing the template to change the
widget is a fundamental change that must be discussed prior
to be included in a release
Modified:
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generat
ion/JXMacrosHelper.java
Modified:
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generat
ion/JXMacrosHelper.java
URL:
http://svn.apache.org/viewcvs/cocoon/blocks/forms/trunk/java/o
rg/apache/cocoon/forms/generation/JXMacrosHelper.java?rev=330598r1=330597r2=330598view=diff
==
---
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
(original)
+++
cocoon/blocks/forms/trunk/java/org/apache/cocoon/forms/generation/JXMacrosHelper.java
Thu Nov 3 10:17:39 2005
@@ -287,10 +287,6 @@
*/
public void generateWidget(Widget widget, Map arguments) throws
SAXException {
// Needs to be buffered
-String state = (String)arguments.get(state);
-if (state != null) {
-widget.setState(WidgetState.stateForName(state));
-}
RootBufferingPipe pipe = new RootBufferingPipe(this.cocoonConsumer,
arguments);
this.pipeStack.push(pipe);
widget.generateSaxFragment(pipe, this.locale);
- --
Giacomo Pati
Otego AG, Switzerland - http://www.otego.com
Orixo, the XML business alliance - http://www.orixo.com
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)
iD8DBQFDcz7KLNdJvZjjVZARAk35AJoDUnrsJHorEvSl4/Itmu2qM+SZbgCgh2Xe
fmH48PeQmNUoOAGYg2QTKXo=
=Cbm2
-END PGP SIGNATURE-
RE: [VOTE] Naming rule for HTML IDs generated by CForms
Hi all, [X] foo.bar:input (colon, not CSS-friendly because of IE) +1 from me as well. It's the least evil one, it does interfere with the libraries meaning of :, however, since it is in effect hidden from the user, it's okay. Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl -
jira karma
Hi all, I just made an account in Jira (mpfingsthorn, email: [EMAIL PROTECTED]), can you add me to the right groups? After two weeks of exams and subsequently needed rest, I am finally ready to dive into cocoon again ;) Thanks a lot! max
fix form libraries before freeze please?
Hi all! I still have problems committing, so if one of you could apply the patch from bug 37005[1] for 2.1.8 before the freeze, that would be great! Bye, Max Pfingsthorn For lazyness: [1] http://issues.apache.org/bugzilla/show_bug.cgi?id=37005
RE: [Vote] Packaging of docs
Please cast your votes for: a) Include the docs in the distribution b) Provide a separate docs package to download The docs will be the ones generated by forrest. +1 for b) as well. max
RE: [Vote] Doc format for release
... Yes, I agree with Ralph and you that we should have a seperate download for our docs and don't add them to the normal distribution at all. +1 for separate download. me too +1 for separate package. max
RE: [Vote] Status file per block
-Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Sunday, October 16, 2005 17:18 To: Cocoon-Dev Subject: [Vote] Status file per block Starting with 2.2 we want to have different release cycles etc. for each block so I think it's time to split up the status.xml file and create a file for each block. This status file will only contain the changes (no committers list) for this block. I think splitting up makes tracking changes in a block much easier. (We can - if required - aggregate all those files into one big status.xml.) So please cast your votes. +1, also for the m2 format. ( yeay, my first vote! :D ) max
RE: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)
... Sorry for the delay in my reply. It is hard to follow 100 mails daily on the list. ;-) No problem, I feel your pain ;) ... Very easy. Since the talk is about conventions as in Rails, then here we introduce a new development rule again: The field name should be unique in the whole application. If you use the same name in 2 different forms, then they refer to the same field in the database. Tha means, if we decide a field is called userName, then whenever we use this name we are refering to the same field! Even if the name is in 2 different forms. Okay, but don't you run into ambiguity issues then? Maybe we can qualify the field id by a table name? Something like cars.brand to differentiate it from motocycles.brand. Would make it clearer, I think. Would also help when generating the final ER diagram. Meaning, do you have a good algorithm to extract an ER-diagram from a bunch of forms? Well, still not, but the above rule, allow to create it. WDYT? True. ... I guess it could work with Sylvain's suggestion that the user makes a library for each entity and uses those for building the final forms. However, this is a rather rigid assumption... and still hard to analyze. The forms library is still valid. It address another user need: Reutilization of user predefined field types. Of course we should also provide a default cform field library. Errr.. What do you mean now? I thought you want to go the other way? If you really want to generate the DB schema from forms then you need to analyse libraries as well to get the complete picture, not provide them... Or did I get something wrong? ... Wouldn't it become a sort of ER diagram then? Yes, somehow. But an E-R diagram from wich can be very easy to build the database model in DDL (Data Definition Language). Of course, isn't that what general ER diagrams are used for anyway? Plus the calculated/processing fields? Yes. Since the sum of calculated fields is less than the sum of non-calculated (hence persisten) fields, we can also introduce a new attribute to define then. That way we can also use the form library to have some predefined calculated fields. As a sample. The sum of the column in a invoce. The calculated field can also use the value of another calculated field to calculate itself. ie: the tax field in an invoice. or the subtotal + shipping. I hope it explain the idea. If we think more about the caculated fields, they are not persistents. The calculated are showed in the form just to provide more info to the user. Often, they are not going to be store in the database. Sometimes, we need to store also calculated fields in the database for DB performance reasons. Okay, I can see that. So you are suggesting to extend the form definitions by an extra attribute per field in case we want to store it or not (default is to store it)? We don't want to just figure out what people is writing. If this was the case, then Druid is already done for 2 years now. We want to make a step further in the current approach. And in this case why the initial point for building the application are the forms not the db schema. I just don't see how explicitly not using the model the application is built on (db schema), but trying to infer it through some obscure means is better... Some reasons: 1-Faster development time. 2-Easier for people that does not understand SQL or write bad SQL. 3-Bring O/R mapping to the masses. ... between others that I cannot think right now are IMHO, full valid reasons to make a try to that. ;-) I agree. That would be nice. However, reason 2 is not really valid as there wouldn't be any SQL writing even if we had people make an ER diagram. You can do that just fine in XML and generate stuff from that (as Druid does, even visually, like you say). What we basically need, according to you, is to provide a bridge from a bunch of form definitions to a Druid ER diagram, right? that is all? ... I believe, Dreamweaver does something like this already. Then the last 20% of making new forms or adjusting generated ones goes quickly. I think we should think in Open Source tools only. Maybe this is just me, sorry. Of course, I agree, just wanted to point out that it is possible to do it quickly. ... Okay, but I think this will be very hard. Much harder than letting people do it the other way and edit generated stuff by hand. Yes, it is. And this is exaclty why we don't have it now. And why I explained we don't found the time to work on that. I just wanted to share the idea to see what other people can contribute to this. I think it is posible to build something like this here. To me there is no project that cannot be done is a Open Source community. As a sample, I remember how M$ pointed out for years that a project like a browser
RE: [VOTE RESULTS] new committer: Max Pfingsthorn
Dear all, Thank you very much! I am very excited! For those of you who I unfotunately didn't meet at either ApacheCon or the GetTogether, a few lines about myself: I've been using Cocoon for almost a year within the scope of my job at Hippo here in Amsterdam. My first programming experience with Cocoon (a few little custom generators and transformers) was around 8 months ago. Since then, I've been impressed by Cocoon many times, mostly the flexibility and already implemented functionality. Recently, I got awed by Ruby on Rails, but I think we can do better! ;) Maybe I should mention here that I get very excited about cool interfaces, which is why the new Ajax/Rich Client hype is just for me! My first ever programming effort dates back as far as 9th grade, that is almost 10 years ago. I started with Turbo Pascal, went on to C/C++ and Java (with some detours through Python, Php, and other scripting languages). C++ and Java are very much alike, however, that extra bit Java has to offer is very appealing.. and makes me feel much safer as a programmer ( it's good to know I can't crash the machine with a Java program :D ). When I am not programming, I am a student at the University of Amsterdam and going for a Master of Science in Artificial Intelligence. There, I do Intelligent Systems, mostly Multi Agent Systems. In 2006, I might participate (yet again) in RoboCup Rescue[1] as part of my Master Thesis. I am looking forward to contributing more in the future! Bye! max [1] http://www.robocup2006.org/sixcms/detail.php?id=242lang=en -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Friday, October 14, 2005 08:25 To: dev@cocoon.apache.org Subject: [VOTE RESULTS] new committer: Max Pfingsthorn Le 11 oct. 05, à 08:28, Bertrand Delacretaz a écrit : ...So I have the pleasure of proposing Max as our new committer!... Congratulations Max, you are elected with 21 binding +1s 1 non-binding +1 one -0 Welcome aboard - as you already have an ASF account you should get full commit access soon, I'll ask for it. -Bertrand
RE: [VOTE RESULTS] new committer: Max Pfingsthorn
-Original Message- From: Jean-Baptiste Quenot [mailto:[EMAIL PROTECTED] Sent: Friday, October 14, 2005 11:21 To: Cocoon Dev Subject: Re: [VOTE RESULTS] new committer: Max Pfingsthorn Dear Max, Congratulations for becoming a new Apache member .. I wished, but not quite there yet ;) and Cocoon committer. It's worth the effort you made with the widget libraries. Thanks, I appreciate it! I wish you intend to enhance your work on the widget libraries. As you know, there are a few issues that we [1]discussed on this list, especially problem with a library defining several cross-referencing classes, and adding the ability to expand a group of widgets without creating an additional nesting level and without the need to use fd:class and fd:new. Yes, this is definitely on my list.. It is complicated though, so it might take a little time... Otherwise, I know you are interested in an AJAX lightweight portal. I intend to provide a sample to Cocoon because I implemented one myself, currently in my [2]private repository. I need to write a demo and ensure that it integrates seamlessly in the Cocoon samples. Yes, that's great! I initially wanted to work on it a bit during the gettogether, but the learning curve for the portal seems to be even steeper than for Cocoon itself ;) I had a look where a good place for extension might be, but I got lost in the sample already... Great to hear that you made it though, I think it would be a fantastic thing to have! Right now, I would like to focus more on Forms, stabilization thereof, Raccoon (the MVC side of it), and Ajax in general. Bye! max
RE: javadocs navigation (was: [RT] Is Cocoon Obsolete?)
... I was thinking about that recently - does anyone know a tool for tag-based navigation of javadocs? A better *navigation* of the javadocs, like being able to see all classes which have the sitemap generator tags, would help a lot. Can't you use the refdoc stuff for that? If it's not ready, which I guess it isn't from the STATUS at http://svn.apache.org/repos/asf/cocoon/gsoc/rgraham/refdoc/STATUS, I could take it from where Robert left it... WDYT? max
RE: [VOTE] new committer: Max Pfingsthorn
Hi everyone! Thank you so much for your votes! Very unexpected and very cool! :D I would be very honored to become a Cocoon Committer. Bertrand Delacretaz wrote: (and besides that, it will be cool to have more people with difficult names to type ;-) As long as I can call him Max... +1 Of course you can! :D Thanks again! max
RE: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)
Hi everyone! Sorry, this one turned out to be quite long with the quotes inside. Bear with me, please! :) ... Hmm, okay. But how do you generate a database schema from a few forms? Especially if there are graph-like relationships between the entities you cannot model in a form definition. Can you point to a graph-like relationships model that cannot be modeled in SQL? Maybe I don't got your point. Sure. Imagine you have a multi-component web application (as in it has a forum, a calendar, and a wiki) and you want all components to have file attachments. You wouldn't want to have a separate implementation for each of the components, but rather use a common one for all of them. Now, you don't have a tree structure of relationships anymore, but a DAG (directed acyclic graph, http://en.wikipedia.org/wiki/Directed_acyclic_graph). These can of course be modelled in SQL using foreign keys, but that is not the point. How do you know when you are actually referring to the same entity in your forms? Meaning, do you have a good algorithm to extract an ER-diagram from a bunch of forms? I think, that would be pretty hard... Especially if you say you might have multiple forms for the same table, where these forms might have different amounts of fields (some left out, some added for processing). I guess it could work with Sylvain's suggestion that the user makes a library for each entity and uses those for building the final forms. However, this is a rather rigid assumption... and still hard to analyze. If you think about it, the form code that is generated is not more than a skeleton anyway. No application will use the exact generated code. I think it would be much easier addind these extra bits (add extra fields or remove ones you don't want to edit) by hand than trying to figure out what people meant when they were writing their forms. No. The initial thread discussion was about patterns. The idea is to follow a pattern in order to get the code generated. I am not telling the initial form model is exactly as our current form definition. Aha. We believe we just need to define few more attributes in the form definition. Wouldn't it become a sort of ER diagram then? Plus the calculated/processing fields? We don't want to just figure out what people is writing. If this was the case, then Druid is already done for 2 years now. We want to make a step further in the current approach. And in this case why the initial point for building the application are the forms not the db schema. I just don't see how explicitly not using the model the application is built on (db schema), but trying to infer it through some obscure means is better... Maybe it would be more worthwhile to make an effort to write a graphical form editor for the lepido project which operates on a certain model of the data the application edits. I believe, Dreamweaver does something like this already. Then the last 20% of making new forms or adjusting generated ones goes quickly. After all it would be just a code generator to cover those 80% of work you have to do anyway, it does not have to be completely correct all the time (working, yes, but not correct for the specific application). Yes, it is a code generator, but no a simpler one. We are not talking about a simple XSL transformation. If this generator was so simple, it might be already implemented. We talk about parse the whole application form definition set , analyze it and get a DB schema for them. Okay, but I think this will be very hard. Much harder than letting people do it the other way and edit generated stuff by hand. Ruby on Rails does the bare minimum of code generation also basically on top of an ER representation, yet still, they do cover enough ground to build stuff fast. This is what I pointed from the begining. We think that starting from an DB model is the wrong way. The starting point should be the forms. In the form definition, we already have identifiers, datatypes, validations, constrains, relationshisps, etc. There is a lot information that can be reused for building a db schema. And once we have a db schema, we can reuse druid or an improved version to make this more complete. I have the feeling we are talking about the same thing, but call it differently. If we can augment an ER representation with some extra validation (which might actually happen in some databases as well, like using the CHECK constraint in postgresql for ranges and so on), this seems a more complete model of the application. I just don't think splitting the information in so many different, and possibly conflicting, parts (forms) is so great... You need to do a lot more analysis and bookkeeping that way. ... Now, if you define views also in terms of other views (like an eclipse perspective), this might work quite nicely. Don't get the point. Can you provide
RE: [QVote] Configurable default for sitemap reloading
But then you can't go and patch in little bugfixes into a running site. You'd have to restart the whole thing. Is there any way to do the cheap checking but leave out the expensive things (if there are such) in production? My 2 cents... max -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Monday, October 10, 2005 15:09 To: dev@cocoon.apache.org Subject: Re: [QVote] Configurable default for sitemap reloading Sylvain Wallez wrote: Carsten Ziegeler wrote: Does anyone mind if I add a setting that is used as the default value for sitemap reloading? Currently you can specify on each mount if the sitemap is checked for changes. Now changing this for each and every sitemap is really annoying and as we are all lazy, I think just adding a default I can simply switch on startup of Cocoon using our new property mechanism would help. So, if a mount does not have a value for check reload, the default is used (which is currently always true), if it has a value this one is used. IMO it doesn't even make sense to have this setting available in the sitemap engine, as *all* other files used by Cocoon at runtime are automatically reloaded by Cocoon if changed. Now I'm +1 for removing the check-reload attribute on map:mount/ Ok, so you always want to check for changes even in production? I would prefer to turn off *all* checking in production by just using a property. So what do you think of using a global check for reload property that is checked by all components that do reloading (sitemap engine, flow etc)? Carsten -- Carsten Ziegeler - Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.org/weblogs/rael/
RE: Reality Check (was Re: [SHRT] Cocoon on Rails Application Component Kernel (CRACK))
...
Let's worry less about perfection and worry more about some simple
changes that have huge payoffs. Once we have the basics down, we can
tackle some of the more difficult aspects.
Okay, but does that really need a completely new sitemap implementation?
The convention is {context}/{controller}/{action}[/{id}]
Well (assuming this sitemap was mounted for the context):
map:match pattern=*/*/*
map:call function=handleControllerCall
map:parameter name=controller value={1}/
map:parameter name=action value={2}/
map:parameter name=id value={3}/
/map:call
/map:match
map:match pattern=*/*
map:call function=handleControllerCall
map:parameter name=controller value={1}/
map:parameter name=action value={2}/
/map:call
/map:match
The handleControllerCall function can be written in flowscript or even use
the great new java flow as shown by Torsten Curdt during the get together. Not
sure how that class reloading works, but if you put the controller classes in
the same path, I guess the reloading feature would work there as well. So, you
can do something like...:
if(action==null) action=index;
contr =
Package.org.apache.cocoon.util.ClassUtils.newInstance(controllers.+controller+Controller);
if(id==null)
contr[action]();
else
contr[action](id); //well, a little more processing here to get the object
with this id first
cocoon.sendPage(views/+controller+/+action);
Right?
max
RE: Bug in Cocoon Forms libraries
Hi! Yes, I fixed this already, along with some other errors which sneaked into the code during integration, I suppose. I will make a patch for this tonight so it can get fixed as soon as possible. Bye! max -Original Message- From: Sergio Bossa [mailto:[EMAIL PROTECTED] Sent: Monday, October 10, 2005 16:40 To: dev@cocoon.apache.org Subject: Bug in Cocoon Forms libraries Hello all, While playing with some of the new features, I noticed a serious bug in the brand new org.apache.cocoon.forms.formmodel.library.Library class, which causes an ArrayIndexOutOfBoundsException. Take a look at the following piece of code, from the getDefinition(String key) method: String[] parts = StringUtils.split(SEPARATOR); librarykey = parts[0]; definitionkey = parts[1]; The problem is clearly a misuse of the split() method. I think it should be corrected in: StringUtils.split(key, SEPARATOR); Please, let me know. Regards, Sergio B. -- Sergio Bossa (http://sbtourist.blogspot.com/) - Pro-Netics s.r.l. (http://www.pro-netics.com) - Montag (http://montag.sourceforge.net) - QuickNote (http://quicknote.sourceforge.net)
trunk doesn't work without xsp block
Hi! I've build the trunk with all blocks disabled but forms, template and ajax. When I do cocoon servlet now, it gives a FileNotFoundException for C:\Projects\svn\cocoon-2.2-present\build\webapp\WEB-INF\xconf\cocoon-xsp.xconf which is referenced by C:\Projects\svn\cocoon-2.2-present\build\webapp\WEB-INF\xconf\cocoon-core-samples-main.xconf If I comment that reference, which is the only interesting line in that file, it works. Just wanted to let you guys know. Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl --
RE: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)
.. Summary: Input the form definitions and templates and let Lepido build the whole cocoon application for you! ;-) Druid looks great. But wouldn't it be better to let users make an ER diagram and take it from there? i.e. create db, java classes, ojb mapping, some default forms with the right definition and binding. Then, the only thing left to do is adjust the template and you are done! :) WDYT? max
RE: [SHRT] Cocoon on Rails Application Component Kernel (CRACK)
... Druid looks great. But wouldn't it be better to let users make an ER diagram and take it from there? i.e. create db, java classes, ojb mapping, some default forms with the right definition and binding. Then, the only thing left to do is adjust the template and you are done! :) Unfortunately, this does not solve the problem: 1. In a form we can have some fields that are calculated, hence there does not exists a corresponding DB field for it. 2. In other situation, you don't want to use all the DB table fields in the form. IMHO, there is no a correct way to go from the DB table to the form. More often than we though a DB table cannot be mapped to a form due the defined interface. Hmm, okay. But how do you generate a database schema from a few forms? Especially if there are graph-like relationships between the entities you cannot model in a form definition. If you think about it, the form code that is generated is not more than a skeleton anyway. No application will use the exact generated code. I think it would be much easier addind these extra bits (add extra fields or remove ones you don't want to edit) by hand than trying to figure out what people meant when they were writing their forms. After all it would be just a code generator to cover those 80% of work you have to do anyway, it does not have to be completely correct all the time (working, yes, but not correct for the specific application). Ruby on Rails does the bare minimum of code generation also basically on top of an ER representation, yet still, they do cover enough ground to build stuff fast. I was also thinking about the views... It might be nice to have a state as to which view to show. Some actions might change this state in a state-machine-like fashion. You might also have a way to directly change the current view. This would make it much easier to translate requests to the server as actual method calls on a controller or even model object (something like /shoppingcart/addItem). After calling the method giving a hashmap of parameters or something similar, the current view would be rendered. Now, it would be especially cool to do this ajax-style and send back a document containing changes to the current view. Without ajax, you get weird urls which are not bookmarkable at all but you translate the old request/response model in a more appropiate action/reaction sort of thing. Now, if you define views also in terms of other views (like an eclipse perspective), this might work quite nicely. WDYT? max
RE: New Ajax block, CForms autocompletion suggestion-lists
Hi! This is great! I was wondering if I can help out with any more ajaxization during the Hackathon. Is there still work to do? If yes, where and what? I would also like to try to ajaxize the portals a bit, for snappiness (like http://www.netvibes.com/, or http://www.google.com/ig). What do you guys think? Is it possible? Bye! max -Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED] Sent: Wednesday, September 28, 2005 12:33 To: dev@cocoon.apache.org Subject: New Ajax block, CForms autocompletion suggestion-lists Hi all, I just added a new Ajax block, which uses the Prototype [1] and Scriptaculous [2] JS libraries. This block is meant to hold Ajax-releated resources and classes that can be used by other components and blocks. One of them is of course CForms. A basic sample shows a field-based filechooser, where dynamic suggestion lists allow to autocomplete the input. I also added a very preliminary implementation of suggestion-lists for CForms. You can now write: fd:field ... fd:suggestion-list fd:item value=aa/ fd:item value=ab/ ... /fd:suggestion-list /fd:field Suggestion lists use the exact same code as selection-list, and you can therefore use any of the available selection lists implementations. Automatic styling for suggestion-list is not yet done, but a simple sample shows how to autocomplete a field. This uses of course the scriptaculous library provided by the Ajax block. All this will be demonstrated next week at the GT :-) Sylvain [1] prototype.conio.net/ [2] http://script.aculo.us/ -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
RE: [cforms] rethinking library naming
Hi everyone! -Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED] Sent: Monday, September 26, 2005 17:24 To: dev@cocoon.apache.org Subject: [cforms] rethinking library naming Hi all, We started to use the new widget libraries today, Nice to see it's used! :D ... These names make it very difficult to understand what does what. I'd like therefore to propose a renaming: - rename fd:class to fd:macro (this is the wording used on the wiki [1][2]) - rename fd:new to fd:expand: expanding is the word used traditionally to denote insertion of the macro contents at the current location. Hmm. Can we implement fd:expand and fd:new to be the same and call it fd:use (see below)? Then we can call fd:class fd:define and say use the thing defined there... - rename fd:import to fd:load-library, to clearly indicate that widgets in the library are made available but not inserted right now, in contrast with jx:import in JXTG that executes the imported template. Like it :) - rename fd:expand to fd:insert (or fd:use?) I would opt for fd:use for the reason below. For this last item, it has to be noted that it is equivalent to an untyped extension, i.e. fd:insert ref=lib:myfield/ is equivalent to fd:field extends=lib:myfield/ if of course myfield is a field. Hmm. This was initially thought of to be a way to just use the thing in the library. Usually, you won't know the type of the widget from the id alone since they should describe concepts now (i.e. customer, person, address). So, it would be easier to just say use the address than make a new group which looks like an address... By the way, don't forget to make similar changes to the bindings, otherwise it'll be chaos ;) Also, I think we should allow fd:load-library only as first-level children of fd:form and fd:library, as it doesn't really make sense to load a library anywhere in a definition, and it further clarifies that libraries are not expanded a the place where they are loaded. fd:form fd:load-library prefix=lib src=lib.xml/ fd:widgets /fd:widgets /fd:form Makes sense. We also encountered a problem with classes: if a library defines several cross-referencing classes (i.e. class A has a fd:new id=B and class B has a fd:new id=A), then the second fd:new fails because it searches in the current form whereas it should search in the originating definition. Hmm, this is a problem. I'm not sure how to fix this right now either... The problem are deep new's and expands's which are hard to find and change id's accordingly when another group definition is used in another form or library. The thing is that we have to have a deep copy of the corresponding group definitions all the way down the heirarchy graph (since new's can also occur in groups which can be included), otherwise we change the one which is in the library object, which is bad if the library is used in different forms with different prefixes. Seems to be quite hard to do this given the current state of things... Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl --
Google Summer of Code - the last minutes
Dear Cocooners, First of all I would like to thank the community for the great experience here. I really loved being part of the team! :) Now, a few minutes before the extended deadline, I am finally _done_. All samples work, docs are written and tests pass! Its a great feeling ;) Here is a little description of what I did: It is now possible to write separate collections of widget definitions and bindings which can be dynamically included. These are called libraries and can be imported into other libraries or form definitions/bindings. This doesn't mean these are automatically used in the including definitions or bindings, but they are available for reuse. Also, cache validation is checked recursively through all dependencies, so if a library deep in the inclusion tree changes, the complete path to the final definition or binding will be invalidated. This is something I always disliked with xsl:include/, so I fixed it here. There are three features implemented now: - Importing of external libraries into another library or form definition This works by mapping names to uris like so 'fd:import prefix=name uri=some/uri/to/a/library/'. Widgets inside the library can be referenced using name:widgetId. - Instantiating widgets from imported libraries This is done via 'fd:expand id=name:widgetId/' and directly evaluates to the referenced WidgetDefinition. This means that if a definition is expanded in a library, it can be reused in an importing definition/binding as if it was defined in the library itself. - Inheriting from other definitions/bindings An extra attribute extends on any widget definition or binding will cause the referenced entity to be resolved and used in the initialisation of the current definition or binding. This way, it is possible to override things like ids, datatypes, labels, xpaths and such and add things like validators or new child widgets or bindings. Widgets may also extend other widgets in the same container, meaning for example two widgets in the same group may extend each other, or two top-level widgets in a form may do the same. Not though that it is not possible to form cycles as references are resolved right away and cycles will result in silent ignores because of nonexisting widgets. This should change to complaining exceptions, and the code is there, just has to be uncommented. There are a few restrictions though: The complex Tree widget unfortunately does not support inheritance yet, however you can define it in a library and expand it in your form if you use it in many places. Also, single validators can only be added, not replaced or extended, since there is no way to address them right now. Same goes for selection list items, it is only possible to reset the selection list to something else. In case you want to know more, you can read the daisy page documenting the library subsystem [1]. My original proposal is still on the wiki [2]. To testdrive the new forms features, do this: - in your working copy of the trunk, cd to src/blocks/forms/trunk - svn switch https://svn.apache.org/repos/asf/cocoon/gsoc/mpfingsthorn/forms (svn will switch this part of the path to the repository above and update your working copy) - do a build in the root of the working copy - check out the forms samples! Thanks again for your opportunity and I am very much looking forward to contribute some more! Best regards, Max Pfingsthorn [1] Daisy page: http://cocoon.zones.apache.org/daisy/documentation/forms/685.html [2] Original proposal: http://wiki.apache.org/cocoon/CocoonFormsLibraryProject Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl --
RE: Event handling in form libraries
Hi! Okay, I see what you mean, but as a user of such a library, you have to be aware of what it requires. In my conception, the usecase you describe is not valid as you try to use only a part of an obviously connected set of widgets. You can do this, however you have to override the event handler in the inheriting widget. This would solve your problem just fine and allow for specifying complex widget structures in a library. I think we shouldn't impose restrictions on the use of libraries and specific parts of widgets within libraries. As long as it is fixable by adding a line or two in your definition and being a bit more aware of what you are inheriting from, this should be fine, right? Additionally, as Sylvain pointed out, there are valid uses of event handlers in top-level library widgets... i.e. on-change for an auto-completing text field via ajax (?). The thing is that even if we don't impose anything, we can still support encapsulating reusable parts, like the car selector or some metadata, in libraries (and promote this as a good practice in the docs). I think, we would be limiting the possibilities of the libraries if we treated them any different than a normal form definition. Bye! max -Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED] Sent: Saturday, September 03, 2005 18:06 To: dev@cocoon.apache.org Subject: Re: Event handling in form libraries Reinhard Poetz wrote: Sylvain Wallez wrote: - event handlers in libraries are allowed, but I don't think they make sense there (e.g. on-value-changed) Why not? A library may for example contain a group of related widgets with some interactions between them, e.g. a reusable car selector :-) [Moving this discussion between Sylvain, Max and me to cocoon-dev as it's of general interest] my wording was bad: I think they would make sense but I think the implementation is a bit difficult or at least this can cause strange errors. Maybe I'm wrong ... Here a simple example why I don't think that it can work with simply using the eventhandler code of the library in the form definition. LIBRARY libWidget1 has eventhandler that references libWidget2 libWidget2 FORM DEFINITION (imports above library) myWidget1 extends libWidget1 What happens now? The form doesn't has a reference to libWidget2. And if it had, how could the reference in the event handler code can work as it probably has a different name than libWidget2 or is reused several times in the form definition. Good point. We may allow on-change listeners in form libraries only in fields that aren't top-level, i.e. part of a group. Now aren't there any valid use cases where a field has an on-change that only acts on itself? Sylvain -- Sylvain WallezAnyware Technologies http://people.apache.org/~sylvain http://www.anyware-tech.com Apache Software Foundation Member Research Technology Director
RE: [GSoC] status reports?
Hi all! Well, I admit I am a bit behind, in a way. I have a strict plan by which I should be done by friday morning/thursday night ;) Progress-wise, I did everything preliminary. Partial widget definitions are possible and checked for completeness just before instantiation. I cleaned up the code a bit in general and I implemented a new component to manage libraries and look them up much like the FormManager. What's left is testing this library feature and inheritance. I decided to drop the Macro stuff in favor of New/Class which basically has the same functionality. Inheritance (when I'm done) will be available for _every_ widget, so you can even use it without using libraries at all. I had some problems, mostly unrelated to programming though. I planned the time so that I would work on it intensely in August, and just last week I had a bad flu and was sleeping basically for the whole week. I lost valuable time during that week, but as I said before, I have a plan and I just love it when a plan comes together! - John Hannibal Smith. ;) Steps until The End: 1. Test the ImportDefinitionBuilder/Library stuff, probably by use of a sample 2. Fix caching (done by the LibraryManager) to use timestamps as well so that forms know their dependencies have changed 3. Implement inheritance by copyconstructor. Builders are already modified to interpret configs as sensible as possible (i.e. merging display data instead of completely resetting it) 4. Binding Library: Model stuff is applicable, so port it 5. Template Library: Can't do much here, just provide inclusion mechanism for Class templates. 6. Oh, and docs of course... Phew, I did say it would be a tight plan, right? 1,2, and half 3 should be done by tonight/tomorrow morning, 4 tomorrow night, 5/6 thursday night. Then I will be on holiday until tuesday, and I'll have the 31st to wrap up anything that is still left. Okay, back to work! max -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Monday, August 22, 2005 08:55 To: dev@cocoon.apache.org Subject: [GSoC] status reports? With ten days left to finish the GSoC projects, I think it would be good for our three students to provide a short status report here. Think 3P: Progress: What have you accomplished and how does it compare to the project's goals. Problems: Is anything preventing you from reaching the project goals, and if yes can we do something about it. Perspectives: What are your plans until the September 1st pencils down deadline. Make sure to leave sufficient time for feedback where you need it. -Bertrand
RE: Cocoon Forms library... some more questions.
Hi!
Thanks for the comments, got some more though ;)
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Thursday, August 11, 2005 11:56
To: dev@cocoon.apache.org
Subject: Re: Cocoon Forms library... some more questions.
Max Pfingsthorn wrote:
Hi everyone!
Sorry that I haven't touched base for so long, but I am
pretty busy... I've been working on Slide a lot and I've been
implementing yet another Schema to CForms transformation,
both for my wonderful employer.
Is the schema to CForms something that could be contributed?
That would
be really great!
Yes, definitely! I'll post more when its more mature ;)
Anyway, I've finally found some time to write some more code
and now I've come across these few things... I thought it
would be nice to get some input from you guys:
1. Macro expansion, at library-build-time,
definition-build-time or instance-build-time? I guess this is
a performance thing, both ways: Takes more time to
instantiate a form, but if a library deep in the inclusion
tree changes, you don't have to reload all levels on top.
Kinda want to avoid what bothers me the most with xsl:include...
I would avoid if possible instance-build-time for performance
reasons.
About reload management, there could be a kind of include
tracker where
all includes files are registered.
For now, I thought I might handle it within one library object. A library might
have a dependenciesHaveChanged() method, which would access the local map of
dependencies and ask the librarymanager if they have changed. This method might
be called after the librarymanager knows that this library hasn't changed.
E.g.:
Library lib = (Library)this.cacheManager.get(source, PREFIX);
if(lib!=null lib.dependenciesHaveChanged()) {
lib = null;
}
if(lib==null) {
// load library specified by source
}
The librarymanager would then sort of recursively ask the libraries and we
would get a path of regeneration where needed.
2. Macro inheritance? I would imagine something like:
fd:macro define=mymacro
fd:field id=field
fd:labelmylabel/fd:label
/fd:field
/fd:macro
fd:macro define=mysecondmacro extends=mymacro
fd:field id=firstname replaces=field
fd:labelfirstname/fd:label
/fd:field
fd:field id=lastname
fd:labellastname/fd:label
/fd:field
/fd:macro
Instead of replaces, I could think of (goes for
library-level reuse too):
- replaces: well, completely replace other widget
- base: make a new widget alongside the other one, but take
the other as a base
- extends: elaborate on the definition of the other widget,
no new widgets created
I may have missed something, but this replace thing seems to me to
introduce way too much complexity. If you make the analogy
with classes,
a subclass cannot remove a method of its parent class and replace it
with something else. It can however overload it to provide
more, while
still respecting the contract of the parent class.
Yes, but what is the contract of a widget with the model? That the type stays
the same? If you think about macros more in terms of a template, then you might
need to replace something. But I agree, replace seems a little out of place.
BTW, macros don't seem to me very different from other
container widgets
such as repeater or even form, and this behaviour should actually be
consistent among all container types.
snip/
3. The wiki page said, there was support for parameterized
macros, but I don't see it... Any pointers?
Hmm... what about considering parameter-less macros for now? ;-)
Thats what I thought ;)
4. Library object: Should it be a standalone thing or rather
a AbstractContainerDefinition (like in the whiteboard code)?
I don't see the big use of it being a widget yet...
Me neither. Furthermore considering that it doesn't really
make sense to
instanciate a library!
OK.
5. Deep copying of widget definitions: This needs to be
possible to keep the definitions stored in the libraries
intact. This might be a hassle, especially with selection
lists and all that extra stuff. Does anyone have an idea how
to do this without implementing it for every widget?
What do you mean by deep copying? Is it copying in a definition the
elements that are reused from the definition it extends? I
don't think
it should be deep: since a definition is immutable, just copying the
needed information from the extended definition should be enough.
Yes, but we want definitions to be mutable, otherwise we cant change it anymore
by extending it. Or Builders can somehow go around the immutability. The way I
think it might be is that definitions should be kept in the library objects.
However, multiple widgets, and therefore definitions, might be derived from a
particular definition in the library. Since we are dealing with references all
RE: Cocoon Forms library... some more questions.
Hi again! -Original Message- From: Sylvain Wallez [mailto:[EMAIL PROTECTED] Sent: Thursday, August 11, 2005 16:32 To: dev@cocoon.apache.org Subject: Re: Cocoon Forms library... some more questions. snip/ Yes, but what is the contract of a widget with the model? That the type stays the same? If you think about macros more in terms of a template, then you might need to replace something. But I agree, replace seems a little out of place. Hmm... I wouldn't go as far as considering macros as a template. If you really need that flexibility, then use a pipeline to build the form definition! Okay... So a macro is just a container then, sort of like a wrapper? Maybe then the only one needed is extend? What makes a macro different from a class now? snip/ What do you mean by deep copying? Is it copying in a definition the elements that are reused from the definition it extends? I don't think it should be deep: since a definition is immutable, just copying the needed information from the extended definition should be enough. Yes, but we want definitions to be mutable, otherwise we cant change it anymore by extending it. ?? Why does extending a definition modify it? The extension definition should grab what it needs from the definition it extends, but not modify it. Also, how can you handle multiple definitions extending a single one if extending means modifying? That's why I wanted a complete clone, ie deep copy, of the definition to be extended/modified. But I see what you mean now. I guess this would work with the beanutils you mentioned before. I am a bit concerned about deeper things, like selection lists, event listeners and so on. We'll see how that goes. Or Builders can somehow go around the immutability. The way I think it might be is that definitions should be kept in the library objects. However, multiple widgets, and therefore definitions, might be derived from a particular definition in the library. Since we are dealing with references all the time, we would change the original definition object while deriving if we didn't make a complete copy of it first. Hmm... Not sure I got everything, but I insist on the immutability of definitions. If a library has changed, then it is rebuilt, and any definitions currently in use (through instances on which users are currently acting) still use the previous version of the definitions. Yes, of course. I wasn't talking about modifying definitions within a library, but rather modifying a copy of a definition from a parent library. So changing definitions while they are in use wouldn't happen. But I guess its just the difference or responsibility, who copies who. My first thought was that the library, when asked for a definition, returns a new definition which looks exactly like the one within the library. But we can do it the other way, that the library/macrodefinition asking the parent library gets the real definition and accesses whatever it needs. We would need some copy constructors then here and there. Ah: Or the builders would be kept by the library. Then they can pump out new definition objects for every time one is requested. This would mean though that the builders would have some state, which is not the case right now. And I guess the whole point was to _not_ reparse the xml all the time. Builders parse the XML and build definitions from it. If a library is stored as a set of definitions, I don't see why reparsing the XML would be needed when a definition uses a library? Exactly, but if it were stored as a set of builders which know how to generate new definitions, then they would have to know something about what they just parsed in order not to reparse the xml again and again. But storing the builders doesn't make sense, so don't worry about it. I was just thinking aloud. Thinking again, maybe it can work like this: 1. A builder starts generating the widgetdefinition from xml 2. The builder instantiates a new definition 3. The builder sees an extends attribute, asks the local library (given as a parameter to buildWidgetDefinition()) for that definition 4. The builder calls super.setupDefinition(widgetElement,newDefinition,baseDefinition), baseDefinition may be null if this widget does not inherit 5. The builder goes through all widget-specific settings, taking the base definition into account where necessary/possible (this might just access private members of the other definitions, without having to go through the getter/setter stuff used by BeanUtils) 6. The definition is returned By local library, I mean the Library object which would be used to resolve extends. This might be the Library object that is being build at the moment or a member of the form which is being build, since macro definitions can also occur directly in forms. This also preserves the separation between
Cocoon Forms library... some more questions.
Hi everyone! Sorry that I haven't touched base for so long, but I am pretty busy... I've been working on Slide a lot and I've been implementing yet another Schema to CForms transformation, both for my wonderful employer. Anyway, I've finally found some time to write some more code and now I've come across these few things... I thought it would be nice to get some input from you guys: 1. Macro expansion, at library-build-time, definition-build-time or instance-build-time? I guess this is a performance thing, both ways: Takes more time to instantiate a form, but if a library deep in the inclusion tree changes, you don't have to reload all levels on top. Kinda want to avoid what bothers me the most with xsl:include... 2. Macro inheritance? I would imagine something like: fd:macro define=mymacro fd:field id=field fd:labelmylabel/fd:label /fd:field /fd:macro fd:macro define=mysecondmacro extends=mymacro fd:field id=firstname replaces=field fd:labelfirstname/fd:label /fd:field fd:field id=lastname fd:labellastname/fd:label /fd:field /fd:macro Instead of replaces, I could think of (goes for library-level reuse too): - replaces: well, completely replace other widget - base: make a new widget alongside the other one, but take the other as a base - extends: elaborate on the definition of the other widget, no new widgets created fd:macro expand=mysecondmacro/ would give: fd:field id=firstname fd:labelfirstname/fd:label /fd:field fd:field id=lastname fd:labellastname/fd:label /fd:field I think we can implement rules for everything the DefinitionBuilders do for inheritance (i.e. by defining a label, it replaces the old one, and by defining a static selection list it extends the old one, etc...) inside the specific DefinitionBuilders. They should do the parsing/setting of the definition objects, but the validation should be up to the definition itself. This way, we can have partial definitions present in the library objects ready for extension and use at the same time. 3. The wiki page said, there was support for parameterized macros, but I don't see it... Any pointers? 4. Library object: Should it be a standalone thing or rather a AbstractContainerDefinition (like in the whiteboard code)? I don't see the big use of it being a widget yet... 5. Deep copying of widget definitions: This needs to be possible to keep the definitions stored in the libraries intact. This might be a hassle, especially with selection lists and all that extra stuff. Does anyone have an idea how to do this without implementing it for every widget? I am looking forward to some input! By the way, I know I am behind... But it is still a long time to September 1st, so I might just make it. Next weekend should be free (finally), so I'll be coding then. It would be great if we could address some of the issues above before that so I can dive in big time ;) Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl --
RE: svn access?
-Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Saturday, July 30, 2005 10:05 To: dev@cocoon.apache.org Subject: Re: svn access? use svn v2 as in very verbose? max
RE: svn access?
But I thought svn is at version 1.2.1.. ? The import I did was more of a test than real work... :D max -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Saturday, July 30, 2005 22:29 To: dev@cocoon.apache.org Subject: Re: svn access? Max Pfingsthorn wrote: -Original Message- From: Upayavira [mailto:[EMAIL PROTECTED] Sent: Saturday, July 30, 2005 10:05 To: dev@cocoon.apache.org Subject: Re: svn access? use svn v2 as in very verbose? As in version 2. But you appear to have managed a commit already. Regards, Upayavira
RE: svn commit: r226577 [38/40] - in /cocoon/gsoc/mpfingsthorn/forms: ./ WEB-INF/ WEB-INF/xconf/ conf/ java/ java/org/ java/org/apache/ java/org/apache/cocoon/ java/org/apache/cocoon/forms/ java/org/a
Hi! Sorry about that... I wasn't quite sure what this cvs list was for until now.. I subscribed now as well. I was just trying out my svn access, so things were bound to go wrong somewhere ;) bye! max -Original Message- From: Bertrand Delacretaz [mailto:[EMAIL PROTECTED] Sent: Saturday, July 30, 2005 23:48 To: dev@cocoon.apache.org Subject: Re: svn commit: r226577 [38/40] - in /cocoon/gsoc/mpfingsthorn/forms: ./ WEB-INF/ WEB-INF/xconf/ conf/ java/ java/org/ java/org/apache/ java/org/apache/cocoon/ java/org/apache/cocoon/forms/ java/org/apache/cocoon/forms/acting/ java/org/apache/cocoon/forms Le 30 juil. 05, à 22:48, [EMAIL PROTECTED] a écrit : Added: cocoon/gsoc/mpfingsthorn/forms/samples/swan/forms/template_model.xml URL: http://svn.apache.org/viewcvs/cocoon/gsoc/mpfingsthorn/forms/samples/ swan/forms/template_model.xml?rev=226577view=auto There were many commit messages from mpfingsthorn in the moderation queue tonight, I'm not going to moderate them all in. Details can be found in the gsoc/mpfingsthorn directory. Max, it looks like you're not subscribed to cvs@cocoon.apache.org, if that's correct please subscribe (but your commit messages will go through without moderation from now on anyway). -Bertrand
svn access?
Hi! I just got an email from root saying I have an account! Yeay! :) Thank you all very much for making this happen! I have a problem though... ssh and putty seem to hang when I try to log in to cvs.apache.org or svn.apache.org. The fingerprints are right, and I didn't even have a chance to type in my temporary password yet... Any ideas? It also said that I need you guys to give me access to stuff, so I was wondering if I might get a dir named max (or mpfingsthorn if you like to call it usernames) in the whiteboard. It would be a bit more clear than just giving me write permissions to the existing forms project there, and would keep the old code intact... What do you think? Best regards, Max Pfingsthorn Hippo Oosteinde 11 1017WT Amsterdam The Netherlands Tel +31 (0)20 5224466 - [EMAIL PROTECTED] / www.hippo.nl --
