[SOT] SingleThreaded components vs. Singletons

[Reinhard Poetz]

For a quick hack I wrote a singleton (simple Java class) that manages the 
Hibernate SessionFactory. As it is only a Cocoon/Hibernate-demo I haven't 
thought much about it, but if I use Hibernate in production, I would write a 
SingleThreaded Avalon component. I would do it because Cocoon is based on 
Avalon, but are there any technical reasons?

--
Reinhard

Re: JXTemplateGenerator

[Christopher Oliver]

Christopher Oliver wrote: > It's not personal, Bertrand. If someone 
does good work or makes a valid > point I will give them proper 
respect. If not, well, I'm not teaching > grade school and it's not my 
job to sugar coat it. 

Really? Wasn't that you that disliked the way Pierpaolo and myself 
avoided the sugar coating when we criticized the FOM design? 
To be honest, Pier's tone doesn't bother me, because he always has been 
able to back it up with valid points, real code, and humorous side comments.

Again, you fail to understand that what appears to be "pointless 
refactoring" for you might well be what turns a sandboxed one-man-show 
proposal into the official community-supported cocoon template system. 
Actually, I think I do (and did) understand that. And Daniel's and some 
others specific suggestions about how to improve the code seem very 
valid to me. So more power to them. However, mixed in that discussion 
were a number of silly ideas (which somehow need to be identified as 
such in order to make positive progress - and when that happens it can 
be painful or embarassing for somebody who feels personally responsible 
for them - but that's part of life).

William Strunk, Jr. and E.B. White, in their book "The Elements of 
Style" (New York, 1959) [page 70] write: "No one can write decently 
who is distrustful of the reader's intelligence, or whose attitude is 
patronizing". 

Let's face it: your code is dense as a neutron star and dense of 
comments and tests as the the outter space around one. 
For what it's worth I do like _your_ writing style above.
Your respect/care for the complexity of the social dynamics that 
originate around it is close to zero. 
Now, let me tell _you_ a story:
I play basketball 3-4 nights a week at the park by my house - 
"streetball", not organized basketball.  Now basketball is a fast paced 
game that requires split-second  decision making. As a result even the 
best players make mistakes in virtually every game. When an experienced 
player commits a turnover, misses an easy shot, misses a defensive 
assigment or whatever, there's no feeling of embarassment because it's 
known to be part of the game. However, inexperienced players tend to 
take their own mistakes as a personal reflection on their ability and 
tend to get embarassed or angry when one of their teamates points it out.

Now, since this is streetball and anyone can play, many different people 
of different skill levels show up.  However, in this case there is a 
harsh reality that if you don't know how to play the game well enough, 
you're likely to get embarassed by getting scored on, having the ball 
stolen from you, or your shots rejected. The only way not to get 
embarassed is to improve your game, to learn from your own mistakes - 
persevering through those embarassing moments - and to learn from other 
players. Anyone who has achieved any skill at basketball has gone 
through this process.

The avalon project was taken over by peop le like you, that considered 
"consensus by friction" a better way to achieve progress and reduce 
the noisy babbage of social interaction with "inferior" talents. 
Result: social entropy expansion that lead to thermal death. 
I don't agree that I am anything like them and I don't think you would 
say that if your really knew me.

Technical problems are way more trivial to solve than social ones. 
Personally, I find both types of problems hard to solve.
Everybody here welcomes contributions, not matter how silly, not 
matter how technologically savvy, now matter how outrageous and no 
matter how sinful and ranting. But respect for your peers is key. 
Unfortunately, true respect is earned, not given.  So it's not that simple.
-- Stefano.
As for Tony, I believe if you look back you might notice that I took the 
initiative in adding the excellent flowscript tutorial that he wrote to 
Cocoon. Hopefully, he does feel that was a compliment (which it was).

-- Chris

DO NOT REPLY [Bug 32156] - [PATCH] Fix for cocoon.jar bundled in ear common for portal.war and portlet.war

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32156





--- Additional Comments From [EMAIL PROTECTED]  2004-12-12 02:51 ---
I'm not sure how this works. As things stand right now, Cocoon cannot be put
into a war (unless websphere explodes it) as PortletDefinitionRegistryImpl uses
getRealPath to locate companion portlets and doesn't expect to find war files.
When I tried to put a Cocoon war containing the portal in Weblogic I got a null
pointer exception during startup.

I also don't understand why you need to place cocoon.jar in the EAR's
APP-INF/lib directory. Could you clarify why that is required?

Despite all that, I guess I understand the issue this patch is trying to solve
and I am going to test it, since what you are trying to fix does seem to be a
problem.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

DO NOT REPLY [Bug 31524] - [PATCH] Contribution page is out of date because moved to SVN

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=31524


[EMAIL PROTECTED] changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED




--- Additional Comments From [EMAIL PROTECTED]  2004-12-12 02:33 ---
It appears that a lot of reformatting was done to the original document in the
attachment.  Anyway, I updated the document to reflect the switch from cvs to 
svn.
Setting to fixed.  Please verify after the site has been updated and close this.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

Re: how to list all sitemap components

[J.Pietschmann]

David Crossley wrote:
Geoff Howard wrote:
I'd just use eclipse to find every class that implements the right
interface(s).  Would that work?

Thanks Geoff. However, command-line tools only
because i need to script it. Sorry, i forgot
to specify that.
A bit of BCEL should do the trick.
J.Pietschmann

Re: Templating: experiments with Conal's html-to-xslt transform

[Christian Stocker]

On 11.12.2004 18:37 Uhr, Gregor J. Rothfuss wrote:
Christian Stocker wrote:
As I mentioned before (to one of stefano's posts), we did something 
similar, but with the TAL syntax. We convert that to XSLT with XSLT 
and then do the actual transformation with XSLT. It's the same idea as 
yours. I like the approach, even though it's not complete yet (our 
implementation) and we could certainly add some of your ideas.

Here's the XSLT
http://svn.bitflux.ch/repos/public/popoon/trunk/components/transformers/xsltal/tal2xslt.xsl 

and here's simplel template
http://svn.bitflux.ch/repos/public/bxcmsdemo/themes/bxcms/template.tal
I don't say, our approach is better than yours, I didn't build an 
opinion on that. But maybe we could join efforts in it. As it's a pure 
XSLT implementation, the programming language behind doesn't really 
matter.

and to take this one step further, what would it take to make these 
templates editable in BXE? being able to make layout changes inside the 
lenya GUI, say, would rock.
The templates are XML, so in principle, no problem for BXE. If it's 
attribute driven, even less.

What would really rock is some templating-enhanced mode. Not sure, what 
that should include, but maybe some straightforward 
adding-template-attributes stuff or real-time transformation to see the 
actual result or Build-My-XPath wizards or whatever.

Btw, I didn't find the time to compare TAL with Conal's approach, but I 
should have some time tomorrow to do that and build an opinion on my own..

chregu

--
christian stocker | Bitflux GmbH | schoeneggstrasse 5 | ch-8004 zurich
phone +41 1 240 56 70 | mobile +41 76 561 88 60  | fax +41 1 240 56 71
http://www.bitflux.ch  |  [EMAIL PROTECTED]  |  gnupg-keyid 0x5CE1DECB

Re: JXTemplateGenerator

[Ralph Goers]

Stefano Mazzocchi wrote:.
Everybody here welcomes contributions, not matter how silly, not 
matter how technologically savvy, now matter how outrageous and no 
matter how sinful and ranting.

But respect for your peers is key.
Without that, any voice, no matter whose, becomes immediately silent, 
if not distracting and harmful.

And yes, I have committed this crime myself (and not only here) but it 
always brought me harm, cold and isolation.

A big price to pay for a little ego self-massaging.
Stefano,
First, I agree wholeheartedly with your response.  However, I have to 
temper that by saying that arrogance and egotism are often tempered with 
age (I should know, right?). In my younger days I was quite arrogant. I 
figured it was my right, since I was good at what I did.  With time you 
learn that there are lots of smart people, and lots of people with 
talents that are different then your own.  For example, while I am great 
with code my skills at designing a web page are lousy. You will 
accomplish very little in life if the people you need help and 
cooperation from don't like you.

In short, it is always OK to criticize an idea or design or even a piece 
of code, but.it is not OK to make that be personal or form our 
criticisms in such a way that they seem to be.

Ralph

Re: JXTemplateGenerator

[Stefano Mazzocchi]

Christopher Oliver wrote:
It's not personal, Bertrand. If someone does good work or makes a valid 
point I will give them proper respect. If not, well, I'm not teaching 
grade school and it's not my job to sugar coat it.
Really? Wasn't that you that disliked the way Pierpaolo and myself 
avoided the sugar coating when we criticized the FOM design?

Again, you fail to understand that what appears to be "pointless 
refactoring" for you might well be what turns a sandboxed one-man-show 
proposal into the official community-supported cocoon template system.

For this to happen, ego and code ownership must be set aside and all 
points of views respectfully debated, especially during brainstorming 
sessions as the one we are experiencing.

William Strunk, Jr. and E.B. White, in their book "The Elements of 
Style" (New York, 1959) [page 70] write:

"No one can write decently who is distrustful of the reader's 
intelligence, or whose attitude is patronizing".

Let's face it: your code is dense as a neutron star and dense of 
comments and tests as the the outter space around one. Your respect/care 
for the complexity of the social dynamics that originate around it is 
close to zero.

The avalon project was taken over by people like you, that considered 
"consensus by friction" a better way to achieve progress and reduce the 
noisy babbage of social interaction with "inferior" talents.

Result: social entropy expansion that lead to thermal death.
Technical problems are way more trivial to solve than social ones. I 
personally feel sad for the dry world of those who consider the first 
more important than the second.

Given that the template system is the contract between skilled 
programmers and unskilled ones, social problems will have to be taken 
into consideration way more than technical ones.

Everybody here welcomes contributions, not matter how silly, not matter 
how technologically savvy, now matter how outrageous and no matter how 
sinful and ranting.

But respect for your peers is key.
Without that, any voice, no matter whose, becomes immediately silent, if 
not distracting and harmful.

And yes, I have committed this crime myself (and not only here) but it 
always brought me harm, cold and isolation.

A big price to pay for a little ego self-massaging.
--
Stefano.

Re: Templating: experiments with Conal's html-to-xslt transform

[Gregor J. Rothfuss]

Christian Stocker wrote:
As I mentioned before (to one of stefano's posts), we did something 
similar, but with the TAL syntax. We convert that to XSLT with XSLT and 
then do the actual transformation with XSLT. It's the same idea as 
yours. I like the approach, even though it's not complete yet (our 
implementation) and we could certainly add some of your ideas.

Here's the XSLT
http://svn.bitflux.ch/repos/public/popoon/trunk/components/transformers/xsltal/tal2xslt.xsl 

and here's simplel template
http://svn.bitflux.ch/repos/public/bxcmsdemo/themes/bxcms/template.tal
I don't say, our approach is better than yours, I didn't build an 
opinion on that. But maybe we could join efforts in it. As it's a pure 
XSLT implementation, the programming language behind doesn't really matter.
and to take this one step further, what would it take to make these 
templates editable in BXE? being able to make layout changes inside the 
lenya GUI, say, would rock.

-gregor

Re: Major bug with cocoon views -- Using views not really possible

[Thomas Alexnat]

Thank you -- I have submitted a new "ugreport (#32650) hope this will 
be fixed anytime... ;)

On 10.12.2004, at 18:33, Joerg Heinicke wrote:
On 10.12.2004 15:13, Thomas Alexnat wrote:
I also think, that this behaviour is a bug. To me it renders the 
usage of the cocoon view concept absolutely useless. My major point 
is, that is, that I cannot use the cocoon views to view my current 
matcher in XML. If I try to do that, everytime I have a 'aggreate' or 
'cocoon:/' protocol in my pipeline, the XSL scrambles the content, 
because previous matchers are also transformed. (see older mails from 
me)
The only workaround I currently know, is to generate the XML content 
in my own pipie -- not using views. This is not a feature to me, its 
more a big bug.
Where can I add this bug? Or to whom can I talk?
You are already talking to *us*, the Cocoon community. Though there 
are people who know more about the internals of Cocoon (sitemap, 
request processing) it is always a community thing and most of 
committers will read this list and so know about this issue. You might 
add it to bugzilla though so that it won't get forgotten. But there is 
no guarantee to get it fixed quickly.

Joerg

DO NOT REPLY [Bug 32650] New: - Transformations in views not usable when using aggregation or cocoon internal protocol: The xml gets transfomed more than once

[bugzilla]

DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG·
RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT
.
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=32650

   Summary: Transformations in views not usable when using
aggregation or cocoon internal protocol: The xml gets
transfomed more than once
   Product: Cocoon 2
   Version: 2.1.6
  Platform: All
OS/Version: Mac OS X 10.3
Status: NEW
  Severity: critical
  Priority: P1
 Component: core
AssignedTo: [EMAIL PROTECTED]
ReportedBy: [EMAIL PROTECTED]
CC: [EMAIL PROTECTED]


Using views seems work, until your content is being loaded internally via a 
'cocoon:/xyz' url or content 
aggregation. When you then XSL transform the XML in a view, the resulting tree 
is corrupt.

This can be verified by calling:
http://localhost:/a?cocoon-view=pretty-content
http://localhost:/b?cocoon-view=pretty-content  (here you will get a 
corrupt html tree)

It seems, that the view transformer gets called twice when using the second 
example. This makes the 
view concept pretty useless with this bug.


-   test.xml   -


   Hello World XML




- sitemap.xmap - (added to the original sitemap)








  


  



This issue has been tested on Cocoon 2.1.5 and 2.1.6 on OS X 10.3.6 on a 
PowerMac Dual G5 and Java 
1.4.2_05.

-- 
Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug, or are watching the assignee.

[GUMP@brutus]: Project cocoon-block-cron (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-cron has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-cron :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-cron/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [cron-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-cron/gump_work/build_cocoon_cocoon-block-cron.html
Work Name: build_cocoon_cocoon-block-cron (Type: Build)
Work ended in a state of : Failed
Elapsed: 5 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=11122004 -Dblock-name=cron gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-11122004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-11122004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-11122004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-11122004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-11122004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-11122004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-11122004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-11122004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-11122004.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-11122004/checkstyle-11122004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-11122004.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-11122004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-11122004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-11122004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/logkit/target/deliverables/jars/avalon-logkit-11122004.jar:/usr/local

[GUMP@brutus]: Project cocoon-block-template (in module cocoon) failed

[Gump]

To whom it may engage...

This is an automated request, but not an unsolicited one. For 
more information please visit http://gump.apache.org/nagged.html, 
and/or contact the folk at [EMAIL PROTECTED]

Project cocoon-block-template has an issue affecting its community integration.
This issue affects 1 projects,
 and has been outstanding for 7 runs.
The current state of this project is 'Failed', with reason 'Build Failed'.
For reference only, the following projects are affected by this:
- cocoon-block-template :  Java XML Framework


Full details are available at:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-template/index.html

That said, some information snippets are provided here.

The following annotations (debug/informational/warning/error messages) were 
provided:
 -DEBUG- Sole output [template-block.jar] identifier set to project name
 -INFO- Failed with reason build failed
 -INFO- Failed to extract fallback artifacts from Gump Repository



The following work was performed:
http://brutus.apache.org/gump/public/cocoon/cocoon-block-template/gump_work/build_cocoon_cocoon-block-template.html
Work Name: build_cocoon_cocoon-block-template (Type: Build)
Work ended in a state of : Failed
Elapsed: 8 secs
Command Line: java -Djava.awt.headless=true 
-Xbootclasspath/p:/usr/local/gump/public/workspace/xml-xerces2/java/build/xercesImpl.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/serializer.jar:/usr/local/gump/public/workspace/xml-xalan/java/build/xalan-unbundled.jar:/usr/local/gump/public/workspace/xml-commons/java/external/build/xml-apis.jar
 org.apache.tools.ant.Main 
-Dgump.merge=/home/gump/workspaces2/public/gump/work/merge.xml 
-Dbuild.sysclasspath=only -Dversion=11122004 -Dblock-name=template gump-block 
[Working Directory: /usr/local/gump/public/workspace/cocoon]
CLASSPATH: 
/opt/jdk1.4/lib/tools.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-11122004/blocks/template/test:/usr/local/gump/public/workspace/cocoon/tools/anttasks:/usr/local/gump/public/workspace/cocoon/build/cocoon-11122004/cocoon.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-11122004/cocoon-testcase.jar:/usr/local/gump/public/workspace/cocoon/build/cocoon-11122004/cocoon-deprecated.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-stylebook.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-jmf.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-swing.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-trax.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-junit.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant-nodeps.jar:/usr/local/gump/public/workspace/ant/dist/lib/ant.jar:/usr/local/gump/public/workspace/ant-contrib/build/lib/ant-contrib-11122004.jar:/usr/local/gump/public/workspace/xml-commons/java/build/resolver.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant-launcher.jar:/usr/local/gump/public/workspace/ant/bootstrap/lib/ant.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/api/target/deliverables/jars/avalon-framework-api-11122004.jar:/usr/local/gump/public/workspace/avalon-tools/tools/magic/target/deliverables/jars/avalon-tools-magic-11122004.jar:/usr/local/gump/public/workspace/dist/junit/junit.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/legacy/target/deliverables/jars/avalon-framework-legacy-11122004.jar:/usr/local/gump/public/workspace/avalon-trunk/runtime/framework/impl/target/deliverables/jars/avalon-framework-impl-11122004.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-i18n-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-compatibility-1.1.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-configuration-1.2.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-interfaces-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-1.0.jar:/usr/local/gump/packages/excalibur-legacy/excalibur-instrument-manager-1.0.jar:/usr/local/gump/public/workspace/excalibur/components/sourceresolve/target/excalibur-sourceresolve-11122004.jar:/usr/local/gump/public/workspace/checkstyle/target/dist/checkstyle-11122004/checkstyle-11122004.jar:/usr/local/gump/packages/antlr-2.7.3/antlr.jar:/usr/local/gump/public/workspace/jakarta-regexp/build/jakarta-regexp-11122004.jar:/usr/local/gump/public/workspace/jakarta-bcel/bin/bcel.jar:/usr/local/gump/public/workspace/jakarta-commons/beanutils/dist/commons-beanutils-core.jar:/usr/local/gump/public/workspace/jakarta-commons/cli/target/commons-cli-11122004.jar:/usr/local/gump/public/workspace/jakarta-commons/collections/build/commons-collections-11122004.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging.jar:/usr/local/gump/public/workspace/jakarta-commons/logging/dist/commons-logging-api.jar:/usr/local/gump/public/workspace/jdom/build/jdom.jar:/usr/local/gump/public/workspace/jakarta-velocity/bin/velocity-11122004.jar:/usr/loc

Re: JXTemplateGenerator

[Daniel Fagerstrom]

Bertrand Delacretaz wrote:
Le 11 déc. 04, à 00:57, Christopher Oliver a écrit :

..."General consensus" has turned out to be incorrect on many 
occasions.
I guess many of us have seeked comfort in that idea, when not geting 
things our way. But while it might be a relevant idea for describing 
science development, the notion of being "correct" is not particulary 
usefull for discussing software development. In software devekopment it 
is much more important to create so much interest in ones ideas that 
people invest the energy in them, that makes them _become_ right. Is 
Unix and Widows NT the _correct_ operating systems?

Like it or not, striving for concensus is an important part of how the 
Cocoon community works. If it is efficient or not must be evaluated from 
the well being of the community and the quality of what we deliver.

What I see is that some people, such as Stefano, are 
looking to build a better templating system while others are 
contemplating what appears to be pointless refactoring...
If the only goal is for these people to become more comfortable with the 
code by refactoring, and especially if they're creating new tests along 
the way it I'm happy. But I understand the refactoring can seem 
pointless to you as you know this code much better.
For successfull code the time invested in writing the first version of 
it, is often a quite small fraction of all the developer time invested 
in the piexe of code during the life time of the project. And in the 
further development of a piece of code, reading and understanding the 
code often takes much longer time than adding the few lines of code that 
corrects the bug or add the new feature.

As a consequence, the efficiency of a piece of code cannot only be 
evaluated in terms of how well it does its work, but it must also be 
evaluated in how efficient it _communicates_ what it does to the ones 
that are reading it. And the communication style of JXTG is IMO entirely 
consistent with the email communication style of its author ;)

So if we succeed in making JXTG easier to digest for the Cocoon 
developer community and nothing more, it is still far from pointless, as 
it will going to save a lot of developer time in the future.

Now, my motivation for being involved in refactoring of JXTG, is to get 
it in such shape that I feel comfortable in using it as base for 
developing some new ideas on. Some of these new ideas has been discussed 
on the list and some are RTs that I don't have discussed yet.

...Any 3000-lines java source file *is* scary in my book, detailed 
analysis would probably show that you code is indeed well structured, 
but looking at it as it is now is scary for many people, myself 
included.
OK, but the size of the source file has no effect on the behavior of 
the classes it contains. If someone wants to convert inner to external 
classes it is a trivial and mindless exercise.  In fact, I would 
hardly call it refactoring...
Point taken, it's more like restructuring (damn, is there a function key 
in IDEA to do this? ;-)

The important thing for me is not really how the code looks though, but 
how the people who are taking charge of it perceive it.
What have been done this far is just a first step, don't worry less 
mechanical things will be done. And while the size of a file doesn't 
affect its behavior, it might effect how well it communucates its behaviour.

...  On the other hand the issues that Stefano raised bring up real 
problems that are not addressed by JXTG at all (nor any of the 
suggested alternatives)...
Ok - there's probably more to do, but in the meantime JXTG is an 
important component of Cocoon, so whatever big or small work people do 
to improve it must be encouraged.

...It's not personal, Bertrand. If someone does good work or makes a 
valid point I will give them proper respect. If not, well, I'm not 
teaching grade school and it's not my job to sugar coat it.
It might not be your job to sugar coat things, but you take the risk of 
focusing your audience energy and the response you get into other areas 
than the technical discussion, by not doing an effort in that direction.

/Daniel

Re: JXTemplateGenerator

[Reinhard Poetz]

Christopher Oliver wrote:
"General consensus" has turned out to be incorrect on many occasions.  
What I see is that some people, such as Stefano, are looking to build a 
better templating system while others are contemplating what appears to 
be pointless refactoring.
As I prepare a presentation on web controller I read the thread where Ovidiu 
presented his continuations idea. General consensus was something like Struts 
did (and still does ;-) and it took a while until people began to understand 
what the power is. And look where we are today ... :-)
Anyway, just a sidenote.

My question is: Chris, you talked to Stefano IRL and read at least some of the 
mails of the templating discussion. What is your understanding where "next 
generation templating" should head to?

--
Reinhard

Re: JXTemplateGenerator

[Bertrand Delacretaz]

Le 11 déc. 04, à 00:57, Christopher Oliver a écrit :
..."General consensus" has turned out to be incorrect on many 
occasions.  What I see is that some people, such as Stefano, are 
looking to build a better templating system while others are 
contemplating what appears to be pointless refactoring...
If the only goal is for these people to become more comfortable with 
the code by refactoring, and especially if they're creating new tests 
along the way it I'm happy. But I understand the refactoring can seem 
pointless to you as you know this code much better.

...Any 3000-lines java source file *is* scary in my book, detailed 
analysis would probably show that you code is indeed well structured, 
but looking at it as it is now is scary for many people, myself 
included.
OK, but the size of the source file has no effect on the behavior of 
the classes it contains. If someone wants to convert inner to external 
classes it is a trivial and mindless exercise.  In fact, I would 
hardly call it refactoring...
Point taken, it's more like restructuring (damn, is there a function 
key in IDEA to do this? ;-)

The important thing for me is not really how the code looks though, but 
how the people who are taking charge of it perceive it.

...  On the other hand the issues that Stefano raised bring up real 
problems that are not addressed by JXTG at all (nor any of the 
suggested alternatives)...
Ok - there's probably more to do, but in the meantime JXTG is an 
important component of Cocoon, so whatever big or small work people do 
to improve it must be encouraged.

...It's not personal, Bertrand. If someone does good work or makes a 
valid point I will give them proper respect. If not, well, I'm not 
teaching grade school and it's not my job to sugar coat it.
I know, but we're all the grade school student of someone else here, 
depending on which area of expertise you consider. So we have to be 
careful not to break the (sometimes fragile) links which hold this 
great community together.

Thanks for your constructive reply (and for the initial comments about 
JXTG by the way, they will help a lot).

-Bertrand


smime.p7s
Description: S/MIME cryptographic signature