Re: [RT] Revisiting Woody's form definition
Andreas Hochsteger wrote: Hi! I have to tell you that this thread is really a pleasure. It's really amazing what 'shared neurons' (like Marc called it) are possible to do ;-) I often have the feeling that while reading a message some ideas come to my mind and recognize that in the next post they are already covered. Perhaps many do like me to just sit back and enjoy watching ideas evolving to genious concepts. - No need to step in ;-) But don't saying anything and just watching might not be that good, so all I can contribute now are these pushing words. So keep up that good work to all people involved here! thx mate, finding shared neurons over at Sylvain's brain is already great fun, but statements like yours above give back tremendous Energy don't feel shy to step in and ride the wave if you feel like it... after all, I'ld like to return the favour :-) -marc= Bye, Andreas Marc Portier wrote: Sylvain Wallez wrote: Marc Portier wrote: Sylvain Wallez wrote: snip / agree totally: that is the crux! (maybe we should change the binding word: this validation is business-model specific) the main thing to note is that this specific validation will also be executed during the form.process() as such I looked at it as being the inline extra specification of an existing datatype (creating thus an anonymous inline datatype as we named it earlier) Ah, I understand ! Clever idea ! thx chap, I just extended your idea (I try to pick them up fast ;-)) in the same way this emerging 'business-specific datatype' could probably just be added into the datatype-catalogue I presume (for cross app consistency if that would make sense: e.g. suppose different forms for registration based on a possible of regular-gold-platinum-speaker case that map to the same uniqueness-id rule!) Yep. This would mean a new-user datatype extending user with the additional validation, right ? absa maybe this is explains why I added business-domain specific validation to be adding onto the datatype (and not be distinct from it) but basically I just wanted to make the remark that it has nothing to do with the actual binding.saveFormToModel() action Yes, you're right. But this may have to do with the object passed to this method (i.e. the application data). ah, you say that you would need the actual business-object to perform the validation? blast, I feel so stupid to have overlooked that fact (guess I didn't recognise this yet in any of the presented examples) I see two solutions for this : - the messy one (IMO) : add some non-visual fields in the form to hold the necessary data, - add a get/setApplicationData() on FormContext so that widgets can use it during form.process() if the form has an associated binding. surely I prefer the second. and guess what my mantra-remark is: it isn't really tied to binding :-) what I mean is that business-specific-validation that requires the ApplicationData present could be driven completely from the flow (without it making use of the declarative data-mapping offered by the current binding) in fact we might consider naming this the ValidationContextBean rather then ApplicationData? snip / basically I'm getting the feeling some of the discussions are mixing up what happens at different moments: 1/ while doing calls to form-manager and bind-manager (to be called typing? defining? setup?) 2/ while calling the form.process (datatype conversion, validation and eventhandling) 3/ while calling the binding.load/save (data mapping/copying) back to this discussion: recognising the 'business-domain-validation' stuff is IMO something that happens at 1/ by the form-manager even if it might be expressed in terms of syntax we know from the current binding definition but it has nothing to do with 'binding' - not with the activity in 3/ - and probably even not with the binding-manager more clear? Yes. I was fooled on the wrong track because binding was the only place where application data was available. But I don't agree business-domain-validation should happen in 1/ since it needs the form values parsed in 2/. sure, my mistake what I meant was that understanding (recognising) 'what to do' as extra validation happens in stage 1/ (typing) but you are right: performing the actual validation, i.e. 'doing it', is surely happening during 2/ (datatype conversion, validation and eventhandling) Actually, if application data is added to FormContext, it can be propagated in the ValidationRule's ExpressionContext (e.g. as an _applicationData_ variable). There will be then no difference between a form-only-validation and a business-domain-validation. We just have ValidationRules that use the application data variable and others that don't. What do you think ? I think it makes perfect sense, and even more important it shows we're on the same track here (also enthousiasm-wise :-)) Sylvain -marc= (looking forward to your conclusions /
Re: [RT] Revisiting Woody's form definition
Marc Portier wrote:
snip/
I see two solutions for this :
- the messy one (IMO) : add some non-visual fields in the form to
hold the necessary data,
- add a get/setApplicationData() on FormContext so that widgets can
use it during form.process() if the form has an associated binding.
surely I prefer the second.
and guess what my mantra-remark is: it isn't really tied to binding :-)
what I mean is that business-specific-validation that requires the
ApplicationData present could be driven completely from the flow
(without it making use of the declarative data-mapping offered by the
current binding)
in fact we might consider naming this the ValidationContextBean rather
then ApplicationData?
Agree. There's a great probability that ValidationData (why should it be
a bean?) will often be the same as ApplicationData, but it formally
doesn't need to. Moreover, there are certainly many uses cases where
ValidationData is required but the form has no binding.
snip/
Actually, if application data is added to FormContext, it can be
propagated in the ValidationRule's ExpressionContext (e.g. as an
_applicationData_ variable). There will be then no difference
between a form-only-validation and a business-domain-validation. We
just have ValidationRules that use the application data variable and
others that don't.
What do you think ?
I think it makes perfect sense, and even more important it shows we're
on the same track here (also enthousiasm-wise :-))
;-)
-marc= (looking forward to your conclusions / proposal - wiki page)
That's today's todo, but these important and stimulating discussions eat
up all most of my time. But we're near to the convergence point !
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
[RT] New Input for woody
I think we all know how woody works (apart from me...), so perhaps I could give some details about my idea. I don't want to propose this as an alternative to woody, I just want to give some input. So here we go: The idea is based on a separation between a template and a definition or binding for it. It's a little bit like woody but also different :) Here is a template example: page xmlns:dywel=http://zis.de/cocoon/dywel/0.1; dywel:DWForm id=form dywel:DWTextField id=name/ dywel:DWTextField id=street/ dywel:DWTextField id=city/ dywel:DWSubmit id=submit/ /dywel:DWForm /page Now, I think apart from namespace and element names this looks like a woody template (except form and submit). The difference lies in the second configuration file, that I call binding. It has an entry for each field used in the template: dywel:bindings xmlns:dywel=http://zis.de/cocoon/dywel/0.1; dywel:binding id=form actionnextPage/action /dywel:binding dywel:binding id=submit valueSubmit/value /dywel:binding dywel:binding id=name valueuser.name/value /dywel:binding dywel:binding id=city valueuser.address.city/value /dywel:binding dywel:binding id=street valueuser.address.city/value /dywel:binding /dywel:bindings How does it work? A component (a java implementation) parses the template and the binding file, the first time it's used. The template is compiled and the bindings are attached to the internal tree representing the template. A special generator uses the java component and asks it to render the page. Now the tree is processed. Each field knows how to render itself. To get the values for a form field, the field asks the component for the value for e.g. user.name. The component now has a getUser() method and the returned user object has a getName() method. When the form is submitted, the same tree is processed and the fields set the values using the component, so getUser().setName() is used etc. It's also possible to test via getUser().validateName() etc. For each form or better web page, you have to write the java component = controller. You simply inherit from a base class and provided methods to get your business objects. (I'm looking to simplify this using fom when everything else is set). So, this solution is tied to java objects (currently). Now, it is possible to specify additional validation and formatting in the binding, like: dywel:binding id=street valueuser.address.city/value validationa rule/validation formattera formatter/formatter /dywel:binding etc. This works pretty well (for me). Now I think this approach has two advantages. The people writing the template do not have to know anything about the binding, they simply create the page and insert a username field (same applies to woody). But the same mechanism is also used to insert values into the template, it's not restricted to form fields: dywel:DWString id=username/ and the binding dywel:binding id=username valueuser.name/value /dywel:binding The same works with repetitions etc. As it doesn't make sense to have soo many different approaches for form handling, I just wanted to integrate woody somehow rather than write everything again. So I guess the template is not the problem, replacing the namespaces and the element names et voila. The compilation of the template I currently use can cope with this I guess. Now the problem is my binding. It's different from the way woody defines things. Thoughts? Carsten
Re: AggregateField and SoC (was Re: [RT] Revisiting Woody's formdefinition)
Sylvain Wallez wrote: Andreas Hochsteger wrote: Hi! A short question comes to my mind, while reading your RT: Is it possible to use data types which are composed of several HTML input fields? We are currently using three input fields for dates (day, month, year) at our current form solution. Thanks for clearification! Marc explained how this can technically occur using AggregatedField. Now from a more semantical point of view, AggregateField is something I'm not very comfortable with. Let's consider its two use cases : 1/ Phone number example In this example, the displayed form shows only one input box, and its value is split into several non-visual subfields used by the application (country code, area code, number). Do these non-visual subfields really belong to the form definition if it never displays them ? Doesn't this split belong to the binding more than to the form definition ? 2/ Date split in several inputs The day/month/year inputs are just a particular visual implementation of a date widget (in the GUI meaning of widget). What if we finally decide to use a calendar popup instead of 3 inputs ? Do we have to change all form definitions ? Maybe that's just nitpicking, but I find this somewhat breaks Woody's clean SoC. Touché. Indeed: The aggregatefield was only introduced when we started thinking about binding... however, by now I have learned to appreciate the concept as having its own value in the woody-model You are right: it does somewhat hook up some back-end business-model vision onto the form-fields... but then again the (other) discussion we are having on the business-model-specific datatyping and even business-model-specific-validation does introduce the same level of mixing, no? And while we try to manage the good SoC here, the reality of the app will always be that people *know* (influenced by their business-domain knowledge on the app they write) about these aggregations when they model the form. And not unlikely the form will need to be able to exploit that knowledge. (In fact I guess that the reality vision expressed above is the real drive behind your current effort to make Woody more lightweight and generally usable?) Purely technical I have also the following argument: I expressed earlier that the Woody model should be seen as the insulation layer between how the end user sees things and how the business-models need to be presented... now, I'm ready to change that into: it is the insulation-POINT where the two worlds are meeting. The Woody form-model is what sits in between how the end-user consumes and edits his HTML-form and how the back-end presents and expects business data... On the HTML form there is weak typing (only strings) and weak structuring (only a map-like structure of request-params) compared to the back-end view of things (rigid structure of staticly typed values) The Woody-form-model takes up the responsibility of making the match between both, therefor it largely needs to know everything about both! (maybe this explains why it is perceived heavy at first glance?) So it needs - datatype knowledge and convertors (doing the string to YourType in 2 directions) - validation rules (making sure we're not handing over gibberish to the backend-model) - mapping pointers into the backend-structure (binding) - ... What the introduction of the Aggregate-field is adding to the show is something I would call 'granularity of information', and to date I'm convinced that the woody-model needs to be aware of the smallest granularity either it be imposed by the end-user view or the back-end structure: 1/ phone number example: end-user sees 1 field back-end expects 3 distinct ones (ctr, zone, local) -- imposed granularity == 3 2/ date example end-user sees 3 fields (day, month, year) back-end expects 1 -- imposed granularity == 3 The above also illustrates that the usage of the aggregate-field will only be useful to people actually having the intent to map stuff onto a backend-business model. (but by now we already aggreed(?) that such is not really tied to actually using the declarative data mapping provided by the binding) What do you think? I also like the practical consequences introduced by the aggregate-field notion: - it becomes a template-designer choice to present the date as one field or as separate fields - it allows for (maybe easier) validation rules on the split parts - it made writing the binding-stuff so easy that I could do it :-) (now you see how I do all effort not to overload Bruno ;-)) -marc= (in elaboration mode again, you all must think I get paid by the word) -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [ANN] Apache Cocoon 2.1 Release Candidate
On Wednesday, Jul 30, 2003, at 11:25 Europe/Rome, Carsten Ziegeler wrote: The Apache Cocoon team is proud to announce the new release of Apache Cocoon. Great. Thanks Carsten. Just one little problem below: In an era where services rather than software will be key for economic success, a better and less expensive model for web publishing will be a winner, especially one based on open standards. We must change this reference to web publishing. I'll write something for this today and present it here. -- Stefano.
Re: [RT] New Input for woody
On Thu, 2003-07-31 at 11:57, Carsten Ziegeler wrote: snip/ Thoughts? Just a quick one: you're assuming there actually is a bean. Or to put it in another way: to create a dywel form, you also need to create a bean. Makes me think a lot of Struts' form beans again (i.e. beans created especially for form handling). One of the goals behind Woody was to make it possible to create forms without necessarily writing a bean... -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: [ANN] Apache Cocoon 2.1 Release Candidate
Stefano Mazzocchi wrote: Just one little problem below: In an era where services rather than software will be key for economic success, a better and less expensive model for web publishing will be a winner, especially one based on open standards. We must change this reference to web publishing. I'll write something for this today and present it here. Great! Thanks, we could change the announcement then. Carsten
Re: [RT] Revisiting Woody's form definition
Sylvain Wallez wrote: Marc Portier wrote: Sylvain Wallez wrote: Marc Portier wrote: snip/ I see two solutions for this : - the messy one (IMO) : add some non-visual fields in the form to hold the necessary data, - add a get/setApplicationData() on FormContext so that widgets can use it during form.process() if the form has an associated binding. surely I prefer the second. and guess what my mantra-remark is: it isn't really tied to binding :-) what I mean is that business-specific-validation that requires the ApplicationData present could be driven completely from the flow (without it making use of the declarative data-mapping offered by the current binding) in fact we might consider naming this the ValidationContextBean rather then ApplicationData? Agree. There's a great probability that ValidationData (why should it be a bean?) will often be the same as ApplicationData, but it formally doesn't need to. Moreover, there are certainly many uses cases where ValidationData is required but the form has no binding. yep, +1 on dropping -Bean suffix (everything in Java is a bean if you want it to. I was thinking about validation rules based on jxpath expressions of course ;-)) -0 on leaving -Context in favor of -Data: I agree that most of the time it will be a quite passive object providing information elements where the custom validation-rules can hook into... However I wouldn't mind if this ValidationContext can be called by these custom validation-rules to do some active stuff. This might very well make the design of these custom thingys a bit easier So I'ld like the name to be more neutral regarding its passive/active position, this makes -Context a better candidate then -Data IMHO, but I'm open to suggestions... Mmmh... by active I guess you mean it provides not only data, but also methods ? Then you're right. But this active word must be banned to yep name this object as it should have *no* impact on the system state. It's the same difference that exists between sitemap matchers and actions : method-wise, they look similar, but only actions can have side effects. yep again I find -Context only slightly less passive then -Data but just a touch more neutral in this respect (e.g. ValidationHandler or even ValidationProvider would have been overdoing it) Sylvain regards, -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [ANN] Apache Cocoon 2.1 Release Candidate
On 31/07/2003 13:27 Stefano Mazzocchi wrote: I removed references to the publishing framework and added a CSS stylesheet to both the cocoon directory and lenya's using a headinsidebody hack (dirty, but it works on all the browsers I tried and it downgrades nicely). looking very nice, thanks! /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Cool (work)flow GUI editor
On Wednesday, Jul 30, 2003, at 18:48 Europe/Rome, Nicola Ken Barozzi
wrote:
http://blog.xesoft.com/jon.lipsky/blog/Java/
?permalink=workflow_viewlets.html
did you guys ever programmed java with JavaStudio? it was a nice little
app that sun released in the early java days. it was visual programming
of java code thru LabView style drag-drop-link of javabeans.
It was sooo cool when you saw a demo.
Horrible to work with it.
why? visual programming is bullshit.
It take half an hour to write a visual representation of something like
if (blah) {
dothis();
} else {
dothat();
}
Try.
--
Stefano.
cvs commit: cocoon-site/src/documentation/content/xdocs/news archives.xml
stevenn 2003/07/31 04:36:54 Modified:src/documentation/content/xdocs/news archives.xml Log: fixed old URI Revision ChangesPath 1.4 +2 -2 cocoon-site/src/documentation/content/xdocs/news/archives.xml Index: archives.xml === RCS file: /home/cvs/cocoon-site/src/documentation/content/xdocs/news/archives.xml,v retrieving revision 1.3 retrieving revision 1.4 diff -u -r1.3 -r1.4 --- archives.xml 3 Jul 2003 14:25:03 - 1.3 +++ archives.xml 31 Jul 2003 11:36:54 - 1.4 @@ -21,7 +21,7 @@ /p ul li - link href=http://outerthought.net/wiki/;Cocoon Wiki/link focuses on content development for the Cocoon project. It is designed to facilitate document development and collaboration from all levels of Cocoon users. Documents include FAQs, snippets, how-tos, tutorials, RTs (random thoughts), dreams, surveys, and more. The preliminary focus of this the wiki is to serve as a documentation breeding ground, where docs can grow until mature enough to become official cvs docs. However, it already represents a lively and valid document resource in its own right. + link href=http://wiki.cocoondev.org/;Cocoon Wiki/link focuses on content development for the Cocoon project. It is designed to facilitate document development and collaboration from all levels of Cocoon users. Documents include FAQs, snippets, how-tos, tutorials, RTs (random thoughts), dreams, surveys, and more. The preliminary focus of this the wiki is to serve as a documentation breeding ground, where docs can grow until mature enough to become official cvs docs. However, it already represents a lively and valid document resource in its own right. /li li link href=http://www.anyware-tech.com/wikiland/;Wikiland/link is an ongoing development effort to build a Cocoon-based wiki architecture. Wikiland features a Cocoon dictionary as the pretext to use, test and develop the wiki. The project is seeking Cocoon-oriented developers to further its development. For more information, see the link href=http://rossel.free.fr/; Wikiland home page./link @@ -29,4 +29,4 @@ /ul /section /body -/document \ No newline at end of file +/document
Re: J2EE+native http 1/3 performance of integrated server!
On 31/07/2003 13:28 Nicola Ken Barozzi wrote: On page 15 I read that from the tests, they found out that running a native webserver and a J2EE container on the same machine was *1/3* of the performance of the integrated solution. Does this mean we should all go for Orion, Jetty, or (hm) Tomcat in standalone mode then? /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Dynamic XSL generation with cocoon: : excalibur Source or cocoonSource bug ?
Hi all,
I have some troubles with a dynamic generated xsl. Here is the sitemap
snippet :
map:match select=requests
map:generate src=.../
map:transform src=cocoon:/picto-filter.xsl
map:parameter name=profile
value={session-attr:profile}/
/map:transform
map:serialize type=xml/
/map:match
map:match pattern=picto-filter.xsl
map:generate src=resources/workflow.xconf/
map:transform
src=stylesheets/picto-filter-generator.xsl/
map:serialize type=xml/
/map:match
And I've got the following stack trace (long... but maybe usefull for
info) :
Original Exception:
org.apache.excalibur.xml.xslt.XSLTProcessorException: Exception in
creating Transform Handler
at
org.apache.excalibur.xml.xslt.XSLTProcessorImpl.getTransformerHandlerAndValidity(XSLTProcessorImpl.java:375)
at
org.apache.cocoon.transformation.TraxTransformer.setup(TraxTransformer.java:302)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.setupPipeline(AbstractProcessingPipeline.java:391)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.setupPipeline(AbstractCachingProcessingPipeline.java:671)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.preparePipeline(AbstractProcessingPipeline.java:505)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:467)
at
org.apache.cocoon.components.treeprocessor.sitemap.SerializeNode.invoke(SerializeNode.java:150)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:84)
at
org.apache.cocoon.components.treeprocessor.sitemap.PreparableMatchNode.invoke(PreparableMatchNode.java:164)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelineNode.invoke(PipelineNode.java:162)
at
org.apache.cocoon.components.treeprocessor.AbstractParentProcessingNode.invokeNodes(AbstractParentProcessingNode.java:108)
at
org.apache.cocoon.components.treeprocessor.sitemap.PipelinesNode.invoke(PipelinesNode.java:162)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:325)
at
org.apache.cocoon.components.treeprocessor.TreeProcessor.process(TreeProcessor.java:307)
at org.apache.cocoon.Cocoon.process(Cocoon.java:626)
at
org.apache.cocoon.servlet.CocoonServlet.service(CocoonServlet.java:1154)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:853)
at
org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:360)
at
org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:294)
at
org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:558)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1714)
at
org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:507)
at org.mortbay.http.HttpContext.handle(HttpContext.java:1664)
at org.mortbay.http.HttpServer.service(HttpServer.java:863)
at org.mortbay.http.HttpConnection.service(HttpConnection.java:775)
at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:939)
at org.mortbay.http.HttpConnection.handle(HttpConnection.java:792)
at
org.mortbay.http.SocketListener.handleConnection(SocketListener.java:201)
at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:289)
at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:455)
Caused by: org.apache.cocoon.ProcessingException: Could not read
resource
file:/E:/Dev/IKA/DocHelp/webapp-dochelp/resources/workflow.xconf:
javax.xml.transform.TransformerException: java.util.EmptyStackException
at
org.apache.cocoon.generation.FileGenerator.generate(FileGenerator.java:151)
at
org.apache.cocoon.components.pipeline.impl.AbstractCachingProcessingPipeline.processXMLPipeline(AbstractCachingProcessingPipeline.java:262)
at
org.apache.cocoon.components.pipeline.AbstractProcessingPipeline.process(AbstractProcessingPipeline.java:679)
at
org.apache.cocoon.components.source.impl.SitemapSource.toSAX(SitemapSource.java:415)
at
org.apache.excalibur.xml.xslt.XSLTProcessorImpl.sourceToSAX(XSLTProcessorImpl.java:389)
at
org.apache.excalibur.xml.xslt.XSLTProcessorImpl.getTransformerHandlerAndValidity(XSLTProcessorImpl.java:311)
... 30 more
Caused by: javax.xml.transform.TransformerException:
java.util.EmptyStackException
at
org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:664)
at
org.apache.xalan.xsltc.trax.TransformerImpl.transform(TransformerImpl.java:298)
at
Re: [ANN] Apache Cocoon 2.1 Release Candidate
Steven Noels wrote, On 31/07/2003 13.32: On 31/07/2003 13:27 Stefano Mazzocchi wrote: I removed references to the publishing framework and added a CSS stylesheet to both the cocoon directory and lenya's using a headinsidebody hack (dirty, but it works on all the browsers I tried and it downgrades nicely). looking very nice, thanks! On Firebird 0.6 the links are so sml... -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: problem applying a generator and transformer
Miguel Carvalho wrote:
Hi, im havinf some trouble creating a Generator in XSP and after that
aplying a transformer in XSL, the problem is, that i am not able to parse
the XML returned by the generator with the transformer.
--
Generator code
xsp:page language=java xmlns:xsp=http://apache.org/xsp;
xsp:structure
xsp:includept.laseeb.dae.xmlDbApi.daeXmlDbApi/xsp:include
xsp:includeorg.xmldb.api.base.ResourceIterator/xsp:include
xsp:includeorg.xmldb.api.base.Resource/xsp:include
xsp:includeorg.xmldb.api.base.XMLDBException/xsp:include
/xsp:structure
document
xsp:logic
try
{
Resource res = null;
String resStr = null;
daeXmlDbApi daeApi = new daeXmlDbApi();
ResourceIterator results;
results = daeApi.getArticleSection(1).getIterator();
while (results.hasMoreResources())
{
res = results.nextResource();
contentsxsp:expr
(String)res.getContent()/xsp:expr/contents
}
}
catch(Exception e)
{
}
/xsp:logic
/document
/xsp:page
Here you have document/ as root element.
--
daeAPI is a API created by me to access to an XINDICE database that contains
XML following the current syntax:
article
title/title
text/text
image/image
/article
--
Transformer code
?xml version=1.0 encoding=iso-8859-1?
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
version=1.0
xsl:output indent=no method=html omit-xml-declaration = yes /
xsl:template match=/
xsl:apply-templates /
/xsl:template
xsl:template match=/contents
xsl:for-each select = /article
tituloxsl:value-of disable-output-escaping = yes
select = /title //titulo
imagemxsl:value-of disable-output-escaping = yes
select = /image //imagem
/xsl:for-each
/xsl:template
/xsl:stylesheet
Here you match on contents/ as root element. Try to remove the line
xsl:output/ or at least make it correct: you don't want html as result
of this transformation. Furthermore does the XSP code return XML or a
string of the database content, that should be XML. Fix it there. Don't
use disable-output-escaping.
Joerg
--
and the problem is that what i get in the view source of the browser is
something like,
lt;?xml version=1.0?gt;
lt;article id=1 rating=2 sectionid=1
xmlns:src=http://xml.apache.org/xindice/Query; src:col=/db/daeDocuments
src:key=1gt;
lt;titlegt;Titulo com rating 2lt;/titlegt;
lt;textgt;Textolt;/textgt;
lt;/articlegt;lt;?xml version=1.0?gt;
lt;article id=2 rating=1 sectionid=1
xmlns:src=http://xml.apache.org/xindice/Query; src:col=/db/daeDocuments
src:key=2gt;
lt;titlegt;Titulo do artigo com rating igual a
1lt;/titlegt;
lt;textgt;texto do artigo com rating igual a
1lt;/textgt;
lt;imagegt;img1.jpglt;/imagegt;
lt;/articlegt;lt;?xml version=1.0?gt;
lt;article id=3 rating=2 sectionid=1
xmlns:src=http://xml.apache.org/xindice/Query; src:col=/db/daeDocuments
src:key=3gt;
lt;titlegt;Titulo do artigo com rating igual a
2lt;/titlegt;
lt;textgt;texto do artigo com rating igual a
2lt;/textgt;
lt;imagegt;img1.jpglt;/imagegt;
lt;/articlegt;lt;?xml version=1.0?gt;
lt;article id=4 rating=2 sectionid=1
xmlns:src=http://xml.apache.org/xindice/Query; src:col=/db/daeDocuments
src:key=4gt;
lt;titlegt;Titulo do artigo com rating igual a
2lt;/titlegt;
lt;textgt;texto do artigo com rating igual a
2lt;/textgt;
lt;imagegt;img1.jpglt;/imagegt;
lt;/articlegt;
and i con't parse it in my transformer.
If anyone could give a look at the code and see what i am doing wrong i
would apreciate it :)
Thanks id advance
Miguel Carvalho
Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
On 31/07/2003 13:35 Stefano Mazzocchi wrote:
On Wednesday, Jul 30, 2003, at 18:48 Europe/Rome, Nicola Ken Barozzi
wrote:
http://blog.xesoft.com/jon.lipsky/blog/Java/
?permalink=workflow_viewlets.html
did you guys ever programmed java with JavaStudio? it was a nice little
app that sun released in the early java days. it was visual programming
of java code thru LabView style drag-drop-link of javabeans.
Yep. Sugar candy appealing to lusers like myself. :-)
It was sooo cool when you saw a demo.
Horrible to work with it.
why? visual programming is bullshit.
It take half an hour to write a visual representation of something like
if (blah) {
dothis();
} else {
dothat();
}
Still, I found the demos pretty valuable with the process variables
being explicitely being created in a separate pane. Makes one think more
about what he is doing.
The nice thing of such a GUI is that it enforces people to make use of
the exposed API, and makes hacks around it, reaching for areas where
scripting authors shouldn't come, a bit more difficult.
- 0 -
I just had a discussion in the car with Bruno about where Apples is
heading (basically he bringing me uptodate - thank you Bruno), and my
layman's conclusion is that different schools of development style are
emerging when building webapps with Cocoon.
1) glueing together ready-made available components using XSPs and the
bag of available Actions
2) Actions and custom Avalon-Cocoon components, which tend to overload
the sitemap with programmatic constructions in the long run
3) 'Webcontinuations flow with Javascript', where people depend on the
availability of Javascript wrappers for common libraries (JDBC, OR
frameworks, ...) - with the challenge of coming up with decent JS
libraries to make sure one doesn't have to reach at too many Java stuff
using 'Packages' - the really cool thing is of course the instant
gratification of save/reload/test
4) 'Apples' which shifts the encapsulation of business and service
components back to full-blown Java, with a simple Apple class calling
upon them while exposing flow decisions in a very lighweight manner in
order to call the correct pipelines
5) 'Dywel' which seems to be going after Struts practices with a nice
dash of Avalonization to go with that
3) and 4) being heavily dependent on the JXTransformer approach (which
is a Good Thing IMHO)
How we are going to manage and support these five schools of thought, I
honestly don't know (not even if we need to be worried altogether), but
I envision some some white-bearded guy is already chuckling in his
corner (http://strongbrains.com/images/darwin.jpg)
interlude advise=don't take this too seriously
More stupidity being put forward, I would humbly suggest to explicitely
name the methodologies:
1) 'Barbara', in kind remembrance of B. Post
2) 'Carsten, the Early Years'
3) 'SchemoVidiuChrismatron'
4) 'Species' - since Apples and Pears are way to generic already, and
it's what Darwin was all about
5) 'Rag' - since Dywel really sounds like a mop in Dutch if slightly
misspelled
... in order to be able to ask a Cocoonie: what religion are you in?
Oh, I used to be an early CultofBarbara groupie, but now I tend to
worship the mighty SchemoVidiuChrismatron.
/interlude
Kidding aside, is my categorization more or less correct? Might be cool
to put on a slide once.
/Steven
--
Steven Noelshttp://outerthought.org/
Outerthought - Open Source, Java XML Competence Support Center
Read my weblog athttp://blogs.cocoondev.org/stevenn/
stevenn at outerthought.orgstevenn at apache.org
Re: [ANN] Apache Cocoon 2.1 Release Candidate
Nicola Ken Barozzi wrote: Steven Noels wrote, On 31/07/2003 13.32: On 31/07/2003 13:27 Stefano Mazzocchi wrote: I removed references to the publishing framework and added a CSS stylesheet to both the cocoon directory and lenya's using a headinsidebody hack (dirty, but it works on all the browsers I tried and it downgrades nicely). looking very nice, thanks! On Firebird 0.6 the links are so sml... I can't read it too (ie or esp. mozilla 1.4). At least one Ctrl-+ is required. Mind increasing the font? Vadim
RE: problem applying a generator and transformer
Hi Joerg,
xsp:expr/ will take its content and add it to the output as a string -
that's your problem.
Try one of the xsp-util functions to include you data as XML (I think it's
util:include-expr/, but please check)
/Adrian
-Original Message-
From: Joerg Heinicke [mailto:[EMAIL PROTECTED]
Sent: Thursday 31 July 2003 14:21
To: [EMAIL PROTECTED]
Subject: Re: problem applying a generator and transformer
Miguel Carvalho wrote:
Hi, im havinf some trouble creating a Generator in XSP and
after that
aplying a transformer in XSL, the problem is, that i am not
able to parse
the XML returned by the generator with the transformer.
--
--
--
Generator code
xsp:page language=java xmlns:xsp=http://apache.org/xsp;
xsp:structure
xsp:includept.laseeb.dae.xmlDbApi.daeXmlDbApi/xsp:include
xsp:includeorg.xmldb.api.base.ResourceIterator/xsp:include
xsp:includeorg.xmldb.api.base.Resource/xsp:include
xsp:includeorg.xmldb.api.base.XMLDBException/xsp:include
/xsp:structure
document
xsp:logic
try
{
Resource res = null;
String resStr = null;
daeXmlDbApi daeApi = new daeXmlDbApi();
ResourceIterator results;
results =
daeApi.getArticleSection(1).getIterator();
while (results.hasMoreResources())
{
res = results.nextResource();
contentsxsp:expr
(String)res.getContent()/xsp:expr/contents
}
}
catch(Exception e)
{
}
/xsp:logic
/document
/xsp:page
Here you have document/ as root element.
--
--
--
daeAPI is a API created by me to access to an XINDICE
database that contains
XML following the current syntax:
article
title/title
text/text
image/image
/article
--
--
--
Transformer code
?xml version=1.0 encoding=iso-8859-1?
xsl:stylesheet xmlns:xsl=http://www.w3.org/1999/XSL/Transform;
version=1.0
xsl:output indent=no method=html omit-xml-declaration
= yes /
xsl:template match=/
xsl:apply-templates /
/xsl:template
xsl:template match=/contents
xsl:for-each select = /article
tituloxsl:value-of
disable-output-escaping = yes
select = /title //titulo
imagemxsl:value-of
disable-output-escaping = yes
select = /image //imagem
/xsl:for-each
/xsl:template
/xsl:stylesheet
Here you match on contents/ as root element. Try to remove the line
xsl:output/ or at least make it correct: you don't want
html as result
of this transformation. Furthermore does the XSP code return XML or a
string of the database content, that should be XML. Fix it
there. Don't
use disable-output-escaping.
Joerg
--
--
--
and the problem is that what i get in the view source of
the browser is
something like,
lt;?xml version=1.0?gt;
lt;article id=1 rating=2 sectionid=1
xmlns:src=http://xml.apache.org/xindice/Query;
src:col=/db/daeDocuments
src:key=1gt;
lt;titlegt;Titulo com rating 2lt;/titlegt;
lt;textgt;Textolt;/textgt;
lt;/articlegt;lt;?xml version=1.0?gt;
lt;article id=2 rating=1 sectionid=1
xmlns:src=http://xml.apache.org/xindice/Query;
src:col=/db/daeDocuments
src:key=2gt;
lt;titlegt;Titulo do artigo
com rating igual a 1lt;/titlegt;
lt;textgt;texto do artigo com
rating igual a 1lt;/textgt;
lt;imagegt;img1.jpglt;/imagegt;
lt;/articlegt;lt;?xml version=1.0?gt;
lt;article id=3 rating=2 sectionid=1
xmlns:src=http://xml.apache.org/xindice/Query;
src:col=/db/daeDocuments
src:key=3gt;
lt;titlegt;Titulo do artigo
com rating igual a 2lt;/titlegt;
lt;textgt;texto do artigo com
rating igual a 2lt;/textgt;
lt;imagegt;img1.jpglt;/imagegt;
lt;/articlegt;lt;?xml version=1.0?gt;
lt;article id=4 rating=2 sectionid=1
xmlns:src=http://xml.apache.org/xindice/Query;
src:col=/db/daeDocuments
src:key=4gt;
lt;titlegt;Titulo do artigo
com rating igual a 2lt;/titlegt;
lt;textgt;texto do artigo com
rating igual a 2lt;/textgt;
lt;imagegt;img1.jpglt;/imagegt;
lt;/articlegt;
and i con't parse it in my transformer.
Re: [Half-solved] Dynamic XSL generation with cocoon: : excaliburSource or cocoon Source bug ?
To be more precise, I changed the first transformer from default to xalan Olivier Billard wrote: I changed the default transformer from xsltc to xalan and it works... What's wrong with the xsltc ? That's not the first time I see things working with xalan and not xsltc... -- Olivier
Re: [Half-solved] Dynamic XSL generation with cocoon: : excaliburSource or cocoon Source bug ?
But please cut at least the stack trace when responsing to such a long mail like your original one - again 59 KB. Joerg Olivier Billard wrote: I changed the default transformer from xsltc to xalan and it works... What's wrong with the xsltc ? That's not the first time I see things working with xalan and not xsltc... -- Olivier
Re: [ANN] Apache Cocoon 2.1 Release Candidate
On Thursday, Jul 31, 2003, at 14:05 Europe/Rome, Nicola Ken Barozzi wrote: Steven Noels wrote, On 31/07/2003 13.32: On 31/07/2003 13:27 Stefano Mazzocchi wrote: I removed references to the publishing framework and added a CSS stylesheet to both the cocoon directory and lenya's using a headinsidebody hack (dirty, but it works on all the browsers I tried and it downgrades nicely). looking very nice, thanks! On Firebird 0.6 the links are so sml... yeah, you're right. I've updated it now using px instead of em, (the only way to route around the DPI screen incompatibilities between win and mac) please check if this works for you. -- Stefano.
Re: Cool (work)flow GUI editor
Stefano Mazzocchi wrote: On Wednesday, Jul 30, 2003, at 18:48 Europe/Rome, Nicola Ken Barozzi wrote: http://blog.xesoft.com/jon.lipsky/blog/Java/ ?permalink=workflow_viewlets.html did you guys ever programmed java with JavaStudio? it was a nice little app that sun released in the early java days. it was visual programming of java code thru LabView style drag-drop-link of javabeans. It was a monster :) It was sooo cool when you saw a demo. Horrible to work with it. why? visual programming is bullshit. Not if it supports full round trip, nonvisual - visual - nonvisual. It's much easier to quickly understand what's going on in the workflow by lookng at the picture instead of looking at the workflow markup (and it's much more complex to do roundtrip if your source is javascript). Vadim
Re: [ANN] Apache Cocoon 2.1 Release Candidate
Stefano Mazzocchi wrote, On 31/07/2003 14.27: ... I've updated it now using px instead of em, (the only way to route around the DPI screen incompatibilities between win and mac) please check if this works for you. Works, thanks :-) -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [Half-solved] Dynamic XSL generation with cocoon: : excaliburSource or cocoon Source bug ?
Ok sorry :) ! I just wanted to keep the original mail... Joerg Heinicke wrote: But please cut at least the stack trace when responsing to such a long mail like your original one - again 59 KB. Joerg Olivier Billard wrote: I changed the default transformer from xsltc to xalan and it works... What's wrong with the xsltc ? That's not the first time I see things working with xalan and not xsltc... -- Olivier
Re: [ANN] Apache Cocoon 2.1 Release Candidate
Joerg Heinicke wrote: Vadim Gritsenko wrote: On Firebird 0.6 the links are so sml... I can't read it too (ie or esp. mozilla 1.4). At least one Ctrl-+ is required. Mind increasing the font? Vadim You can configure a minimum font size in Mozilla :-) You do recommend this to all Cocoon users? Seriously? And what to do about all the other web sites where font will become too large? Vadim
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/pipeline/impl BaseCachingProcessingPipeline.java AbstractCachingProcessingPipeline.java
cziegeler2003/07/31 05:39:04
Modified:src/java/org/apache/cocoon/components/pipeline/impl
AbstractCachingProcessingPipeline.java
Added: src/java/org/apache/cocoon/components/pipeline/impl
BaseCachingProcessingPipeline.java
Log:
Create new base class for caching, remove unused method
Revision ChangesPath
1.10 +6 -54
cocoon-2.1/src/java/org/apache/cocoon/components/pipeline/impl/AbstractCachingProcessingPipeline.java
Index: AbstractCachingProcessingPipeline.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/pipeline/impl/AbstractCachingProcessingPipeline.java,v
retrieving revision 1.9
retrieving revision 1.10
diff -u -r1.9 -r1.10
--- AbstractCachingProcessingPipeline.java31 Jul 2003 03:54:22 - 1.9
+++ AbstractCachingProcessingPipeline.java31 Jul 2003 12:39:04 - 1.10
@@ -57,17 +57,11 @@
import java.util.ArrayList;
import java.util.Date;
-import org.apache.avalon.framework.activity.Disposable;
-import org.apache.avalon.framework.component.ComponentException;
-import org.apache.avalon.framework.component.ComponentManager;
import org.apache.avalon.framework.parameters.ParameterException;
import org.apache.avalon.framework.parameters.Parameters;
import org.apache.cocoon.ConnectionResetException;
import org.apache.cocoon.ProcessingException;
import org.apache.cocoon.caching.*;
-import org.apache.cocoon.components.pipeline.AbstractProcessingPipeline;
-import org.apache.cocoon.components.sax.XMLDeserializer;
-import org.apache.cocoon.components.sax.XMLSerializer;
import org.apache.cocoon.environment.Environment;
import org.apache.cocoon.transformation.Transformer;
import org.apache.cocoon.util.HashUtil;
@@ -76,8 +70,8 @@
import org.apache.excalibur.source.impl.validity.DeferredValidity;
/**
- * This is the base class for all caching pipeline implementations.
- *
+ * This is the base class for all caching pipeline implementations
+ * that check the different pipeline components.
*
* @since 2.1
* @author a href=mailto:[EMAIL PROTECTED]Carsten Ziegeler/a
@@ -85,11 +79,7 @@
* @version CVS $Id$
*/
public abstract class AbstractCachingProcessingPipeline
-extends AbstractProcessingPipeline
-implements Disposable {
-
-/** This is the Cache holding cached responses */
-protected Cache cache;
+extends BaseCachingProcessingPipeline {
/** The role name of the generator */
protected String generatorRole;
@@ -103,11 +93,6 @@
/** The role name of the reader */
protected String readerRole;
-/** The deserializer */
-protected XMLDeserializer xmlDeserializer;
-/** The serializer */
-protected XMLSerializer xmlSerializer;
-
/** The cached byte stream */
protected byte[] cachedResponse;
/** The timestamp of the cached byte stream */
@@ -148,30 +133,12 @@
protected abstract void connectCachingPipeline(Environment environment)
throws ProcessingException;
/**
- * Composable Interface
- */
-public void compose (ComponentManager manager)
-throws ComponentException {
-super.compose(manager);
-}
-
-/**
* Parameterizable Interface - Configuration
*/
public void parameterize(Parameters params)
throws ParameterException {
super.parameterize(params);
this.configuredDoSmartCaching =
params.getParameterAsBoolean(smart-caching, true);
-String cacheRole = params.getParameter(cache-role, Cache.ROLE);
-if ( this.getLogger().isDebugEnabled()) {
-this.getLogger().debug(Using cache + cacheRole);
-}
-
-try {
-this.cache = (Cache)this.manager.lookup(cacheRole);
-} catch (ComponentException ce) {
-throw new ParameterException(Unable to lookup cache: + cacheRole,
ce);
-}
}
/**
@@ -970,13 +937,6 @@
* Recyclable Interface
*/
public void recycle() {
-super.recycle();
-
-this.manager.release( this.xmlDeserializer );
-this.xmlDeserializer = null;
-
-this.manager.release( this.xmlSerializer );
-this.xmlSerializer = null;
this.generatorRole = null;
this.transformerRoles.clear();
@@ -989,18 +949,10 @@
this.transformerIsCacheableProcessingComponent = null;
this.toCacheKey = null;
this.toCacheSourceValidities = null;
-}
-/**
- * Disposable Interface
- */
-public void dispose() {
-if ( null != this.manager ) {
-this.manager.release(this.cache);
-}
-
RE: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Steven Noels wrote: interlude advise=don't take this too seriously More stupidity being put forward, I would humbly suggest to explicitely name the methodologies: 1) 'Barbara', in kind remembrance of B. Post 2) 'Carsten, the Early Years' 3) 'SchemoVidiuChrismatron' 4) 'Species' - since Apples and Pears are way to generic already, and it's what Darwin was all about 5) 'Rag' - since Dywel really sounds like a mop in Dutch if slightly misspelled ... in order to be able to ask a Cocoonie: what religion are you in? Oh, I used to be an early CultofBarbara groupie, but now I tend to worship the mighty SchemoVidiuChrismatron. /interlude Kidding aside, is my categorization more or less correct? Might be cool to put on a slide once. More or less :) perhaps it's not correct to but my name together with actions at 2), we all know who checked in the Action interface... Serious: what about a humour page on our web site with nice and funny things like these? Especially I like 'SchemoVidiuChrismatron' ! Carsten
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
On 31/07/2003 14:23 Steven Noels wrote: 1) 'Barbara', in kind remembrance of B. Post 2) 'Carsten, the Early Years' 3) 'SchemoVidiuChrismatron' 4) 'Species' - since Apples and Pears are way to generic already, and it's what Darwin was all about 5) 'Rag' - since Dywel really sounds like a mop in Dutch if slightly misspelled and Bruno reminds me of Schools I forgot about: - the who said I shouldn't use Tomcat filters to manage Hibernate sessions school, just be happy that I don't system.exec() a shell script to do the same - the look at me calculating a CRC checksum of a creditcard number using XPath school of XMLForms I'm signing off for this afternoon, so I'll stop nagging the list with frivolous mails - don't you worry. ;-) /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Re: Cool (work)flow GUI editor
Stefano Mazzocchi dijo:
why? visual programming is bullshit.
It take half an hour to write a visual representation of something like
if (blah) {
dothis();
} else {
dothat();
}
Try.
I totally agree. I can add: MS Visual programming is ...(what yoou said :)
But, there are some nice tools as VisualAge C++ from IBM. It was very easy
and fast because it was OO oriented. I used it in 1995. Also in 1993-94 I
used a CASE system from a company called Westmount that was also very
fast. It was Relational oriented, in the age when OOA and OOD was a weird
thing for most of the people.
Best Regards,
Antonio Gallardo.
Re: Dynamic XSL generation with cocoon: : excalibur Source or cocoonSource bug ?
Olivier Billard wrote: Hi Vadim ! Relatively to recent mails of the thread, you think it could work with xsltc, if some offendering xsl were removed ? Yes. Just added transform to xsl-dynamic-source: xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xsp=http://apache.org/xsp; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xsl:template match=xsl:stylesheet/xsl:template/xsl:if/p Hey there!!! br/ xsl:apply-templates/ /xsl:template xsl:template match=@*|node() priority=-1 xsl:copy xsl:apply-templates select=@*|node()/ /xsl:copy /xsl:template /xsl:stylesheet And it still works ok with default xslt transformer - which is xsltc. When/if you find a bug in xsltc please report it to xalan-dev or bugzilla. Vadim
Re: Dynamic XSL generation with cocoon: : excalibur Source or cocoonSource bug ?
What do you mean about Just added transform to xsl-dynamic-source ? Vadim Gritsenko wrote: Olivier Billard wrote: Hi Vadim ! Relatively to recent mails of the thread, you think it could work with xsltc, if some offendering xsl were removed ? Yes. Just added transform to xsl-dynamic-source: xsl:stylesheet version=1.0 xmlns:xsl=http://www.w3.org/1999/XSL/Transform; xmlns:xsp=http://apache.org/xsp; xmlns:xsp-request=http://apache.org/xsp/request/2.0; xsl:template match=xsl:stylesheet/xsl:template/xsl:if/p Hey there!!! br/ xsl:apply-templates/ /xsl:template xsl:template match=@*|node() priority=-1 xsl:copy xsl:apply-templates select=@*|node()/ /xsl:copy /xsl:template /xsl:stylesheet And it still works ok with default xslt transformer - which is xsltc. When/if you find a bug in xsltc please report it to xalan-dev or bugzilla. Vadim
Releasing 2.1
I just want to collect opinions how to manage the final release. Now, it seems 2.1rc1 is relative stable, no real complains, some minor issues but no showstoppers. From that we could say: the current cvs is the final version. point. I don't think we need a rc2. Should we take before we do the release some actions? Like... ..updating docs ..changing readme ..asking users for testing (which was a success for 2.0.3 and 2.0.4) etc. Whatever we do, I think a timeframe of two weeks is good, so I suggest a final release on tuesday, 12th. Carsten
Re: Dynamic XSL generation with cocoon: : excalibur Source or cocoonSource bug ?
Olivier Billard wrote: What do you mean about Just added transform to xsl-dynamic-source ? Meaning: I've just added a transformation step to the xsl-dynamic-source matcher to more closely reproduce your scenario and samples/sources/sitemap.xmap now reads: !-- Generate XSL source dynamically using XSP page. -- map:match pattern=xsl-dynamic-source map:generate type=serverpages src=style/simple-page2html.xsp/ map:transform src=test.xsl/ map:serialize type=xml/ /map:match And content of test.xsl I sent in previous email and all is working just fine with xsltc. Vadim
Re: Releasing 2.1
Carsten Ziegeler wrote: I just want to collect opinions how to manage the final release. Now, it seems 2.1rc1 is relative stable, no real complains, some minor issues but no showstoppers. I know of two bugs ATM which are kind of bugging me: 1) broken tutorial due to missing support of action sets 2) broken views wrt to resources (see Re: Treeprocessor bug with map:resource and views?) From that we could say: the current cvs is the final version. point. I don't think we need a rc2. True. Should we take before we do the release some actions? Like... ..updating docs How's your portal going? I seen that the doc has lots of place holders. ..changing readme ..asking users for testing (which was a success for 2.0.3 and 2.0.4) .. finish samples refactoring / cleanup .. fix some more bugs from bugzilla etc. Whatever we do, I think a timeframe of two weeks is good, so I suggest a final release on tuesday, 12th. I would opt for 3 weeks but 2 is good enough too. Vadim
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/servlet CocoonServlet.java
vgritsenko2003/07/31 06:29:54
Modified:src/java/org/apache/cocoon/servlet CocoonServlet.java
Log:
Get message from exception
Revision ChangesPath
1.11 +8 -7 cocoon-2.1/src/java/org/apache/cocoon/servlet/CocoonServlet.java
Index: CocoonServlet.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/servlet/CocoonServlet.java,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- CocoonServlet.java31 Jul 2003 03:54:22 - 1.10
+++ CocoonServlet.java31 Jul 2003 13:29:54 - 1.11
@@ -50,6 +50,7 @@
*/
package org.apache.cocoon.servlet;
+import java.io.EOFException;
import java.io.File;
import java.io.FileInputStream;
import java.io.FileOutputStream;
@@ -1113,18 +1114,18 @@
rse);
return;
-} catch ( SocketException se ) {
+} catch (ConnectionResetException cre) {
if (log.isDebugEnabled()) {
-log.debug(The connection was reset, se);
+log.debug(cre.getMessage(), cre);
} else if (log.isWarnEnabled()) {
-log.warn(se.getMessage());
+log.warn(cre.getMessage());
}
-} catch (ConnectionResetException cre) {
+} catch ( SocketException se ) {
if (log.isDebugEnabled()) {
-log.debug(cre.getMessage(), cre);
+log.debug(se.getMessage(), se);
} else if (log.isWarnEnabled()) {
-log.warn(cre.getMessage());
+log.warn(se.getMessage());
}
} catch (Exception e) {
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Steven Noels dijo: interlude advise=don't take this too seriously More stupidity being put forward, I would humbly suggest to explicitely name the methodologies: 1) 'Barbara', in kind remembrance of B. Post 2) 'Carsten, the Early Years' 3) 'SchemoVidiuChrismatron' 4) 'Species' - since Apples and Pears are way to generic already, and it's what Darwin was all about 5) 'Rag' - since Dywel really sounds like a mop in Dutch if slightly misspelled ... in order to be able to ask a Cocoonie: what religion are you in? Oh, I used to be an early CultofBarbara groupie, but now I tend to worship the mighty SchemoVidiuChrismatron. I think many of us started believing in the Cult of Barbara. After all for many of us that never saw a hairy beasts as XSLT and Cocoon. I think this was the easier way to start using Cocoon. Many of us saw this: XSP is easy to learn and Java is well known, I can believe in this cult. We can call this also The beginning, because of us started using Cocoon trying to find better ways of development. :) After ending the 1 application while learning Cocoon and some hard battles with the hairy beasts. The beasts started to be tamed for us. Then we started losing our faith in the cult of Barbara, because we saw how dificult will be mantain the new scripting lang. called XSP. :( At that time many of us started the exodus and at the beginning was the cult of 'Carsten, the Early Years'. Then is the The transformers. :) There was a time (before Flow) that the idea was use transformers and actions for every thing. But this showed also problems related to database intensive applications. I never being part of this. :( But the transformer idea remain as a good legacy for the next generations. /interlude Kidding aside, is my categorization more or less correct? Might be cool to put on a slide once. Seriously, where I can find more about Apples and Dywel? It is being be part of Cocoon? Best Regards, Antonio Gallardo
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Steven Noels wrote: Kidding aside, is my categorization more or less correct? Might be cool to put on a slide once. I can't speak to accuracy but a page in the docs explaining these viewpoints could really help users make sense of docs and demos that seem to point in different directions. The two biggest design differences I notice are the transformer-centric vs. generator-centric. Clearly this is not an either/or choice. But explaining the difference between all these choices in an overview would be really helpful. Geoff
RE: [RT] New Input for woody
Carsten Ziegeler dijo: My approach is targetted at editing business objects (=java objects). It's not used for editing xml data or for processing form values in others ways, like sending emails etc. Hi Carsten: The idea looks great. A business oriented framework! What can we also use to use to send mails under this framework? Sometimes there is a need to send a automatic email notifications of some changes. But of course we can use other approach to do this maybe encapsulated into the business objects. Are you thinking in persistence? How you mean this will be done? I will be glad if we can exchange some ideas between this. I am currenlty spending my time trying to find a new way. The idea of create business objects. Maybe we can create a more generalized interface to do that. I am also facing the raping changes in the Woody arena. But it is OK. I am glad Woody that woody runs too fast! Currently I am starting to try Woody with Beans (or may we can call it ValueObjects)? You can also download the lastest CVS of OJB because there is a very nice presentation that was posted 2 or 3 days ago. I think it is a worth to see it. At the end it show how we can abstract the Data Access Tier. Best Regards, Antonio Gallardo. That's why I still think that it makes sense to follow the dywel approach but I want to use underneath as much as possible from the existing features we already have. Carsten
Re: Releasing 2.1
Vadim Gritsenko wrote: Carsten Ziegeler wrote: I just want to collect opinions how to manage the final release. Now, it seems 2.1rc1 is relative stable, no real complains, some minor issues but no showstoppers. I've seen a heated complaint on users related to a bug in XSLTC (which the notes say is default but is it actually configured that way?) I know of two bugs ATM which are kind of bugging me: 1) broken tutorial due to missing support of action sets I started looking into this and found it's just totally unimplemented. I didn't have time to continue on it. Given that we are trying to discourage actions, maybe the tutorial should get changed? ... Everything else sounds good and important, but I can't promise much personally right now, so I won't say much. Geoff
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUIeditor]
On Thu, 2003-07-31 at 15:30, Antonio Gallardo wrote: snip/ Seriously, where I can find more about Apples and Dywel? It is being be part of Cocoon? Apples is Marc's try at creating an implementation of the generalized flow ideas he's been spreading the last couple of weeks. Basically it is the same as flowscript, but your flows are written in Java and lack continuations. So you have to implement your own logic for figuring out the current state each time you get a request entering your apple. What you do get for free (compared to e.g. using actions) is an interaction-based storage area (namely the instance variables in your apple), which is way better and easier than using the session to store parameters for a certain flow. It also allows you to pass data to the view layer in a flowscript-compatible way, and the integration with the sitemap is nicer. For the actual code see http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21900 -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
RE: [RT] New Input for woody
Antonio Gallardo wrote: The idea looks great. A business oriented framework! What can we also use to use to send mails under this framework? Sometimes there is a need to send a automatic email notifications of some changes. But of course we can use other approach to do this maybe encapsulated into the business objects. You can either use one of the existing other approaches or you can send the mail from within your java code. Are you thinking in persistence? How you mean this will be done? I will be glad if we can exchange some ideas between this. Yes, persistence is the key feature. Now currently you can use whatever you want, hibernate, ojb etc. I don't want to create a layer inbetween and I don't want to force others to use one over the other. I just started to look at those two and currently I like ojb more. I guess I will have to throw my ideas for some improvements into the ojb list and see what happens. Persistence is a separate concern so I don't want to solve this in Cocoon. If you or me or anyone else has specific requirements for persistence than we/you/he should try to get in contact with one of the persistence development teams. I am currenlty spending my time trying to find a new way. The idea of create business objects. Maybe we can create a more generalized interface to do that. I am also facing the raping changes in the Woody arena. But it is OK. I am glad Woody that woody runs too fast! Currently I am starting to try Woody with Beans (or may we can call it ValueObjects)? Ok, I'm interested to see the results. You can also download the lastest CVS of OJB because there is a very nice presentation that was posted 2 or 3 days ago. I think it is a worth to see it. At the end it show how we can abstract the Data Access Tier. I donwloaded the latest rc and it took me some hours yesterday night to get it running. I ported my test app from hibernate to ojb and it wasn't that easy because hibernate has some nice features ojb does not have and vice versa. Carsten
Re: Cool (work)flow GUI editor
On Thursday, Jul 31, 2003, at 14:31 Europe/Rome, Vadim Gritsenko wrote: Stefano Mazzocchi wrote: why? visual programming is bullshit. Not if it supports full round trip, nonvisual - visual - nonvisual. It's much easier to quickly understand what's going on in the workflow by lookng at the picture instead of looking at the workflow markup (and it's much more complex to do roundtrip if your source is javascript). You are right, roundtripping makes a huge difference and you are right again saying that it is much harder to write a script-graphic parser than a graphic-script one, still not impossible. -- Stefano.
DO NOT REPLY [Bug 21925] - [PATCH] FOM Request object does not provide access to all the request's values
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21925 [PATCH] FOM Request object does not provide access to all the request's values [EMAIL PROTECTED] changed: What|Removed |Added Summary|FOM Request object does not |[PATCH] FOM Request object |provide access to all the |does not provide access to |request's values|all the request's values
RE: Releasing 2.1
Vadim Gritsenko wrote: Carsten Ziegeler wrote: I just want to collect opinions how to manage the final release. Now, it seems 2.1rc1 is relative stable, no real complains, some minor issues but no showstoppers. I know of two bugs ATM which are kind of bugging me: 1) broken tutorial due to missing support of action sets 2) broken views wrt to resources (see Re: Treeprocessor bug with map:resource and views?) Ok. How's your portal going? I seen that the doc has lots of place holders. It's going pretty well...it's usable and stable but far from being finished. And it will take some time to complete the docs. ..changing readme ..asking users for testing (which was a success for 2.0.3 and 2.0.4) .. finish samples refactoring / cleanup .. fix some more bugs from bugzilla etc. Whatever we do, I think a timeframe of two weeks is good, so I suggest a final release on tuesday, 12th. I would opt for 3 weeks but 2 is good enough too. 3 weeks wouldn't be a problem, either. Carsten
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Antonio Gallardo wrote: Steven Noels dijo: snip / Kidding aside, is my categorization more or less correct? Might be cool to put on a slide once. Seriously, where I can find more about Apples and Dywel? It is being be part of Cocoon? [Dywel] is Carsten's personal attempt at the form-handling-thing - he announced it first here: http://radio.weblogs.com/0107211/2003/07/10.html#a134 - and is now active in the woody discussions to see which parts of woody could serve his vision - I think he's more or less still in the early stages of design and prototype (just like woody in fact) - his blog somewhat provides a basis for follow up on the status - he is best placed to correct/augment where needed [Apples] is my first throw at building a flow implementation framework that would allow for classic Java/Avalon components to be holding the business logic of your flow aware use cases. - most of the ideas behind it were first expressed here: http://wiki.cocoondev.org/Wiki.jsp?page=GeneralizedFlow - As for the code itself: I wrapped it up as an alpha-cocoon-block which for now can be found here: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21900 - A guide into this initial design and usage is here: http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105913410112209w=2 - feel free to ask questions on any of this as for community impact / adoption / participation: this is to date largely dreamware and tryout stuff ... your comments and participation are welcome I think this kind of research helps out in getting a better understanding, and can generate some sensible refactorings by taking a different view to things if / when / how / why all of this ever gets adopted by the community (and becomes really a 'school') is not to be predicted, we did however have a recent thread that expressed the commitment from all sides to make sure these alternatives are not to become a basis for fragmentation of the group-effort, but rather supporting and goaled at integration and unification HTH, -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog at http://radio.weblogs.com/0116284/ [EMAIL PROTECTED] [EMAIL PROTECTED]
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/caching Cache.java
cziegeler2003/07/31 07:28:19
Modified:src/java/org/apache/cocoon/caching/impl CacheImpl.java
src/java/org/apache/cocoon/caching Cache.java
Log:
Changing type of key to allow more generic caching algorithms
Revision ChangesPath
1.5 +11 -9
cocoon-2.1/src/java/org/apache/cocoon/caching/impl/CacheImpl.java
Index: CacheImpl.java
===
RCS file:
/home/cvs/cocoon-2.1/src/java/org/apache/cocoon/caching/impl/CacheImpl.java,v
retrieving revision 1.4
retrieving revision 1.5
diff -u -r1.4 -r1.5
--- CacheImpl.java13 Jul 2003 03:10:10 - 1.4
+++ CacheImpl.java31 Jul 2003 14:28:18 - 1.5
@@ -50,10 +50,14 @@
*/
package org.apache.cocoon.caching.impl;
+import java.io.IOException;
+import java.io.Serializable;
+import java.util.Map;
+
import org.apache.avalon.framework.activity.Disposable;
-import org.apache.avalon.framework.component.Composable;
import org.apache.avalon.framework.component.ComponentException;
import org.apache.avalon.framework.component.ComponentManager;
+import org.apache.avalon.framework.component.Composable;
import org.apache.avalon.framework.logger.AbstractLogEnabled;
import org.apache.avalon.framework.parameters.ParameterException;
import org.apache.avalon.framework.parameters.Parameterizable;
@@ -62,10 +66,7 @@
import org.apache.cocoon.ProcessingException;
import org.apache.cocoon.caching.Cache;
import org.apache.cocoon.caching.CachedResponse;
-import org.apache.cocoon.caching.PipelineCacheKey;
import org.apache.excalibur.store.Store;
-import java.io.IOException;
-import java.util.Map;
/**
* This is the Cocoon cache. This component is responsible for storing
@@ -112,7 +113,7 @@
* @param responsethe cached response
*/
public void store(Map objectModel,
- PipelineCacheKey key,
+ Serializable key,
CachedResponse response)
throws ProcessingException {
try {
@@ -128,7 +129,7 @@
* @param key the key used by the caching algorithm to identify the
*request
*/
-public CachedResponse get(PipelineCacheKey key) {
+public CachedResponse get(Serializable key) {
return (CachedResponse)this.store.get(key);
}
@@ -138,7 +139,7 @@
* @param key the key used by the caching algorithm to identify the
*request
*/
-public void remove(PipelineCacheKey key) {
+public void remove(Serializable key) {
this.store.remove(key);
}
@@ -146,13 +147,14 @@
* clear cache of all cached responses
*/
public void clear() {
+// FIXME this clears the whole store!
this.store.clear();
}
/**
* See if a response is cached under this key
*/
- public boolean containsKey(PipelineCacheKey key) {
+ public boolean containsKey(Serializable key) {
return this.store.containsKey(key);
}
1.3 +7 -5 cocoon-2.1/src/java/org/apache/cocoon/caching/Cache.java
Index: Cache.java
===
RCS file: /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/caching/Cache.java,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -r1.2 -r1.3
--- Cache.java13 Jul 2003 03:10:10 - 1.2
+++ Cache.java31 Jul 2003 14:28:18 - 1.3
@@ -52,6 +52,8 @@
import org.apache.avalon.framework.component.Component;
import org.apache.cocoon.ProcessingException;
+
+import java.io.Serializable;
import java.util.Map;
/**
@@ -78,7 +80,7 @@
* @param responsethe cached response
*/
void store(Map objectModel,
- PipelineCacheKey key,
+ Serializable key,
CachedResponse response)
throws ProcessingException;
@@ -88,7 +90,7 @@
* @param key the key used by the caching algorithm to identify the
*request
*/
-CachedResponse get(PipelineCacheKey key);
+CachedResponse get(Serializable key);
/**
* Remove a cached response.
@@ -96,7 +98,7 @@
* @param key the key used by the caching algorithm to identify the
*request
*/
-void remove(PipelineCacheKey key);
+void remove(Serializable key);
/**
* clear cache of all cached responses
@@ -106,5 +108,5 @@
/**
* See if a response is cached under this key.
*/
-boolean containsKey(PipelineCacheKey key);
+boolean containsKey(Serializable key);
}
RE: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Marc Portier wrote: [Dywel] is Carsten's personal attempt at the form-handling-thing - he announced it first here: http://radio.weblogs.com/0107211/2003/07/10.html#a134 - and is now active in the woody discussions to see which parts of woody could serve his vision - I think he's more or less still in the early stages of design and prototype (just like woody in fact) - his blog somewhat provides a basis for follow up on the status - he is best placed to correct/augment where needed Thanks Marc! You saved me a little bit of typing! Yes, Dywel is a test do build a framework for building webapps on top of Cocoon. I have some rough concepts and a simple nonfunctional prototyp :) running, and as put above I want to reuse as much as possible. I spent the last nights with looking at the persistence layer, the next thing (perhaps at the weeking) is the state handling. I plan to have something similar like Apples seems to be. So perhaps I can use something from there as well. As soon as I have something more usable I will make it available somewhere put I guess not in the cocoon cvs first. That has to be a community decision. Carsten
Flow's processPipelineTo() and FileSource
I'm having a hell of a time using flow with processPipelineTo() and OutputStreams coming out from FileSource(s). The problem is that FileSource#getOutputStream() creates a temporary file (... to be discussed later ...) and such file gets renamed to the original one only upon OutputStream.close(). Now, AbstractInterpreter, line 201, actually calls flush() but *never* close. As a result, everything is kinda ... well... screwed up. Patch is trivial, but I'm wondering if adding out.close() in AbstractInterpreter.java might break something: any flow experts around? Now for the FileSource: I do understand *some* of the reasoning behind using a temporary file, but I have to disagree on the implementation: naming it [filename].tmp is a bit of a bet, since someone might legitimately have such a filename around. While I understand that there might be memory issues with large files, I guess that either: 1. keeping a ByteArrayOutputStream; 2. forget about it and just write the file; 3. use a more clever name that doesn't risk conflicts this much are all better options. Is that OK to you if I work on it? I don't know if I have access to the Excalibur CVS though... Ciao, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
cvs commit: cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/profile ProfileManager.java
cziegeler2003/07/31 07:37:05 Modified:src/blocks/portal/java/org/apache/cocoon/portal/layout CompositeLayout.java src/blocks/portal/java/org/apache/cocoon/portal/profile ProfileManager.java Log: Fixing javadocs Revision ChangesPath 1.7 +4 -4 cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/layout/CompositeLayout.java Index: CompositeLayout.java === RCS file: /home/cvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/layout/CompositeLayout.java,v retrieving revision 1.6 retrieving revision 1.7 diff -u -r1.6 -r1.7 --- CompositeLayout.java 26 May 2003 13:18:19 - 1.6 +++ CompositeLayout.java 31 Jul 2003 14:37:05 - 1.7 @@ -66,14 +66,14 @@ /** * Add indexed item to the itemList. - * @param index, index for the position inside the list - * @param item, item to add + * @param index index for the position inside the list + * @param item item to add */ void addItem(int index, Item item); /** * Add Item to the ItemList. - * @param item, item to add + * @param item item to add */ void addItem(Item item); 1.8 +2 -2 cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/profile/ProfileManager.java Index: ProfileManager.java === RCS file: /home/cvs/cocoon-2.1/src/blocks/portal/java/org/apache/cocoon/portal/profile/ProfileManager.java,v retrieving revision 1.7 retrieving revision 1.8 diff -u -r1.7 -r1.8 --- ProfileManager.java 18 Jul 2003 14:41:45 - 1.7 +++ ProfileManager.java 31 Jul 2003 14:37:05 - 1.8 @@ -78,7 +78,7 @@ * a specific layout object in the profile defined by * the layout key. * @param layoutKey A key describing the layout or null for the default - * @param subKeyThe id of a layout object or null for the root object + * @param layoutIDThe id of a layout object or null for the root object * @return The layout */ Layout getPortalLayout(String layoutKey, String layoutID);
[OT] Font size, Re: [ANN] Apache Cocoon 2.1 Release Candidate
Joerg Heinicke wrote: Vadim Gritsenko wrote: You can configure a minimum font size in Mozilla :-) You do recommend this to all Cocoon users? Seriously? And what to do about all the other web sites where font will become too large? Vadim No, to all Mozilla users. Because there are many websites having to little fonts. For example www.spiegel.de is a bit strenuous to read in default font size, Looks good to me, btw. I hadn't understand a word, but size is good :) What I can't read is www.distrowatch.com without pressing Ctrl-+ *at least* once (killer feature this ctrl-+!). Sometimes I do it twice ;-) so I set it to 11px. Of course, we should fix this (as Stefano already did), but you can't force all websites to increase their font sizes. Mozilla is gaining market share, btw. Apache.org is a geek site and you can see mozilla share around 10%+ and growing (see stats), but recently in the press they also noticed growing mozilla share. After some time those sites will have to change. Vadim
Re: Cocoon Schools of Development [was: Re: Cool (work)flow GUI editor]
Steven Noels dijo: 5) 'Rag' - since Dywel really sounds like a mop in Dutch if slightly misspelled Hey, Dywel is a full british name:-) From carsten blog: http://www.britannia.com/bios/ebk/dyweldm.html Best Regards, Antonio Gallardo
Woody complex multipaged form
I've send this to [EMAIL PROTECTED] as it contains some ideas about Woody multipage forms * INTRODUCTION * Consider such case: You have a form for inputting report parameters. It goes something like this: Please input all report parameters blah blah: Customer code : _ *pick* Start date : _ *pick* End date : _ *pick* Ordering : __\/_ --- - Submit - --- A little description: 1. Customer code you need a valid customer code here. There are a lot customer codes (for example 10'000). In my xml form description (which is later on rendered to html via a stylesheet) I have introduced specialized input type called picker which renders as a readonly edit box and a button. When *pick* button is pressed: 1. a popup window opens which contains a form with query parameters 2. I can query a customer 3. get a list of first XXX results 4. pick a customer by clicking a table row 5. the above causes to fill-in the edit box with a valid customer code and the popup closes automatically 2. Start and end date I have introduced a JavaScript based calendar ( div shown in an absolute position) so now: 1. I do not need to worry that the date is invalid 2. the form looks really sexy :) * GOAL * I'd like to achieve the same/similar functionality with Woody without too much effort. So first: 1. Can I implement a widget that is not a standard one (a customer/product picker, date picker)? 2. Can I render it my way without rewriting the whole woody stylesheet? (I think not). Big question now: 3. Some users hate popup windows (me too). So I'd like to migrate to flow based approach and after customer picker button is pressed a query page is opened but IN THE SAME WINDOW. After picking a customer the flow goes back to main form. As far as I understand Woody builds it's model basing on request parameters (I do not get the whole binding concept right now so please correct me). How can I store the main form data until flow gets back to it? Let me remind you that the purpose of this whole thing is to write a bunch of reports so I really do not want to write a bean for each report I implement. A nice approach would be : 1. Display a report form and allow user to edit data. 2. When a picker is pressed the whole form is stored (with no bean and stuff - just the whole form) somewhere in the session context under form_name 3. Picker is displayed 4. If picker is submitted - some of picker model data is rewritten to a main model 5. Main report is displayed again. what do you think about all that? LG
Re: Dynamic XSL generation with cocoon: : excalibur Source or cocoonSource bug ?
Hi Sylvain !
How is the back-to-the-work ?
I note this for the future, but I solved this pb with the use of xalan
instead of xslt.
But maybe an error like the one you mentionned could make XSLTC go crazy...
--
Olivier
Sylvain Wallez wrote:
Olivier Billard wrote:
Hi all,
I have some troubles with a dynamic generated xsl. Here is the
sitemap snippet :
map:match select=requests
map:generate src=.../
map:transform src=cocoon:/picto-filter.xsl
map:parameter name=profile
value={session-attr:profile}/
/map:transform
map:serialize type=xml/
/map:match
map:match pattern=picto-filter.xsl
map:generate src=resources/workflow.xconf/
map:transform
src=stylesheets/picto-filter-generator.xsl/
map:serialize type=xml/
/map:match
And I've got the following stack trace (long... but maybe usefull for
info) :
snip/
To isolate the problem, you should also try to use a static snapshot
of the XSL. This will tell if cocoon: is the culprit.
Now I vaguely remember something about this EmptyStackException... do
you have xsl:attribute that comes after a child element of the one
on which the attribute is to be added ? E.g :
foo
bar/
xsl:attribute name=attvalue/xsl:attribute
/foo
If yes, you should move bar/ after xsl:attribute
Sylvain
Woody complex multipaged form
I am really sorry if this is a repost but I have some problems with my smtp server. I've send this to [EMAIL PROTECTED] as it contains some ideas about Woody multipage forms * INTRODUCTION * Consider such case: You have a form for inputting report parameters. It goes something like this: Please input all report parameters blah blah: Customer code : _ *pick* Start date : _ *pick* End date : _ *pick* Ordering : __\/_ --- - Submit - --- A little description: 1. Customer code you need a valid customer code here. There are a lot customer codes (for example 10'000). In my xml form description (which is later on rendered to html via a stylesheet) I have introduced specialized input type called picker which renders as a readonly edit box and a button. When *pick* button is pressed: 1. a popup window opens which contains a form with query parameters 2. I can query a customer 3. get a list of first XXX results 4. pick a customer by clicking a table row 5. the above causes to fill-in the edit box with a valid customer code and the popup closes automatically 2. Start and end date I have introduced a JavaScript based calendar ( div shown in an absolute position) so now: 1. I do not need to worry that the date is invalid 2. the form looks really sexy :) * GOAL * I'd like to achieve the same/similar functionality with Woody without too much effort. So first: 1. Can I implement a widget that is not a standard one (a customer/product picker, date picker)? 2. Can I render it my way without rewriting the whole woody stylesheet? (I think not). Big question now: 3. Some users hate popup windows (me too). So I'd like to migrate to flow based approach and after customer picker button is pressed a query page is opened but IN THE SAME WINDOW. After picking a customer the flow goes back to main form. As far as I understand Woody builds it's model basing on request parameters (I do not get the whole binding concept right now so please correct me). How can I store the main form data until flow gets back to it? Let me remind you that the purpose of this whole thing is to write a bunch of reports so I really do not want to write a bean for each report I implement. A nice approach would be : 1. Display a report form and allow user to edit data. 2. When a picker is pressed the whole form is stored (with no bean and stuff - just the whole form) somewhere in the session context under form_name 3. Picker is displayed 4. If picker is submitted - some of picker model data is rewritten to a main model 5. Main report is displayed again. what do you think about all that? LG
Re: [RT] New Input for woody
Carsten, it took me some time to read and re-read and map: I kinda heard the implied question 'how to map this on woody' so I'll basically try to answer that... Carsten Ziegeler wrote: I think we all know how woody works (apart from me...), so perhaps I could give some details about my idea. I don't want to propose this as an alternative to woody, I just want to give some input. So here we go: The idea is based on a separation between a template and a definition or binding for it. It's a little bit like woody but also different :) Here is a template example: page xmlns:dywel=http://zis.de/cocoon/dywel/0.1; dywel:DWForm id=form dywel:DWTextField id=name/ dywel:DWTextField id=street/ dywel:DWTextField id=city/ dywel:DWSubmit id=submit/ /dywel:DWForm /page Now, I think apart from namespace and element names this looks like a woody template (except form and submit). yep as I understood from earlier discussions this also serves as a form-model-definition (meaning dywel doesn't require an aditional file for that) The difference lies in the second configuration file, that I call binding. It has an entry for each field used in the template: dywel:bindings xmlns:dywel=http://zis.de/cocoon/dywel/0.1; dywel:binding id=form actionnextPage/action /dywel:binding dywel:binding id=submit valueSubmit/value /dywel:binding dywel:binding id=name valueuser.name/value /dywel:binding dywel:binding id=city valueuser.address.city/value /dywel:binding dywel:binding id=street valueuser.address.city/value /dywel:binding /dywel:bindings How does it work? A component (a java implementation) parses the template and the binding file, the first time it's used. The template is compiled and the bindings are attached to the internal tree representing the template. could you elaborate on 'attached' is an instance of the business object involved in this process? this sounds like what woody does with the form-definition file: build up an internal tree that represents the form and knows about the rich datatypes of the back-end A special generator uses the java component and asks it to render the page. Now the tree is processed. Each field knows how to render itself. To get the values for a form field, the field asks the component for the value for e.g. user.name. The component now has a getUser() method and the returned user object has a getName() method. this sounds like the business object instance values are only read at this time... souds like woody's Binding.loadFormFromModel() When the form is submitted, the same tree is processed and the fields set the values using the component, so getUser().setName() is used etc. It's also possible to test via getUser().validateName() etc. the idea in Woody is that the commit only reaches up to the form-model, copying over to the business-model is a different decision (controlled by flow typically, and possibly via the assistance of the declarative data-mapping of the 'binding') (the same 'binding' word depicts a different concept in the woody vs dywel namespaces, vaguely related, but different IMO) For each form or better web page, you have to write the java component = controller. You simply inherit from a base class and provided methods to get your business objects. (I'm looking to simplify this using fom when everything else is set). So, this solution is tied to java objects (currently). well, it is tied to a custom-to-be-written java object from a distance it looks like you'll need some luck for hooking up some existing java objects from a long-before-dywel designed business application (e.g. the validation method, but also the type of the argument in the setXXX methods, the web is presenting you with Strings, how is the conversion done? -- this is the crux of my current understanding of dywel) if that is the case then one is going to need to write a specific javabean to accomodate for the intermediate step before actually talking to the legacy backend system woody's proposition is to use not Java code but the form-definition file to describe this intermediate model... AFAIU both approaches use this kind of intermediate stage as a basis for validation and string-type conversion (remembering Bruno's recent rumblings on jxpath addressing inside form-widgets the line could get very thin) Now, it is possible to specify additional validation and formatting in the binding, like: dywel:binding id=street valueuser.address.city/value validationa rule/validation formattera formatter/formatter /dywel:binding etc. similar I'm still looking for the reverse of the formatter (string to type?) This works pretty well (for me). Now I think this approach has two advantages. The people writing the template do not have to know anything about the binding, they simply create the page and insert a username field (same applies to woody). But the same mechanism is also used to insert values into the
Re: [RT] New Input for woody
On Thu, 2003-07-31 at 17:25, Marc Portier wrote: snip/ As I see it now, the integration is not trivial (but possible) Your bean seems to provide an alternative to the declarative woody-widget tree (form-model) We could argue about the woody-widget tree being the real CORE of woody, so the 'not trivial' gets to have some meaning I guess :-) 'Integration' then becomes making the form-model pluggable which would come down to 1/ making the woody-template-transformer can pull out the values using jxpath rather then using the widget API 2/ and the other way around the form.process(request) needs to evolve to Dywel.process(bean-or-widgetTree, request); which could again use some jxpath-like approach to perform its setValues... not trivial, maybe possible, useful? _very_ quick skim-read, but: didn't you just reinvent XMLForm? -- Bruno Dumon http://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: Flow's processPipelineTo() and FileSource
Gianugo Rabellino wrote:
I'm having a hell of a time using flow with processPipelineTo() and
OutputStreams coming out from FileSource(s).
The problem is that FileSource#getOutputStream() creates a temporary
file (... to be discussed later ...) and such file gets renamed to the
original one only upon OutputStream.close(). Now, AbstractInterpreter,
line 201, actually calls flush() but *never* close. As a result,
everything is kinda ... well... screwed up.
Patch is trivial, but I'm wondering if adding out.close() in
AbstractInterpreter.java might break something: any flow experts around?
I don't see why there should be some consequences on the flow itself...
Just replace flush() by close() !
Now for the FileSource: I do understand *some* of the reasoning behind
using a temporary file, but I have to disagree on the implementation:
naming it [filename].tmp is a bit of a bet, since someone might
legitimately have such a filename around. While I understand that
there might be memory issues with large files, I guess that either:
1. keeping a ByteArrayOutputStream;
2. forget about it and just write the file;
3. use a more clever name that doesn't risk conflicts this much
I would avoid 2. The reason why I used a temporary file is because of
the streamed nature of Cocoon pipelines. If an error occurs within the
processing, the original content is not partially overwritten. My
preference would go to 3.
are all better options.
Is that OK to you if I work on it? I don't know if I have access to
the Excalibur CVS though...
As a Cocoon committer, you should.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
cvs commit: cocoon-2.1/src/java/org/apache/cocoon/components/flow AbstractInterpreter.java
gianugo 2003/07/31 08:43:49 Modified:src/java/org/apache/cocoon/components/flow AbstractInterpreter.java Log: Close the outputstream after processing is over. Revision ChangesPath 1.5 +2 -1 cocoon-2.1/src/java/org/apache/cocoon/components/flow/AbstractInterpreter.java Index: AbstractInterpreter.java === RCS file: /home/cvs/cocoon-2.1/src/java/org/apache/cocoon/components/flow/AbstractInterpreter.java,v retrieving revision 1.4 retrieving revision 1.5 diff -u -r1.4 -r1.5 --- AbstractInterpreter.java 18 May 2003 16:36:40 - 1.4 +++ AbstractInterpreter.java 31 Jul 2003 15:43:49 - 1.5 @@ -199,6 +199,7 @@ result = processor.process(wrapper); wrapper.commitResponse(); out.flush(); +out.close(); // Return whatever the processor returned us return(result);
Re: Releasing 2.1
Carsten Ziegeler wrote: I just want to collect opinions how to manage the final release. Now, it seems 2.1rc1 is relative stable, no real complains, some minor issues but no showstoppers. From that we could say: the current cvs is the final version. point. I don't think we need a rc2. Should we take before we do the release some actions? Like... ..updating docs ..changing readme ..asking users for testing (which was a success for 2.0.3 and 2.0.4) etc. Whatever we do, I think a timeframe of two weeks is good, so I suggest a final release on tuesday, 12th. Carsten Claiming the user's point of view I say we must definitely fix more bugs. The last time such a call was made we lowered the count to 100 from 130 IIRC. If we now fix/reject/... again 30 bugs I'm satisfied ;-) I know all the work on this is voluntary, but we can't ignore the users. Some issues: 1. POI: No real problem, but what about the code move to the POI project? They seem to prepare the 2.0 release, so I guess they only have no time at the moment ... 2. XSLTC: Geoff already mentioned it. I know of two heavy bugs in our 2.5.1 XSLTC: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20308 : stylesheet includes, seems to be already fixed in XSLTC CVS. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20381 : top-level variable with document(). This bug is so annoying because the stylesheet works in a way, but the cause of the failure is not obvious. And we don't know the reason for it until now: XSLTC command line works, Xalan works. But if we switch from Xalan to XSLTC in Cocoon the stylesheet stops working. The simplest fix would be to make Xalan the default again, but I don't like this. Has anybody the time and enthusiasm to find out the reason for the bug? 3. Caching: There still exist some bugs related to caching: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=14348 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=16958 and maybe also http://nagoya.apache.org/bugzilla/show_bug.cgi?id=17924 http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21213 Independent on this we should add more Components for Cocoon on Bugzilla. Core, General Components and Sitemap Components is not really helpful I guess. Joerg
Re: Flow's processPipelineTo() and FileSource
Sylvain Wallez wrote: I'm having a hell of a time using flow with processPipelineTo() and OutputStreams coming out from FileSource(s). The problem is that FileSource#getOutputStream() creates a temporary file (... to be discussed later ...) and such file gets renamed to the original one only upon OutputStream.close(). Now, AbstractInterpreter, line 201, actually calls flush() but *never* close. As a result, everything is kinda ... well... screwed up. Patch is trivial, but I'm wondering if adding out.close() in AbstractInterpreter.java might break something: any flow experts around? I don't see why there should be some consequences on the flow itself... Just replace flush() by close() ! Just did it, but I didn't replace flush(), just added close() afterwards: it's better to be sure that there are no leftovers... Now for the FileSource: I do understand *some* of the reasoning behind using a temporary file, but I have to disagree on the implementation: naming it [filename].tmp is a bit of a bet, since someone might legitimately have such a filename around. While I understand that there might be memory issues with large files, I guess that either: 1. keeping a ByteArrayOutputStream; 2. forget about it and just write the file; 3. use a more clever name that doesn't risk conflicts this much I would avoid 2. The reason why I used a temporary file is because of the streamed nature of Cocoon pipelines. If an error occurs within the processing, the original content is not partially overwritten. My preference would go to 3. I see and understand. Yet temporary files, besides being somehow inconvenient, can be a major security hole in general. I'd rather go for 1, then, accumulating bytes as they come on a ByteArrayOutputStream and writing them upon close() (and maybe flush() too?). True, this is in turn a possible security hole since someone might DOS the machine by processing gigabyte-sized files, but all in all I tend to think that it's a better solution... and yes, doing transaction on a filesystem is a PITA. :-) Ciao, are all better options. Is that OK to you if I work on it? I don't know if I have access to the Excalibur CVS though... As a Cocoon committer, you should. I understand that I am authorized in line of principle, just don't know if I need to be explicitely enabled. Anyway, I'll check it out. :-) Thanks for everything, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: [RT] Revisiting Woody's form definition
Hunsberger, Peter wrote:
Marc Portier [EMAIL PROTECTED] writes:
Andreas Hochsteger wrote:
Hi!
A short question comes to my mind, while reading your RT:
Is it possible to use data types which are composed of several HTML
input fields?
We are currently using three input fields for dates (day,
month, year)
at our current form solution.
No, not currently...
I had a proposing shot at this some weeks ago, see some remarks
hidden in this posting:
http://marc.theaimsgroup.com/?l=xml-cocoon-devm=105712568410208w=2
in short: I think the existing aggregate-widget could be adapted
to support this
This is an extremely important issue in a generalized form building
system. It's more than just splitting and combining a field, you really
want to completely decouple the rendering from the form model as much as
you can. If course that's one of the things that XSLT is all about
which takes one full circle into templating languages: at some point
isn't it just easier to find a way to plug in custom XSLT transforms for
rendering? Maybe not full scale XSLT, but perhaps rather something
along the lines of what Schematron does (element rule matching) only for
rendering. If the element has a rendering rule (a full scale XSLT
template inside of some XML object) you apply it to create the output
representation, otherwise you get the default rendering. Similarly, if
the element has a collection(?) rule (what's the opposite of rendering?)
you run it as a XSLT template. Not sure if that would work for you
guys, but it's likely where we're headed...
That's exactly what I did for an XMLForm-based prototype : a few
UIType attributes on XMLForm's widgets drive the layout :
- UIType=calendar on a xf:textbox changes the input to a input+popup
calendar
- UIType=table on a xf:repeat changes the group's layout to a table
(each set of children becomes a table row) while the default behaviour
is to layout each set of children as an html fieldset
This allows the template (going back to Woody terms) to completely
abstract the rendering details of the layout, and concentrate only on
the description of this layout.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Orixo, the opensource XML business alliance - http://www.orixo.com
RE: Cool (work)flow GUI editor
[Vadim Gritsenko] [Stefano Mazzocchi] It was sooo cool when you saw a demo. Horrible to work with it. why? visual programming is bullshit. Not if it supports full round trip, nonvisual - visual - nonvisual. Visual programming is very old, i.e., 1960's. (http://radio.weblogs.com/0119894/2003/04/23.html for pointers to some resources and blog entries) There is a level of detail and interactivity which is appropriate for different sizes of represented objects: High detail (e.g., expressions/lines of Java code) -- Representation only with all interaction done with the underlying code. Lower detail (e.g., web pages, business objects, web services calls) -- Visual manipulation via model without access to underlying code, property panels for configuration, drill-down to code or expressions Low detail (e.g., web applications, physical servers) -- Representation only with real-time updates and some interactivity (e.g., monitoring/management) For a platform like Cocoon, a visual representation with linkage or drill-down to locations in configuration files or source code would be the way to go. The representation would have to be regenerated with changes, but it would provide a visual overview. (This could probably even be done with SVG...) $0.02, -- PB
Re: Releasing 2.1
On Thursday, Jul 31, 2003, at 15:20 Europe/Rome, Carsten Ziegeler wrote: I just want to collect opinions how to manage the final release. Now, it seems 2.1rc1 is relative stable, no real complains, some minor issues but no showstoppers. From that we could say: the current cvs is the final version. point. I don't think we need a rc2. Should we take before we do the release some actions? Like... ..updating docs ..changing readme ..asking users for testing (which was a success for 2.0.3 and 2.0.4) etc. Whatever we do, I think a timeframe of two weeks is good, so I suggest a final release on tuesday, 12th. I like the plan. Just one thing: what about moving the wiki on cocoon.apache.org/wiki/ before release? Steven? -- Stefano.
Update excalibur datasource ??
I run into problems with current excalibur datasource (1.1.1) that is shipping with cocoon. look at: http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/datasource/src/java/org/a pache/avalon/excalibur/datasource/AbstractJdbcConnection.java for brief description. The comment under revision 1.30 describes the bug and the fix. i know you like release version's as library's, but i think this is an important point for upgrading to the developer version. frank
Re: Woody complex multipaged form
Hi: Your idea is very important. And I think currently Woody does not have something like that. I think the picker is in database applications terminology is called browser. It would be cool to integrate this idea. Best Regards, Antonio Gallardo. Leszek Gawron dijo: I am really sorry if this is a repost but I have some problems with my smtp server. I've send this to [EMAIL PROTECTED] as it contains some ideas about Woody multipage forms * INTRODUCTION * Consider such case: You have a form for inputting report parameters. It goes something like this: Please input all report parameters blah blah: Customer code : _ *pick* Start date : _ *pick* End date : _ *pick* Ordering : __\/_ --- - Submit - --- A little description: 1. Customer code you need a valid customer code here. There are a lot customer codes (for example 10'000). In my xml form description (which is later on rendered to html via a stylesheet) I have introduced specialized input type called picker which renders as a readonly edit box and a button. When *pick* button is pressed: 1. a popup window opens which contains a form with query parameters 2. I can query a customer 3. get a list of first XXX results 4. pick a customer by clicking a table row 5. the above causes to fill-in the edit box with a valid customer code and the popup closes automatically 2. Start and end date I have introduced a JavaScript based calendar ( div shown in an absolute position) so now: 1. I do not need to worry that the date is invalid 2. the form looks really sexy :) * GOAL * I'd like to achieve the same/similar functionality with Woody without too much effort. So first: 1. Can I implement a widget that is not a standard one (a customer/product picker, date picker)? 2. Can I render it my way without rewriting the whole woody stylesheet? (I think not). Big question now: 3. Some users hate popup windows (me too). So I'd like to migrate to flow based approach and after customer picker button is pressed a query page is opened but IN THE SAME WINDOW. After picking a customer the flow goes back to main form. As far as I understand Woody builds it's model basing on request parameters (I do not get the whole binding concept right now so please correct me). How can I store the main form data until flow gets back to it? Let me remind you that the purpose of this whole thing is to write a bunch of reports so I really do not want to write a bean for each report I implement. A nice approach would be : 1. Display a report form and allow user to edit data. 2. When a picker is pressed the whole form is stored (with no bean and stuff - just the whole form) somewhere in the session context under form_name 3. Picker is displayed 4. If picker is submitted - some of picker model data is rewritten to a main model 5. Main report is displayed again. what do you think about all that? LG
WebDAV maturity (was Re: [VOTE] Commit access for Guido Casper)
Stephan Michels wrote: I should mention that Stefan Michels provided an early draft in - I think it Stephan was more than 1,5 years ago but unfortunately (IMO) decided to focus on the SlideSource. Hmm, yes, perhaps a bad idea ;-) I got too few response on that. My experience with WebDAV taught me that all these things doesn't really work in real life. Perhaps, you proof me wrong :) Hope so :) I share the experience that WebDAV maturity progresses slowly (and steadily). But interoperability will be the reward. And this alone is it worth it (IMO). Guido
RE: Woody complex multipaged form
Leszek Gawron [EMAIL PROTECTED] observes: On Thu, Jul 31, 2003 at 10:33:24AM -0600, Antonio Gallardo wrote: Hi: Your idea is very important. And I think currently Woody does not have something like that. I think the picker is in database applications terminology is called browser. It would be cool to integrate this idea. It would be the best if more than one woody form instance could be present in the session at the same time. This way you can separate the picker/browser implementation from the form main itself so it can be reused (for example in reports you reuse customer/product/representative picker a lot) LG If you don't mind a restriction (don't know how big?) on what browsers you can use the easiest way to do this is with iframe. Each iframe becomes a separate request back to Cocoon (and can have it's own model). You can use this to implement popup widgets that don't require a separate window if you're willing to use JavaScript. For compatibility you can then fall back to new windows for browsers that don't support iframe. But for any of this to work I think you need JavaScript? We also use iframes to support types of composition of widgets, in particular, forms within forms...
Re: Flow's processPipelineTo() and FileSource
Why can't you just call close() in your flowscript? I don't see anything in the contract of processPipelineTo() that indicates that it should close the stream. In my opinion, calling flush() but not close() as in the original implementation is correct. My $0.02, Chris Sylvain Wallez wrote: Gianugo Rabellino wrote: I'm having a hell of a time using flow with processPipelineTo() and OutputStreams coming out from FileSource(s). The problem is that FileSource#getOutputStream() creates a temporary file (... to be discussed later ...) and such file gets renamed to the original one only upon OutputStream.close(). Now, AbstractInterpreter, line 201, actually calls flush() but *never* close. As a result, everything is kinda ... well... screwed up. Patch is trivial, but I'm wondering if adding out.close() in AbstractInterpreter.java might break something: any flow experts around? I don't see why there should be some consequences on the flow itself... Just replace flush() by close() ! Now for the FileSource: I do understand *some* of the reasoning behind using a temporary file, but I have to disagree on the implementation: naming it [filename].tmp is a bit of a bet, since someone might legitimately have such a filename around. While I understand that there might be memory issues with large files, I guess that either: 1. keeping a ByteArrayOutputStream; 2. forget about it and just write the file; 3. use a more clever name that doesn't risk conflicts this much I would avoid 2. The reason why I used a temporary file is because of the streamed nature of Cocoon pipelines. If an error occurs within the processing, the original content is not partially overwritten. My preference would go to 3. are all better options. Is that OK to you if I work on it? I don't know if I have access to the Excalibur CVS though... As a Cocoon committer, you should. Sylvain
Re: Update excalibur datasource ??
Frank Taffelt wrote: I run into problems with current excalibur datasource (1.1.1) that is shipping with cocoon. look at: http://cvs.apache.org/viewcvs.cgi/avalon-excalibur/datasource/src/java/org/a pache/avalon/excalibur/datasource/AbstractJdbcConnection.java for brief description. The comment under revision 1.30 describes the bug and the fix. i know you like release version's as library's, but i think this is an important point for upgrading to the developer version. frank Since we coordinate with Excalibur, can't we just ask if it is ready for a bugfix release? Berin? Peter Royal? Geoff
Re: Releasing 2.1
Am Donnerstag, 31. Juli 2003 17.46 schrieb Joerg Heinicke: Some issues: 1. POI: No real problem, but what about the code move to the POI project? They seem to prepare the 2.0 release, so I guess they only have no time at the moment ... 2. XSLTC: Geoff already mentioned it. I know of two heavy bugs in our 2.5.1 XSLTC: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20308 : stylesheet includes, seems to be already fixed in XSLTC CVS. http://nagoya.apache.org/bugzilla/show_bug.cgi?id=20381 : top-level variable with document(). This bug is so annoying because the stylesheet works in a way, but the cause of the failure is not obvious. And we don't know the reason for it until now: XSLTC command line works, Xalan works. But if we switch from Xalan to XSLTC in Cocoon the stylesheet stops working. There's another XSLTC Bug that affects Cocoon. If you use a cocoon:/ URL in XSLTs document() function, the URI is prepended by the stylesheets path. That was a realy annoying bug that took me quite some time. The only fix for this bug is to switch back to Xalan: http://nagoya.apache.org/bugzilla/show_bug.cgi?id=21857 Simon
Re: Flow's processPipelineTo() and FileSource
Christopher Oliver wrote: Why can't you just call close() in your flowscript? I don't see anything in the contract of processPipelineTo() that indicates that it should close the stream. In my opinion, calling flush() but not close() as in the original implementation is correct. On second thought, yes, you're right. The OutputStream might be reused later, and if you call close() in the flow you miss that opportunity. I'm reverting the patch right now: next on the list is finding out why close() in flowscript was giving me problems, while putting it there solved everything. Probably something wrong in FileSource. Thanks, -- Gianugo Rabellino Pro-netics s.r.l. - http://www.pro-netics.com Orixo, the XML business alliance - http://www.orixo.com (Now blogging at: http://blogs.cocoondev.org/gianugo/)
Re: Update excalibur datasource ??
On Thursday, July 31, 2003, at 01:18 PM, Geoff Howard wrote: Since we coordinate with Excalibur, can't we just ask if it is ready for a bugfix release? Berin? Peter Royal? thread started on [EMAIL PROTECTED] to get you a release :) -pete
Re: GUMP good news/bad news
On Thursday, July 31, 2003, at 02:07 PM, Berin Loritsch wrote: Resource: http://gump.covalent.net/log/index.html (Note that this is the only GUMP server with today's results so far) Good news: The Excalibur XMLUtils and Store are no longer breaking Cocoon's GUMP run. Bad news: Jing and Jaxen are. The reason for Jaxen has to do with an incompatibility with Dom4J CVS. Actually its a circular dependency, and the Jaxen team is (slowly) working to get it resolved. -pete
Re: Update excalibur datasource ??
Peter Royal wrote: On Thursday, July 31, 2003, at 01:18 PM, Geoff Howard wrote: Since we coordinate with Excalibur, can't we just ask if it is ready for a bugfix release? Berin? Peter Royal? thread started on [EMAIL PROTECTED] to get you a release :) -pete Thanks! I monitor over there (not fun lately by the way) so I may chime in if needed. Geoff
service manager Q
I'm getting my GenericTaskManager stuff running under 2.1rc1 and ran across a snag. I thought 2.1 was switching over to the whole Serviceable interface. So, I make this action I wrote implement Serviceable and ask the ServiceManager for a component that is defined in the cocoon.xconf file (the GenericTaskManager) and I get some class back called $Proxy2! So, that is an inner class with no package! I look around the code and it looks like the ExcaliburComponentManger is still being used which deals just with Components. Should I even try asking the ServiceManager for components defined in the cocoon.xconf file? David
AW: service manager Q
hi david, AFAIK there should be no problem with getting components from a ServiceManager. behind the scenes an ExcaliburComponentManager is wrapped by a WrapperServicerManager which delegates to the ECM and creates those proxies you mentioned. one point regarding ServiceSelector's: since proxies are being used you have to make sure that you have the respective service interfaces defined. otherwise you'll get ClassNotFoundException's. apart from that you shouldn't have any problems. -Ursprungliche Nachricht- Von: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Auftrag von David Kavanagh Gesendet: Donnerstag, 31. Juli 2003 22:18 An: [EMAIL PROTECTED] Betreff: service manager Q I'm getting my GenericTaskManager stuff running under 2.1rc1 and ran across a snag. I thought 2.1 was switching over to the whole Serviceable interface. So, I make this action I wrote implement Serviceable and ask the ServiceManager for a component that is defined in the cocoon.xconf file (the GenericTaskManager) and I get some class back called $Proxy2! So, that is an inner class with no package! I look around the code and it looks like the ExcaliburComponentManger is still being used which deals just with Components. Should I even try asking the ServiceManager for components defined in the cocoon.xconf file? David
Moving Cocoon wiki to proper ASF equipment [was: Re: Releasing 2.1]
On 31/07/2003 18:13 Stefano Mazzocchi wrote: Just one thing: what about moving the wiki on cocoon.apache.org/wiki/ before release? I was actually thinking of asking infrastructure@ to migrate the Wiki to the new beefy minotaur. As a transition, we could check whether mod_proxy/proxy_pass would be possible, possibly with mod_cache - people knowledgeable in this would be helpful. But from what I read on the infrastructure@ list, it appears nagoya might still be the place to go for heavy use Java apps, yet I understand Pier hasn't got time yet to upgrade/reconfigure nagoya. Infrastructure peeps: this is about the JSPWiki-based Cocoon wiki running on wiki.cocoondev.org. Having run regularly upgraded this beasty for considerable time, I can attest it's a neat Wiki implementation and runs quite well. I'd be happy to further help maintaining it anywhere it is hosted. Your comments are very much welcomed. /Steven -- Steven Noelshttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/stevenn/ stevenn at outerthought.orgstevenn at apache.org
Garbage or The Quest for the Perfect Template Language
These days I'm banging my head against the limitations of template
languages. I've tried XSP and it's not in any way limited, but it has
its share of problems (difficult to debug and offers too many ways to
shoot oneself in the foot), JXTemplate{Transformer,Generator} (no way to
call methods on context objects, no decent arithmetic) and Velocity
(stream based, no FP math).
I've read about Garbage but I haven't tried it. It looks promising
though, and I hope that Pier is going to really push it forward when he
finds some free time.
There are a couple of things that a good template language should do.
Consider the following requirement: given a model consisting of a list
of floating point numbers, print all of them, localizing their
represantion according to some locale, then compute and display their sum.
You can format the numbers using Velocity, but you must explicitly pass
an instance of DecimalFormat to the view. I'd like the template language
to have built-in support for the localization of numbers, currencies and
dates.
You cannot apparently sum the numbers using Velocity. I was startled to
discover, the other day, that if you try to sum doubles with Velocity,
it will instead concatenate their string representations! I hope it was
a mistake of mine, because it would really be dumb if it were indeed the
case. Anyway, whatever the language we come up with, it should be able
to correctly perform floating point arithmetic.
This is my plea for the perfect template language and I hope that,
whoever implements it, considers adding these features.
Ugo
Re: Garbage or The Quest for the Perfect Template Language
Ugo Cei wrote:
These days I'm banging my head against the limitations of template
languages. I've tried XSP and it's not in any way limited, but it has
its share of problems (difficult to debug and offers too many ways to
shoot oneself in the foot), JXTemplate{Transformer,Generator} (no way to
call methods on context objects, no decent arithmetic)
What exactly is the problem with the arithmetic in Jexl and/or JXPath?
What problem did you encounter calling methods? You should be able to
with do that with both Jexl and JXPath.
Regards,
Chris
J2EE+native http 1/3 performance of integrated server!
I read this http://www.middleware-company.com/casestudy/tmc-performance-study-jul-2003.pdf On page 15 I read that from the tests, they found out that running a native webserver and a J2EE container on the same machine was *1/3* of the performance of the integrated solution. Then, on page 51, it talks about how they think performance can be increased, and talk about SEDA, that Avalon is slowly embracing. Maybe Avalon should push more on it, dunno. -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
