Re: [Proposal] New Block building system
Stefano Mazzocchi wrote: Reinhard Poetz wrote: More information and explanations can be found at http://wiki.apache.org/cocoon/CocoonBlockBuilder [not critizing, just curious] can you explain why you think that having block/lib is going to be jar hell while lib/block is not? I would really like to see block/lib instead of lib/block but without Pier's shielding classloader I don't see how we do NOT end in jar versioning hell. Following situation: Block A uses betwixt-0.5.jar, block B uses betwixt-0.6.jar and you want to run both blocks in the same web application. Without shielding it's not possible to use libraries separatly. My temporary solution is using a library repository that only contains one betwixt jar: jars file id=betwixt titleJakarte Commons Betwixt/title description ... /description used-byCocoon/used-by libblocks/betwixt-0.6/lib /jars The descriptor of block A looks like this: block id=http://bla/blockA; nameblock A/name libraries lib id=betwixt location=core/ /libraries /block for block B block id=http://bla/blockB; nameblock B/name libraries lib id=betwixt location=core/ /libraries /block This way only one betwixt version can be used and if e.g. block B uses the outdated version 0.5 it wouldn't compile any more. I know far from being perfect, but maybe you or others have ideas how we can solve this problem in a better way. -- Reinhard
Re: [VOTE] Leszek Gawron and Ralph Goers as committers
Folks please cast your votes for: [ ] Leszek [ ] Ralph as Apache Cocoon committers. +1 for both, welcome Ralph and Leszek! -marc= -- Marc Portierhttp://outerthought.org/ Outerthought - Open Source, Java XML Competence Support Center Read my weblog athttp://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
Re: [RT] StringTemplate: The answer to our templating needs?
Tony Collen wrote: Do we need a new, (standardized?) or possibly even *gasp* better templating system for Cocoon? This is where I encourage people to dive in and give their own [RT]s and thoughts on the issue. First, thank you for the pointer. Interesting stuff. But first, we should agree on our needs and then we should choose a technology. IMO less is more - the templating engine should really focus on presenting data. I see following needs: - really powerful query language to access * all kind of objects * incl. passed DOM trees - control structures like for/each, if, choose - call methods on passed objects - stream objects (DOM, XMLizable, ...?) - and probably a way to define macros (see cForm macros) Don't know whether we need the possibilty to use xPath expressions on passed objects. On one hand it would be helpful, on the other we probably end again with two different syntax. -- Reinhard
Re: [RT] StringTemplate: The answer to our templating needs?
On Fri, 29 Oct 2004, Reinhard Poetz wrote: Tony Collen wrote: Do we need a new, (standardized?) or possibly even *gasp* better templating system for Cocoon? This is where I encourage people to dive in and give their own [RT]s and thoughts on the issue. First, thank you for the pointer. Interesting stuff. But first, we should agree on our needs and then we should choose a technology. IMO less is more - the templating engine should really focus on presenting data. I see following needs: - really powerful query language to access * all kind of objects * incl. passed DOM trees - control structures like for/each, if, choose - call methods on passed objects - stream objects (DOM, XMLizable, ...?) - and probably a way to define macros (see cForm macros) Add this: - works as a Transformer (SAX pipeline) Don't know whether we need the possibilty to use xPath expressions on passed objects. On one hand it would be helpful, on the other we probably end again with two different syntax. XPath is what we're used to when writing xslt stylesheets. The Java dotted notation is what we're used to when writing Java code. As the templating engine will most likely be some xml syntax XPath make IMHO much more sense to me than dottet notation. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: [RT] StringTemplate: The answer to our templating needs?
Reinhard Poetz wrote:
Tony Collen wrote:
Do we need a new, (standardized?) or possibly even *gasp* better
templating system for Cocoon? This is where I encourage people to
dive in and give their own [RT]s and thoughts on the issue.
First, thank you for the pointer. Interesting stuff.
But first, we should agree on our needs and then we should choose a
technology.
IMO less is more - the templating engine should really focus on
presenting data. I see following needs:
- really powerful query language to access
* all kind of objects
* incl. passed DOM trees
- control structures like for/each, if, choose
- call methods on passed objects
- stream objects (DOM, XMLizable, ...?)
- and probably a way to define macros (see cForm macros)
- Ability to directly produce SAX events, for efficiency reasons.
Don't know whether we need the possibilty to use xPath expressions on
passed objects. On one hand it would be helpful, on the other we
probably end again with two different syntax.
XPath is a must-have when you deal with XML documents while Jexl is
mostly useless in that case but is straightforward when you deal with
JavaBeans. I also agree that understanding the difference between
${continuation.id} and #{$continuation/id} is less than evident.
So what about a unified syntax for expansion tokens, within which
different languages could be used. Example:
- ${continuation.id} // Jexl, default syntax
- ${xpath:$continuation/id} // xpath
- ${im:defaults:skin} // input-module
- ${ognl:$continuation.id} // OGNL [1]
Sylvain
[1] http://www.ognl.org/
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [RT] StringTemplate: The answer to our templating needs?
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while
Jexl is mostly useless in that case but is straightforward
when you deal with JavaBeans. I also agree that understanding
the difference between ${continuation.id} and
#{$continuation/id} is less than evident.
So what about a unified syntax for expansion tokens, within
which different languages could be used. Example:
- ${continuation.id} // Jexl, default syntax
- ${xpath:$continuation/id} // xpath
- ${im:defaults:skin} // input-module
- ${ognl:$continuation.id} // OGNL [1]
Hmm, one of the things I really don't like with JXTG is that you
have to different expression languages. You never know which to
use and some things work only with one specific language.
And for me this comes near to FS :)
So, let's decide on one language that we think is the best, but
let's provide a hook so others can plugin their language if *they*
want to.
Carsten
Re: [RT] StringTemplate: The answer to our templating needs?
Le 29 oct. 04, à 10:17, Carsten Ziegeler a écrit : ...Hmm, one of the things I really don't like with JXTG is that you have to different expression languages. You never know which to use and some things work only with one specific language. And for me this comes near to FS :) Yes - but pluggability can be useful for the future and have good effects on code: if someone finds time to refactor the (working but verrry scary if you ask me) JXTG code, making the expression language pluggable certainly helps improve the code structure. I don't think JXTG is broken now, it works well but the code is hard to understand and having all classes in a single huge source code file does not help. ...So, let's decide on one language that we think is the best, but let's provide a hook so others can plugin their language if *they* want to... +1 to both -Bertrand smime.p7s Description: S/MIME cryptographic signature
Implementation of the Continuations checker
The current implementation of our continuations manager uses the excalibur event package for the background checker that checks for expired continuations. Now, this approach has the problem, that excalibur event is deprecated. In addition we aren't using it somewhere else, so it would be great if we could remove this dependency. Yesterday, I wrote a simple replacement which I checked into 2.2: a simple background thread is initialized that sleeps for a configured period of time, checks the continuations, sleeps etc. Now, this solution should work. The question is now, should I port this to 2.1.x as well? Are there better solutions? Carsten Carsten Ziegeler Open Source Group, SN AG http://www.s-und-n.de http://www.osoco.net/weblogs/rael/
Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while
Jexl is mostly useless in that case but is straightforward
when you deal with JavaBeans. I also agree that understanding
the difference between ${continuation.id} and
#{$continuation/id} is less than evident.
So what about a unified syntax for expansion tokens, within
which different languages could be used. Example:
- ${continuation.id} // Jexl, default syntax
- ${xpath:$continuation/id} // xpath
- ${im:defaults:skin} // input-module
- ${ognl:$continuation.id} // OGNL [1]
Hmm, one of the things I really don't like with JXTG is that you
have to different expression languages. You never know which to
use and some things work only with one specific language.
And for me this comes near to FS :)
Agree, but considering the wide variety of applications contexts where
Cocoon is used, I don't think there can be a single one-size-fits-all
language.
There are also a number of places in Cocoon where we need to evaluate
expressions: templates, sitemap, form validators, form bindings, etc,
which are currently implemented separately with different syntaxes. We
need a common expression evaluation component.
So, let's decide on one language that we think is the best, but
let's provide a hook so others can plugin their language if *they*
want to.
That's exactly what I suggest above: we choose a standard default
language, but open the possibility to plug in new ones. XPath is a
must-have, Jexl and IM have very valid use cases which IMO justify them
to be provided by Cocoon. Other languages are just a possibility that we
offer _if_ people want to add their own language.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
RE: [RT] StringTemplate: The answer to our templating needs?
Bertrand Delacretaz wrote: I don't think JXTG is broken now, it works well but the code is hard to understand and having all classes in a single huge source code file does not help. Yupp, that is one of the problems with JXTG. It would be great if a new solution would be pluggable to add new tag libs as well. I created a long time ago the TemplateObjectModelHelper which is in the scratchpad area. The idea of this class is to provide one single object model that can be used in various components, like a template generator/transformer, input moduls, java code etc. In the end, regardless where you want to access objects (flow, template stuff, input modules) you always use the same way, like cocoon.request etc. Depending on the language the component provides the syntax may vary, like cocoon/request - but the path you use is always the same. Carsten
RE: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Sylvain Wallez wrote:
That's exactly what I suggest above: we choose a standard
default language, but open the possibility to plug in new
ones. XPath is a must-have, Jexl and IM have very valid use
cases which IMO justify them to be provided by Cocoon. Other
languages are just a possibility that we offer _if_ people
want to add their own language.
What can you do with Jexl what you can't do with an XPath based
language? My understanding is that they only differ in their syntax
('.' instead of '/').
Now even if Jexl has more functionality I don't see a reason why
this could not be added to an xpath based language.
Personally, I like the jexl syntax (with the dots) more, but if
we decide to go the '/' way of life, well let's do it - it doesn't
really matter.
Carsten
RE: [RT] StringTemplate: The answer to our templating needs?
-Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 10:47 AM To: [EMAIL PROTECTED] Subject: RE: [RT] StringTemplate: The answer to our templating needs? Bertrand Delacretaz wrote: I don't think JXTG is broken now, it works well but the code is hard to understand and having all classes in a single huge source code file does not help. Yupp, that is one of the problems with JXTG. It would be great if a new solution would be pluggable to add new tag libs as well. Making it pluggable may also have the disadvantage that languages are added that can give more control than required for presentation of data. This can make the separation of concerns less clear, which is IMO one of the great things in Cocoon (the control flow). Templates may look like XSP pages, or similair (code mixed with content), breaking the SoC. Or am I wrong? Bart.
Re: Implementation of the Continuations checker
Carsten Ziegeler wrote:
The current implementation of our continuations manager uses
the excalibur event package for the background checker that
checks for expired continuations.
Now, this approach has the problem, that excalibur event is
deprecated. In addition we aren't using it somewhere else,
so it would be great if we could remove this dependency.
Yesterday, I wrote a simple replacement which I checked into 2.2:
a simple background thread is initialized that sleeps for a
configured period of time, checks the continuations, sleeps etc.
Now, this solution should work.
The question is now, should I port this to 2.1.x as well? Are there
better solutions?
java.util.TimerTask?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
DO NOT REPLY [Bug 25951] - Flow - Implicit variable declaration causes double setup/invalidate of FOM_Cocoon
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25951. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25951 Flow - Implicit variable declaration causes double setup/invalidate of FOM_Cocoon [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Additional Comments From [EMAIL PROTECTED] 2004-10-29 09:42 --- The global scope is now locked when a function or continuation is called. Global variables must be explictely declared, and forgetting the 'var' keyword will throw an exception indicating the variable name and the source code location.
DO NOT REPLY [Bug 25283] - [Roadmap] Flowscript - NEXT release
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=25283. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=25283 [Roadmap] Flowscript - NEXT release This bug depends on bug 25951, which changed state: What|Old Value |New Value Status|NEW |RESOLVED Resolution||FIXED
Re: Implementation of the Continuations checker
On Fri, 29 Oct 2004, Carsten Ziegeler wrote: The current implementation of our continuations manager uses the excalibur event package for the background checker that checks for expired continuations. Now, this approach has the problem, that excalibur event is deprecated. In addition we aren't using it somewhere else, so it would be great if we could remove this dependency. Yesterday, I wrote a simple replacement which I checked into 2.2: a simple background thread is initialized that sleeps for a configured period of time, checks the continuations, sleeps etc. Now, this solution should work. The question is now, should I port this to 2.1.x as well? Are there better solutions? Does this mean the CommandManager from the Context is gone? -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: Implementation of the Continuations checker
Carsten Ziegeler wrote: The current implementation of our continuations manager uses the excalibur event package for the background checker that checks for expired continuations. Now, this approach has the problem, that excalibur event is deprecated. In addition we aren't using it somewhere else, so it would be great if we could remove this dependency. Yesterday, I wrote a simple replacement which I checked into 2.2: a simple background thread is initialized that sleeps for a configured period of time, checks the continuations, sleeps etc. Now, this solution should work. The question is now, should I port this to 2.1.x as well? Are there better solutions? I think this is completely enough for such a simple task. lg -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
RE: Implementation of the Continuations checker
Giacomo Pati wrote: On Fri, 29 Oct 2004, Carsten Ziegeler wrote: The current implementation of our continuations manager uses the excalibur event package for the background checker that checks for expired continuations. Now, this approach has the problem, that excalibur event is deprecated. In addition we aren't using it somewhere else, so it would be great if we could remove this dependency. Yesterday, I wrote a simple replacement which I checked into 2.2: a simple background thread is initialized that sleeps for a configured period of time, checks the continuations, sleeps etc. Now, this solution should work. The question is now, should I port this to 2.1.x as well? Are there better solutions? Does this mean the CommandManager from the Context is gone? Yes, at least for 2.2 - for 2.1.x we would have to decide if we remove it. Are you using it? Carsten
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
That's exactly what I suggest above: we choose a standard
default language, but open the possibility to plug in new
ones. XPath is a must-have, Jexl and IM have very valid use
cases which IMO justify them to be provided by Cocoon. Other
languages are just a possibility that we offer _if_ people
want to add their own language.
What can you do with Jexl what you can't do with an XPath based
language? My understanding is that they only differ in their syntax
('.' instead of '/').
Now even if Jexl has more functionality I don't see a reason why
this could not be added to an xpath based language.
Personally, I like the jexl syntax (with the dots) more, but if
we decide to go the '/' way of life, well let's do it - it doesn't
really matter.
Carsten
Maybe I do not fully understand JXPath but I had a lot of troubles with
evaluating expressions that involved java beans and some test conditions
(equality). I had to convert some of jx:if conditions to Jexl because I
couldn't make it work for JXPath.
I also see from my experience that Jexl has a much lower learning curve (at
least for my developers who are familiar with Java and not so much with XPath).
I do not see much space for next language in JX if the language is
another-bean-or-xml-query-language. What I would really like there is the
ability to write a little more soplisticated macros. jx:macro simplicity
causes more sophisticated macros impossible to write. I implemented a reusable
list control (something like http://valuelist.sourceforge.net/) in JX with
controls for:
- filtering
- paging (next, prev, first, last, no per page, seek to page number)
- row actions
- list control actions
but it turned out that what I have implemented imposes a lot of constraints on
how a developer should use it. I see a little space of improvement with
current jx:macro implementation.
--
Leszek Gawron [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: rev 55957 - in cocoon/branches/BRANCH_2_1_X: . src/java/org/apache/cocoon/components/flow/javascript/fom
[EMAIL PROTECTED] wrote:
@@ -687,6 +703,7 @@
if (fun == Scriptable.NOT_FOUND) {
throw new ResourceNotFoundException(Function \javascript: + funName +
()\ not found);
}
+thrScope.setLock(true);
ScriptRuntime.call(context, fun, thrScope, funArgs, thrScope);
} catch (JavaScriptException ex) {
EvaluatorException ee = Context.reportRuntimeError(
@@ -710,6 +727,7 @@
throw new CascadingRuntimeException(ee.getMessage(), ee);
}
} finally {
+thrScope.setLock(false);
setSessionScope(thrScope);
if (cocoon != null) {
cocoon.popCallContext();
Is there a reason why you need to un-lock it?
Vadim
Re: [Proposal] New Block building system
Stefano Mazzocchi wrote: Reinhard Poetz wrote: More information and explanations can be found at http://wiki.apache.org/cocoon/CocoonBlockBuilder [not critizing, just curious] can you explain why you think that having block/lib is going to be jar hell while lib/block is not? you can have one block use lib-1.0.jar and another one use lib-1.1.jar? I haven't been following the discussion closely so I may talk rubbish. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: svn commit: rev 55957 - in cocoon/branches/BRANCH_2_1_X: . src/java/org/apache/cocoon/components/flow/javascript/fom
Vadim Gritsenko wrote:
[EMAIL PROTECTED] wrote:
@@ -687,6 +703,7 @@
if (fun == Scriptable.NOT_FOUND) {
throw new
ResourceNotFoundException(Function \javascript: + funName + ()\
not found);
}
+thrScope.setLock(true);
ScriptRuntime.call(context, fun, thrScope,
funArgs, thrScope);
} catch (JavaScriptException ex) {
EvaluatorException ee = Context.reportRuntimeError(
@@ -710,6 +727,7 @@
throw new
CascadingRuntimeException(ee.getMessage(), ee);
}
} finally {
+thrScope.setLock(false);
setSessionScope(thrScope);
if (cocoon != null) {
cocoon.popCallContext();
Is there a reason why you need to un-lock it?
Yes: the scope must be unlocked whenever a script is loaded, in order
for the global variable declarations to be possible. Without unlock, no
global variables, which would be pretty much annoying :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Persisting SimpleLuceneQuery [Long]
Hi All At the GT, I got the chance to meet Antonio (oh joy !!) and one of the many things we talked about was the possibility of him giving me some help learning Apache ORO. He very graciously accepted!!! I have a project, the o.a.c.bean.query.SimpleLuceneQuery, in Cocoon, which is possibly an ideal candidate, as it comes out of a project for work and I have already made it persistable, using Hibernate. What I hope to do is to make the Queries persistable in HSQLDB via ORO and add this to Cocoon as a new Block, both as a sample and as a useful module that should be easy to add to your own project. Antonio's recommendation was that we discuss this conversion on the Dev list, as other members of the list could also benefit from this. So, unless anyone has any objections .. here goes !!! Background: The QueryBean is a simple Bean for allowing the User to assemble complex Queries on a Lucene index via CForms, without having to know the Lucene Query Language. Try it, it is in the Lucene Samples. I have actually completely re-written the flowscript in my local version to be much cleaner, but the current version in Cocoon allows you to do the following: Quick Queries: a simple query assembled from request params Complex Queries: a CForms repeater to allow multiple Queries and'd or or'd together Multiple match types (like, contains, exact etc.). Easy to setup field Queries. Query History kept in your Session, you can re-use and edit previous Queries Structure: A Query is made up of a single SimpleLuceneQueryBean, which has at least one SimpleLuceneCriterionBean(s) in it's Collection. The (currently PostGres) DB Schema is very simple, it looks like this: CREATE TABLE query ( id serial unique,/* the unique persistence ID */ user_id text NOT NULL, /* the ID of the owner */ q_date timestamp,/* the date it was saved */ q_bool text, /* how the criteria are combined */ q_name text,/* the name of the saved query */ q_type text, /* the type of the saved query (ie. which CForm) */ q_size integer /* the number of results to show per page */ ); CREATE TABLE criterion ( id serial unique,/* the unique persistence ID */ query_id integer, /* the query this belongs to */ c_field text, /* the lucene field to search in */ c_match text, /* the type of match to perform */ c_term text, /* the term to search for */ c_position integer, /* the index of this criterion in the query's criteria */ foreign key (query_id) references query(id) ); GRANT INSERT, SELECT, UPDATE, DELETE ON query, query_id_seq, criterion, criterion_id_seq TO cocoon; As you can see from this, there are a bunch of text fields to hold info about the query, and a one-to-many relationship between the Query and the Criterion(s). If you compare this with the current state of the Beans in Cocoon, the following changes have been made: Added the property 'user' to the Query so we can see which are yours Changed the name of the property that hold the query text in the Criterion from 'value' to 'term' to make it clearer. Mapping: Below, is the Hibernate Mapping for the Query and Criterion Beans, adjusted to the Cocoon Package. As you can see, it is about as simple as you can get. hibernate-mapping package=org.apache.cocoon.bean.query class name=SimpleLuceneQueryBean table=query id name=id column=id type=long generator class=sequence param name=sequencequery_id_seq/param /generator /id property name=bool column=q_bool type=string/ property name=date column=q_date type=timestamp/ property name=name column=q_name type=string/ property name=type column=q_type type=string/ property name=size column=q_size type=long/ property name=user column=user_id type=string/ list name=criteria table=criterion cascade=all-delete-orphan lazy=false key column=query_id/ index column=c_position/ one-to-many class=SimpleLuceneCriterionBean/ /list /class /hibernate-mapping hibernate-mapping package=org.apache.cocoon.bean.query class name=SimpleLuceneCriterionBean table=criterion id name=id column=id type=long generator class=sequence param name=sequencecriterion_id_seq/param /generator /id property name=field column=c_field type=string/ property name=match column=c_match type=string/ property name=term column=c_term type=string/ /class /hibernate-mapping The FlowScript: This is the QueryFavourites JavaScript Object Library that handles most of the work, you will see that it uses our PersistanceFactory to manage the connection to PostGres. The error messages it outputs are i18n keys. importClass(Packages.net.sf.hibernate.expression.Expression); importClass(Packages.net.sf.hibernate.expression.Order); importPackage(Packages.org.apache.cocoon.bean.query);
RE: [RT] StringTemplate: The answer to our templating needs?
Bart Molenkamp wrote: Bertrand Delacretaz wrote: I don't think JXTG is broken now, it works well but the code is hard to understand and having all classes in a single huge source code file does not help. Yupp, that is one of the problems with JXTG. It would be great if a new solution would be pluggable to add new tag libs as well. Making it pluggable may also have the disadvantage that languages are added that can give more control than required for presentation of data. This can make the separation of concerns less clear, which is IMO one of the great things in Cocoon (the control flow). Templates may look like XSP pages, or similair (code mixed with content), breaking the SoC. Or am I wrong? No, you're right - this is a possible danger. But as long as we only make it pluggable and be careful that we don't fall into this trap, I see no problem with it. Carsten
Re: [RT] StringTemplate: The answer to our templating needs?
Tony Collen wrote: -- Well, I was too quick on the key presses, so here goes again. Sorry for the spam :) -- Brought to you by the maniac that brings you ANTLR! A while ago I was investigating different templating languages, and I came across one called StringTemplate [1] Of particular interest is the author's paper, Enforcing Model-View Separation in Template Engines [2]. Please read it. It's interesting. I don't consider myself a template or grammar/language parsing expert, but this guy seems to have put a ton of thought into what makes a good templating engine. Specifically, his work seems grounded in some pretty solid language parsing theory. Another reason would be because of JXTemplateGenerator. This generator is arguably one of the most popular combos to use with the Power Trio model of Cocoon development. Unfortunately, the JXTG seemed to be a one-man-show, and since that one man is gone, the likelihood of the generator getting proper maintenance decreases significantly. The code is also huge and scary (at least to me ;) ). Looks scary but really isn't. The amount of inner classes makes it quite problematic to read. Additionally, the dual syntax for accessing things through JXPath and JEXL expressions has led to people, including myself, being confused as to when to use each syntax. Seeing the mixed syntax is even worse. IMO we need a *single*, easy-to-use syntax for this. I do not agree. See my other post today in this thread. Therefore, I suggest that Cocoon needs a better, simple, minimalistic templating system that's not the JXTemplateGenerator. Another good thing: StringTemplate is BSD license. Of course, this is a do-ocracy, but I lack some of the finer knowledge to do a StringTemplate generator. Do we need a new, (standardized?) or possibly even *gasp* better templating system for Cocoon? This is where I encourage people to dive in and give their own [RT]s and thoughts on the issue. JXTG is very good but it lacks a way to extend it with some reusable pieces of code (macros). I have been trying to make some other templating languages be usable with cocoon but all of them are generating TEXT and in cocoon xml land this is a real problem. Here JXTG is really powerful. It will convert every model value to XML safe representation. - Velocity: does not have a built in support for xmlification. the only way is to write some extension that would be awful to use. - FreeMarker: also generates text but it's got some support for xmlification. The problem is that it's got it's own source resolving mechanism that is in total contradiction to what cocoon works on. Result: whole resolving and caching would have to be thrown away. I think that all templating languages that are not xml based will also introduce character encoding problems. I say: let's stick to JXTG just add some power with the ability to write more sophisticated macros/taglibs. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
RE: Implementation of the Continuations checker
On Fri, 29 Oct 2004, Carsten Ziegeler wrote: Giacomo Pati wrote: On Fri, 29 Oct 2004, Carsten Ziegeler wrote: The current implementation of our continuations manager uses the excalibur event package for the background checker that checks for expired continuations. Now, this approach has the problem, that excalibur event is deprecated. In addition we aren't using it somewhere else, so it would be great if we could remove this dependency. Yesterday, I wrote a simple replacement which I checked into 2.2: a simple background thread is initialized that sleeps for a configured period of time, checks the continuations, sleeps etc. Now, this solution should work. The question is now, should I port this to 2.1.x as well? Are there better solutions? Does this mean the CommandManager from the Context is gone? Yes, at least for 2.2 - for 2.1.x we would have to decide if we remove it. Are you using it? Yes, we used the CommandManager in some projects. It is based on the PooledExecutor from Doug Leas concurrent-utils package. It comes in quite handy as you can put tasks there you'd like to be done asynchroniously (ie. indexing a uploaded document with lucene to speed up percieved performance). One alternative is that we build up our own CommandManager into the Context which is piece of cake to do. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: [RT] StringTemplate: The answer to our templating needs?
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while
Jexl is mostly useless in that case but is straightforward
when you deal with JavaBeans. I also agree that understanding
the difference between ${continuation.id} and
#{$continuation/id} is less than evident.
So what about a unified syntax for expansion tokens, within
which different languages could be used. Example:
- ${continuation.id} // Jexl, default syntax
- ${xpath:$continuation/id} // xpath
- ${im:defaults:skin} // input-module
- ${ognl:$continuation.id} // OGNL [1]
Hmm, one of the things I really don't like with JXTG is that you
have to different expression languages. You never know which to
use and some things work only with one specific language.
And for me this comes near to FS :)
And if there are language constructs that are not possible to implement with
JXPath and JavaBeans? And I am sure there are (I had some problems myself but
shoot me in the head: I do not remember the exact cases). Should we be saying
to users: it does not work with JXPath, still it would with Jext, since we
dropped jexl officialy you have to plug it back in yourself?
--
Leszek Gawron [EMAIL PROTECTED]
Project ManagerMobileBox sp. z o.o.
+48 (61) 855 06 67 http://www.mobilebox.pl
mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [Proposal] New Block building system
Leszek Gawron wrote: Stefano Mazzocchi wrote: Reinhard Poetz wrote: More information and explanations can be found at http://wiki.apache.org/cocoon/CocoonBlockBuilder [not critizing, just curious] can you explain why you think that having block/lib is going to be jar hell while lib/block is not? you can have one block use lib-1.0.jar and another one use lib-1.1.jar? I haven't been following the discussion closely so I may talk rubbish. not yet, but RealBlocks will enable this -- Reinhard
Re: [RT] StringTemplate: The answer to our templating needs?
Carsten Ziegeler wrote: Bart Molenkamp wrote: Bertrand Delacretaz wrote: I don't think JXTG is broken now, it works well but the code is hard to understand and having all classes in a single huge source code file does not help. Yupp, that is one of the problems with JXTG. It would be great if a new solution would be pluggable to add new tag libs as well. Making it pluggable may also have the disadvantage that languages are added that can give more control than required for presentation of data. This can make the separation of concerns less clear, which is IMO one of the great things in Cocoon (the control flow). Templates may look like XSP pages, or similair (code mixed with content), breaking the SoC. Or am I wrong? No, you're right - this is a possible danger. But as long as we only make it pluggable and be careful that we don't fall into this trap, I see no problem with it. The question is: Do we want to prevent our users from this or is it their own decision? -- Reinhard
RE: Implementation of the Continuations checker
Giacomo Pati wrote: Yes, we used the CommandManager in some projects. It is based on the PooledExecutor from Doug Leas concurrent-utils package. It comes in quite handy as you can put tasks there you'd like to be done asynchroniously (ie. indexing a uploaded document with lucene to speed up percieved performance). One alternative is that we build up our own CommandManager into the Context which is piece of cake to do. I have nothing against building our own one (we use concurrent-utils in the core already), so if you volunteer... :) But why do we put it into the Context? Wouldn't it be better to make a simple component out of it? Carsten
RE: [RT] StringTemplate: The answer to our templating needs?
Leszek Gawron wrote: And if there are language constructs that are not possible to implement with JXPath and JavaBeans? And I am sure there are (I had some problems myself but shoot me in the head: I do not remember the exact cases). Should we be saying to users: it does not work with JXPath, still it would with Jext, since we dropped jexl officialy you have to plug it back in yourself? I suggest an xpath based language not JXPath :) Yes, I had some problems with JXPath as well, so I wouldn't use it but rather write an own implementation which isn't that difficult. Carsten
Re: Cocoon Portal Engine Tools
What the meaning GT? What's that? On Thu, 28 Oct 2004 13:08:08 -0400, JACOB, ERIC [EMAIL PROTECTED] wrote: Hi, I would be interested in that too. Anyone has tried out the demo at GT and could provide some comments about the tool? Eric -Original Message- From: Ralph Goers [mailto:[EMAIL PROTECTED] Sent: Thursday, October 28, 2004 11:38 AM To: [EMAIL PROTECTED] Subject: Re: Cocoon Portal Engine Tools Just a reminder that I am still very interested in seeing this. Is there a preview version I could get my hands on? Ralph Jon Evans said: Hi, On 7 Oct 2004, at 08:08, Matthew Langham wrote: Not yet. We hope to have a demo version with us at the GT and then be able to commit something soon after. Really looking forward to seeing it! See you at the GT. Cheers, Jon -- Merlin Information Systems Limited, Merlin House, Gawcott Road, Buckingham, United Kingdom. MK18 1TN Tel: +44 (0) 1280 824331 Fax: +44 (0) 1280 824112 http://www.misgl.com Provider of IT Services and Online Portal Support Services. Confidentiality: The information contained in this email (including any attachments) is confidential and is intended solely for the use of the named addressee. Access, copying or re-use of the information in it by any other person is not authorised. If you are not the intended recipient, please notify us immediately by telephone or by e-mail to [EMAIL PROTECTED] *** This mail has been scanned for viruses ***
Re: [RT] StringTemplate: The answer to our templating needs?
Bart Molenkamp wrote: -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 10:47 AM To: [EMAIL PROTECTED] Subject: RE: [RT] StringTemplate: The answer to our templating needs? Bertrand Delacretaz wrote: I don't think JXTG is broken now, it works well but the code is hard to understand and having all classes in a single huge source code file does not help. Yupp, that is one of the problems with JXTG. It would be great if a new solution would be pluggable to add new tag libs as well. Making it pluggable may also have the disadvantage that languages are added that can give more control than required for presentation of data. This can make the separation of concerns less clear, which is IMO one of the great things in Cocoon (the control flow). Templates may look like XSP pages, or similair (code mixed with content), breaking the SoC. You are right the SoC might be broken easily. Still you can code your business logic in flow. It's not elegant but you can. Same goes for templating languages. You shouldn't break SoC but you can. That won't kill you. That's how I started using cocoon. After a few projects you realize yourself that XSP does not work for you and you try to make the project be more elegant. You are ready for more advanced approach. It's like driving a car: a car has a power to go 200 km/h. Still you are being taught not to drive at that speed. You should be able to do a lot with your templating language but be advised to do it in some commonly agreed manner. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
RE: [RT] StringTemplate: The answer to our templating needs?
Reinhard Poetz wrote: No, you're right - this is a possible danger. But as long as we only make it pluggable and be careful that we don't fall into this trap, I see no problem with it. The question is: Do we want to prevent our users from this or is it their own decision? It's their own decision. Now in the end you can't prevent users from doing so - and perhaps, although we think that it's wrong it might be exactly what they need for their use case. I definitly have the need to plug my own tags into JXTG ;) Carsten
Re: [RT] StringTemplate: The answer to our templating needs?
Reinhard Poetz wrote: No, you're right - this is a possible danger. But as long as we only make it pluggable and be careful that we don't fall into this trap, I see no problem with it. The question is: Do we want to prevent our users from this or is it their own decision? Applying constraints on such level of functionality just makes it less flexible. Even right now you can issue a business logic in JXTG by calling some bean method. Still users are adviced not to do it. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: [RT] StringTemplate: The answer to our templating needs?
Carsten Ziegeler wrote: Reinhard Poetz wrote: It's their own decision. Now in the end you can't prevent users from doing so - and perhaps, although we think that it's wrong it might be exactly what they need for their use case. I definitly have the need to plug my own tags into JXTG ;) I cannot agree more. It is my decision if I choose/need to break SoC. -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
RE: Implementation of the Continuations checker
On Fri, 29 Oct 2004, Carsten Ziegeler wrote: Giacomo Pati wrote: Yes, we used the CommandManager in some projects. It is based on the PooledExecutor from Doug Leas concurrent-utils package. It comes in quite handy as you can put tasks there you'd like to be done asynchroniously (ie. indexing a uploaded document with lucene to speed up percieved performance). One alternative is that we build up our own CommandManager into the Context which is piece of cake to do. I have nothing against building our own one (we use concurrent-utils in the core already), so if you volunteer... :) Sure, no problem. How should it be named? Someone mentioned Crons JobScheduler as it has a fireJob() method that could do it but would we want the cron block go into the core? But why do we put it into the Context? Wouldn't it be better to make a simple component out of it? It dosn't matter for me as long as a flow script ca do .setupObject( foo ) and foo is able to get it. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
RE: Implementation of the Continuations checker
Giacomo Pati wrote: Sure, no problem. How should it be named? What does it do? :) Someone mentioned Crons JobScheduler as it has a fireJob() method that could do it but would we want the cron block go into the core? Hmm, I think this depends on the effort it takes to create it. If we have to add/maintain 10 classes with hundreds of LOCs, I would say, let's use Cron - but if it is a simple class, we should imho avoid the dependency for the core. But why do we put it into the Context? Wouldn't it be better to make a simple component out of it? It dosn't matter for me as long as a flow script ca do .setupObject( foo ) and foo is able to get it. Great :) Carsten
Duesseldorf, Nov8-Nov11
I'll be attending the Glesstec [1] fair in Duesseldorf from Nov 8 to Nov 11. It would be fun to meet up with some ASF folks there, maybe for a dinner gettogether. [1] http://www.glasstec-online.com/ -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
RE: Implementation of the Continuations checker
On Fri, 29 Oct 2004, Carsten Ziegeler wrote: Giacomo Pati wrote: Sure, no problem. How should it be named? What does it do? :) Someone mentioned Crons JobScheduler as it has a fireJob() method that could do it but would we want the cron block go into the core? Hmm, I think this depends on the effort it takes to create it. If we have to add/maintain 10 classes with hundreds of LOCs, I would say, let's use Cron - but if it is a simple class, we should imho avoid the dependency for the core. Well, this depend of the functionality needed. With a look into the event package there are: Command (Interface) DelayedCommand (Interface) RepeatedCommand (Interface) on the client side, and there will be: CommandManager (Interface) DefaultCommandManager (Class) plus some helper classes to implement the scheduling on the service side. Now, decide yourself if it is worth doing it ourself (in fact, cloning the event package more or less and maintaining it) or put the cron block into core which has all you need for background task management but adds some more jars and classes to the core. But why do we put it into the Context? Wouldn't it be better to make a simple component out of it? It dosn't matter for me as long as a flow script ca do .setupObject( foo ) and foo is able to get it. Great :) Carsten -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: Cocoon Portal Engine Tools
e-|vira wrote: What the meaning GT? What's that? http://www.orixo.com/events/gt2004/ -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Implementation of the Continuations checker
Giacomo Pati wrote: On Fri, 29 Oct 2004, Carsten Ziegeler wrote: Giacomo Pati wrote: On Fri, 29 Oct 2004, Carsten Ziegeler wrote: The current implementation of our continuations manager uses the excalibur event package for the background checker that checks for expired continuations. Now, this approach has the problem, that excalibur event is deprecated. In addition we aren't using it somewhere else, so it would be great if we could remove this dependency. Yesterday, I wrote a simple replacement which I checked into 2.2: a simple background thread is initialized that sleeps for a configured period of time, checks the continuations, sleeps etc. Now, this solution should work. The question is now, should I port this to 2.1.x as well? Are there better solutions? Does this mean the CommandManager from the Context is gone? Yes, at least for 2.2 - for 2.1.x we would have to decide if we remove it. Are you using it? Yes, we used the CommandManager in some projects. It is based on the PooledExecutor from Doug Leas concurrent-utils package. It comes in quite handy as you can put tasks there you'd like to be done asynchroniously (ie. indexing a uploaded document with lucene to speed up percieved performance). I believe that the excalibur event package lives on at d-haven [1]. Why not use that? 1. http://api.d-haven.org/event/ -- Unico
Re: Cocoon Portal Engine Tools
Thanks On Fri, 29 Oct 2004 13:45:53 +0200, Leszek Gawron [EMAIL PROTECTED] wrote: e-|vira wrote: What the meaning GT? What's that? http://www.orixo.com/events/gt2004/ -- Leszek Gawron [EMAIL PROTECTED] Project ManagerMobileBox sp. z o.o. +48 (61) 855 06 67 http://www.mobilebox.pl mobile: +48 (501) 720 812 fax: +48 (61) 853 29 65
Re: Implementation of the Continuations checker
Unico Hommes wrote: ... I believe that the excalibur event package lives on at d-haven [1]. Why not use that? Oh oh. We did this discussion with the container, I hope we don't have to go over this again for every Avalon dependency we have ;-P 1. http://api.d-haven.org/event/ -- Nicola Ken Barozzi [EMAIL PROTECTED] - verba volant, scripta manent - (discussions get forgotten, just code remains) -
Re: [RT] StringTemplate: The answer to our templating needs?
On 29.10.2004 13:07, Carsten Ziegeler wrote: It's their own decision. Now in the end you can't prevent users from doing so But that's exactly what the document is about: *enforcing* separation instead of *encourage*. StringTemplate claims to provide that. Joerg
Re: Implementation of the Continuations checker
Nicola Ken Barozzi wrote: Unico Hommes wrote: ... I believe that the excalibur event package lives on at d-haven [1]. Why not use that? Oh oh. We did this discussion with the container, I hope we don't have to go over this again for every Avalon dependency we have ;-P Nope just with Avalon/Excalibur *components* in general. The relationship between Cocoon and its container is much more integral than that between Cocoon and the components it uses. I was under the impression that we would be continuing to use excalibur components. Not knowing the history of the migration of event to d-haven I just wanted to find out whether this case is somehow special. BTW if I inadvertently raised a painful subject I apologize for that, it is not my intention to antagonize at all. But to discuss these issues openly. -- Unico
Re: Cocoon read-only (ex: CD-ROM) add ${context-work} parameter to logkit.xconf from CocoonServlet.java
Frédéric Glorieux wrote:
I'm usually running multiple instances of same cocoon for debug
(different ports, different servletPath, to test under different
contexts and initParams). I know how to find my logs in such ways, but
with the config upper, it may be nice to have something like
{webapp}/WEB-INF/work/{ServletName}_{host}_{port}_{ServletPath}/logs
instead of
{webapp}/WEB-INF/work/cocoon-files/logs
I tried to found a way to get these infos from *CocoonServlet.java* line
271, but ServletContext and ServletConfig don't seems to expose those
infos. It's of course a very bad idea to wait for the first request to
get {host}_{port}_{ServletPath} for a log path, but if more guru than me
have an idea of a 2 line solution...
Problem is, you can run *same* Cocoon instance with different hosts, ports, etc.
So no, this idea is not feasible.
Vadim
Re: svn commit: rev 55895 - cocoon/branches/BRANCH_2_1_X
Tony Collen wrote: [EMAIL PROTECTED] wrote: --- cocoon/branches/BRANCH_2_1_X/blocks.properties(original) +++ cocoon/branches/BRANCH_2_1_X/blocks.propertiesThu Oct 28 14:51:15 2004 @@ -72,7 +72,6 @@ #include.block.lucene=false #include.block.naming=false #include.block.paranoid=false -#include.block.php=false #include.block.poi=false #-[dependency]: portal depends on authentication-fw, html, session-fw. #-[dependency]: portal is needed by faces. @@ -160,6 +159,7 @@ # For including one of them you have to set the exclude property into comment in # blocks.properties. +include.block.php=false #-[dependency]: portal-fw depends on authentication-fw, session-fw. include.block.portal-fw=false include.block.swf=false Modified: cocoon/branches/BRANCH_2_1_X/gump.xml == --- cocoon/branches/BRANCH_2_1_X/gump.xml(original) +++ cocoon/branches/BRANCH_2_1_X/gump.xmlThu Oct 28 14:51:15 2004 @@ -451,7 +451,7 @@ nag from=Gump lt;[EMAIL PROTECTED]gt; to=[EMAIL PROTECTED]/ /project - project name=cocoon-block-php status=stable + project name=cocoon-block-php status=deprecated packageorg.apache.cocoon/package ant target=gump-block Is this all that needed to be done in order to correctly deprecate the block, or is there something else I'm missing (e.g. a @deprecated tag on the PHPGenerator) ? Of course. PS You re-generated blocks.properties, not hand-edited it, right? Vadim
Test
Just a test. I was thinking I get bounces from some addresses whenever I post here. Sorry for the inconvenience. -- Giacomo Pati Otego AG, Switzerland - http://www.otego.com Orixo, the XML business alliance - http://www.orixo.com
Re: Persisting SimpleLuceneQuery [Long]
Le 29 oct. 04, à 12:41, Jeremy Quinn a écrit : ...What I hope to do is to make the Queries persistable in HSQLDB via ORO... ORO? That's a regexp package, do you mean OJB instead? ...I suppose one of the first questions that needs asking before going ahead and making an Apache ORO equivalent to the above, is : is the structure of the SimpleLuceneQuery/SimpleLuceneQueryBean and SimpleLuceneCriterion/SimpleLuceneCriterionBean as good as it needs to be? Can it be improved? Is it easy enough to extend it? Is the Interface overkill? If it is desirable, is it properly done etc. etc... One simplification in terms of storage might be to edit the query criterion as an XML document and store this as a block in the DB (but I don't know how hard it is to get from this XML to Lucene criteria then). It would make the DB model much simpler, and I don't think you're running queries on the criterion table anyway, or are you? I imagine querying on the user_id, date and name fields only, so I'm not sure if the separate criterion table brings something. Also, considering storage of an XML block keyed by user_id, date and name makes it easier to make storage pluggable, allowing file-based storage if someone wants it for example. I don't want to suggest change for the sake of change, but as you're asking ;-) ...Should QueryFavourites.js be rewritten in Java? Should it be in the style of a DAO? Dunno about a DAO but it looks like it should - this is not code that is going to change often, and it needs to be robust and tested, so I'd move it to java. ...I guess I need to add a new Block to Cocoon, eek I have never done one !! It's very easy if you take one of the simplest blocks as a template. ...Once again, I would like to express my thanks to Antonio for offering to help with this... We know he's a nice guy ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Persisting SimpleLuceneQuery [Long]
Il giorno 29/ott/04, alle 12:41, Jeremy Quinn ha scritto: What I hope to do is to make the Queries persistable in HSQLDB via ORO and add this to Cocoon as a new Block, both as a sample and as a useful module that should be easy to add to your own project. I'm sure you meant OJB instead of ORO here, right? Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Implementation of the Continuations checker
On Oct 29, 2004, at 4:41 AM, Carsten Ziegeler wrote: Yesterday, I wrote a simple replacement which I checked into 2.2: a simple background thread is initialized that sleeps for a configured period of time, checks the continuations, sleeps etc. Now, this solution should work. The question is now, should I port this to 2.1.x as well? Are there better solutions? If you want to do something very simple, then do that. But if something more complex is desired, I say stick with the existing component to manage the threads (d-haven event fka excalibur event) -pete
Re: [RT] StringTemplate: The answer to our templating needs?
Le 29 oct. 04, à 12:59, Reinhard Poetz a écrit : Bart Molenkamp wrote: ... No, you're right - this is a possible danger. But as long as we only make it pluggable and be careful that we don't fall into this trap, I see no problem with it. The question is: Do we want to prevent our users from this or is it their own decision? Definitely their own decision. I think the show the mainstream/correct way but don't block users from doing whatever if they really want attitude that we see in several places in Cocoon is very powerful. It leaves space for people to be experimental and (sometimes) find cool new ways of doing things. If you think about it this is the basic philosophy of unix: consider your users as intelligent people and don't take them by the hand too much. This is very powerful for platforms, and Cocoon *is* becoming a platform. -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Implementation of the Continuations checker
Il giorno 29/ott/04, alle 11:26, Sylvain Wallez ha scritto: java.util.TimerTask? +1. Do the simplest thing that might possibly work. KISS, YAGNI, etc. etc. etc. Ugo -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: Persisting SimpleLuceneQuery [Long]
On 29 Oct 2004, at 13:23, Ugo Cei wrote: Il giorno 29/ott/04, alle 12:41, Jeremy Quinn ha scritto: What I hope to do is to make the Queries persistable in HSQLDB via ORO and add this to Cocoon as a new Block, both as a sample and as a useful module that should be easy to add to your own project. I'm sure you meant OJB instead of ORO here, right? Yeah, sorry :) OJB, OJB OJB . that is even worse than your OBJ mistake ;) regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: Persisting SimpleLuceneQuery [Long]
Jeremy Quinn wrote: If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! Aha! I'm on to you, person that wants to make believe he is Jeremy Quinn! ;-) -- Unico
Re: Persisting SimpleLuceneQuery [Long]
On 29 Oct 2004, at 13:21, Bertrand Delacretaz wrote: Le 29 oct. 04, à 12:41, Jeremy Quinn a écrit : ...What I hope to do is to make the Queries persistable in HSQLDB via ORO... ORO? That's a regexp package, do you mean OJB instead? Yes groan ;) ...I suppose one of the first questions that needs asking before going ahead and making an Apache ORO equivalent to the above, is : is the structure of the SimpleLuceneQuery/SimpleLuceneQueryBean and SimpleLuceneCriterion/SimpleLuceneCriterionBean as good as it needs to be? Can it be improved? Is it easy enough to extend it? Is the Interface overkill? If it is desirable, is it properly done etc. etc... One simplification in terms of storage might be to edit the query criterion as an XML document and store this as a block in the DB (but I don't know how hard it is to get from this XML to Lucene criteria then). It would definitely complicate matters. It would make the DB model much simpler, and I don't think you're running queries on the criterion table anyway, or are you? I imagine querying on the user_id, date and name fields only, so I'm not sure if the separate criterion table brings something. Also, considering storage of an XML block keyed by user_id, date and name makes it easier to make storage pluggable, allowing file-based storage if someone wants it for example. I don't want to suggest change for the sake of change, but as you're asking ;-) OK ;) Thanks for this feedback, but I am still not convinced . ...Should QueryFavourites.js be rewritten in Java? Should it be in the style of a DAO? Dunno about a DAO but it looks like it should - this is not code that is going to change often, and it needs to be robust and tested, so I'd move it to java. It was written in OO JS as an exercise in my getting used to that form of the language, however, it is now easy to re-code as Java . ...I guess I need to add a new Block to Cocoon, eek I have never done one !! It's very easy if you take one of the simplest blocks as a template. I tried once before, but mierably failed to get it to work, here is my incentive to try again ;) ...Once again, I would like to express my thanks to Antonio for offering to help with this... We know he's a nice guy ;-) +1 thanks regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: Implementation of the Continuations checker
Nicola Ken Barozzi wrote: Unico Hommes wrote: ... I believe that the excalibur event package lives on at d-haven [1]. Why not use that? Or we could stick with excalibur-event, if there is nothing wrong with it. Oh oh. We did this discussion with the container, I hope we don't have to go over this again for every Avalon dependency we have ;-P This smells a lot as NIH syndrome [1]. Are we going to rewrite every single excalibur component we use? Vadim [1] http://c2.com/cgi/wiki?NotInventedHere
Re: Persisting SimpleLuceneQuery [Long]
On 29 Oct 2004, at 13:37, Unico Hommes wrote: Jeremy Quinn wrote: If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! Aha! I'm on to you, person that wants to make believe he is Jeremy Quinn! ;-) ROFL Objective reality is a synthetic construct, dealing with a hypothetical universalization of a multitude of subjective realities. Philip K Dick - The Electric Ant smime.p7s Description: S/MIME cryptographic signature
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
That's exactly what I suggest above: we choose a standard
default language, but open the possibility to plug in new
ones. XPath is a must-have, Jexl and IM have very valid use
cases which IMO justify them to be provided by Cocoon. Other
languages are just a possibility that we offer _if_ people
want to add their own language.
What can you do with Jexl what you can't do with an XPath based
language? My understanding is that they only differ in their syntax
('.' instead of '/').
Now even if Jexl has more functionality I don't see a reason why
this could not be added to an xpath based language.
Technically this should be possible, but how do we write something like
widget.getChild(foo).getAttribute(bar) in XPath?
That's why I propose to have a default syntax (be it JXPath or Jexl),
and let other syntax be plugged in, while limiting ourselves the range
of what is included in Cocoon.
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Persisting SimpleLuceneQuery [Long]
Jeremy Quinn wrote: On 29 Oct 2004, at 13:23, Ugo Cei wrote: Il giorno 29/ott/04, alle 12:41, Jeremy Quinn ha scritto: What I hope to do is to make the Queries persistable in HSQLDB via ORO and add this to Cocoon as a new Block, both as a sample and as a useful module that should be easy to add to your own project. I'm sure you meant OJB instead of ORO here, right? Yeah, sorry :) OJB, OJB OJB . that is even worse than your OBJ mistake ;) LOL Count over the week how many corrections you'll get ;-P Vadim
Re: Persisting SimpleLuceneQuery [Long]
Le 29 oct. 04, à 14:36, Jeremy Quinn a écrit : ...I'm sure you meant OJB instead of ORO here, right? Yeah, sorry :) OJB, OJB OJB . that is even worse than your OBJ mistake ;) Although...implementing persistence based on ORO might be an interesting exercise for a Friday afternoon ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: Persisting SimpleLuceneQuery [Long]
Il giorno 29/ott/04, alle 14:36, Jeremy Quinn ha scritto: On 29 Oct 2004, at 13:23, Ugo Cei wrote: Il giorno 29/ott/04, alle 12:41, Jeremy Quinn ha scritto: What I hope to do is to make the Queries persistable in HSQLDB via ORO and add this to Cocoon as a new Block, both as a sample and as a useful module that should be easy to add to your own project. I'm sure you meant OJB instead of ORO here, right? Yeah, sorry :) OJB, OJB OJB . that is even worse than your OBJ mistake ;) No, it was Bertrand's mistake, not mine ;-) Ugo (who obviously has nothing better to do on a Friday afternoon than nitpicking) -- Ugo Cei - http://beblogging.com/ smime.p7s Description: S/MIME cryptographic signature
Re: [RT] StringTemplate: The answer to our templating needs?
Carsten Ziegeler wrote: Bertrand Delacretaz wrote: I don't think JXTG is broken now, it works well but the code is hard to understand and having all classes in a single huge source code file does not help. Yupp, that is one of the problems with JXTG. It would be great if a new solution would be pluggable to add new tag libs as well. I created a long time ago the TemplateObjectModelHelper which is in the scratchpad area. The idea of this class is to provide one single object model that can be used in various components, ++1 ! like a template generator/transformer, input moduls, java code etc. About Java code, do you mean in Actions, Transformers, etc? Or, you mean flowscript beans? In the end, regardless where you want to access objects (flow, template stuff, input modules) you always use the same way, like cocoon.request etc. Depending on the language the component provides the syntax may vary, like cocoon/request - but the path you use is always the same. Vadim
Re: [RT] StringTemplate: The answer to our templating needs?
Carsten Ziegeler wrote:
Leszek Gawron wrote:
And if there are language constructs that are not possible to
implement with JXPath and JavaBeans? And I am sure there are
(I had some problems myself but shoot me in the head: I do
not remember the exact cases). Should we be saying to users:
it does not work with JXPath, still it would with Jext,
since we dropped jexl officialy you have to plug it back in yourself?
I suggest an xpath based language not JXPath :) Yes, I had some
problems with JXPath as well, so I wouldn't use it but rather write an
own implementation which isn't that difficult.
I remember it having bugs like #{0 != ''} evaluating to false, but is it a
reason to reinvent the wheel? I'd rather prefer having common jxpath component
shared among many projects than each project start implementing xpath-like syntaxes.
Vadim
Re: Persisting SimpleLuceneQuery [Long]
On 29 Oct 2004, at 13:49, Ugo Cei wrote: Il giorno 29/ott/04, alle 14:36, Jeremy Quinn ha scritto: On 29 Oct 2004, at 13:23, Ugo Cei wrote: Il giorno 29/ott/04, alle 12:41, Jeremy Quinn ha scritto: What I hope to do is to make the Queries persistable in HSQLDB via ORO and add this to Cocoon as a new Block, both as a sample and as a useful module that should be easy to add to your own project. I'm sure you meant OJB instead of ORO here, right? Yeah, sorry :) OJB, OJB OJB . that is even worse than your OBJ mistake ;) No, it was Bertrand's mistake, not mine ;-) Bejesus !!! I have done it again ;) Ugo (who obviously has nothing better to do on a Friday afternoon than nitpicking) Glad to see you enjoying yourself, mate ;) regards Jeremy If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! smime.p7s Description: S/MIME cryptographic signature
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
That's exactly what I suggest above: we choose a standard default
language, but open the possibility to plug in new ones. XPath is a
must-have, Jexl and IM have very valid use cases which IMO justify
them to be provided by Cocoon. Other languages are just a possibility
that we offer _if_ people want to add their own language.
What can you do with Jexl what you can't do with an XPath based
language? My understanding is that they only differ in their syntax
('.' instead of '/').
Now even if Jexl has more functionality I don't see a reason why
this could not be added to an xpath based language.
Technically this should be possible, but how do we write something like
widget.getChild(foo).getAttribute(bar) in XPath?
Tecnically, this will be
getAttribute(getChild($widget, foo), bar)
in JXPath. Not exactly easy to read, but possible :)
Vadim
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Le 29 oct. 04, à 15:05, Vadim Gritsenko a écrit : Sylvain Wallez wrote: ...Technically this should be possible, but how do we write something like widget.getChild(foo).getAttribute(bar) in XPath? Tecnically, this will be getAttribute(getChild($widget, foo), bar) in JXPath. Not exactly easy to read, but possible :) And technically in plain XPath it would be something like //widget/foo/@bar -Bertrand smime.p7s Description: S/MIME cryptographic signature
[BUG] Redirector is null in handle-errors
I just tried to make a redirect inside an error-handler and it doesn't work as the redirector on the InvokeContext is not set. So it seems that we have to set it in the ErrorHandlerHelper class when the new error invoke context is created. The question is now, which redirector implementation to use? The same as the one used for the InvokeContent during pipeline executing? A new one? Thoughts? Carsten
RE: [RT] StringTemplate: The answer to our templating needs?
Vadim Gritsenko wrote: like a template generator/transformer, input moduls, java code etc. About Java code, do you mean in Actions, Transformers, etc? Or, you mean flowscript beans? No, I meant Action, Transformers etc. Carsten
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
What can you do with Jexl what you can't do with an XPath based
language? My understanding is that they only differ in their syntax
('.' instead of '/').
Now even if Jexl has more functionality I don't see a reason why
this could not be added to an xpath based language.
Technically this should be possible, but how do we write something
like widget.getChild(foo).getAttribute(bar) in XPath?
Tecnically, this will be
getAttribute(getChild($widget, foo), bar)
in JXPath. Not exactly easy to read, but possible :)
That's what I meant: not exactly easy to read, especially for someone
having the related Java API in mind :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Persisting SimpleLuceneQuery [Long]
Jeremy Quinn wrote: On 29 Oct 2004, at 13:37, Unico Hommes wrote: Jeremy Quinn wrote: If email from this address is not signed IT IS NOT FROM ME Always check the label, folks ! Aha! I'm on to you, person that wants to make believe he is Jeremy Quinn! ;-) ROFL Objective reality is a synthetic construct, dealing with a hypothetical universalization of a multitude of subjective realities. Philip K Dick - The Electric Ant Ah see, I *knew* it was you after all. I should better tune my intra-subjective antennae ;-) -- Unico
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Bertrand Delacretaz wrote: Le 29 oct. 04, à 15:05, Vadim Gritsenko a écrit : Sylvain Wallez wrote: ...Technically this should be possible, but how do we write something like widget.getChild(foo).getAttribute(bar) in XPath? Tecnically, this will be getAttribute(getChild($widget, foo), bar) in JXPath. Not exactly easy to read, but possible :) And technically in plain XPath it would be something like //widget/foo/@bar IIUC, JXPath has pluggable introspectors, so it above can be reduced to: $widget/foo/@bar Vadim
Re: [RT] StringTemplate: The answer to our templating needs?
Carsten Ziegeler wrote: Vadim Gritsenko wrote: like a template generator/transformer, input moduls, java code etc. About Java code, do you mean in Actions, Transformers, etc? Or, you mean flowscript beans? No, I meant Action, Transformers etc. If you already thought about it, how would you pass top level cocoon object into actions, transformers, etc? Vadim
RE: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
-Original Message- From: Vadim Gritsenko [mailto:[EMAIL PROTECTED] Bertrand Delacretaz wrote: Le 29 oct. 04, à 15:05, Vadim Gritsenko a écrit : Sylvain Wallez wrote: ...Technically this should be possible, but how do we write something like widget.getChild(foo).getAttribute(bar) in XPath? Tecnically, this will be getAttribute(getChild($widget, foo), bar) in JXPath. Not exactly easy to read, but possible :) And technically in plain XPath it would be something like //widget/foo/@bar IIUC, JXPath has pluggable introspectors, so it above can be reduced to: $widget/foo/@bar Vadim Or maybe one or more DynamicPropertyHandlers are enough (or are those the same as the introspectors you're talking about?). Bart.
RE: [RT] StringTemplate: The answer to our templating needs?
Vadim Gritsenko wrote: Carsten Ziegeler wrote: Vadim Gritsenko wrote: like a template generator/transformer, input moduls, java code etc. About Java code, do you mean in Actions, Transformers, etc? Or, you mean flowscript beans? No, I meant Action, Transformers etc. If you already thought about it, how would you pass top level cocoon object into actions, transformers, etc? Not that much, but if you look at the TemplateObjectModelHelper: it returns a Map - this map is your entry point and you can use an expression like cocoon.request on this map and it should work. That's just a start. Carsten
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Vadim Gritsenko wrote:
Bertrand Delacretaz wrote:
Le 29 oct. 04, à 15:05, Vadim Gritsenko a écrit :
Sylvain Wallez wrote:
...Technically this should be possible, but how do we write
something like widget.getChild(foo).getAttribute(bar) in XPath?
Tecnically, this will be
getAttribute(getChild($widget, foo), bar)
in JXPath. Not exactly easy to read, but possible :)
And technically in plain XPath it would be something like
//widget/foo/@bar
IIUC, JXPath has pluggable introspectors, so it above can be reduced to:
$widget/foo/@bar
Eeek. Do you really think people will write their introspectors to have
a readable syntax?
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Le 29 oct. 04, à 15:51, Sylvain Wallez a écrit : Vadim Gritsenko wrote: Bertrand Delacretaz wrote: ... And technically in plain XPath it would be something like //widget/foo/@bar IIUC, JXPath has pluggable introspectors, so it above can be reduced to: $widget/foo/@bar Eeek. Do you really think people will write their introspectors to have a readable syntax? I'm a bit lost here (ok it's Friday ;-) JXPath *does* actually do stuff like $bean/member/submember, right? And according to its docs [1] it should also allow $bean/member/@submember and return the same result. So, I don't see what we're talking about really - I must be missing something obviously ;-) -Bertrand [1] http://jakarta.apache.org/commons/jxpath/users-guide.html#Attributes smime.p7s Description: S/MIME cryptographic signature
Re: Cocoon read-only (ex: CD-ROM) add ${context-work} parameter to logkit.xconf from CocoonServlet.java
Vadim Gritsenko wrote:
Frédéric Glorieux wrote:
I'm usually running multiple instances of same cocoon for debug
(different ports, different servletPath, to test under different
contexts and initParams). I know how to find my logs in such ways, but
with the config upper, it may be nice to have something like
{webapp}/WEB-INF/work/{ServletName}_{host}_{port}_{ServletPath}/logs
instead of
{webapp}/WEB-INF/work/cocoon-files/logs
I tried to found a way to get these infos from *CocoonServlet.java*
line 271, but ServletContext and ServletConfig don't seems to expose
those infos. It's of course a very bad idea to wait for the first
request to get {host}_{port}_{ServletPath} for a log path, but if more
guru than me have an idea of a 2 line solution...
Problem is, you can run *same* Cocoon instance with different hosts,
ports, etc. So no, this idea is not feasible.
OK, so this thread is closed. I was thinking about something like the
tomcat work hierarchy
Catalina
localhost
-
admin
...
probably too heavy for Coocoon, if someone need it, why not use tomcat :o) ?
--
Frédéric Glorieux (ingénieur documentaire, AJLSM)
http://www.ajlsm.com
Re: svn commit: rev 55895 - cocoon/branches/BRANCH_2_1_X
Vadim Gritsenko wrote: PS You re-generated blocks.properties, not hand-edited it, right? I hand-edited it at first, and then I found the re-generation script, ran it, and the result was the same. Vadim Tony
RE: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
I don't know if I'm right here, but...
- For java objects, Jexl can do more than JXPath.
- For DOM trees, JXPath is better (readible).
Maybe it's a good idea to configure the expression language you want to
use? E.g. in the configuration of the JXTG, or maybe passing it as a
parameter in map:generate ..., so that the JXTG has one expression
language when it is generating XML. Then it's fairly easy to swich from
language, based on the type of data you provide.
Bart.
-Original Message-
From: Sylvain Wallez [mailto:[EMAIL PROTECTED]
Sent: Friday, October 29, 2004 3:22 PM
To: [EMAIL PROTECTED]
Subject: Re: Expression languages (was Re: [RT] StringTemplate: The
answer
to our templating needs?)
Vadim Gritsenko wrote:
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
What can you do with Jexl what you can't do with an XPath based
language? My understanding is that they only differ in their
syntax
('.' instead of '/').
Now even if Jexl has more functionality I don't see a reason why
this could not be added to an xpath based language.
Technically this should be possible, but how do we write something
like widget.getChild(foo).getAttribute(bar) in XPath?
Tecnically, this will be
getAttribute(getChild($widget, foo), bar)
in JXPath. Not exactly easy to read, but possible :)
That's what I meant: not exactly easy to read, especially for someone
having the related Java API in mind :-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Bertrand Delacretaz wrote:
Le 29 oct. 04, à 15:51, Sylvain Wallez a écrit :
Vadim Gritsenko wrote:
Bertrand Delacretaz wrote:
...
And technically in plain XPath it would be something like
//widget/foo/@bar
IIUC, JXPath has pluggable introspectors, so it above can be reduced
to:
$widget/foo/@bar
Eeek. Do you really think people will write their introspectors to
have a readable syntax?
I'm a bit lost here (ok it's Friday ;-)
JXPath *does* actually do stuff like $bean/member/submember, right?
And according to its docs [1] it should also allow
$bean/member/@submember and return the same result.
Sure, but the point is about accessing methods that aren't JavaBean
accessors, e.g. how would JXPath know that foo/bar/@baz should be
translated to foo.giveMeAValue(bar).andAnotherOne(baz).
So, I don't see what we're talking about really - I must be missing
something obviously ;-)
Mmmh... time to go for a relaxing week-end, Bertrand ;-)
Sylvain
--
Sylvain Wallez Anyware Technologies
http://www.apache.org/~sylvain http://www.anyware-tech.com
{ XML, Java, Cocoon, OpenSource }*{ Training, Consulting, Projects }
Re: Implementation of the Continuations checker
Vadim Gritsenko said: Nicola Ken Barozzi wrote: Unico Hommes wrote: ... I believe that the excalibur event package lives on at d-haven [1]. Why not use that? Or we could stick with excalibur-event, if there is nothing wrong with it. I believe the major concern is making sure that the Cocoon core only relies on solid, well-supported components backed by strong communities. My understanding, and I could be wrong, is that excalibur no longer fits that description. I don't know if that is true of D-Haven Event. The site only lists 4 members on the project team, however I'm pretty sure at least two of them are quite active in other open source projects. Out of curiosity, does anyone know what else might be using this? Ralph
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Bertrand Delacretaz wrote: Le 29 oct. 04, à 15:51, Sylvain Wallez a écrit : Vadim Gritsenko wrote: Bertrand Delacretaz wrote: ... And technically in plain XPath it would be something like //widget/foo/@bar IIUC, JXPath has pluggable introspectors, so it above can be reduced to: $widget/foo/@bar Eeek. Do you really think people will write their introspectors to have a readable syntax? No. But we already do this for CForms and JavaScript. Why not for JXPath? It's totally feasible. I'm a bit lost here (ok it's Friday ;-) JXPath *does* actually do stuff like $bean/member/submember, right? Yes, it does, if you have getMember() in $bean, and getSubmember() in $bean/member. And according to its docs [1] it should also allow $bean/member/@submember and return the same result. So, I don't see what we're talking about really - I must be missing something obviously ;-) But we were talking about getChild(foo)... Vadim -Bertrand [1] http://jakarta.apache.org/commons/jxpath/users-guide.html#Attributes
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Le 29 oct. 04, à 17:20, Vadim Gritsenko a écrit : ..But we were talking about getChild(foo)... got it now - thanks ;-) -Bertrand smime.p7s Description: S/MIME cryptographic signature
Re: [RT] StringTemplate: The answer to our templating needs?
Leszek Gawron said: JXTG is very good but it lacks a way to extend it with some reusable pieces of code (macros). I have been trying to make some other templating languages be usable with cocoon but all of them are generating TEXT and in cocoon xml land this is a real problem. Here JXTG is really powerful. It will convert every model value to XML safe representation. I say: let's stick to JXTG just add some power with the ability to write more sophisticated macros/taglibs. I tend to agree with Leszek's sentiments above. Perhaps people would be more comfortable with JXTG if it was refactored into a more readable form. In my organization I have only heard two complaints about JXTG: 1. They cannot generate XML the way they would like. Because it requires the template to be valid XML it is sometimes difficult to generate a valid XML document. A way to generate start and end tags would be useful. 2. The ability to add tag libraries easily to it is a must. Perhaps item 1 could be implemented that way. Interestingly, I've heard very few complaints that it supports two syntaxes. Most people don't seem to care what the syntax is as long as they can find a way to get the job done. Ralph
DO NOT REPLY [Bug 31857] - [PATCH] Portal - Page Labels
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=31857. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=31857 [PATCH] Portal - Page Labels --- Additional Comments From [EMAIL PROTECTED] 2004-10-29 17:02 --- Created an attachment (id=13262) Fixes a minor bug in the original code.
RE: [BUG] Redirector is null in handle-errors
Ok I did a quick fix and simply pass the redirect of the original context. This seems to work...at least for me. Carsten -Original Message- From: Carsten Ziegeler [mailto:[EMAIL PROTECTED] Sent: Friday, October 29, 2004 3:15 PM To: Cocoon-Dev Subject: [BUG] Redirector is null in handle-errors I just tried to make a redirect inside an error-handler and it doesn't work as the redirector on the InvokeContext is not set. So it seems that we have to set it in the ErrorHandlerHelper class when the new error invoke context is created. The question is now, which redirector implementation to use? The same as the one used for the InvokeContent during pipeline executing? A new one? Thoughts? Carsten
Re: A widget framework (long)
Hello
I really appreciate you taking the time to look through the code. I've
inlined some comments below.
On Thu, 2004-10-28 at 15:06, Sylvain Wallez wrote:
Jonas Ekstedt wrote:
On Thu, 2004-10-28 at 12:50, Reinhard Poetz wrote:
After reading it once, one question: Do you see any way to integrate your ideas
into Cocoon Forms?
One part that I believe could be incorporated into CForms would be how
the view model is populated.
That's the ugly I was mentioning in my previous post : this is a very
dangerous approach, similar to the now defunct XMLForm (see [1],
mapping to the application data model). Having a direct and live
mapping from the form to the data model is an open door to inconsistent
business data in case validation fails.
Furthermore, just like XMLForm, your approach doesn't allow smart
convertors to be defined, taking into account formats, locale, etc. And
validation occurs on strings, which is just why we rejected the use of
Commons Validator, as CForms widgets have strongly typed values.
The models I provided do indeed map directly to the application object,
but this was on purpose. There are use cases when that is needed (eg.
when a bean provides derived values).
The next step is to create datamodels addressing the needs you
described. Here are some ideas that I've come up with:
* Cloning models
Operates on a clone of the application object. I'm working on a
ClonedBeanModel, and sketching a TransactionResultSetModel. The former
clones the application bean, and only when the user so request, updates
the application bean. The TransactionResultSetModel would copy the
resultset to a separate datastructure and similarly only update the
database when finished.
* Typesafe models with value conversions
This is an extension of the the cloned models concept with the addition
of type checking and value conversion in the getValue/setValue
functions.
* Secure models
The user can condition getting/setting of values by defining a security
policy. Eg. A user with role=administrator can set the property A to
any of {1, 2, 3} but a user with role=user can only set it to any of
{1, 2}.
As an example of a typesafe model with value conversion I updated the
framework to include a CFormModel that wraps a Cocoon Forms form. You
can download it at http://home.student.uu.se/j/joek8725/widgets.html.
The CFormModel takes advantage of the type checking and value conversion
in CForms as well as enable you to protect your business object from
being inconsistent using cforms binding. It should be said however that
the CFormModel is a terrible hack and should only be considered as an
example.
I added some samples as well. A CFormModel based Calculation wizard that
shows you type checking as well as a Personnel editor that uses CForms
binding to protect the application object.
Cheers
--
Jonas
RE: Implementation of the Continuations checker
Ralph Goers wrote: I believe that the excalibur event package lives on at d-haven [1]. Why not use that? Or we could stick with excalibur-event, if there is nothing wrong with it. I believe the major concern is making sure that the Cocoon core only relies on solid, well-supported components backed by strong communities. My understanding, and I could be wrong, is that excalibur no longer fits that description. Don't know the answer to that, but: excalibur event is deprecated and no longer used. Fortress that was using excalibur event has moved to d-haven event. We have a possible bug that was reported recently on this list. I don't know if that is true of D-Haven Event. The site only lists 4 members on the project team, however I'm pretty sure at least two of them are quite active in other open source projects. Out of curiosity, does anyone know what else might be using this? Apart from Fortress? Don't know. Ok, let's see what we have: Cocoon is not using the Event package at all, apart from the continuations checker which can be implemented in just a few lines - I did this for 2.2 - apart from that Cocoon does not need it. There are people out there who might be using this package for their own projects - so we can: a) keep it to support possible users although we don't need it. Keeping it might be a little bit difficult as it's already deprecated and the future is unknown. b) replace it with something else, users have to migrate and we then support the users although we don't need it. c) remove it and if a user needs it she can add it as her own component and use it. HINTthis is not a vote/HINT Don't know which is best, but I tend to option c) in this case. Carsten
Re: [Proposal] New Block building system
Reinhard Poetz wrote: Stefano Mazzocchi wrote: Reinhard Poetz wrote: More information and explanations can be found at http://wiki.apache.org/cocoon/CocoonBlockBuilder [not critizing, just curious] can you explain why you think that having block/lib is going to be jar hell while lib/block is not? I would really like to see block/lib instead of lib/block but without Pier's shielding classloader I don't see how we do NOT end in jar versioning hell. Good point. +1 to your choice. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] StringTemplate: The answer to our templating needs?
Giacomo Pati wrote: On Fri, 29 Oct 2004, Reinhard Poetz wrote: Tony Collen wrote: Do we need a new, (standardized?) or possibly even *gasp* better templating system for Cocoon? This is where I encourage people to dive in and give their own [RT]s and thoughts on the issue. First, thank you for the pointer. Interesting stuff. But first, we should agree on our needs and then we should choose a technology. IMO less is more - the templating engine should really focus on presenting data. I see following needs: - really powerful query language to access * all kind of objects * incl. passed DOM trees - control structures like for/each, if, choose - call methods on passed objects - stream objects (DOM, XMLizable, ...?) - and probably a way to define macros (see cForm macros) Add this: - works as a Transformer (SAX pipeline) Don't know whether we need the possibilty to use xPath expressions on passed objects. On one hand it would be helpful, on the other we probably end again with two different syntax. XPath is what we're used to when writing xslt stylesheets. The Java dotted notation is what we're used to when writing Java code. As the templating engine will most likely be some xml syntax XPath make IMHO much more sense to me than dottet notation. May I remind you people of Pier's Garbage? He lost interest in it, but I personally like the approach very much. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [RT] StringTemplate: The answer to our templating needs?
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while
Jexl is mostly useless in that case but is straightforward
when you deal with JavaBeans. I also agree that understanding
the difference between ${continuation.id} and
#{$continuation/id} is less than evident.
So what about a unified syntax for expansion tokens, within
which different languages could be used. Example:
- ${continuation.id} // Jexl, default syntax
- ${xpath:$continuation/id} // xpath
- ${im:defaults:skin} // input-module
- ${ognl:$continuation.id} // OGNL [1]
Hmm, one of the things I really don't like with JXTG is that you
have to different expression languages. You never know which to
use and some things work only with one specific language.
And for me this comes near to FS :)
Amen. I wouldn't even go for plugins. Let's chose one syntax and just
use that.
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: Expression languages (was Re: [RT] StringTemplate: The answer to our templating needs?)
Sylvain Wallez wrote:
Carsten Ziegeler wrote:
Sylvain Wallez wrote:
XPath is a must-have when you deal with XML documents while Jexl is
mostly useless in that case but is straightforward when you deal with
JavaBeans. I also agree that understanding the difference between
${continuation.id} and #{$continuation/id} is less than evident.
So what about a unified syntax for expansion tokens, within which
different languages could be used. Example:
- ${continuation.id} // Jexl, default syntax
- ${xpath:$continuation/id} // xpath
- ${im:defaults:skin} // input-module
- ${ognl:$continuation.id} // OGNL [1]
Hmm, one of the things I really don't like with JXTG is that you
have to different expression languages. You never know which to
use and some things work only with one specific language.
And for me this comes near to FS :)
Agree, but considering the wide variety of applications contexts where
Cocoon is used, I don't think there can be a single one-size-fits-all
language.
There are also a number of places in Cocoon where we need to evaluate
expressions: templates, sitemap, form validators, form bindings, etc,
which are currently implemented separately with different syntaxes. We
need a common expression evaluation component.
So, let's decide on one language that we think is the best, but
let's provide a hook so others can plugin their language if *they*
want to.
That's exactly what I suggest above: we choose a standard default
language, but open the possibility to plug in new ones. XPath is a
must-have, Jexl and IM have very valid use cases which IMO justify them
to be provided by Cocoon. Other languages are just a possibility that we
offer _if_ people want to add their own language.
Excuse my ignorance, but can you outline the pro/cons of each path
language, along with what it can't be done with it that can be done with
others?
I guess that would be helpful for people to decide.
--
Stefano.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [RT] StringTemplate: The answer to our templating needs?
Carsten Ziegeler wrote: Bertrand Delacretaz wrote: I don't think JXTG is broken now, it works well but the code is hard to understand and having all classes in a single huge source code file does not help. Yupp, that is one of the problems with JXTG. It would be great if a new solution would be pluggable to add new tag libs as well. I created a long time ago the TemplateObjectModelHelper which is in the scratchpad area. The idea of this class is to provide one single object model that can be used in various components, like a template generator/transformer, input moduls, java code etc. In the end, regardless where you want to access objects (flow, template stuff, input modules) you always use the same way, like cocoon.request etc. Depending on the language the component provides the syntax may vary, like cocoon/request - but the path you use is always the same. I like! -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Implementation of the Continuations checker
Bart Molenkamp wrote: Maybe CRON can handle this job? Or isn't it a good idea to have the core of Cocoon depent on CRON? unfortunately, CRON is not a portable service across OS and we do support silly microsoft OSs too. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Implementation of the Continuations checker
Stefano Mazzocchi wrote: Bart Molenkamp wrote: Maybe CRON can handle this job? Or isn't it a good idea to have the core of Cocoon depent on CRON? unfortunately, CRON is not a portable service across OS and we do support silly microsoft OSs too. We have a Cron block based on Quartz scheduler. I believe Bart was referring to the block. Vadim (one of those sitting on silly OSes)
Re: Implementation of the Continuations checker
Unico Hommes wrote: Giacomo Pati wrote: On Fri, 29 Oct 2004, Carsten Ziegeler wrote: Giacomo Pati wrote: On Fri, 29 Oct 2004, Carsten Ziegeler wrote: The current implementation of our continuations manager uses the excalibur event package for the background checker that checks for expired continuations. Now, this approach has the problem, that excalibur event is deprecated. In addition we aren't using it somewhere else, so it would be great if we could remove this dependency. Yesterday, I wrote a simple replacement which I checked into 2.2: a simple background thread is initialized that sleeps for a configured period of time, checks the continuations, sleeps etc. Now, this solution should work. The question is now, should I port this to 2.1.x as well? Are there better solutions? Does this mean the CommandManager from the Context is gone? Yes, at least for 2.2 - for 2.1.x we would have to decide if we remove it. Are you using it? Yes, we used the CommandManager in some projects. It is based on the PooledExecutor from Doug Leas concurrent-utils package. It comes in quite handy as you can put tasks there you'd like to be done asynchroniously (ie. indexing a uploaded document with lucene to speed up percieved performance). I believe that the excalibur event package lives on at d-haven [1]. Why not use that? 1. http://api.d-haven.org/event/ because, with all due respect to Berin, this is another one man show and we are sick of having them change under our feet. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: Implementation of the Continuations checker
Vadim Gritsenko wrote: Nicola Ken Barozzi wrote: Unico Hommes wrote: ... I believe that the excalibur event package lives on at d-haven [1]. Why not use that? Or we could stick with excalibur-event, if there is nothing wrong with it. Oh oh. We did this discussion with the container, I hope we don't have to go over this again for every Avalon dependency we have ;-P This smells a lot as NIH syndrome [1]. Are we going to rewrite every single excalibur component we use? Potentially, yes. It's a small price to pay to gain solidity of your foundations. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
Re: [Proposal] New Block building system
Reinhard Pÿfff6tz wrote: --- Stefano Mazzocchi [EMAIL PROTECTED] schrieb: Reinhard Poetz wrote: Stefano Mazzocchi wrote: Reinhard Poetz wrote: More information and explanations can be found at http://wiki.apache.org/cocoon/CocoonBlockBuilder [not critizing, just curious] can you explain why you think that having block/lib is going to be jar hell while lib/block is not? I would really like to see block/lib instead of lib/block but without Pier's shielding classloader I don't see how we do NOT end in jar versioning hell. Good point. +1 to your choice. I think it can provide a smooth transition from current blocks to RealBlocks and the work can be done in incremental steps. Agreed. Stefano and others, What do you think, should I continue with the new block build system? Go right ahead. -- Stefano. smime.p7s Description: S/MIME Cryptographic Signature
